Eric, just want to be clear on this one point. See below. > > S 5.5. > > > is being mapped from a multicast destination EID. > > > > > > 5.5. EID-to-RLOC UDP Map-Reply Message > > > > > > A Map-Reply returns an EID-Prefix with a prefix length that is less > > > than or equal to the EID being requested. The EID being requested is > > > > How do I behave if I receive an EID-Prefix that is less than any of my > > mappings. So, I might have mappings for 10.1.0.0/16 and 10.2.0.0/16 > > and someone asks me for 10.0.0.0/8? Also, when you talk about prefix > > length, I assume you mean the length fo the mask? > > We had an extended back and forth on this. I still don't find the document > very clear, and I'm not sure that this text is correct. Specifically, > consider the following example, where the MS has two mappings: > > 10/8 -> ETR1 > 10.0.1/24 -> ETR2 > > The Map-Request is for 10.1/16. In email, we agreed that you cannot return > only the first mapping because that would implicitly over-claim. This means > that you either supset one of your mappings or return both (I understood > Dino to be saying you return both). However, the 10.0.1/24 mapping has > a longer prefix than the requested one, so that would seem to violate this > text.
With the above entries in the mapping system, a Map-Request fro 10.1.0.0/16 gets returned the 10.0.0.0/8 entry. (1) A Map-Request for 10.0.1.1/32 returns only 10.0.1.0/24. (2) A Map-Request for 10.2.2.2/32 returns both 10.0.0.0/8 and 10.0.1.0/24 (even though 10.2.2.2 is not more specific than 10.0.1.0/24). (3) A Map-Request for 10.0.0.0/<8 (less than 8) returns an empty RLOC-set. As I mentioned last night if a Map-Request matches an entry in the mapping system and the mapping system has more specifics for that matched prefix, then all more specifics are returned. The reason is for when 10.0.1.1/32 is looked up in the ITR/RTR map-cache the /24 ETR2 is used. The mapping system does not know what the ITR has cached so it must return all more specifics. I hope this clears things up. Dino _______________________________________________ lisp mailing list [email protected] https://www.ietf.org/mailman/listinfo/lisp
