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
