Subject: [lisp] I-D Action: draft-ietf-lisp-rfc6830bis-10.txt

From: [email-masked]
Date: Sun, 04 Mar 2018 15:51:04 -0800

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Locator/ID Separation Protocol WG of the IETF.

        Title           : The Locator/ID Separation Protocol (LISP)
        Authors         : Dino Farinacci
                          Vince Fuller
                          Dave Meyer
                          Darrel Lewis
                          Albert Cabellos
	Filename        : draft-ietf-lisp-rfc6830bis-10.txt
	Pages           : 50
	Date            : 2018-03-04

Abstract:
   This document describes the data-plane protocol for the Locator/ID
   Separation Protocol (LISP).  LISP defines two namespaces, End-point
   Identifiers (EIDs) that identify end-hosts and Routing Locators
   (RLOCs) that identify network attachment points.  With this, LISP
   effectively separates control from data, and allows routers to create
   overlay networks.  LISP-capable routers exchange encapsulated packets
   according to EID-to-RLOC mappings stored in a local map-cache.

   LISP requires no change to either host protocol stacks or to underlay
   routers and offers Traffic Engineering, multihoming and mobility,
   among other features.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-lisp-rfc6830bis/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-lisp-rfc6830bis-10
https://datatracker.ietf.org/doc/html/draft-ietf-lisp-rfc6830bis-10

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-lisp-rfc6830bis-10

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Luigi Iannone <[email-masked]>
Date: Mon, 5 Mar 2018 10:44:21 +0100

Hi Albert, Dino,

this version of the document doesn’t not yet completely respect the discussions of the last months. 

Do you plan another version before London?

Thanks

Luigi

> On 5 Mar 2018, at 00:51, [email-masked] wrote:
> 
> 
> _______________________________________________
> I-D-Announce mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

---

From: Albert Cabellos <[email-masked]>
Date: Mon, 5 Mar 2018 14:09:07 +0100

Hi all

This document should address all the comments except this one:

G.- Move sections 16 (Mobility Considerations), 17 (xTR Placement
Considerations), 18 (Traceroute Consideration) to a new OAM document

The authors would like to have a better understanding of where this text
will go.

If we adress this by today I can submit a new version (before the cut-off)
taking this comment into account.

Thanks!

Albert

On Mon, Mar 5, 2018 at 10:44 AM, Luigi Iannone <[email-masked]> wrote:

> lisp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lisp
>

---

From: Dino Farinacci <[email-masked]>
Date: Mon, 5 Mar 2018 10:06:43 -0800

> G.- Move sections 16 (Mobility Considerations), 17 (xTR Placement Considerations), 18 (Traceroute Consideration) to a new OAM document
> 
> The authors would like to have a better understanding of where this text will go.

Right, we concluded to not remove the valuable text. A lot of time and thought went into writing it and we didn’t want to lose it. There was no where that was agreed upon to put it.

So since we felt there was no concensus on Sections 16-18, we didn’t make any change.

Dino

> 
> If we adress this by today I can submit a new version (before the cut-off) taking this comment into account.
> 
> Thanks!
> 
> Albert
>

---

From: Luigi Iannone <[email-masked]>
Date: Mon, 5 Mar 2018 20:54:07 +0100

> On 5 Mar 2018, at 19:06, Dino Farinacci <[email-masked]> wrote:
> 
>> Hi all
>> 
> Right, we concluded to not remove the valuable text.

Nobody wants to lose valuable text.

> A lot of time and thought went into writing it and we didn’t want to lose it. There was no where that was agreed upon to put it.

That is not accurate. There was clear indication to move it to a new OAM document, without any change in the text.
Purpose was to have just a different placeholder that make more sense.
This is an half an hour task. 

> So since we felt there was no concensus on Sections 16-18, we didn’t make any change.

Again not accurate, please spend half an hour to create the OAM document.
If you do not have time we can appoint other editors for the task. Authorship will be anyway preserved.

Thanks

Luigi

---

From: Dino Farinacci <[email-masked]>
Date: Mon, 5 Mar 2018 12:35:00 -0800

> Nobody wants to lose valuable text.

Glad you feel that way.

> This is an half an hour task. 

But there was also concerns about slowing the process down. And the co-authors (Albert and I) don’t think it should move from RFC6833.

So there isn’t concensus. And I don’t believe it is even rough concensus.

> If you do not have time we can appoint other editors for the task. Authorship will be anyway preserved.

Section 16 is “Mobility Considerations” that discusses various forms of how EIDs can change RLOCs. And it sets up for different designs that are already documented in various documents. But Mobility certainly shouldn’t go in an OAM document. 

