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

From: Ross Callon <[email-masked]>
Date: Mon, 1 Jun 2015 15:35:34 +0000

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

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

>…
> 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)

Thanks, Ross

From: Luigi Iannone [mailto:[email-masked]]
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-masked]<mailto:[email-masked]>> 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-masked]] 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

---

From: Luigi Iannone <[email-masked]>
Date: Wed, 3 Jun 2015 09:54:52 +0200

Hi Ross,

Comments inline.

ciao

L.

> On 01 Jun 2015, at 17:35, Ross Callon <[email-masked]> wrote:
> 
> >…

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 putting this as a separate item in section 5.2 makes sense.

Agreed

> >             BGP routing infrastructure (current PI addresses only)

Agreed

> On 27 May 2015, at 23:46, Ross Callon <[email-masked] <mailto:[email-masked]>> wrote:
> 
> 
> From: lisp [mailto:[email-masked] <mailto:[email-masked]>] On Behalf Of Luigi Iannone
> 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>]

---

From: Ross Callon <[email-masked]>
Date: Thu, 4 Jun 2015 01:24:56 +0000

>             open questions related to the deployment of such

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

Agreed

Agreed

Thanks, Ross

Hi Ross,

thanks for your review.

ciao

L.

OLD

NEW

Thanks, Ross

Hi All,

Thanks
Luigi & Joel

---

From: Dino Farinacci <[email-masked]>
Date: Wed, 3 Jun 2015 22:26:44 -0700

> On Jun 3, 2015, at 6:24 PM, Ross Callon <[email-masked]> wrote:
> 
>  
> 

I think the text you suggest is fine. But we haven't ever used the term "OAM" before. I would like all the documentation to be consistent so would suggest using "RLOC reach ability mechanisms". 

Dino

---

From: Luigi Iannone <[email-masked]>
Date: Thu, 4 Jun 2015 09:56:51 +0200

> On 04 Jun 2015, at 03:24, Ross Callon <[email-masked]> wrote:
> 

Looks very good to me.

thanks

L.

> On 01 Jun 2015, at 17:35, Ross Callon <[email-masked] <mailto:[email-masked]>> wrote:
>  
> >…
> From: Luigi Iannone [mailto:[email-masked] <mailto:[email-masked]>]

---

From: Luigi Iannone <[email-masked]>
Date: Thu, 4 Jun 2015 10:00:49 +0200

> On 04 Jun 2015, at 07:26, Dino Farinacci <[email-masked]> wrote:
> 
> 
> 
> On Jun 3, 2015, at 6:24 PM, Ross Callon <[email-masked] <mailto:[email-masked]>> wrote:
> 
>>  
>> 
> I think the text you suggest is fine. But we haven't ever used the term "OAM" before. I would like all the documentation to be consistent so would suggest using "RLOC reach ability mechanisms”. 

Hi Dino,

I understand your point, but may be OAM is a more general term that covers the RLOC reachability case.

yet, if it is fine with Ross I guess we can use “RLOC reachability”.

ciao

L.

---

From: Dino Farinacci <[email-masked]>
Date: Thu, 4 Jun 2015 08:02:38 -0700

Parenthesizing "OAM" would be fine with the text I suggest. 

Dino 

> On Jun 4, 2015, at 1:00 AM, Luigi Iannone <[email-masked]> wrote:
> 
>

---

From: Ross Callon <[email-masked]>
Date: Thu, 4 Jun 2015 15:16:00 +0000

The text that we seem to be converging on (“…and requires some new functionality such as OAM enhancements and EID to RLOC mapping”) mentions OAM as an *example* of new functionality, and does not claim to have a complete list of new functionality.

Thus to me “RLOC reachability detection” is also a valid example of a new functionality, and may in fact be a better example of a “new functionality” than “OAM” would be (since all networks have always required some form of “OAM”, but not all networks require some form of “RLOC reachability detection”).

Thus it seems fine to me to replace “OAM” with “RLOC reachability” in the proposed text.

Ross

From: Dino Farinacci [mailto:[email-masked]]
Sent: Thursday, June 04, 2015 11:03 AM
To: Luigi Iannone
Cc: Ross Callon; LISP mailing list list
Subject: Re: [lisp] WG Last Call draft-ietf-lisp-impact-02

Dino

On Jun 4, 2015, at 1:00 AM, Luigi Iannone <[email-masked]<mailto:[email-masked]>> wrote:

On 04 Jun 2015, at 07:26, Dino Farinacci <[email-masked]<mailto:[email-masked]>> wrote:

On Jun 3, 2015, at 6:24 PM, Ross Callon <[email-masked]<mailto:[email-masked]>> wrote:

Hi Dino,

ciao

L.

Dino

---

From: Dino Farinacci <[email-masked]>
Date: Thu, 4 Jun 2015 08:19:50 -0700

> On Jun 4, 2015, at 8:16 AM, Ross Callon <[email-masked]> wrote:
> 

As written it is a noun. I indicated "RLOC reachability mechanisms". 

Dino

---

From: Ross Callon <[email-masked]>
Date: Thu, 4 Jun 2015 15:22:34 +0000

Yup. "RLOC reachability mechanisms" sounds like the right term in this case. 

Thanks, Ross

-----Original Message-----
From: Dino Farinacci [mailto:[email-masked]] 
Sent: Thursday, June 04, 2015 11:20 AM
To: Ross Callon
Cc: Luigi Iannone; LISP mailing list list
Subject: Re: [lisp] WG Last Call draft-ietf-lisp-impact-02

Dino

---

From: Luigi Iannone <[email-masked]>
Date: Thu, 4 Jun 2015 17:40:41 +0200

Excellent.

We will use “RLOC reachability mechanisms”

Thanks.

ciao

L.

> On 04 Jun 2015, at 17:22, Ross Callon <[email-masked]> wrote:
>