]> Cisco Systems, Inc.

India aramahen@cisco.com

Cisco Systems, Inc.

thanmano@cisco.com

Routing Inter-Domain Routing BGP-LS Segment Routing SR Policy YANG This document defines a YANG data model for the operational state of Segment Routing (SR) Policy candidate paths that are advertised using BGP - Link State (BGP-LS). The model augments the read-only BGP-LS Link-State Database with the SR Policy Candidate Path Network Layer Reachability Information (NLRI) and the associated BGP-LS Attribute TLVs specified in RFC 9857. About This Document The latest revision of this draft can be found at . Status information for this document may be found at . Discussion of this document takes place on the Inter-Domain Routing Working Group mailing list (), which is archived at . Subscribe at . Source for this draft and an issue tracker can be found at .

Introduction specifies a mechanism by which Link-State (LS) and Traffic Engineering (TE) information is collected and distributed using the Border Gateway Protocol (BGP). extends that mechanism with the SR Policy Candidate Path NLRI (NLRI Type 5), the Segment Routing Protocol-ID (9), and a set of BGP-LS Attribute TLVs that report the operational state of an SR Policy at candidate-path granularity. The reported information includes the Binding Segment Identifier (BSID), the candidate-path state and names, path constraints, and the segment lists associated with the candidate path. defines a YANG 1.1 data model for BGP-LS, BGP-LS-VPN, and BGP-LS-SPF as an extension of the BGP YANG data model , which is itself instantiated under the routing management model . That model includes a read-only Link-State Database (LSDB) for the Node, Link, Prefix, and SRv6 SID NLRIs received using BGP-LS, but it does not represent the SR Policy Candidate Path NLRI. This document defines the ietf-bgp-ls-sr-policy YANG module, which augments that LSDB with a read-only representation of the SR Policy Candidate Path NLRI and its associated BGP-LS Attribute TLVs. The module does not configure SR Policies and does not alter BGP-LS protocol procedures. The module conforms to the Network Management Datastore Architecture (NMDA) ; all data nodes defined by this document are reported in the operational state datastore.

Conventions and Definitions

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.

Terminology This document uses the terminology defined in , , and . In addition, the following terms are used:

Candidate path:

A path associated with an SR Policy, as defined in Section 2.2 of . An SR Policy can have multiple candidate paths, of which at most one is active at any given time.

Headend:

The node at which an SR Policy is instantiated and at which traffic is steered onto the SR Policy, as defined in .

Segment list:

An ordered list of segments that describes a path through the SR domain, as defined in . The term "SID list" is used interchangeably.

Server:

The entity that implements the module defined in this document and exposes the BGP-LS LSDB through a network management protocol.

Acronyms This document uses the following acronyms: Acronyms

Acronym	Definition
BGP	Border Gateway Protocol
BGP-LS	BGP - Link State
BSID	Binding Segment Identifier
CP	Candidate Path
LS	Link-State
LSDB	Link-State Database
NLRI	Network Layer Reachability Information
NMDA	Network Management Datastore Architecture
PCE	Path Computation Element
PCEP	Path Computation Element Communication Protocol
SID	Segment Identifier
SR	Segment Routing
SR-MPLS	Segment Routing over MPLS
SRLG	Shared Risk Link Group
SRv6	Segment Routing over IPv6
TE	Traffic Engineering
TLV	Type-Length-Value

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

Prefixes in Data Node Names In this document, names of data nodes and other data model objects are prefixed using the standard prefix associated with the corresponding YANG imported modules, as shown in the following table. Prefixes and Corresponding YANG Modules

Prefix	YANG Module	Reference
inet	ietf-inet-types
yang	ietf-yang-types
rt	ietf-routing
ietf-rt-t	ietf-routing-types
bgp	ietf-bgp
bgp-ls	ietf-bgp-ls
bgp-lsdb	ietf-bgp-lsdb
iana-bgp-ls-srp-t	iana-bgp-ls-sr-policy-types	RFC XXXX

Overview of the Data Model The tree diagram below shows an abridged view of the ietf-bgp-ls-sr-policy module. The sr-policy-candidate-paths container is augmented into each BGP-LS LSDB instance whose Protocol-ID is Segment Routing. Each candidate path is identified by the Local Node Descriptors and the SR Policy Candidate Path Descriptor carried in the NLRI. The attributes container holds the state TLVs carried in the associated BGP-LS Attribute. The complete tree diagram is provided in .

Abridged Tree Diagram of ietf-bgp-ls-sr-policy

Design of the Data Model

Scope and Augmentation The ietf-bgp-ls-sr-policy module augments the operational BGP-LS LSDB defined by . The module augments only the link-state database. The separate link-state-spf database is not augmented because does not define the SR Policy Candidate Path NLRI for BGP-LS-SPF. The sr-policy-candidate-paths container is a sibling of the nodes, links, prefixes, srv6-sids, and unknowns containers in an LSDB instance. A when statement restricts the container to LSDB instances whose protocol leaf is sr, which corresponds to the Segment Routing Protocol-ID (9) assigned by . The NLRI Identifier field is represented by the identifier key of the enclosing LSDB instance.

Candidate Path Identification Each entry in the candidate-path list represents one SR Policy Candidate Path NLRI. The list key consists of the decoded fields of the Local Node Descriptors TLV followed by the fields of the mandatory SR Policy Candidate Path Descriptor TLV (TLV 554). shows the correspondence between the NLRI fields and the YANG data nodes.

Mapping of NLRI Fields to List Keys bgp-ls:instance/protocol +-------------------------------+ | Identifier (64 bits) |-> bgp-ls:instance/identifier +-------------------------------+ | Local Node Descriptors (256) | | Autonomous System (512) |-> candidate-path/as | BGP Router-ID (516) |-> candidate-path/bgp-router-id | Confed. Member (517) |-> candidate-path/member-as | IPv4 Router-ID (1028) |-> candidate-path/ipv4-router-id | IPv6 Router-ID (1029) |-> candidate-path/ipv6-router-id +-------------------------------+ | SR Policy CP Descriptor (554) | | Protocol-Origin |-> candidate-path/protocol-origin | Flags (E, O) |-> candidate-path/descriptor-flags | Endpoint |-> candidate-path/endpoint | Policy Color |-> candidate-path/color | Originator ASN |-> candidate-path/originator-as | Originator Address |-> candidate-path/originator-address | Discriminator |-> candidate-path/discriminator +-------------------------------+ ]]>

YANG requires every key leaf to have a value. requires the Autonomous System (TLV 512) and BGP Router-ID (TLV 516) Node Descriptors when the headend is the BGP-LS Producer, but makes them optional when a PCE is the BGP-LS Producer. The BGP Confederation Member (TLV 517) Node Descriptor is always optional, and at least one of the IPv4 Router-ID (TLV 1028) and IPv6 Router-ID (TLV 1029) Node Descriptors is required. A server therefore MUST populate the key leaves as follows when the corresponding Node Descriptor TLV is absent from the NLRI:

