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 protected]> 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, [email protected] 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 > [email protected] > https://www.ietf.org/mailman/listinfo/int-area _______________________________________________ Int-area mailing list [email protected] https://www.ietf.org/mailman/listinfo/int-area
