SR Policies Extensions for Network Resource Partition in BGP-LS

Introduction Segment Routing (SR) Policy is an ordered list of segments (i.e. instructions) that represent a source-routed policy. Packet flows are steered into a SR Policy on a node where it is instantiated called a headend node. The packets steered into an SR Policy carry an ordered list of segments associated with that SR Policy. provides the definition of IETF network slice for use within the IETF and discusses the general framework for requesting and operating IETF Network Slices, their characteristics, and the necessary system components and interfaces.It also introduces the concept Network Resource Partition (NRP), which is a subset of the resources and associated policies in the underlay network. introduces a scalable data plane approach to support Network Slice is to carry a dedicated NRP ID in the data packet to identify the NRP the packet belongs to, so that the packet can be processed and forwarded using the subset of network resources allocated to the NRP. For SR Policy with IPv6 data plane, the approach to encapsulate the NRP ID in IPv6 Hop-by-Hop Options header is defined in . For SR Policy with MPLS data plane, one approach to encapsulate the NRP ID to the packet is defined in . defines the extensions to BGP SR policy to specify the NRP which the SR Policy candidate path is associated with. describes a mechanism to distribute SR policy information to external components using BGP-LS. SR policy information can be used by external components for path computation, re-optimization, service placement, network visualization, etc. A Network Resource Partition (NRP) is a subset of the network resources and associated policies on each of a connected set of links in the underlay network. The SR policy indicates the forwarding path of the data packet, and the NRP ID indicates the reserved resources along the path specified by the SR policy. By associating the SR policy with a specific NRP, the forwarding path and resource reservation along the path are ensured. BGP-LS reports the association between SR Policy Candidate Path (CP) and NRP-ID, which is used to synchronize the association information between the SR Policy CP and the NRP-ID. This document defines a new TLV which enables the headend to report the NRP which the SR Policy CP is associated with by using BGP-LS.

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.

Carrying NRP TLV in BGP-LS A SR Policy CP MAY be instantiated with a specific NRP on the headend node via a local configuration, PCEP, or BGP SR Policy signaling. Then the state and attributes of the NRP associated with the candidate path of SR policy can be distributed to the controller. In order to collect configuration and states of the NRP SR policy, this document defines a new SR Policy state TLV called the NRP TLV which enables the headend to report the state at the SR Policy CP level. This TLV is carried in the optional non-transitive BGP Attribute "LINK_STATE Attribute" defined in associated with the SR Policy CP NLRI type. This TLV is optional and only one these TLVs is advertised for a given SR Policy CP. If multiple TLVs are present, then the first one is considered valid and the rest are ignored as describe in . The TLV has the following format: where: Type: TBD. Length: 8. The total length of the value field not including Type and Length fields. Flag: 2-octet flag field. None is defined at this stage. The flags SHOULD be set to zero on transmission and MUST be ignored on receipt. RESERVED: 2-octet reserved bits. It SHOULD be set to zero on transmission and MUST be ignored on receipt. NRP ID: 4-octet domain significant identifier of Network Resource Partition. Value 0 and 0xFFFFFFFF are reserved. NRP ID is planned by network operator.

Scalability Considerations The mechanism specified in this document defines a mechanism for the headend of the SR policy to report configuration and states of an SR policy carrying the NRP information by using BGP-LS. Although the proposed mechanism allows an NRP MAY support many SR policies, in normal case the association between the SR Policy and the NRP is considered to be 1:1. As the number of NRP increases, the number of SR Policies would also increase accordingly, and the status reported by the headend increases accordingly. However, the relationship between the SR Policy and the NRP is relatively stable and does not change status frequently. On the other hand this will only cause an increase in the status reporting information of the head node, the impacts to the BGP control plane are considered acceptable.

Acknowledgements The authors would like to thank Susan Hares, Joel Halpern, Ketan Talaulikar, Vishnu Pavan Beeram, Adrian Farrel, and Changwang Lin for their review and discussion of this document.

IANA Considerations IANA maintains a registry group called "Border Gateway Protocol - Link State (BGP-LS) Parameters" with a registry called "BGP-LS NLRI and Attribute TLVs". The following TLV codepoints are suggested (for early allocation by IANA):

Security Considerations Procedures and protocol extensions defined in this document do not affect the BGP security model. See the "Security Considerations"section of for a discussion of BGP security. Security considerations for acquiring and distributing BGP-LS information are discussed in . Security considerations for acquiring and distributing BGP-LS SR Policy information are discussed in . Additionally, it MAY be considered that reporting the NRP ID in association with the SR policy constitutes a risk to confidentiality of mission-critical or commercially sensitive information about the network. It is the responsibility of the network operator to ensure that only trusted nodes (that include both routers and controller applications) within the SR domain are configured to receive such information.