Hi Mirja,
trying to follow up on this issue.
The ECN text for encapsulation is currently:
The 'Explicit Congestion Notification' (ECN) field (bits 6 and 7
of the IPv6 'Traffic Class' field) requires special treatment in
order to avoid discarding indications of congestion [RFC3168
<https://tools.ietf.org/html/rfc3168>].
ITR encapsulation MUST copy the 2-bit 'ECN' field from the inner
header to the outer header. Re-encapsulation MUST copy the 2-bit
'ECN' field from the stripped outer header to the new outer
header.
Can we keep it as it is (updating the reference to 6040)?
The text for decapsulation is:
CURRENT:
The 'Explicit Congestion Notification' (ECN) field (bits 6 and 7
of the IPv6 'Traffic Class' field) requires special treatment in
order to avoid discarding indications of congestion [RFC6040
<https://tools.ietf.org/html/rfc6040>]. If
the 'ECN' field contains a congestion indication codepoint (the
value is '11', the Congestion Experienced (CE) codepoint), then
ETR decapsulation MUST copy the 2-bit 'ECN' field from the
stripped outer header to the surviving inner header that is used
to forward the packet beyond the ETR. These requirements preserve
CE indications when a packet that uses ECN traverses a LISP tunnel
and becomes marked with a CE indication due to congestion between
the tunnel endpoints. Implementations exist that copy the 'ECN'
field from the outer header to the inner header even though
[RFC6040 <https://tools.ietf.org/html/rfc6040>] does not recommend this
behavior. It is RECOMMENDED
that implementations change to support the behavior in [RFC6040
<https://tools.ietf.org/html/rfc6040>].
Which I suggest we shrink to:
NEW:
The 'Explicit Congestion Notification' (ECN) field (bits 6 and 7
of the IPv6 'Traffic Class' field) requires special treatment in
order to avoid discarding indications of congestion [RFC6040
<https://tools.ietf.org/html/rfc6040>].
Note that implementations exist that copy the 'ECN'
field from the outer header to the inner header even though
[RFC6040 <https://tools.ietf.org/html/rfc6040>] does not recommend such
behavior. It is RECOMMENDED
that implementations change, so to support the specifications in [RFC6040
<https://tools.ietf.org/html/rfc6040>].
The text above clearly states that implementations should be conform to 6040.
Is it what you were looking for?
Or am I missing something?
Ciao
L.
> On 24 Sep 2018, at 19:34, Dino Farinacci <[email protected]> wrote:
>
> Well, the implementations are out and working. And we said in the latest
> updates to consider using RFC6040. So not sure we can do much more than that.
>
> Dino
>
>> On Sep 24, 2018, at 5:52 AM, Mirja Kuehlewind (IETF) <[email protected]>
>> wrote:
>>
>> Because they don’t follow RFC6040 and therefore we do something different in
>> some corner cases.
>>
>>
>>
>>> Am 22.09.2018 um 06:52 schrieb Dino Farinacci <[email protected]>:
>>>
>>>> However, I totally disagree with your comment on providing details that
>>>> are not implemented. If they are not implemented correctly, it might even
>>>> be more important to spell them out in this document, so implementors have
>>>> chance to update their (future) implementation to do the correct thing.
>>>> Having deployed implementations that are non standard-conform always
>>>> happens and in this case it is probably not specifically problematic as it
>>>> doesn’t impact interoperability. However, it is important though that the
>>>> spec is correct.
>>>
>>> And why do you think they are implemented incorrectly?
>>>
>>> Dino
>>>
>>
>
_______________________________________________
lisp mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lisp
