Carlos,
On 08/07/16 20:32, Carlos Pignataro (cpignata) wrote:
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).
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.
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.
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
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
--
________________________________________________________________
Bob Briscoe http://bobbriscoe.net/
_______________________________________________
Int-area mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/int-area
