Should I review 09 or 08? But please once you reply to this mail than you stick to the decision until I review the document.
L. > On 13 Jan 2018, at 19:30, Dino Farinacci <[email protected]> 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 <[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 >> >> 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 [email protected] https://www.ietf.org/mailman/listinfo/lisp
