Subject: [lisp] Issue Title (number): LSB handling details (66)

From: Darrel Lewis <[email-masked]>
Date: Tue, 20 Jul 2010 14:09:38 -0700

Issue Title (number): LSB handling details (66)
Draft Section: 6.5
Issue Description: LSB handling and encoding  
Comments:

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. 

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. 

Response:

Dear Yakov-

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.  Please feel free to continue discussion of your issue 
on the LISP working group mailing list, [email-masked]. Should discussion 
result in WG consensus that changes are required, the authors will 
incorporate appropriate text into a future version of the draft.

	Thanks!
	Darrel, for the LISP document authors

---

From: Damien Saucez <[email-masked]>
Date: Wed, 28 Jul 2010 14:46:13 +0200

Hello,
On 20 Jul 2010, at 23:09, Darrel Lewis wrote:

> are reachable or not.  

We could imagine to impose the V bit + L bit  combination. So everytime the
L bit is set, it is combined with a version number. The version number is 
incremented every time LSB changes. In this case, if we have out-of-order 
packets, the ETR can ignore the LSB bits in the packets with lower  version 
numbers. Because it is re-ordering, it is not supposed to have the old version
for more than few seconds (the lifetime packets in the network). If someone do
not want to use the version increment, it can set the special 0-version which
would mean, use the LSB as today (not combined with version).

The problem is to know what an xTR has to do when it receives a new version.
 Querying the mapping system seem to be irrelevant here has it will not give 
feedback about the actual e2e reachability of RLOCs. On the other hand,
querying an ETR directly seems to be invalid also as maybe the new version
is related to a change of mapping and thus maybe the ETR is not an ETR
anymore!

Thanks,

Damien Saucez

> Please feel free to continue discussion of your issue 
> _______________________________________________
> lisp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lisp