Opened 9 years ago

Closed 8 years ago

#66 closed technical (fixed)

Strict RLOC ordering causing problems on mapping changes

Reported by: luigi@… Owned by:
Priority: major Component: draft-ietf-lisp
Severity: - Keywords:
Cc:

Description (last modified by luigi@…)

This ticket groups together co-related issues concerning RLOC ordering raised by D. Papadimitriou and Y. Rekhter in their respective reviews.

From D. Papadimitriou's review:

Section 6.5 the section does not actually explain which messages are
used to update the list of Loc-Reach or Loc-Status bits. If it is data
traffic-driven then the mechanism is again dependent on the symmetry
of the reverse path and the packet rate but also packet differential
delays between packets. In the latter case, it is not clear how ITR
could retrieve the correct RLOCs to be used if a sequence of 8 packets
sent from ETR to ITR indicates 0,0,0,0,0,0,0,1 for a given RLOC
(indicated as available at arrival of the 8th packet) is received as
1,0,0,0,0,0,0,0. The section makes a long digression on ordering
locator set this is not the issue without a sequence number it will
never be possible for the receiving ITR to determine the actual state
of the EID-to-RLOC mappings at ETRs. This is even if ETR do not keep
track of who requested mappings upon communication they should tell
the state of their mapping but also their transition.

From Y. Rekhter's review:
This is part of Comment 32

Section 6.5

When a locator record is added to the end of a locator-set, it is
easy to update mappings. We assume new mappings will maintain the
same locator ordering as the old mapping but just have new locators
appended to the end of the list. So some ITRs can have a new mapping
while other ITRs have only an old mapping that is used until they
time out.

This identifies a real problem; i.e., the locator status bits are
contextually dependent on the locator set that was advertised, but
there is no explicit binding between them and the particular locator
set to which they relate. Thus, any version skew between ITR and ETR
will result in misinterpretation of the locator status bits.

This seems like it could be a serious problem (though section 6.3 is
so underspecified and hard to follow that this is difficult to pin
down) and needs to be understood better. The fixes proposed in this
section seem complex and incomplete.

When an ITR has only an old mapping but detects bits set in the
loc-status-bits that correspond to locators beyond the list it has
cached, it simply ignores them. However, this can only happen for
locator addresses that are lexicographically greater than the locator
addresses in the existing locator-set.

It is previously stated that locators in the locator-set must be
sorted; this would seem to indicate that you cannot add a locator to
the locator-set on demand, and that a process such as defined in 6.5.1
must be used to try to ensure sync between ITR and ETR

There would seem to be a need to either get rid of locator-sets, or
come up with a better system for synchronizing them. The consequences
of out-of-sync locator-sets should also be spelled out.

Change History (8)

comment:1 Changed 9 years ago by luigi@…

  • Description modified (diff)
  • Summary changed from Strict RLOC ordering causing problems on mapping changes (from Y. Rekhter's review) to Strict RLOC ordering causing problems on mapping changes

comment:2 Changed 9 years ago by luigi@…

  • Description modified (diff)

comment:3 Changed 8 years ago by luigi@…

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

Authors replied on the mailinglist that in their opinion there is no need to make any change to the draft. Neither the original person that raised the issue nor the mailinglist stated a different opinion.

comment:4 Changed 8 years ago by luigi@…

  • Status changed from resolved to closed

comment:5 Changed 8 years ago by yakov@…

  • Resolution fixed deleted
  • Status changed from closed to reopened

The issues raised in this ticket are still not addressed. Therefore the ticket should stay open.

comment:6 Changed 8 years ago by yakov@…

From the response to my comment:

Thank you for your contribution to draft-ietf-lisp-06.txt. The draft authors
have reviewed your comments but do not feel that changes to the document are
warranted at this time. We think that the use of version numbers will help
this. Its also important to note that LSBs are a hint and a request/reply
exchange will confirm from the R-bits of the locators in the locator-set which
are reachable or not.

To close the ticket the draft authors should describe how the use of version number will address the issues raised in the ticket. Likewise, the authors should point to the specific text in the draft that makes it clear that "LSBs are a hint" and thus are are not sufficient to determine locator's reachability - a request/reply exchange will be required.

comment:7 Changed 8 years ago by luigi@…

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

The issue has been fixed with the text describing the case of new RLOC inserted in the middle of the RLOC set lexicographically ordered.

comment:8 Changed 8 years ago by luigi@…

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