]> 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. This document extends BGP-LS to advertise the link attributes of underlay link and the END.XU SID information.

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. 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. This document uses the Link-State NLRI to advertise the link attributes of underlay link. 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. Link attributes involve the END.X/LAN END.X SID TLV and link MSD types. This document focuses on advertising the END.XU SID information.

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. If all information derived from the IGP protocols, the corresponding Protocol-ID MUST be used. If BGP-LS is sourcing local information and some of the information of the underlay link (e.g., the Remote AS Number and the Remote Router Identifier) is manually configured, this field should be set to Static configuration (value 5). Identifier indicates the routing universe. The identifier setting varies depending on the scenario. If all information derived from the IGP protocols, 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. If BGP-LS is sourcing local information, the identifier field is fixed to 0. The sub-TLVs of node descriptor for underlay link are described 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 setting of BGP-LS Identifier is the same as . 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 to cope with the scenario where there is no IGP protocol on local router. For the new sub-TLV, the value of "Code Point" field is TBD, the value of "Description" field is Static Router-ID, and the "Length" field is variable. The value of Static Router-ID is the global unique device identifier. It is flexible and can be an IPv6 address, a device identifier or a string name. The method of obtaining the value of Static Router-ID is also described in Section 3.2.

Link Descriptors This document inherits all Sub-TLVs of the link descriptors in , which is listed as follows: 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. Whether the TLV is present depends on the scenario. 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, 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.

Advertising Underlay Link SRv6 SIDs 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 inherits the SRv6 END.X SID Sub-TLV to advertise the SRv6 END.XU SID information. 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 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.

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. This document specifies encoding of extensions to the IS-IS routing protocol in support of Generalized Multi-Protocol Label Switching (GMPLS). [STANDARDS-TRACK] This document describes extensions to the Intermediate System to Intermediate System (IS-IS) protocol to support Traffic Engineering (TE). This document extends the IS-IS protocol by specifying new information that an Intermediate System (router) can place in Link State Protocol Data Units (LSP). This information describes additional details regarding the state of the network that are useful for traffic engineering computations. [STANDARDS-TRACK] 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.