> I see your point, what about the following sentence:
>
> LISP comprises both an tunnel-based data plane
> and a distributed control plane for the Internet, hence,
> being more than simple encapsulation technology,
> open questions related to the deployment of such
> infrastructure remains.
I think that this makes the right point. I am wondering whether we should
wordsmith this a bit to get the grammar a bit smoother, or if we should let the
RFC editor staff do it. I will try to take a shot at wordsmithing and we can
see how this comes out.
It seems to me that LISP is “an tunnel-based data plane and a distributed
control plane” which requires a number of new functions such as mapping and
OAM. I am wondering about extending this idea in your text to something like:
LISP comprises both an tunnel-based data plane
and a distributed control plane for the Internet, and
requires some new functionality such as OAM enhancements
and EID to RLOC mapping. Being more than simple encapsulation
technology, there are remaining open questions related to the
deployment of LISP in the Internet.
Does this sound about right?
Thanks, Ross
From: Luigi Iannone [mailto:[email protected]]
Sent: Wednesday, June 03, 2015 3:55 AM
To: Ross Callon
Cc: LISP mailing list list
Subject: Re: [lisp] WG Last Call draft-ietf-lisp-impact-02
Hi Ross,
Comments inline.
ciao
L.
On 01 Jun 2015, at 17:35, Ross Callon
<[email protected]<mailto:[email protected]>> wrote:
>…
> There still are many, economical and technical, open questions related to
> the deployment of such infrastructure.
>
> The purpose of the draft is to document what we know about the impact on the
> existing Internet.
> The right thing to do is to delete at once that sentence, because it does not
> document any impact.
I think that this sentence is a good summary of the overall document, and thus
I think that it is valuable to leave it in. As a summary, I could see it making
sense towards the end of the document, although there doesn’t seem to be
anywhere towards the end to put it.
Thinking about this a bit more: What is essentially being proposed with LISP is
a new addressing and routing paradigm for the core of the Internet, and the
Internet is rapidly becoming pretty much the control plane for the world. As
such, if there are potentially issues then I think that we have a
responsibility to say so. In this case it is pretty clear reading through this
document, or just thinking through the issues and reading the full set of LISP
documents, that there are both economic and technical “open questions related
to the deployment of such infrastructure” and as such I think that we need to
explicitly say this.
I see your point, what about the following sentence:
LISP comprises both an tunnel-based data plane
and a distributed control plane for the Internet, hence,
being more than simple encapsulation technology,
open questions related to the deployment of such
infrastructure remains.
>…
> The overhead related to OAM traffic (for example, for liveness detection)
> is not known.
>
> Rather it would go in section 5.2 as a separate item.
I think that putting this as a separate item in section 5.2 makes sense.
Agreed
>…
> NEW
> The above assumptions are in line with [RFC7215] and current LISP
> deployments, however, such situation may change in the long term.
> For example, the first bullet above assumes that only edge networks
> already owning their address space (current PI address owners) will
> switch to LISP. Speculating whether and how PA owning edge networks
> might switch to LISP was outside the scope. Nevertheless, [KIF13] and
> [CDLC] explore different EDI prefix space
> sizes, still showing results that are consistent and equivalent to the
> above assumptions.
>
> What if instead it is explicated in the first bullet:
>
> EID-to-RLOC mappings follow the same prefix size as the current
> BGP routing infrastructure (using a PI model);
I think that the point here is not just that it is following the PI model, but
that it is assuming a scale that only the current PI’s are going to use LISP
(and therefore be in the mapping table). How about:
> EID-to-RLOC mappings follow the same prefix size as the current
> BGP routing infrastructure (current PI addresses only)
Agreed
Thanks, Ross
From: Luigi Iannone [mailto:[email protected]]
Sent: Friday, May 29, 2015 8:34 AM
To: Ross Callon
Cc: LISP mailing list list
Subject: re: [lisp] WG Last Call draft-ietf-lisp-impact-02
Hi Ross,
thanks for your review.
I think that your comments can be easily accommodate.
Have a look inline.
ciao
L.
On 27 May 2015, at 23:46, Ross Callon
<[email protected]<mailto:[email protected]>> wrote:
The document seems much improved. I still have three issues which should be
corrected before the document is ready for publication.
Section 1, last paragraph, second sentence. This currently reads:
There still are many, economical rather than technical, open questions
related to
the deployment of such infrastructure.
However, it is clear that there are both economical and technical issues. As
examples of technical issues, later in the document (section 5.2) talks about
the difficulty in troubleshooting, and states “…the major issue that years of
LISP experimentation have shown is the difficulty of troubleshooting. When
there is a problem in the network, it is hard to pin-point the reason as the
operator only has a partial view of the network”. This is of course one example
of a technical issue (another related one is my next comment below). Thus I
think that it would be correct to change this sentence to state:
There still are many, economical and technical, open questions related to
the deployment of such infrastructure.
The purpose of the draft is to document what we know about the impact on the
existing Internet.
The right thing to do is to delete at once that sentence, because it does not
document any impact.
This might have been lost in the vigorous discussion of other issues which
occurred during the first WGLC, however, my comments from the previous WGLC
included one point which has not been addressed. This comment was:
> Finally, perhaps I missed it but I didn’t see any discussion of the
> volume of overhead related to OAM traffic used for liveness detection
> (the need for ITR’s to determine the reachability of ETR’s).
I still think that we need discussion of the overhead related to OAM traffic.
If this is not known, it might be appropriate simply to add to the second
paragraph of section 1 something along the lines of:
The overhead related to OAM traffic (for example, for liveness detection)
is not known.
Rather it would go in section 5.2 as a separate item.
Also, in section 3, first bullet after the first paragraph, the document
currently states:
o EID-to-RLOC mappings follow the same prefix size as the current
BGP routing infrastructure;
In email in our earlier discussion Florin Coras stated:
> The goal our experiments was to understand the
> performance of LISP map-caches if edge
> networks already owning their address space (PI address owners) were to
> switch to LISP. Speculating if and how PA owning edge networks are to
> switch to LISP was outside the scope.
I think that these two points are saying the same thing. However, I am not sure
whether most (or all) readers will understand that the bullet point in the
current document implies the point that Florin made in his email. We could
clarify this in the next paragraph as follows:
OLD
The above assumptions are inline with [RFC7215] and current LISP
deployments, however, such situation may change in the long term.
Nevertheless, [KIF13] and [CDLC] explore different EDI prefix space
sizes, still showing results that are consitent and equivalent to the
above assumptions.
NEW
The above assumptions are in line with [RFC7215] and current LISP
deployments, however, such situation may change in the long term.
For example, the first bullet above assumes that only edge networks
already owning their address space (current PI address owners) will
switch to LISP. Speculating whether and how PA owning edge networks
might switch to LISP was outside the scope. Nevertheless, [KIF13] and
[CDLC] explore different EDI prefix space
sizes, still showing results that are consistent and equivalent to the
above assumptions.
What if instead it is explicated in the first bullet:
EID-to-RLOC mappings follow the same prefix size as the current
BGP routing infrastructure (using a PI model);
Thanks, Ross
From: lisp [mailto:[email protected]] On Behalf Of Luigi Iannone
Sent: Thursday, May 14, 2015 3:44 PM
To: LISP mailing list list
Cc: Joel Halpern Direct
Subject: [lisp] WG Last Call draft-ietf-lisp-impact-02
Hi All,
the authors of the LISP Impact document
[https://tools.ietf.org/id/draft-ietf-lisp-impact-02.txt]
submitted a new version of the draft and requested the Work Group Last Call.
This email starts a WG Last Call, to end May 28th, 2015.
Please review this updated WG document and let the WG know if you agree that it
is ready for handing to the AD.
If you have objections, please state your reasons why, and explain what it
would take to address your concerns.
Thanks
Luigi & Joel
_______________________________________________
lisp mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lisp