Section 17 discusses where xTRs (data-plane boxes) should reside in the network. And sets up for a more detail discussion which is in the Deployment RFC.

Section 18 is “Traceroute Considerations”, this arguably can go into an OAM document. But it would be 3 pages. And then one would argue there are other OAM mechanisms spread across LISP documents that could go in an OAM document.

This will not take 1/2 hour.

And I’m finding it hard to see the value in doing all this busy work. We have already accomplished separating data-plane text from control-plane text. We achieved that goal from the charter.

Dino

---

From: Albert Cabellos <[email-masked]>
Date: Mon, 5 Mar 2018 22:33:57 +0100

Hi

I'll post a new version without such sections shortly.

I volunteer to help writing the OAM document.

Albert

On Mon, Mar 5, 2018 at 9:35 PM, Dino Farinacci <[email-masked]> wrote:

> >> A lot of time and thought went into writing it and we didn’t want to
> lose it. There was no where that was agreed upon to put it.
> >
> > That is not accurate. There was clear indication to move it to a new OAM
> document, without any change in the text.
> But there was also concerns about slowing the process down. And the
> co-authors (Albert and I) don’t think it should move from RFC6833.
>
> Section 16 is “Mobility Considerations” that discusses various forms of
> how EIDs can change RLOCs. And it sets up for different designs that are
> already documented in various documents. But Mobility certainly shouldn’t
> go in an OAM document.
>
> Section 17 discusses where xTRs (data-plane boxes) should reside in the
> network. And sets up for a more detail discussion which is in the
> Deployment RFC.
>
> Section 18 is “Traceroute Considerations”, this arguably can go into an
> OAM document. But it would be 3 pages. And then one would argue there are
> other OAM mechanisms spread across LISP documents that could go in an OAM
> document.
>
> And I’m finding it hard to see the value in doing all this busy work. We
> have already accomplished separating data-plane text from control-plane
> text. We achieved that goal from the charter.
>
> Dino
>
>

---

From: Luigi Iannone <[email-masked]>
Date: Tue, 6 Mar 2018 10:29:24 +0100

Hi Albert,

thanks for submitting the updated document.

I have have a few residual nits listed below. Fixed those we can move to LC IMO.

Ciao

L.

> 
>    LISP Nonce:  The LISP 'Nonce' field is a 24-bit value that is
>       randomly generated by an ITR when the N-bit is set to 1.  Nonce
>       generation algorithms are an implementation matter but are
>       required to generate different nonces when sending to different
>       destinations.  
[Luigi]
As stated for -07: What is a destination? Should be different RLOCs, for clarity.

The Clock Sweep mechanism is just about management should go in AOM.

The following document are not Normative:

 [RFC4086 <>]  Eastlake 3rd, D., Schiller, J., and S. Crocker,
              "Randomness Requirements for Security", BCP 106 <https://tools.ietf.org/html/bcp106>, RFC 4086 <https://tools.ietf.org/html/rfc4086>,
              DOI 10.17487/RFC4086, June 2005,
              <https://www.rfc-editor.org/info/rfc4086 <https://www.rfc-editor.org/info/rfc4086>>.

[RFC6275 <>]  Perkins, C., Ed., Johnson, D., and J. Arkko, "Mobility
              Support in IPv6", RFC 6275 <https://tools.ietf.org/html/rfc6275>, DOI 10.17487/RFC6275, July
              2011, <https://www.rfc-editor.org/info/rfc6275 <https://www.rfc-editor.org/info/rfc6275>>.

> On 5 Mar 2018, at 22:33, Albert Cabellos <[email-masked]> wrote:
> 
> Hi 
> 
> On Mon, Mar 5, 2018 at 9:35 PM, Dino Farinacci <[email-masked] <mailto:[email-masked]>> wrote:
> >> On 5 Mar 2018, at 19:06, Dino Farinacci <[email-masked] <mailto:[email-masked]>> wrote:
> >>
> >>> Hi all
> >>>

---

From: Albert Cabellos <[email-masked]>
Date: Mon, 19 Mar 2018 11:06:06 +0000

Hi all

I just posted -12 with the changes suggested by Luigi

Albert

On Tue, Mar 6, 2018 at 9:29 AM, Luigi Iannone <[email-masked]> wrote:

>  [RFC4086]  Eastlake 3rd, D., Schiller, J., and S. Crocker,
>               <https://www.rfc-editor.org/info/rfc4086>.
>
>
> [RFC6275]  Perkins, C., Ed., Johnson, D., and J. Arkko, "Mobility
>               2011, <https://www.rfc-editor.org/info/rfc6275>.
>
>
>
>
>
>
>> > That is not accurate. There was clear indication to move it to a new
>> OAM document, without any change in the text.