BGP SR Policy Extensions for Virtual Transport Network

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 . The concept of Virtual Transport Network (VTN) is introduced in . A VTN is a virtual underlay network which has customized network topology and a set of dedicated or shared network resources. In a network, different VTNs may be created to meet different service requirements, and different services can be mapped to different VTNs. In scenarios where multiple virtual networks (VTNs) exist in the network, the identifier of VTN in which the SR policy is instantiated may also need to be specified, so that the header of data packet can also be augmented with the information of the associated VTN. This document defines the BGP extensions to specify the VTN ID associated with a candidate path of SR policy.

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 .

In order to specify the VTN the candidate path of SR policy is associated with, a new sub-TLV called "VTN sub-TLV" is defined in the BGP Tunnel Encapsulation Attribute . The VTN sub-TLV can be carried in the BGP Tunnel Encapsulation Attribute with the tunnel type set to SR Policy. The VTN sub-TLV is optional and MUST NOT appear more than once for one SR Policy candidate path. If the VTN 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 VTN sub-TLV has the following format:

where: Type: 123 Length: 6 Flags: 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. All of the reserved bits SHOULD be set to zero on transmission and MUST be ignored on receipt. VTN ID: A 32-bit global significant identifier which is used to identify a VTN. Value 0 and 0xFFFFFFFF are reserved. The encoding structure of BGP SR Policy with the VTN sub-TLV is expressed as below:

Attributes: Tunnel Encaps Attribute (23) Tunnel Type: SR Policy Binding SID Preference Priority Policy Name Explicit NULL Label Policy (ENLP) VTN Segment List Weight Segment Segment ... ...]]>

When a candidate path of SR policy is associated with a specific VTN, the originating node of SR policy SHOULD include the associated VTN in the BGP Tunnel Encapsulation Attribute of the BGP SR policy. The setting of other fields and attributes in BGP SR policy SHOULD follows 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 a VTN, the receiver node of the SR policy SHOULD encapsulate VTN-specific information to the header of packets steered to the SR policy. For SR Policy with IPv6 data plane, the possible approach is to encapsulate the VTN-ID to the packet using the mechanism defined in . For SR Policy with MPLS data plane, the usage of the VTN information is similar, the possible mechanism to encapsulate the VTN-ID to the packet is defined in Although the proposed mechanism allows that different candidate paths in one SR policy be associated with different VTNs, in normal network scenarios it is considered that the mapping between service to VTN is consistent, in such case all candidate paths of one SR policy are associated with the same VTN.

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 and Haibo Wang for the review and discussion of this document.