• as and member-as: the value 0.
• bgp-router-id: the value 0.0.0.0. This leaf uses the dotted-quad type because the BGP Identifier is a 4-octet value that is not necessarily an IPv4 address.
• ipv4-router-id: the IPv4 unspecified address (0.0.0.0).
• ipv6-router-id: the IPv6 unspecified address (::).

A must statement enforces that at least one of ipv4-router-id and ipv6-router-id contains a specified address. also permits other Node Descriptor TLVs defined in , such as the IGP Router-ID (TLV 515), to be included in the Local Node Descriptors TLV. Such descriptors are not represented in the list key by this version of the module.

Candidate Path Attributes The attributes container represents the BGP-LS Attribute associated with the NLRI. shows the correspondence between the BGP-LS Attribute TLVs and sub-TLVs defined in and and the YANG data nodes defined under the attributes container. Indentation of the TLV code point indicates a sub-TLV of the preceding TLV.

Mapping of BGP-LS Attribute TLVs to Data Nodes

The SRv6 Endpoint Behavior (TLV 1250) and SRv6 SID Structure (TLV 1252) sub-TLVs apply to the srv6-binding-sid list entries and to the segment list entries. These are represented by the SRv6 SID attribute grouping reused from . The following rules apply to the representation of the BGP-LS Attribute:

• specifies that only the first valid instance of certain TLVs and sub-TLVs is used when multiple instances are received. For such TLVs and sub-TLVs, the server MUST represent only the instance that is used according to .
• The SR Binding SID TLV (TLV 1201) is represented by the sr-binding-sid container. The D-flag is represented by the srv6-dataplane bit of the flags leaf. When the D-flag is clear, the server MUST report the Binding SID and Specified Binding SID fields in the binding-sid and specified-binding-sid leaves. When the D-flag is set, the TLV uses the SRv6 encoding that is deprecated by Section 5.1 of , and the server MUST report these fields in the srv6-binding-sid and srv6-specified-binding-sid leaves. In both cases, when either field is set to 0 (e.g., because no Binding SID has been specified), the server MUST NOT report the corresponding leaf.
• Each SRv6 Binding SID TLV (TLV 1212) is represented by one entry of the srv6-binding-sid list. permits multiple instances of this TLV for a candidate path. The server MUST assign the index key according to the order in which the TLVs appear in the BGP-LS Attribute, starting at 0. When the Binding SID or Specified Binding SID field is set to 0, the server MUST NOT report the corresponding leaf.
• The Protocol-Origin, Metric Type, and Segment Type fields carry code points from IANA registries. These are represented by union types whose first member is an enumeration defined in the IANA-maintained iana-bgp-ls-sr-policy-types module () and whose second member is uint8. When a code point is defined in the revision of the IANA-maintained module implemented by the server, the server MUST report the enumeration name. Otherwise, including for User Defined metric types, the server MUST report the numeric value.
• When the Disjoint Group Identifier or Bidirectional Group Identifier field carries a 4-octet value, the server MUST report it in the group-id leaf. When the field carries a PCEP ASSOCIATION Object , the server MUST report the object, as received, in the pcep-association-object leaf.
• Bandwidth values are encoded by in bytes per second as IEEE 754 single-precision floating-point numbers . The module represents bandwidth using the bandwidth-ieee-float32 type defined in , in bytes per second. The server MUST report the received value without conversion or rounding.
• Each flag defined by is represented by a bit of the same name in a YANG bits type. The YANG bit positions match the bit numbering used in . Bits that are undefined in are ignored by a receiver and are not represented.
• A TLV or sub-TLV that is not recognized by the server SHOULD be reported in the unknown list of the enclosing level, using the unknown attribute grouping reused from .

Segment Lists and Segments Segment lists and segments are represented by lists that are ordered-by user so that the received order is preserved. The server MUST assign the index key of a segment list according to the order in which the corresponding SR Segment List TLV appears in the BGP-LS Attribute, starting at 0. The server MUST assign the index key of a segment according to the order in which the corresponding SR Segment sub-TLV appears in the SR Segment List TLV, starting at 0. The optional Segment List Identifier defined in Section 5.7.4 of is represented by the identifier leaf and is not used as the list key, because it is optional and is not required to be present for every segment list. A segment list without any SR Segment sub-TLVs (e.g., a dynamic path that has not yet been computed) is represented by a segment-list entry without segment entries. Segment Descriptor Types A through K defined in Section 5.7.1.1 of are represented by separate cases of the descriptor choice. The type leaf of a segment contains the Segment Type, and each case is constrained by a when statement to the corresponding enumeration name. The SID value is present only when the S-flag (sid-present) of the segment is set. The Algorithm field of a Type A or Type B descriptor is meaningful only when the A-flag (algorithm-valid) of the segment is set.

YANG Modules

