Subject: [Int-area] New draft to update L2TP, GRE, PPTP, GTP & VXLAN, etc. for ECN

From: Bob Briscoe <[email-masked]>
Date: Fri, 8 Jul 2016 13:18:15 +0100

tsvwg, intarea, and respective co-chairs,
[re-sent with hyphen in int-area@]

I have posted a new very brief draft (under 2 pages not incl. 
boilerplate), intended for standards track as a bis to RFC6040.
As suggested in Buenos Aires, this has been extracted from 
draft-ietf-tsvwg-ecn-encap-guidelines, to cut all the clutter and 
highlight solely the standards track stuff.

Propagating Explicit Congestion Notification Across IP Tunnel Headers 
Separated by a Shim
https://tools.ietf.org/html/draft-briscoe-tsvwg-rfc6040bis-00

If approved, it is intended to update L2TP, GRE, PPTP, GTP & VXLAN.
Obviously the IETF does not control GTP - see text for how 3GPP might 
use this spec.
Simialrly, given VXLAN is informational, it's perhaps not appropriate to 
update it - exactly how this is worded is for discussion.

For IETF-96, I've asked for a slot in intarea to explain, and I also 
hope to cover this in an ecn-encap-guidelines slot in tsvwg.

I'd appreciate help identifying more tunnelling protocols that follow 
the pattern of a shim sandwiched between two IP headers.
Since posting, I've looked at Joe's Tunnelling draft and realised I 
missed out Geneve and GUE. More?

Cheers

Bob

On 08/07/16 12:41, [email-masked] wrote:
> A new version of I-D, draft-briscoe-tsvwg-rfc6040bis-00.txt
> has been successfully submitted by Bob Briscoe and posted to the
> IETF repository.
>
> Name:		draft-briscoe-tsvwg-rfc6040bis
> Revision:	00
> Title:		Propagating Explicit Congestion Notification Across IP Tunnel Headers Separated by a Shim
> Document date:	2016-07-08
> Group:		Individual Submission
> Pages:		5
> URL:            https://www.ietf.org/internet-drafts/draft-briscoe-tsvwg-rfc6040bis-00.txt
> Status:         https://datatracker.ietf.org/doc/draft-briscoe-tsvwg-rfc6040bis/
> Htmlized:       https://tools.ietf.org/html/draft-briscoe-tsvwg-rfc6040bis-00
>
>
> Abstract:
>     RFC 6040 on "Tunnelling of Explicit Congestion Notification" made the
>     rules for propagation of ECN consistent for all forms of IP in IP
>     tunnel.  This specification extends the scope of RFC 6040 to include
>     tunnels where two IP headers are separated by a shim header that
>     cannot stand alone.
>
>
>
>
> 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.
>
> The IETF Secretariat
>

-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Fri, 8 Jul 2016 19:32:48 +0000

Bob,

When you say L2TP, do you mean only L2TPv2 [RFC 2661] as in the I-D, or also L2TPv3 [RFC 3931]? (I think should be both). 

One additional point of clarification — the draft says:

   This specification therefore updates the
   following specifications of tightly coupled shim headers by adding
   that RFC 6040 SHOULD apply when the shim header is used between IP
   headers:

However, some of the listed tunneling technologies include additional encapsulations between the shim and the inner IP. Those are not part of the shim header per se. For example, IP | GRE | Ethernet | IP. Same for VXLAN. There’s PPP for L2TP, etc. The draft scope says:

   In many cases the shim header(s) and the outer IP header are always
   added (or removed) as part of the same process.  We call this a
   tightly coupled shim header.

It might be beneficial to tighten the scope to more definitively spec if it is IP | shim | something | IP, for “something” being non-null.

However, 

Thanks,

— Carlos.

