Joe,
On 19/06/17 13:45, Joe Touch wrote:
Hi, Bob,
On 6/19/2017 4:37 AM, Bob Briscoe wrote:
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?
The issue is that the paragraph defines "tightly coupled" in terms of
"tightly coupled".
AFAICT, "tightly coupled" depends on whether the layers are added all
in the same software context or some "peeking" occurs after the shim
layer is added but before the final IP.
So I think you are not objecting to the para I quoted above, but to
something in the previous para, quoted here:
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. Processing the shim and outer together
is often necessary because the shim(s) are not sufficient for packet
forwarding in their own right; not unless complemented by an outer
header.
Is the phrase "as part of the same process" the one you are objecting to?
If so, I have no objection to using an alternative to the word 'process'
to avoid the implication that this means specifically one 'process' as
defined for the OS in question. It wasn't intended to use the word
'process' so strictly. The more general meaning of 'procedure' or
'routine' was intended.
The main point was that the definition of a shim is something that
cannot be used alone to forward a packet to another network address,
unless it is complemented by an outer PSN header.
Whatever, these paragraphs only give context to the subsequent normative
text, which (deliberately) doesn't actually rely on these definitions
anyway.
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?
My point is that the propagation of ECN across shim layers needs to be
more clearly explained as optional (even, IMO, for "tightly coupled"
cases). Right now, it reads more like "OK, so if you're layering has
failed to support ECN propagation, here's how to at least make it safe".
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.
Agreed, but again you're implying that there's something wrong with
code that can't propagate ECN, rather than saying that ECN operates at
the IP layer in which it is inserted by routers. Expecting ECN to
propagate to tunnels is an optimization that in one sense is useful
when it works, but in another is the antithesis of the point of tunneling.
The difficulty being addressed in this section is that blindly copying
an inner ECN field to an outer is unsafe (whether or not you want to
support ECN).
There is so much text in S.3.2 that says ECN is optional that I'm not
sure how I can say it any more times without making the reader die of
boredom. S.3.2. starts with
Even when ECN propagation is not implemented or is not being used,
and the proposed new normative text starts:
When the implementation of a tunnel ingress does not support
[RFC6040 <https://tools.ietf.org/html/rfc6040>] or one of its compatible
predecessors ([RFC4301 <https://tools.ietf.org/html/rfc4301>] or the
full functionality mode of [RFC3168
<https://tools.ietf.org/html/rfc3168>]) and when the outer tunnel
header is IP (v4 or v6),
And the section ends with all this:
Permanently zeroing the outer ECN field is safe, but it is not
sufficient to claim compliance withRFC 6040
<https://tools.ietf.org/html/rfc6040> because it does not meet
the aim of introducing ECN support to tunnels (seeSection 4.3 of [RFC6040]
<https://tools.ietf.org/html/rfc6040#section-4.3>). Developers and network
operators are encouraged to
implement and deploy tunnel endpoints compliant withRFC 6040
<https://tools.ietf.org/html/rfc6040> (as
updated by the present specification) in order to provide the
benefits of wider ECN deployment [RFC8087
<https://tools.ietf.org/html/rfc8087>]. Nonetheless, propagation
of ECN between IP headers, whether separated by shim headers or not,
has to be OPTIONAL to implement and to use, because:
o Legacy implementations of tunnels without any ECN support already
exist
o A network might be designed so that there is usually no bottleneck
within the tunnel
o If the tunnel endpoints would have to search within an L2 header
to find an encapsulated IP header, it might not be worth the
potential performance hit
What more do you want me to say, to emphasize that ECN is optional?
Preferably, please suggest specific edits.
Cheers
Bob
Joe
--
________________________________________________________________
Bob Briscoe http://bobbriscoe.net/
_______________________________________________
nvo3 mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/nvo3
