| Internet-Draft | YANG Model for BGP SR Policy | November 2026 |
| Lin & Gong | Expires 6 May 2027 | [Page] |
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.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 6 May 2027.¶
Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
Segment Routing (SR) [RFC8402] allows a headend node to steer a packet flow along a specific path. An SR Policy [RFC9256] 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.¶
[RFC9830] 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 [RFC9012] 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. [RFC9830] also updates the Color Extended Community of [RFC9012] to support additional steering modes. Additional Segment sub-TLVs for segment types other than the SR-MPLS label [RFC8660] and SRv6 SID [RFC8986] types are defined in [RFC9831].¶
The BGP YANG model [I-D.ietf-idr-bgp-model] defines a vendor-neutral YANG [RFC7950] model for BGP [RFC4271] 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 [I-D.ietf-idr-bgp-model]).¶
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 [RFC4760]. 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 [I-D.ietf-spring-sr-policy-yang], which, per Section 8 of [RFC9830], reports the SR Policies provisioned via the BGP SR Policy SAFI along with their operational states.¶
The following terms are used in this document:¶
SR Policy: An ordered list of segments (instructions) that define a source-routed policy [RFC9256].¶
Candidate Path (CP): A single path associated with an SR Policy, comprising one or more segment lists [RFC9256].¶
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 [RFC9256].¶
BSID: Binding SID, a segment identifier associated with an SR Policy [RFC9256].¶
AFI/SAFI: Address Family Identifier / Subsequent Address Family Identifier [RFC4760].¶
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 used in this document follow the notation defined in [RFC8340].¶
This document defines one YANG module: "ietf-bgp-sr-policy".¶
The "ietf-bgp-sr-policy" YANG module extends the BGP YANG model [I-D.ietf-idr-bgp-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) [RFC9830].¶
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 [RFC9830]).¶
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.¶
The full tree of the "ietf-bgp-sr-policy" YANG module is provided in Appendix A. The following subsections list the subtree structures.¶
The overall tree structure of the "ietf-bgp-sr-policy" YANG module is shown in Figure 1.¶
The "ietf-bgp-sr-policy" YANG module augments the BGP YANG module "ietf-bgp" [I-D.ietf-idr-bgp-model] 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.¶
module: ietf-bgp-sr-policy
augment /rt:routing/rt:control-plane-protocols
/rt:control-plane-protocol/bgp:bgp/bgp:global
/bgp:afi-safis/bgp:afi-safi:
+--rw sr-policy
+--rw prefix-limit
| ...
+--rw propagate-to-ebgp? boolean
+--rw ignore-unsupported-subtlvs? boolean
augment /rt:routing/rt:control-plane-protocols
/rt:control-plane-protocol/bgp:bgp/bgp:rib/bgp:afi-safis
/bgp:afi-safi:
+--ro sr-policy
+--ro loc-rib
| ...
+--ro neighbors
...
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.¶
The SR Policy configuration structure is shown in Figure 2.¶
module: ietf-bgp-sr-policy
augment /rt:routing/rt:control-plane-protocols
/rt:control-plane-protocol/bgp:bgp/bgp:global
/bgp:afi-safis/bgp:afi-safi:
+--rw sr-policy
+--rw prefix-limit
| +--rw max-prefixes? uint32
| +--rw warning-threshold-pct? rt-types:percentage
| +--rw teardown? boolean
| +--rw idle-time? union
| +--ro prefix-limit-exceeded? boolean
+--rw propagate-to-ebgp? boolean
+--rw ignore-unsupported-subtlvs? boolean
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 [I-D.ietf-idr-bgp-model], 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 [RFC9830]). 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 [RFC9830]). 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'.¶
The SR Policy RIB structure is shown in Figure 3.¶
augment /rt:routing/rt:control-plane-protocols
/rt:control-plane-protocol/bgp:bgp/bgp:global
/bgp:afi-safis/bgp:afi-safi:
+--rw sr-policy
+--rw prefix-limit
| +--rw max-prefixes? uint32
| +--rw warning-threshold-pct? rt-types:percentage
| +--rw teardown? boolean
| +--rw idle-time? union
| +--ro prefix-limit-exceeded? boolean
+--rw propagate-to-ebgp? boolean
+--rw ignore-unsupported-subtlvs? boolean
augment /rt:routing/rt:control-plane-protocols
/rt:control-plane-protocol/bgp:bgp/bgp:rib/bgp:afi-safis
/bgp:afi-safi:
+--ro sr-policy
+--ro loc-rib
| +--ro routes
| +--ro route* [distinguisher color endpoint]
| +--ro distinguisher uint32
| +--ro color uint32
| +--ro endpoint inet:ip-address
| +--ro active? boolean
| +--ro last-modified? yang:timeticks
| +--ro eligible-route? boolean
| +--ro ineligible-reason? identityref
| +--ro attr-index? leafref
| +--ro community-index? leafref
| +--ro ext-community-index? leafref
| +--ro large-community-index? leafref
| +--ro reject-reason? union
| +--ro candidate-path
| ...
+--ro neighbors
+--ro neighbor* [neighbor-address]
+--ro neighbor-address inet:ip-address
+--ro adj-rib-in-pre
| +--ro routes
| +--ro route*
| [distinguisher color endpoint path-id]
| ...
+--ro adj-rib-in-post
| +--ro routes
| +--ro route*
| [distinguisher color endpoint path-id]
| ...
+--ro adj-rib-out-pre
| +--ro routes
| +--ro route*
| [distinguisher color endpoint path-id]
| ...
+--ro adj-rib-out-post
+--ro routes
+--ro route*
[distinguisher color endpoint path-id]
...
The 'loc-rib' contains the set of SR Policy candidate paths selected by the BGP best-path selection algorithm (Section 9.1 of [RFC4271]) and eligible to be passed to the SRPM. The route entry is keyed by the <Distinguisher, Color, Endpoint> tuple of the SR Policy NLRI [RFC9830], which uniquely identifies an SR Policy candidate path; the NLRI fields have fixed positions and lengths (Section 2.1 of [RFC9830]), so the tuple uniquely identifies the route across implementations. The 'active' leaf indicates whether the candidate path is usable (Section 4.2.2 of [RFC9830]) and has been passed to the SRPM for candidate path selection as described in Section 2.9 of [RFC9256].¶
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 Figure 4.¶
module: ietf-bgp-sr-policy
augment /rt:routing/rt:control-plane-protocols
/rt:control-plane-protocol/bgp:bgp/bgp:rib/bgp:afi-safis
/bgp:afi-safi:
+--ro sr-policy
+--ro neighbors
+--ro neighbor* [neighbor-address]
...
+--ro adj-rib-in-pre
| +--ro routes
| +--ro route*
| [distinguisher color endpoint path-id]
| +--ro distinguisher uint32
| +--ro color uint32
| +--ro endpoint inet:ip-address
| +--ro path-id uint32
| +--ro attr-index? leafref
| +--ro community-index? leafref
| +--ro ext-community-index? leafref
| +--ro large-community-index? leafref
| +--ro last-modified? yang:timeticks
| +--ro eligible-route? boolean
| +--ro ineligible-reason? identityref
| +--ro unknown-attributes
| | +--ro unknown-attribute* [attr-type]
| | +--ro optional? boolean
| | +--ro transitive? boolean
| | +--ro partial? boolean
| | +--ro extended? boolean
| | +--ro attr-type uint8
| | +--ro attr-len? uint16
| | +--ro attr-value? binary
| +--ro reject-reason? union
| +--ro candidate-path
| ...
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') [I-D.ietf-idr-bgp-model], 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 [RFC9830]).¶
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 [RFC9830], 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 Figure 5.¶
+--ro candidate-path
+--ro preference? uint32
+--ro priority? uint8
+--ro policy-name? string
+--ro candidate-path-name? string
+--ro enlp? sr-policy-enlp
+--ro binding-sid
| +--ro specified-bsid-only? boolean
| +--ro drop-upon-invalid? boolean
| +--ro (bsid)?
| +--:(none)
| | +--ro none? empty
| +--:(mpls) {sr-mpls}?
| | +--ro mpls-label? uint32
| +--:(srv6) {srv6}?
| +--ro srv6-sid? inet:ipv6-address
+--ro srv6-binding-sids {srv6}?
| +--ro srv6-binding-sid* [sid]
| +--ro sid inet:ipv6-address
| +--ro specified-bsid-only? boolean
| +--ro drop-upon-invalid? boolean
| +--ro endpoint-behavior? uint16
| +--ro locator-block-length? uint8
| +--ro locator-node-length? uint8
| +--ro function-length? uint8
| +--ro argument-length? uint8
+--ro segment-lists
+--ro segment-list* [index]
+--ro index uint32
+--ro weight
| +--ro value? uint32
+--ro segments
+--ro segment* [index]
+--ro index uint32
+--ro sid-verification? boolean
+--ro (segment-type)?
+--:(type-a) {sr-mpls}?
| +--ro mpls-label? uint32
| +--ro traffic-class? uint8
| +--ro ttl? uint8
+--:(type-b) {srv6}?
+--ro srv6-sid? inet:ipv6-address
+--ro endpoint-behavior? uint16
+--ro locator-block-length? uint8
+--ro locator-node-length? uint8
+--ro function-length? uint8
+--ro argument-length? uint8
All the sub-TLVs of the SR Policy tunnel type are optional (Section 2.4 of [RFC9830]); 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 [RFC9830]. The 'binding-sid' container models the Binding SID sub-TLV (Section 2.4.2 of [RFC9830]), 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 [RFC9830]), 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 [RFC9830]. The 'segment-lists' container models the Segment List sub-TLVs (Section 2.4.4 of [RFC9830]): 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 [RFC8660]) and Type B (SRv6 SID [RFC8986]) sub-TLVs are modeled; the additional segment types specified in [RFC9831] are left to future revisions of this document. The 'enlp' leaf models the Explicit NULL Label Policy sub-TLV (Section 2.4.5 of [RFC9830]); 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 [I-D.ietf-spring-sr-policy-yang] and are outside the scope of this document.¶
This YANG module has normative references to [RFC7950], [RFC8349], [RFC9911], [RFC9830], [I-D.ietf-idr-bgp-model], and [I-D.ietf-netmod-yang-semver] (the 'ysv:version' extension used to tag the module revision with a semantic version).¶
Note that the "RFC XXXX" in this YANG module must be replaced by the publication RFC number of [I-D.ietf-idr-bgp-model], "RFC YYYY" must be replaced by the RFC number assigned to this document, and "RFC ZZZZ" must be replaced by the publication RFC number of [I-D.ietf-netmod-yang-semver]. This note is to be removed after the publication of those documents.¶
<CODE BEGINS> file "ietf-bgp-sr-policy@2026-11-02.yang"
module ietf-bgp-sr-policy {
yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-bgp-sr-policy";
prefix bsp;
/*
* Import and Include
*/
import ietf-routing {
prefix rt;
reference
"RFC 8349: A YANG Data Model for Routing Management
(NMDA Version)";
}
import ietf-inet-types {
prefix inet;
reference
"RFC 9911: Common YANG Data Types";
}
import ietf-yang-semver {
prefix ysv;
reference
"RFC ZZZZ: YANG Semantic Versioning";
}
import ietf-bgp {
prefix bgp;
reference
"RFC XXXX: YANG Model for Border Gateway Protocol (BGP-4)";
}
import iana-bgp-afi-safi-types {
prefix bast;
reference
"RFC XXXX: YANG Model for Border Gateway Protocol (BGP-4)";
}
organization
"IETF Inter-Domain Routing (IDR) Working Group";
contact
"WG Web: <https://datatracker.ietf.org/wg/idr/>
WG List: IDR <mailto:idr@ietf.org>
Author: Changwang Lin
<mailto:linchangwang.04414@h3c.com>";
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
<Distinguisher, Color, Endpoint>.";
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 <Distinguisher, Color, Endpoint> 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;
}
}
}
}
}
}
<CODE ENDS>¶
This section is modeled after the template described in Section 3.7.1 of [RFC9907].¶
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) [RFC6241] and RESTCONF [RFC8040]. These YANG-based management protocols (1) have to use a secure transport layer (e.g., Secure Shell (SSH) [RFC4252], TLS [RFC9846]) and (2) have to use mutual authentication.¶
The Network Configuration Access Control Model (NACM) [RFC8341] 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:¶
bsp:sr-policy/bsp:prefix-limit bsp:sr-policy/bsp:propagate-to-ebgp bsp:sr-policy/bsp:ignore-unsupported-subtlvs¶
Setting 'propagate-to-ebgp' to 'true' allows SR Policy advertisements to propagate to EBGP neighbors; the security considerations of Section 7 of [RFC9830] 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 [RFC9830]. The following subtrees and data nodes have particular sensitivities/vulnerabilities:¶
/rt:routing/rt:control-plane-protocols/rt:control-plane-protocol/ bgp:bgp/bgp:rib/bgp:afi-safis/bgp:afi-safi/bsp:sr-policy/ bsp:loc-rib /rt:routing/rt:control-plane-protocols/rt:control-plane-protocol/ bgp:bgp/bgp:rib/bgp:afi-safis/bgp:afi-safi/bsp:sr-policy/ bsp:neighbors¶
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 [RFC9830], [RFC9256], and [RFC8402] apply to any deployment that uses the data model defined in this document.¶
IANA is requested to register the following URI in the "ns" registry within the "IETF XML Registry" group ([RFC3688]):¶
URI: urn:ietf:params:xml:ns:yang:ietf-bgp-sr-policy Registrant Contact: The IESG. XML: N/A; the requested URI is an XML namespace¶
IANA is requested to register the following YANG module in the "YANG Module Names" registry ([RFC6020]) within the "YANG Parameters" registry group.¶
Name: ietf-bgp-sr-policy Maintained by IANA? N Namespace: urn:ietf:params:xml:ns:yang:ietf-bgp-sr-policy Prefix: bsp Reference: RFC YYYY¶
augment /rt:routing/rt:control-plane-protocols
/rt:control-plane-protocol/bgp:bgp/bgp:global
/bgp:afi-safis/bgp:afi-safi:
+--rw sr-policy
+--rw prefix-limit
| +--rw max-prefixes? uint32
| +--rw warning-threshold-pct? rt-types:percentage
| +--rw teardown? boolean
| +--rw idle-time? union
| +--ro prefix-limit-exceeded? boolean
+--rw propagate-to-ebgp? boolean
+--rw ignore-unsupported-subtlvs? boolean
augment /rt:routing/rt:control-plane-protocols
/rt:control-plane-protocol/bgp:bgp/bgp:rib/bgp:afi-safis
/bgp:afi-safi:
+--ro sr-policy
+--ro loc-rib
| +--ro routes
| +--ro route* [distinguisher color endpoint]
| +--ro distinguisher uint32
| +--ro color uint32
| +--ro endpoint inet:ip-address
| +--ro active? boolean
| +--ro last-modified? yang:timeticks
| +--ro eligible-route? boolean
| +--ro ineligible-reason? identityref
| +--ro attr-index? leafref
| +--ro community-index? leafref
| +--ro ext-community-index? leafref
| +--ro large-community-index? leafref
| +--ro reject-reason? union
| +--ro candidate-path
| ...
+--ro neighbors
+--ro neighbor* [neighbor-address]
+--ro neighbor-address inet:ip-address
+--ro adj-rib-in-pre
| +--ro routes
| +--ro route*
| [distinguisher color endpoint path-id]
| ...
+--ro adj-rib-in-post
| +--ro routes
| +--ro route*
| [distinguisher color endpoint path-id]
| ...
+--ro adj-rib-out-pre
| +--ro routes
| +--ro route*
| [distinguisher color endpoint path-id]
| ...
+--ro adj-rib-out-post
+--ro routes
+--ro route*
[distinguisher color endpoint path-id]
...¶