> So, that would mean in the case > where the Map-Request contains 10.0.0.1, the MS would have to reply > with: > > 10/16 -> ETR1 > 10.0.2/24 -> ETR3 // New
10.0.0.1 is not more specific than 10.0.2.0/24 because 10.0.0.1 & 0xffffff00 = 10.0.0.0 which is not equal to 10.0.2.0 & 0xffffff00 = 10.0.2.0. So a lookup for 10.0.2.2 would return only the ETR3 entry. And if 10.0.0.1 was looked up later than the /16 would be returned. But when 10.0.0.1 is looked up first, than all more specifics of the matching entry, the /16, must be returned. Because you don’t want the cache to match a coarse entry in the cache when there is a more specific in the mapping system. > The first of these is necessary to provide correct routing information > for the requested prefix and the second to avoid providing incorrect > routing information for 10.0.2.1. Right. > Do I have this correct? It seems like the alternative is that the MS > or ETR synthesize a new, more specific prefix. Is that what's intended > instead? The example in S 5.5 suggests otehrwise, but perhaps I am > misunderstanding. Well it could return a prefix 10.0.0.1/32 with an RLOC of ETR1 so the entires stored in the cache are the ones actually used. But that would cause not Map-Request load and more entires in the cache. So one trades off up front all registered entries in the cache versus all possible destination EIDs that matches the coarsest prefix. Dino _______________________________________________ lisp mailing list [email protected] https://www.ietf.org/mailman/listinfo/lisp
