Joe,
[Cutting the distr to nvo3 and adding tsvwg.]
On 16/06/17 20:38, Joe Touch wrote:
Hi, Bob,
This approach seems to assume an integrated implementation of multiple
protocol layers.
There are other cases where the "shim" is added indirectly, as a
packet is "tunneled" independently over multiple protocols.
So what aspect of the following para (in S.3.1) does not include the
case(s) you are thinking of:
In some cases a tunnel adds an outer IP header and a tightly coupled
shim header to an inner header that is not an IP header, but that in
turn encapsulates an IP header (or might encapsulate an IP header).
For instance an inner Ethernet (or other link layer) header might
encapsulate an inner IP header as its payload. We call this a
tightly coupled shim over an encapsulating header.
Can you be more specific? Or perhaps give an example? Or suggest an edit
to the above text?
I scanned the draft and didn't see this addressed explicitly (maybe I
missed it). It's implied throughout 3.2 but never stated as a MAY,
e.g., systems MAY support ECN across shim layers but are NOT REQUIRED
to do so. Can that sort of explicit caveat be included? This case
might be added as a final bullet in the list at the end of section 3.2.
Section 3.2 solely gives the cases where ECN is not or cannot be
supported, so any ECN field in an outer IP header will have to be zeroed
(typically by configuration because the implementation will not include
any ECN logic).
If none of the cases listed in S.3.2 applies, then you would be in the
territory of section 3.1 (i.e. supporting ECN would already be covered
by RFC6040).
S.3.2 is solely there to plug an important hole that was left in
RFC6040. RFC6040 said what implementers have to do to support RFC6040,
but it did not include what /network operators/ have to do if they have
an implementation that does not support any ECN tunnelling spec
(RFC6040, RFC4301 or full functionality mode of RFC3168).
Have I misunderstood your point? Could I have made the text clearer?
I only realized S.3.2 was needed when I discovered that there is still
equipment being built that is copying the 8-bit ToS byte from inner to
outer as if the Internet Protocol is still as it was before Diffserv was
standardized 19 years ago (Dec 1998).
I suspect lazy implementers search for "Internet Protocol header" and
follow the many outdated articles you can find on the Web, rather than
checking the RFCs. For instance, the 2nd hit from Google (ranked just
below Wikipedia) erroneously tells us that the 8-bit ToS field contains
3 precedence bits (that are ignored), 4 ToS bits and 1 currently unused
bit. I am not going to cite the link here, which will just reinforce its
ranking.
Bob
Joe
On 6/16/2017 7:25 AM, Bob Briscoe wrote:
Fabio, Larry, Uri,
I notice VXLAN-GPE is on the IETF standards track.
It will need to specify support for propagation of the ECN field
between inner and outer for cases when there is (or might be) an IP
header (v4 or v6) within the L2 encapsulation, and when the outer is
IP (v4 or v6).
I believe ECN propagation between inner and outer is already in the
Linux code for VXLAN, but it's not specified in RFC7348, so other
implementations might overlook it. Given that ECN is heavily used in
DCs (e.g. for DCTCP), this is a significant omission.
Please refer to draft-ietf-tsvwg-rfc6040update-shim
<https://tools.ietf.org/html/draft-ietf-tsvwg-rfc6040update-shim> and
RFC6040.
I will warn you that, unless you believe that all existing VXLAN
implementations already support ECN, this will not be just a
straightforward case of referencing the appropriate RFCs. If there
might be non-ECN VXLAN decapsulators out there, the tunnel ingress
will have to know (by config or capability negotiation) whether the
egress supports ECN propagation, and if not, switch to 'compatibility
mode' (zeroing the outer ECN field). That could require definition of
a capability parameter during tunnel set-up (unless you envisage
tunnel set up will always be by administrative config).
Cheers
Bob
--
________________________________________________________________
Bob Briscoehttp://bobbriscoe.net/
_______________________________________________
nvo3 mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/nvo3
_______________________________________________
nvo3 mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/nvo3
--
________________________________________________________________
Bob Briscoe http://bobbriscoe.net/
_______________________________________________
nvo3 mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/nvo3
