Re: [lisp] looking for clarifications on rfc 6830

Thanks for your answers.

Speaking about the Best-Match Prefixes, the RFC asks for returning all best-matched prefixes. For the example in the RFC, The prefix 10.1.2.0/24, for example, is NOT a best-match prefix, but the RFC still wants to return it. This is exactly where the confusion comes from.

After reading your explanation, it comes to my mind that it is better off to introduce a concept like "more specific" and "less-specific".

10.1.2.0/24 is "more specific" than 10.1.0.0/16, and 10.0.0.0/8 is "less-specific" than 10.1.0.0/16.

Using "more specific", the RFC could be rephrased as something like this: It will return the best-match prefix and all prefixes that are more specific than the best-match prefix.

For the example in the spec, 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, since 10.1.0.0/16 is the best-match prefix and the other two are more specific than the best-match prefix.

Does the above make sense?

Richard

-----Original Message-----
From: Joel M. Halpern [mailto:jmh@joelhalpern.com] 
Sent: Monday, October 19, 2015 12:02 PM
To: Richard Li; LISP mailing list list
Subject: 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
>