ietf
[Top] [All Lists]

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

2012-11-16 10:49:21
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?    


<Prev in Thread] Current Thread [Next in Thread>