On 1/12/18 8:20 AM, Albert Cabellos 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
confirm.
I think one of the goals of the charter was to to open up to a broad set
of use cases where that terminology might not be meaningful.
B.- Change definitions of EID and RLOC as ‘identifier of the overlay’
and ‘identifier of the underlay’ respectively.
personally, I'm not keen to this change of terminology.
EID and RLOC have become of common use, and well understood, even
outside of the LISP circles. I've often assisted to conversations in
non-LISP groups where people use the term LISP EID/RLOC to qualify IP
addresses in the overlay/underlay.
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.
Confirm.
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.
Confirm on the section semplification.
Wrt putting the rest in a separate OAM document, I don't have a strong
opinion. Probably not having a new document requires less work to be
done that makes me lean toward NOT having a new 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
Confirm.
F.- Move Solicit-Map-Request to 6833bis
Confirm.
G.- Move sections 16 (Mobility Considerations), 17 (xTR Placement
Considerations), 18 (Traceroute Consideration) to a new OAM document
I'm fine with both options. Probably not having a new document requires
less work to be done that makes me lean toward NOT having a new OAM
document.
Thanks,
Fabio
_______________________________________________
lisp mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lisp
_______________________________________________
lisp mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lisp
