RE: [lisp] Last Call: (LISP EID Block) to Informational RFC
> On 15 Nov. 2012, at 10:43 , Sander Steffann wrote: > > > Hi, > > > >> I have to ask, who can request an netblock from this address space > >> and from where? > >> I might be blind but I couldn't find it mentioned anywhere. > > > > Good question. Will there be a central registry, or will parts of the space > > be > delegated to i.e. LISP based ISPs? > > > > Hi Sander, > > no central registry has been ever discussed, was more about delegated the > space to LISP ISPs. So there will be a pool of addresses that the RIR's can allocate out of for EIDs? If that's the case, what is the additional value to an ISP who would conceivably have to pay the RIR for another block of V6 addresses specifically for use as EIDs, when most likely they are already paying for a block that can be used for either purpose? Paul
RE: [lisp] Last Call: (LISP EID Block) to Informational RFC
> One thing we have to be very careful with here is that EIDs are not directly > allocated/assigned to end sites from this block. That will cause everyone to > independently find (different) PITRs for their space, which will make a mess > of the global IPv6 routing table... > > Thanks, > Sander I don't think that (by definition) there is any way to cleanly aggregate PI space. Legacy advertisements are going to be done by their LISP provider and will have to match the endpoint's PI allocations.
RE: [lisp] Last Call: (LISP EID Block) to Informational RFC
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?