BGP-LS SR Policy Module The ietf-bgp-ls-sr-policy module imports typedefs from , , and the iana-bgp-ls-sr-policy-types module defined in , the routing management module defined in , the BGP module defined in , and the BGP-LS and LSDB modules defined in . The module also references and . file "ietf-bgp-ls-sr-policy@2026-10-28.yang" module ietf-bgp-ls-sr-policy { yang-version 1.1; namespace "urn:ietf:params:xml:ns:yang:ietf-bgp-ls-sr-policy"; prefix bgp-ls-sr-policy; import ietf-inet-types { prefix inet; reference "RFC 9911: Common YANG Data Types."; } import ietf-yang-types { prefix yang; reference "RFC 9911: Common YANG Data Types."; } import ietf-routing-types { prefix ietf-rt-t; reference "RFC 8294: Common YANG Data Types for the Routing Area."; } import ietf-routing { prefix rt; reference "RFC 8349: A YANG Data Model for Routing Management (NMDA Version)."; } import ietf-bgp { prefix bgp; reference "I-D.ietf-idr-bgp-model: BGP YANG Model for Service Provider Networks."; } import ietf-bgp-ls { prefix bgp-ls; reference "I-D.ietf-lsvr-bgp-ls-yang: A YANG Model for BGP-LS, BGP-LS-VPN, and BGP-LS-SPF."; } import ietf-bgp-lsdb { prefix bgp-lsdb; reference "I-D.ietf-lsvr-bgp-ls-yang: A YANG Model for BGP-LS, BGP-LS-VPN, and BGP-LS-SPF."; } import iana-bgp-ls-sr-policy-types { prefix iana-bgp-ls-srp-t; reference "RFC XXXX: A YANG Data Model for BGP-LS Segment Routing Policy."; } organization "IETF IDR Working Group"; contact "WG Web: WG List: Authors: Aravind Babu MahendraBabu Thanigaivel Manoharan "; description "This module augments the operational Link-State Database in the BGP-LS YANG data model with a representation of the Segment Routing (SR) Policy Candidate Path NLRI and its associated BGP-LS attributes, as defined in RFC 9857. 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 XXXX; see the RFC itself for full legal notices."; revision 2026-10-28 { description "Initial revision."; reference "RFC 9857: Advertisement of Segment Routing Policies Using BGP - Link State. I-D.aravind-idr-bgp-ls-sr-policy-yang: A YANG Data Model for BGP-LS Segment Routing Policy."; } typedef protocol-origin { type union { type iana-bgp-ls-srp-t:protocol-origin; type uint8 { range "1..255"; } } description "The component responsible for instantiating an SR Policy candidate path, from the IANA 'SR Policy Protocol-Origin' registry. A code point that is not defined in the implemented revision of the IANA-maintained module is reported as a numeric value."; reference "RFC 9857, Sections 4 and 8.4."; } typedef metric-type { type union { type iana-bgp-ls-srp-t:metric-type; type uint8; } description "An SR Policy metric type from the IANA 'BGP-LS SR Policy Metric Types' registry. A code point that is not defined in the implemented revision of the IANA-maintained module, including a User Defined code point, is reported as a numeric value."; reference "RFC 9857, Sections 5.6.6, 5.7.2, and 8.6."; } typedef segment-type { type union { type iana-bgp-ls-srp-t:segment-type; type uint8 { range "1..255"; } } description "A Segment Type from the IANA 'BGP-LS SR Segment Descriptor Types' registry. A code point that is not defined in the implemented revision of the IANA-maintained module is reported as a numeric value."; reference "RFC 9857, Sections 5.7.1 and 8.5."; } typedef descriptor-flags { type bits { bit endpoint-ipv6 { position 0; description "The endpoint is encoded as an IPv6 address."; } bit originator-ipv6 { position 1; description "The originator is encoded as an IPv6 address."; } } description "Flags in the SR Policy Candidate Path Descriptor TLV."; reference "RFC 9857, Section 4."; } typedef binding-sid-flags { type bits { bit srv6-dataplane { position 0; description "The Binding SID values are SRv6 SIDs instead of SR-MPLS labels. This encoding is deprecated by RFC 9857."; } bit allocated { position 1; description "The Binding SID value is allocated."; } bit specified-unavailable { position 2; description "The specified Binding SID is unavailable."; } bit srlb { position 3; description "The Binding SID is from the headend SRLB."; } bit fallback { position 4; description "The value was dynamically allocated due to fallback."; } } description "Flags in the SR Binding SID TLV. The SRLB flag applies only to an SR-MPLS Binding SID."; reference "RFC 9857, Section 5.1."; } typedef srv6-binding-sid-flags { type bits { bit allocated { position 0; description "The SRv6 Binding SID value is allocated."; } bit specified-unavailable { position 1; description "The specified SRv6 Binding SID is unavailable."; } bit fallback { position 2; description "The value was dynamically allocated due to fallback."; } } description "Flags in the SRv6 Binding SID TLV."; reference "RFC 9857, Section 5.2."; } typedef candidate-path-state-flags { type bits { bit administrative-shutdown { position 0; description "The candidate path is administratively shut down."; } bit active { position 1; description "The candidate path is active in the forwarding plane."; } bit backup { position 2; description "The candidate path is a backup path."; } bit evaluated { position 3; description "The candidate path has been evaluated for validity."; } bit valid { position 4; description "The candidate path has at least one valid SID list."; } bit on-demand-nexthop { position 5; description "The path was instantiated by an on-demand nexthop trigger."; } bit delegated { position 6; description "The path was delegated to a PCE or controller."; } bit provisioned { position 7; description "The path was provisioned by a PCE or controller."; } bit drop-upon-invalid { position 8; description "Drop-upon-invalid behavior is requested."; } bit transit-eligible { position 9; description "The path is eligible for use as a transit policy."; } bit dropping { position 10; description "The active path is dropping traffic due to drop-upon-invalid behavior."; } } description "Operational state flags for an SR Policy candidate path."; reference "RFC 9857, Section 5.3."; } typedef candidate-path-constraint-flags { type bits { bit srv6-dataplane { position 0; description "Use the SRv6 dataplane instead of SR-MPLS."; } bit protected { position 1; description "Prefer protected SIDs."; } bit unprotected { position 2; description "Prefer unprotected SIDs."; } bit specified-algorithm { position 3; description "Use SIDs belonging to the specified SR Algorithm."; } bit specified-topology { position 4; description "Use SIDs belonging to the specified topology."; } bit strict { position 5; description "Treat the protection preference as a strict constraint."; } bit fixed { position 6; description "The path is fixed after computation."; } bit hop-by-hop { position 7; description "Use only adjacency SIDs in hop-by-hop fashion."; } } description "Flags in the SR Candidate Path Constraints TLV."; reference "RFC 9857, Section 5.6."; } typedef disjoint-request-flags { type bits { bit srlg { position 0; description "SRLG disjointness is requested."; } bit node { position 1; description "Node disjointness is requested."; } bit link { position 2; description "Link disjointness is requested."; } bit fallback { position 3; description "Fallback to lower disjointness is permitted."; } bit best-path-fallback { position 4; description "Fallback to the default best path is permitted."; } } description "Requested SR disjointness constraints."; reference "RFC 9857, Section 5.6.4."; } typedef disjoint-status-flags { type bits { bit srlg { position 0; description "SRLG disjointness was achieved."; } bit node { position 1; description "Node disjointness was achieved."; } bit link { position 2; description "Link disjointness was achieved."; } bit fallback { position 3; description "Computation fell back to lower disjointness."; } bit best-path-fallback { position 4; description "Computation fell back to the default best path."; } bit invalid { position 5; description "The constraint could not be met and the path is invalid."; } } description "Achieved SR disjointness status."; reference "RFC 9857, Section 5.6.4."; } typedef bidirectional-flags { type bits { bit reverse { position 0; description "This candidate path is the reverse path."; } bit co-routed { position 1; description "The bidirectional path is co-routed."; } } description "Flags for an SR bidirectional group constraint."; reference "RFC 9857, Section 5.6.5."; } typedef metric-constraint-flags { type bits { bit optimization-metric { position 0; description "This is the optimization metric for the dynamic path."; } bit margin-present { position 1; description "A metric margin is present."; } bit absolute-margin { position 2; description "The margin is absolute rather than a percentage."; } bit bound-present { position 3; description "A metric bound is present."; } } description "Flags for an SR Metric Constraint sub-TLV."; reference "RFC 9857, Section 5.6.6."; } typedef segment-list-flags { type bits { bit srv6-dataplane { position 0; description "The SID list contains SRv6 SIDs."; } bit explicit { position 1; description "The SID list belongs to an explicit candidate path."; } bit computed { position 2; description "The SID list was computed."; } bit verified { position 3; description "The SID list passed verification or needed none."; } bit resolved { position 4; description "The first segment was resolved."; } bit computation-failed { position 5; description "Dynamic path computation failed."; } bit specified-algorithm { position 6; description "All SIDs belong to the specified algorithm."; } bit specified-topology { position 7; description "All SIDs belong to the specified topology."; } bit fault-monitor-removed { position 8; description "Fault monitoring removed the SID list from forwarding."; } } description "Flags in the SR Segment List TLV."; reference "RFC 9857, Section 5.7."; } typedef segment-flags { type bits { bit sid-present { position 0; description "The SID field is present."; } bit explicitly-provisioned { position 1; description "The SID was explicitly provisioned."; } bit verified { position 2; description "The SID passed verification or needed none."; } bit resolved { position 3; description "The SID was resolved or needed no resolution."; } bit algorithm-valid { position 4; description "The algorithm in the descriptor is valid."; } } description "Flags in an SR Segment sub-TLV."; reference "RFC 9857, Section 5.7.1."; } typedef segment-list-metric-flags { type bits { bit margin-present { position 0; description "A metric margin is present."; } bit absolute-margin { position 1; description "The margin is absolute rather than a percentage."; } bit bound-present { position 2; description "A metric bound is present."; } bit value-present { position 3; description "A computed metric value is present."; } } description "Flags in an SR Segment List Metric sub-TLV."; reference "RFC 9857, Section 5.7.2."; } grouping sr-policy-node-descriptors { description "Decoded fields of the Local Node Descriptors TLV identifying the SR Policy headend."; reference "RFC 9857, Section 3."; leaf as { type inet:as-number; description "Autonomous System Number in Node Descriptor TLV 512. A value of zero indicates that the descriptor was absent."; } leaf bgp-router-id { type yang:dotted-quad; description "BGP Identifier in Node Descriptor TLV 516. The value 0.0.0.0 indicates that the descriptor was absent."; } leaf member-as { type inet:as-number; description "BGP Confederation Member ASN in Node Descriptor TLV 517. A value of zero indicates that the descriptor was absent."; } leaf ipv4-router-id { type inet:ipv4-address; description "IPv4 Router-ID of the headend from TLV 1028. The unspecified address is used when only an IPv6 Router-ID is present."; } leaf ipv6-router-id { type inet:ipv6-address; description "IPv6 Router-ID of the headend from TLV 1029. The unspecified address is used when only an IPv4 Router-ID is present."; } } grouping sr-policy-candidate-path-descriptor { description "Decoded fields of the mandatory SR Policy Candidate Path Descriptor TLV."; reference "RFC 9857, Section 4."; leaf protocol-origin { type protocol-origin; mandatory true; description "Protocol or component that instantiated the path."; } leaf descriptor-flags { type descriptor-flags; mandatory true; description "Address-family flags from the descriptor TLV."; } leaf endpoint { type inet:ip-address; mandatory true; description "SR Policy endpoint."; } leaf color { type uint32; mandatory true; description "SR Policy color."; } leaf originator-as { type inet:as-number; mandatory true; description "ASN of the candidate-path originator."; } leaf originator-address { type inet:ip-address; mandatory true; description "Address of the candidate-path originator."; } leaf discriminator { type uint32; mandatory true; description "Candidate-path discriminator."; } } grouping group-identifier { description "Group identifier carried in the SR Disjoint Group and SR Bidirectional Group Constraint sub-TLVs."; reference "RFC 9857, Sections 5.6.4 and 5.6.5."; choice group-identifier { mandatory true; description "The identifier is encoded either as a 4-octet value or as an entire PCEP ASSOCIATION Object."; case group-id { leaf group-id { type uint32; description "4-octet group identifier."; } } case pcep-association-object { leaf pcep-association-object { type binary; description "Entire PCEP ASSOCIATION Object, including its optional TLVs, as received. The object is not parsed by BGP speakers."; reference "RFC 8697: Path Computation Element Communication Protocol (PCEP) Extensions for Establishing Relationships between Sets of Label Switched Paths (LSPs), Section 6.1."; } } } } grouping candidate-path-constraints { description "Constraints associated with an SR Policy candidate path."; container constraints { presence "An SR Candidate Path Constraints TLV was received."; description "Constraints and optimization objectives for the path."; reference "RFC 9857, Section 5.6."; leaf flags { type candidate-path-constraint-flags; description "Constraint flags."; } leaf multi-topology-id { type uint16 { range "0..4095"; } description "Preferred IGP multi-topology identifier."; } leaf algorithm { type uint8; description "Preferred SR Algorithm."; } container affinity { presence "An SR Affinity Constraint sub-TLV was received."; description "Extended Administrative Group affinity constraints. Each leaf-list entry represents one 32-bit word, in wire order."; reference "RFC 9857, Section 5.6.1."; leaf-list exclude-any { type uint32; ordered-by user; description "Affinity words for the exclude-any constraint."; } leaf-list include-any { type uint32; ordered-by user; description "Affinity words for the include-any constraint."; } leaf-list include-all { type uint32; ordered-by user; description "Affinity words for the include-all constraint."; } } leaf-list excluded-srlg { type uint32; ordered-by user; description "Shared Risk Link Group values excluded from the path."; reference "RFC 9857, Section 5.6.2."; } leaf bandwidth { type ietf-rt-t:bandwidth-ieee-float32; units "bytes per second"; description "Requested bandwidth. The protocol encodes this value as an IEEE 754 single-precision floating-point number."; reference "RFC 9857, Section 5.6.3."; } container disjoint-group { presence "An SR Disjoint Group Constraint sub-TLV was received."; description "Requested and achieved path disjointness."; reference "RFC 9857, Section 5.6.4."; leaf request-flags { type disjoint-request-flags; description "Requested disjointness properties."; } leaf status-flags { type disjoint-status-flags; description "Achieved disjointness properties."; } uses group-identifier; } container bidirectional-group { presence "An SR Bidirectional Group Constraint sub-TLV was received."; description "Bidirectional path association."; reference "RFC 9857, Section 5.6.5."; leaf flags { type bidirectional-flags; description "Bidirectional group flags."; } uses group-identifier; } list metric { key "type"; description "Metric constraints associated with the candidate path."; reference "RFC 9857, Section 5.6.6."; leaf type { type metric-type; description "Metric type code point."; } leaf flags { type metric-constraint-flags; description "Metric constraint flags."; } leaf margin { type uint32; description "Absolute or percentage metric margin."; } leaf bound { type uint32; description "Worst metric value allowed for a valid path."; } } } } grouping segment-descriptor { description "Descriptor for one of the segment types defined by RFC 9857."; choice descriptor { description "Descriptor fields selected according to the segment type."; case type-a { container type-a { when "../type = 'type-a'"; description "Type A: SR-MPLS label descriptor."; leaf algorithm { type uint8; mandatory true; description "IGP Algorithm used to select the SID."; } } } case type-b { container type-b { when "../type = 'type-b'"; description "Type B: SRv6 SID descriptor."; leaf algorithm { type uint8; mandatory true; description "IGP Algorithm used to select the SID."; } } } case type-c { container type-c { when "../type = 'type-c'"; description "Type C: IPv4 node address for an SR-MPLS Prefix SID."; leaf algorithm { type uint8; mandatory true; description "IGP Algorithm used to select the SID."; } leaf node-address { type inet:ipv4-address; mandatory true; description "IPv4 address associated with the node."; } } } case type-d { container type-d { when "../type = 'type-d'"; description "Type D: IPv6 node address for an SR-MPLS Prefix SID."; leaf algorithm { type uint8; mandatory true; description "IGP Algorithm used to select the SID."; } leaf node-address { type inet:ipv6-address; mandatory true; description "IPv6 global address associated with the node."; } } } case type-e { container type-e { when "../type = 'type-e'"; description "Type E: IPv4 node and local interface identifier."; leaf node-address { type inet:ipv4-address; mandatory true; description "IPv4 address associated with the node."; } leaf local-interface-id { type uint32; mandatory true; description "Local interface identifier."; } } } case type-f { container type-f { when "../type = 'type-f'"; description "Type F: IPv4 local and remote interface addresses."; leaf local-interface-address { type inet:ipv4-address; mandatory true; description "Local interface address."; } leaf remote-interface-address { type inet:ipv4-address; mandatory true; description "Remote interface address; zero may indicate that the value is unused."; } } } case type-g { container type-g { when "../type = 'type-g'"; description "Type G: IPv6 node addresses and interface identifiers for an SR-MPLS adjacency."; uses ipv6-node-and-interface-pair; } } case type-h { container type-h { when "../type = 'type-h'"; description "Type H: IPv6 local and remote interface addresses for an SR-MPLS adjacency."; uses ipv6-interface-address-pair; } } case type-i { container type-i { when "../type = 'type-i'"; description "Type I: IPv6 node address for an SRv6 End SID."; leaf algorithm { type uint8; mandatory true; description "IGP Algorithm used to select the SID."; } leaf node-address { type inet:ipv6-address; mandatory true; description "IPv6 global address associated with the node."; } } } case type-j { container type-j { when "../type = 'type-j'"; description "Type J: IPv6 node addresses and interface identifiers for an SRv6 End.X SID."; uses ipv6-node-and-interface-pair; } } case type-k { container type-k { when "../type = 'type-k'"; description "Type K: IPv6 local and remote interface addresses for an SRv6 End.X SID."; uses ipv6-interface-address-pair; } } } } grouping ipv6-node-and-interface-pair { description "IPv6 node addresses and interface identifiers for both ends of a link."; leaf local-node-address { type inet:ipv6-address; mandatory true; description "IPv6 global address of the local node."; } leaf local-interface-id { type uint32; mandatory true; description "Local node interface identifier."; } leaf remote-node-address { type inet:ipv6-address; mandatory true; description "IPv6 global address of the remote node; zero may indicate that the value is unused."; } leaf remote-interface-id { type uint32; mandatory true; description "Remote node interface identifier; zero may indicate that the value is unused."; } } grouping ipv6-interface-address-pair { description "IPv6 interface addresses for both ends of a link."; leaf local-interface-address { type inet:ipv6-address; mandatory true; description "IPv6 global address of the local interface."; } leaf remote-interface-address { type inet:ipv6-address; mandatory true; description "IPv6 global address of the remote interface."; } } grouping segment-lists { description "SID lists belonging to an SR Policy candidate path."; list segment-list { key "index"; ordered-by user; description "A SID list in the order received. The index is the zero-based position of the SID list within the candidate path."; reference "RFC 9857, Section 5.7."; leaf index { type uint32; description "Zero-based position of the SID list in the order received."; } leaf flags { type segment-list-flags; description "SID-list state and dataplane flags."; } leaf multi-topology-id { type uint16 { range "0..4095"; } description "Multi-topology identifier used by the SID list."; } leaf algorithm { type uint8; description "SR Algorithm used by the SID list."; } leaf weight { type uint32; description "Weight used for load balancing across SID lists."; } leaf identifier { type uint32; description "Candidate-path-scoped SID-list identifier. Zero means that no identifier is associated with the SID list."; reference "RFC 9857, Section 5.7.4."; } list segment { key "index"; ordered-by user; description "An ordered segment in the SID list."; reference "RFC 9857, Section 5.7.1."; leaf index { type uint32; description "Zero-based position of the segment in the SID list."; } leaf type { type segment-type; mandatory true; description "Segment Type of the segment."; } leaf flags { type segment-flags; description "Segment state flags."; } choice sid { description "Resolved or explicitly provisioned SID value. A SID value is present only when the 'sid-present' flag is set."; case mpls { leaf mpls-label { type ietf-rt-t:mpls-label-general-use; description "SR-MPLS label."; } } case srv6 { leaf srv6-sid { type inet:ipv6-address; description "SRv6 SID."; } } } uses segment-descriptor; uses bgp-lsdb:bgp-ls-topo-srv6-sid-attr; uses bgp-lsdb:bgp-ls-topo-unknown-attr; } list metric { key "type"; description "Computed metric values for this SID list."; reference "RFC 9857, Section 5.7.2."; leaf type { type metric-type; description "Metric type code point."; } leaf flags { type segment-list-metric-flags; description "Metric presence and interpretation flags."; } leaf margin { type uint32; description "Absolute or percentage metric margin."; } leaf bound { type uint32; description "Worst metric value allowed for a valid path."; } leaf value { type uint32; description "Computed metric value."; } } leaf bandwidth { type ietf-rt-t:bandwidth-ieee-float32; units "bytes per second"; description "Allocated bandwidth. The protocol encodes this value as an IEEE 754 single-precision floating-point number."; reference "RFC 9857, Section 5.7.3."; } uses bgp-lsdb:bgp-ls-topo-unknown-attr; } } grouping sr-policy-candidate-paths { description "Operational SR Policy candidate paths advertised in BGP-LS."; container sr-policy-candidate-paths { description "BGP-LS topology entries for SR Policy Candidate Path NLRIs."; list candidate-path { must "ipv4-router-id != '0.0.0.0' or " + "ipv6-router-id != '::'" { error-message "At least one headend IPv4 or IPv6 Router-ID must be " + "present."; description "RFC 9857 requires at least one auxiliary Router-ID for the SR Policy headend."; } key "as bgp-router-id member-as ipv4-router-id " + "ipv6-router-id protocol-origin descriptor-flags " + "endpoint color originator-as originator-address " + "discriminator"; description "An SR Policy candidate-path NLRI and its BGP-LS attributes. The list key is the decoded Local Node Descriptors TLV followed by the mandatory SR Policy Candidate Path Descriptor TLV."; reference "RFC 9857, Sections 3 through 5."; uses sr-policy-node-descriptors; uses sr-policy-candidate-path-descriptor; container attributes { description "Decoded BGP-LS Attribute TLVs associated with the SR Policy Candidate Path NLRI."; leaf policy-name { type string; description "Symbolic SR Policy name from TLV 1213. RFC 9857 recommends, but does not require, that the name be limited to 255 octets."; reference "RFC 9857, Section 5.4."; } leaf candidate-path-name { type string; description "Symbolic candidate-path name from TLV 1203. RFC 9857 recommends, but does not require, that the name be limited to 255 octets."; reference "RFC 9857, Section 5.5."; } container sr-binding-sid { presence "An SR Binding SID TLV was received."; description "Binding SID state reported in the SR Binding SID TLV (TLV 1201). The 'srv6-dataplane' flag (D-flag) selects between the SR-MPLS and SRv6 encodings. The SRv6 encoding of this TLV is deprecated by RFC 9857 and is represented only for backward compatibility; SRv6 Binding SIDs are otherwise represented by the srv6-binding-sid list (TLV 1212)."; reference "RFC 9857, Section 5.1."; leaf flags { type binding-sid-flags; description "Binding SID status flags."; } choice dataplane { description "Binding SID values according to the dataplane indicated by the 'srv6-dataplane' flag."; case mpls { leaf binding-sid { when "not(bit-is-set(../flags, 'srv6-dataplane'))"; type ietf-rt-t:mpls-label-general-use; description "Allocated or operational SR-MPLS Binding SID."; } leaf specified-binding-sid { when "not(bit-is-set(../flags, 'srv6-dataplane'))"; type ietf-rt-t:mpls-label-general-use; description "Explicitly specified SR-MPLS Binding SID."; } } case srv6 { leaf srv6-binding-sid { when "bit-is-set(../flags, 'srv6-dataplane')"; type inet:ipv6-address; description "Allocated or operational SRv6 Binding SID."; } leaf srv6-specified-binding-sid { when "bit-is-set(../flags, 'srv6-dataplane')"; type inet:ipv6-address; description "Explicitly specified SRv6 Binding SID."; } } } } list srv6-binding-sid { key "index"; ordered-by user; description "An SRv6 Binding SID associated with the candidate path, in the order in which the SRv6 Binding SID TLVs were received."; reference "RFC 9857, Section 5.2."; leaf index { type uint32; description "Zero-based position of the SRv6 Binding SID TLV in the order received."; } leaf binding-sid { type inet:ipv6-address; description "Allocated or operational SRv6 Binding SID."; } leaf flags { type srv6-binding-sid-flags; description "SRv6 Binding SID status flags."; } leaf specified-binding-sid { type inet:ipv6-address; description "Explicitly specified SRv6 Binding SID."; } uses bgp-lsdb:bgp-ls-topo-srv6-sid-attr; uses bgp-lsdb:bgp-ls-topo-unknown-attr; } container state { presence "An SR Candidate Path State TLV was received."; description "Operational status at candidate-path level."; reference "RFC 9857, Section 5.3."; leaf priority { type uint8; mandatory true; description "Candidate-path priority."; } leaf flags { type candidate-path-state-flags; description "Candidate-path operational state flags."; } leaf preference { type uint32; mandatory true; description "Candidate-path preference."; } } uses candidate-path-constraints; uses segment-lists; uses bgp-lsdb:bgp-ls-topo-unknown-attr; } } } } augment "/rt:routing/rt:control-plane-protocols/" + "rt:control-plane-protocol/bgp:bgp/bgp:global/" + "bgp:afi-safis/bgp:afi-safi/bgp-ls:link-state/" + "bgp-ls:bgp-ls-topology/bgp-ls:instances/" + "bgp-ls:instance" { when "bgp-ls:protocol = 'sr'" { description "SR Policy candidate-path NLRIs use the Segment Routing Protocol-ID (9)."; } description "Add SR Policy Candidate Path NLRI entries to the BGP-LS Link-State Database. This augmentation targets BGP-LS and not the separate BGP-LS-SPF Link-State Database instantiation."; uses sr-policy-candidate-paths; } } ]]>

