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