]> New H3C Technologies

China linchangwang.04414@h3c.com

China Mobile

China gongliyan@chinamobile.com

rtg IDR Working Group YANG, BGP, SR Policy, Segment Routing This document defines a YANG data model for the BGP Segment Routing (SR) Policy address families (RFC 9830). The model augments the BGP YANG model to add the IPv4 SR Policy (AFI, SAFI = 1, 73) and IPv6 SR Policy (AFI, SAFI = 2, 73) address families, including SR Policy-specific configuration, the SR Policy RIB, per-neighbor Adj-RIBs, and the decoded SR Policy candidate path information, such as preference, Binding SID, and segment lists.

Introduction Segment Routing (SR) allows a headend node to steer a packet flow along a specific path. An SR Policy is an ordered list of segments that define a source-routed policy. An SR Policy consists of one or more Candidate Paths (CPs), each comprising one or more segment lists, and a Binding SID (BSID) may be associated with the selected CP of an SR Policy. specifies how BGP can be used to distribute SR Policy candidate paths. It introduces an SR Policy Subsequent Address Family Identifier (SAFI) with code point 73 for the IPv4 (AFI = 1) and IPv6 (AFI = 2) address families, where the Network Layer Reachability Information (NLRI) identifies an SR Policy candidate path as the tuple <Distinguisher, Color, Endpoint>, and the candidate path details are encoded in sub-TLVs of the Tunnel Encapsulation Attribute with a Tunnel Type set to "SR Policy" (code point 15). These sub-TLVs include the Preference, Binding SID, SRv6 Binding SID, Segment List, Explicit NULL Label Policy (ENLP), Priority, SR Policy Name, and SR Policy Candidate Path Name sub-TLVs. also updates the Color Extended Community of to support additional steering modes. Additional Segment sub-TLVs for segment types other than the SR-MPLS label and SRv6 SID types are defined in . The BGP YANG model defines a vendor-neutral YANG model for BGP protocol configuration, policy, and operational state, including a Routing Information Base (RIB). It defines an extension pattern for adding new address families: a new identity derived from 'afi-safi-type' in the IANA-maintained 'iana-bgp-afi-safi-types' module, together with augmentations of the AFI/SAFI lists in the global configuration tree and in the RIB tree (Appendix B of ). This document applies this address family extension pattern to the SR Policy address families, whose NLRI is carried as MP_REACH_NLRI/MP_UNREACH_NLRI per . It defines a YANG module, "ietf-bgp-sr-policy", that registers the SR Policy address family identities, adds SR Policy-specific configuration and RIB augmentation, and defines the decoded SR Policy candidate path information as reusable groupings. This model covers the BGP protocol level of SR Policy signaling; the YANG data model for the operation and management of SR Policies at the SR Policy Module (SRPM) level is defined in , which, per Section 8 of , reports the SR Policies provisioned via the BGP SR Policy SAFI along with their operational states.

Terminology and Notation Conventions

Terminology The following terms are used in this document:

• SR Policy: An ordered list of segments (instructions) that define a source-routed policy .
• Candidate Path (CP): A single path associated with an SR Policy, comprising one or more segment lists .
• SRPM: SR Policy Module, the functional element on the headend that learns candidate paths, selects the active candidate path, and installs it in the forwarding plane .
• BSID: Binding SID, a segment identifier associated with an SR Policy .
• ENLP: Explicit NULL Label Policy .
• AFI/SAFI: Address Family Identifier / Subsequent Address Family Identifier .
• Loc-RIB: The local RIB containing the routes selected by the local BGP speaker.
• Adj-RIB-In / Adj-RIB-Out: Per-neighbor routing information bases for received and advertised routes, respectively.

Tree Diagrams Tree diagrams used in this document follow the notation defined in .

Data Model Overview This document defines one YANG module: "ietf-bgp-sr-policy". The "ietf-bgp-sr-policy" YANG module extends the BGP YANG model with the SR Policy address families. It lives under the BGP protocol instance, reusing the base model's AFI/SAFI configuration structure, RIB structure, and route annotations. It includes:

• SR Policy address family identities: 'ipv4-sr-policy' (AFI, SAFI = 1, 73) and 'ipv6-sr-policy' (AFI, SAFI = 2, 73) .
• SR Policy-specific configuration for the global AFI/SAFI, such as the prefix limit, the control of the propagation of SR Policy NLRIs to EBGP neighbors, and the handling of unsupported sub-TLVs.
• The SR Policy RIB: a Loc-RIB of SR Policy candidate paths selected by the BGP best-path selection algorithm, and per-neighbor Adj-RIB-In/Out tables (pre- and post-policy).
• Decoded SR Policy candidate path information: the preference, priority, policy name, candidate path name, ENLP, Binding SID, SRv6 Binding SIDs, and the segment lists with their weight and segments, decoded from the sub-TLVs of the SR Policy Tunnel Type of the Tunnel Encapsulation Attribute (Sections 2.2 and 2.4 of ).

Network management applications enable the SR Policy address family on a BGP instance by creating an entry in the global 'afi-safi' list with one of the SR Policy identities as the 'name', following the same procedure as for any other address family in the base model.

BGP SR Policy YANG Module

Tree View The full tree of the "ietf-bgp-sr-policy" YANG module is provided in . The following subsections list the subtree structures.

