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.
Also, the doc is written based on an implementation hint ('process')
rather than a protocol requirement.
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
> 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).
> 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.
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).
Joe
_______________________________________________
nvo3 mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/nvo3
