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