rfc9658.original   rfc9658.txt 
MPLS Working Group IJ. Wijnands Internet Engineering Task Force (IETF) IJ. Wijnands
Internet-Draft Individual Request for Comments: 9658 Individual
Updates: 7307 (if approved) M. Mishra (Editor) Updates: 7307 M. Mishra, Ed.
Intended status: Standards Track K. Raza Category: Standards Track K. Raza
Expires: 21 November 2024 Cisco Systems, Inc. ISSN: 2070-1721 Cisco Systems, Inc.
Z. Zhang Z. Zhang
Juniper Networks Juniper Networks
A. Gulko A. Gulko
Edward Jones wealth management Edward Jones
20 May 2024 October 2024
mLDP Extensions for Multi-Topology Routing Multipoint LDP Extensions for Multi-Topology Routing
draft-ietf-mpls-mldp-multi-topology-09
Abstract Abstract
Multi-Topology Routing (MTR) is a technology to enable service Multi-Topology Routing (MTR) is a technology that enables service
differentiation within an IP network. Flexible Algorithm (FA) is differentiation within an IP network. The Flexible Algorithm (FA) is
another mechanism of creating a sub-topology within a topology using another mechanism for creating a sub-topology within a topology using
defined topology constraints and computation algorithm. In order to defined topology constraints and computation algorithms. In order to
deploy mLDP (Multipoint label distribution protocol) in a network deploy Multipoint LDP (mLDP) in a network that supports MTR, FA, or
that supports MTR, FA, or other methods of signaling non-default IGP other methods of signaling non-default IGP Algorithms (IPAs), mLDP is
algorithms, mLDP is required to become topology and algorithm aware. required to become topology and algorithm aware. This document
This document specifies extensions to mLDP to support MTR, with an specifies extensions to mLDP to support the use of MTR/IPAs such
algorithm, in order for Multipoint LSPs(Label Switched Paths) to that, when building multipoint Label Switched Paths (LSPs), the LSPs
follow a particular topology and algorithm. It updates [RFC7307] by can follow a particular topology and algorithm. This document
allocating eight bits from a previously reserved field to be used as updates RFC 7307 by allocating eight bits from a previously reserved
the IGP Algorithm (IPA) field. field to be used as the "IPA" field.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This is an Internet Standards Track document.
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 This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 7841.
This Internet-Draft will expire on 21 November 2024. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
https://www.rfc-editor.org/info/rfc9658.
Copyright Notice Copyright Notice
Copyright (c) 2024 IETF Trust and the persons identified as the Copyright (c) 2024 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 (https://trustee.ietf.org/ Provisions Relating to IETF Documents
license-info) in effect on the date of publication of this document. (https://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. Code Components carefully, as they describe your rights and restrictions with respect
extracted from this document must include Revised BSD License text as to this document. Code Components extracted from this document must
described in Section 4.e of the Trust Legal Provisions and are include Revised BSD License text as described in Section 4.e of the
provided without warranty as described in the Revised BSD License. Trust Legal Provisions and are provided without warranty as described
in the Revised BSD License.
Table of Contents Table of Contents
1. Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology
3. Specification of Requirements . . . . . . . . . . . . . . . . 4 2.1. Abbreviations
4. MT Scoped mLDP FECs . . . . . . . . . . . . . . . . . . . . . 4 2.2. Specification of Requirements
4.1. MP FEC Extensions for MT . . . . . . . . . . . . . . . . 5 3. MT-Scoped mLDP FECs
4.1.1. MP FEC Element . . . . . . . . . . . . . . . . . . . 5 3.1. MP FEC Extensions for MT
4.1.2. MT IP Address Families . . . . . . . . . . . . . . . 6 3.1.1. MP FEC Element
4.1.3. MT MP FEC Element . . . . . . . . . . . . . . . . . . 6 3.1.2. MT IP Address Families
4.2. Topology IDs . . . . . . . . . . . . . . . . . . . . . . 7 3.1.3. MT MP FEC Element
5. MT Multipoint Capability . . . . . . . . . . . . . . . . . . 8 3.2. Topology IDs
6. MT Applicability on FEC-based features . . . . . . . . . . . 9 4. MT Multipoint Capability
6.1. Typed Wildcard MP FEC Elements . . . . . . . . . . . . . 9 5. MT Applicability on FEC-Based Features
6.2. End-of-LIB . . . . . . . . . . . . . . . . . . . . . . . 10 5.1. Typed Wildcard MP FEC Elements
7. Topology-Scoped Signaling and Forwarding . . . . . . . . . . 10 5.2. End-of-LIB
7.1. Upstream LSR selection . . . . . . . . . . . . . . . . . 10 6. Topology-Scoped Signaling and Forwarding
7.2. Downstream forwarding interface selection . . . . . . . . 10 6.1. Upstream LSR Selection
8. LSP Ping Extensions . . . . . . . . . . . . . . . . . . . . . 11 6.2. Downstream Forwarding Interface Selection
9. Implementation Status . . . . . . . . . . . . . . . . . . . . 11 7. LSP Ping Extensions
9.1. Cisco Systems . . . . . . . . . . . . . . . . . . . . . . 12 8. Security Considerations
10. Security Considerations . . . . . . . . . . . . . . . . . . . 12 9. IANA Considerations
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 10. References
12. Contributor . . . . . . . . . . . . . . . . . . . . . . . . . 13 10.1. Normative References
13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13 10.2. Informative References
14. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 Contributors
14.1. Normative References . . . . . . . . . . . . . . . . . . 13 Acknowledgments
14.2. Informative References . . . . . . . . . . . . . . . . . 14 Authors' Addresses
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15
1. Glossary 1. Introduction
FA - Flexible Algorithm Multi-Topology Routing (MTR) is a technology that enables service
FEC - Forwarding Equivalence Class differentiation within an IP network. IGPs (e.g., OSPF and IS-IS)
and LDP have already been extended to support MTR. To support MTR,
an IGP maintains distinct IP topologies referred to as "Multi-
Topologies" (or "MTs"), and computes and installs routes specific to
each topology. OSPF extensions (see [RFC4915]) and IS-IS extensions
(see [RFC5120]) specify the MT extensions under respective IGPs. To
support IGP MT, similar LDP extensions (see [RFC7307]) have been
specified to make LDP be MT aware and to be able to set up unicast
Label Switched Paths (LSPs) along IGP MT routing paths.
IGP - Interior Gateway Protocol A more lightweight mechanism to define constraint-based topologies is
the Flexible Algorithm (FA) (see [RFC9350]). The FA is another
mechanism for creating a sub-topology within a topology using defined
topology constraints and computation algorithms. This can be done
within an MTR topology or the default topology. An instance of such
a sub-topology is identified by a 1-octet value (Flexible Algorithm)
as documented in [RFC9350]. At the time of writing, an FA is a
mechanism to create a sub-topology; in the future, different
algorithms might be defined for this purpose. Therefore, in the
remainder of this document, we'll refer to this as the "IGP
Algorithm" or "IPA". The "IPA" field (see Sections 3.1.2 and 5.1) is
an 8-bit identifier for the algorithm. The permissible values are
tracked in the "IGP Algorithm Types" registry [IANA-IGP-ALGO-TYPES].
IPA - IGP Algorithm Throughout this document, the term "Flexible Algorithm" (or "FA")
shall denote the process of generating a sub-topology and signaling
it through the IGP. However, it is essential to note that the
procedures outlined in this document are not exclusively applicable
to the FA: they are extendable to any non-default algorithm as well.
LDP - Label Distribution Protocol "Multipoint LDP" (or "mLDP") refers to extensions in LDP to set up
multipoint LSPs (i.e., point-to-multipoint (P2MP) or multipoint-to-
multipoint (MP2MP) LSPs) by means of a set of extensions and
procedures defined in [RFC6388]. In order to deploy mLDP in a
network that supports MTR and the FA, mLDP is required to become
topology and algorithm aware. This document specifies extensions to
mLDP to support the use of MTR/IPAs such that, when building
multipoint LSPs, it can follow a particular topology and algorithm.
Therefore, the identifier for the particular topology to be used by
mLDP has to become a 2-tuple {MTR Topology Id, IPA}.
LSP - Label Switched Path 2. Terminology
mLDP - Multipoint LDP 2.1. Abbreviations
MP - Multipoint (P2MP or MP2MP) FA: Flexible Algorithm
MP2MP - Multipoint-to-Multipoint FEC: Forwarding Equivalence Class
MT - Multi-Topology IGP: Interior Gateway Protocol
MT-ID - Multi-Topology Identifier IPA: IGP Algorithm
MTR - Multi-Topology Routing LDP: Label Distribution Protocol
MVPN - Multicast over Virtual Private Network defined in section LSP: Label Switched Path
2.3 of [RFC6513]
P2MP - Point-to-Multipoint mLDP: Multipoint LDP
PMSI - Provider Multicast Service Interfaces [RFC6513] MP: Multipoint
2. Introduction MP2MP: Multipoint-to-Multipoint
Multi-Topology Routing (MTR) is a technology to enable service MT: Multi-Topology
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 IS-IS 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 lightweight mechanism to define constraint-based topologies is MT-ID: Multi-Topology Identifier
the Flexible Algorithm (FA) [RFC9350]. FA can be seen as creating a
sub-topology within a topology using defined topology constraints and
computation algorithms. This can be done within an MTR topology or
the default Topology. An instance of such a sub-topology is
identified by a 1 octet value (Flex-Algorithm) as documented in
[RFC9350]. A flexible Algorithm is a mechanism to create a sub- MTR: Multi-Topology Routing
topology, but in the future, different algorithms might be defined
for how to achieve that. For that reason, in the remainder of this
document, we'll refer to this as the IGP Algorithm. The IGP
Algorithm (IPA) Field Section 4.1.2 Section 6.1 is an 8-bit
identifier for the algorithm. The permissible values are tracked in
the IANA IGP Algorithm Types registry [IANA-IGP-ALGO-TYPES].
Throughout this document, the term Flexible Algorithm (FA) shall MVPN: Multicast VPN in Section 2.3 of [RFC6513]
denote the process of generating a sub-topology and signaling it
through Interior Gateway Protocol (IGP). However, it is essential to
note that the procedures outlined in this document are not
exclusively applicable to Flexible Algorithm but are extendable to
any non-default algorithm as well.
Multipoint LDP (mLDP) refers to extensions in LDP to setup multi- P2MP: Point-to-Multipoint
point LSPs (point-to-multipoint (P2MP) or multipoint-to-multipoint
(MP2MP)), by means of a 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/IGP
Algorithm such that when building a Multi-Point LSPs it can follow a
particular topology and algorithm. This means that the identifier
for the particular topology to be used by mLDP have to become a
2-tuple (MTR Topology Id, IGP Algorithm).
3. Specification of Requirements PMSI: Provider Multicast Service Interfaces [RFC6513]
2.2. Specification of Requirements
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in
14 [RFC2119] [RFC8174] when, and only when, they appear in all BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
4. MT Scoped mLDP FECs 3. MT-Scoped mLDP FECs
As defined in [RFC7307], MPLS Multi-Topology Identifier (MT-ID) is an As defined in [RFC7307], an MPLS Multi-Topology Identifier (MT-ID) is
identifier that is used to associate an LSP with a certain MTR used to associate an LSP with a certain MTR topology. In the context
topology. In the context of MP LSPs, this identifier is part of the of MP LSPs, this identifier is part of the mLDP FEC encoding; this is
mLDP FEC encoding so that LDP peers are able to setup an MP LSP via so that LDP peers are able to set up an MP LSP via their own defined
their own defined MTR policy. In order to avoid conflicting MTR MTR policy. In order to avoid conflicting MTR policies for the same
policies for the same mLDP FEC, the MT-ID needs to be a part of the mLDP FEC, the MT-ID needs to be a part of the FEC. This ensures that
FEC, so that different MT-ID values will result in unique MP-LSP FEC different MT-ID values will result in unique MP-LSP FEC elements.
elements.
The same applies to the IGP Algorithm. The IGP Algorithm needs to be The same applies to the IPA. The IPA needs to be encoded as part of
encoded as part of the mLDP FEC to create unique MP-LSPs. The IGP the mLDP FEC to create unique MP LSPs. The IPA is also used to
Algorithm is also used to signal to mLDP (hop-by-hop) which Algorithm signal to the mLDP (hop-by-hop) which algorithm needs to be used to
needs to be used to create the MP-LSP. create the MP LSP.
Since the MT-ID and IGP Algorithm are part of the FEC, they apply to Since the MT-ID and IPA are part of the FEC, they apply to all the
all the LDP messages that potentially include an mLDP FEC element. LDP messages that potentially include an mLDP FEC element.
4.1. MP FEC Extensions for MT 3.1. MP FEC Extensions for MT
The following subsections define the extensions to bind an mLDP FEC The following subsections define the extensions to bind an mLDP FEC
to a topology. These mLDP MT extensions reuse some of the extensions to a topology. These mLDP MT extensions reuse some of the extensions
specified in [RFC7307]. specified in [RFC7307].
4.1.1. MP FEC Element 3.1.1. MP FEC Element
Base mLDP specification [RFC6388] defines MP FEC Element as follows: The base mLDP specification ([RFC6388]) defines the MP FEC element as
follows:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MP FEC type | Address Family | AF Length | | MP FEC type | Address Family | AF Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Root Node Address | | Root Node Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Opaque Length | Opaque Value | | Opaque Length | Opaque Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
~ ~ ~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: MP FEC Element Format [RFC6388] Figure 1: MP FEC Element Format
Where the "Root Node Address" encoding is defined according to the Where the "Root Node Address" field encoding is defined according to
given "Address Family" with its length (in octets) specified by the the given "Address Family" field with its length (in octets)
"AF Length" field. specified by the "AF Length" field.
To extend MP FEC elements for MT, the {MT-ID, IPA} tuple is relevant To extend MP FEC elements for MT, the {MT-ID, IPA} tuple is relevant
in the context of the root address of the MP LSP. This tuple in the context of the root address of the MP LSP. This tuple
determines the (sub)-topology in which the root address needs to be determines the (sub-)topology in which the root address needs to be
resolved. As the {MT-ID, IPA} tuple should be considered part of the resolved. As the {MT-ID, IPA} tuple should be considered part of the
mLDP FEC, it is most naturally encoded as part of the root address. mLDP FEC, it is most naturally encoded as part of the root address.
4.1.2. MT IP Address Families 3.1.2. MT IP Address Families
[RFC7307] specifies new address families, named "MT IP" and "MT [RFC7307] specifies new address families, named "MT IP" and "MT
IPv6," to allow for the specification of an IP prefix within a IPv6," to allow for the specification of an IP prefix within a
topology scope. In addition to using these address families for topology scope. In addition to using these address families for
mLDP, 8 bits of the 16-bit Reserved field are utilized to encode the mLDP, 8 bits of the 16-bit "Reserved" field that was described in RFC
IGP Algorithm. The resulting format of the data associated with 7307 are utilized to encode the IPA. The resulting format of the
these new Address Families is as follows: data associated with these new address families is as follows:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 Address | | IPv4 Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | IPA | MT-ID | | Reserved | IPA | MT-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 Address | | IPv6 Address |
| | | |
| | | |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | IPA | MT-ID | | Reserved | IPA | MT-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Modified MT IP Address Families Data Format Figure 2: Modified Format for MT IP Address Families
Where: Where:
IPv4/IPv6 Address: An IP address corresponding to "MT IP" and "MT IPv4 Address and IPv6 Address: An IP address corresponding to the
IPv6" address families respectively. "MT IP" and "MT IPv6" address families, respectively.
IPA: The IGP Algorithm. IPA: The IGP Algorithm.
Reserved: This 8-bit field MUST be zero on transmission and MUST Reserved: This 8-bit field MUST be zero on transmission and MUST be
be ignored on receipt. ignored on receipt.
4.1.3. MT MP FEC Element 3.1.3. MT MP FEC Element
By using the extended MT IP Address Family, the resulting MT MP FEC When using the extended "MT IP" address family, the resulting MT-
element should be encoded as follows: Scoped MP FEC element should be encoded as follows:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MP FEC type | AF (MT IP/ MT IPv6) | AF Length | | MP FEC type | AF (MT IP/ MT IPv6) | AF Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Root Node Address | | Root Node Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | IPA | MT-ID | | Reserved | IPA | MT-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Opaque Length | Opaque Value | | Opaque Length | Opaque Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
~ ~ ~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: IP MT-Scoped MP FEC Element Format Figure 3: Format for an IP MT-Scoped MP FEC Element
In the context of this document, the applicable LDP FECs for MT mLDP In the context of this document, the applicable LDP FECs for MT mLDP
([RFC6388]) include: ([RFC6388]) include:
* MP FEC Elements: * MP FEC elements:
- P2MP (type 0x6) - P2MP (type 0x6)
- MP2MP-up (type 0x7) - MP2MP-up (type 0x7)
- MP2MP-down (type 0x8) - MP2MP-down (type 0x8)
* Typed Wildcard FEC Element (type 0x5 defined in [RFC5918] ) * Typed Wildcard FEC Element (type 0x5 defined in [RFC5918])
In case of "Typed Wildcard FEC Element", the FEC Element type MUST be In the case of the Typed Wildcard FEC Element, the FEC element type
one of the MP FECs listed above. MUST be one of the MP FECs listed above.
This specification allows the use of Topology-scoped mLDP FECs in LDP This specification allows the use of topology-scoped mLDP FECs in LDP
label and notification messages, as applicable. labels and notification messages, as applicable.
[RFC6514] defines the PMSI tunnel attribute for MVPN, and specifies [RFC6514] defines the PMSI tunnel attribute for MVPN and specifies
that when the Tunnel Type is set to mLDP P2MP LSP, the Tunnel that:
Identifier is a P2MP FEC Element, and when the Tunnel Type is set to
mLDP Multipoint-to-Multipoint (MP2MP) LSP, the Tunnel Identifier is
an MP2MP FEC Element. When the extension defined in this
specification is in use, the "IP MT-Scoped MP FEC Element Format"
form of the respective FEC elements MUST be used in these two cases.
4.2. Topology IDs * when the Tunnel Type is set to mLDP P2MP LSP, the Tunnel
Identifier is a P2MP FEC element, and
* when the Tunnel Type is set to mLDP MP2MP LSP, the Tunnel
Identifier is an MP2MP FEC element.
When the extension defined in this specification is in use, the IP
MT-Scoped MP FEC element form of the respective FEC elements MUST be
used in these two cases.
3.2. Topology IDs
This document assumes the same definitions and procedures associated This document assumes the same definitions and procedures associated
with MPLS MT-ID as specified in [RFC7307] specification. with MPLS MT-ID as specified in [RFC7307].
5. MT Multipoint Capability 4. MT Multipoint Capability
The "MT Multipoint Capability" is a new LDP capability, defined in The "MT Multipoint" capability is a new LDP capability, defined in
accordance with the LDP Capability definition guidelines outlined in accordance with the LDP capability definition guidelines outlined in
[RFC5561]. An mLDP speaker advertises this capability to its peers [RFC5561]. An mLDP speaker advertises this capability to its peers
to announce its support for MTR and the procedures specified in this to announce its support for MTR and the procedures specified in this
document. This capability MAY be sent either in an Initialization document. This capability MAY be sent either in an Initialization
message at session establishment or dynamically during the session's message at session establishment or dynamically during the session's
lifetime via a Capability message, provided that the "Dynamic lifetime via a Capability message, provided that the "Dynamic
Announcement" capability from [RFC5561] has been successfully Announcement" capability from [RFC5561] has been successfully
negotiated with the peer. negotiated with the peer.
The format of this capability is as follows: The format of this capability is as follows:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U|F| MT Multipoint Capability | Length | |U|F| MT Multipoint Capability | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|S| Reserved | |S| Reserved |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
Figure 4: MT Multipoint Capability TLV Format Figure 4: Format for the MT Multipoint Capability TLV
Where: Where:
U- and F-bits: MUST be 1 and 0, respectively, as per Section 3 of U and F bits: MUST be 1 and 0, respectively, as per Section 3 of
LDP Capabilities [RFC5561]. [RFC5561].
MT Multipoint Capability: TLV type. MT Multipoint Capability: The TLV type.
Length: The length (in octets) of TLV. The value of this field Length: This field specifies the length of the TLV in octets. The
MUST be 1 as there is no Capability-specific data [RFC5561] that value of this field MUST be 1, as there is no capability-specific
follows in the TLV. Length: This field specifies the length of data [RFC5561] following the TLV.
the TLV in octets. The value of this field MUST be 1, as there is
no Capability-specific data [[RFC5561]] following the TLV.
S-bit: Set to 1 to announce and 0 to withdraw the capability (as S bit: Set to 1 to announce and 0 to withdraw the capability (as per
per [RFC5561]. [RFC5561]).
An mLDP speaker that has successfully advertised and negotiated "MT An mLDP speaker that has successfully advertised and negotiated the
Multipoint" capability MUST support the following: "MT Multipoint" capability MUST support the following:
1. Topology-scoped mLDP FECs in LDP messages (Section 4.1) 1. Topology-scoped mLDP FECs in LDP messages (Section 3.1)
2. Topology-scoped mLDP forwarding setup (Section 7) 2. Topology-scoped mLDP forwarding setup (Section 6)
6. MT Applicability on FEC-based features 5. MT Applicability on FEC-Based Features
6.1. Typed Wildcard MP FEC Elements 5.1. Typed Wildcard MP FEC Elements
[RFC5918] extends base LDP and defines Typed Wildcard FEC Element [RFC5918] extends the base LDP and defines the Typed Wildcard FEC
framework. Typed Wildcard FEC element can be used in any LDP message Element framework. A Typed Wildcard FEC Element can be used in any
to specify a wildcard operation for a given type of FEC. LDP message to specify a wildcard operation for a given type of FEC.
The MT extensions, defined in this document, do not require any The MT extensions defined in this document do not require any
extension to procedures for Typed Wildcard FEC Element support extension to procedures for support of the Typed Wildcard FEC Element
[RFC5918], and these procedures apply as-is to Multipoint MT FEC [RFC5918], and these procedures apply as is to Multipoint MT FEC
wildcarding. Similar to Typed Wildcard MT Prefix FEC Element, as wildcarding. Similar to the Typed Wildcard MT Prefix FEC element, as
defined in [RFC7307], the MT extensions allow the use of "MT IP" or defined in [RFC7307], the MT extensions allow the use of "MT IP" or
"MT IPv6" in the Address Family field of the Typed Wildcard MP FEC "MT IPv6" in the "Address Family" field of the Typed Wildcard MP FEC
element. This is done in order to use wildcard operations for MP Element. This is done in order to use wildcard operations for MP
FECs in the context of a given (sub)-topology as identified by the FECs in the context of a given (sub-)topology as identified by the
MT-ID and IPA field. "MT-ID" and "IPA" fields.
This document defines the following format and encoding for a Typed This document defines the following format and encoding for a Typed
Wildcard MP FEC element: Wildcard MP FEC Element:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Typed Wcard (5)| Type = MP FEC | Len = 6 | AF = MT IP ..| |Typed Wcard (5)| Type = MP FEC | Len = 6 | AF = MT IP ..|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|... or MT IPv6 | Reserved | IPA | MT-ID | |... or MT IPv6 | Reserved | IPA | MT-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|MT ID (contd.) | |MT-ID (cont.) |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
Figure 5: Typed Wildcard MT MP FEC Element Figure 5: Format for the Typed Wildcard MT MP FEC Element
Where: Where:
Type: One of MP FEC Element type (P2MP, MP2MPup, MP2MP-down). Type: One of the MP FEC element types (P2MP, MP2MP-up, or MP2MP-
down)
MT ID: MPLS MT ID MT-ID: MPLS MT-ID
IPA: The IGP Algorithm IPA: The IGP Algorithm
The defined format allows an LSR to perform wildcard MP FEC The defined format allows a Label Switching Router (LSR) to perform
operations under the scope of a (sub-)topology. wildcard MP FEC operations under the scope of a (sub-)topology.
6.2. End-of-LIB 5.2. End-of-LIB
[RFC5919] specifies extensions and procedures that allow an LDP [RFC5919] specifies extensions and procedures that allow an LDP
speaker to signal its End-of-LIB for a given FEC type to a peer. By speaker to signal its End-of-LIB (Label Information Base) for a given
leveraging the End-of-LIB message, LDP ensures that label FEC type to a peer. By leveraging the End-of-LIB message, LDP
distribution remains consistent and reliable, even during network ensures that label distribution remains consistent and reliable, even
disruptions or maintenance activities. The MT extensions for MP FEC during network disruptions or maintenance activities. The MT
do not require any modifications to these procedures and apply as-is extensions for MP FEC do not require any modifications to these
to MT MP FEC elements. Consequently, an MT mLDP speaker MAY signal procedures and apply as they are to MT MP FEC elements.
its convergence per (sub-)topology using the MT Typed Wildcard MP FEC Consequently, an MT mLDP speaker MAY signal its convergence per
element. (sub-)topology using the MT Typed Wildcard MP FEC Element.
7. Topology-Scoped Signaling and Forwarding 6. Topology-Scoped Signaling and Forwarding
Since the {MT-ID, IPA} tuple is part of an mLDP FEC, there is no need 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 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 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 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 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 label in the table. However, in order to implement MTR in an mLDP
network, the selection procedures for upstream LSR and downstream network, the selection procedures for an upstream LSR and a
forwarding interface need to be changed. downstream forwarding interface need to be changed.
7.1. Upstream LSR selection 6.1. Upstream LSR Selection
The procedures as described in RFC-6388 section-2.4.1.1 depend on the The procedures described in Section 2.4.1.1 of [RFC6388] depend on
best path to reach the root. When the {MT-ID, IPA} tuple is signaled the best path to reach the root. When the {MT-ID, IPA} tuple is
as part of the FEC, this tuple is used to select the (sub-)topology signaled as part of the FEC, the tuple is also used to select the
that must be used to find the best path to the root address. Using (sub-)topology that must be used to find the best path to the root
the next-hop from this best path, a LDP peer is selected following address. Using the next-hop from this best path, an LDP peer is
the procedures as defined in [RFC6388]. selected following the procedures defined in [RFC6388].
7.2. Downstream forwarding interface selection 6.2. Downstream Forwarding Interface Selection
The procedures as described in RFC-6388 section-2.4.1.2 describe how Section 2.4.1.2 of [RFC6388] describes the procedures for how a
a downstream forwarding interface is selected. In these procedures, downstream forwarding interface is selected. In these procedures,
any interface leading to the downstream LDP neighbor can be any interface leading to the downstream LDP neighbor can be
considered as candidate forwarding interface. When the {MT-ID, IPA} considered to be a candidate forwarding interface. When the {MT-ID,
tuple is part of the FEC, this is no longer true. An interface must IPA} tuple is part of the FEC, this is no longer true. An interface
only be selected if it is part of the same (sub-)topology that was must only be selected if it is part of the same (sub-)topology that
signaled in the mLDP FEC element. Besides this restriction, the was signaled in the mLDP FEC element. Besides this restriction, the
other procedures in [RFC6388] apply. other procedures in [RFC6388] apply.
8. LSP Ping Extensions 7. LSP Ping Extensions
[RFC6425] defines procedures to detect data plane failures in [RFC6425] defines procedures to detect data plane failures in
Multipoint MPLS LSPs. Section 3.1.2 of [RFC6425] defines new Sub- 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 types and sub-TLVs for Multipoint LDP FECs to be sent in the "Target
Stack" TLV of an MPLS echo request message [RFC8029]. FEC Stack" TLV of an MPLS Echo Request message [RFC8029].
To support LSP ping for MT Multipoint LSPs, this document uses To support LSP ping for MT MP LSPs, this document uses existing sub-
existing sub-types "P2MP LDP FEC Stack" and "MP2MP LDP FEC Stack" types "P2MP LDP FEC Stack" and "MP2MP LDP FEC Stack" defined in
defined in [RFC6425]. The LSP Ping extension is to specify "MT IP" [RFC6425]. The LSP ping extension is to specify "MT IP" or "MT IPv6"
or "MT IPv6" in the "Address Family" field, set the "Address Length" in the "Address Family" field, set the "Address Length" field to 8
field to 8 (for MT IP) or 20 (for MT IPv6), and encode the sub-TLV (for MT IP) or 20 (for MT IPv6), and encode the sub-TLV with
with additional {MT-ID, IPA} information as an extension to the "Root additional {MT-ID, IPA} information as an extension to the "Root LSR
LSR Address" field. The resultant format of sub-tlv is as follows: Address" field. The resultant format of sub-TLV is as follows:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Address Family (MT IP/MT IPv6) | Address Length| | |Address Family (MT IP/MT IPv6) | Address Length| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
~ Root LSR Address (Cont.) ~ ~ Root LSR Address (Cont.) ~
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | IPA | MT-ID | | Reserved | IPA | MT-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Opaque Length | Opaque Value ... | | Opaque Length | Opaque Value ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
~ ~ ~ ~
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: Multipoint LDP FEC Stack Sub-TLV Format for MT 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 The rules and procedures of using this new sub-TLV in an MPLS Echo
request message are the same as defined for P2MP/MP2MP LDP FEC Stack Request message are the same as defined for the P2MP/MP2MP LDP FEC
Sub-TLV in [RFC6425]. The only difference is that the Root LSR Stack sub-TLV in [RFC6425]. The only difference is that the "Root
address is now (sub-)topology scoped. LSR Address" field is now (sub-)topology scoped.
9. Implementation Status
[Note to the RFC Editor - remove this section before publication, as
well as remove the reference to [RFC7942]
This section records the status of known implementations of the
protocol defined by this specification at the time of posting of this
Internet-Draft, and is based on a proposal described in [RFC7942] .
The description of implementations in this section is intended to
assist the IETF in its decision processes in progressing drafts to
RFCs. Please note that the listing of any individual implementation
here does not imply endorsement by the IETF. Furthermore, no effort
has been spent to verify the information presented here that was
supplied by IETF contributors. This is not intended as, and must not
be construed to be, a catalog of available implementations or their
features. Readers are advised to note that other implementations may
exist.
According to [RFC7942] , "this will allow reviewers and working
groups to assign due consideration to documents that have the benefit
of running code, which may serve as evidence of valuable
experimentation and feedback that have made the implemented protocols
more mature. It is up to the individual working groups to use this
information as they see fit".
9.1. Cisco Systems
The feature has been implemented on IOS-XR.
* Organization: Cisco Systems
* Implementation: Cisco systems IOS-XR has an implementation.
Capability has been used from [RFC7307] and plan to update the
value once IANA assigns new value.
* Description: The implementation has been done.
* Maturity Level: Product
* Contact: mankamis@cisco.com
10. Security Considerations 8. Security Considerations
This extension to mLDP does not introduce any new security This extension to mLDP does not introduce any new security
considerations beyond that already applied to the base LDP considerations beyond what is already applied to the base LDP
specification [RFC5036], LDP extensions for Multi-Topology specification [RFC5036], the LDP extensions for Multi-Topology
specification [RFC7307] base mLDP specification [RFC6388], and MPLS specification [RFC7307], the base mLDP specification [RFC6388], and
security framework [RFC5920]. the MPLS security framework specification [RFC5920].
11. 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.
+-----+------------------+---------------+-------------------------+
|Value| Description | Reference | Notes/Registration Date |
+-----+------------------+---------------+-------------------------+
| TBA | MT Multipoint | This document | |
| | Capability | | |
+-----+------------------+---------------+-------------------------+
Figure 7: IANA Code Point
12. Contributor 9. IANA Considerations
Anuj Budhiraja Cisco systems This document defines a new LDP capability parameter TLV called the
"MT Multipoint Capability". IANA has assigned the value 0x0510 from
the "TLV Type Name Space" registry in the "Label Distribution
Protocol (LDP) Parameters" group as the new code point.
13. Acknowledgments +========+===============+===========+=========================+
| Value | Description | Reference | Notes/Registration Date |
+========+===============+===========+=========================+
| 0x0510 | MT Multipoint | RFC 9658 | |
| | Capability | | |
+--------+---------------+-----------+-------------------------+
The authors would like to acknowledge Eric Rosen for his input on Table 1: MT Multipoint Capability
this specification.
14. References 10. References
14.1. Normative References 10.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,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC4915] Psenak, P., Mirtorabi, S., Roy, A., Nguyen, L., and P. [RFC4915] Psenak, P., Mirtorabi, S., Roy, A., Nguyen, L., and P.
Pillay-Esnault, "Multi-Topology (MT) Routing in OSPF", Pillay-Esnault, "Multi-Topology (MT) Routing in OSPF",
RFC 4915, DOI 10.17487/RFC4915, June 2007, RFC 4915, DOI 10.17487/RFC4915, June 2007,
<https://www.rfc-editor.org/info/rfc4915>. <https://www.rfc-editor.org/info/rfc4915>.
skipping to change at page 14, line 25 skipping to change at line 567
[RFC6514] Aggarwal, R., Rosen, E., Morin, T., and Y. Rekhter, "BGP [RFC6514] Aggarwal, R., Rosen, E., Morin, T., and Y. Rekhter, "BGP
Encodings and Procedures for Multicast in MPLS/BGP IP Encodings and Procedures for Multicast in MPLS/BGP IP
VPNs", RFC 6514, DOI 10.17487/RFC6514, February 2012, VPNs", RFC 6514, DOI 10.17487/RFC6514, February 2012,
<https://www.rfc-editor.org/info/rfc6514>. <https://www.rfc-editor.org/info/rfc6514>.
[RFC7307] Zhao, Q., Raza, K., Zhou, C., Fang, L., Li, L., and D. [RFC7307] Zhao, Q., Raza, K., Zhou, C., Fang, L., Li, L., and D.
King, "LDP Extensions for Multi-Topology", RFC 7307, King, "LDP Extensions for Multi-Topology", RFC 7307,
DOI 10.17487/RFC7307, July 2014, DOI 10.17487/RFC7307, July 2014,
<https://www.rfc-editor.org/info/rfc7307>. <https://www.rfc-editor.org/info/rfc7307>.
[RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running
Code: The Implementation Status Section", BCP 205,
RFC 7942, DOI 10.17487/RFC7942, July 2016,
<https://www.rfc-editor.org/info/rfc7942>.
[RFC8029] Kompella, K., Swallow, G., Pignataro, C., Ed., Kumar, N., [RFC8029] Kompella, K., Swallow, G., Pignataro, C., Ed., Kumar, N.,
Aldrin, S., and M. Chen, "Detecting Multiprotocol Label Aldrin, S., and M. Chen, "Detecting Multiprotocol Label
Switched (MPLS) Data-Plane Failures", RFC 8029, Switched (MPLS) Data-Plane Failures", RFC 8029,
DOI 10.17487/RFC8029, March 2017, DOI 10.17487/RFC8029, March 2017,
<https://www.rfc-editor.org/info/rfc8029>. <https://www.rfc-editor.org/info/rfc8029>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC9350] Psenak, P., Ed., Hegde, S., Filsfils, C., Talaulikar, K., [RFC9350] Psenak, P., Ed., Hegde, S., Filsfils, C., Talaulikar, K.,
and A. Gulko, "IGP Flexible Algorithm", RFC 9350, and A. Gulko, "IGP Flexible Algorithm", RFC 9350,
DOI 10.17487/RFC9350, February 2023, DOI 10.17487/RFC9350, February 2023,
<https://www.rfc-editor.org/info/rfc9350>. <https://www.rfc-editor.org/info/rfc9350>.
14.2. Informative References 10.2. Informative References
[IANA-IGP-ALGO-TYPES] [IANA-IGP-ALGO-TYPES]
"IGP Algorithm Types", <https://www.iana.org/assignments/ IANA, "IGP Algorithm Types",
igp-parameters/igp-parameters.xhtml#igp-algorithm-types>. <https://www.iana.org/assignments/igp-parameters>.
[RFC5036] Andersson, L., Ed., Minei, I., Ed., and B. Thomas, Ed., [RFC5036] Andersson, L., Ed., Minei, I., Ed., and B. Thomas, Ed.,
"LDP Specification", RFC 5036, DOI 10.17487/RFC5036, "LDP Specification", RFC 5036, DOI 10.17487/RFC5036,
October 2007, <https://www.rfc-editor.org/info/rfc5036>. October 2007, <https://www.rfc-editor.org/info/rfc5036>.
[RFC5561] Thomas, B., Raza, K., Aggarwal, S., Aggarwal, R., and JL. [RFC5561] Thomas, B., Raza, K., Aggarwal, S., Aggarwal, R., and JL.
Le Roux, "LDP Capabilities", RFC 5561, Le Roux, "LDP Capabilities", RFC 5561,
DOI 10.17487/RFC5561, July 2009, DOI 10.17487/RFC5561, July 2009,
<https://www.rfc-editor.org/info/rfc5561>. <https://www.rfc-editor.org/info/rfc5561>.
skipping to change at page 15, line 28 skipping to change at line 611
[RFC5919] Asati, R., Mohapatra, P., Chen, E., and B. Thomas, [RFC5919] Asati, R., Mohapatra, P., Chen, E., and B. Thomas,
"Signaling LDP Label Advertisement Completion", RFC 5919, "Signaling LDP Label Advertisement Completion", RFC 5919,
DOI 10.17487/RFC5919, August 2010, DOI 10.17487/RFC5919, August 2010,
<https://www.rfc-editor.org/info/rfc5919>. <https://www.rfc-editor.org/info/rfc5919>.
[RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS [RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS
Networks", RFC 5920, DOI 10.17487/RFC5920, July 2010, Networks", RFC 5920, DOI 10.17487/RFC5920, July 2010,
<https://www.rfc-editor.org/info/rfc5920>. <https://www.rfc-editor.org/info/rfc5920>.
Contributors
Anuj Budhiraja
Cisco Systems
Acknowledgments
The authors would like to acknowledge Eric Rosen for his input on
this specification.
Authors' Addresses Authors' Addresses
IJsbrand Wijnands IJsbrand Wijnands
Individual Individual
Email: ice@braindump.be Email: ice@braindump.be
Mankamana Mishra Mankamana Mishra (editor)
Cisco Systems, Inc. Cisco Systems, Inc.
821 Alder Drive 821 Alder Drive
Milpitas, CA 95035 Milpitas, CA 95035
United States of America United States of America
Email: mankamis@cisco.com Email: mankamis@cisco.com
Kamran Raza Kamran Raza
Cisco Systems, Inc. Cisco Systems, Inc.
2000 Innovation Drive 2000 Innovation Drive
Kanata ON K2K-3E8 Kanata ON K2K-3E8
skipping to change at page 16, line 4 skipping to change at line 640
Milpitas, CA 95035 Milpitas, CA 95035
United States of America United States of America
Email: mankamis@cisco.com Email: mankamis@cisco.com
Kamran Raza Kamran Raza
Cisco Systems, Inc. Cisco Systems, Inc.
2000 Innovation Drive 2000 Innovation Drive
Kanata ON K2K-3E8 Kanata ON K2K-3E8
Canada Canada
Email: skraza@cisco.com Email: skraza@cisco.com
Zhaohui Zhang Zhaohui Zhang
Juniper Networks Juniper Networks
10 Technology Park Dr. 10 Technology Park Dr.
Westford, MA 01886 Westford, MA 01886
United States of America United States of America
Email: zzhang@juniper.net Email: zzhang@juniper.net
Arkadiy Gulko Arkadiy Gulko
Edward Jones wealth management Edward Jones Wealth Management
United States of America United States of America
Email: Arkadiy.gulko@edwardjones.com Email: Arkadiy.gulko@edwardjones.com
 End of changes. 111 change blocks. 
358 lines changed or deleted 313 lines changed or added

This html diff was produced by rfcdiff 1.48.