Re: [lisp] 6830bis Review

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.)

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
>>> lisp@ietf.org
>>> https://www.ietf.org/mailman/listinfo/lisp
> 
> 