Hi, Bob,
I think we're on the same page here. I'll suggest that it would be
useful to clarify "tightly coupled" as referring to "is required by a
specification (not just as an implementation issue)" and replace "part
of the same process" with "as defined in an integrated manner in a
specification requirement".
FWIW, I do think nearly every RFC comes with "the IETF recommends you do
this", which is at least partly why the IESG puts a strong wording to
the contrary for individual submissions where they don't agree with that
sentiment, so it would be useful to recheck the wording throughout in
that light. However, I don't have any specific suggestions.
I.e., although we agree, I'm not sure someone reading the document in
its current form would get the same impression.
Joe
On 6/21/2017 6:13 PM, Bob Briscoe wrote:
> 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