IANA-Maintained Module This document defines the initial version of the iana-bgp-ls-sr-policy-types YANG module. The module defines enumerations for code points in the "SR Policy Protocol-Origin", "BGP-LS SR Segment Descriptor Types", and "BGP-LS SR Policy Metric Types" registries established by . The version below reflects those registries at the time of writing. This document requests IANA to publish and maintain the module as described in . A single module covers these three registries because they contain closely related, one-octet code points used by the same BGP-LS SR Policy data model and are expected to remain small. Enumerations are used instead of identities because the numeric value of each enumeration corresponds directly to the code point carried in the protocol encoding. The typedefs used by the BGP-LS SR Policy module combine each enumeration with uint8, allowing a server to report a code point that is not defined by the revision of the IANA-maintained module that it implements. file "iana-bgp-ls-sr-policy-types@2026-10-28.yang" module iana-bgp-ls-sr-policy-types { yang-version 1.1; namespace "urn:ietf:params:xml:ns:yang:iana-bgp-ls-sr-policy-types"; prefix iana-bgp-ls-srp-t; organization "Internet Assigned Numbers Authority (IANA)"; contact "Internet Assigned Numbers Authority ICANN 12025 Waterfront Drive, Suite 300 Los Angeles, CA 90094-2536 United States of America Tel: +1 310 301 5800 "; description "This module contains type definitions for the code points of the IANA registries used by SR Policy information distributed in BGP - Link State (BGP-LS). 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). The initial version of this YANG module is part of RFC XXXX; see the RFC itself for full legal notices. All revisions of IANA-maintained modules can be found in the 'YANG Parameters' registry group (https://www.iana.org/assignments/yang-parameters)."; revision 2026-10-28 { description "Initial revision."; reference "RFC XXXX: A YANG Data Model for BGP-LS Segment Routing Policy."; } typedef protocol-origin { type enumeration { enum pcep { value 1; description "PCEP."; reference "RFC 9857: Advertisement of Segment Routing Policies Using BGP - Link State."; } enum bgp-sr-policy { value 2; description "BGP SR Policy."; reference "RFC 9857: Advertisement of Segment Routing Policies Using BGP - Link State."; } enum configuration { value 3; description "Configuration (CLI, YANG model via NETCONF, etc.)."; reference "RFC 9857: Advertisement of Segment Routing Policies Using BGP - Link State."; } enum pcep-via-pce { value 10; description "PCEP (in PCEP or when BGP-LS Producer is PCE)."; reference "RFC 9857: Advertisement of Segment Routing Policies Using BGP - Link State."; } enum bgp-sr-policy-via-pce { value 20; description "BGP SR Policy (in PCEP or when BGP-LS Producer is PCE)."; reference "RFC 9857: Advertisement of Segment Routing Policies Using BGP - Link State."; } enum configuration-via-pce { value 30; description "Configuration (CLI, YANG model via NETCONF, etc. In PCEP or when BGP-LS Producer is PCE)."; reference "RFC 9857: Advertisement of Segment Routing Policies Using BGP - Link State."; } } description "Code points of the IANA 'SR Policy Protocol-Origin' registry."; reference "RFC 9857: Advertisement of Segment Routing Policies Using BGP - Link State, Section 8.4."; } typedef segment-type { type enumeration { enum type-a { value 1; description "Type A Segment."; reference "RFC 9857: Advertisement of Segment Routing Policies Using BGP - Link State."; } enum type-b { value 2; description "Type B Segment."; reference "RFC 9857: Advertisement of Segment Routing Policies Using BGP - Link State."; } enum type-c { value 3; description "Type C Segment."; reference "RFC 9857: Advertisement of Segment Routing Policies Using BGP - Link State."; } enum type-d { value 4; description "Type D Segment."; reference "RFC 9857: Advertisement of Segment Routing Policies Using BGP - Link State."; } enum type-e { value 5; description "Type E Segment."; reference "RFC 9857: Advertisement of Segment Routing Policies Using BGP - Link State."; } enum type-f { value 6; description "Type F Segment."; reference "RFC 9857: Advertisement of Segment Routing Policies Using BGP - Link State."; } enum type-g { value 7; description "Type G Segment."; reference "RFC 9857: Advertisement of Segment Routing Policies Using BGP - Link State."; } enum type-h { value 8; description "Type H Segment."; reference "RFC 9857: Advertisement of Segment Routing Policies Using BGP - Link State."; } enum type-i { value 9; description "Type I Segment."; reference "RFC 9857: Advertisement of Segment Routing Policies Using BGP - Link State."; } enum type-j { value 10; description "Type J Segment."; reference "RFC 9857: Advertisement of Segment Routing Policies Using BGP - Link State."; } enum type-k { value 11; description "Type K Segment."; reference "RFC 9857: Advertisement of Segment Routing Policies Using BGP - Link State."; } } description "Code points of the IANA 'BGP-LS SR Segment Descriptor Types' registry."; reference "RFC 9857: Advertisement of Segment Routing Policies Using BGP - Link State, Section 8.5."; } typedef metric-type { type enumeration { enum igp { value 0; description "IGP."; reference "RFC 9857: Advertisement of Segment Routing Policies Using BGP - Link State."; } enum min-unidirectional-delay { value 1; description "Min Unidirectional Delay."; reference "RFC 9857: Advertisement of Segment Routing Policies Using BGP - Link State."; } enum te { value 2; description "TE."; reference "RFC 9857: Advertisement of Segment Routing Policies Using BGP - Link State."; } enum hop-count { value 3; description "Hop Count."; reference "RFC 9857: Advertisement of Segment Routing Policies Using BGP - Link State."; } enum sid-list-length { value 4; description "SID List Length."; reference "RFC 9857: Advertisement of Segment Routing Policies Using BGP - Link State."; } enum bandwidth { value 5; description "Bandwidth."; reference "RFC 9857: Advertisement of Segment Routing Policies Using BGP - Link State."; } enum avg-unidirectional-delay { value 6; description "Avg Unidirectional Delay."; reference "RFC 9857: Advertisement of Segment Routing Policies Using BGP - Link State."; } enum unidirectional-delay-variation { value 7; description "Unidirectional Delay Variation."; reference "RFC 9857: Advertisement of Segment Routing Policies Using BGP - Link State."; } enum loss { value 8; description "Loss."; reference "RFC 9857: Advertisement of Segment Routing Policies Using BGP - Link State."; } } description "Code points of the IANA 'BGP-LS SR Policy Metric Types' registry. The User Defined range (128-255) is not enumerated."; reference "RFC 9857: Advertisement of Segment Routing Policies Using BGP - Link State, Section 8.6."; } } ]]>