Overall Structure The overall tree structure of the "ietf-bgp-sr-policy" YANG module is shown in . The "ietf-bgp-sr-policy" YANG module augments the BGP YANG module "ietf-bgp" at two points. The first augmentation adds SR Policy-specific configuration to the global AFI/SAFI list; the second augmentation adds the SR Policy RIB to the RIB AFI/SAFI tree. Both augmentations are active only when the AFI/SAFI name is derived from the 'ipv4-sr-policy' or 'ipv6-sr-policy' identities.

Overall BGP SR Policy Tree Structure

The first augmentation has a container 'sr-policy', which provides the SR Policy-specific configuration for an SR Policy AFI/SAFI instance. The second augmentation has a container 'sr-policy', which holds the SR Policy RIB: the Loc-RIB of the SR Policy candidate paths selected by the BGP best-path selection algorithm, and the per-neighbor Adj-RIB tables.

SR Policy Configuration The SR Policy configuration structure is shown in .

SR Policy Configuration Subtree Structure

The configuration data nodes of the container 'sr-policy' are described as follows: 'prefix-limit': The prefix limit imported from the base model's 'mp-all-afi-safi-common' grouping , which limits the number of SR Policy routes accepted from a peer. 'propagate-to-ebgp': Controls the propagation of received SR Policy NLRIs to EBGP neighbors. By default, a BGP node receiving an SR Policy NLRI does not propagate it to any EBGP neighbor (Section 4.2.3 of ). Setting this leaf to 'true' enables the propagation of valid SR Policy NLRIs to EBGP neighbors, which is applicable when the SR domain comprises multiple Autonomous Systems (ASes) within a single service provider domain. The default is 'false'. 'ignore-unsupported-subtlvs': When an SR Policy tunnel type includes a sub-TLV that is unrecognized or unsupported, the update is not considered usable by default, and an implementation may provide an option for ignoring unsupported sub-TLVs (Section 4.2.2 of ). Setting this leaf to 'true' enables that option, so that an update containing unrecognized or unsupported sub-TLVs may still be considered usable and passed to the SRPM. The default is 'false'.

SR Policy RIB The SR Policy RIB structure is shown in .

SR Policy RIB Subtree Structure

The 'loc-rib' contains the set of SR Policy candidate paths selected by the BGP best-path selection algorithm (Section 9.1 of ) and eligible to be passed to the SRPM. The route entry is keyed by the <Distinguisher, Color, Endpoint> tuple of the SR Policy NLRI , which uniquely identifies an SR Policy candidate path; the NLRI fields have fixed positions and lengths (Section 2.1 of ), so the tuple uniquely identifies the route across implementations. The 'active' leaf indicates whether the candidate path is usable (Section 4.2.2 of ) and has been passed to the SRPM for candidate path selection as described in Section 2.9 of . The 'neighbors' container lists the SR Policy neighbors. For each neighbor, the model provides four tables: Adj-RIB-In pre-policy and post-policy, and Adj-RIB-Out pre-policy and post-policy. Each table contains a list of routes keyed by 'distinguisher', 'color', 'endpoint', and 'path-id'. The structure of an Adj-RIB route entry is shown in .

SR Policy Adj-RIB Route Entry Subtree Structure

Route entries reuse the base model's route-annotation groupings ('bgp-common-route-annotations-state', 'bgp-adj-rib-attr-state', attribute and community index references, 'bgp-unknown-attr-top', and 'rib-ext-route-annotations') , so that operators see the same operational state attributes for SR Policy routes as for any other address family. The Adj-RIB-In post-policy table additionally uses the 'bgp-adj-rib-in-post-route-annotations-state' grouping, which provides the 'best-path' flag. The BGP decision process for the SR Policy SAFI selects the best route, which is considered "usable" for passing on to the SRPM and is also propagated irrespective of its usability (Section 4.2 of ).

Candidate Path Information The module defines the 'sr-policy-candidate-path' grouping, which models the decoded contents of the SR Policy Tunnel Type of the Tunnel Encapsulation Attribute , i.e., the SR Policy candidate path information. It is attached to the Loc-RIB route entries and to the Adj-RIB route entries of the SR Policy RIB, so that operators can inspect the candidate path details -- preference, priority, policy name, candidate path name, ENLP, Binding SID, SRv6 Binding SIDs, and segment lists with their weight and segments -- without decoding the raw Tunnel Encapsulation Attribute (which remains available in the attribute sets referenced by the route annotations). The structure of the candidate path information is shown in .

SR Policy Candidate Path Subtree Structure

