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