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