SR Policy
Extensions for Path Segment and Bidirectional PathHuawei TechnologiesHuawei Campus, No. 156 Beiqing Rd.Beijing100095Chinac.l@huawei.comHuawei TechnologiesHuawei Campus, No. 156 Beiqing Rd.Beijing100095Chinalizhenbin@huawei.comChina TelecomGuangzhouChinayinyuany@chinatelecom.cnChina MobileBeijingChinachengweiqiang@chinamobile.comCisco Systemsketant.ietf@gmail.com
Routing Area
Interdomain Routing Working GroupA Segment Routing (SR) policy is a set of candidate SR paths
consisting of one or more segment lists with necessary path attributes.
For each SR path, it may also have its own path attributes, and Path
Segment is one of them. A Path Segment is defined to identify an SR
path, which can be used for performance measurement, path correlation,
and end-2-end path protection. Path Segment can be also used to
correlate two unidirectional SR paths into a bidirectional SR path which
is required in some scenarios, for example, mobile backhaul transport
network.This document defines extensions to BGP to distribute SR policies
carrying Path Segment and bidirectional path information.The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119.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 . For distributing SR
policies to the headend, specifies a mechanism
by using BGP, and new sub-TLVs are defined for SR Policies in BGP UPDATE
message.In many use cases such as performance measurement, the path to which
the packets belong is required to be identified. Futhermore, in some
scenarios, for example, mobile backhaul transport network, there are
requirements to support bidirectional path. However, there is no path
identification information for each Segment List in the SR Policies
defined in .
Also, the SR Policies defined in only supports
unidirectional SR paths.Therefore, this document defines the extension to SR policies that
carry Path Segment in the Segment List and support bidirectional path.
The Path Segment can be a Path Segment in SR-MPLS and SRv6 , or other IDs that can
identify a path. Also, this document defines extensions to BGP to
distribute SR policies carrying Path Segment and bidirectional path
information.This memo makes use of the terms defined in
and .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.As defined in
, the SR Policy encoding structure is as follows:An SR path can be specified by an Segment List sub-TLV that contains
a set of segment sub-TLVs and other sub-TLVs as shown above. As defined
in , a candidate
path includes multiple SR paths specified by SID list. The Path Segment
can be used for identifying an SR path(specified by SID list) from the
headend and the tailend. Also, it can be used for identifying an SR
candidate path in some use cases if needed. This document defines a new
Path Segment sub-TLV within Segment List sub-TLV, the details will be
described at section 3.1. The new SR Policy encoding structure with Path
Segmentg sub-TLV is expressed as below:The Path Segment is used to identified an SR path, and it can be used
in OAM or IOAM use cases. When all the SID Lists within a candidate path
share the same Path Segment ID, the Path Segment can be used to collect
the aggregated information of the candidate path. Multiple Path Segment
MAY be included in a Segment List for different use cases, all of them
SHOULD be inserted into the SID List.This section defines an SR Path Segment sub-TLV.An SR Path Segment sub-TLV is included in the segment list sub-TLV
to identify an SID list. It has the following format:Where:Type: to be assigned by IANA.Length: the total length of the value field not including Type
and Length fields.Flags: 8 bits of flags. Following flags are defined:L-Flag: Local flag. Set when the Path Segment has local
significance on an SR node. B-Flag: This flag, when set, indicates the presence of the
SRv6 Endpoint Behavior and SID Structure encoding specified in
Section 2.4.4.2.13 of . It MUST be
ignored when the value of length field is smaller than 18.The rest bits of Flag are reserved and MUST be set to 0 on
transmission and MUST be ignored on receipt.Path Segment ID: if the length is 2, then no Path Segment ID is
present. If the length is 6 then the Path Segment ID is encoded in
4 octets using
the format below. TC, S, TTL (Total of 12 bits) are RESERVED and
SHOULD be set to zero and MUST be ignored. If the length is 18 then the Path Segment ID contains a 16-octet
SRv6 Path Segment ID .If the length is larger than 18 and B-flag is set, then SRv6
Endpoint Behavior and SID Structure TLVs is included.In some scenarios, for example, mobile backhaul transport network,
there are requirements to support bidirectional path. In SR, a
bidirectional path can be represented as a binding of two unidirectional
SR paths. This document also defines a Reverse Segment List sub-TLV to
describe the reverse path associated with the forward path specified by
the Segment List. An SR policy carrying SR bidirectional path
information is expressed as below:A Reverse Path Segment List sub-TLV is defined to specify an SR
reverse path associated with the path specified by the Segment List,
and it has the following format:where:Type: TBA.Length: the total length of the sub-TLVs encoded within the Reverse
Path Segment List Sub-TLV not including the Type and Length
fields.RESERVED: 1 octet of reserved bits. SHOULD be unset on transmission
and MUST be ignored on receipt.sub-TLVs, reuse the sub-TLVs in Segment List defined in . One or more mandatory SR Path Segment sub-TLVs that contains
the Path Segments of the reverse SR path.One or more Segment sub-TLVs to specify the reverse SR
path.The Segment sub-TLVs in the Reverse Path Segment List sub-TLV
provides the information of the reverse SR path, which can be used for
directing egress BFD peer to use specific path for the reverse
direction of the BFD session or other applications.The document does not bring new operation beyond the description of
operations defined in . The existing
operations defined in can apply to this
document directly.Typically but not limit to, the unidirectional or bidirectional SR
policies carrying path identification infomation are configured by a
controller.After configuration, the unidirectional or bidirectional SR policies
carrying path identification infomation will be advertised by BGP update
messages. The operation of advertisement is the same as defined in , as well as the
reception.The consumer of the unidirectional or bidirectional SR policies is
not the BGP process, it can be any applications, such as performance
measurement . The operation of
sending information to consumers is out of scope of this document.This document defines new Sub-TLVs in following registries:This document defines new sub-TLVs in the registry "SR Policy List
Sub-TLVs" to
be assigned by IANA:TBAMany thanks to Shraddha Hedge for her detailed review and
professional comments.