Subject: [lisp] looking for clarifications on rfc 6830

From: Richard Li <[email-masked]>
Date: Mon, 19 Oct 2015 18:43:49 +0000

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.

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)?

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.

Thanks,

Richard

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 19 Oct 2015 15:02:13 -0400

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

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

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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lisp
>

---

From: Dino Farinacci <[email-masked]>
Date: Mon, 19 Oct 2015 13:37:54 -0700

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

Please let me clarify. “L” is the largest packet an ITR can send so there is no fragmentation. So it is made up size H, the size of the headers the ITR will prepend, and S, the size of the packet that is offered by the source. S is the maximum that the source can send so that when H is added we can get L.

This is all stated in the 1-3 bullets.

The S/2 + H is the intentional size. We were not trying to get the maximum size packets for fragmentation because the intermediate routers could add headers (if there was more tunneling going on). So we give the intermediate routers S/2 room.

Dino

---

From: Richard Li <[email-masked]>
Date: Wed, 21 Oct 2015 22:16:18 +0000

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:[email-masked]] 
Sent: Monday, October 19, 2015 12:02 PM
To: Richard Li; LISP mailing list list
Subject: Re: [lisp] looking for clarifications on rfc 6830

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?
>
> and S is also a fixed size (= L - H, where L is the path MTU).
>

> Take a look at the EID prefixes in binary:

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?

---

From: Dino Farinacci <[email-masked]>
Date: Wed, 21 Oct 2015 15:39:11 -0700

> Thanks for your answers.

Let me respond to your comment. See questions inline and thanks for your detailed review.

> 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 RF…

The RFC really implies a longest-match is looked up, but more than the longest match is returned.

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

Yes, that is how one would do a map-cache lookup for a local cache. For entries in the mapping database the overlapping prefixes can be registered from multiple places.

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

So let me explain the example in the spec:

The longest match lookup for 10.1.1.1 can only be 10.1.1.0/24. If any other lookup was required for 10.*.*.*, it would not match the 10.1.1.0/24 entry. For example, a lookup for 10.1.7.7 would return 10.1.0.0/16 and a lookup for 10.7.7.7 would return 10.0.0.0/8. This is all traditional longest-match lookup rules.

Now for 10.1.5.5, in the second example. The longest match for 10.1.5.5 is 10.1.0.0/16. If that was the only entry returned, then a lookup for 10.1.1.1 would not occur because the ITR had a map-cache entry for 10.1.0.0/16. And, then of course, the packet would go to the wrong RLOCs (the ones for 10.1.0.0/16 and not for 10.1.1.0/24. 

So the *additional* entries returned are entries that are more specific for 10.1.0.0/16. So that all of 10.1.0.0/16, 10.1.1.0/24, and 10.1.2.0/24 are cached so when a packet is received by the ITR for destination 10.1.1.1, the 10.1.1.0/24 entry is used.

And if later, a packet was received by the ITR for destination 10.7.7.7, none of those entries returned for the 10.1.5.5 lookup would match, so the 10.0.0.0/8 entry would be returned.

Does that make it more clear?

Dino

P.S. Coarseness is good for scale but not for correctness.  ;-)

---

From: Joel Halpern Direct <[email-masked]>
Date: Wed, 21 Oct 2015 18:40:51 -0400

Looking at the text, there are two different references.  The first part
talks about "a Map-Request with n EID that best matches any EID-prefix
MUST be returned."
This is correct.  The Map-Reply must include the EID-prefix which
best-matches the EID from the request.
The grammar is a bit awkward in trying to say that if any other prefixes
need to be returned along with that, they need to go in the same
Map-Reply message.  But the text is not incorrect.

And the later text makes it clear that the prefixes that must be
included are the more-specific prefixes within the best-match. The 
current structure is important in part because conceptually there may be 
other reasons why a set of prefixes need to be sent.

Still, I would ask that you help us keep track of the fact that thsi 
third paragraph of 5.3 could be worded better.

Yours,
Joel

On 10/21/15 6:16 PM, Richard Li wrote:
> 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".
>
> 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.
>
> -----Original Message----- From: Joel M. Halpern
> [mailto:[email-masked]] 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
>
>> I have read RFC 6830. I have a few points I could not figure them
>> out by myself. Appreciated if you could clarify them.
>>
...
>> 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.
>>
> 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
>> [email-masked] https://www.ietf.org/mailman/listinfo/lisp
>>

---

From: Richard Li <[email-masked]>
Date: Wed, 21 Oct 2015 23:06:34 +0000

Yes. Agreed. 

With yours and Dino's explanation, I understand why LISP needs those "more specific" prefixes. The original wording just doesn't seem straightforward enough. 

OK. I'll keep track of them for your future revision.

Thanks,

Richard

-----Original Message-----
From: Joel Halpern Direct [mailto:[email-masked]] 
Sent: Wednesday, October 21, 2015 3:41 PM
To: Richard Li; LISP mailing list list
Subject: Re: [lisp] looking for clarifications on rfc 6830

Looking at the text, there are two different references.  The first part talks about "a Map-Request with n EID that best matches any EID-prefix MUST be returned."
This is correct.  The Map-Reply must include the EID-prefix which best-matches the EID from the request.
The grammar is a bit awkward in trying to say that if any other prefixes need to be returned along with that, they need to go in the same Map-Reply message.  But the text is not incorrect.

And the later text makes it clear that the prefixes that must be included are the more-specific prefixes within the best-match. The current structure is important in part because conceptually there may be other reasons why a set of prefixes need to be sent.

Still, I would ask that you help us keep track of the fact that thsi third paragraph of 5.3 could be worded better.

Yours,
Joel

On 10/21/15 6:16 PM, Richard Li wrote:
> 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 
> 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.
>
> To: Richard Li; LISP mailing list list Subject: Re: [lisp] looking for 
> clarifications on rfc 6830
>
...