> On Jul 8, 2016, at 8:18 AM, Bob Briscoe <[email-masked]> wrote:
> 
> I have posted a new very brief draft (under 2 pages not incl. boilerplate), intended for standards track as a bis to RFC6040.
> As suggested in Buenos Aires, this has been extracted from draft-ietf-tsvwg-ecn-encap-guidelines, to cut all the clutter and highlight solely the standards track stuff.
> 
> Propagating Explicit Congestion Notification Across IP Tunnel Headers Separated by a Shim
> Obviously the IETF does not control GTP - see text for how 3GPP might use this spec.
> Simialrly, given VXLAN is informational, it's perhaps not appropriate to update it - exactly how this is worded is for discussion.
> 
> For IETF-96, I've asked for a slot in intarea to explain, and I also hope to cover this in an ecn-encap-guidelines slot in tsvwg.
> 
> I'd appreciate help identifying more tunnelling protocols that follow the pattern of a shim sandwiched between two IP headers.
> Since posting, I've looked at Joe's Tunnelling draft and realised I missed out Geneve and GUE. More?
> 
> Cheers
> 
> 
> Bob
> 
> _______________________________________________
> Int-area mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/int-area

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Fri, 8 Jul 2016 19:36:17 +0000

[correcting [email-masked]<mailto:[email-masked]>]

On Jul 8, 2016, at 3:09 PM, Bob Briscoe <[email-masked]<mailto:[email-masked]>> wrote:

David,

On 08/07/16 15:50, Black, David wrote:
VXLAN (RFC 7348) is an independent submission (ISE) RFC - it is not updatable by the IETF.
Yeah, I realised that after I pressed submit (as I said).
I've removed VXLAN from the "Updates" header.
I will just have to treat VXLAN like I've treated GTP - cite it, and say we expect the <other forum> to refer to the present spec.

And VXLAN-GPE <https://tools.ietf.org/html/draft-ietf-nvo3-vxlan-gpe-02>?

Thanks,

— Carlos.

I've updated my local copy, and I've mentioned Geneve and GUE, altho they already correctly refer to RFC6040, so no need to "update" them.
I might post an -01 draft before the deadline tonight. That didn't used to be possible when the deadlines were on different days, but I think it works now.

Bob

Thanks, --David

-----Original Message-----
From: Bob Briscoe [mailto:[email-masked]]
Sent: Friday, July 08, 2016 8:12 AM
To: tsvwg IETF list; [email-masked]<mailto:[email-masked]>; Wassim Haddad; [email-masked]<mailto:[email-masked]>; Gorry
Fairhurst; Black, David
Subject: New draft to update L2TP, GRE, PPTP, GTP & VXLAN, etc. for ECN

Cheers

Bob

On 08/07/16 12:41, [email-masked]<mailto:[email-masked]> wrote:
A new version of I-D, draft-briscoe-tsvwg-rfc6040bis-00.txt
has been successfully submitted by Bob Briscoe and posted to the
IETF repository.

Name: draft-briscoe-tsvwg-rfc6040bis
Revision: 00
Title: Propagating Explicit Congestion Notification Across IP Tunnel
Headers Separated by a Shim
Document date: 2016-07-08
Group: Individual Submission
Pages: 5
URL:            https://www.ietf.org/internet-drafts/draft-briscoe-tsvwg-
rfc6040bis-00.txt
Status:         https://datatracker.ietf.org/doc/draft-briscoe-tsvwg-rfc6040bis/
Htmlized:       https://tools.ietf.org/html/draft-briscoe-tsvwg-rfc6040bis-00

Abstract:

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<http://tools.ietf.org>.

The IETF Secretariat

--
______________________________________________________________
__
Bob Briscoe                               http://bobbriscoe.net/

---

From: Bob Briscoe <[email-masked]>
Date: Fri, 8 Jul 2016 22:41:54 +0100

Carlos,

> When you say L2TP, do you mean only L2TPv2 [RFC 2661] as in the I-D, or also L2TPv3 [RFC 3931]? (I think should be both).
Thx. I've added L2TPv3 to my local copy - might post -01 later tonight. 
I recall adding that to my list in the past, but it must have fallen off 
again.
> It might be beneficial to tighten the scope to more definitively spec if it is IP | shim | something | IP, for “something” being non-null.
Any suggestions for how I can make the scope clearer - I thought I had 
made it clear: it's only if the shim and outer IP are added to an inner 
IP. Because, in the example you give an Ethernet header doesn't have an 
ECN field.

