Hi,
On 27 Dec 2017, at 05:13, Dino Farinacci <[email protected]> wrote:
>
[snip]
>> Agreed, what about this (please comment):
>>
>> When doing ITR/PITR encapsulation:
>>
>> o The outer-header 'Time to Live' field (or 'Hop Limit' field, in the
>> case of IPv6) SHOULD be copied from the inner-header 'Time to Live' field.
>> o The outer-header 'Differentiated Services Code Point' (DSCP) field (or
>> the 'Traffic Class' field, in the case of IPv6) SHOULD be copied from the
>> inner-header DSCP field ('Traffic Class' field, in the case of IPv6)
>> considering the exception listed below.
>> o 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.
>>
>> When doing ETR/PETR decapsulation:
>>
>> o The inner-header 'Time to Live' field (or 'Hop Limit' field, in the case
>> of IPv6) SHOULD be copied from the outer-header 'Time to Live' field, when
>> the Time to Live value of the outer header is less than the Time to Live
>> value of the inner header. Failing to perform this check can cause the Time
>> to Live of the inner header to increment across encapsulation/decapsulation
>> cycles. This check is also performed when doing initial encapsulation, when
>> a packet comes to an ITR or PITR destined for a LISP site.
>> o The inner-header 'Differentiated Services Code Point' (DSCP) field (or
>> the 'Traffic Class' field, in the case of IPv6) SHOULD be copied from the
>> outer-header DSCP field ('Traffic Class' field, in the case of IPv6)
>> considering the exception listed below.
>> o 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]. 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.
>>
>> Note that if an ETR/PETR is also an ITR/PITR and chooses to re-encapsulate
>> after decapsulating, the net effect of this is that the new outer header
>> will carry the same Time to Live as the old outer header minus 1.
>>
>> Copying the Time to Live (TTL) serves two purposes: first, it preserves the
>> distance the host intended the packet to travel; second, and more
>> importantly, it provides for suppression of looping packets in the event
>> there is a loop of concatenated tunnels due to misconfiguration. See
>> Section 18.3 for TTL exception handling for traceroute packets.
>
> I had planned to take Luigi’s suggestion. I did not want to rewrite this
> section. It was carefully written by David Black with consolation from the
> ECN experts. I do not want to lose this technical text.
The text proposed by Albert is very close to the original and has exactly the
same content, just expressed in an clearer way. No loss here.
I will ask David to review the text again.
The current text in section 5.3 is still not correct because it talks about
“type of service” and “ECN”.
Luigi
_______________________________________________
lisp mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lisp
