Opened 9 years ago

Closed 9 years ago

#114 closed technical (fixed)

EID-to-RLOC mapping - transients

Reported by: yakov@… Owned by:
Priority: major Component: alt
Severity: - Keywords:
Cc:

Description

From section 3:

EID-to-RLOC Database: The EID-to-RLOC database is a global

distributed database that contains all known EID-prefix to RLOC
mappings. Each potential ETR typically contains a small piece of
the database: the EID-to-RLOC mappings for the EID prefixes
"behind" the router. These map to one of the router's own,
globally-visible, IP addresses. The same database mapping entries
MUST be configured on all ETRs for a given site. That is, the
EID-prefixes for the site and locator-set for each EID-prefix MUST
be the same on all ETRs so they consistently send Map-Reply
messages with the same database mapping contents.

During the time period when the EID-to-RLOC mapping changes, and a site has multiple ETRs the spec has to document the procedures by which all the ETRs of a given site "consistently send Map-Reply messages with the same database mapping contents".

Change History (5)

comment:1 Changed 9 years ago by luigi@…

Reply sent by Vince Fuller:

  • Just as with routing protocols or any other distributed database, there will inevitibly be short windows where an update to the configuration on one device can lag an update to another device; configuring multiple ETRs with the same EID-to-RLOC mappings is no different. The existing text describes proper practice when configuration devices; the authors do not feel it is necessary to specifically state that the world won't come to an end if multiple ETRs with the same database mappings do not have their configurations updated at pricesly the same instant. If the issue author or another WG member believes that an explicit warning is necessary then the document authors welcome suggested text.

Note: ticket will be closed Friday 25th March unless the responses noted here do not address the concern. If the concern is still not addressed substantive reasoning would be appreciated.

comment:2 Changed 9 years ago by yakov@…

To address the issue please add the following after "That is, the
EID-prefixes for the site and locator-set for each EID-prefix MUST
be the same on all ETRs so they consistently send Map-Reply
messages with the same database mapping contents."

Note that there may be transient conditions when the EID-prefix for the site
and locator-set for each EID-prefix MAY not be the same on all ETRs. As a result,
for the duration of these transient conditions not all the ETRs would be able to
send Map-Reply messages with the same database mapping contents.

Furthermore, if the authors think that sending inconsistent Map-Reply during transients has no negative implications, then add the following at the end of the text I suggested above:

This has no negative implications.

And if the authors think that sending inconsistent Map-Reply during transients does have negative implications, then the authors should list them following the text I suggested above.


comment:3 Changed 9 years ago by luigi@…

Reply sent by Vince Fuller,

  • In looking at the recent email exchange with Yakov over item #114, I don't see where this issue applies to draft-ietf-lisp-alt since it doesn't say anything about consistent ETR configuration. The suggested text changes would appear to the definition of "EID-to-RLOC Database" in section 3 of draft-ietf-lisp, that currently reads as follows:
    • EID-to-RLOC Database: The EID-to-RLOC database is a global distributed database that contains all known EID-prefix to RLOC mappings. Each potential ETR typically contains a small piece of the database: the EID-to-RLOC mappings for the EID prefixes "behind" the router. These map to one of the router's own, globally-visible, IP addresses. The same database mapping entries MUST be configured on all ETRs for a given site. That is, the EID-prefixes for the site and locator-set for each EID-prefix MUST be the same on all ETRs so they consistently send Map-Reply messages with the same database mapping contents.

Seems like the simplest fix for this is simply to delete the last part of the last sentence: "so they consistently send Map-Reply messages with the same database mapping contents". Mandating consistent configuration should result in sending consistent EID-to-RLOC mappings in Map-Reply messages. The extra text invites unnecessary (IMHO) discussion of transient cases.

comment:4 Changed 9 years ago by terry.manderson@…

  • Resolution set to fixed
  • Status changed from new to resolved

As WG-Chairs we are closing this ticket. It is sufficient to document in draft-ietf-lisp that transients exist. As an experimental draft it is not necessary to require the draft to document all cases where the transient existence will cause a failure. That awareness can and will come, from experimentation and post analysis.

comment:5 Changed 9 years ago by terry.manderson@…

  • Status changed from resolved to closed
Note: See TracTickets for help on using tickets.