BGP SR Policy Extensions for Network Resource Partition

Abstract

Segment 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 subset of network resources allocated in the underlay network which can be used to support one or a group of RFC 9543 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.¶

2. NRP Identifier of SR Policy

In order to specify the NRP the candidate path of SR policy is associated with, a new sub-TLV called "NRP ID" sub-TLV is defined in the BGP Tunnel Encapsulation Attribute [RFC9012]. The NRP ID sub-TLV can be carried in the BGP Tunnel Encapsulation Attribute with the tunnel type set to SR Policy. The use of the NRP ID sub-TLV in other tunnel types is outside the scope of this document.¶

The NRP sub-TLV has the 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      |     Flags     |   Reserved    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         NRP ID (4 octets)                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                      Figure 1. NRP ID Sub-TLV

where:¶

• Type: 123 (assigned by IANA)¶

• Length: 6 octets.¶

• Flags: 1-octet flag field. None is defined at this stage. The flags MUST be set to zero on transmission and MUST be ignored on receipt.¶

• Reserved: 1 octet of reserved bits. It MUST 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 an NRP in the control plane [I-D.ietf-teas-ns-ip-mpls]. The values of 0 and 0xFFFFFFFF are reserved.¶

The encoding structure of BGP SR Policy with the NRP ID sub-TLV is expressed as below:¶

         SR Policy SAFI NLRI: <Distinguisher, Policy-Color, Endpoint>
         Attributes:
            Tunnel Encaps Attribute (23)
               Tunnel Type: SR Policy (15)
                   Binding SID
                   SRv6 Binding SID
                   Preference
                   Priority
                   Policy Name
                   Policy Candidate Path Name
                   Explicit NULL Label Policy (ENLP)
                   NRP ID
                   Segment List
                       Weight
                       Segment
                       Segment
                       ...
                   ...
             Figure 2. SR Policy Encoding with NRP ID sub-TLV

The NRP ID sub-TLV is optional and MUST NOT appear more than once for one SR Policy candidate path.¶

3. Procedures

When a candidate path of SR Policy is instantiated within an NRP, and a network-wide data plane NRP Selector ID is used for identifying the resources of the NRP, the originating node of SR Policy MUST include the NRP ID sub-TLV in the BGP Tunnel Encapsulation Attribute of the BGP SR Policy. The setting of other fields and attributes in BGP SR Policy follows the mechanism as defined in [RFC9830].¶

On reception of an SR Policy NLRI with NRP ID sub-TLV in the BGP Tunnel Encapsulation Attribute , a BGP speaker determines if it is valid and usable according to the rules defined in Section 4.2 of [RFC9830].¶

The selected best routes of the SR Policy SAFI is passed on to the SR Policy Module (SRPM) for further processing as described in Section 4.2.2 of [RFC9830].¶

Although the proposed mechanism allows different candidate paths in one SR policy to 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.¶

4. Error Handling

The error handling of the BGP Update messages for BGP SR Policy SAFI with the NRP extensions defined in this document follows the procedures in section 5 of [RFC9830].¶

The NRP ID sub-TLV is considered malformed if its format does not match the above description. If the NRP ID sub-TLV appears more than once, or its format is considered malformed, the associated BGP SR Policy NLRI is considered malformed and the "treat-as-withdraw" strategy of [RFC7606] MUST be applied.¶

5. Operational Considerations

The mechanism specified in this document adds additional information to the signaling of SR Policy candidate paths in BGP. As the number of NRP increases, the number of SR Policies may also increase. When SR Policies are associated with different NRPs, the amount of control plane information exchanged between the network controller and the headend nodes for provisioning SR Policy would increase. However, since the SR Policy candidate paths distributed using BGP are only installed by the corresponding headend nodes, the impacts to the BGP control plane are considered acceptable.¶

9. References