Re: [lisp] Confirm/Deny changes on draft 6830bis

Hi Albert

Please find below my comments PPE

On Fri, Jan 12, 2018 at 5:20 PM, Albert Cabellos <albert.cabellos@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
>

<PPE> Confirm

>
> B.- Change definitions of EID and RLOC as ‘identifier of the overlay’ and
> ‘identifier of the underlay’ respectively.
>

<PPE> Deny - Agree with some others on the list that this does not add much
for clarification.

>
> 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.
>
>
> <PPE>  Abstain for now

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

> 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
>
>
> <PPE> Confirm see some of my comments on this on the thread.

> F.- Move Solicit-Map-Request to 6833bis
>
> <PPE> Confirm

> G.- Move sections 16 (Mobility Considerations), 17 (xTR Placement
> Considerations), 18 (Traceroute Consideration) to a new OAM document
>
>
>
<PPE> Confirm

Thanks
Padma

>
> _______________________________________________
> lisp mailing list
> lisp@ietf.org
> https://www.ietf.org/mailman/listinfo/lisp
>
>