| Internet-Draft | Short Title | March 2023 |
| Liu, et al. | Expires 10 September 2023 | [Page] |
The SRv6 END.XU function points to an underlying interface, which can represent an underly link (or path) between two routers. Since BGP or IGP routing protocols cannot advertise underlay link topology information, this document extends BGP-LS to advertise the topology information carried in END.XU.¶
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 10 September 2023.¶
Copyright (c) 2023 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 [I-D.dong-spring-srv6-inter-layer-programming], a new SRv6 function called END.XU is defined to support SRv6 multi-layer network programming. As a typical scenario, the END.XU function can be applied to the optical network or MTN (Metro Transport Network [I-D.dong-spring-srv6-inter-layer-programming]), and points to an underly interface, which can represent an underlying link (or path) between two routers.¶
A BGP-LS router can advertise topology information from the BGP routing protocol (e.g., for EPE) or the IGP routing protocols (e.g., for IS-IS/OSPFv3). However, the topology information of underlay links cannot be obtained from the BGP or IGP routing protocol since the underlay links are deployed statically. Therefore, this document extends the BGP-LS protocol to advertise the link attributes of underlay link and the END.XU SID information.¶
In [RFC7752], the Link-State NLRI includes the node/link/prefix descriptors. In this document, only the node descriptors and link descriptors are involved. [RFC7752] describes node descriptors based on the IGP/BGP protocol as the node anchoring the local end of the link. This document uses the Link-State NLRI to advertise the link attributes of underlay link, and describes the difference between the static configuration and the dynamic protocols (including the IGP and BGP routing protocols) in the key fields. Moreover, this document describes how to obtain local and peer information on the underlay link carried by END.XU. For advertising the attributes of nodes and links, this document inherits the node attribute TLV and link attribute TLV from [RFC7752], which are not described in this document.¶
Draft [I-D.ietf-idr-bgpls-srv6-ext] provides BGP-LS extensions related to SRv6 SIDs and other SRv6 information based on IGP or BGP. Link attributes involve the END.X/LAN END.X SID TLV and link MSD types. This document focuses on the extension of the SRv6 END.XU SID TLV type.¶
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.¶
This document inherits the Link-State NLRI [RFC7752] to advertise the underlay link information. The Link-State NLRI includes the node descriptors and the link descriptors.¶
The general format of node descriptors is shown in section 3.2 of [RFC7752]. The field filling rules are described as follows:¶
Protocol-ID indicates the source protocol type of BGP-LS. For the END.XU function, the link carried on the optical network or MTN network is a link under the IP layer. Some of the information of the underlay link (e.g., the Remote AS Number and the Remote Router Identifier) is obtained manually. Therefore, this field should be set to Static configuration (value 5).¶
Identifier indicates the routing universe. The identifier setting varies according to the scenario. If there is no IGP/BGP protocol, the identifier field is fixed to 0. If dynamic protocol-enabled links and static underlay links coexist, as described in section 3.2 of [RFC7752], the NLRIs representing link-state objects (nodes, links, or prefixes) from the same routing universe MUST have the same value of Identifier. Therefore, the Identifier field of the underlay link must be the same as that of other non-underlay links on which IGP/BGP-EPE is deployed.¶
Section 3.2.1.4 of [RFC7752] describes the types of node descriptor sub-TLVs as follows:¶
+--------------------+-------------------+----------+ | Sub-TLV Code Point | Description | Length | +--------------------+-------------------+----------+ | 512 | Autonomous System | 4 | | 513 | BGP-LS Identifier | 4 | | 514 | OSPF Area-ID | 4 | | 515 | IGP Router-ID | Variable | | TBD | Static Router-ID | Variable | +--------------------+-------------------+----------+¶
The value of TLV 512 or 513 is mandatory for underlay links. The method of obtaining the value of TLV 512 is described in Section 3.2. The value of TLV 513 can be specified only by static configuration.¶
The values of TLV 514 and 515 are valid only when the BGP-LS source is an IGP protocol. For the underlay links, a new node descriptor sub-TLV needs to be extended, where the value of "Code Point" field is TBD, the value of "Description" field is Static Router-ID, and the "Length" field is variable. The method of obtaining the value of Static Router-ID is also described in Section 3.2.¶
The value of Static Router-ID is the global unique device identifier (e.g. IPv6 TE Router IDs [RFC6119]).¶
This document inherits all Sub-TLVs of the link descriptors in [RFC7752].¶
For the static underlay link associated with END.XU, the IPv6 addresses of interfaces and neighbors, and the local and remote link identifiers are the most basic TLV types.¶
There are two typical application scenarios：¶
1) Static underlay links are used as Layer 3 links. IPv6 addresses are mandatory. The combination of interface and neighbor IPv6 addresses is used to uniquely identify a link. Whether the interface and neighbor IPv6 addresses are reachable is optional. If IPv4/IPv6 dual-stack coexists on the same static underlay link, the local and remote link identifiers are mandatory to prevent the controller from considering the underlay link as two different links.¶
2) Static underlay links are used as point-to-point links instead of Layer 3 links. A point-to-point link does not require additional IP addresses. Therefore, the local and remote link identifiers are unique link identifiers, and must be used as mandatory.¶
Sections 3.1 and 3.2 describe three key parameters of the underlay link carried by END.XU, including AS number, static router ID, and link identifier. The following describes how to obtain the three parameters.¶
The value of the local parameters can be obtained from the control management module of the local device.¶
The remote parameter value can be controlled in either of the following two ways:¶
If the controller is used, the controller obtains the AS number, IPv6 address, and link identifier of remote device. Then, the controller delivers them to the local device through the northbound interface. Finally, local device advertises the underlay link state information and the END.XU SID information to the controller.¶
If there is no controller, only the link-layer protocol on the static underlay link can be used to obtain the peer AS, IPv6 address, and link identifier (such as LLDP). The link-layer protocol-based parameter obtaining requires the extension of the link-layer protocol and is not described in this document.¶
Based on [I-D.ietf-idr-bgpls-srv6-ext], the BGP-LS attributes related to the static underlay link carried by END.XU include the node attributes via the BGP-LS Node NLRI and the link attributes via the BGP-LS Link NLRI. The node attributes inherit the content in section 3 of [I-D.ietf-idr-bgpls-srv6-ext]. For the link attributes, this document extends a new TLV, called SRv6 End.XU SID TLV, to advertise the SRv6 SIDs associated with a static adjacency SID.¶
The SRv6 End.XU SID TLV is used to advertise the SRv6 SIDs associated with an SRv6 END.XU behavior that corresponds to a point-to-point static underlay link.¶
The SRv6 SID for the underlay link using the End.XU behaviors [I-D.dong-spring-srv6-inter-layer-programming] are advertised using the SRv6 End.XU SID TLV.¶
The format of the SRv6 End.XU SID TLV is inherited from the SRv6 END.X SID Sub-TLV [RFC9352].¶
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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Endpoint Behavior | Flags | Algorithm | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Weight | Reserved | SID (16 octets) ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SID (cont ...) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SID (cont ...) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SID (cont ...) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SID (cont ...) | Sub-TLVs (variable) . . . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+¶
Endpoint Behavior: 2 octet field. The Endpoint Behavior code point for this SRv6 END.XU SID as defined in section 6 of [I-D.dong-spring-srv6-inter-layer-programming].¶
Flags: 1 octet of flags. B-Flag is fixed to 0. S-Flag is fixed to 0. P-Flag is fixed to 1 for static configuration and 0 for dynamic allocation.¶
Algorithm: 1 octet field. END.XU function carries a pure static underlay link. No algorithm is used. Therefore, the value is fixed to 0.¶
Weight: 1 octet field. The value represents the weight of the SID for the purpose of load balancing. The use of the weight is defined in [RFC8402].¶
Reserved: 1 octet field that MUST be set to 0 and ignored on receipt.¶
SID: 16 octet field. This field encodes the advertised SRv6 SID as 128 bit value.¶
Sub-TLVs: They are allocated from the IANA "BGP-LS Node Descriptor, Link Descriptor, Prefix Descriptor, and Attribute TLVs" registry and are used to advertise sub-TLVs that provide additional attributes for the specific SRv6 SID. This document does not define new sub-TLVs for SRv6 End.XU SID TLV.¶
IANA is requested to allocate one Sub-TLV Code Point for node descriptor：¶
+--------------------+-------------------+----------+ | Sub-TLV Code Point | Description | Length | +--------------------+-------------------+----------+ | TBD | Static Router-ID | Variable | +--------------------+-------------------+----------+¶
The authors would like to thank Jie Dong and Yongjian Hu for their review and comments.¶