Subject: Re: [lisp] draft-lewis-lisp-gpe-02.txt

From: Marc Binderberger <[email-masked]>
Date: Mon, 7 Jul 2014 17:27:27 -0700

Hello Darrel et al.,

few questions/comments on your updated draft:

1) not sure Figure 2 and 3 do make much sense as for P=1 the LISP header 
layout is figure 4. Yes it is a very didactic approach ;-) but at the end the 
OAM and version bits are there is any case with P=1 - or not?

2) the layout does not fit well with draft-farinacci-lisp-crypto-00. Are 
there any plans to solve this?  Should this at least be mentioned somewhere?

3) probably too trivial but section "3.3. Version Bits" is not mentioning 
anything about the receiver behaviour. Sure, if you don't know the version, 
drop it. Or at least I assume this is what you have in mind (?).

4) section "4.1. LISP-gpe Routers to (legacy) LISP Routers" you say

   When the P bit is set, the N, E, and V bits MUST be set to zero.  The
   receiving (legacy) LISP router will ignore N, E and V bits, when the
   P bit is set.

I would think a receiving legacy LISP router has no idea about the P bit, 
which is why you explicitly set N/E/V to zero?

5) as you even mention "Ethernet" (or 802.1Q) in the informative reference 
section, what about a reference to "Network Service Header" ?

So just smaller points I make, overall a very interesting document!

Best regards,
Marc

On Fri, 04 Jul 2014 12:45:06 -0700, [email-masked] wrote:
> 
> A New Internet-Draft is available from the on-line Internet-Drafts 
> directories.
> 
> 
>         Title           : LISP Generic Protocol Extension
>         Authors         : Darrel Lewis
>                           Puneet Agarwal
>                           Larry Kreeger
>                           Fabio Maino
>                           Paul Quinn
>                           Michael Smith
>                           Navindra Yadav
> 	Filename        : draft-lewis-lisp-gpe-02.txt
> 	Pages           : 15
> 	Date            : 2014-07-04
> 
> Abstract:
>    This draft describes extending the Locator/ID Separation Protocol
>    (LISP) [RFC6830], via changes to the LISP header, with three new
>    capabilities: support for multi-protocol encapsulation, operations,
>    administration and management (OAM) signaling, and explicit
>    versioning.
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-lewis-lisp-gpe/
> 
> There's also a htmlized version available at:
> http://tools.ietf.org/html/draft-lewis-lisp-gpe-02
> 
> A diff from the previous version is available at:
> http://www.ietf.org/rfcdiff?url2=draft-lewis-lisp-gpe-02
> 
> 
> 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/
> 
> _______________________________________________
> 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: Fabio Maino <[email-masked]>
Date: Tue, 08 Jul 2014 13:32:41 -0700

> OAM and version bits are there is any case with P=1 - or not?
Right, we are trying to show a feature per each sub section. Maybe we 
should explicitly mark as "0/1" the bits that are not shown in a given 
subsection. We'll work on that.

> there any plans to solve this?  Should this at least be mentioned somewhere?

Both this draft and lisp-crypto are proposals to extend the LISP encap 
with new features. I don't think they need to refer each other at this 
point.

I just note that by adding multiprotocol support, one could add a shim 
header that provides encryption services to the LISP payload.

> drop it. Or at least I assume this is what you have in mind (?).

good point. Will add.

> which is why you explicitly set N/E/V to zero?

Right. Per LISP specification P bit is ignored, and given that NEV are 
set to zero, the next protocol field is ignored too. We'll rephrase the 
sentence to make it more clear.
> section, what about a reference to "Network Service Header" ?
Right. Will add.

Thanks for the review!

Fabio

---

From: Dino Farinacci <[email-masked]>
Date: Tue, 8 Jul 2014 13:39:00 -0700

> Both this draft and lisp-crypto are proposals to extend the LISP encap with new features. I don't think they need to refer each other at this point.
> 
> I just note that by adding multiprotocol support, one could add a shim header that provides encryption services to the LISP payload.

When I selected the location of the K bits, I knew the P-bit was predefined in the gpe draft, so I didn't use that location. There are no flag bits left if GPE and lisp-crypto are accepted as working group items. 

Dino

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 08 Jul 2014 20:04:15 -0400

I am very concerned about the compatibility behavior of this.
If the sender is setting the P bit, and the next header, then he 
presumably thinks that is useful to the receiver.  If the receiver is 
ignoring the P bit, and ignoring the field occupied by the next-header, 
how will the receiver know what the content is?  Are we assuming that 
the sender will magically know what packet type the receiver expects, 
even though the sender is capable of sending several different packet types?

I am also concerned that this is removing several features that the 
working group has, up till now, deemed important.  If this gpe is 
important, then we will have to ensure that we do not count on any of 
those features for reliable operation.  If that is our intent, then the 
document really needs to say so explicitly so that WG adoption actually 
represents agreement to those constraints.

Yours,
Joel

> On 7/7/14, 5:27 PM, Marc Binderberger wrote:
...

---

From: Dino Farinacci <[email-masked]>
Date: Tue, 8 Jul 2014 17:08:25 -0700

> If the sender is setting the P bit, and the next header, then he presumably thinks that is useful to the receiver.  If the receiver is ignoring the P bit, and ignoring the field occupied by the next-header, how will the receiver know what the content is?  Are we assuming that the sender will magically know what packet type the receiver expects, even though the sender is capable of sending several different packet types?