Security Considerations The YANG module specified in this document defines a schema for data that is designed to be accessed through network management protocols such as NETCONF or RESTCONF . The lowest NETCONF layer is the secure transport layer, and the mandatory-to-implement secure transport is Secure Shell (SSH) . The lowest RESTCONF layer is HTTPS, and the mandatory-to-implement secure transport is TLS . 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 no data nodes defined in the ietf-bgp-ls-sr-policy module that are writable, creatable, or deletable (i.e., config true, which is the default). The module therefore introduces no write-related vulnerabilities. The iana-bgp-ls-sr-policy-types module defines only data types and no data nodes, RPCs, actions, or notifications; it introduces no security considerations of its own. 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-data, or notification) to these data nodes. These are the subtrees and data nodes and their sensitivity/vulnerability (the augmented path is abbreviated; the full path is shown in ):

.../bgp-ls:instance/bgp-ls-sr-policy:sr-policy-candidate-paths:

This subtree contains headend, endpoint, and originator addresses, Binding SIDs, complete segment lists, path constraints, requested and allocated bandwidth, and disjointness and bidirectional associations. Unauthorized read access to this information discloses network topology, traffic-engineering intent, and path-protection strategy, which identifies as potentially commercially sensitive. Such information can also assist an attacker in identifying critical nodes and links or in crafting packets that use valid SIDs.

