| Internet-Draft | Advertising TE Paths using BGP-LS | November 2024 |
| Previdi, et al. | Expires 15 May 2025 | [Page] |
This document describes a mechanism to collect the Traffic Engineering Path information that is locally available in a node and advertise it into BGP Link-State (BGP-LS) updates. Such information can be used by external components for path computation, re-optimization, service placement, network visualization, etc.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 15 May 2025.¶
Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
In many network environments, traffic engineering (TE) paths are instantiated into various forms:¶
All this information can be grouped into the same term: TE Paths. In the rest of this document we refer to TE Paths as the set of information related to the various instantiation of policies: MPLS TE LSPs, Local MPLS cross-connects, etc.¶
TE Paths are generally instantiated at the head-end and are based on either local configuration or controller-based programming of the node using various APIs and protocols, e.g., PCEP.¶
In many network environments, the configuration, and state of each TE Path that is available in the network is required by a controller which allows the network operator to optimize several functions and operations through the use of a controller aware of both topology and state information.¶
One example of a controller is the stateful Path Computation Element (PCE) [RFC8231], which could provide benefits in path optimization. While some extensions are proposed in the Path Computation Element Communication Protocol (PCEP) for the Path Computation Clients (PCCs) to report the LSP states to the PCE, this mechanism may not be applicable in a management-based PCE architecture as specified in section 5.5 of [RFC4655]. As illustrated in the figure below, the PCC is not an LSR in the routing domain, thus the head-end nodes of the TE-LSPs may not implement the PCEP protocol. In this case, a general mechanism to collect the TE-LSP states from the ingress LERs is needed. This document proposes a TE Path state collection mechanism complementary to the mechanism defined in [RFC8231].¶
-----------
| ----- |
Service | | TED |<-+----------->
Request | ----- | TED synchronization
| | | | mechanism (e.g.,
v | | | routing protocol)
------------- Request/ | v |
| | Response| ----- |
| NMS |<--------+> | PCE | |
| | | ----- |
------------- -----------
Service |
Request |
v
---------- Signaling ----------
| Head-End | Protocol | Adjacent |
| Node |<---------->| Node |
---------- ----------
Figure 1. Management-Based PCE Usage
¶
In networks with composite PCE nodes as specified in section 5.1 of [RFC4655], PCE is implemented on several routers in the network, and the PCCs in the network can use the mechanism described in [RFC8231] to report the TE Path information to the PCE nodes. An external component may also need to collect the TE Path information from all the PCEs in the network to obtain a global view of the LSP state in the network.¶
In multi-area or multi-AS scenarios, each area or AS can have a child PCE to collect the TE Paths in its domain, in addition, a parent PCE needs to collect TE Path information from multiple child PCEs to obtain a global view of LSPs inside and across the domains involved.¶
In another network scenario, a centralized controller is used for service placement. Obtaining the TE Path state information is quite important for making appropriate service placement decisions with the purpose of both meeting the application's requirements and utilizing network resources efficiently.¶
The Network Management System (NMS) may need to provide global visibility of the TE Paths in the network as part of the network visualization function.¶
BGP has been extended to distribute link-state and traffic engineering information to external components [RFC9552]. BGP-LS is extended to carry TE Path information via [I-D.ietf-idr-bgp-ls-sr-policy] so that the same protocol may be used to also collect Segment Routing traffic engineering paths information such that external components like controllers can use the same protocol for network information collection. This document specifies similar extensions to BGP-LS for the advertisement of information other TE Paths to external components.¶
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶
The "Link-State NLRI" defined in [RFC9552] is extended to carry the TE Path information. New TLVs carried in the Link_State Attribute defined in [RFC9552] are also defined to carry the attributes of a TE Path in the subsequent sections.¶
The format of "Link-State NLRI" is defined in [RFC9552] as follows:¶
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | NLRI Type | Total NLRI Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | // Link-State NLRI (variable) // | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+¶
Additional "NLRI Types" are defined for TE Path Information as following:¶
The common format for these NLRI types is defined in Section 3 below.¶
This document defines TE Path NLRI Types with their common format as shown in the following figure:¶
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 +-+-+-+-+-+-+-+-+ | Protocol-ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Identifier | | (64 bits) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ // Node Descriptor TLV (for the Headend) // +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ // TE Path Descriptors (variable) // +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ where:¶
Protocol-ID field specifies the component that owns the TE Path state in the advertising node. The existing protocol-id value of 5 for Static Configuration applies for some of the NLRI types and the "RSVP-TE" Protocol-ID (value 8) is defined for some of the other types in this document.¶
"Local Node Descriptor" (TLV 256) as defined in [RFC9552] that describes the headend node.¶
"TE Path Descriptors" consists of one or more of the TLVs listed as below for use with the respective NLRI type advertisements as specified in Section 4:¶
+-----------+----------------------------------+ | Codepoint | Descriptor TLVs | +-----------+----------------------------------+ | 550 | Tunnel ID | | 551 | LSP ID | | 552 | IPv4/6 Tunnel Head-end address | | 553 | IPv4/6 Tunnel Tail-end address | | 555 | Local MPLS Cross Connect | +-----------+----------------------------------+¶
The Local Node Descriptor TLV MUST include the following Node Descriptor TLVs:¶
BGP Router-ID (TLV 516) [RFC9086], which contains a valid BGP Identifier of the node originating the TE Path advertisement.¶
Autonomous System Number (TLV 512) [RFC9552], which contains the ASN or AS Confederation Identifier (ASN) [RFC5065], if confederations are used, of the node originating the TE Path advertisement.¶
The Local Node Descriptor TLV SHOULD include at least one of the following Node Descriptor TLVs:¶
IPv4 Router-ID of Local Node (TLV 1028) [RFC9552], which contains the IPv4 TE Router-ID of the local node when one is provisioned.¶
IPv6 Router-ID of Local Node (TLV 1029) [RFC9552], which contains the IPv6 TE Router-ID of the local node when one is provisioned.¶
The Local Node Descriptor TLV MAY include the following Node Descriptor TLVs:¶
This section defines the TE Path Descriptors TLVs which are used to describe the TE Path being advertised by using the NLRI types defined in Section 3.¶
The Tunnel Identifier TLV contains the Tunnel ID defined in [RFC3209] and is used with the Protocol-ID set to RSVP-TE to advertise the MPLS-TE LSP NLRI Type. It is a mandatory TE Path Descriptor TLV for MPLS-TE LSP NLRI type. It has the following format:¶
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tunnel ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ where:¶
The LSP Identifier TLV contains the LSP ID defined in [RFC3209] and is used with the Protocol-ID set to RSVP-TE to advertise the MPLS-TE LSP NLRI Type. It is a mandatory TE Path Descriptor TLV for MPLS-TE LSP NLRI type. It has the following format:¶
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LSP ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ where:¶
The IPv4/IPv6 Tunnel Head-End Address TLV contains the Tunnel Head-End Address defined in [RFC3209] and is used with the Protocol-ID set to RSVP-TE to advertise the MPLS-TE LSP NLRI Type. It is a mandatory TE Path Descriptor TLV for MPLS-TE LSP NLRI type. It has the following format:¶
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ // IPv4/IPv6 Tunnel Head-End Address (variable) // +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ where:¶
When the IPv4/IPv6 Tunnel Head-end Address TLV contains an IPv4 address, its length is 4 (octets).¶
When the IPv4/IPv6 Tunnel Head-end Address TLV contains an IPv6 address, its length is 16 (octets).¶
The IPv4/IPv6 Tunnel Tail-End Address TLV contains the Tunnel Tail-End Address defined in [RFC3209] and is used with the Protocol-ID set to RSVP-TE to advertise the MPLS-TE LSP NLRI Type. It is a mandatory TE Path Descriptor TLV for MPLS-TE LSP NLRI type. It has the following format:¶
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ // IPv4/IPv6 Tunnel Tail-End Address (variable) // +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ where:¶
When the IPv4/IPv6 Tunnel Tail-end Address TLV contains an IPv4 address, its length is 4 (octets).¶
When the IPv4/IPv6 Tunnel Tail-end Address TLV contains an IPv6 address, its length is 16 (octets).¶
The Local MPLS Cross Connect TLV identifies a local MPLS state in the form of an incoming label and interface followed by an outgoing label and interface. The outgoing interface may appear multiple times (for multicast states). It is used with Protocol ID set to "Static Configuration" value 5 as defined in [RFC9552]. It is a mandatory TE Path Descriptor TLV for MPLS Local Cross-connect NLRI type.¶
The Local MPLS Cross Connect TLV has the following format:¶
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Incoming label (4 octets) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Outgoing label (4 octets) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ // Sub-TLVs (variable) // +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ where:¶
Type: 555¶
Length: variable.¶
Incoming and Outgoing labels: 4 octets each.¶
Sub-TLVs: following Sub-TLVs are defined:¶
The Local MPLS Cross Connect TLV:¶
MUST have an incoming label.¶
MUST have an outgoing label.¶
MAY contain an Interface Sub-TLV having the I-flag set.¶
MUST contain at least one Interface Sub-TLV having the I-flag unset.¶
MAY contain multiple Interface Sub-TLV having the I-flag unset. This is the case of a multicast MPLS cross-connect.¶
MAY contain an FEC Sub-TLV.¶
The following sub-TLVs are defined for the Local MPLS Cross Connect TLV:¶
+-----------+----------------------------------+ | Codepoint | Descriptor TLV | +-----------+----------------------------------+ | 556 | MPLS Cross Connect Interface | | 557 | MPLS Cross Connect FEC | +-----------+----------------------------------+¶
These are defined in the following sub-sections.¶
The MPLS Cross Connect Interface sub-TLV is optional and contains the identifier of the interface (incoming or outgoing) in the form of an IPv4/IPv6 address and/or a local interface identifier.¶
The MPLS Cross Connect Interface sub-TLV has the following format:¶
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ | Flags | +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Local Interface Identifier (4 octets) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ // Interface Address (4 or 16 octets) // +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ where:¶
Type: 556¶
Length: 9 or 21.¶
Flags: 1 octet of flags defined as follows:¶
0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ |I| | +-+-+-+-+-+-+-+-+ where:¶
I-Flag is the Interface flag. When set, the Interface Sub-TLV describes an incoming interface. If the I-flag is not set, then the Interface Sub-TLV describes an outgoing interface.¶
Local Interface Identifier: a 4-octet identifier.¶
Interface address: a 4-octet IPv4 address or a 16-octet IPv6 address.¶
The MPLS Cross Connect FEC sub-TLV is optional and contains the FEC associated with the incoming label.¶
The MPLS Cross Connect FEC sub-TLV has the following format:¶
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Flags | Masklength | Prefix (variable) // +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ // Prefix (variable) // +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ where:¶
Type: 557¶
Length: variable.¶
Flags: 1 octet of flags defined as follows:¶
0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ |4| | +-+-+-+-+-+-+-+-+ where:¶
4-Flag is the IPv4 flag. When set, the FEC Sub-TLV describes an IPv4 FEC. If the 4-flag is not set, then the FEC Sub-TLV describes an IPv6 FEC.¶
Mask Length: 1 octet of prefix length.¶
Prefix: an IPv4 or IPv6 prefix whose mask length is given by the " Mask Length" field padded to an octet boundary.¶
A new TLV called "MPLS-TE Path State TLV", is used to describe the characteristics of the MPLS-TE LSP NLRI type and it is carried in the optional non-transitive BGP Attribute "LINK_STATE Attribute" defined in [RFC9552]. These MPLS-TE LSP characteristics include the characteristics and attributes of the LSP, its dataplane, explicit path, Quality of Service (QoS) parameters, route information, the protection mechanisms, etc.¶
The MPLS-TE Path State TLV has the following format:¶
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Object-origin | Address Family| RESERVED | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ // MPLS-TE Path State Objects (variable) // +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ where:
Type: 1200¶
Length: the total length of the MPLS-TE Path State TLV not including the Type and Length fields.¶
Object-origin: identifies the component (or protocol) from which the contained object originated. This allows for objects defined in different components to be collected while avoiding the possible codepoint collisions among these components. The following object-origin codepoints are defined in this document.¶
+----------+------------------+ | Code | Object | | Point | Origin | +----------+------------------+ | 1 | RSVP-TE | | 2 | PCEP | | 3 | Local/Static | +----------+------------------+¶
Address Family: describes the address family used to set up the MPLS-TE path. The following address family values are defined in this document:¶
+----------+------------------+ | Code | Dataplane | | Point | | +----------+------------------+ | 1 | MPLS-IPv4 | | 2 | MPLS-IPv6 | +----------+------------------+¶
RESERVED: 16-bit field. SHOULD be set to 0 on transmission and MUST be ignored on receipt.¶
TE Path State Objects: Rather than replicating all these objects in this document, the semantics and encodings of the objects as defined in RSVP-TE and PCEP are reused.¶
The state information is carried in the "MPLS-TE Path State Objects" with the following format as described in the sub-sections below.¶
RSVP-TE objects are encoded in the "MPLS-TE Path State Objects" field of the MPLS-TE Path State TLV and consists of MPLS TE LSP objects defined in RSVP-TE [RFC3209] [RFC3473]. Rather than replicating all MPLS TE LSP-related objects in this document, the semantics and encodings of the MPLS TE LSP objects are re-used. These MPLS TE LSP objects are carried in the MPLS-TE Path State TLV.¶
When carrying RSVP-TE objects, the "Object-Origin" field is set to "RSVP-TE".¶
The following RSVP-TE Objects are defined:¶
For the MPLS TE LSP Objects listed above, the corresponding sub-objects are also applicable to this mechanism. Note that this list is not exhaustive, other MPLS TE LSP objects which reflect specific characteristics of the MPLS TE LSP can also be carried in the LSP state TLV.¶
PCEP objects are encoded in the "MPLS-TE Path State Objects" field of the MPLS-TE Path State TLV and consist of PCEP objects defined in [RFC5440]. Rather than replicating all MPLS TE LSP-related objects in this document, the semantics, and encodings of the MPLS TE LSP objects are re-used. These MPLS TE LSP objects are carried in the MPLS-TE Path State TLV.¶
When carrying PCEP objects, the "Object-Origin" field is set to "PCEP".¶
The following PCEP Objects are defined:¶
For the MPLS TE LSP Objects listed above, the corresponding sub-objects are also applicable to this mechanism. Note that this list is not exhaustive, other MPLS TE LSP objects which reflect specific characteristics of the MPLS TE LSP can also be carried in the TE Path State TLV.¶
The BGP-LS advertisements for the TE Path NLRI types are originated by the headend node for the TE Paths that are instantiated on its local node.¶
For MPLS TE LSPs signaled via RSVP-TE, the NLRI descriptor TLVs as specified in Section 4.1, Section 4.2, Section 4.3, and Section 4.4 are used. Then the TE LSP state is encoded in the BGP-LS Attribute field as MPLS-TE Path State TLV as described in Section 5. The RSVP-TE objects that reflect the state of the LSP are included as defined in Section 5.1. When the TE LSP is setup with the help of PCEP signaling then another MPLS-TE Path State TLV SHOULD be used to encode the related PCEP objects corresponding to the LSP as defined in Section 5.2.¶
When a SR Policy [RFC9256] is setup with the help of PCEP signaling [RFC8664] then a MPLS-TE Path State TLV MAY be used to encode the related PCEP objects corresponding to the LSP as defined in Section 5.2 specifically to report information and status that is not covered by the SR Policy State TLVs specified in #draft-ietf-idr-bgp-ls-sr-policy#. In the event of a conflict of information, the receiver MUST prefer the information originated via the SR Policy State TLVs over the PCEP objects reported via the TE Path State TLV.¶
The Existing BGP operational and management procedures apply to this document. No new procedures are defined in this document. The considerations as specified in [RFC9552] apply to this document.¶
In general, it is assumed that the TE Path head-end nodes are responsible for the advertisement of TE Path state information, while other nodes, e.g. the nodes in the path of a policy, MAY report the TE Path information (if available) when needed. For example, the border routers in the inter-domain case will also distribute LSP state information since the ingress node may not have the complete information for the end-to-end path.¶
This section describes the code point allocation by IANA for this document.¶
IANA maintains a registry called "BGP-LS NLRI-Types" in the "Border Gateway Protocol - Link State (BGP-LS) Parameters" registry group.¶
The following table lists the code points pending allocation by IANA:¶
+------+-------------------------------+---------------+ | Type | NLRI Type | Reference | +------+-------------------------------+---------------+ | TBD | MPLS-TE LSP NLRI | this document | | TBD | MPLS Local Cross-connect NLRI | this document | +------+-------------------------------+---------------+¶
IANA maintains a registry called "BGP-LS Protocol-IDs" in the "Border Gateway Protocol - Link State (BGP-LS) Parameters" registry group.¶
The following Protocol-ID codepoints have been allocated by IANA:¶
+-------------+----------------------------------+---------------+ | Protocol-ID | NLRI information source protocol | Reference | +-------------+----------------------------------+---------------+ | 8 | RSVP-TE | this document | +-------------+----------------------------------+---------------+¶
IANA maintains a registry called "Node Anchor, Link Descriptor and Link Attribute TLVs" in the "Border Gateway Protocol - Link State (BGP-LS) Parameters" registry group.¶
The following table lists the status of TLV code points that have been allocated by IANA:¶
+-------+----------------------------------------+---------------+ | Code | Description | Value defined | | Point | | in | +-------+----------------------------------------+---------------+ | 550 | Tunnel ID | this document | | 551 | LSP ID | this document | | 552 | IPv4/6 Tunnel Head-end address | this document | | 553 | IPv4/6 Tunnel Tail-end address | this document | | 555 | MPLS Local Cross Connect | this document | | 556 | MPLS Cross Connect Interface | this document | | 557 | MPLS Cross Connect FEC | this document | | 1200 | MPLS-TE Path State | this document | +-------+----------------------------------------+---------------+¶
This document requests IANA to maintain a new registry under "Border Gateway Protocol - Link State (BGP-LS) Parameters" registry group with the allocation policy of "Expert Review" [RFC8126] using the guidelines for Designated Experts as specified in [RFC9552]. The new registry is called "TE State Path Origin" and contains the codepoints allocated to the "Object Origin" field defined in Section 5. The registry contains the following codepoints, with initial values, to be assigned by IANA with the reference set to this document:¶
+----------+------------------------------------------+ | Code | Object | | Point | Origin | +----------+------------------------------------------+ | 0 | Reserved (not to be used) | | 1 | RSVP-TE | | 2 | PCEP | | 3 | Local/Static | | 4-250 | Unassigned | | 251-255 | Private Use (not to be assigned by IANA) | +----------+------------------------------------------+¶
This document requests IANA to maintain a new registry under "Border Gateway Protocol - Link State (BGP-LS) Parameters" registry group with the allocation policy of "Expert Review" [RFC8126] using the guidelines for Designated Experts as specified in [RFC9552]. The new registry is called "TE State Address Family" and contains the codepoints allocated to the "Address Family" field defined in Section 5. The registry contains the following codepoints, with initial values, to be assigned by IANA with the reference set to this document:¶
+----------+------------------------------------------+ | Code | Address | | Point | Family | +----------+------------------------------------------+ | 0 | Reserved (not to be used) | | 1 | MPLS-IPv4 | | 2 | MPLS-IPv6 | | 3-250 | Unassigned | | 251-255 | Private Use (not to be assigned by IANA) | +----------+------------------------------------------+¶
Procedures and protocol extensions defined in this document do not affect the BGP security model. See [RFC6952] for details.¶
The following people have substantially contributed to the editing of this document:¶
Clarence Filsfils Cisco Systems Email: [email protected]¶
Mach (Guoyi) Chen Huawei Technologies Email: [email protected]¶
The authors would like to thank Dhruv Dhody, Mohammed Abdul Aziz Khalid, Lou Berger, Acee Lindem, Siva Sivabalan, Arjun Sreekantiah, Dhanendra Jain, Francois Clad, Zafar Ali, Stephane Litkowski, and Aravind Babu Mahendra Babu for their review and valuable comments.¶