All the sub-TLVs of the SR Policy tunnel type are optional (Section 2.4 of ); a leaf or container that is absent indicates that the corresponding sub-TLV was not present in the received SR Policy encoding. Where more than one instance of a single-instance sub-TLV was received, only the first instance is reported, per Section 2.4 of . The 'binding-sid' container models the Binding SID sub-TLV (Section 2.4.2 of ), including the "Specified-BSID-Only" (S) and "Drop-Upon-Invalid" (I) flags; the 'srv6-binding-sids' list models the SRv6 Binding SID sub-TLV (Section 2.4.3 of ), of which more than one instance may be signaled, together with the SRv6 Endpoint Behavior and SID Structure encoding of Section 2.4.4.2.4 of . The 'segment-lists' container models the Segment List sub-TLVs (Section 2.4.4 of ): each entry is a single explicit path with an optional weight, and its segments are reported in the order in which they are encoded in the Segment List sub-TLV. The Segment Type A (SR-MPLS label ) and Type B (SRv6 SID ) sub-TLVs are modeled; the additional segment types specified in are left to future revisions of this document. The 'enlp' leaf models the Explicit NULL Label Policy sub-TLV (Section 2.4.5 of ); when it is absent, the decision of whether to push an Explicit NULL label is a matter of local configuration. The presence of an SRv6 Endpoint Behavior and SID Structure is indicated by the presence of the corresponding leaves, which corresponds to the B-Flag of the segment and SRv6 Binding SID flags. The 'sr-policy-segment', 'sr-policy-binding-sid', and 'srv6-endpoint-behavior-sid-structure' groupings are defined in this revision as reusable building blocks for future revisions of this document that may attach the candidate path structure to locally configured SR Policies or to the operational state of the steering. This initial version provides the SR Policy address family infrastructure as a basic subset: the SR Policy configuration and operational state of the SRPM itself, including the selection of the active candidate path and the steering of service routes, are modeled by and are outside the scope of this document.