I made this comment to the co-authors of the draft. I suggested the best way to handle this is for an ETR to indicate in its RLOC record it registers to the mapping system, what format it can parse. Again, you know where I'm going with this but don't want to say so. LOL.

> I am also concerned that this is removing several features that the working group has, up till now, deemed important.  If this gpe is important, then we will have to ensure that we do not count on any of those features for reliable operation.  If that is our intent, then the document really needs to say so explicitly so that WG adoption actually represents agreement to those constraints.

Agree.

Dino

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

---

From: Fabio Maino <[email-masked]>
Date: Tue, 08 Jul 2014 17:19:03 -0700

Dino,
I thought that lisp-crypto was overlapping with the use of P bit 
already. My mistake: I see that the picture in the lisp-crypto draft 
mentions indeed the P bit.

I think what GPE is trying to propose, is an extension to the LISP 
protocol that together with crypto would allow LISP to handle a set of 
"features": multiprotocol, services, metadata... IMO, if we have to 
change the data path, we should rather look at a change that enables a 
set of "features" rather than a single one.

Fabio

---

From: Dino Farinacci <[email-masked]>
Date: Tue, 8 Jul 2014 17:23:57 -0700

> Dino,
> I thought that lisp-crypto was overlapping with the use of P bit already. My mistake: I see that the picture in the lisp-crypto draft mentions indeed the P bit.

Not sure why I would want to do that. I would like all designs to play together nicely and not look like they were done in silos.

> I think what GPE is trying to propose, is an extension to the LISP protocol that together with crypto would allow LISP to handle a set of "features": multiprotocol, services, metadata... IMO, if we have to change the data path, we should rather look at a change that enables a set of "features" rather than a single one.

Yes, if they can be added at the same time. But typically has happened and we have seen this with LISP since 2007 that features get added over time in subsequent generation products. And I have been put on record many times for not changing the data plane.

IMO, the P-bit is a change that doesn't really add anything new but does something for another data-plane. That probably does not have a good cost/benefit tradeoff. 

Howver, service chaining is a completely different matter.

Dino

---

From: Fabio Maino <[email-masked]>
Date: Tue, 08 Jul 2014 17:45:41 -0700

On 7/8/14, 5:04 PM, Joel M. Halpern wrote:
> presumably thinks that is useful to the receiver.
No. the draft is just suggesting that a GPE implementation can take 
advantage of how LISP is specified and send a GPE encapsulated packet 
(with an IPvX payload) to a LISP receiver. There are no assumption made 
on the receiver behavior, excpet than it should be a LISP device.

> If the receiver is ignoring the P bit, and ignoring the field occupied 
> by the next-header, how will the receiver know what the content is?  
> Are we assuming that the sender will magically know what packet type 
> the receiver expects, even though the sender is capable of sending 
> several different packet types?

that information could come from the mapping system.

> those features for reliable operation.  If that is our intent, then 
> the document really needs to say so explicitly so that WG adoption 
> actually represents agreement to those constraints.
>

Fair comment, we'll add text trying to capture this.

I personally think that it would be a reasonable trade off to give those 
features up in exchange of adding support for multiprotocol, OAM and 
explicit service  tagging. If the group wishes to do so, I think that 
the flexibility added by GPE would allow to reintroduce some or all of 
those features.

Fabio

---

From: Marc Binderberger <[email-masked]>
Date: Wed, 9 Jul 2014 11:24:20 -0700

Hello Joel,

> I am also concerned that this is removing several features that the working 
> group has, up till now, deemed important.

I'm not sure I understand this comment. You mean the collision with 
draft-farinacci-lisp-crypto-00 ? (and other drafts which I may have missed)

Or do you mean that N/E/V must be zero when P=1 ?  How is this different from 
e.g. N/E must be zero when V=1 ?

Regards, Marc

On Tue, 08 Jul 2014 20:04:15 -0400, Joel M. Halpern wrote:
> If the sender is setting the P bit, and the next header, then he presumably 
> thinks that is useful to the receiver.  If the receiver is ignoring the P 
> bit, and ignoring the field occupied by the next-header, how will the 
> receiver know what the content is?  Are we assuming that the sender will 
> magically know what packet type the receiver expects, even though the 
> sender is capable of sending several different packet types?
> 
> I am also concerned that this is removing several features that the working 
> group has, up till now, deemed important.  If this gpe is important, then 
> we will have to ensure that we do not count on any of those features for 
> reliable operation.  If that is our intent, then the document really needs 
> to say so explicitly so that WG adoption actually represents agreement to 
> those constraints.
> 
> Yours,
> Joel

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 09 Jul 2014 15:35:31 -0400

I am refering to the issue that N/E/V must be zero.
This is different from N/E must be zero when V is one for two reasons.
The important reason, and the only reason that the WG needs to address, 
is that the existing document explains what features are lost when you 
do that.
The other reason is that the N/E/V bits are essentially alternative 
mechanisms for addressing related problems.  The P bit is for a very 
different problem.

I have seen confirmation on the list from the authros taht they are 
happy to put in the explicit text.  After that, I leave it to the rest 
of the WG whether the tradeoff is one they want to make.

Yours,
Joel