Associating Segment Routing (SR) Policy with Network Resource Partition (NRP)

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶

This Internet-Draft will expire on 29 December 2024.¶

Copyright Notice

Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved.¶

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶

Table of Contents

1. Introduction

The concept and architecture of Segment Routing (SR) Policy is defined in [RFC9256]. An SR Policy is a set of candidate paths, each consisting of one or more segment lists. The head end node 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.¶

[RFC9543] introduces the concept and the characteristics of network slice built using IETF technologies, and describes a general framework for RFC 9543 network slice management and operation. [I-D.ietf-teas-enhanced-vpn] describes the framework and the candidate component technologies for delivering enhanced VPN services. Enhanced VPN can be used for the realization of RFC 9543 network slices. [RFC9543] also introduces the concept Network Resource Partition (NRP), which is a subset of the network resources and associated policies in the underlay network. An NRP can be used to support one or a group of enhanced VPN or RFC 9543 network slice services.¶

In SR networks, an NRP can be realized using NRP-specific resource-aware segments as defined in [I-D.ietf-spring-resource-aware-segments] and [I-D.ietf-spring-sr-for-enhanced-vpn]. With this approach, a separate set of resource-aware SIDs need to be assigned for each NRP.¶

For network scenarios where the number of NRP is large, [I-D.ietf-teas-nrp-scalability] suggests to introduce a dedicated NRP ID in the data packet. The data plane NRP ID is a network-wide identifier which can be used by network nodes to identify the set of network resources allocated to the NRP. This is considered as a scalable approach for realizing NRP, as the number of SR SIDs will not be proportional to the number of NRPs. The mechanisms for encapsulating NRP ID in data packet are out of the scope of this document and are specified in separate documents. The encapsulation of NRP information in IPv6 data plane is specified in [I-D.ietf-6man-enhanced-vpn-vtn-id], and the encapsulation of NRP information in MPLS data plane is specified in [I-D.li-mpls-enhanced-vpn-vtn-id].¶

In SR networks where there are multiple NRPs, an SR Policy may need to be associated with a particular NRP. Within the NRP, the SR Policy can be used for steering and forwarding traffic which is mapped to the NRP, so that the traffic can be forwarded along the selected path using the subset of network resources and policy of the NRP for guaranteed performance. For NRPs built with resource-aware segments, the association of SR Policy with NRP can be achieved by using NRP-specific resource-aware SIDs to construct the segment lists of the SR Policy. For NRPs built using dedicated data plane NRP ID, normal SR SIDs will be used for the segment lists of SR Policy, then the association between SR Policy and NRP needs to be specified explicitly.¶

This document defines extensions to the SR Policy Architecture for associating SR Policy with NRP.¶

2. Associating SR Policy with NRP

As defined in [RFC9256], an SR Policy is associated with one or more candidate paths. A candidate path is the unit for signaling of an SR Policy to a headend via protocol extensions like the Path Computation Element Communication Protocol (PCEP) [RFC8664] [I-D.ietf-pce-segment-routing-policy-cp] or BGP SR Policy [I-D.ietf-idr-sr-policy-safi]. A candidate path consists of one or multiple segment lists. The segment lists are used for load balancing.¶

The association between SR Policy and NRP is specified at the candidate path level. For an SR Policy associated with NRP, each of its candidate path needs to be associated with an NRP. The NRP ID is used to indicate the NRP to which the SR Policy candidate path is associated with. All the segment lists of the candidate path are associated with the same NRP. The protocol extensions for signaling of the SR Policy associated with NRP are described in [I-D.ietf-idr-sr-policy-safi] and [I-D.dong-pce-pcep-nrp], and the mechanism for advertising the status of SR Policy which is associated with NRP is described in [I-D.chen-idr-bgp-ls-sr-policy-nrp].¶

     SR Policy POL1: <Headend = H1, Color = 1, Endpoint = E1>
          Binding SID
          Candidate Path CP1 <Protocol-Origin, Originator, Discriminator>
              Preference
              Priority
              NRP
              Segment List 1
                   Weight W1
                   Segments <SID11...SID1i>
              Segment List 2
                   Weight W2
                   Segments <SID21...SID2i>
          Candidate Path CP2 <Protocol-Origin, Originator, Discriminator>
              Preference
              Priority
              NRP
              Segment List 3
                   Weight W3
                   Segments <SID31...SID3i>
              Segment List 4
                   Weight W4
                   Segments <SID41...SID4i>
          ...

3. Security Considerations

This document introduces no additional security vulnerabilities in addition to the ones as described in [RFC9256].¶

4. IANA Considerations

This document has no IANA actions.¶

5. Acknowledgements

The authors would like to thank XXX for the review and discussion of this document.¶

Authors' Addresses