> I would talk about that purely in terms of RLOCs being dervice from, and > assigned according to, the underlay. It is up to the underlay to set it > policies so that it scales well (or chooses not to care, as some underlays > do.)
I can change “global Internet” to “core” and “provider underlay networks”. What do you think? Dino > > Yours, > Joel > > On 12/27/17 11:44 PM, Dino Farinacci wrote: >>> Actually, I do not see why the LISP spec should talk at all about the >>> scalability of the underlay. The underlay is what it is. We are not >>> claiming to change that. >> But if you assign non PA addresses to RLOCs, the underlay scalability will >> be worse. It’s definitely worth mentioning how EIDs are independent and can >> be opaque where RLOCs need to be topologically aggregatable, or otherise you >> worsen the underlay. >> Dino >>> Working Group: Does anyone else have an opinion either way? This document >>> belongs to the WG, not to the chairs or the editors. >>> >>> Yours, >>> Joel >>> >>> On 12/27/17 11:18 PM, Dino Farinacci wrote: >>>>>> Note, we still care about scalability of any underlay, especially the >>>>>> Internet core, so we should leave this in. Note, we ARE still solving >>>>>> the scalability problem. >>>>>> >>>>>> I don’t know why any of you would think differently. >>>>> >>>>> We are solving this issue and many others. But the point of the document >>>>> is specifying a data-plane, not the benefits of this data-plane. >>>> When you spec a protocol you must say why you are doing it and ususally a >>>> requirements for the solution state that. So benefits is a natural output >>>> of satisfying the requirements. And at the same time we also indicate what >>>> the costs are. >>>>>> I have planned to remove the sentence. >>>>>> >>>>>> What do you think about defining an EID as an identifier of the overlay >>>>>> and an RLOC as an identifier of the underlay? (Probably this needs to be >>>>>> reworded, but you get my point). >>>>>> >>>>>> In my view this definition is broader and accounts for many of the LCAF >>>>>> uses. >>>> We spent two years on the definition of an EID and RLOC. There were so >>>> many people that contributed and discussed it. Why undo that effort. There >>>> is nothing inherently wrong with the definitions. >>>>>> >>>>> I had planned to take Luigi’s suggestion. I did not want to rewrite this >>>>> section. It was carefully written by David Black with consolation from >>>>> the ECN experts. I do not want to lose this technical text. >>>>> >>>>> I still think that Luigi's suggestion clarifies the text and that my edit >>>>> (hopefully) makes it easier for readers to understand. I just moved some >>>>> sentences . >>>> I made some changes but it is never a good idea to repeat the same exact >>>> text. Check the new wording. >>>>>>> Actually we should merge this section with 'Routing Locator Hashing’ >>>>>> >>>>>> I disagree with you guys. Who do you think punts packets when there is a >>>>>> map-cache miss? The data-plane. Note there are many users of the >>>>>> control-plane, an SDN controller, many data-planes, and lig/rig. How >>>>>> they each use the control-plane is documented in their own documents. >>>>>> >>>>>> And please do not suggest that lig/rig usage of the control plane move >>>>>> to 6833bis. >>>>>> >>>>> As an example, if we keep the 'Routing Locator Hashing' text as it is >>>>> then it only works with Map-Reply messages: >>>>> >>>>> "When an ETR provides an EID-to-RLOC mapping in a Map-Reply message that >>>>> is stored in the map-cache of a requesting ITR” >>>>> >>>>> The point is to allow LISP data-plane to work with any control-plane. >>>> No that has never been a requirement. We have stated (in the charter) that >>>> we can use any data-plane “with the LISP control-plane”. We have never >>>> discussed and it was never a requirement to do the converse. >>>> Dino >>>> _______________________________________________ >>>> lisp mailing list >>>> [email protected] >>>> https://www.ietf.org/mailman/listinfo/lisp
_______________________________________________ lisp mailing list [email protected] https://www.ietf.org/mailman/listinfo/lisp
