> On 18 Sep 2018, at 12:32, Mirja Kuehlewind (IETF) <[email protected]> wrote:
>
> Hi Dino,
>
> please see below.
>
>> Am 17.09.2018 um 19:48 schrieb Dino Farinacci <[email protected]>:
>>
>>> PROPOSED
>>> "The 'Explicit Congestion Notification' (ECN) field (bits 6 and 7
>>> of the IPv6 'Traffic Class' field) [RFC3168] requires special treatment
>>> in
>>> order to preserve the use of ECN on the path.
>>> ITR encapsulation MUST copy the 2-bit 'ECN' field from the inner
>>> header to the outer header, inline with the ’Normal Mode’ in section 4.1
>>> of [RFC6040]. Re-encapsulation SHOULD follow the decapsulation as
>>> described
>>> below and then 2-bit 'ECN' field from the stripped inner header to the
>>> new outer header.“
>>
>> I did not include this text because the last sentence is not formed well.
>> Please restate. A verb is missing.
>
> copy
>
>>
>>> "The 'Explicit Congestion Notification' (ECN) field (bits 6 and 7
>>> of the IPv6 'Traffic Class' field) requires special treatment on
>>> decapsulation in
>>> order to avoid discarding indications of congestion,
>>> inline with section 4.2 of [RFC6040]. If
>>> the 'ECN‘ field of the outer header contains a congestion indication
>>> codepoint (the
>>> value is '11', the Congestion Experienced (CE) codepoint) and the inner
>>> header indicates ECN support (either ECT(0) or ECT(1) codepoint is set),
>>> then ETR decapsulation MUST also set CE field in the inner header that
>>> is
>>> used
>>> to forward the packet beyond the ETR. If the inner packet is marked as
>>> non-
>>> ECT but the outer header has the CE mark set, the packet MUST be dropped
>>> instead. Any discrepancy between the inner and outer header for non-ECT,
>>> ECT(0) and ECT(1) MUST NOT be copied from the outer header. These
>>> requirements preserve
>>> CE indications when a packet that is ECN-capable traverses a LISP tunnel
>>> and becomes marked with a CE indication due to congestion between
>>> the tunnel endpoints or transforms an CE into loss if that packet is not
>>> ECN-capable conserving the congestion indication towards a non-ECN
>>> enables
>>> endpoint.”
>>
>> I didn’t include this text because (1) it under states what to do with IPv4,
>> (2) it has too much detail that is already in RFC6040, and (3) it undoes
>> text that other reviewers have offered.
>
> I didn’t change the mentioning of IPv6 here. Yes please at IPv4.
>
> You can remove all this text and only point to rfc6040.
Mirja,
So why not keeping the text as it is (actually with some of the improvement you
suggested), but for all the rest we refer to 6040.
See below.
For the encapsulation we keep what you proposed:
"The 'Explicit Congestion Notification' (ECN) field (bits 6 and 7
of the IPv6 'Traffic Class' field) [RFC3168] requires special treatment in
order to preserve the use of ECN on the path.
ITR encapsulation MUST copy the 2-bit 'ECN' field from the inner
header to the outer header, inline with the ’Normal Mode’ in section 4.1
of [RFC6040]. Re-encapsulation SHOULD follow the decapsulation as
described
below and then copy the 2-bit 'ECN' field from the stripped inner header
to the
new outer header.“
For the decapsulation we simply keep the following:
"The 'Explicit Congestion Notification' (ECN) field (bits 6 and 7
of the IPv6 'Traffic Class' field) requires special treatment on
decapsulation in
order to avoid discarding indications of congestion,
inline with section 4.2 of [RFC6040]. If
the 'ECN‘ field of the outer header contains a congestion indication
codepoint (the
value is '11', the Congestion Experienced (CE) codepoint) and the inner
header indicates ECN support (either ECT(0) or ECT(1) codepoint is set),
then ETR decapsulation MUST also set CE field in the inner header that is
used to forward the packet beyond the ETR.
Further information on how to preserve CE information can be found in
RFC6040.”
L.
_______________________________________________
lisp mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lisp
