Hi Mirja,
> On 5 Feb 2019, at 16:39, Mirja Kuehlewind (IETF) <[email protected]> wrote: > > Hi Luigi, > > I just realized that I never replied to this mail. The change below is okay, > however, it did not make it into the current version of the draft and > therefore I cannot clear my discuss. Fair enough. Let me sum up the changes we agree on: Section 5.3 in the part marked as "When doing ITR/PITR encapsulation:” OLD: 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>]. 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. NEW and simplified: 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 as specified in [RFC6040 <https://tools.ietf.org/html/rfc6040>]. Note the re-encapsultion test has been remove (see later on) Section 5.3 in the part marked as "When doing ETR/PETR decapsulation:" OLD: 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>]. NEW and simplified: 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 as specified in [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 this behavior. It is RECOMMENDED that implementations change to support the behavior in [RFC6040 <https://tools.ietf.org/html/rfc6040>]. In the same section drop completely the last paragraph because is a duplicate of the above. Replaced by a note on the re-encapsulation: NEW (Replacing last paragraph) Some xTRs and PxTRs performs re-encapsulation operations and need to treat the 'Explicit Congestion Notification' (ECN) in a special way. Because the re-encapsulation operation is a sequence of two operations, namely a decapsulation followed by an encapsulation, the ECN bits MUST be treated as described above for these two operations. Does it sound OK to you? Ciao L. > Please also note that the text on decapsulation is basically in the same > section twice. I recommend to remove it once and adapt the other one > accordingly. > > Further, inline with RFC6040, you would also need to align the > re-encapsulation part. Currently the text says: > "Re-encapsulation MUST copy the 2-bit 'ECN' field from the stripped outer > header to the new outer header.“ > Usually re-encapsulation is performed by doing de-encapsulation and then > encapsulation again. The difference here would be, that if e.g. the inner > header is not-ETC but the tunnel changes the bits to ETC0 or ETC1 this error > is not further propagated, indicating ECN support where there is not ECN > support. > > Thanks, > Mirja > > > >> Am 26.09.2018 um 17:27 schrieb Luigi Iannone <[email protected]>: >> >> 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 >> ]. >> 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 >> ]. 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 >> ] does not recommend this behavior. It is RECOMMENDED >> that implementations change to support the behavior in [ >> 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]. >> Note that implementations exist that copy the 'ECN' >> field from the outer header to the inner header even though >> [ >> RFC6040 >> ] does not recommend such behavior. It is RECOMMENDED >> that implementations change, so to support the specifications in [ >> 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