The content of this subtree is derived from BGP-LS information received from other speakers, and the number of candidate paths, segment lists, segments, metrics, and unknown TLVs is controlled by those speakers. Implementations SHOULD apply to this subtree the same resource limits and malformed-TLV handling that apply to the underlying BGP-LS LSDB . This document defines no RPC or action operations. The security considerations of , , , , and also apply.

IANA Considerations

The "IETF XML" Registry IANA is requested to register the following URIs in the "ns" subregistry within the "IETF XML Registry" :

The "YANG Module Names" Registry IANA is requested to register the following YANG modules in the "YANG Module Names" registry within the "YANG Parameters" registry group:

Maintenance of the IANA-Maintained Module IANA is requested to post the initial version of the iana-bgp-ls-sr-policy-types YANG module defined in and to maintain it as follows. IANA is requested to add a "YANG Enum Name" column to each of the "SR Policy Protocol-Origin", "BGP-LS SR Segment Descriptor Types", and "BGP-LS SR Policy Metric Types" registries. For every assigned code point that is represented in the initial module, IANA is requested to populate that column with the name of the enum statement having the same numeric value in the corresponding typedef. The column is left empty for Reserved, Unassigned, Private Use, and User Defined entries. A future assignment that is to be represented in the module MUST include a unique YANG enum name that conforms to the identifier syntax in . IANA is requested to add the following note to the page that displays the iana-bgp-ls-sr-policy-types module:

