On Wed, Feb 6, 2019 at 7:06 PM Dino Farinacci <farina...@gmail.com> wrote:
> > 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. > Sorry, I think you lost me here. How does the MS know that the ITR already has the ETR3 entry? I would expect that if you had the sequence of queries: 10.0.2.2/32 and 10.0.0.1/32, you would get (10.0.2/24) and then (10/16 and 10.0.2/24). Am I confuges? > 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. > Thanks. > 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. > Sorry, I think you lost me here. Are you saying that the MS can *either* return both the 10/16 and 10.0.2/24 prefixes *or* 10.0.0.1/32 at its discretion? Thanks, -Ekr > 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 lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp
