--- 1/draft-ietf-mpls-lsp-ping-lag-multipath-07.txt 2019-04-04 05:13:14.651548999 -0700 +++ 2/draft-ietf-mpls-lsp-ping-lag-multipath-08.txt 2019-04-04 05:13:14.707550553 -0700 @@ -1,27 +1,27 @@ Internet Engineering Task Force N. Akiya Internet-Draft Big Switch Networks Updates: 8029 (if approved) G. Swallow Intended status: Standards Track Cisco Systems -Expires: October 5, 2019 S. Litkowski +Expires: October 6, 2019 S. Litkowski B. Decraene Orange J. Drake Juniper Networks M. Chen Huawei - April 03, 2019 + April 04, 2019 Label Switched Path (LSP) Ping/Trace Multipath Support for Link Aggregation Group (LAG) Interfaces - draft-ietf-mpls-lsp-ping-lag-multipath-07 + draft-ietf-mpls-lsp-ping-lag-multipath-08 Abstract This document defines extensions to the MPLS Label Switched Path (LSP) Ping and Traceroute mechanisms as specified in RFC 8029. The extensions allow the MPLS LSP Ping and Traceroute mechanisms to discover and exercise specific paths of Layer 2 (L2) Equal-Cost Multipath (ECMP) over Link Aggregation Group (LAG) interfaces. Additionally, a mechanism is defined to enable determination of the capabilities of an LSR supported. @@ -44,21 +44,21 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on October 5, 2019. + This Internet-Draft will expire on October 6, 2019. Copyright Notice Copyright (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -164,33 +164,33 @@ can be blind to label switching failures over a problematic LAG interface. It is, thus, desirable to extend the MPLS LSP Ping and Traceroute to have deterministic diagnostic coverage of LAG interfaces. The need for a solution of this problem was motivated by issues encountered in live networks. 2. Overview of Solution - This document defines an new TLV to discover the capabilities of a + This document defines a new TLV to discover the capabilities of a responder LSR and extensions for use with the MPLS LSP Ping and Traceroute mechanisms to describe Multipath Information for individual LAG member links, thus allowing MPLS LSP Ping and Traceroute to discover and exercise specific paths of L2 ECMP over LAG interfaces. The reader is expected to be familiar with mechanics Downstream Detailed Mapping TLV (DDMAP) described in Section 3.4 of [RFC8029]. The solution consists of the MPLS echo request containing a DDMAP TLV and the new LSR Capability TLV to indicate that separate load balancing information for each L2 nexthop over LAG is desired in the - MPLS echo reply. The Responder LSR places the same LSR capability + MPLS echo reply. The Responder LSR places the same LSR Capability TLV in the MPLS echo reply to provide acknowledgement back to the initiator LSR. It also adds, for each downstream LAG member, load balance information (i.e., multipath information and interface index). This mechanism is applicable to all types of LSPs which can traverse over LAG interfaces. Many LAGs are built from p2p links, with router X and router X+1 having direct connectivity and the same number of LAG members. It is possible to build LAGs asymmetrically by using Ethernet switches between two routers. Appendix A lists some use cases for which the mechanisms defined in this document may not be applicable. Note that the mechanisms described in this @@ -246,21 +246,21 @@ 3. LSR Capability Discovery The MPLS Ping operates by an initiator LSR sending an MPLS echo request message and receiving back a corresponding MPLS echo reply message from a responder LSR. The MPLS Traceroute operates in a similar way except the initiator LSR potentially sends multiple MPLS echo request messages with incrementing TTL values. There have been many extensions to the MPLS Ping and Traceroute - mechanism over the years. Thus it is often useful, and sometimes + mechanisms over the years. Thus it is often useful, and sometimes necessary, for the initiator LSR to deterministically disambiguate the differences between: o The responder LSR sent the MPLS echo reply message with contents C because it has feature X, Y and Z implemented. o The responder LSR sent the MPLS echo reply message with contents C because it has subset of features X, Y and Z implemented but not all. @@ -318,21 +318,21 @@ 4. Mechanism to Discover L2 ECMP Multipath 4.1. Initiator LSR Procedures Through the "LSR Capability Discovery" as defined in Section 3, the initiator LSR can understand whether the responder LSR can describe incoming/outgoing LAG member links separately in the DDMAP TLV. Once the initiator LSR knows that a responder can support this - meachanims, then it sends an MPLS echo request carrying a DDMAP TLV + mechanism, then it sends an MPLS echo request carrying a DDMAP TLV with the "LAG Description Indicator flag" (G) set to the responder LSR. The "LAG Description Indicator flag" (G) indicates that separate load balancing information for each L2 nexthop over a LAG is desired in the MPLS echo reply. The new "LAG Description Indicator flag" is described in Section 7. 4.2. Responder LSR Procedures When a responder LSR received an MPLS echo request message with the "LAG Description Indicator flag" set in the DDMAP TLV, if the @@ -373,29 +373,30 @@ outside the scope of this document. + The responder LSR MUST add an Multipath Data Sub-TLV for this LAG member link, if the received DDMAP TLV requested multipath information. Based on the procedures described above, every LAG member link will have a Local Interface Index Sub-TLV and a Multipath Data Sub-TLV entries in the DDMAP TLV. The order of the Sub-TLVs in the DDMAP TLV for a LAG member link MUST be Local Interface Index Sub-TLV - immediately followed by Multipath Data Sub-TLV. A LAG member link - MAY also have a corresponding Remote Interface Index Sub-TLV. When a - Local Interface Index Sub-TLV, a Remote Interface Index-Sub-TLV and a - Multipath Data Sub-TLV are placed in the DDMAP TLV to describe a LAG - member link, they MUST be placed in the order of Local Interface - Index Sub-TLV, Remote Interface Index-Sub-TLV and Multipath Data Sub- - TLV. The block of local interface index, (optional remote interface - index) and multipath data sub-TLVs for each member link MUST appear - adjacent to each other in order of increasing local interface index. + immediately followed by Multipath Data Sub-TLV except as follows. A + LAG member link MAY also have a corresponding Remote Interface Index + Sub-TLV. When a Local Interface Index Sub-TLV, a Remote Interface + Index-Sub-TLV and a Multipath Data Sub-TLV are placed in the DDMAP + TLV to describe a LAG member link, they MUST be placed in the order + of Local Interface Index Sub-TLV, Remote Interface Index-Sub-TLV and + Multipath Data Sub-TLV. The block of local interface index, + (optional remote interface index) and multipath data sub-TLVs for + each member link MUST appear adjacent to each other in order of + increasing local interface index. A responder LSR possessing a LAG interface with two member links would send the following DDMAP for this LAG interface: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ DDMAP fields describing LAG interface with DS Flags G set ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Local Interface Index Sub-TLV of LAG member link #1 | @@ -709,23 +710,23 @@ G LAG Description Indicator When this flag is set in the MPLS echo request, the responder LSR is requested to respond with detailed LAG information. When this flag is set in the MPLS echo reply, the corresponding DDMAP TLV describes a LAG interface. 8. Local Interface Index Sub-TLV - The Local Interface Index Sub-TLV is an optional TLV, it describes - the interface index assigned by the local LSR to an egress interface. - One or more Local Interface Index sub-TLVs MAY appear in a DDMAP TLV. + The Local Interface Index Sub-TLV describes the interface index + assigned by the local LSR to an egress interface. One or more Local + Interface Index sub-TLVs MAY appear in a DDMAP TLV. The format of the Local Interface Index Sub-TLV is below: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Local Interface Index | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ @@ -963,21 +964,21 @@ attacks only have a small window of opportunity. If these messages are indeed hijacked (non-delivery) by an intermediate node, the use of these mechanisms will determine the data plane is not working (as it should). Hijacking of a responder node such that it provides a legitimate reply would involve compromising the node itself and the MPLS control domain. [RFC5920] provides additional MPLS network-wide operation recommendations to avoid attacks and recommendations to follow. Please note that source IP address filtering provides only a weak form of access control and is not, in general, a reliable security mechanism. Nonetheless, it is required here in the absence - of any more robust mechanism that might be used. + of any more robust mechanisms that might be used. 13. IANA Considerations 13.1. LSR Capability TLV The IANA is requested to assign new value TBD1 (from the range 4-16383) for LSR Capability TLV from the "Multiprotocol Label Switching Architecture (MPLS) Label Switched Paths (LSPs) Ping Parameters - TLVs" registry. @@ -1115,21 +1116,21 @@ The authors would like to thank Nagendra Kumar, Sam Aldrin, for providing useful comments and suggestions. The authors would like to thank Loa Andersson for performing a detailed review and providing number of comments. The authors also would like to extend sincere thanks to the MPLS RT review members who took time to review and provide comments. The members are Eric Osborne, Mach Chen and Yimin Shen. The suggestion by Mach Chen to generalize and create the LSR Capability TLV was tremendously helpful for this document and likely for future - documents extending the MPLS LSP Ping and Traceroute mechanism. The + documents extending the MPLS LSP Ping and Traceroute mechanisms. The suggestion by Yimin Shen to create two separate validation procedures had a big impact to the contents of this document. 15. References 15.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997,