• New values must not be added directly to the "iana-bgp-ls-sr-policy-types" YANG module. They must instead be added to the corresponding authoritative IANA registry.

When a new code point is assigned in the "SR Policy Protocol-Origin", "BGP-LS SR Segment Descriptor Types", or "BGP-LS SR Policy Metric Types" registry, other than in the Reserved, Private Use, or User Defined ranges, a new enum statement MUST be added to the corresponding protocol-origin, segment-type, or metric-type typedef of the module. The enum statement MUST have the following sub-statements:

enum:

The YANG enum name recorded in the registry.

value:

The assigned code point.

description:

The description of the code point in the registry.

reference:

The reference of the code point in the registry, including the title of the referenced document.

When the description or reference of a code point is updated in one of these registries, the corresponding enum statement MUST be updated. When a code point is deprecated or made obsolete, a status sub-statement with the value deprecated or obsolete, respectively, MUST be added to the corresponding enum statement. Each time the module is updated, a new revision statement MUST be added before the existing revision statements. The description of the new revision statement MUST identify the changes made. IANA is requested to add the following note to each of the three registries listed above:

• When this registry is modified, the YANG module "iana-bgp-ls-sr-policy-types" must be updated as defined in RFC XXXX.

RFC Editor: Please replace XXXX with the RFC number assigned to this document and remove this note.

