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 | September 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. 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 MTR, with an algorithm, in | |||
algorithm, in order for Multipoint LSPs(Label Switched Paths) to | order for multipoint LSPs (Label Switched Paths) to follow a | |||
follow a particular topology and algorithm. It updates [RFC7307] by | particular topology and algorithm. It updates RFC 7307 by allocating | |||
allocating eight bits from a previously reserved field to be used as | eight bits from a previously reserved field to be used as the IPA | |||
the IGP Algorithm (IPA) field. | 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. IGP protocols (OSPF and IS-IS) | |||
and LDP have already been extended to support MTR. To support MTR, | ||||
an IGP maintains independent IP topologies, called "Multi-Topologies" | ||||
(or "MTs"), and computes/installs routes per 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 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]. 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/IPA 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 so that different | |||
FEC, so that different MT-ID values will result in unique MP-LSP FEC | 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 Data 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 MP | |||
element should be encoded as follows: | 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: Data 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. | |||
skipping to change at page 8, line 27 ¶ | skipping to change at line 347 ¶ | |||
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: Data 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: The length (in octets) of the TLV. The value of this field | |||
MUST be 1 as there is no Capability-specific data [RFC5561] that | MUST be 1 as there is no Capability-specific data [RFC5561] that | |||
follows in the TLV. Length: This field specifies the length of | follows in 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 | Length: This field specifies the length of the TLV in octets. The | |||
per [RFC5561]. | value of this field MUST be 1, as there is no Capability-specific | |||
data [RFC5561] following the TLV. | ||||
An mLDP speaker that has successfully advertised and negotiated "MT | S bit: Set to 1 to announce and 0 to withdraw the capability (as per | |||
Multipoint" capability MUST support the following: | [RFC5561]). | |||
1. Topology-scoped mLDP FECs in LDP messages (Section 4.1) | An mLDP speaker that has successfully advertised and negotiated the | |||
"MT Multipoint" capability MUST support the following: | ||||
2. Topology-scoped mLDP forwarding setup (Section 7) | 1. Topology-scoped mLDP FECs in LDP messages (Section 3.1) | |||
6. MT Applicability on FEC-based features | 2. Topology-scoped mLDP forwarding setup (Section 6) | |||
6.1. Typed Wildcard MP FEC Elements | 5. MT Applicability on FEC-Based Features | |||
[RFC5918] extends base LDP and defines Typed Wildcard FEC Element | 5.1. Typed Wildcard MP FEC Elements | |||
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, defined in this document, do not require any | [RFC5918] extends the base LDP and defines the Typed Wildcard FEC | |||
extension to procedures for Typed Wildcard FEC Element support | Element framework. A Typed Wildcard FEC element can be used in any | |||
[RFC5918], and these procedures apply as-is to Multipoint MT FEC | LDP message to specify a wildcard operation for a given type of FEC. | |||
wildcarding. Similar to Typed Wildcard MT Prefix FEC Element, as | ||||
The MT extensions defined in this document do not require any | ||||
extension to procedures for support of the Typed Wildcard FEC Element | ||||
[RFC5918], and these procedures apply as is to Multipoint MT FEC | ||||
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: Data 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 571 ¶ | |||
[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 615 ¶ | |||
[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 644 ¶ | |||
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. | ||||
350 lines changed or deleted | 309 lines changed or added | |||
This html diff was produced by rfcdiff 1.48. |