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