Joe,
On 21/06/17 23:46, Joe Touch wrote:
Hi, Bob,
On 6/19/2017 10:41 AM, Bob Briscoe wrote:
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?
Yes.
The doc is written a bit backwards; it presumes an optimization rather
than presuming the safe default.
[BB] Your concern holds if one believes that every RFC is implicitly
preceded be the statement "The IETF recommends that you comply with this
RFC". In contrast, I believe there is nothing implicit around an RFC. I
see an RFC solely as a specification of what an implementer can
voluntarily choose to comply with in order to interoperate with others
all collectively and voluntarily choosing to add a particular feature to
the Internet.
I think some of our previous disagreement have hinged on this difference
of opinion on the status of RFCs. If you know of any IETF document that
resolves this, pls point to it. Otherwise, discussion of every I-D is
going to tend to divert into an argument over this point.
Also, the doc is written based on an implementation hint ('process')
rather than a protocol requirement.
[BB] I explained (still in the thread below) that the normative protocol
requirements text a little later in the draft is (deliberately) not
dependent on this scene-setting paragraph. A common way to write an RFC
is to say "We have this sort of stuff in the world. Now here's some
normative text that is written more generically so that it applies to
that sort of stuff we have just described, as well as more general cases."
IMO, the recommendations should be:
ECN bits MUST be set to a known safe default when an IP layer is added,
EXCEPT if a tunnel is specified as the integrated insertion of
multiple layers, then jumping layers to coordinate ECN MAY be valid
[BB] See above. This would be a good way to write this RFC, if it was
implicitly surrounded by "The IETF recommends you comply with this RFC".
But If implementers reading this RFC are a self-selecting set who are
trying to implement ECN tunnelling, then the way it is written is a good
way.
Neither is incorrect. But given RFC6040 is already immutably published.
and it is written in the latter style, the only style that can be used
for an update is the same style.
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.
Even when a shim is enough to accomplish such fowarding, if the shim
lacks ECN support then ECN information should not be crossing the shim
layer (unless the shim isn't really defined as a separate layer, e.g.,
the example I gave above would state that the tunnel encapsulation
isn't shim THEN IP, but shim AND IP as an integrated step).
[BB] I don't disagree. I believe we are still only disagreeing about the
implicit status of RFCs ("Commandments" vs. "Points to Voluntarily
congregate around").
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).
Then IMHO that should be your title and focus.
[BB] It is the title, but only of the section. The document as a whole
is about what it says in the title of the document: "Propagating
Explicit Congestion Notification Across IP Tunnel Headers Separated by a
Shim"
The doc reads a bit backwards, more focusing on the optimization of
how and when you can do a smart copy across a shim than the basic idea
that "this isn't how ECN works".
It's not that you don't say this, it's that a reader would get the
reverse impression (i.e., that they should find a way to integrate
shim processing to enable this leap, rather than the fact that this is
a true exception and not the focus).
That is indeed the impression I would expect a reader to get, given I
see readers as a self-selected set who are already motivated to find a
way to enable this leap.
BTW, I have not come across an implementation yet that intrinsically
cannot do this smart copy to enable ECN (or Diffserv) to leap across a
shim. However, I would be surprised if there was not one.
Bob
Joe
_______________________________________________
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
