> 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 RFC still wants to return > it. This is exactly where the confusion comes from. The RFC really implies a longest-match is looked up, but more than the longest match is returned. > 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. 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. > 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. 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. ;-) > > Does the above make sense? > > Richard > > > -----Original Message----- > From: Joel M. Halpern [mailto:[email protected]] > 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 >> [email protected] >> https://www.ietf.org/mailman/listinfo/lisp >> > > _______________________________________________ > lisp mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/lisp
_______________________________________________ lisp mailing list [email protected] https://www.ietf.org/mailman/listinfo/lisp
