Subject: [lisp] #66: Strict RLOC ordering causing problems on mapping changes (from Y. Rekhter's review)

From: "lisp issue tracker" <[email-masked]>
Date: Wed, 21 Apr 2010 11:59:30 -0000

#66: Strict RLOC ordering causing problems on mapping changes (from Y. Rekhter's
review)
------------------------------------------+---------------------------------
Reporter:  luigi@…                        |       Owner:                 
    Type:  technical                      |      Status:  new            
Priority:  major                          |   Component:  draft-ietf-lisp
Severity:  -                              |    Keywords:                 
------------------------------------------+---------------------------------
 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.

-- 
Ticket URL: <http://zinfandel.levkowetz.com/wg/lisp/trac/ticket/66>
lisp <http://tools.ietf.org/lisp/>
LISP WG document issues

---

From: "lisp issue tracker" <[email-masked]>
Date: Wed, 21 Apr 2010 12:52:36 -0000

#66: Strict RLOC ordering causing problems on mapping changes
------------------------------------------+---------------------------------
Reporter:  luigi@…                        |       Owner:                 
    Type:  technical                      |      Status:  new            
Priority:  major                          |   Component:  draft-ietf-lisp
Severity:  -                              |    Keywords:                 
------------------------------------------+---------------------------------
Description changed by luigi@…:

> of out-of-sync locator-sets should also be spelled out.

New description:

 '''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:'''

 Section 6.5

--

-- 
Ticket URL: <http://trac.tools.ietf.org/wg/lisp/trac/ticket/66#comment:1>
lisp <http://tools.ietf.org/lisp/>
LISP WG document issues

---

From: "lisp issue tracker" <[email-masked]>
Date: Thu, 22 Apr 2010 12:20:54 -0000

New description:

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

 Section 6.5

--

-- 
Ticket URL: <http://trac.tools.ietf.org/wg/lisp/trac/ticket/66#comment:2>
lisp <http://tools.ietf.org/lisp/>
LISP WG document issues