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

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 <ietf@bobbriscoe.net> wrote:
> 
> 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, internet-drafts@ietf.org 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/
> 
> _______________________________________________
> Int-area mailing list
> Int-area@ietf.org
> https://www.ietf.org/mailman/listinfo/int-area