BGP Extensions of SR Policy for Composite Candidate Path New H3C Technologies
lihao@h3c.com
New H3C Technologies
chen.mengxiao@h3c.com
New H3C Technologies
linchangwang.04414@h3c.com
China Mobile
jiangwenying@chinamobile.com
China Mobile
chengweiqiang@chinamobile.com
General Network Working Group Segment Routing SR Policy BGP Segment Routing is a source routing paradigm that explicitly indicates the forwarding path for packets at the ingress node. An SR Policy is associated with one or more candidate paths. A candidate path is either dynamic, explicit or composite. This document defines extensions to BGP to distribute SR policies carrying composite candidate path information. So that composite candidate paths can be installed when the SR policy is applied.
Segment routing (SR) is a source routing paradigm that explicitly indicates the forwarding path for packets at the ingress node. The ingress node steers packets into a specific path according to the Segment Routing Policy (SR Policy) as defined in . In order to distribute SR policies to the headend, specifies a mechanism by using BGP. An SR Policy is associated with one or more candidate paths. A composite candidate path acts as a container for grouping of SR Policies. As described in section 2.2 in , the composite candidate path construct enables combination of SR Policies, each with explicit candidate paths and/or dynamic candidate paths with potentially different optimization objectives and constraints, for a load-balanced steering of packet flows over its constituent SR Policies. describes some use cases for SR policy group composite candidate path. This document defines extensions to Border Gateway Protocol (BGP) to distribute SR policies carrying composite candidate path information. So that composite candidate paths can be installed when the SR policy is applied.
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.
As defined in , the SR policy encoding structure is as follows: SR Policy SAFI NLRI: <Distinguisher, Policy-Color, Endpoint> Attributes: Tunnel Encaps Attribute (23) Tunnel Type: SR Policy Binding SID SRv6 Binding SID Preference Priority Policy Name Policy Candidate Path Name Explicit NULL Label Policy (ENLP) Segment List Weight Segment Segment ... ...
As described in section 2.2 in , the endpoints of the constituent SR Policies and the parent SR Policy MUST be identical, and the colors of each of the constituent SR Policies and the parent SR Policy MUST be different. Therefore a constituent SR Policy is referenced only by color in the composite candidate path since its headend and endpoint are identical to the parent SR policy.
SR policy with composite candidate path information is expressed as below: SR Policy SAFI NLRI: <Distinguisher, Policy-Color, Endpoint> Attributes: Tunnel Encaps Attribute (23) Tunnel Type: SR Policy Binding SID SRv6 Binding SID Preference Priority Policy Name Policy Candidate Path Name Explicit NULL Label Policy (ENLP) Segment List Weight Segment Segment ... Constituent SR Policy Weight ...
The Constituent SR Policy sub-TLV encodes a single composite path towards the endpoint. The Constituent SR Policy sub-TLV is an optional sub-TLV of BGP Tunnel Encapsulation Attribute, and MAY appear multiple times in the SR Policy encoding. The ordering of Constituent SR Policy sub-TLVs does not matter. The Constituent SR Policy sub-TLV MAY contain a Weight sub-TLV. Since a candidate path is either dynamic, explicit or composite, the Constituent SR Policy sub-TLV and the Segment List sub-TLV SHOULD NOT appear in the same candidate path.
The Constituent SR Policy 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 | RESERVED | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Color | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | sub-TLVs | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
where: Type: to be assigned by IANA. Length: the total length of the value field not including Type and Length fields. RESERVED: 2 octet of reserved bits. SHOULD be set to zero on transmission and MUST be ignored on receipt. Color: 4-octet value identifying the constituent SR policy. sub-TLVs currently defined: An optional single Weight sub-TLV which is defined in section 2.4.4.1 in . According to , the fraction of flows steered into each constituent SR Policy is equal to the relative weight of each constituent SR Policy.
The document does not bring new operation beyond the description of operations defined in . The existing operations defined in can apply to this document directly. Typically but not limit to, the SR policies carrying composite candidate path information are configured by a controller. After configuration, the SR policies carrying path composite candidate path information will be advertised by BGP update messages. The operation of advertisement is the same as defined in , as well as the receiption.
Procedures and protocol extensions defined in this document do not affect the security considerations discussed in .
This document defines a new Sub-TLV in registries "SR Policy List Sub-TLVs" : Value Description Reference TBA Constituent SR Policy Sub-TLV This document
Advertising Segment Routing Policies in BGP This document defines a new BGP SAFI with a new NLRI in order to advertise a candidate path of a Segment Routing (SR) Policy. An SR Policy is a set of candidate paths, each consisting of one or more segment lists. The headend of an SR Policy may learn multiple candidate paths for an SR Policy. Candidate paths may be learned via a number of different mechanisms, e.g., CLI, NetConf, PCEP, or BGP. This document specifies the way in which BGP may be used to distribute SR Policy candidate paths. New sub-TLVs for the Tunnel Encapsulation Attribute are defined for signaling information about these candidate paths. Key words for use in RFCs to Indicate Requirement Levels 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. Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words 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. Segment Routing Architecture 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. Segment Routing Policy Architecture Segment Routing (SR) allows a headend node to steer a packet flow along any path. Intermediate per-flow states are eliminated thanks to source routing. The headend node steers a flow into an SR Policy. The header of a packet steered in an SR Policy is augmented with an ordered list of segments associated with that SR Policy. This document details the concepts of SR Policy and steering into an SR Policy. This document updates RFC 8402 as it details the concepts of SR Policy and steering into an SR Policy. Use Cases for Parent SR Policy Segment Routing (SR) allows a headend node to steer a packet flow along any path. Intermediate per-flow states are eliminated thanks to source routing. The headend node steers a flow into an SR Policy. The header of a packet steered in an SR Policy is augmented with an ordered list of segments associated with that SR Policy. This document details the concepts of SR Policy and steering into an SR Policy.