BGP SR Policy Extensions for Network
Resource PartitionHuawei Technologiesjie.dong@huawei.comHuawei Technologieshuzhibo@huawei.comChina Unicompangran@chinaunicom.cnIDR Working GroupSegment Routing (SR) Policy is a set of candidate paths, each
consisting of one or more segment lists and the associated information.
The header of a packet steered in an SR Policy is augmented with an
ordered list of segments associated with that SR Policy. A Network
Resource Partition (NRP) is a collection of network resources allocated
in the network which can be used to support one or a group of IETF
network slice services.In networks where there are multiple NRPs, an SR Policy may be
associated with a particular NRP. The association between SR Policy and
NRP needs to be specified, so that for service traffic which is steered
into the SR Policy, the header of the packets can be augmented with the
information associated with the NRP. An SR Policy candidate path can be
distributed using BGP SR Policy. This document defines the extensions to
BGP SR policy to specify the NRP which the SR Policy candidate path is
associated with.The concept of Segment Routing (SR) policy is defined in . An SR Policy is a set
of candidate paths, each consisting of one or more segment lists. The
head end of an SR Policy may learn multiple candidate paths for an SR
Policy. The header of a packet steered in an SR Policy is augmented with
an ordered list of segments associated with that SR Policy. The BGP
extensions to distribute SR Policy candidate paths is defined in . introduces the
concept and the characteristics of IETF network slice, and describes a
general framework for IETF network slice management and operation. It
also introduces the concept Network Resource Partition (NRP), which is a
collection of resources identified in the underlay network. IETF network
slice can be realized by mapping a set of connectivity constructs to a
network resource partition (NRP). describes the framework and the
candidate component technologies for providing enhanced VPN (VPN+)
services based on VPN and Traffic Engineering (TE) technologies.
Enhanced VPN (VPN+) can be used for the realization of IETF network
slices. In the context of network slicing, an NRP is considered as an
instantiation of the VTN as defined in .As described in , one
scalable data plane approach is to carry a dedicated NRP ID in the data
packet to identify the NRP the packet belongs to, so that the packet can
be processed and forwarded using the set of network resources allocated
to the NRP.In networks where there are multiple NRPs, an SR Policy may be
associated with a particular NRP. The association between SR Policy and
NRP needs to be specified, so that for service traffic which is steered
into the SR Policy, the header of the packets can be augmented with the
information associated with the NRP. An SR Policy candidate path can be
distributed using BGP SR Policy. This document defines the extensions to
BGP SR policy to specify the NRP which the SR Policy candidate path is
associated with.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
BCP14 when, and only
when, they appear in all capitals, as shown here.In order to specify the NRP the candidate path of SR policy is
associated with, a new sub-TLV called "NRP sub-TLV" is defined in the
BGP Tunnel Encapsulation Attribute . The NRP
sub-TLV can be carried in the BGP Tunnel Encapsulation Attribute with
the tunnel type set to SR Policy.The NRP sub-TLV is optional and MUST NOT appear more than once for
one SR Policy candidate path. If the NRP sub-TLV appears more than once,
the associated BGP SR Policy NLRI is considered malformed and the
"treat-as-withdraw" strategy of is applied.The NRP sub-TLV has the following format:where:Type: 123Length: 6Flags: 1-octet flag field. None is defined at this stage. The
flags SHOULD be set to zero on transmission and MUST be ignored on
receipt.RESERVED: 1 octet of reserved bits. It SHOULD be set to zero on
transmission and MUST be ignored on receipt.NRP ID: A 32-bit domain significant identifier which is used to
identify a NRP. Value 0 and 0xFFFFFFFF are reserved.The encoding structure of BGP SR Policy with the NRP sub-TLV is
expressed as below:When a candidate path of SR Policy is instantiated with a specific
NRP, the originating node of SR Policy SHOULD include the NRP sub-TLV in
the BGP Tunnel Encapsulation Attribute of the BGP SR Policy. The setting
of other fields and attributes in BGP SR Policy SHOULD follow the
mechanism as defined in .When a BGP speaker receives an SR Policy which is acceptable and
usable according to the rules as defined in , and the SR Policy
candidate path selected as the best candidate path is associated with an
NRP, the receiver node of the SR Policy SHOULD encapsulate the NRP ID in
the header of packets which are steered to the SR Policy. For SR Policy
with IPv6 data plane, the approach is to encapsulate the NRP ID in IPv6
Hop-by-Hop Options header using the mechanism as defined in . For SR Policy with MPLS
data plane, one possible mechanism to encapsulate the NRP ID to the
packet is defined in .Although the proposed mechanism allows that different candidate paths
in one SR policy be associated with different NRPs, in normal network
scenarios it is considered that the association between an SR Policy and
NRP is consistent, in such case all candidate paths of one SR policy
SHOULD be associated with the same NRP.The security considerations of BGP and BGP SR policy apply to this
document.IANA has assigned the sub-TLV type as defined in Section 3 from "BGP
Tunnel Encapsulation Attribute sub-TLVs" registry.The authors would like to thank Guoqi Xu, Lei Bao, Haibo Wang and
Shunwan Zhuang for their review and discussion of this document.Key words for use in RFCs to Indicate Requirement
LevelsIn 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.