Re: [lisp] WG Last Call draft-ietf-lisp-impact-02

[Luigi Iannone <[e-mail]>]

Hi Ross,

Comments inline.

ciao

L.



> On 01 Jun 2015, at 17:35, Ross Callon <[e-mail]> 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:[e-mail]] 
> 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 <[e-mail] <mailto:[e-mail]>> 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:[e-mail] <mailto:[e-mail]>] 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 <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
>