Re: [lisp] looking for clarifications on rfc 6830

Thank you for reading RFC 6830 carefully.
My understanding of the answers to your questions is in line below.
Yours,
Joel

On 10/19/15 2:43 PM, Richard Li wrote:
> Hi Folks,
>
> I have read RFC 6830. I have a few points I could not figure them out by
> myself. Appreciated if you could clarify them.
>
> 1.TTL
>
> Page 20, Section 5.3:
>
> The inner-header 'Time to Live' field (or 'Hop Limit' field, in the case
> of IPv6) SHOULD be copied from the outer-header 'Time to Live' field,
> when the Time to Live value of the outer header is less than the Time to
> Live value of the inner header.
>
> Isn’t it always true that the TTL in outer header is less than or equal
> to TTL in the inner header. Since the ITR copies TTL from the inner
> header to the outer header, the ETR should find that TTL in the outer
> header can’t be bigger than TTL in the inner header.

the reason the comparison condition is needed is that the encapsulation 
condition of copying the TTL is only a SHOULD.  If the ITR did something 
else, for some reason, then the safety condition might not be met a 
priori.  Since the ETR does not know exactly what the ITR did, it needs 
to check.

>
> 2.Fragment size:
>
> Page 21, Section 5.4.1
>
> The size of the encapsulated fragments is then (S/2 + H), which is less
> than the ITR's estimate of the path MTU between the ITR and its
> correspondent ETR.
>
> Is this right?
>
> Look! H is a fixed number (= UDP header length + LISP header length),
> and S is also a fixed size (= L – H, where L is the path MTU).
>
> It looks to me that the fragment size should be less than (S/2+H).
>
> In order to achieve (S/2+H), does the spec actually suggest any padding
> so as to meet (S/2+H)?

There is a bit of sloppy wording.  The S in (S/2 + H) is not the maximum 
S supportable without fragmentation, but the actual size packet received 
from the site.  When we revise this document, we should clean up the 
description to make it more clear.

>
> 3.Best-Match Prefixes
>
> Page 35, Section 6.1.5:
>
> A Map-Request for EID 10.1.5.5 would cause a Map-Reply with a record
> count of 3 to be returned with mapping records for EID-Prefixes
> 10.1.0.0/16, 10.1.1.0/24, and 10.1.2.0/24.
>
> Take a look at the EID prefixes in binary:
>
> 00001010.00000000.00000000.00000000 (10.0.0.0/8)
>
> 00001010.00000001.00000000.00000000 (10.1.0.0/16)
>
> 00001010.00000001.00000001.00000000 (10.1.1.0/24)
>
> 00001010.00000001.00000010.00000000 (10.1.2.0/24)
>
> 00001010.00000001.00000101.00000101 (10.1.5.5/32)
>
> Performing the best match of 10.1.5.5/32 against the EID prefix
> database, we will have only 10.1.0.0/16.

I am not sure what your question is here.  The reason the extra entries 
(beyond 10.1.0.0/16 have to be returned is not that one of them matches 
the request.  Youa re correct, and the text agrees, that there is only 
one entry matching 10.1.5.5/32.  The reason the extra entries need to be 
returned is that in the absence of those entries, later packets which 
match those other entries will be misdirected.
Is the text insufficiently clear about the reason for sending the 
additional entries?
If so, can you suggest text improvement for us to use in the next revision?

>
> Thanks,
>
> Richard
>
>
>
> _______________________________________________
> lisp mailing list
> lisp@ietf.org
> https://www.ietf.org/mailman/listinfo/lisp
>