SR Policies
Extensions for Path Segment and Bidirectional Path in BGP-LSHuawei TechnologiesHuawei Campus, No. 156 Beiqing Rd.Beijing100095Chinac.l@huawei.comHuawei TechnologiesHuawei Campus, No. 156 Beiqing Rd.Beijing100095Chinalizhenbin@huawei.comChina Telecom109 West Zhongshan AveGuangzhouChinazhuyq8@chinatelecom.cnChina MobileBeijingChinachengweiqiang@chinamobile.comCisco Systemsketant.ietf@gmail.com
Routing Area
Interdomain Routing Working GroupThis document specifies the way of collecting configuration and
states of SR policies carrying Path Segment and bidirectional path
information by using BPG-LS. Such information can be used by external
conponents for many use cases such as performance measurement, path
re-optimization and end-to-end protection.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 allows the ingress node steers packets into a specific
path according to the Segment Routing Policy .However, the SR Policies defined in only supports
unidirectional SR paths and there is no path ID in a Segment List to
identify an SR path. For identifying an SR path and supporting
bidirectional path ,
new policies carrying Path Segment and bidirectional path information
are defined in , as
well as the extensions to BGP to distribute new SR policies. The Path
Segment can be a Path Segment in SR-MPLS and SRv6 , or other IDs that can
identify a path.In many network scenarios, the configuration and state of each TE
Policy is required by a controller which allows the network operator to
optimize several functions and operations through the use of a
controller aware of both topology and state information .To collect the TE Policy information that is locally available in a
router, describes a
new mechanism by using BGP-LS update messages.Based on the mechanism defined in , this document describes a
mechanism to distribute configuration and states of the new SR policies
defined in to
external components using BGP-LS.This memo makes use of the terms defined in
and .A mechanism to collect states of SR Policies via BGP-LS is proposed
by . The
characteristics of an SR policy can be described by a TE Policy State
TLV, which is carried in the optional non-transitive BGP Attribute
"LINK_STATE Attribute" defined in . The TE
Policy State TLV contains several sub-TLVs such as SR TE Policy
sub-TLVs. defines the BGP
extensions for Path Segment. The encoding is shown below.Also, defines SR
policy extensions for bidirectional SR path, the encoding is shown
below:In order to collect configuration and states of unidirectional and
bidirectional SR policies defined in , this document defines
new sub-TLVs in SR TE Policy sub-TLVs. This section defines the SR Path Segment sub-TLV to describe a Path
Segment, and it can be included in the Segment List sub-TLV as defined
in . An SR Path
Segment sub-TLV can be associated with an SR path specified by a
Segment List sub-TLV. Multiple Path Segment MAY be included in a
Segment List for different 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. The
format of Path Segment TLV is shown below.Where,Type: to be assigned by IANA.Length: the total length of the value field not including Type
and Length fields.Flags: 2 octet field that indicates attribute and status of the
Path Segment. The following bit positions are defined. Other bits
SHOULD be cleared by originator and MUST be ignored by receiver.
Where:D-Flag : Indicates the dataplane for the BSIDs, it is set
when Path Segment ID is a 16-octet SRv6 SID unset when the
Path Segment ID is a 4-octet SR/MPLS label value.B-Flag: This flag, when set, indicates the presence of the
SRv6 Endpoint Behavior and SID Structure encoding specified in
. It MUST be
ignored when D-flag is unset. They indicate the SRv6 Endpoint
behavior and SID structure for the Path Segment ID value in
the TLV.L-Flag: Local flag. Set when the Path Segment has local
significance on an SR node. RESERVED: 2 octets. SHOULD be set to 0 by originator and MUST
be ignored by receiver.Path Segment ID: It indicates the Path Segment ID value based
on the status flags.The SRv6 Endpoint Behavior TLV (1250) and the SRv6 SID Structure
TLV (1252) defined in are
used as sub-TLVs of the SR Path Segment Sub-TLV to optionally indicate
the SRv6 Endpoint behavior and SID structure for the Binding SID value
in the TLV when the Path Segment is an SRv6 Path Segment.In some scenarios like 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
. An SR policy
carrying SR bidirectional path information is expressed in Figure 2.
defines a new
sub-TLV to describe a reversed SR path of an SID list. This section defines a Reverse Segment List sub-TLV to specify a
reverse SR path associated with the path specified by the Segment
List, and it reuses the format of SR Segment List TLV defined in :All fields, except the type are defined in , and this TLV reuses it
directly. The Type of this TLV is TBA.The SR Segment sub-TLV MUST be included as an
ordered set of sub-TLVs within the SR Segment List TLV when the
SID-List is not empty. A SID-List may be empty in certain cases (e.g.
for a dynamic path) where the headend has not yet performed the
computation and hence not derived the segments required for the path;
in such cases, the SR Segment List TLV SHOULD NOT include any SR
Segment sub-TLVs .Note: currently, only one reverse SID list is supported, so the
weight field CAN be ignored when processing. However, multiple reverse
SID list MAY be supported in the future, and the use case of
supporting this still need to be discussed.The operations procedures of can apply to
this document.Typically but not limited to, the uni/bidirectional SR policies
carrying path identification information can be distributed by the
ingress node.Generally, BGP-LS is used for collecting link states and
synchronizing with the external component. The consumer of the
uni/bidirectional SR policies carrying path identification information
is not BGP LS process by itself, and it can be any applications such as
performance measurement and
path re-coputation or re-optimization, etc. The operation of sending
information to other precesses is out of scope of this document.IANA maintains a registry called "Border Gateway Protocol - Link
State (BGP-LS) Parameters" with a sub-registry called "Node Anchor,
Link Descriptor and Link Attribute TLVs". The following TLV codepoints
are suggested (for early allocation by IANA):TBAMany thanks to Shraddha Hedge for her detailed review and
professional comments.