References Normative References YANG is a data modeling language used to model configuration data, 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 defines a collection of common data types using the YANG data modeling language. These derived common types are designed to be imported by other modules defined in the routing area. Datastores are a fundamental concept binding the data models written in the YANG data modeling language to network management protocols such as the Network Configuration Protocol (NETCONF) and RESTCONF. This document defines an architectural framework for datastores based on the experience gained with the initial simpler model, addressing requirements that were not well supported in the initial model. This document updates RFC 7950. 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. This document introduces a generic mechanism to create a grouping of Label Switched Paths (LSPs) in the context of a Path Computation Element (PCE). This grouping can then be used to define associations between sets of LSPs or between a set of LSPs and a set of attributes (such as configuration parameters or behaviors), and it is equally applicable to the stateful PCE (active and passive modes) and the stateless PCE. Segment Routing (SR) allows a node to steer a packet flow along any path. Intermediate per-path states are eliminated thanks to source routing. SR Policy is an ordered list of segments (i.e., instructions) that represent a source-routed policy. Packet flows are steered into an 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. This document updates RFC 8402 as it details the concepts of SR Policy and steering into an SR Policy. Segment Routing over IPv6 (SRv6) allows for a flexible definition of end-to-end paths within various topologies by encoding paths as sequences of topological or functional sub-paths called "segments". These segments are advertised by various protocols such as BGP, IS-IS, and OSPFv3. This document defines extensions to BGP - Link State (BGP-LS) to advertise SRv6 segments along with their behaviors and other attributes via BGP. The BGP-LS address-family solution for SRv6 described in this document is similar to BGP-LS for SR for the MPLS data plane, which is defined in RFC 9085. In many environments, a component external to a network is called upon to perform computations based on the network topology and the current state of the connections within the network, including Traffic Engineering (TE) information. This is information typically distributed by IGP routing protocols within the network. This document describes a mechanism by which link-state and TE information can be collected from networks and shared with external components using the BGP routing protocol. This is achieved using a BGP Network Layer Reachability Information (NLRI) encoding format. The mechanism applies to physical and virtual (e.g., tunnel) IGP links. The mechanism described is subject to policy control. Applications of this technique include Application-Layer Traffic Optimization (ALTO) servers and Path Computation Elements (PCEs). This document obsoletes RFC 7752 by completely replacing that document. It makes some small changes and clarifications to the previous specification. This document also obsoletes RFC 9029 by incorporating the updates that it made to RFC 7752. This document describes a mechanism used to collect Segment Routing (SR) Policy information that is locally available in a node and advertise it into BGP - Link State (BGP-LS) updates. Such information can be used by external components for path computation, reoptimization, service placement, network visualization, etc. This document defines a collection of common data types to be used with the YANG data modeling language. It includes several new type definitions and obsoletes RFC 6991. 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. Arrcus, Inc Arrcus, Inc Cisco, Inc This document defines a YANG data model for configuration and management of BGP-LS, BGP-LS-VPN, and BGP-LS-SPF. IANA n.d. In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Informative References 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. 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] This document describes a method for invoking and running the Network Configuration Protocol (NETCONF) within a Secure Shell (SSH) session as an SSH subsystem. This document obsoletes RFC 4742. [STANDARDS-TRACK] 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 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. IEEE

Complete Tree Diagram This appendix provides the complete tree diagram for the operational data defined by the ietf-bgp-ls-sr-policy module.

Examples This appendix provides non-normative examples of the BGP-LS LSDB populated with an SR-MPLS candidate path and an SRv6 candidate path. The data is shown under the bgp-ls-topology container of the link-state container of the BGP-LS AFI/SAFI. The examples use the XML encoding defined in and the IPv4 and IPv6 documentation address prefixes.

SR-MPLS Candidate Path The following example contains one SR-MPLS explicit candidate path instantiated by local configuration (Protocol-Origin 3). The candidate path has an allocated Binding SID and one segment list containing a Type C segment (IPv4 Prefix SID). bgp:bgp example bgp-ls:bgp-ls default sr 0 65000 192.0.2.1 0 192.0.2.1 :: configuration 192.0.2.200 100 65000 192.0.2.1 1 blue-policy primary allocated 16000 100 active evaluated valid 200 0 explicit computed verified resolved 1 10 0 type-c sid-present verified resolved 16001 0 192.0.2.2 ]]>

SRv6 Candidate Path The following example contains one SRv6 dynamic candidate path with an allocated SRv6 Binding SID and one computed segment list containing a Type I segment (SRv6 End SID). The headend is identified only by its IPv6 Router-ID; the IPv4 Router-ID key leaf therefore contains the unspecified address. bgp:bgp example bgp-ls:bgp-ls default sr 0 65000 192.0.2.1 0 0.0.0.0 2001:db8::1 configuration endpoint-ipv6 2001:db8::200 200 65000 192.0.2.1 1 green-policy 0 2001:db8:100::1 allocated 100 active evaluated valid 200 0 srv6-dataplane computed verified 1 0 type-i sid-present verified resolved 2001:db8:200::1 0 2001:db8::2 ]]>

Acknowledgments The authors would like to thank the authors and contributors of and for their work on the protocol definitions and the base YANG model used by this document.