Subject: Re: [lisp] #66: Strict RLOC ordering causing problems on mapping changes

From: "lisp issue tracker" <[email-masked]>
Date: Wed, 16 Mar 2011 09:51:02 -0000

#66: Strict RLOC ordering causing problems on mapping changes

Changes (by luigi@…):

  * status:  new => resolved
  * resolution:  => fixed

Comment:

 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.

-- 
------------------------------------------+---------------------------------
Reporter:  luigi@…                        |        Owner:                 
    Type:  technical                      |       Status:  resolved       
Priority:  major                          |    Component:  draft-ietf-lisp
Severity:  -                              |   Resolution:  fixed          
Keywords:                                 |  
------------------------------------------+---------------------------------

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

---

From: "lisp issue tracker" <[email-masked]>
Date: Wed, 16 Mar 2011 09:59:26 -0000

Changes (by luigi@…):

  * status:  resolved => closed

    Type:  technical                      |       Status:  closed         

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

---

From: "lisp issue tracker" <[email-masked]>
Date: Wed, 16 Mar 2011 19:14:38 -0000

Changes (by yakov@…):

  * status:  closed => reopened
  * resolution:  fixed =>

Comment:

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

-- 
------------------------------------------+---------------------------------
Reporter:  luigi@…                        |        Owner:                 
    Type:  technical                      |       Status:  reopened       
Priority:  major                          |    Component:  draft-ietf-lisp
Severity:  -                              |   Resolution:                 
Keywords:                                 |  
------------------------------------------+---------------------------------

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

---

From: "lisp issue tracker" <[email-masked]>
Date: Thu, 17 Mar 2011 16:14:08 -0000

Comment(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.

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

---

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 18 Mar 2011 14:38:22 -0400

Yakov,
     There is extensive text on the various RLOC maintenance mechanisms, 
including an entire section on how the ITR cleans up its cache.  Are you 
asking for a pointer to the lisp-map-versioning document?

Yours,
Joel

---

From: Yakov Rekhter <[email-masked]>
Date: Tue, 22 Mar 2011 05:53:56 -0700

Joel,

> asking for a pointer to the lisp-map-versioning document?

The problem raised in the ticket has to do with the following. Quoting
from Section 6.6:

   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.  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.

The above covers the case when a new locator record is appended
to the end of the list. The above does *not* cover the case where
(due to the algorithm used for ordering) a new locator record
has to be inserted in the middle of the list. To cover this
new text should be added right after the text I quoted above.

Yakov.

---

From: Luigi Iannone <[email-masked]>
Date: Tue, 22 Mar 2011 14:48:13 +0100

Hi,

I think that the misleading sentence is the first one:

>   easy to update mappings.  

From my understanding, whenever there is a new RLOC, authors suggest to append it to the list of RLOC and set to 1 the corresponding bit of the loc-status-bits. That's all.

I would fix the text in the following way:

	When a locator record is added, 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.  
	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.  

I would drop the last sentence, about lexicographic order, as well. The above text looks sufficient to me.

Luigi

---

From: Yakov Rekhter <[email-masked]>
Date: Tue, 22 Mar 2011 07:03:38 -0700

Luigi,

> From my understanding, whenever there is a new RLOC, authors suggest 
> to append it to the list of RLOC and set to 1 the corresponding bit 
> of the loc-status-bits. That's all.
> 

Please note that in the Map-Reply "The locator-set MUST be sorted
in order of ascending IP address where an IPv4 locator address is
considered numerically 'less than' an IPv6 locator address." (from
section 6.1.5).

Thus the text you proposed above is still insufficient, as it does
not cover the case where a new locator need to be inserted in the
*middle* of the list.

Yakov.

> >>>    have reviewed your comments but do not feel that changes to the docume
n
> > t
> >>>    exchange will confirm from the R-bits of the locators in the locator-s
e
> > t
> >>>  version number will address the issues raised in the ticket. Likewise, t
h
> > e
> >>>  authors should point to the specific text in the draft that makes it cle
a
> > r