RE: [lisp] Last Call: <draft-ietf-lisp-eid-block-03.txt> (LISP EID Block) to Informational RFC

[Paul Vinciguerra <[e-mail]>]

So, I had originally thought that the reason for this was to change the characteristics of a new flow with a cache-hit from the ..!!! that we see to a !!!!!

But even if you know that the destination is an EID, you still need to lookup the RLOCs, so how does this help?  If the destination is a non-LISP endpoint, and there is a cache-miss, isn't the packet forwarded to the destination, hoping that the packet can be delivered unencapsulated because it is not and EID, or that there is a legacy aggregate being announced that knows the destination to deliver the encapsulated packet until the xTR's cache populates? 

Section 3 states:

By defining an IPv6 EID Block [, it] is possible to configure the router so
   to natively forward all packets that have not a destination address
   in the block, without performing any lookup whatsoever.

This reads as if the intent is to set a policy that would only allow LISP encapsulation to IPv6 destinations within this new block and to remove the existing ability to encapsulate to existing v6 EID's in the DDT.  The implication to me is that if I have existing v6 space, I must provide legacy transit through my own PxTR's, almost as a second class citizen as I will be assured a suboptimal path.

Do I have this wrong?