Internet DRAFT - draft-jiang-spring-parent-sr-policy-use-cases
draft-jiang-spring-parent-sr-policy-use-cases
SPRING Working Group W. Jiang
Internet Draft W. Cheng
Intended status: Informational China Mobile
Expires: July 5, 2024 C. Lin
Y. Qiu
New H3C Technologies
January 5, 2024
Use Cases for Parent SR Policy
draft-jiang-spring-parent-sr-policy-use-cases-03
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), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
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."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
This Internet-Draft will expire on July 5 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
(http://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 Simplified BSD License text as described in
Jiang, et al. Expire July, 2024 [Page 1]
Internet-Draft Parent SR Policy January 2024
Section 4.e of the Trust Legal Provisions and are provided without
warranty as described in the Simplified BSD License.
Abstract
Segment Routing is a source routing paradigm that explicitly
indicates the forwarding path for packets at the ingress node. An
SR Policy is associated with one or more candidate paths, and each
candidate path is dynamic, explicit or composite. This document
illustrates some use cases for parent SR policy in MPLS and IPv6
environment.
Table of Contents
1. Introduction ................................................. 2
2. Terminology .................................................. 3
3. Parent SR Policy ............................................. 3
4. Steering into a Parent SR Policy ............................. 4
5. On-demand Parent SR Policy ................................... 5
6. Parent SR Policy Use Cases ................................... 6
6.1. Parent SR Policy in L3VPN over TE Scenarios ............. 6
6.2. Parent SR Policy in Cloud Backbone Acceleration Scenarios 7
6.3. Parent SR Policy in the L2VPN Network Scenarios ......... 8
6.4. Parent SR Policy in the Application-aware Scenarios ..... 8
6.5. Application of ODN Parent SR Policy in Trusted Network
Scenarios .................................................... 9
6.6. Best-effort Forwarding Scenarios when SR Policy Becomes
Unavailable ................................................. 11
7. Implementation Status ....................................... 11
8. IANA Considerations ......................................... 12
9. Security Considerations ..................................... 12
10. References ................................................. 12
10.1. Normative References .................................. 12
10.2. Informative References ................................ 12
11. Acknowledgments ............................................ 12
Authors' Addresses ............................................. 13
1. Introduction
Segment routing (SR) [RFC8402] is a source routing paradigm that
explicitly indicates the forwarding path for packets at the ingress
node. The ingress node steers packets into a specific path according
to the Segment Routing Policy (SR Policy) as defined in [RFC9256].
In order to distribute SR policies to the headend, [I-D.ietf-idr-
segment-routing-te-policy] specifies a mechanism by using BGP.
Jiang, et al. Expires July, 2024 [Page 2]
Internet-Draft Parent SR Policy January 2024
An SR Policy is associated with one or more candidate paths. A
composite candidate path acts as a container for grouping SR
Policies. As described in section 2.2 in [RFC9256], the composite
candidate path construct enables combination of SR Policies, each
with explicit candidate paths and/or dynamic candidate paths with
potentially different optimization objectives and constraints, for
load-balanced steering of packet flows over its constituent SR
Policies. For service-class based steering, and in the best-effort
forwarding scenario when SR policy becomes unavailable, packets are
also forwarded over the constituent SR policies of composite
candidate path.
For convenience, the composite candidate path formed by the
combination of SR policies is called parent SR policy. In [RFC9256],
there is no use case about SR policy composite candidate path. This
document illustrates some use cases for parent SR policy in MPLS and
IPv6 environment to provide best practice cases for operators.
2. Terminology
The definitions of the basic terms are identical to those found in
Alternate Marking [RFC8402].
The important new terms that need to be explained are listed below:
Parent SR policy: According to [RFC9256] a parent SR policy
represents a composite candidate path that acts as a container for
grouping SR policies.
ODN: On-demand Next-Hop.
ODN SR policy: Preconfigure an ODN template specified color. When
the device receives a BGP route, if the color extended attribute
value of the BGP route is the same as the color value of an ODN
template, the device can automatically create an SR policy.
ODN parent SR policy: A parent SR policy dynamically created through
ODN.
3. Parent SR Policy
An SR Policy is associated with one or more candidate paths.
According to [RFC9256] a parent SR policy is the composite candidate
path that acts as a container for grouping SR policies. The parent
SR policy is valid when it has at least one valid constituent SR
policy.
Jiang, et al. Expires July, 2024 [Page 3]
Internet-Draft Parent SR Policy January 2024
As defined in [RFC9256], the endpoints of the constituent SR
Policies and the parent SR policy MUST be identical, and the colors
of each of the constituent SR Policies and the parent SR policy MUST
be different. Parent SR policy and its constituent SR Policies
follow the same criteria:
o The endpoints of the constituent SR Policies and its parent SR
policy MUST be identical.
o The colors of each of the constituent SR Policies and its parent
SR policy MUST be different.
o The constituent SR Policies MUST NOT contain parent SR policy.
As a special SR policy, parent SR policy also has color attribute,
which is identified by <color, endpoint> on the headend.
A parent SR policy can be generated by static configuration or a
centralized controller distribution, also can be generated based on
the on-demand SR policy optimization template dynamically.
4. Steering into a Parent SR Policy
A headend can steer a packet flow into a valid parent SR policy in
various ways:
o Per-flow Steering: Specify the mapping relationship between
color and flow characteristics (such as DSCP) for parent SR
policy, and create a policy group that binds a destination IP
address. Upon receiving a packet with the specified destination
address, the device searches for the SR policy containing the
color value mapped to the flow characteristics of the packet in
the parent SR policy. The device will use the matching SR
policy to forward the packet.
The device obtains a parent SR policy for traffic steering as
follows:
* Matches the destination IP/IPv6 address in a packet with a
parent SR policy.
* Searches for a parent SR policy with color and endpoint
address matching the color extended community attribute and
next hop in a BGP route, and recurses the BGP route to the
parent SR policy.
The Ingress node can match flow characteristics in its ingress
interfaces (upon any field such as Ethernet
Jiang, et al. Expires July, 2024 [Page 4]
Internet-Draft Parent SR Policy January 2024
destination/source/VLAN/TOS or IP destination/source/DSCP or
transport ports or application attribute etc.) and color them
with an internal per-packet forwarding-class variable.
According to the forwarding-class variable the ingress node
selects the matching SR policy in the parent SR policy.
o Policy-based Steering: incoming packets match a routing policy
that directs them on a parent SR policy. Parse the flow
characteristics (such as DSCP/802.1p value) from the packet
header, find its corresponding color, and then match it to an
SR policy in the parent SR policy, forward the incoming packets
through the matched SR policy.
If a parent SR policy has at least one valid constituent SR Policy
of specified color, flow load-balance steer over its valid
constituent SR policies with the same color. When all constituent SR
policies of specified color are invalid, packets are forwarded based
on a default SR policy preconfigured.
5. On-demand Parent SR Policy
SR policies are generally generated by manual static configuration
or distributed by centralized controller. Manual configuration may
be troublesome, especially when many SR policies need to be
configured. The controller mode may also not be suitable for
operators who need to make full use of distributed intelligence.
In scenarios that distinguish service forwarding paths based on DSCP
value and 802.1p priority, parent SR policies can be automatically
created through ODN to establish the dynamic mapping between service
types and parent SR policies, which can greatly reduce the workload
of configuration.
Create the ODN template of parent SR policy in the headend. When the
device receives a BGP route, if the color extended community
attribute carried by the BGP route is the same as the color value of
the ODN template, the next hop address of the BGP route is used as
the destination endpoint address of the parent SR policy, and the
color value of the ODN template is used as the color attribute of
the parent SR policy to generate a parent SR policy.
After the parent SR policy is created by ODN, its constituent SR
policy is usually generated by ODN. ODN SR policy dynamically
generates candidate paths through affinity attributes, flex-algo
algorithm or PCE calculation.
Jiang, et al. Expires July, 2024 [Page 5]
Internet-Draft Parent SR Policy January 2024
6. Parent SR Policy Use Cases
The use cases described in this section do not constitute an
exhaustive list of all the possible scenarios: this section only
includes some of the most common envisioned deployment models for
parent SR policy.
6.1. Parent SR Policy in L3VPN over TE Scenarios
In Figure 1, CE1 and CE2 belong to the same L3VPN and access the
public network through PE1 and PE2 respectively. There are many
kinds of traffic between CE1 and CE2. When the ordinary traffic is
too large, the forwarding of important traffic will be affected.
In order to ensure the forwarding quality of important services, the
steering based on Forwarding class can be configured using parent SR
policy. After the steering based on forwarding class is configured,
the traffic of different service levels will be carried by the
specified SR policy tunnel, which can effectively ensure the
forwarding quality of important services with high service levels.
+----+
+--| P3 |--+
| +----+ |
| |
+-----+ +-----+ +----+ +----+ +-----+ +-----+
| CE1 |---| PE1 |---| P1 |----| P2 |----| PE2 |---| CE2 |
+-----+ +-----+ +----+ +----+ +-----+ +-----+
| |
|<===========================>|
Parent SR Policy
Figure 1
It is assumed that in this network, the parent SR policy contains
three constituent policies: Policy-A, Policy-B and Policy-C.
Services with different forwarding class will carry different DSCP
values in the packet. Identify the customer's service through DSCP
on PE1. The voice traffic of VIP customers is forwarded according to
the path of low-delay Policy-A, other traffic of VIP customers is
forwarded according to the path of Policy-B, and all businesses of
non VIP customers are carried by Policy-C.
Jiang, et al. Expires July, 2024 [Page 6]
Internet-Draft Parent SR Policy January 2024
6.2. Parent SR Policy in Cloud Backbone Acceleration Scenarios
As shown in Figure 2, multiple cloud data centers are interconnected
through cloud backbone networks. In the public cloud, there are
different SLA requirements for different service types, such as
voice service and cloud disk. Deploy a static parent SR policy on
the core of the cloud backbone network to prevent network
congestion. There are multiple SR policies in the parent SR policy.
In order to ensure the service quality of different types of
services, the service types are distinguished by flow
classification, then different services are mapped to different DSCP
value, and finally the traffic of different DSCP is imported into
different SR policies.
...................................
. Backbone .
. +--------+ .
. | Public | .
. +--------| Cloud |-----------+ .
. | +--------+ | .
+--------+ . | | . +--------+
| Public |---+ . | | . +---| Public |
| Cloud | +-+----+ +----+ +----+ +----+-+ | Cloud |
+--------+ | PE |----| P |-----| P |----| PE | +--------+
+-+----+ +----+ +----+ +----+-+
+--------+ | . | | . | +--------+
|Private |---+ . | +----+ | . +---|Private |
| Cloud | . +--| P |--+ . | Cloud |
+--------+ . +----+ . +--------+
. |<------------->| .
. Parent SR Policy .
...................................
Figure 2
Through the parent SR policy, different forwarding paths can be
introduced based on the DSCP value in the IP/IPv6 packet header.
First, create a parent SR policy and assign color identification to
the parent SR policy.
Then, configure multiple SR policies into one parent SR policy in
the headend, specify the mapping relationship between each SR policy
and DSCP value in the parent SR policy, and then bind the service
type to the specified parent SR policy.
In this way, when the headend receives traffic, it first matches to
the parent SR policy according to the next hop and color of the
route, and then finds the mapped SR policy in the corresponding
Jiang, et al. Expires July, 2024 [Page 7]
Internet-Draft Parent SR Policy January 2024
group according to the DSCP value carried in the IP/IPv6 packet
header.
DSCP based steering is suitable for differentiating services at the
source and specifying different DSCP value scenarios.
6.3. Parent SR Policy in the L2VPN Network Scenarios
Similar to the DSCP-based steering scenario, in the layer 2 access
network and L2VPN network, the service types are distinguished by
the 802.1p priority in the packet header, and the 802.1p priority is
mapped to color in the parent SR policy. Different services can be
forwarded into different paths.
+----+
+---| P1 |---+
| +----+ |
+-----+ +-----+ | | +-----+ +-----+
| CE1 |---| PE1 |---| |---| PE2 |---| CE2 |
+-----+ +-----+ | | +-----+ +-----+
| +----+ |
+---| P2 |---+
| +----+ |
|<========================>|
Parent SR Policy
Figure 3
As shown in Figure 3, CE1 and CE2 belong to the same VPLS and are
connected to the MPLS backbone network through PE1 and PE2
respectively. Establish two MPLS-SR policy tunnels Policy-A and
Policy-B between PE1 and PE2 to carry this VPLS service. Policy-A
and Policy-B are the constituent policies of parent SR policy. Two
SR policy tunnels correspond to two different priorities. The VPLS
access end classifies the traffic flow, trusts the priority of
802.1p, and introduces the services of VPLS leased line users and
non-leased line users into different SR policy according to
different priorities.
6.4. Parent SR Policy in the Application-aware Scenarios
By carrying the application attribute (including APP ID and APP
parameters) through data packets, i.e., the delivery of application-
aware information and ensuring the security and reliability of
application-aware information, the network senses the application
groups' requirements and provides high-quality differentiated
services according to the demand of the applications. And when the
network transmits the data packets, it matches the SR policy
according to the application attribute in the data packets and
selects the corresponding path of constituent SRv6 policy to
Jiang, et al. Expires July, 2024 [Page 8]
Internet-Draft Parent SR Policy January 2024
transmit the data packets (e.g., low latency path) to meet the SLA
requirements and service chain in order to improve the service
quality.
As shown in Figure 4 below, the parent policy contains three
constituent SR policies: Policy-A, Policy-B and Policy-C. The data
packets of APP1 are forwarded by Policy-A, the data packets of APP2
are forwarded by Policy-B, and the data packets of APP3 are
forwarded by Policy-C.
+------+ +-----------+ +------+
| APP1 | /=====| Policy-A |=====\ | APP1 |
+------+ / +-----------+ \ +------+
+------+ +-------+ +-----------+ +--------+ +------+
| APP2 |---| PE |====| Policy-B |===| PE |---| APP2 |
+------+ +-------+ +-----------+ +--------+ +------+
+------+ \ +-----------+ / +------+
| APP3 | \=====| Policy-C |=====/ | APP3 |
+------+ +-----------+ +------+
|<---------------------------->|
Parent SR Policy
Figure 4
6.5. Application of ODN Parent SR Policy in Trusted Network Scenarios
Section 3 of [I-D.lin-opsec-trustroute-problem-statement] introduces
the use case of trusted network. By dynamically creating SR policy
through ODN, automatic steering traffic according to security level
can be realized.
From the perspective of security and trustworthiness, the security
levels for users with different security requirements and the
trustworthiness levels of the network transmission devices can be
determined according to their performance and reliability. Different
forwarding paths are provided for packets with different security
levels.
Jiang, et al. Expires July, 2024 [Page 9]
Internet-Draft Parent SR Policy January 2024
----------
/ \
| APP Server |
\ /
----------
|
|
+----------+
| |
+----------------| Device-E |---------------+ =====
| | | | ^ P
| +----------+ | | a
| Trustworthiness level =7 | | r
| | | | e
| | | | n
+----------+ +----------+ +----------+ | t
| | | | | | |
| Device-B | | Device-C | | Device-D | | S
| | | | | | | R
+----------+ +----------+ +----------+ |
Trustworthiness level =1 | Trustworthiness level =3 | P
| Trustworthiness level =3 | | o
| | | | l
| | | | i
| +----------+ | | c
+----------------| |---------------+ V y
| Device-A | =====
+---------------| |---------------+
| +----------+ |
| Trustworthiness level =7 |
| | |
| | |
+----------+ +----------+ +----------+
| User-1 | | User-2 | | User-3 |
+----------+ +----------+ +----------+
security level =1 security level =2 security level =3
Figure 5
As shown in Figure 5, the trustworthiness level is configured on
each network transmission device.
Device-E colors the advertised BGP routes through the color extended
community attribute, and different services correspond to different
colors.
Jiang, et al. Expires July, 2024 [Page 10]
Internet-Draft Parent SR Policy January 2024
When Device-A receives a BGP route with color C1 and endpoint E,
device a will automatically generate a parent SR policy (C1, E)
according to the ODN template of color C1.
The composition SR policy of parent SR policy is also generated
according to ODN template. DSCP1 is mapped to color C2. After
creating a parent SR policy (C1, E), Device-A generates an ODN SR
policy (C2, E) according to the mapping relationship between DSCP
and color (DSCP1->C2).
Services with different security levels use different DSCPs. When
the user generates a service packet, it carries the corresponding
DSCP value (DSCP1) on the IPv6 packet header, and sends it to the
Device-A. After receiving the service packet, the service packet is
steered according to SR policy (C2, E).
6.6. Best-effort Forwarding Scenarios when SR Policy Becomes
Unavailable
When all the constituent SR policies in the parent SR policy are not
valid, or all the selected paths of the SR policy are unavailable,
the service traffic will not be forwarded according to the specified
path. At this time, the best-effort forwarding path can be
configured for the parent SR policy, and the endpoints through which
traffic forwarding must pass can be designed in the best-effort
forwarding path.
During network deployment, the best-effort forwarding path can be a
default SR policy or an SR BE forwarding path. Specify a best-effort
forwarding path in the parent SR policy. When all specified
candidate paths are invalid, or the mapping relationship
corresponding to their service type is not matched in the parent SR
policy, select the default best-effort path forwarding.
7. Implementation Status
In November 2021, by configuring the parent SR policy defined in
this document, China Mobile has successfully verified the composite
candidate path that acts as a container for grouping SR Policies on
the device and controller.
Hardware implementation in H3C CR16010H-FA and CR19000-8 running
Comware
China mobile IP Network Controller
Jiang, et al. Expires July, 2024 [Page 11]
Internet-Draft Parent SR Policy January 2024
8. IANA Considerations
This document has no IANA actions.
9. Security Considerations
This document presents use cases to be considered by the deployment
of SR Policy. It does not introduce any security considerations.
10. References
10.1. Normative References
[I-D.ietf-idr-segment-routing-te-policy] Previdi, S., Filsfils, C.,
Talaulikar, K., Mattes, P., Rosen, E., Jain, D., and S.
Lin, "Advertising Segment Routing Policies in BGP", draft-
ietf-idr-segment-routing-te-policy-26 (work in progress),
October 2023.
[I-D.lin-opsec-trustroute-problem-statement] Lin, T., Li, H., Shi,
X., Yin, X., Chen, W., "Problem Statement and Use Cases of
Trustworthiness-based Routing", draft-lin-opsec-
trustroute-problem-statement-03 (work in progress), July
2023.
[RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L.,
Decraene, B., Litkowski, S., and R. Shakir, "Segment
Routing Architecture", RFC 8402, DOI 10.17487/RFC8402,
July 2018, <https://www.rfc-editor.org/info/rfc8402>.
[RFC9256] Filsfils, C., Talaulikar, K., Voyer, D., Bogdanov, A., and
Mattes, P., "Segment Routing Policy Architecture", RFC
8402, DOI 10.17487/RFC9256, July 2022, <https://www.rfc-
editor.org/info/rfc9256>.
10.2. Informative References
TBD
11. Acknowledgments
The authors would like to thank the following for their valuable
contributions of this document:
TBD
Jiang, et al. Expires July, 2024 [Page 12]
Internet-Draft Parent SR Policy January 2024
Authors' Addresses
Wenying Jiang
China Mobile
Email: jiangwenying@chinamobile.com
Weiqiang Cheng
China Mobile
Email: chengweiqiang@chinamobile.com
Changwang Lin
New H3C Technologies
Email: linchangwang.04414@h3c.com
Yuanxiang Qiu
New H3C Technologies
Email: qiuyuanxiang@h3c.com
Jiang, et al. Expires July, 2024 [Page 13]
