]> Huawei Technologies

101 software Avenue, Yuhua District Nanjing 210012 China liuguoliang@huawei.com

Huawei Technologies

No.9 Huanhu Road, Songshan Lake High-tech Industrial Development Zone Dongguan 523808 China fanxingpeng1@huawei.com

Huawei Technologies

Huawei Campus, No.156 Beiqing Road Beijing 100095 China jie.dong@huawei.com

General SPRING Working Group Internet-Draft 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.

Introduction In , 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 ), 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 , the Link-State NLRI includes the node/link/prefix descriptors. In this document, only the node descriptors and link descriptors are involved. 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 , which are not described in this document. Draft 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.

Terminology

Requirements Language 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 when, and only when, they appear in all capitals, as shown here.

The Link-State NLRI This document inherits the Link-State NLRI to advertise the underlay link information. The Link-State NLRI includes the node descriptors and the link descriptors.

Node Descriptors The general format of node descriptors is shown in section 3.2 of . 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 , 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 describes the types of node descriptor sub-TLVs as follows: 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 ).

Link Descriptors This document inherits all Sub-TLVs of the link descriptors in . 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.

The BGP-LS Attribute Based on , 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 . 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.

SRv6 End.XU SID TLV 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 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 . Endpoint Behavior: 2 octet field. The Endpoint Behavior code point for this SRv6 END.XU SID as defined in section 6 of . 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 . 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.

Security Considerations TBD

IANA Considerations IANA is requested to allocate one Sub-TLV Code Point for node descriptor：

Acknowledgements The authors would like to thank Jie Dong and Yongjian Hu for their review and comments.

References Normative References In a number of environments, a component external to a network is called upon to perform computations based on the network topology and current state of the connections within the network, including Traffic Engineering (TE) information. This is information typically distributed by IGP routing protocols within the network. This document describes a mechanism by which link-state and TE information can be collected from networks and shared with external components using the BGP routing protocol. This is achieved using a new BGP Network Layer Reachability Information (NLRI) encoding format. The mechanism is applicable to physical and virtual IGP links. The mechanism described is subject to policy control. Applications of this technique include Application-Layer Traffic Optimization (ALTO) servers and Path Computation Elements (PCEs). Segment Routing (SR) leverages the source routing paradigm. A node steers a packet through an ordered list of instructions, called "segments". A segment can represent any instruction, topological or service based. A segment can have a semantic local to an SR node or global within an SR domain. SR provides a mechanism that allows a flow to be restricted to a specific topological path, while maintaining per-flow state only at the ingress node(s) to the SR domain. SR can be directly applied to the MPLS architecture with no change to the forwarding plane. A segment is encoded as an MPLS label. An ordered list of segments is encoded as a stack of labels. The segment to process is on the top of the stack. Upon completion of a segment, the related label is popped from the stack. SR can be applied to the IPv6 architecture, with a new type of routing header. A segment is encoded as an IPv6 address. An ordered list of segments is encoded as an ordered list of IPv6 addresses in the routing header. The active segment is indicated by the Destination Address (DA) of the packet. The next active segment is indicated by a pointer in the new routing header. This document specifies a method for exchanging IPv6 traffic engineering information using the IS-IS routing protocol. This information enables routers in an IS-IS network to calculate traffic-engineered routes using IPv6 addresses. [STANDARDS-TRACK] The Segment Routing (SR) architecture allows a flexible definition of the end-to-end path by encoding it as a sequence of topological elements called "segments". It can be implemented over the MPLS or the IPv6 data plane. This document describes the IS-IS extensions required to support SR over the IPv6 data plane. This document updates RFC 7370 by modifying an existing registry. In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Informative References LinkedIn Cisco Systems Cisco Systems Huawei Bell Canada Orange Segment Routing over IPv6 (SRv6) allows for a flexible definition of end-to-end paths within various topologies by encoding paths as sequences of topological or functional sub-paths, called "segments". These segments are advertised by various protocols such as BGP, IS-IS and OSPFv3. This document defines extensions to BGP Link-state (BGP-LS) to advertise SRv6 segments along with their behaviors and other attributes via BGP. The BGP-LS address-family solution for SRv6 described in this document is similar to BGP-LS for SR for the MPLS data-plane defined in a separate document. Huawei Technologies China Mobile China Mobile China Mobile This document defines a new SRv6 function which can be used for SRv6 based inter-layer network programming. It is a variant of the SRv6 End.X behavior which is called "End.XU". Instead of pointing to an interface with layer-3 adjacency, the End.XU behavior points to an underlay interface which connects to a remote layer-3 node via underlying links or connections that may be invisible in the L3 topology.