MPLS Working Group IJ. Wijnands
Internet-Draft K. Raza
Intended status: Standards Track Cisco Systems, Inc.
Expires: September 6, 2018 Z. Zhang
Juniper Networks
A. Gulko
Thomson Reuters
March 5, 2018
mLDP Extensions for Multi-Topology Routing
draft-wijnands-mpls-mldp-multi-topology-00.txt
Abstract
Multi-Topology Routing (MTR) is a technology to enable service
differentiation within an IP network. Flexible Algorithm (FA) is
another mechanism of creating a sub-topology within a topology using
defined topology constraints and computation algorithm. In order to
deploy mLDP in a network that supports MTR and/or FA, mLDP is
required to become topology and FA aware. This document specifies
extensions to mLDP to support MTR with FA such that when building a
Multi-Point LSPs it can follow a particular topology and algorithm.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
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 September 6, 2018.
Copyright Notice
Copyright (c) 2018 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
Wijnands, et al. Expires September 6, 2018 [Page 1]
Internet-Draft Multi-Topology mLDP March 2018
(https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Specification of Requirements . . . . . . . . . . . . . . . . 4
4. MT Scoped mLDP FECs . . . . . . . . . . . . . . . . . . . . . 4
4.1. MP FEC Extensions for MT . . . . . . . . . . . . . . . . 4
4.1.1. MP FEC Element . . . . . . . . . . . . . . . . . . . 4
4.1.2. MT IP Address Families . . . . . . . . . . . . . . . 5
4.1.3. MT MP FEC Element . . . . . . . . . . . . . . . . . . 6
4.2. Topology IDs . . . . . . . . . . . . . . . . . . . . . . 7
5. MT Multipoint Capability . . . . . . . . . . . . . . . . . . 7
6. MT Applicability on FEC-based features . . . . . . . . . . . 8
6.1. Typed Wildcard MP FEC Elements . . . . . . . . . . . . . 8
6.2. End-of-LIB . . . . . . . . . . . . . . . . . . . . . . . 9
7. Topology-Scoped Signaling and Forwarding . . . . . . . . . . 10
7.1. Upstream LSR selection . . . . . . . . . . . . . . . . . 10
7.2. Downstream forwarding interface selection . . . . . . . . 10
8. LSP Ping Extensions . . . . . . . . . . . . . . . . . . . . . 10
9. Security Considerations . . . . . . . . . . . . . . . . . . . 11
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
12.1. Normative References . . . . . . . . . . . . . . . . . . 12
12.2. Informative References . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13
1. Glossary
MT - Multi-Topology
MT-ID - Multi-Topology Identifier
MTR - Multi-Topology Routing
IGP - Interior Gateway Protocol
MP - Multipoint (P2MP or MP2MP)
LDP - Label Distribution Protocol
Wijnands, et al. Expires September 6, 2018 [Page 2]
Internet-Draft Multi-Topology mLDP March 2018
mLDP - Multipoint LDP
P2MP - Point-to-Multipoint
MP2MP - Multipoint-to-Multipoint
FEC - Forwarding Equivalence Class
LSP - Label Switched Path
FA - Flexible Algorithm
IPA - IGP Algorithm
2. Introduction
Multi-Topology Routing (MTR) is a technology to enable service
differentiation within an IP network. IGP protocols (OSPF and IS-IS)
and LDP have already been extended to support MTR. To support MTR,
an IGP maintains independent IP topologies, termed as "Multi-
Topologies" (MT), and computes/installs routes per topology. OSPF
extensions [RFC4915] and ISIS extensions [RFC5120] specify the MT
extensions under respective IGPs. To support IGP MT, similar LDP
extensions [RFC7307] have been specified to make LDP MT-aware and be
able to setup unicast Label Switched Paths (LSPs) along IGP MT
routing paths.
A more light weight mechanism to define constraint-based topologies
is Flexible Algorithm (FA) [I-D.hegdeppsenak-isis-sr-flex-algo]. FA
can be seen as creating a sub-topology within a topology using
defined topology constraints and computation algorithm. This can be
done within a MTR topology or just the default Topology. An instance
of such a sub-topology is identified by a 1 octet value as documented
in [I-D.hegdeppsenak-isis-sr-flex-algo]). Flexible Algorithm is a
mechanism to create a sub-topology, but in the future different
algorithms might be defined on how to achieve that. For that reason,
in the remainder of this document we'll refer to this as the IGP
Algorithm (IPA).
Multipoint LDP (mLDP) refers to extensions in LDP to setup multi-
point LSPs (point-to-multipoint (P2MP) or multipoint-to-multipoint
(MP2MP)), by means of set of extensions and procedures defined in
[RFC6388]. In order to deploy mLDP in a network that supports MTR
and FA, mLDP is required to become topology and algorithm aware.
This document specifies extensions to mLDP to support MTR/IPA such
that when building a Multi-Point LSPs it can follow a particular
topology and alogirthm. This means that the identifier for the
Wijnands, et al. Expires September 6, 2018 [Page 3]
Internet-Draft Multi-Topology mLDP March 2018
particular Topology to be used by mLDP have to become a two tuple
(MTR Topology Id, IGP Algorithm).
3. Specification of Requirements
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
In this document, these words will appear with that interpretation
only when in ALL CAPS. Lower case uses of these words are not to be
interpreted as carrying RFC-2119 significance.
4. MT Scoped mLDP FECs
As defined in [RFC7307], MPLS Multi-Topology Identifier (MT-ID) is an
identifier that is used to associate an LSP with a certain MTR
topology. In the context of MP LSPs, this identifier is part of the
mLDP FEC encoding so that LDP peers are able to setup an MP LSP via
their own defined MTR policy. In order to avoid conflicting MTR
policies for the same mLDP FEC, the MT-ID needs to be a part of the
FEC, so that different MT-ID values will result in unique MP-LSP FEC
elements.
The same applies to the IPA. The IPA needs to be encoded as part of
the mLDP FEC to create unique MP-LSPs and at the same time is used to
signal to mLDP (hop-by-hop) which Algorithm needs to be used to
create the MP-LSP.
Since the MT-ID and IPA are part of the FEC, they apply to all the
LDP messages that potentially include an mLDP FEC element.
4.1. MP FEC Extensions for MT
Following subsections propose the extensions to bind an mLDP FEC to a
topology. The mLDP MT extensions reuse some of the extensions
specified in [RFC7307].
4.1.1. MP FEC Element
Base mLDP specification [RFC6388] defines MP FEC Element as follows:
Wijnands, et al. Expires September 6, 2018 [Page 4]
Internet-Draft Multi-Topology mLDP March 2018
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MP FEC type | Address Family | AF Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Root Node Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Opaque Length | Opaque Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: MP FEC Element Format [RFC6388]
Where "Root Node Address" encoding is as defined for given "Address
Family", and whose length (in octets) is specified by the "AF Length"
field.
To extend MP FEC elements for MT, the {MT-ID, IPA} is a tuple that is
relevant in the context of the root address of the MP LSP. The {MT-
ID, IPA} tuple determines in which (sub)-topology the root address
needs to be resolved. Since the {MT-ID, IPA} tuple should be
considered part of the mLDP FEC, the most natural place to encode
this tuple is as part of the root address. While encoding it, we
also propose to use "MT IP" Address Families as described in
following sub section.
4.1.2. MT IP Address Families
[RFC7307] has specified new address families, named "MT IP" and "MT
IPv6", to allow specification of an IP prefix within a topology
scope. In addition to using this address family for mLDP, we also
use 8 bits of the 16 bits Reserved field to encode the IGP Algorithm
(IPA) Registry. The resulting format of the data associated with
these new Address Families is as follows:
Wijnands, et al. Expires September 6, 2018 [Page 5]
Internet-Draft Multi-Topology mLDP March 2018
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | IPA | MT-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 Address |
| |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | IPA | MT-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Modified MT IP Address Families Data Format
Where:
IPv4/IPv6 Address: An IP address corresponding to "MT IP" and "MT
IPv6" address families respectively.
IPA: The IGP Algorithm, values are from the IGP Algorithm
registry.
Reserved: This 8-bit field MUST be zero. If a message is received
that includes a MT address family where the 8 bit Reserved value
is not zero, the message must be discarded.
4.1.3. MT MP FEC Element
By using extended MT IP Address Family, the resultant MT MP FEC
element is to be encoded as follows:
Wijnands, et al. Expires September 6, 2018 [Page 6]
Internet-Draft Multi-Topology mLDP March 2018
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MP FEC type | AF (MT IP/ MT IPv6) | AF Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Root Node Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | IPA | MT-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Opaque Length | Opaque Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: IP MT-Scoped MP FEC Element Format
In the context of this document, the applicable LDP FECs for MT mLDP
include:
o MP FEC Elements:
* P2MP (type 0x6)
* MP2MP-up (type 0x7)
* MP2MP-down (type 0x8)
o Typed Wildcard FEC Element (type 0x5)
In case of "Typed Wildcard FEC Element", the sub FEC Element type
MUST be one of the MP FECs listed above.
This specification allows the use of Topology-scoped mLDP FECs in LDP
label and notification messages, as applicable.
4.2. Topology IDs
This document assumes the same definitions and procedures associated
with MPLS MT-ID as defined in [RFC7307] specification.
5. MT Multipoint Capability
"MT Multipoint Capability" is a new LDP capability, defined in
accordance with LDP Capability definition guidelines [RFC5561], that
is to be advertised to its peers by an mLDP speaker to announce its
capability to support MTR and the procedures specified in this
document. This capability MAY be sent either in an Initialization
Wijnands, et al. Expires September 6, 2018 [Page 7]
Internet-Draft Multi-Topology mLDP March 2018
message at the session establishment time, or in a Capability message
dynamically during the lifetime of a session (only if "Dynamic
Announcement" capability [RFC5561] has been successfully negotiated
with the peer).
The format of this capability is as follows:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U|F| MT Multipoint Cap.(IANA) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|S| Reserved |
+-+-+-+-+-+-+-+-+
Figure 4: MT Multipoint Capability TLV Format
Where:
U- and F-bits: MUST be 1 and 0, respectively, as per Section 3 of
LDP Capabilities [RFC5561].
MT Multipoint Capaility: TLV type (IANA assigned).
Length: The length (in octets) of TLV. The value of this field
MUST be 1 as there is no Capability-specific data [RFC5561] that
follows in the TLV.
S-bit: Set to 1 to announce and 0 to withdraw the capability (as
per [RFC5561].
An mLDP speaker that has successfully advertised and negotiated "MT
Multipoint" capability MUST support the following:
1. Topology-scoped mLDP FECs in LDP messages (Section 4.1)
2. Topology-scoped mLDP forwarding setup (Section 7)
6. MT Applicability on FEC-based features
6.1. Typed Wildcard MP FEC Elements
[RFC5918] extends base LDP and defines Typed Wildcard FEC Element
framework. Typed Wildcard FEC element can be used in any LDP message
to specify a wildcard operation for a given type of FEC.
The MT extensions proposed in document do not require any extension
in procedures for Typed Wildcard FEC Element support [RFC5918], and
Wijnands, et al. Expires September 6, 2018 [Page 8]
Internet-Draft Multi-Topology mLDP March 2018
these procedures apply as-is to Multipoint MT FEC wildcarding. Like
Typed Wildcard MT Prefix FEC Element, as defined in [RFC7307], the MT
extensions allow use of "MT IP" or "MT IPv6" in the Address Family
field of the Typed Wildcard MP FEC element in order to use wildcard
operations for MP FECs in the context of a given (sub)-topology as
identified by the MT-ID and IPA field.
This document proposes following format and encoding for a Typed
Wildcard MP FEC element:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Typed Wcard (5)| Type = MP FEC | Len = 6 | AF = MT IP ..|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|... or MT IPv6 | Reserved | IPA | MT-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|MT ID (contd.) |
+-+-+-+-+-+-+-+-+
Figure 5: Typed Wildcard MT MP FEC Element
Where:
Type: One of MP FEC Element type (P2MP, MP2MPup, MP2MP-down).
MT ID: MPLS MT ID
IPA: The IGP Algorithm, values are from the IGP Algorithm
registry.
The proposed format allows an LSR to perform wildcard MP FEC
operations under the scope of a (sub-)topology.
6.2. End-of-LIB
[RFC5919] specifies extensions and procedures that allows an LDP
speaker to signal its End-of-LIB (i.e. convergence) for a given FEC
type towards a peer. MT extensions for MP FEC do not require any
change in these procedures and they apply as-is to MT MP FEC
elements. This means that an MT mLDP speaker MAY signal its
convergence per (sub-)topology using MT Typed Wildcard MP FEC
element.
Wijnands, et al. Expires September 6, 2018 [Page 9]
Internet-Draft Multi-Topology mLDP March 2018
7. Topology-Scoped Signaling and Forwarding
Since the {MT-ID, IPA} tuple is part of an mLDP FEC, there is no need
to support the concept of multiple (sub-)topology forwarding tables
in mLDP. Each MP LSP will be unique due to the tuple being part of
the FEC. There is also no need to have specific label forwarding
tables per topology, and each MP LSP will have its own unique local
label in the table. However, In order to implement MTR in an mLDP
network, the selection procedures for upstream LSR and downstream
forwarding interface need be changed.
7.1. Upstream LSR selection
The procedures as described in RFC-6388 section-2.4.1.1 depend on the
best path to reach the root. When the {MT-ID, IPA} tuple is signaled
as part of the FEC, this tuple is used to select the (sub-)topology
that must be used to find the best path to the root address. Using
the next-hop from this best path, a LDP peer is selected following
the procedures as defined in [RFC6388].
7.2. Downstream forwarding interface selection
The procedures as described in RFC-6388 section-2.4.1.2 describe how
a downstream forwarding interface is selected. In these procedures,
any interface leading to the downstream LDP neighbor can be
considered as candidate forwarding interface. When the {MT-ID, IPA}
tuple is part of the FEC, this is no longer true. An interface must
only be selected if it is part of the same (sub-)topology that was
signaled in the mLDP FEC element. Besides this restriction, the
other procedures in [RFC6388] apply.
8. LSP Ping Extensions
[RFC6425] defines procedures to detect data plane failures in
Multipoint MPLS LSPs. Section 3.1.2 of [RFC6425] defines new Sub-
Types and Sub-TLVs for Multipoint LDP FECs to be sent in "Target FEC
Stack" TLV of an MPLS echo request message [RFC4379].
To support LSP ping for MT Multipoint LSPs, this document uses
existing sub-types "P2MP LDP FEC Stack" and "MP2MP LDP FEC Stack"
defined in [RFC6425]. The proposed extension is to specify "MT IP"
or "MT IPv6" in the "Address Family" field, set the "Address Length"
field to 8 (for MT IP) or 20 (for MT IPv6), and encode the sub-TLV
with additional {MT-ID, IPA} information as an extension to the "Root
LSR Address" field. The resultant format of sub-tlv is as follows:
Wijnands, et al. Expires September 6, 2018 [Page 10]
Internet-Draft Multi-Topology mLDP March 2018
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Address Family (MT IP/MT IPv6) | Address Length| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
~ Root LSR Address (Cont.) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | IPA | MT-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Opaque Length | Opaque Value ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
~ ~
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: Multipoint LDP FEC Stack Sub-TLV Format for MT
The rules and procedures of using this new sub-TLV in an MPLS echo
request message are same as defined for P2MP/MP2MP LDP FEC Stack Sub-
TLV in [RFC6425] with only difference being that Root LSR address is
now (sub-)topology scoped.
9. Security Considerations
This extension to mLDP does not introduce any new security
considerations beyond that already apply to the base LDP
specification [RFC5036], base mLDP specification [RFC6388], and MPLS
security framework [RFC5920].
10. IANA Considerations
This document defines a new LDP capability parameter TLV. IANA is
requested to assign the lowest available value after 0x0500 from "TLV
Type Name Space" in the "Label Distribution Protocol (LDP)
Parameters" registry within "Label Distribution Protocol (LDP) Name
Spaces" as the new code point for the LDP TLV code point.
Wijnands, et al. Expires September 6, 2018 [Page 11]
Internet-Draft Multi-Topology mLDP March 2018
+-----+------------------+---------------+-------------------------+
|Value| Description | Reference | Notes/Registration Date |
+-----+------------------+---------------+-------------------------+
| TBA | MT Multipoint | This document | |
| | Capability | | |
+-----+------------------+---------------+-------------------------+
Figure 7: IANA Code Point
11. Acknowledgments
The authors would like to acknowledge Eric Rosen for his input on
this specification.
12. References
12.1. Normative References
[I-D.hegdeppsenak-isis-sr-flex-algo]
Psenak, P., Hegde, S., Filsfils, C., and A. Gulko, "ISIS
Segment Routing Flexible Algorithm", draft-hegdeppsenak-
isis-sr-flex-algo-02 (work in progress), February 2018.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://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,
<https://www.rfc-editor.org/info/rfc4379>.
[RFC4915] Psenak, P., Mirtorabi, S., Roy, A., Nguyen, L., and P.
Pillay-Esnault, "Multi-Topology (MT) Routing in OSPF",
RFC 4915, DOI 10.17487/RFC4915, June 2007,
<https://www.rfc-editor.org/info/rfc4915>.
[RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi
Topology (MT) Routing in Intermediate System to
Intermediate Systems (IS-ISs)", RFC 5120,
DOI 10.17487/RFC5120, February 2008,
<https://www.rfc-editor.org/info/rfc5120>.
Wijnands, et al. Expires September 6, 2018 [Page 12]
Internet-Draft Multi-Topology mLDP March 2018
[RFC6388] Wijnands, IJ., Ed., Minei, I., Ed., Kompella, K., and B.
Thomas, "Label Distribution Protocol Extensions for Point-
to-Multipoint and Multipoint-to-Multipoint Label Switched
Paths", RFC 6388, DOI 10.17487/RFC6388, November 2011,
<https://www.rfc-editor.org/info/rfc6388>.
[RFC6425] Saxena, S., Ed., Swallow, G., Ali, Z., Farrel, A.,
Yasukawa, S., and T. Nadeau, "Detecting Data-Plane
Failures in Point-to-Multipoint MPLS - Extensions to LSP
Ping", RFC 6425, DOI 10.17487/RFC6425, November 2011,
<https://www.rfc-editor.org/info/rfc6425>.
[RFC7307] Zhao, Q., Raza, K., Zhou, C., Fang, L., Li, L., and D.
King, "LDP Extensions for Multi-Topology", RFC 7307,
DOI 10.17487/RFC7307, July 2014,
<https://www.rfc-editor.org/info/rfc7307>.
12.2. Informative References
[RFC5036] Andersson, L., Ed., Minei, I., Ed., and B. Thomas, Ed.,
"LDP Specification", RFC 5036, DOI 10.17487/RFC5036,
October 2007, <https://www.rfc-editor.org/info/rfc5036>.
[RFC5561] Thomas, B., Raza, K., Aggarwal, S., Aggarwal, R., and JL.
Le Roux, "LDP Capabilities", RFC 5561,
DOI 10.17487/RFC5561, July 2009,
<https://www.rfc-editor.org/info/rfc5561>.
[RFC5918] Asati, R., Minei, I., and B. Thomas, "Label Distribution
Protocol (LDP) 'Typed Wildcard' Forward Equivalence Class
(FEC)", RFC 5918, DOI 10.17487/RFC5918, August 2010,
<https://www.rfc-editor.org/info/rfc5918>.
[RFC5919] Asati, R., Mohapatra, P., Chen, E., and B. Thomas,
"Signaling LDP Label Advertisement Completion", RFC 5919,
DOI 10.17487/RFC5919, August 2010,
<https://www.rfc-editor.org/info/rfc5919>.
[RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS
Networks", RFC 5920, DOI 10.17487/RFC5920, July 2010,
<https://www.rfc-editor.org/info/rfc5920>.
Authors' Addresses
Wijnands, et al. Expires September 6, 2018 [Page 13]
Internet-Draft Multi-Topology mLDP March 2018
IJsbrand Wijnands
Cisco Systems, Inc.
De kleetlaan 6a
Diegem 1831
Belgium
Email: ice@cisco.com
Kamran Raza
Cisco Systems, Inc.
2000 Innovation Drive
Kanata, ON K2K-3E8
Canada
Email: skraza@cisco.com
Zhaohui Zhang
Juniper Networks
10 Technology Park Dr.
Westford MA 01886
US
Email: zzhang@juniper.net
Arkadiy Gulko
Thomson Reuters
195 Broadway
New York NY 10007
USA
Email: arkadiy.gulko@thomsonreuters.com
Wijnands, et al. Expires September 6, 2018 [Page 14]