On Mar 13, 2013, at 10:37 AM, Darrel Lewis <[email protected]> wrote:
> > On Mar 13, 2013, at 7:21 AM, Noel Chiappa wrote: > >> >> This is exactly my impression too, and for that very reason. >> >> Perhaps I'm confused, but it seems to me that pretty much the only thing this >> block buys someone is that one can tell, simply by looking at such IPv6 >> addresses, that they are EIDs - one don't need to do a mapping lookup cycle Well you do if you need to populate your map-cache with RLOCs. As I said, the reason for the /12 is to know who aren't EIDs (with a supported configuration knob) so legacy forwarding in an ITR or PITR does not drop packets while doing a non-fruitful lookup. >> to see if a mapping exists. And maybe there are some other things too (e.g. >> the whole block can be anycast routed to the nearest PITR). This is an added benefit yes. > I don't think you are confused. Noel is definitely not confused. > I think, as long as we support the 'conversion' of existing prefixes to EID > prefixes*, then the complexity in the implementation to support this behavior > must exist, and the corresponding value of having some destinations you don't > have to ask the mapping system about is reduced. Right - the knob allows you to wholesale know if the lookup will provide RLOCs. Dino > > -Darrel > > * and I think supporting this is a MUST > _______________________________________________ > lisp mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/lisp _______________________________________________ lisp mailing list [email protected] https://www.ietf.org/mailman/listinfo/lisp
