draft-ietf-mpls-lsp-ping-lag-multipath-01.txt   draft-ietf-mpls-lsp-ping-lag-multipath-02.txt 
Internet Engineering Task Force N. Akiya Internet Engineering Task Force N. Akiya
Internet-Draft Big Switch Networks Internet-Draft Big Switch Networks
Updates: 4379,6424 (if approved) G. Swallow Updates: 8029 (if approved) G. Swallow
Intended status: Standards Track Cisco Systems Intended status: Standards Track Cisco Systems
Expires: January 24, 2016 S. Litkowski Expires: November 20, 2017 S. Litkowski
B. Decraene B. Decraene
Orange Orange
J. Drake J. Drake
Juniper Networks Juniper Networks
July 23, 2015 M. Chen
Huawei
May 19, 2017
Label Switched Path (LSP) Ping/Trace Multipath Support for Label Switched Path (LSP) Ping/Trace Multipath Support for
Link Aggregation Group (LAG) Interfaces Link Aggregation Group (LAG) Interfaces
draft-ietf-mpls-lsp-ping-lag-multipath-01 draft-ietf-mpls-lsp-ping-lag-multipath-02
Abstract Abstract
This document defines an extension to the MPLS Label Switched Path This document defines an extension to the MPLS Label Switched Path
(LSP) Ping and Traceroute as specified in RFC 4379. The extension (LSP) Ping and Traceroute as specified in RFC 8029. The extension
allows the MPLS LSP Ping and Traceroute to discover and exercise allows the MPLS LSP Ping and Traceroute to discover and exercise
specific paths of Layer 2 (L2) Equal-Cost Multipath (ECMP) over Link specific paths of Layer 2 (L2) Equal-Cost Multipath (ECMP) over Link
Aggregation Group (LAG) interfaces. Aggregation Group (LAG) interfaces.
This document updates RFC4379 and RFC6424. This document updates RFC8029.
Requirements Language Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
skipping to change at page 1, line 48 skipping to change at page 2, line 4
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on November 20, 2017.
This Internet-Draft will expire on January 24, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2017 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 3, line 13 skipping to change at page 3, line 16
12.4. Detailed Interface and Label Stack TLV . . . . . . . . . 23 12.4. Detailed Interface and Label Stack TLV . . . . . . . . . 23
12.4.1. Sub-TLVs for TLV Type TBD4 . . . . . . . . . . . . . 24 12.4.1. Sub-TLVs for TLV Type TBD4 . . . . . . . . . . . . . 24
12.5. DS Flags . . . . . . . . . . . . . . . . . . . . . . . . 24 12.5. DS Flags . . . . . . . . . . . . . . . . . . . . . . . . 24
13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 24 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 24
14. References . . . . . . . . . . . . . . . . . . . . . . . . . 25 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 25
14.1. Normative References . . . . . . . . . . . . . . . . . . 25 14.1. Normative References . . . . . . . . . . . . . . . . . . 25
14.2. Informative References . . . . . . . . . . . . . . . . . 25 14.2. Informative References . . . . . . . . . . . . . . . . . 25
Appendix A. LAG with L2 Switch Issues . . . . . . . . . . . . . 26 Appendix A. LAG with L2 Switch Issues . . . . . . . . . . . . . 26
A.1. Equal Numbers of LAG Members . . . . . . . . . . . . . . 26 A.1. Equal Numbers of LAG Members . . . . . . . . . . . . . . 26
A.2. Deviating Numbers of LAG Members . . . . . . . . . . . . 26 A.2. Deviating Numbers of LAG Members . . . . . . . . . . . . 26
A.3. LAG Only on Right . . . . . . . . . . . . . . . . . . . . 27 A.3. LAG Only on Right . . . . . . . . . . . . . . . . . . . . 26
A.4. LAG Only on Left . . . . . . . . . . . . . . . . . . . . 27 A.4. LAG Only on Left . . . . . . . . . . . . . . . . . . . . 27
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27
1. Introduction 1. Introduction
1.1. Terminology 1.1. Terminology
The following acronyms/terms are used in this document: The following acronyms/terms are used in this document:
o MPLS - Multiprotocol Label Switching. o MPLS - Multiprotocol Label Switching.
skipping to change at page 3, line 41 skipping to change at page 3, line 44
o LAG - Link Aggregation Group. o LAG - Link Aggregation Group.
o Initiator LSR - LSR which sends MPLS echo request. o Initiator LSR - LSR which sends MPLS echo request.
o Responder LSR - LSR which receives MPLS echo request and sends o Responder LSR - LSR which receives MPLS echo request and sends
MPLS echo reply. MPLS echo reply.
1.2. Background 1.2. Background
The MPLS Label Switched Path (LSP) Ping and Traceroute as specified The MPLS Label Switched Path (LSP) Ping and Traceroute as specified
in [RFC4379] are powerful tools designed to diagnose all available in [RFC8029] are powerful tools designed to diagnose all available
layer 3 (L3) paths of LSPs, i.e., provides diagnostic coverage of L3 layer 3 (L3) paths of LSPs, i.e., provides diagnostic coverage of L3
Equal-Cost Multipath (ECMP). In many MPLS networks, Link Aggregation Equal-Cost Multipath (ECMP). In many MPLS networks, Link Aggregation
Group (LAG) as defined in [IEEE802.1AX], which provide Layer 2 (L2) Group (LAG) as defined in [IEEE802.1AX], which provide Layer 2 (L2)
ECMP, are often used for various reasons. MPLS LSP Ping and ECMP, are often used for various reasons. MPLS LSP Ping and
Traceroute tools were not designed to discover and exercise specific Traceroute tools were not designed to discover and exercise specific
paths of L2 ECMP. The result raises a limitation for following paths of L2 ECMP. The result raises a limitation for following
scenario when LSP X traverses over LAG Y: scenario when LSP X traverses over LAG Y:
o Label switching of LSP X over one or more member links of LAG Y o Label switching of LSP X over one or more member links of LAG Y
have succeeded. have succeeded.
skipping to change at page 4, line 30 skipping to change at page 4, line 33
Creation of this document was motivated by issues encountered in live Creation of this document was motivated by issues encountered in live
networks. networks.
2. Overview 2. Overview
This document defines an extension to the MPLS LSP Ping and This document defines an extension to the MPLS LSP Ping and
Traceroute to describe Multipath Information for LAG member links Traceroute to describe Multipath Information for LAG member links
separately, thus allowing MPLS LSP Ping and Traceroute to discover separately, thus allowing MPLS LSP Ping and Traceroute to discover
and exercise specific paths of L2 ECMP over LAG interfaces. Reader and exercise specific paths of L2 ECMP over LAG interfaces. Reader
is expected to be familiar with mechanics of the MPLS LSP Ping and is expected to be familiar with mechanics of the MPLS LSP Ping and
Traceroute described in Section 3.3 of [RFC4379] and Downstream Traceroute described in Section 3.3 of [RFC8029] and Downstream
Detailed Mapping TLV (DDMAP) described in Section 3.3 of [RFC6424]. Detailed Mapping TLV (DDMAP) described in Section 3.4 of [RFC8029].
MPLS echo request carries a DDMAP and an optional TLV to indicate MPLS echo request carries a DDMAP and an optional TLV to indicate
that separate load balancing information for each L2 nexthop over LAG that separate load balancing information for each L2 nexthop over LAG
is desired in MPLS echo reply. Responder LSR places the same is desired in MPLS echo reply. Responder LSR places the same
optional TLV in the MPLS echo reply to provide acknowledgement back optional TLV in the MPLS echo reply to provide acknowledgement back
to the initiator. It also adds, for each downstream LAG member, a to the initiator. It also adds, for each downstream LAG member, a
load balance information (i.e. multipath information and interface load balance information (i.e. multipath information and interface
index). The following figure and the texts provides an example using index). The following figure and the texts provides an example using
an LDP network. However the problem and the mechanism is applicable an LDP network. However the problem and the mechanism is applicable
to all types of LSPs which can traverse over LAG interfaces. to all types of LSPs which can traverse over LAG interfaces.
skipping to change at page 10, line 23 skipping to change at page 10, line 23
sending DDMAP. sending DDMAP.
o The Multipath Data Sub-TLVs MUST be updated to include just one o The Multipath Data Sub-TLVs MUST be updated to include just one
Multipath Data Sub-TLV. The initiator MAY keep just the Multipath Multipath Data Sub-TLV. The initiator MAY keep just the Multipath
Data Sub-TLV corresponding to the LAG member link being traversed, Data Sub-TLV corresponding to the LAG member link being traversed,
or combine the Multipath Data Sub-TLVs for all LAG member links or combine the Multipath Data Sub-TLVs for all LAG member links
into a single Multipath Data Sub-TLV when diagnosing further into a single Multipath Data Sub-TLV when diagnosing further
downstream LSRs. downstream LSRs.
o All other fields of the DDMAP are to comply with procedures o All other fields of the DDMAP are to comply with procedures
described in [RFC6424]. described in [RFC8029].
Using the DDMAP example described in the Figure 2, the DDMAP being Using the DDMAP example described in the Figure 2, the DDMAP being
sent by the initiator LSR through LAG member link #1 to the next sent by the initiator LSR through LAG member link #1 to the next
downstream LSR should be: downstream LSR should be:
0 1 2 3 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 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 ~ ~ DDMAP fields describing LAG interface with DS Flags G set ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 19, line 6 skipping to change at page 19, line 6
| Must Be Zero | Sub-TLV Length | | Must Be Zero | Sub-TLV Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. . . .
. List of Sub-TLVs . . List of Sub-TLVs .
. . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: Detailed Interface and Label Stack TLV Figure 7: Detailed Interface and Label Stack TLV
The Detailed Interface and Label Stack TLV format is derived from the The Detailed Interface and Label Stack TLV format is derived from the
Interface and Label Stack TLV format (from [RFC4379]). Two changes Interface and Label Stack TLV format (from [RFC8029]). Two changes
are introduced. First is that label stack, which is of variable are introduced. First is that label stack, which is of variable
length, is converted into a sub-TLV. Second is that a new sub-TLV is length, is converted into a sub-TLV. Second is that a new sub-TLV is
added to describe an interface index. The fields of Detailed added to describe an interface index. The fields of Detailed
Interface and Label Stack TLV have the same use and meaning as in Interface and Label Stack TLV have the same use and meaning as in
[RFC4379]. A summary of the fields taken from the Interface and [RFC8029]. A summary of the fields taken from the Interface and
Label Stack TLV is as below: Label Stack TLV is as below:
Address Type Address Type
The Address Type indicates if the interface is numbered or The Address Type indicates if the interface is numbered or
unnumbered. It also determines the length of the IP Address unnumbered. It also determines the length of the IP Address
and Interface fields. The resulting total for the initial part and Interface fields. The resulting total for the initial part
of the TLV is listed in the table below as "K Octets". The of the TLV is listed in the table below as "K Octets". The
Address Type is set to one of the following values: Address Type is set to one of the following values:
skipping to change at page 19, line 45 skipping to change at page 19, line 45
received is numbered, then the Address Type MUST be set to IPv4 received is numbered, then the Address Type MUST be set to IPv4
Numbered or IPv6 Numbered, the IP Address MUST be set to either Numbered or IPv6 Numbered, the IP Address MUST be set to either
the LSR's Router ID or the interface address, and the Interface the LSR's Router ID or the interface address, and the Interface
MUST be set to the interface address. MUST be set to the interface address.
If the interface is unnumbered, the Address Type MUST be either If the interface is unnumbered, the Address Type MUST be either
IPv4 Unnumbered or IPv6 Unnumbered, the IP Address MUST be the IPv4 Unnumbered or IPv6 Unnumbered, the IP Address MUST be the
LSR's Router ID, and the Interface MUST be set to the index LSR's Router ID, and the Interface MUST be set to the index
assigned to the interface. assigned to the interface.
Note: Usage of IPv6 Unnumbered has the same issue as [RFC4379], Note: Usage of IPv6 Unnumbered has the same issue as [RFC8029],
described in Section 3.4.2 of [I-D.ietf-mpls-ipv6-only-gap]. A described in Section 3.4.2 of [RFC7439]. A solution should be
solution should be considered an applied to both [RFC4379] and considered an applied to both [RFC8029] and this document.
this document.
Sub-TLV Length Sub-TLV Length
Total length in octets of the sub-TLVs associated with this Total length in octets of the sub-TLVs associated with this
TLV. TLV.
10.1. Sub-TLVs 10.1. Sub-TLVs
This section defines the sub-TLVs that MAY be included as part of the This section defines the sub-TLVs that MAY be included as part of the
Detailed Interface and Label Stack TLV. Detailed Interface and Label Stack TLV.
Sub-Type Value Field Sub-Type Value Field
--------- ------------ --------- ------------
skipping to change at page 21, line 50 skipping to change at page 21, line 50
An Index assigned by the LSR to this interface. An Index assigned by the LSR to this interface.
11. Security Considerations 11. Security Considerations
This document extends LSP Traceroute mechanism to discover and This document extends LSP Traceroute mechanism to discover and
exercise L2 ECMP paths. As a result of supporting the code points exercise L2 ECMP paths. As a result of supporting the code points
and procedures described in this document, additional processing are and procedures described in this document, additional processing are
required by initiator LSRs and responder LSRs, especially to compute required by initiator LSRs and responder LSRs, especially to compute
and handle increasing number of multipath information. Due to and handle increasing number of multipath information. Due to
additional processing, it is critical that proper security measures additional processing, it is critical that proper security measures
described in [RFC4379] and [RFC6424] are followed. described in [RFC8029] are followed.
The LSP Traceroute allows an initiator LSR to discover the paths of The LSP Traceroute allows an initiator LSR to discover the paths of
tested LSPs, providing deep knowledge of the MPLS network. Exposing tested LSPs, providing deep knowledge of the MPLS network. Exposing
such information to a malicious user is considered dangerous. To such information to a malicious user is considered dangerous. To
prevent leakage of vital information to untrusted users, a responder prevent leakage of vital information to untrusted users, a responder
LSR MUST only accept MPLS echo request messages from trusted sources LSR MUST only accept MPLS echo request messages from trusted sources
via filtering source IP address field of received MPLS echo request via filtering source IP address field of received MPLS echo request
messages. messages.
12. IANA Considerations 12. IANA Considerations
skipping to change at page 25, line 23 skipping to change at page 25, line 23
14. References 14. References
14.1. Normative References 14.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>. <http://www.rfc-editor.org/info/rfc2119>.
[RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-Protocol
Label Switched (MPLS) Data Plane Failures", RFC 4379,
DOI 10.17487/RFC4379, February 2006,
<http://www.rfc-editor.org/info/rfc4379>.
[RFC6424] Bahadur, N., Kompella, K., and G. Swallow, "Mechanism for
Performing Label Switched Path Ping (LSP Ping) over MPLS
Tunnels", RFC 6424, DOI 10.17487/RFC6424, November 2011,
<http://www.rfc-editor.org/info/rfc6424>.
[RFC7537] Decraene, B., Akiya, N., Pignataro, C., Andersson, L., and [RFC7537] Decraene, B., Akiya, N., Pignataro, C., Andersson, L., and
S. Aldrin, "IANA Registries for LSP Ping Code Points", S. Aldrin, "IANA Registries for LSP Ping Code Points",
RFC 7537, DOI 10.17487/RFC7537, May 2015, RFC 7537, DOI 10.17487/RFC7537, May 2015,
<http://www.rfc-editor.org/info/rfc7537>. <http://www.rfc-editor.org/info/rfc7537>.
14.2. Informative References [RFC8029] Kompella, K., Swallow, G., Pignataro, C., Ed., Kumar, N.,
Aldrin, S., and M. Chen, "Detecting Multiprotocol Label
Switched (MPLS) Data-Plane Failures", RFC 8029,
DOI 10.17487/RFC8029, March 2017,
<http://www.rfc-editor.org/info/rfc8029>.
[I-D.ietf-mpls-ipv6-only-gap] 14.2. Informative References
George, W. and C. Pignataro, "Gap Analysis for Operating
IPv6-only MPLS Networks", draft-ietf-mpls-ipv6-only-gap-04
(work in progress), November 2014.
[IANA-MPLS-LSP-PING] [IANA-MPLS-LSP-PING]
IANA, "Multi-Protocol Label Switching (MPLS) Label IANA, "Multi-Protocol Label Switching (MPLS) Label
Switched Paths (LSPs) Ping Parameters", Switched Paths (LSPs) Ping Parameters",
<http://www.iana.org/assignments/mpls-lsp-ping-parameters/ <http://www.iana.org/assignments/mpls-lsp-ping-parameters/
mpls-lsp-ping-parameters.xhtml>. mpls-lsp-ping-parameters.xhtml>.
[IEEE802.1AX] [IEEE802.1AX]
IEEE Std. 802.1AX, "IEEE Standard for Local and IEEE Std. 802.1AX, "IEEE Standard for Local and
metropolitan area networks - Link Aggregation", November metropolitan area networks - Link Aggregation", November
2008. 2008.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226, IANA Considerations Section in RFCs", BCP 26, RFC 5226,
DOI 10.17487/RFC5226, May 2008, DOI 10.17487/RFC5226, May 2008,
<http://www.rfc-editor.org/info/rfc5226>. <http://www.rfc-editor.org/info/rfc5226>.
[RFC7439] George, W., Ed. and C. Pignataro, Ed., "Gap Analysis for
Operating IPv6-Only MPLS Networks", RFC 7439,
DOI 10.17487/RFC7439, January 2015,
<http://www.rfc-editor.org/info/rfc7439>.
Appendix A. LAG with L2 Switch Issues Appendix A. LAG with L2 Switch Issues
Several flavors of "LAG with L2 switch" provisioning models are Several flavors of "LAG with L2 switch" provisioning models are
described in this section, with MPLS data plane ECMP traversal described in this section, with MPLS data plane ECMP traversal
validation issues with each. validation issues with each.
A.1. Equal Numbers of LAG Members A.1. Equal Numbers of LAG Members
R1 ==== S1 ==== R2 R1 ==== S1 ==== R2
skipping to change at page 28, line 4 skipping to change at page 27, line 37
Stephane Litkowski Stephane Litkowski
Orange Orange
Email: stephane.litkowski@orange.com Email: stephane.litkowski@orange.com
Bruno Decraene Bruno Decraene
Orange Orange
Email: bruno.decraene@orange.com Email: bruno.decraene@orange.com
John E. Drake John E. Drake
Juniper Networks Juniper Networks
Email: jdrake@juniper.net Email: jdrake@juniper.net
Mach(Guoyi) Chen
Huawei
Email: mach.chen@huawei.com
 End of changes. 23 change blocks. 
36 lines changed or deleted 34 lines changed or added

This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/