> Should I review 09 or 08?
It would be better to do -09. If I had known comments were coming from you I
would have waited to put in Albert’s text. What I did in -09 is simply
cut-and-paste his text.
> But please once you reply to this mail than you stick to the decision until I
> review the document.
I won’t make any other changes until I see your comments.
Dino
>
> L.
>
>
>> On 13 Jan 2018, at 19:30, Dino Farinacci <farina...@gmail.com> wrote:
>>
>> Here is a -09 proposal to add your requested change C below. All the other
>> points are still open for discussion.
>>
>> Dino
>>
>> <rfcdiff.html>
>>
>> <draft-ietf-lisp-rfc6830bis-09.txt>
>>
>>> On Jan 12, 2018, at 8:20 AM, Albert Cabellos <albert.cabel...@gmail.com>
>>> wrote:
>>>
>>> Hi all
>>>
>>> As editor of 6830bis I´d like to confirm or deny the following changes
>>> which I believe have support.
>>>
>>> Please note that I have intentionally ignored minor/editorial changes to
>>> help sync all the participants. I hope that the list below captures the
>>> most relevant ones.
>>>
>>> Also note that I don´t necessarily agree with all the changes listed below,
>>> but that´s an opinion with a different hat.
>>>
>>> WG: Please CONFIRM or DENY:
>>>
>>> -------
>>>
>>> A.- Remove definitions of PA and PI
>>>
>>> B.- Change definitions of EID and RLOC as ‘identifier of the overlay’ and
>>> ‘identifier of the underlay’ respectively.
>>>
>>> C.- In section 5.3, change the description of the encap/decap operation
>>> concerning how to deal with ECN and DSCP bits to (new text needs to be
>>> validated by experts):
>>>
>>> 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.
>>>
>>> D.- Simplify section ‘Router Locator Selection’ stating that the data-plane
>>> MUST follow what´s stored in the map-cache (priorities and weights), the
>>> remaining text should go to an OAM document.
>>>
>>> E.- Rewrite Section “Routing Locator Reachability” considering the
>>> following changes:
>>>
>>> * Keep bullet point 1 (examine LSB), 6 (receiving a data-packet) and
>>> Echo-Nonce
>>> * Move to 6833bis bullet point 2 (ICMP Network/Host Unreachable),3
>>> (hints from BGP),4 (ICMP Port Unreachable),5 (receive a Map-Reply as a
>>> response) and RLOC probing
>>>
>>>
>>> F.- Move Solicit-Map-Request to 6833bis
>>>
>>> G.- Move sections 16 (Mobility Considerations), 17 (xTR Placement
>>> Considerations), 18 (Traceroute Consideration) to a new OAM document
>>>
>>>
>>
>
_______________________________________________
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp
