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. 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