YANG Module This YANG module has normative references to , , , , , and (the 'ysv:version' extension used to tag the module revision with a semantic version). WG List: IDR Author: Changwang Lin "; description "This module contains YANG definitions for the BGP Segment Routing (SR) Policy address families. It extends the BGP YANG model defined in RFC XXXX with the IPv4 SR Policy (AFI, SAFI = 1, 73) and IPv6 SR Policy (AFI, SAFI = 2, 73) address families, per RFC 9830, and adds the corresponding RIB contents and the decoded SR Policy candidate path information. Copyright (c) 2026 IETF Trust and the persons identified as authors of the code. All rights reserved. Redistribution and use in source and binary forms, with or without modification, is permitted pursuant to, and subject to the license terms contained in, the Revised BSD License set forth in Section 4.c of the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info). This version of this YANG module is part of RFC YYYY; see the RFC itself for full legal notices. All revisions of IETF and IANA published modules can be found at the YANG Parameters registry group (https://www.iana.org/assignments/yang-parameters)."; revision 2026-11-02 { description "Initial Version"; ysv:version 0.0.1; reference "RFC YYYY: YANG Model for BGP Segment Routing Policy"; } /* * Features. */ feature sr-mpls { description "The implementation supports SR-MPLS Binding SIDs and SR-MPLS label segments of an SR Policy candidate path."; reference "RFC 8660: Segment Routing with the MPLS Data Plane"; } feature srv6 { description "The implementation supports SRv6 Binding SIDs and SRv6 SID segments of an SR Policy candidate path."; reference "RFC 8986: Segment Routing over IPv6 (SRv6) Network Programming"; } /* * Identities. */ identity ipv4-sr-policy { base bast:afi-safi-type; description "IPv4 SR Policy (AFI, SAFI = 1, 73)."; reference "RFC 9830: Advertising Segment Routing Policies in BGP"; } identity ipv6-sr-policy { base bast:afi-safi-type; description "IPv6 SR Policy (AFI, SAFI = 2, 73)."; reference "RFC 9830: Advertising Segment Routing Policies in BGP"; } /* * Typedefs. */ typedef sr-policy-enlp { type enumeration { enum push-ipv4-null { value 1; description "Push an IPv4 Explicit NULL label on an unlabeled IPv4 packet but do not push an IPv6 Explicit NULL label on an unlabeled IPv6 packet."; } enum push-ipv6-null { value 2; description "Push an IPv6 Explicit NULL label on an unlabeled IPv6 packet but do not push an IPv4 Explicit NULL label on an unlabeled IPv4 packet."; } enum push-both-null { value 3; description "Push an IPv4 Explicit NULL label on an unlabeled IPv4 packet and push an IPv6 Explicit NULL label on an unlabeled IPv6 packet."; } enum no-push { value 4; description "Do not push an Explicit NULL label."; } } description "Explicit NULL Label Policy (ENLP) for unlabeled IP packets that are steered into an SR Policy for the MPLS data plane. The value of the enumeration corresponds to the ENLP value defined in RFC 9830."; reference "RFC 9830: Advertising Segment Routing Policies in BGP, Section 2.4.5"; } /* * Groupings. */ grouping srv6-endpoint-behavior-sid-structure { description "SRv6 Endpoint Behavior and SID Structure encoding, as defined in Section 2.4.4.2.4 of RFC 9830. The presence of these leaves corresponds to the B-Flag of the SR Policy Segment Flags or of the SR Policy SRv6 Binding SID Flags."; leaf endpoint-behavior { type uint16; description "SRv6 Endpoint Behavior code point for this SRv6 SID as defined in Section 10.2 of RFC 8986. The value 65535 (Opaque) leaves the choice of the SRv6 Endpoint Behavior to the headend."; reference "RFC 8986: Segment Routing over IPv6 (SRv6) Network Programming, Section 10.2"; } leaf locator-block-length { type uint8; units "bits"; description "SRv6 SID Locator Block length in bits."; reference "RFC 8986: Segment Routing over IPv6 (SRv6) Network Programming, Section 3.2"; } leaf locator-node-length { type uint8; units "bits"; description "SRv6 SID Locator Node length in bits."; reference "RFC 8986: Segment Routing over IPv6 (SRv6) Network Programming, Section 3.2"; } leaf function-length { type uint8; units "bits"; description "SRv6 SID Function length in bits."; reference "RFC 8986: Segment Routing over IPv6 (SRv6) Network Programming, Section 3.2"; } leaf argument-length { type uint8; units "bits"; description "SRv6 SID Arguments length in bits. The total of the locator block, locator node, function, and argument lengths must be less than or equal to 128."; reference "RFC 8986: Segment Routing over IPv6 (SRv6) Network Programming, Section 3.2"; } } grouping sr-policy-segment { description "A single segment of a segment list, i.e., a single element of the explicit path of an SR Policy candidate path, as encoded in a Segment sub-TLV of the Segment List sub-TLV (Section 2.4.4.2 of RFC 9830). The segment types defined in RFC 9830 (Type A: SR-MPLS label, Type B: SRv6 SID) are modeled; the additional segment types specified in RFC 9831 are left to future revisions of this document. A mix of SR-MPLS and SRv6 segments makes the segment list invalid, per Section 5.1 of RFC 9256."; leaf index { type uint32; description "Position of the segment in the explicit path. The segments are reported in the order in which they are encoded in the Segment List sub-TLV, starting with index 1; this is the order in which the segments are pushed on the packets steered into the SR Policy."; } leaf sid-verification { type boolean; description "When true (V-Flag of the SR Policy Segment Flags), the originator requested SID verification of this segment, which is used by the SRPM as described in Section 5.1 of RFC 9256."; reference "RFC 9830: Advertising Segment Routing Policies in BGP, Section 2.4.4.2.3"; } choice segment-type { description "The segment type. Only the Segment Type A (SR-MPLS label) and Type B (SRv6 SID) sub-TLVs of RFC 9830 are modeled in this revision."; case type-a { if-feature "sr-mpls"; description "SR-MPLS label segment (Segment Type A, Section 2.4.4.2.1 of RFC 9830)."; leaf mpls-label { type uint32 { range "16..1048575"; } description "The 20-bit label value. The reserved MPLS label values (0-15) are not valid values."; reference "RFC 3032: MPLS Label Stack Encoding, RFC 5462: Multiprotocol Label Switching (MPLS) Label Stack Entry: 'EXP' Field Renamed to 'Traffic Class' Field"; } leaf traffic-class { type uint8 { range "0..7"; } description "Traffic Class (TC) field of the label. The value 0 indicates that the originator wants the receiver to choose the TC value."; } leaf ttl { type uint8; description "TTL field of the label. The value 255 indicates that the originator wants the receiver to choose the TTL value."; } } case type-b { if-feature "srv6"; description "SRv6 SID segment (Segment Type B, Section 2.4.4.2.2 of RFC 9830)."; leaf srv6-sid { type inet:ipv6-address; description "The SRv6 SID of the segment."; } uses srv6-endpoint-behavior-sid-structure; } } } grouping sr-policy-binding-sid { description "Binding SID information of an SR Policy candidate path, as encoded in the Binding SID sub-TLV (Section 2.4.2 of RFC 9830)."; leaf specified-bsid-only { type boolean; description "When true (S-Flag), encodes the 'Specified-BSID-Only' behavior: the SR Policy is not instantiated unless the specified BSID is available."; reference "RFC 9256: Segment Routing Policy Architecture, Section 6.2.3."; } leaf drop-upon-invalid { type boolean; description "When true (I-Flag), encodes the 'Drop-Upon-Invalid' behavior: the SR Policy is to drop traffic steered over it when no valid candidate path is available, per Section 8.2 of RFC 9256."; reference "RFC 9256: Segment Routing Policy Architecture, Section 8.2."; } choice bsid { description "The Binding SID value. When no BSID is present (sub-TLV length 2), the 'none' case is selected."; case none { leaf none { type empty; description "No BSID is present."; } } case mpls { if-feature "sr-mpls"; leaf mpls-label { type uint32 { range "16..1048575"; } description "SR-MPLS Binding SID label value. The reserved MPLS label values (0-15) are not valid values. The TC, S, and TTL bits of the label encoding are reserved and are not modeled."; } } case srv6 { if-feature "srv6"; leaf srv6-sid { type inet:ipv6-address; description "SRv6 Binding SID. The support for the use of the Binding SID sub-TLV for the signaling of an SRv6 BSID is retained primarily for backward compatibility; it is recommended to signal an SRv6 BSID using the SRv6 Binding SID sub-TLV instead (Section 2.4.2 of RFC 9830)."; } } } } grouping sr-policy-srv6-binding-sid { description "An entry of the SRv6 Binding SID sub-TLVs (Section 2.4.3 of RFC 9830). More than one SRv6 Binding SID sub-TLV may be signaled in the same SR Policy encoding to indicate one or more SRv6 SIDs, each with potentially different SRv6 Endpoint Behaviors to be instantiated."; leaf sid { type inet:ipv6-address; description "The SRv6 Binding SID. The unspecified address (::) may be used when the originator wants to indicate the desired SRv6 Endpoint Behavior, SID Structure, or flags without specifying the BSID."; } leaf specified-bsid-only { type boolean; description "When true (S-Flag), encodes the 'Specified-BSID-Only' behavior, per Section 6.2.3 of RFC 9256."; } leaf drop-upon-invalid { type boolean; description "When true (I-Flag), encodes the 'Drop-Upon-Invalid' behavior, per Section 8.2 of RFC 9256."; } uses srv6-endpoint-behavior-sid-structure; } grouping sr-policy-segment-lists { description "Segment List sub-TLVs of an SR Policy candidate path (Section 2.4.4 of RFC 9830). Each entry encodes a single explicit path towards the Endpoint as described in Section 5.1 of RFC 9256. The ordering of Segment List sub-TLVs does not matter; the 'index' is an implementation-assigned identifier."; container segment-lists { description "Enclosing container for the list of segment lists of the candidate path."; list segment-list { key "index"; description "A single explicit path towards the Endpoint, per Section 5.1 of RFC 9256."; leaf index { type uint32; description "Implementation-assigned identifier of this segment list within the candidate path."; } container weight { description "Weight of the segment list, as encoded in the Weight sub-TLV (Section 2.4.4.1 of RFC 9830). This container is absent when no Weight sub-TLV was received; the weight of a segment list without a Weight sub-TLV is then a matter of local policy."; leaf value { type uint32 { range "1..4294967295"; } description "Weight associated with the segment list, used for load balancing across the segment lists of the SR Policy as described in Section 2.11 of RFC 9256. A weight value of zero is invalid."; } } container segments { description "Enclosing container for the segments of the explicit path."; list segment { key "index"; uses sr-policy-segment; description "Ordered list of the segments of the explicit path. A mix of SR-MPLS and SRv6 segments makes the segment list invalid, per Section 5.1 of RFC 9256."; } } } } } grouping sr-policy-candidate-path { description "Decoded SR Policy candidate path information, obtained from the SR Policy Tunnel Type (code point 15) of the Tunnel Encapsulation Attribute (Sections 2.2 and 2.4 of RFC 9830). All sub-TLVs are optional; a leaf or container that is absent indicates that the corresponding sub-TLV was not present in the SR Policy encoding. Where more than one instance of a single-instance sub-TLV was received, only the first instance is reported, per Section 2.4 of RFC 9830."; container candidate-path { config false; description "SR Policy candidate path information."; leaf preference { type uint32; description "Preference of the SR Policy candidate path, as encoded in the Preference sub-TLV (Section 2.4.1 of RFC 9830). It is used by the SRPM for the selection of the active candidate path as described in Section 2.7 of RFC 9256."; } leaf priority { type uint8; description "Priority of the SR Policy, as encoded in the Priority sub-TLV (Section 2.4.6 of RFC 9830). It indicates the order in which the SR policies are recomputed upon topological change, as described in Section 2.12 of RFC 9256."; } leaf policy-name { type string; description "Symbolic name of the SR Policy, as encoded in the SR Policy Name sub-TLV (Section 2.4.8 of RFC 9830)."; } leaf candidate-path-name { type string; description "Symbolic name of the SR Policy candidate path, as encoded in the SR Policy Candidate Path Name sub-TLV (Section 2.4.7 of RFC 9830)."; } leaf enlp { type sr-policy-enlp; description "Explicit NULL Label Policy of the SR Policy, as encoded in the ENLP sub-TLV (Section 2.4.5 of RFC 9830). This leaf is absent when no ENLP sub-TLV was received; the decision of whether to push an Explicit NULL label on unlabeled IP packets steered into the SR Policy is then a matter of local configuration."; } container binding-sid { description "Binding SID of the SR Policy candidate path, as encoded in the Binding SID sub-TLV (Section 2.4.2 of RFC 9830). This container is absent when no Binding SID sub-TLV was received."; uses sr-policy-binding-sid; } container srv6-binding-sids { if-feature "srv6"; description "Enclosing container for the SRv6 Binding SID sub-TLVs (Section 2.4.3 of RFC 9830). More than one SRv6 Binding SID sub-TLV may be signaled in the same SR Policy encoding."; list srv6-binding-sid { key "sid"; uses sr-policy-srv6-binding-sid; description "An SRv6 Binding SID, together with the SRv6 Endpoint Behavior and SID Structure to be instantiated on the headend node. The presence of the SRv6 Endpoint Behavior and SID Structure leaves corresponds to the B-Flag of the SR Policy SRv6 Binding SID Flags."; } } uses sr-policy-segment-lists; } } grouping sr-policy-nlri-keys { description "Key leaves identifying an SR Policy NLRI, per Section 2.1 of RFC 9830. The SR Policy NLRI is the tuple ."; leaf distinguisher { type uint32; description "The Distinguisher field of the SR Policy NLRI. It has no semantic value; it is used by the SR Policy originator to differentiate multiple candidate paths of the same SR Policy, and candidate paths meant for different headends but having the same Color and Endpoint."; } leaf color { type uint32 { range "1..4294967295"; } description "The Color of the SR Policy, an unsigned non-zero integer value. The Color is used to match the Color of the destination prefixes to steer traffic into the SR Policy as specified in Section 8 of RFC 9256."; } leaf endpoint { type inet:ip-address; description "The Endpoint of the SR Policy, an IPv4 (4-octet) or IPv6 (16-octet) address according to the AFI of the NLRI. It identifies the Endpoint of the SR Policy, which may represent a single node or a set of nodes (e.g., an anycast address). The unspecified address (0.0.0.0 for IPv4, :: for IPv6) is the null Endpoint."; } } grouping sr-policy-adj-rib { description "Common structural grouping for each SR Policy Adj-RIB table."; container routes { config false; description "Enclosing container for the list of SR Policy routes in the routing table."; list route { key "distinguisher color endpoint path-id"; description "List of SR Policy routes in the table, keyed by the SR Policy NLRI and path-id to distinguish multiple routes for the same NLRI (e.g., when BGP add-paths is enabled)."; uses sr-policy-nlri-keys; uses bgp:bgp-adj-rib-attr-state; uses bgp:bgp-adj-rib-common-attr-refs; uses bgp:bgp-common-route-annotations-state; uses bgp:bgp-unknown-attr-top; uses bgp:rib-ext-route-annotations; uses sr-policy-candidate-path; } } } grouping sr-policy-adj-rib-in-post { description "Common structural grouping for the SR Policy Adj-RIB-In post-policy table."; container routes { config false; description "Enclosing container for the list of SR Policy routes in the routing table."; list route { key "distinguisher color endpoint path-id"; description "List of SR Policy routes in the table, keyed by the SR Policy NLRI and path-id to distinguish multiple routes for the same NLRI (e.g., when BGP add-paths is enabled)."; uses sr-policy-nlri-keys; uses bgp:bgp-adj-rib-attr-state; uses bgp:bgp-adj-rib-common-attr-refs; uses bgp:bgp-common-route-annotations-state; uses bgp:bgp-adj-rib-in-post-route-annotations-state; uses bgp:bgp-unknown-attr-top; uses bgp:rib-ext-route-annotations; uses sr-policy-candidate-path; } } } /* * Data nodes. */ augment "/rt:routing/rt:control-plane-protocols/" + "rt:control-plane-protocol/bgp:bgp/bgp:global/" + "bgp:afi-safis/bgp:afi-safi" { when "derived-from-or-self(bgp:name, 'bsp:ipv4-sr-policy') or " + "derived-from-or-self(bgp:name, 'bsp:ipv6-sr-policy')" { description "This augmentation is valid for an SR Policy AFI/SAFI instance."; } description "BGP SR Policy specific configuration that applies to the global AFI/SAFI."; container sr-policy { description "SR Policy specific configuration for the AFI/SAFI."; uses bgp:mp-all-afi-safi-common; leaf propagate-to-ebgp { type boolean; default "false"; description "When false (the default), received SR Policy NLRIs are not propagated to any EBGP neighbor, per Section 4.2.3 of RFC 9830. When true, valid SR Policy NLRIs may be propagated to EBGP neighbors, which is applicable when the SR domain comprises multiple ASes within a single service provider domain."; reference "RFC 9830: Advertising Segment Routing Policies in BGP, Section 4.2.3."; } leaf ignore-unsupported-subtlvs { type boolean; default "false"; description "When false (the default), an SR Policy update whose SR Policy tunnel type includes a sub-TLV that is unrecognized or unsupported is not considered usable, per Section 4.2.2 of RFC 9830. When true, unsupported sub-TLVs are ignored, so that an update containing unrecognized or unsupported sub-TLVs may still be considered usable and passed to the SRPM."; reference "RFC 9830: Advertising Segment Routing Policies in BGP, Section 4.2.2."; } } } augment "/rt:routing/rt:control-plane-protocols/" + "rt:control-plane-protocol/bgp:bgp/bgp:rib/" + "bgp:afi-safis/bgp:afi-safi" { when "derived-from-or-self(bgp:name, 'bsp:ipv4-sr-policy') or " + "derived-from-or-self(bgp:name, 'bsp:ipv6-sr-policy')" { description "This augmentation is valid for an SR Policy AFI/SAFI instance."; } description "BGP SR Policy RIB augmentation."; container sr-policy { config false; description "Container for the BGP SR Policy RIB."; container loc-rib { description "The SR Policy Loc-RIB: the set of SR Policy candidate paths selected by the BGP best-path selection algorithm and eligible to be passed to the SRPM."; container routes { config false; description "Enclosing container for the list of SR Policy routes."; list route { key "distinguisher color endpoint"; description "List of SR Policy routes in the Loc-RIB, keyed by the tuple of the SR Policy NLRI."; uses sr-policy-nlri-keys; leaf active { type boolean; description "Indicates whether the SR Policy candidate path is usable (Section 4.2.2 of RFC 9830) and has been passed to the SRPM for candidate path selection as described in Section 2.9 of RFC 9256."; } uses bgp:bgp-common-route-annotations-state; uses bgp:bgp-loc-rib-common-attr-refs; uses bgp:rib-ext-route-annotations; uses sr-policy-candidate-path; } } } container neighbors { description "Enclosing container for the neighbor list."; list neighbor { key "neighbor-address"; description "List of SR Policy neighbors of the local BGP speaker."; leaf neighbor-address { type inet:ip-address; description "IP address of the BGP neighbor or peer."; } container adj-rib-in-pre { description "Per-neighbor table containing the SR Policy NLRI updates received from the neighbor before any local input policy rules have been applied."; uses sr-policy-adj-rib; } container adj-rib-in-post { description "Per-neighbor table containing the SR Policy paths received from the neighbor that are eligible for best-path selection after local input policy rules have been applied."; uses sr-policy-adj-rib-in-post; } container adj-rib-out-pre { description "Per-neighbor table containing SR Policy paths eligible for sending to the neighbor before output policy rules have been applied."; uses sr-policy-adj-rib; } container adj-rib-out-post { description "Per-neighbor table containing SR Policy paths eligible for sending to the neighbor after output policy rules have been applied."; uses sr-policy-adj-rib; } } } } } }]]>

Security Considerations This section is modeled after the template described in Section 3.7.1 of . The "ietf-bgp-sr-policy" YANG module defines a data model that is designed to be accessed via YANG-based management protocols, such as Network Configuration Protocol (NETCONF) and RESTCONF . These YANG-based management protocols (1) have to use a secure transport layer (e.g., Secure Shell (SSH) , TLS ) and (2) have to use mutual authentication. The Network Configuration Access Control Model (NACM) provides the means to restrict access for particular NETCONF or RESTCONF users to a preconfigured subset of all available NETCONF or RESTCONF protocol operations and content. There are a number of data nodes defined in this YANG module that are writable/creatable/deletable (i.e., config true, which is the default). All writable data nodes are likely to be sensitive or vulnerable in some network environments. Write operations (e.g., edit-config) and delete operations to these data nodes without proper protection or authentication can have a negative effect on network operations. In particular, the ability to enable or disable an SR Policy address family, to change the 'propagate-to-ebgp' or 'ignore-unsupported-subtlvs' settings, or to modify prefix limits may lead to SR Policy information being propagated outside of the SR domain, or to unusable SR Policy candidate paths being passed to the SRPM. The following subtrees and data nodes have particular sensitivities/vulnerabilities: Setting 'propagate-to-ebgp' to 'true' allows SR Policy advertisements to propagate to EBGP neighbors; the security considerations of Section 7 of require precaution to ensure that SR Policy information is limited to nodes within the trusted SR domain, and enabling EBGP propagation without care may leak endpoint addresses, SR SIDs, and traffic engineering policy information beyond the trusted SR domain. Setting 'ignore-unsupported-subtlvs' to 'true' causes updates that contain unsupported sub-TLVs to be considered usable, which may lead to SR Policies being passed to the SRPM with incomplete candidate path information. Changing prefix limits may allow an excessive number of SR Policy routes to be installed, exhausting device resources. Some of the readable data nodes in this YANG module may be considered sensitive or vulnerable in some network environments. It is thus important to control read access (e.g., via get, get-config, or notification) to these data nodes. The SR Policy RIB contents (the <Distinguisher, Color, Endpoint> tuples, the decoded candidate path information including segment lists and SR SIDs, and the per-neighbor Adj-RIB tables) reveal traffic engineering and service programming information about the network, which may be considered sensitive, as described in Section 7 of . The following subtrees and data nodes have particular sensitivities/vulnerabilities: There are no particularly sensitive RPC or action operations. The SR Policy mechanism itself allows traffic to be steered along specific paths on the basis of candidate paths disseminated via BGP; the security considerations of , , and apply to any deployment that uses the data model defined in this document.

IANA Considerations

BGP SR Policy YANG Module Registry IANA is requested to register the following URI in the "ns" registry within the "IETF XML Registry" group (): IANA is requested to register the following YANG module in the "YANG Module Names" registry () within the "YANG Parameters" registry group.

References Normative References This document describes an IANA maintained registry for IETF standards which use Extensible Markup Language (XML) related items such as Namespaces, Document Type Declarations (DTDs), Schemas, and Resource Description Framework (RDF) Schemas. The Secure Shell Protocol (SSH) is a protocol for secure remote login and other secure network services over an insecure network. This document describes the SSH authentication protocol framework and public key, password, and host-based client authentication methods. Additional authentication methods are described in separate documents. The SSH authentication protocol runs on top of the SSH transport layer protocol and provides a single authenticated tunnel for the SSH connection protocol. [STANDARDS-TRACK] This document defines extensions to BGP-4 to enable it to carry routing information for multiple Network Layer protocols (e.g., IPv6, IPX, L3VPN, etc.). The extensions are backward compatible - a router that supports the extensions can still interoperate with a router that doesn't support the extensions. YANG is a data modeling language used to model configuration and state data manipulated by the Network Configuration Protocol (NETCONF), NETCONF remote procedure calls, and NETCONF notifications. [STANDARDS-TRACK] The Network Configuration Protocol (NETCONF) defined in this document provides mechanisms to install, manipulate, and delete the configuration of network devices. It uses an Extensible Markup Language (XML)-based data encoding for the configuration data as well as the protocol messages. The NETCONF protocol operations are realized as remote procedure calls (RPCs). This document obsoletes RFC 4741. [STANDARDS-TRACK] YANG is a data modeling language used to model configuration and state data, Remote Procedure Calls, and notifications for network management protocols. This document describes the syntax and semantics of version 1.1 of the YANG language. YANG version 1.1 is a maintenance release of the YANG language, addressing ambiguities and defects in the original specification. There are a small number of backward incompatibilities from YANG version 1. This document also specifies the YANG mappings to the Network Configuration Protocol (NETCONF). This document describes an HTTP-based protocol that provides a programmatic interface for accessing data defined in YANG, using the datastore concepts defined in the Network Configuration Protocol (NETCONF). This document captures the current syntax used in YANG module tree diagrams. The purpose of this document is to provide a single location for this definition. This syntax may be updated from time to time based on the evolution of the YANG language. The standardization of network configuration interfaces for use with the Network Configuration Protocol (NETCONF) or the RESTCONF protocol requires a structured and secure operating environment that promotes human usability and multi-vendor interoperability. There is a need for standard mechanisms to restrict NETCONF or RESTCONF protocol access for particular users to a preconfigured subset of all available NETCONF or RESTCONF protocol operations and content. This document defines such an access control model. This document obsoletes RFC 6536. This document specifies three YANG modules and one submodule. Together, they form the core routing data model that serves as a framework for configuring and managing a routing subsystem. It is expected that these modules will be augmented by additional YANG modules defining data models for control-plane protocols, route filters, and other functions. The core routing data model provides common building blocks for such extensions -- routes, Routing Information Bases (RIBs), and control-plane protocols. The YANG modules in this document conform to the Network Management Datastore Architecture (NMDA). This document obsoletes RFC 8022. Independent This document specifies version 1.3 of the Transport Layer Security (TLS) protocol. TLS allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery. This document obsoletes RFC 8446, which specified TLS 1.3. This document obsoletes RFC 5246 (specifying TLS 1.2) and RFCs 5077, 6961, 7627, and 8422, all of which pertain to TLS 1.2 or earlier, and updates RFCs 5705 and 6066. This document also specifies new requirements for TLS 1.2 implementations. A Segment Routing (SR) Policy is an ordered list of segments (also referred to as "instructions") that define a source-routed policy. An SR Policy consists of one or more Candidate Paths (CPs), each comprising one or more segment lists. This document specifies how BGP can be used to distribute SR Policy candidate paths. It introduces a BGP SAFI for advertising a candidate path of an SR Policy and defines sub-TLVs for the Tunnel Encapsulation Attribute to signal information related to these candidate paths. Furthermore, this document updates RFC 9012 by extending the Color Extended Community to support additional steering modes over SR Policy. RFC 9911, DOI 10.17487/RFC9911 Kloud Services Arrcus Huawei HPE This document defines a YANG data model for configuring and managing BGP, including protocol, policy, and operational aspects, such as RIB, based on data center, carrier, and content provider operational requirements. Cisco Systems, Inc. Cisco Systems, Inc. Equinix Ericsson Nokia Everything OPS This document specifies a YANG extension along with guidelines for applying an extended set of semantic versioning rules to revisions of YANG artifacts (e.g., modules and packages). Additionally, this document defines a YANG extension for controlling module imports based on these modified semantic versioning rules. This document updates RFCs 7950, 9907, and 8525. Informative References This document discusses the Border Gateway Protocol (BGP), which is an inter-Autonomous System routing protocol. The primary function of a BGP speaking system is to exchange network reachability information with other BGP systems. This network reachability information includes information on the list of Autonomous Systems (ASes) that reachability information traverses. This information is sufficient for constructing a graph of AS connectivity for this purpose from which routing loops may be pruned, and, at the AS level, some policy decisions may be enforced. This document obsoletes RFC 1771. Segment Routing (SR) leverages the source routing paradigm. A node steers a packet through an ordered list of instructions, called segments. Each one of these instructions represents a function to be called at a specific location in the network. A variety of functions may be programmed on a node, including topology-related and service-related instructions. This document defines the SR architecture. Segment Routing (SR) leverages the source routing paradigm. A node steers a packet through an ordered list of instructions, called segments. This document describes how to represent SR segments over the MPLS data plane. The Segment Routing over IPv6 (SRv6) Network Programming framework enables a network operator or an application to specify several packet processing functions by encoding a sequence of instructions in the IPv6 packet header. This document defines the SRv6 network programming concept and its most basic functions. This document defines a BGP path attribute that can be used with any BGP address family to provide information needed by a router to create a tunnel that can be used as the forwarding path of the other routes being advertised by the protocol. This document obsoletes RFC 5512. Segment Routing (SR) allows a headend node to steer a packet flow along a specific path. A Segment Routing (SR) Policy is an ordered list of segments that define a source-routed policy. This document details the concepts of SR Policy and steering into an SR Policy, including the concepts of candidate paths, Binding SIDs, and their instantiation on the SR-MPLS and SRv6 data planes. "Advertising Segment Routing Policies in BGP" (RFC 9830) defines the Segment List sub-TLV of the Tunnel Encapsulation Attribute, which is used for the advertisement of Segment Routing (SR) Policies in BGP, together with the Segment sub-TLVs for the SR-MPLS label (Type A) and SRv6 SID (Type B) segment types. This document specifies the sub-TLVs used for the additional segment types for the Segment List sub-TLV. This document provides guidelines for authors and reviewers of specifications containing YANG data models, including IANA-maintained YANG modules. Recommendations and procedures are defined, which are intended to increase interoperability and usability of Network Configuration Protocol (NETCONF) and RESTCONF protocol implementations that utilize YANG modules. This document obsoletes RFC 8407; it also updates RFC 8126 by providing additional guidelines for writing the IANA considerations for RFCs that specify IANA-maintained YANG modules. Cisco Systems Cisco Systems Huawei Technologies SoftBank Juniper Networks This document defines a YANG data model for Segment Routing (SR) Policy that can be used for configuring, instantiating, and managing SR policies. The model is generic and applies equally to the MPLS and SRv6 instantiations of SR policies.

Full Tree of BGP SR Policy YANG Module