| Internet-Draft | BGP-LS SR Policy | March 2023 |
| Liu & Peng | Expires 2 October 2023 | [Page] |
This document defines extensions to BGP in order to advertise Network Resource Partition (NRP) in SR policy.¶
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 2 October 2023.¶
Copyright (c) 2023 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.¶
[I-D.ietf-teas-ietf-network-slices] specified the definition of the IETF Network Slice and the general principles of network slicing in the IETF context. It introduced the concept of Network Resource Partition (NRP), which is is a subset of the forwarding resources and associated policies on each of a connected set of links in the underlay network.¶
[I-D.ietf-teas-ns-ip-mpls] introduces the terminology NRP Identifier (NRP-ID) which is globally unique within an NRP domain and that can be used in the control or management plane to identify the resources associated with the NRP.¶
[RFC9256] details the concepts of SR Policy and steering into an SR Policy.[I-D.ietf-idr-segment-routing-te-policy] specifies the way to use BGP to distribute one or more of the candidate paths of an SR Policy to the headend of that policy.¶
This document defines extensions to BGP in order to advertise NRP-ID in 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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶
To distinguish forwarding behavior of different network slices, each segment lists in SR policy need to be computed within the scope of NRP identified by NRP-ID. As NRP has global significance, all segments of the same segment list can share a single NRP. This document defines a new NRP sub-TLV in Segment List Sub-TLV to indicate which slice this segment list belongs to,¶
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=TBD1 | Length | Flags | RESERVED |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NRP-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
where,¶
The new SR Policy encoding structure with Path Segmentg sub-TLV is expressed as below:¶
SR Policy SAFI NLRI: <Distinguisher, Policy-Color, Endpoint>
Attributes:
Tunnel Encaps Attribute (23)
Tunnel Type: SR Policy
Binding SID
Preference
Priority
Policy Name
Explicit NULL Label Policy (ENLP)
Segment List
Weight
NRP-ID
Segment
Segment
Segment
...
Segment
Segment
Segment
...
...
¶
The operations about advertisement and reception of SR policy can refer to [I-D.ietf-idr-segment-routing-te-policy]. Typically, a controller can compute SR path taking acount of NRP criteria, so that the SR path can be limited in the scope of NRP identified by NRP-ID. The controller can obtain the NRP virtual topology information through necessary tools such BGP-LS, netconf, etc, and maintain the database for the traffic engineering path computation. The proposal in this document supports that multiple segment list each with different NRP-ID, to meet the requirements that service flow is carried by multiple network slices. However, it also support that all segment list or all candidate path of the SR policy belongs to the same slice.¶
The NRP information contained in Segment List Sub-TLV can help the headend to translate the segment to NRP related SID, if the Segment Sub-TLV has not provided optional SID information. Even if Segment Sub-TLV has provided valid SID information, it is also beneficial for the headend to know which slice this path belongs to, according to the NRP information contained in Segment List Sub-TLV.¶
TBD¶
Procedures and protocol extensions defined in this document do not affect the security considerations discussed in [I-D.ietf-idr-segment-routing-te-policy].¶