Thanks Mirja. Ciao
L. > On 6 Feb 2019, at 18:57, Mirja Kuehlewind (IETF) <[email protected]> wrote: > > Hi Luigi, > > yes that sounds great! > > Thanks! > Mirja > > >> Am 06.02.2019 um 17:10 schrieb Luigi Iannone <[email protected]>: >> >> 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 >> ]. >> 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]. >> >> >> 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 >> ]. 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]. >> >> >> 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 >> ]. Note that 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]. >> >> >> 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
