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 <farina...@gmail.com> 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) <i...@kuehlewind.net> >> 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 <farina...@gmail.com>: >>> >>>> 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 lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp