[lisp] looking for clarifications on rfc 6830

[Richard Li <[e-mail]>]

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