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