> Hi Dino, > >> Nothing is coming. Nothing really needs to change. >> >> But if there is anything written up to define allocation procedures, the >> RIRs can review such a document. >> >> The main motivation for this prefix is to optimize ITRs so they know that a >> destination is in a LISP site. This COULD eliminate a mapping database >> lookup for a destination not in this range. Meaning, if a packet is destined >> to a non-EID, you may know this by inspecting the address rather than asking >> the mapping system. > > I don't agree. For example: I'm using regular space for LISP EIDs now, so you > can't assume that if it's not in this block that it's not in the mapping > system...
That is why I capitalized "COULD". >>>> This draft is purely a draft to REQUEST space. There will need to be a >>>> deployment guide on how to allocate EIDs, in general. >>> >>> And if the RIR system is used every RIR will develop its own policy for >>> allocating EIDs independently (hopefully based on the recommendations in >>> such a deployment guide). It will have to be very clear whose >>> responsibility it is to allocate from this space, and when assigning >>> responsibility it might be a good idea to make sure they accept that >>> responsibility too. >> >> Right. >> >>> Note that I am not opposing the idea. I'm just trying to make sure this >>> address space doesn't disappear into a black hole because nobody takes the >>> responsibility to manage it. >>> >>> 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, >> >> Why not? > > Because the RIR communities will probably just refuse to allocate from this > space if it means that all those routes end up in the BGP table... They are > already plenty of people that don't like regular PI policies... You have all the PITRs in the world advertise only the one /12 into underlying routing. >>> which will make a mess of the global IPv6 routing table... >> >> And why do you think you need to assign PITRs per sub-block? > > I hope that is not necessary, but if addresses are assigned to end-sites > directly in a PI-like way then who is going to provide PITR services for the > users? Someone has to pay the bandwidth cost for operating PITR services are provide for non-LISP sources to send to these sites. If you have a well-known defined /12 that all PITRs advertise, then when you allocate sub-blocks, you don't have to change, reconfigure, or touch the 1000s of PITRs deployed. > a PITR... And the users of that space want reliability, so they are not going > to rely on the goodwill of some unknown 3rd parties. There is too much bad > experience with 2002::/16 for that. We do that all the time on the Internet unless you sent this email on a source-route to me. ;-) > If you see another way that I am missing please let me know! I want this to > work, I just don't see how... > - Sander Dino _______________________________________________ lisp mailing list [email protected] https://www.ietf.org/mailman/listinfo/lisp