That case falls under the last catch-all paragraph that refers to 
draft-ietf-ecn-encap-guidelines, which attempts to cover every 
possibility in a more general way. In section 4.2 & section 6 you'll 
find that if ECN is in an IP header within an Ethernet header either you 
give up, or if you're a switch-router you violate layering and look 
inside the Ethernet header to find ECN in the IP header. Then, you refer 
to RFC6040 to propagate to/from the outer IP, jumping over the shim.

Bob

---

From: Bob Briscoe <[email-masked]>
Date: Fri, 8 Jul 2016 22:48:42 +0100

Carlos, (adding Lawrence & Uri as editors of VXLAN-GPE),

Thx for pointing this out.

I don't need to update a draft that isn't an RFC yet. The VXLAN-GPE 
draft should just refer to RFC6040 directly, which would correct the 
fact that ECN propagation was omitted from the original VXLAN 
implementation and spec.

Cheers

Bob

On 08/07/16 20:36, Carlos Pignataro (cpignata) wrote:
> [correcting [email-masked] <mailto:[email-masked]>]
>
>> I will just have to treat VXLAN like I've treated GTP - cite it, and 
>> say we expect the <other forum> to refer to the present spec.
>>
>
>> I've updated my local copy, and I've mentioned Geneve and GUE, altho 
>> they already correctly refer to RFC6040, so no need to "update" them.
>> I might post an -01 draft before the deadline tonight. That didn't 
>> used to be possible when the deadlines were on different days, but I 
>> think it works now.
>>
>>
>> Bob
>>>
>>> Thanks, --David
>>>
>>>> To: tsvwg IETF list; [email-masked] <mailto:[email-masked]>; 
>>>> Wassim Haddad; [email-masked] <mailto:[email-masked]>; Gorry
>>>> Fairhurst; Black, David
>>>>> Name:draft-briscoe-tsvwg-rfc6040bis
>>>>> Revision:00
>>>>> Title:Propagating Explicit Congestion Notification Across IP Tunnel
>>>>> Document date:2016-07-08
>>>>> Group:Individual Submission
>>>>> Pages:5
>>>>> Status: 
>>>>> https://datatracker.ietf.org/doc/draft-briscoe-tsvwg-rfc6040bis/
>>>>> Htmlized: 
>>>>> until the htmlized version and diff are available at 
>>>>> tools.ietf.org <http://tools.ietf.org>.
>>>>>
>>>>> The IETF Secretariat
>>>>>
>>>> --

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Fri, 8 Jul 2016 22:04:17 +0000

Bob,

On Jul 8, 2016, at 5:41 PM, Bob Briscoe <[email-masked]<mailto:[email-masked]>> wrote:

Carlos,

When you say L2TP, do you mean only L2TPv2 [RFC 2661] as in the I-D, or also L2TPv3 [RFC 3931]? (I think should be both).
Thx. I've added L2TPv3 to my local copy - might post -01 later tonight. I recall adding that to my list in the past, but it must have fallen off again.

It might be beneficial to tighten the scope to more definitively spec if it is IP | shim | something | IP, for “something” being non-null.
Any suggestions for how I can make the scope clearer - I thought I had made it clear: it's only if the shim and outer IP are added to an inner IP. Because, in the example you give an Ethernet header doesn't have an ECN field.

That case falls under the last catch-all paragraph that refers to draft-ietf-ecn-encap-guidelines, which attempts to cover every possibility in a more general way. In section 4.2 & section 6 you'll find that if ECN is in an IP header within an Ethernet header either you give up, or if you're a switch-router you violate layering and look inside the Ethernet header to find ECN in the IP header. Then, you refer to RFC6040 to propagate to/from the outer IP, jumping over the shim.

Thanks. Indeed, the paragraphs in ietf-tsvwg-ecn-encap-guidelines cover my question.

Thanks,

— Carlos.

Bob

However,

Thanks,

— Carlos.

On Jul 8, 2016, at 8:18 AM, Bob Briscoe <[email-masked]<mailto:[email-masked]>> wrote:

Cheers

Bob

Abstract:

The IETF Secretariat