Hi Albert , you find my comments inline.
Thanks again for your work. Ciao L. > On 12 Jan 2018, at 17:20, Albert Cabellos <[email protected]> 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 Agree. > > B.- Change definitions of EID and RLOC as ‘identifier of the overlay’ and > ‘identifier of the underlay’ respectively. For the RLOC I would put modify the definition as follows: Routing Locator (RLOC): An RLOC is an IPv4 [RFC0791] or IPv6 [RFC8200] address of an Egress Tunnel Router (ETR). An RLOC is the output of an EID-to-RLOC mapping lookup. An EID maps to one or more RLOCs. Typically, RLOCs are numbered from address blocks assigned to a site at each point to which it attaches to the underlay network, as such they represent the identifiers of the underlay. Multiple RLOCs can be assigned to the same ETR device or to multiple ETR devices at a site. > > 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): Agree. > > 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. Agree > > 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 Agree > > > F.- Move Solicit-Map-Request to 6833bis Agree > > G.- Move sections 16 (Mobility Considerations), 17 (xTR Placement > Considerations), 18 (Traceroute Consideration) to a new OAM document Agree I would like to add a _personal_ opinion about the OAM document. Looks like OAM is a good idea but concern has been expressed on whether adding a document would slow down the progress. I do not think this will happen. OAM is just a cut&paste of existing text on which no technical comments on the content itself has been made. As such creating OAM is a one hour job and since the content is stable text that has been reviewed extensively I do not see any issue in adopting the document right away (ideally in parallel with last call of 6830bis). After such step we check consistency with 6833bis and we last call both 6833bis and AOM in parallel. So no additional time. Again, this is my personal view but I believe that is definitively doable. Ciao > > > _______________________________________________ > lisp mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/lisp
_______________________________________________ lisp mailing list [email protected] https://www.ietf.org/mailman/listinfo/lisp
