Use Cases for Parent SR Policy
draft-jiang-spring-parent-sr-policy-use-cases-00
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Active".
|
|
|---|---|---|---|
| Authors | Jiang Wenying , Weiqiang Cheng , Changwang Lin , Yuanxiang Qiu | ||
| Last updated | 2022-07-09 | ||
| RFC stream | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-jiang-spring-parent-sr-policy-use-cases-00
SPRING Working Group W. Jiang
Internet Draft W. Cheng
Intended status: Standards Track China Mobile
Expires: January 10, 2023 C. Lin
Y. Qiu
New H3C Technologies
July 9, 2022
Use Cases for Parent SR Policy
draft-jiang-spring-parent-sr-policy-use-cases-00
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 January 10 2023.
Copyright Notice
Copyright (c) 2022 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 January, 2023 [Page 1]
Internet-Draft Parent SR Policy July 2022
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 an parent SR Policy ........................... 4
5. On-demand parent SR Policy .................................. 5
6. Parent SR Policy Use Cases .................................. 5
6.1. Parent SR Policy in L3VPN over TE Scenarios ............. 6
6.2. Parent SR Policy in Cloud Backbone Acceleration Scenarios 6
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 ........................................ 11
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 [I-D.ietf-
spring-segment-routing-policy]. 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 January, 2023 [Page 2]
Internet-Draft Parent SR Policy July 2022
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 [I-D.ietf-spring-segment-
routing-policy], 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 [I-D.ietf-
spring-segment-routing-policy], 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 [I-D.ietf-
spring-segment-routing-policy]，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 [I-D.ietf-spring-segment-routing-policy]，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.
As defined in [I-D.ietf-spring-segment-routing-policy], the
endpoints of the constituent SR Policies and the parent SR Policy
Jiang, et al. Expires January, 2023 [Page 3]
Internet-Draft Parent SR Policy July 2022
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:
The endpoints of the constituent SR Policies and its parent SR
Policy MUST be identical
The colors of each of the constituent SR Policies and its parent
SR Policy MUST be different
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 an 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 parent policy 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
destination/source/VLAN/TOS or IP destination/source/DSCP or
transport ports or application attribute etc.) and color them with
Jiang, et al. Expires January, 2023 [Page 4]
Internet-Draft Parent SR Policy July 2022
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 an 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.
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
Jiang, et al. Expires January, 2023 [Page 5]
Internet-Draft Parent SR Policy July 2022
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 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.
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
Jiang, et al. Expires January, 2023 [Page 6]
Internet-Draft Parent SR Policy July 2022
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
parent policy according to the DSCP value carried in the IP/IPv6
packet header.
Jiang, et al. Expires January, 2023 [Page 7]
Internet-Draft Parent SR Policy July 2022
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 SR policy to transmit
the data packets (e.g., low latency path) to meet the SLA
Jiang, et al. Expires January, 2023 [Page 8]
Internet-Draft Parent SR Policy July 2022
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 January, 2023 [Page 9]
Internet-Draft Parent SR Policy July 2022
----------
/ \
| APP Server |
\ /
----------
|
|
+----------+
| |
+----------------| Device-E |---------------+ =====
| | | | ^ P
| +----------+ | | a
| Trustworthiness level =7 | | r
| | | | e
| | | | n
| | | | t
+----------+ +----------+ +----------+ |
| | | | | | | S
| Device-B | | Device-C | | Device-D | | R
| | | | | | |
+----------+ +----------+ +----------+ | P
Trustworthiness level =1 | Trustworthiness level =3 | o
| Trustworthiness level =3 | | 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.
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.
Jiang, et al. Expires January, 2023 [Page 10]
Internet-Draft Parent SR Policy July 2022
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
8. IANA Considerations
This document has no IANA actions.
Jiang, et al. Expires January, 2023 [Page 11]
Internet-Draft Parent SR Policy July 2022
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-spring-segment-routing-policy] Filsfils, C., Talaulikar,
K., Voyer, D., Bogdanov, A., and P. Mattes, "Segment
Routing Policy Architecture", draft-ietf-spring-segment-
routing-policy-22 (work in progress), March 2022.
[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-18 (work in progress),
June 2022.
[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-02 (work in progress), June
2022.
[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>.
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 January, 2023 [Page 12]
Internet-Draft Parent SR Policy July 2022
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 January, 2023 [Page 13]