Signaling Composite Candidate Path of SR Policy using BGP-LS
New H3C Technologieslinchangwang.04414@h3c.comChina Mobilechengweiqiang@chinamobile.comCisco Systems, Inczali@cisco.comCisco Systems, Incaramahen@cisco.comZTE CorporationNanjingChinachen.ran@zte.com.cn
General
Network Working GroupSegment RoutingSR PolicyBGP-LSSR Policy Architecture [RFC9256] defines the concept of a Composite Candidate Path.
A regular SR Policy Candidate Path outputs traffic to a set of Segment Lists,
while an SR Policy Composite Candidate Path outputs traffic recursively to a set of SR Policies
on the same headend. This document specifies the extensions to BGP Link State (BGP-LS) to
carry composite candidate path information in the advertisement of an SR policy.As described in , BGP Link State (BGP-LS) provides a mechanism by which link-state and TE information can be collected from networks and shared with external components using the BGP routing protocol.Segment routing (SR) is a source routing paradigm that explicitly indicates the forwarding path for packets at the ingress node. The ingress node steers packets into a specific path according to the Segment Routing Policy (SR Policy) as defined in .SR Policy Architecture defines the concept of a Composite Candidate Path. A regular SR Policy Candidate Path outputs traffic to a set of Segment Lists, while an SR Policy Composite Candidate Path outputs traffic recursively to a set of SR Policies on the same headend. An SR Policy is associated with one or more candidate paths. A composite candidate path acts as a container for grouping of SR Policies. As described in section 2.2 in [RFC9256], the composite candidate path construct enables combination of SR Policies, for a load-balanced steering of packet flows over its constituent SR Policies. defines extensions for BGP to distribute SR policies carrying composite candidate path information. While as defined in Section 3.6 of , PCEP signals the Composite Candidate Path. describes a mechanism to collect the SR policy information that is locally available in a node and advertise it into BGP-LS updates.
This document extends it to provide some extra information to carry composite candidate path information in the BGP-LS advertisement.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. defines the BGP-LS NLRI that can be a Node NLRI, a Link NLRI or a Prefix NLRI. The corresponding BGP-LS attribute is a Node Attribute, a Link Attribute or a Prefix Attribute. describes a mechanism to collect the SR Policy information that is locally available in a node and advertise it into BGP Link State (BGP-LS) updates. This section defines a new sub-TLV which is carried in the optional non-transitive BGP Attribute "LINK_STATE Attribute" defined in .Segment Routing Policy (SR Policy) architecture is specified in . A SR Policy can comprise of one or more candidate paths, and each candidate path is either dynamic, explicit or composite. A composite candidate path can comprise of one or more constituent SR policies. The endpoints of the constituent SR Policies and the parent SR Policy MUST be identical, and the colors of each of the constituent SR Policies and the parent SR Policy MUST be different.The Composite Candidate Path TLV is used to report the constituent SR policy(s) of a composite candidate path. It is carried in the optional non-transitive BGP-
LS Attribute defined in [RFC9552] and is associated with the SR
Policy Candidate Path NLRI type. Only a single instance
of this TLV is advertised for a given candidate path. If multiple
instances are present, then the first valid (i.e., not determined to
be malformed as per section 8.2.2 of [RFC9552]) one is used and the
rest are ignored.The TLV has following format:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RESERVED |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Color |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Weight |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sub-TLVs (variable) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
where:
Type: to be assigned by IANA.Length: the total length of the value field not including Type and Length fields.Reserved: 32 bits reserved and MUST be set to 0 on transmission and MUST be ignored on receipt.Color: 4 octets that indicates the color of the constituent SR Policy.Weight: 4 octet field that indicates the weight associated with the SID-List for weighted load-balancing. Refer Section 2.2 and 2.11 of .Sub-TLVs: variable and contains any other optional attributes
associated with the Composite Candidate Path. Currently, the sub-TLV only defines the Per-Flow Forwarding Class TLV.Per-Flow Candidate Path builds on top of the concept of the Composite Candidate Path.
Each Path in a Per-Flow Candidate Path is assigned a 3-bit forward class value,
which allows Quality of Service (QoS) classified traffic to be steered depending on the forward class.
The Per-Flow Forwarding Class TLV is an optional sub-TLV of the Composite Candidate Path TLV.Only a single instance of this sub-TLV is
advertised for a given candidate path. If multiple instances are
present, then the first valid (i.e., not determined to be malformed
as per section 8.2.2 of [RFC9552]) one is used and the rest are
ignored.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | FC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
where:
Type (16 bits): TBD1 for "PER-FLOW-FORWARD-CLASS" TLV.Length (16 bits): 4.Reserved: This field MUST be set to zero on transmission and MUST be
ignored on receipt.FC (3 bits): Forward class value that is given by the QoS classifier to
traffic entering the given Candidate Path. Different classes of traffic
that enter the given Candidate Path can be differentially steered into
different Colors.The document does not bring new operation beyond the description of operations defined in and . The existing operations defined in and can apply to this document directly.Typically but not limit to, the BGP-LS messages carrying composite candidate path information along with the SR policy are distributed to a controller.After configuration, the composite candidate path information will be advertised by BGP update messages. The operation of advertisement is the same as defined in and , as well as the reception.Procedures and protocol extensions defined in this document do not
affect the BGP security model. See the "Security
Considerations" section of for a discussion of BGP security.
Security considerations for acquiring and distributing BGP-LS
information are discussed in . Security considerations for
acquiring and distributing BGP-LS SR Policy information are discussed in .
Additionally, reporting SR policies that carry composite candidate path information
MAY pose a risk to the confidentiality of mission-critical or commercially sensitive network information.
It is the responsibility of the network operator to ensure that only trusted nodes (including both routers and controller applications)
within the SR domain are configured to receive such information.
This document defines a new TLV in the BGP-LS NLRI and Attribute TLVs:ValueDescriptionReferenceTBAComposite Candidate PathThis documentTBAPer-Flow Forwarding ClassThis documentCross-WG Information This section describes cross-working group information for use
during the IETF review process. This section will be removed by the RFC editor prior to publication. Spring WG Section 2.2 of [RFC9256] defines the concept of a Composite Candidate Path.
Section 2.13 of [RFC9256] illustrates an information model for hierarchical relationships
between the SR Policy constructs.
A Parent SR Policy is the composite candidate path that acts as a container for
grouping SR Policies which meet different service optimization objectives and constraints
and have the same destination endpoint. [I-D. draft-ietf-spring-sr-policy-group]
defines illustrates some use cases for parent SR Policy and SR Policy Group to
simplify deployment and provide best practice cases for operators.
PCE WG Composite Candidate Paths can be distributed via the Path Computation Element Communication Protocol (PCEP),
as described in section 3.6 of [I-D.draft-ietf-pce-multipath].
SRv6Ops defines extensions for BGP to distribute
SR policies carrying composite candidate path information. This document extends it to provide some extra
information to carry composite candidate path information in the BGP-LS advertisement.