Hi Ross,

Comments inline.

ciao

L.



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

Reply via email to