Internet DRAFT - draft-shi-cats-ipv6-based-con
draft-shi-cats-ipv6-based-con
Computing-Aware Traffic Steering H. Shi
Internet-Draft C. Li
Intended status: Informational Z. Li
Expires: 7 March 2024 Huawei Technologies
4 September 2023
IPv6-based Cloud-Oriented Networking
draft-shi-cats-ipv6-based-con-01
Abstract
This document describes the scenarios, requirements and technologies
for IPv6-based Cloud-oriented Networking.
Discussion Venues
This note is to be removed before publishing as an RFC.
Discussion of this document takes place on the Computing-Aware
Traffic Steering Working Group mailing list (cats@ietf.org), which is
archived at https://mailarchive.ietf.org/arch/browse/cats/.
Source for this draft and an issue tracker can be found at
https://github.com/VMatrix1900/draft-cats-ipv6-based-con.
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 7 March 2024.
Copyright Notice
Copyright (c) 2023 IETF Trust and the persons identified as the
document authors. All rights reserved.
Shi, et al. Expires 7 March 2024 [Page 1]
Internet-Draft IPv6 based CON September 2023
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 . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Requirements Language . . . . . . . . . . . . . . . . . . 4
3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Underlay . . . . . . . . . . . . . . . . . . . . . . . . 5
3.2. Overlay . . . . . . . . . . . . . . . . . . . . . . . . . 6
4. IPv6-based Cloud-Oriented Networking . . . . . . . . . . . . 7
4.1. Requirements . . . . . . . . . . . . . . . . . . . . . . 7
4.1.1. Quick Connection . . . . . . . . . . . . . . . . . . 7
4.1.2. Hybrid Network Connection . . . . . . . . . . . . . . 7
4.1.3. Path Programming . . . . . . . . . . . . . . . . . . 8
4.1.4. Resource Assurance . . . . . . . . . . . . . . . . . 8
4.1.5. Deterministic Delay . . . . . . . . . . . . . . . . . 8
4.1.6. Service Function Chaining . . . . . . . . . . . . . . 9
4.1.7. Performance Measurement . . . . . . . . . . . . . . . 9
4.1.8. Reliability . . . . . . . . . . . . . . . . . . . . . 9
4.1.9. Security . . . . . . . . . . . . . . . . . . . . . . 9
4.1.10. Forwarding Efficiency . . . . . . . . . . . . . . . . 10
4.1.11. Application-Aware Networking . . . . . . . . . . . . 10
4.2. Solutions . . . . . . . . . . . . . . . . . . . . . . . . 10
4.2.1. VPN . . . . . . . . . . . . . . . . . . . . . . . . . 11
4.2.2. Path Programming . . . . . . . . . . . . . . . . . . 11
4.2.3. Service Function Chaining . . . . . . . . . . . . . . 11
4.2.4. IPv6 based Network Slicing . . . . . . . . . . . . . 12
4.2.5. IPv6-based On-path Measurement . . . . . . . . . . . 12
4.2.6. Reliability . . . . . . . . . . . . . . . . . . . . . 13
4.2.7. Security . . . . . . . . . . . . . . . . . . . . . . 14
4.2.8. IPv6 Forwarding Efficiency . . . . . . . . . . . . . 15
4.2.9. Application-aware IPv6 Networking . . . . . . . . . . 15
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
6. Security Considerations . . . . . . . . . . . . . . . . . . . 16
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 16
7.1. Normative References . . . . . . . . . . . . . . . . . . 16
7.2. Informative References . . . . . . . . . . . . . . . . . 16
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 22
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 22
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22
Shi, et al. Expires 7 March 2024 [Page 2]
Internet-Draft IPv6 based CON September 2023
1. Introduction
With the development of cloud computing, increasing services have
been migrated from enterprises to cloud data centers. Compared with
interconnections between branches and headquarters, new connections
between enterprise sites to cloud data centers and inter-cloud are
added, which bring new requirements and challenges for existing
networks.
When enterprises have workloads & applications & data split among
different data centers, especially for those enterprises with
multiple sites that are already interconnected by VPNs (e.g., MPLS
L2VPN/L3VPN), challenges are introduced.
[I-D.ietf-rtgwg-net2cloud-problem-statement] describes the problems
that enterprises face today when interconnecting their branch offices
with dynamic workloads in third party data centers (a.k.a. Cloud
DCs).
SD-WAN is a flexible WAN architecture that enables flexible network-
to-cloud and inter-clouds connections. It supports to use
alternative paths like internet or 4G / 5G connection instead of
expensive MPLS leased lines to exchange data between sites and
clouds. However, when a WAN path travels multiple MPLS domains, the
configurations are complicated due to multiple services touch points
need to be configured. Therefore, it is hard to support end-to-end
path programming in IPv4/MPLS based SD-WAN.
When using VXLAN in SD-WAN, only the overlay path or anchor points
can be specified while the underlay forwarding path can not be
specified. Therefore, strict TE requirements like deterministic
delay, specified path forwarding can not be satisfied.
In order to resolve these challenges, this document propose
IPv6-based Cloud-Oriented Networking (CON). In addition, it
describes the challenges for existing networks when clouds and
networks are converged, requirements that IPv6-based CON should
satisfy, and the solutions in IPv6-based CON that satisfy the
requirements.
IPv6-based CON supports quick and flexible connections between sites
and clouds and inter-clouds, it also supports end-to-end path
programming, which can be used for many use cases, such as strict
path traffic engineering, deterministic delay forwarding, and service
function chaining, to provide better network services for cloud-
network and inter-cloud interconnections.
Shi, et al. Expires 7 March 2024 [Page 3]
Internet-Draft IPv6 based CON September 2023
2. Terminology
This document makes use of the terms defined in [RFC8754] and
[RFC8200], and the reader is assumed to be familiar with that
terminology. This document introduces the following terms:
POP: Point of Presence
CON: Cloud-Oriented Networking.
EC: Edge Computing.
EDC: Edge Data center
RDC: Regional Data Center
CDC: Core Data Center
2.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
3. Problem Statement
As development of cloud, many clouds have been deployed, such as
Private cloud, Public Cloud, and Hybrid Cloud. The cloud services
can be provided by a third party, such as an OTT (Over-The-Top)
content provider, and it can be provided by a network operator as
well. Furthermore, cloud can be deployed not only in IT data centers
but also CT data centers.
With the development and successful application of cloud native
design in the IT field and Network Functions Virtualization (NFV)
technologies, virtualization and cloudification have gradually
matured and evolved to provide a new level of productivity, offering
a new approach to telecom network construction. Building cloud-based
telecom networks (also known as telco clouds) becomes a new way of
telecom network construction.
In order to support low latency communication, the request should be
responded at the near cloud data center, therefore edge computing
data center (a.k.a Edge Cloud) is introduced. Telecommunication
services and third-party OTT services can be deployed in the edge
cloud.
Shi, et al. Expires 7 March 2024 [Page 4]
Internet-Draft IPv6 based CON September 2023
As the deployment of clouds, the traffic pattern in the network has
changed significantly, which results in new challenges for existing
networks.
3.1. Underlay
From the aspect of underlay, cloud services requires the network to
provide quick and flexible connection.
The typical topology of telco cloud is shown in figure 1.
+++++++ +++++++ ++++++
| EDC | | RDC | | CDC|
+++++++ +++++++ ++++++
| ********* | ************ |
| * * | * * |
OLT/CSG/CPE---PE--* Metro *--PE--* Backbone *--PE--IGW---Internet
* * * *
********* ************
Figure 1.Typical topology of telco cloud
The edge cloud is deployed in edge data center (EDC) in the access
network usually, so that the servers in the edge cloud can respond to
the delay-sensitive requests rapidly, like 5G URLLC traffic. The
traffic is not delay-sensitive can be responded in regional cloud DC,
which is located in the metro or core network. Most cloud services
may be deployed in the core cloud DC considering reducing the cost,
which is far from the end user. Like, the UPF may locate in the
regional cloud DC or Core cloud DC, so that it can support more
users.
The traffic from end users to cloud servers are forwarded along with
different paths due to the different locations of the end users and
the cloud servers.
In addition, when deploying new services, for instance, deploying a
leased line from an enterprise site to a cloud data center, it will
take probably weeks in the current IPv4/MPLS carrier network.
Because the VPN configuration is needed to be done at multiple PE
nodes if the leased line travels multiple domains (when using Option
A between domains). Also, the cloud operator needs to negotiate with
network operators if the cloud services and the network services are
provided by different operators. For example, thousands of chain
stores such as grocery stores or super markets are needed to connect
to their enterprise VPNs, and they may use the cloud services.
However, in IPv4/MPLS network, it may take weeks to establish a new
VPN connection from a site to headquarter or cloud tenant networks.
Shi, et al. Expires 7 March 2024 [Page 5]
Internet-Draft IPv6 based CON September 2023
Furthermore, different traffic of different enterprise/tenant/users
are treated differently in clouds, and they MAY be forwarded along
with different service function chains (SFC). However, it is hard to
support SFC in IPv4 or MPLS based network in carrier's networks or
data center networks. Normally, to support SFC, the traffic steering
policies are configured at multiple nodes along the SFC path, which
is complicated.
3.2. Overlay
In order to provide quick and flexible cloud connection, overlay
connection is provided by cloud providers, especially the OTT cloud
providers.
SD-WAN is a typical fabric for DCI connection between clouds and
sites, which provides a cheaper and smarter WAN connection. Many SD-
WAN providers builds their own WAN backbone network by connecting
their POP GWs to provide better SLA assurance for tenants. The
typical topology of SD-WAN with POP GWs is shown in figure 2.
Site CPE1--POP GW1 --------------------------POP GW2---Site CPE2
| |
| SD-WAN Backbone |
| |
Cloud1---POP GW3---------------------------POP GW4--Cloud2
Figure 2. Typical topology of SD-WAN
Currently, the traffic from the CPE to POP GW is forwarded through
the shortest forwarding path over the Internet, or an MPLS tunnel.
In addition, traffic from POP GW to another POP GW can be forwarded
along with the MPLS tunnel that is a leased line, or over the
internet, depending on the forwarding policies.
When the traffic is forwarded over the internet, it can be forwarded
over a VXLAN tunnel. However, when using VXLAN, only the overlay
connection is provided to enterprises/tenants, while the underlay
forwarding path can not be specified and programmed. Therefore the
SLA requirements can not be guaranteed when the traffic is forwarded
overlay.
Shi, et al. Expires 7 March 2024 [Page 6]
Internet-Draft IPv6 based CON September 2023
4. IPv6-based Cloud-Oriented Networking
This document describes a networking architecture called IPv6-based
Cloud-Oriented Networking (CON). IPv6-based CON is an IPv6-based
networking which provide quick, flexible connection to support
dynamic site to cloud, and inter-cloud connections. Also, it
supports end-to-end underlay forwarding path programming, so that
services like strict path TE and SFC can be supported better.
The following section describes the requirements in IPv6-based CON,
and the related solutions that meet the requirements.
4.1. Requirements
This section describes the overall requirements which need to be
fulfilled by IPv6-based Cloud-Oriented Networking.
4.1.1. Quick Connection
Enterprise sites can locate at any location around the world, they
need to connect to the clouds or other sites in any time, from any
where. Also, enterprises may have some Virtual Private Clouds (VPC)
in different clouds, they need to connect to each other in real time
as well. The servers may locate in different cloud data centers or
enterprise sites, which provide services for employees or other
users. Therefore quick connection is required in IPv6-based CON.
4.1.2. Hybrid Network Connection
The enterprise VPN traffic can be forwarded around the world, which
may travel heterogeneous networks, such as IPv4, MPLS and IPv6.
Typically, when a SD-WAN network connects multiple sites and clouds,
it may cover hybrid networks. For example, the sub-path from the CPE
to POP WG could be an IPv4 sub-path without any resource guarantee.
The sub-path between POP GWs could be an MPLS LSP with resource
reservation.
Therefore, connection over hybrid networks MUST be supported in
IPv6-based CON.
Shi, et al. Expires 7 March 2024 [Page 7]
Internet-Draft IPv6 based CON September 2023
4.1.3. Path Programming
When the enterprise VPN traffic is forwarded among sites or clouds,
it may be forwarded along different paths. Each path has different
performance such as different bandwidth, delay, etc. For instance,
path A is the shortest path from site 1 to cloud 1, which has the
lowest delay, while the path B can provide more bandwidth than path
A. Therefore, the delay-sensitive traffic like PC gaming traffic
SHOULD be forwarded along with path A, and the traffic that is delay-
insensitive but requiring large bandwidth SHOULD be forwarded along
with path B.
In order to meet the different SLA requirements, IPv6-based CON MUST
support path programming.
4.1.4. Resource Assurance
In RSVP-TE MPLS, resources like bandwidth can be reserved for an LSP.
When the traffic is forwarded along the LSP, the bandwidth can be
guaranteed, which makes sure that the traffic will not be affected by
other traffic. In order to provide SLA guaranteed services,
IPv6-based CON MUST support Resource Assurance.
Network slicing is an approach to provide separate and independent
end-to-end logical network over the physical network infrastructure.
Each Network Slicing has its own resources, which can meet the
specific SLA requirements. In order to provide SLA guaranteed
services, IPv6-based CON MUST support network slicing.
4.1.5. Deterministic Delay
Delay-sensitive traffic has the strict requirements of network delay.
Especially, when the servers moved to clouds instead of locating
locally within the enterprise site, the long physical distance of
packet forwarding path will introduce larger delay. In the
traditional network, the shortest forwarding path is calculated based
on the metric, and the metric is usually associated to the physical
hops instead of latency. However, minimum delay forwarding is
required for delay-sensitive traffic, like real-time video broadcast
and video meeting.
Therefore, IPv6-based CON MUST have the capability to support path
computing based on delay. Also, it MUST be able to provide
deterministic delay forwarding.
Shi, et al. Expires 7 March 2024 [Page 8]
Internet-Draft IPv6 based CON September 2023
4.1.6. Service Function Chaining
Service Function Chaining [RFC7665] is a mechanism to provide
different value-added services (VAS) for packets.
A service function chain defines an ordered set of abstract service
functions and ordering constraints that must be applied to packets
and/or frames and/or flows selected as a result of classification
[RFC7665].
An example of an abstract service function is "a firewall".
Typically, different tenant's traffic in cloud data center will
traverse different services function chain containing Firewall, DPI
or other VAS.
Therefore, IPv6-based CON MUST have the capability to support SFC.
4.1.7. Performance Measurement
Many OAM mechanisms are used to support network operation.
Performance Measurement (PM) is one of the most important part of
OAM. With PM, the real-time QoS of the forwarding path, like delay,
packet loss ratio and throughput, can be measured.
PM can be implemented in one of three ways: active, passive, or
hybrid [RFC7799], differing in whether OAM packets need to be
proactively sent.
On-path telemetry [I-D.song-opsawg-ifit-framework] is an hybrid mode
OAM/PM mechanism, which provides better accuracy than active PM.
Therefore, on-path Performance Measurement MUST be supported in
IPv6-based CON.
4.1.8. Reliability
In Cloud-Network Interconnection scenarios, the enterprise traffic is
forwarded over the WAN paths. The traffic can be sensitive to delay
or packet losing, so high reliability is required in these scenarios.
Therefore, protection of node and links MUST be supported in
IPv6-based CON. Furthermore, redundancy transmission SHOULD be
supported.
4.1.9. Security
As mentioned above, the enterprise traffic is forwarded over the WAN
paths in IPv6-based CON. The security of the traffic MUST be
ensured.
Shi, et al. Expires 7 March 2024 [Page 9]
Internet-Draft IPv6 based CON September 2023
Also, in SD-WAN scenarios, customers are most concerned about
security.
Therefore, IPv6-based CON MUST support secure connection, and MUST
provide security assurance for the traffic in transmission.
4.1.10. Forwarding Efficiency
Tenants/Customers rent the physical or logical WAN links/paths from
network operators for building they cloud-network interconnection
enterprise network, so the forwarding efficiency is important for the
WAN path tenant.
Path Maximum Transmission Unit indicates the maximum size of a packet
that it can be forwarded along a path. Setting an appropriate PMTU
for packets can avoid fragmentation or dropping, so that the
forwarding efficiency can be raised.
Also, the overhead of packets MUST be added very carefully since it
affects the forwarding efficiency directly. Especially, when many
SIDs are inserted in an SRv6 packet, the overhead of the SID list is
too large. [I-D.srcompdt-spring-compression-requirement] describes
the requirements of SRv6 compression.
Therefore, the IPv6-based CON MUST support PMTU probing and
configuration. In addition, it MUST support SRv6 compression.
4.1.11. Application-Aware Networking
Network operators are typically unaware of which applications are
traversing their networks, which is because the network layer is
decoupled from application layer. Adding application knowledge to
the network layer enables finer granularity requirements of
applications to be specified to the network operator. As IPv6 is
being widely deployed, the programmability provided by IPv6
encapsulations can be augmented by conveying application information.
In IPv6-based CON, many types of applications' traffic is exchanged
between sites and clouds. They have various requirements of QoS, and
should be treated differently. In order to provide finer granularity
traffic engineering to reduce the cost of WAN services, application-
aware networking SHOULD be supported in IPv6-based CON.
4.2. Solutions
This section describes the candidate solutions that meet the
requirements in IPv6-based CON.
Shi, et al. Expires 7 March 2024 [Page 10]
Internet-Draft IPv6 based CON September 2023
4.2.1. VPN
VPN is a basic and essential services for cloud-networks
interconnections.
SRv6 supports VPN by encoding the VPN information into the VPN SID
[RFC8986].
Based on IPv6, SRv6 VPN can be established across multiple domains.
It avoids configuring VPN services at each boundary nodes at each
domain like the way in IPv4/MPLS networks (Option A). Deploying VPN
based on SRv6 can shorten the duration significantly.
Also, L2VPN and L3VPN can be supported uniformly based on EVPN
control plane [RFC9252]. Therefore, combining the SRv6 data plane
and EVPN control plane, the VPN can be deployed in an easy and
flexible way in IPv6-based CON.
4.2.2. Path Programming
Based on SRv6, the traffic forwarding path can be programmed at the
ingress of the SRv6 domain, so that the traffic from sites to clouds
or inter-cloud can be forwarded through the specific underlay path.
For instance, in SD-WAN scenarios, the POP GW can choose a specific
underlay forwarding path in WAN by choosing a binding SID
[I-D.dukes-spring-sr-for-sdwan]. If the CPE supports SRv6, a
controller can convey the programmed path information to the CPE via
BGP SRv6 policy [I-D.ietf-idr-segment-routing-te-policy] or PCEP SRv6
policy [I-D.ietf-pce-segment-routing-policy-cp].
If the WAN connection travels multiple domains, the WAN path can be
connected by multiple tunnels, such as VXLAN, GRE tunnel.
[I-D.dunbar-sr-sdwan-over-hybrid-networks] describes how to
associated the tunnels.
In order to shorten the delay, a CPE or PE can choose the nearest
server in a specific cloud, and forward the packets through
programmed paths.
4.2.3. Service Function Chaining
SFC is required in IPv6-based CON since different tenants subscribe
different value-added services.
Shi, et al. Expires 7 March 2024 [Page 11]
Internet-Draft IPv6 based CON September 2023
[I-D.ietf-spring-sr-service-programming] defines the mechanism to
support SFC in SRv6. Each service function (SF) can be represented
as an SRv6 SID if it supports SRv6. If the SF is SRv6-unaware
device, then proxy SID is used. By programming service SIDs into the
SRH, the SFC can be supported in SRv6.
Thanks to IPv6 reachability, SRv6 supports to program the end-to-end
forwarding path from the carrier network to the inside the cloud data
center, even to multiple clouds.
If NSH-based SFC has been deployed, a transition solution should be
considered, and [I-D.ietf-spring-nsh-sr] describes a NSH and SR
integration SFC solution.
4.2.4. IPv6 based Network Slicing
The tenant traffic MUST be isolated in WAN to avoid affecting by
other internet traffic.
A framework, Enhanced VPN (VPN+), to form an enhanced connectivity
services between customer sites is defined as per
[I-D.ietf-teas-enhanced-vpn]. Typically, VPN+ will be used to form
the underpinning of network slicing. It also defines Virtual
Transport Network (VTN). A VTN is a virtual underlay network that
connects customer edge points with the capability of providing the
isolation and performance characteristics required by an enhanced VPN
customer. A VTN usually has a customized topology and a set of
dedicated or shared network resources [I-D.ietf-teas-enhanced-vpn].
A VTN-ID option in IPv6 HBH header is defined in
[I-D.dong-6man-enhanced-vpn-vtn-id] to identify the Virtual Transport
Network (VTN) the packet belongs to. A VTN can be used as the
underlay for one or a group of VPNs to provide enhanced VPN (VPN+)
services.
By using VTN-ID, an end-to-end IPv6 network slicing is identified in
transport network. Tenant traffic in WAN can be forwarded in the VTN
with guaranteed resource.
4.2.5. IPv6-based On-path Measurement
The extension of supporting Alternate Marking Method [RFC9341] in
IPv6 is defined in [RFC9343]. It describes how the Alternate Marking
Method to be used as the hybrid performance measurement tool in an
IPv6 domain by defining a new Extension Header Option.
Shi, et al. Expires 7 March 2024 [Page 12]
Internet-Draft IPv6 based CON September 2023
Alternate Marking Method is a hybrid on-path performance measurement
method, and the metadata of each node can be collected by the
collector to compute the performance of the path.
IOAM is another on-path measurement method.
[I-D.ietf-ippm-ioam-ipv6-options] defines a new IPv6 option, called
IOAM option to support carrying IOAM metadata in the IPv6 data
packet. However, carrying all the metadata in the data packet will
bring challenges for hardware processing. For instance, long-length
metadata may cause recircle in processing. Therefore, [RFC9326]
defines a direct export option in IOAM, which enables the nodes to
export the metadata to collector directly. Furthermore,
[I-D.song-opsawg-ifit-framework] outlines a high-level framework to
provide an operational environment that utilizes existing and
emerging on-path telemetry techniques to enable the collection and
correlation of performance information from the network.
4.2.6. Reliability
4.2.6.1. Local Protection
Local protection mechanisms like Fast Reroute (FRR) provide 50 ms
protection on nodes for traffic.
Regarding link failures, TI-LFA
[I-D.ietf-rtgwg-segment-routing-ti-lfa] provides a fast reroute
mechanism by sending the traffic to an expected post-convergence
paths from the point of local repair.
Regarding the middle endpoint node failures,
[I-D.hu-spring-segment-routing-proxy-forwarding] defines a mechanism
for fast reroute protection against the failure of a SR-TE path. It
can provide fast reroute protection for an adjacency segment, a node
segment and a binding segment of the path. Also,
[I-D.chen-rtgwg-srv6-midpoint-protection] defines midpoint
protection, which enables the direct neighbor of the failed endpoint
to perform the function of the endpoint, replace the IPv6 destination
address to the next endpoint, and choose the next hop based on the
new destination address.
Regarding the egress node failures,
[I-D.ietf-rtgwg-srv6-egress-protection] defines a local protection
solution using the mirror SID.
Shi, et al. Expires 7 March 2024 [Page 13]
Internet-Draft IPv6 based CON September 2023
4.2.6.2. End-to-End Protection
End-to-End Protection is also required in IPv6-based CON. Normally,
host-standby nodes are deployed for supporting traffic switching from
the failed node to the alternative node. In order to detect the
failure, End-to-end BFD is required. Once the BFD session is failed,
the traffic can be steered into a disjoint forwarding path, and the
traffic will be forwarded to the host-standby node.
4.2.6.3. Redundancy Protection
In order to avoid losing packets,
[I-D.geng-spring-sr-redundancy-protection] defines a redundancy
transmission solution.
The document defines two types of segment including Redundancy
Segment and Merging Segment to empower the Segment Routing with the
capability of redundancy protection.
4.2.7. Security
As per [I-D.li-spring-srv6-security-consideration], SRv6 inherits
potential security vulnerabilities from Source Routing and IPv6, but
it does not introduce new critical security threats.
Regarding a limited domain, SPRING architecture [RFC8402] defines
clear trusted domain boundaries so that source-routing information is
only available within the trusted domain and never exposed to the
outside of the domain. It is expected that, by default, explicit
routing is only used within the boundaries of the administered
domain. Therefore, the data plane does not expose any source-routing
information when a packet leaves the trusted domain. The traffic is
filtered at the domain boundaries [RFC8402].
However, it has been noted that the AH and ESP are not directly
applicable in order to reduce the vulnerabilities of SRv6 due to the
presence of mutable fields in the SRH
[I-D.li-spring-srv6-security-consideration]. In order to resolve
this problem, [RFC8754] defines a mechanism to carry HMAC TLV in the
SRH to verify the integrity of packets including the SRH fields.
Regarding end-to-end security protection across multiple domains, an
end-to-end IPSec tunnel is suggested to be deployed.
In typical SD-WAN scenarios, the IPSec tunnel should be used between
the CPE and POP GW.
Shi, et al. Expires 7 March 2024 [Page 14]
Internet-Draft IPv6 based CON September 2023
4.2.8. IPv6 Forwarding Efficiency
4.2.8.1. PMTU
The host may discover the PMTU by Path MTU Discovery (PMTUD)
[RFC8201] or other means. But the ingress node still needs to
examine the packet size to drop too large packets to avoid malicious
packets or error packets attack. Also, the packet size may exceed
the PMTU because of the new encapsulation of SR-MPLS or SRv6 at the
ingress. In order to check whether the packet size exceeds the PMTU
or not, the ingress node need to know the Path MTU associated to the
forwarding path.
However, the path maximum transmission unit (MTU) information for SR
path is not available since the SR does not require signaling.
[I-D.ietf-idr-bgp-ls-link-mtu] proposes a BGP-LS extensions to
collect the link MTU of the links in the networks.
[I-D.ietf-idr-sr-policy-path-mtu] and [I-D.li-pce-pcep-pmtu] defines
extensions to distribute path MTU information within BGP and PCEP SR
policies, respectively. In this way, the controller can compute the
appropriate PMTU for an SR path.
4.2.8.2. SRv6 Compression
The overhead of SRv6 encapsulation brings challenges for hardware
processing and transmission.
[I-D.srcompdt-spring-compression-requirement] describes the
requirements of SRv6 compression.
G-SRv6 is proposed in [I-D.cl-spring-generalized-srv6-np], which
supports to encode multiple types of SIDs in SRH. This SRH is called
Generalized SRH [I-D.lc-6man-generalized-srh] while the SID is called
Generalized SID.
G-SRv6 supports to encode the compressed SIDs in the SRH to reduce
the size of SRv6 SID list in SRH
[I-D.cl-spring-generalized-srv6-for-cmpr]. A COC (Continuation of
Compression) flavor is defined to indicate the continuation of SRv6
compressed SIDs in the SID list.
4.2.9. Application-aware IPv6 Networking
Application-aware Networking (APN) is proposed by
[I-D.li-apn-framework], where application characteristic information
such as application identification and its network performance
requirements is carried in the packet encapsulation in order to
facilitate service provisioning, perform application-level traffic
steering and network resource adjustment.
Shi, et al. Expires 7 March 2024 [Page 15]
Internet-Draft IPv6 based CON September 2023
Application-aware IPv6 Networking (APN6) framework makes use of IPv6
encapsulation in order to convey the application-aware information
along with the data packet to the network so to facilitate the
service deployment and SLA guarantee.
[I-D.li-6man-app-aware-ipv6-network] defines the encodings of the
application characteristic information, for the APN6 framework, that
can be exchanged between an application and the network
infrastructure through IPv6 extension headers.
5. IANA Considerations
TBD
6. Security Considerations
TBD
7. References
7.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/rfc/rfc2119>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.
[RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", STD 86, RFC 8200,
DOI 10.17487/RFC8200, July 2017,
<https://www.rfc-editor.org/rfc/rfc8200>.
[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/rfc/rfc8402>.
[RFC8754] Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J.,
Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header
(SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020,
<https://www.rfc-editor.org/rfc/rfc8754>.
7.2. Informative References
Shi, et al. Expires 7 March 2024 [Page 16]
Internet-Draft IPv6 based CON September 2023
[I-D.chen-rtgwg-srv6-midpoint-protection]
Chen, H., Hu, Z., Chen, H., Geng, X., Liu, Y., and G. S.
Mishra, "SRv6 Midpoint Protection", Work in Progress,
Internet-Draft, draft-chen-rtgwg-srv6-midpoint-protection-
12, 12 August 2023,
<https://datatracker.ietf.org/doc/html/draft-chen-rtgwg-
srv6-midpoint-protection-12>.
[I-D.cl-spring-generalized-srv6-for-cmpr]
Cheng, W., Li, Z., Li, C., Clad, F., Liu, A., Xie, C.,
Liu, Y., and S. Zadok, "Generalized SRv6 Network
Programming for SRv6 Compression", Work in Progress,
Internet-Draft, draft-cl-spring-generalized-srv6-for-cmpr-
07, 4 May 2023, <https://datatracker.ietf.org/doc/html/
draft-cl-spring-generalized-srv6-for-cmpr-07>.
[I-D.cl-spring-generalized-srv6-np]
Cheng, W., Li, Z., Li, C., Xie, C., Li, C., Tian, H., and
F. Zhao, "Generalized SRv6 Network Programming", Work in
Progress, Internet-Draft, draft-cl-spring-generalized-
srv6-np-03, 14 March 2021,
<https://datatracker.ietf.org/doc/html/draft-cl-spring-
generalized-srv6-np-03>.
[I-D.dong-6man-enhanced-vpn-vtn-id]
Dong, J., Li, Z., Xie, C., Ma, C., and G. S. Mishra,
"Carrying Virtual Transport Network (VTN) Identifier in
IPv6 Extension Header", Work in Progress, Internet-Draft,
draft-dong-6man-enhanced-vpn-vtn-id-06, 24 October 2021,
<https://datatracker.ietf.org/doc/html/draft-dong-6man-
enhanced-vpn-vtn-id-06>.
[I-D.dukes-spring-sr-for-sdwan]
Dukes, D., Filsfils, C., Dawra, G., Xu, X., Voyer, D.,
Camarillo, P., Clad, F., and S. Salsano, "SR For SDWAN:
VPN with Underlay SLA", Work in Progress, Internet-Draft,
draft-dukes-spring-sr-for-sdwan-03, 22 February 2021,
<https://datatracker.ietf.org/doc/html/draft-dukes-spring-
sr-for-sdwan-03>.
[I-D.dunbar-sr-sdwan-over-hybrid-networks]
Dunbar, L. and M. Toy, "SRv6 across SDWAN paths", Work in
Progress, Internet-Draft, draft-dunbar-sr-sdwan-over-
hybrid-networks-07, 18 May 2021,
<https://datatracker.ietf.org/doc/html/draft-dunbar-sr-
sdwan-over-hybrid-networks-07>.
Shi, et al. Expires 7 March 2024 [Page 17]
Internet-Draft IPv6 based CON September 2023
[I-D.geng-spring-sr-redundancy-protection]
Geng, X., Chen, M., Yang, F., Camarillo, P., and G. S.
Mishra, "SRv6 for Redundancy Protection", Work in
Progress, Internet-Draft, draft-geng-spring-sr-redundancy-
protection-05, 2 August 2021,
<https://datatracker.ietf.org/doc/html/draft-geng-spring-
sr-redundancy-protection-05>.
[I-D.hu-spring-segment-routing-proxy-forwarding]
Hu, Z., Chen, H., Yao, J., Bowers, C., Zhu, Y., and Y.
Liu, "SR-TE Path Midpoint Restoration", Work in Progress,
Internet-Draft, draft-hu-spring-segment-routing-proxy-
forwarding-24, 21 August 2023,
<https://datatracker.ietf.org/doc/html/draft-hu-spring-
segment-routing-proxy-forwarding-24>.
[I-D.ietf-idr-bgp-ls-link-mtu]
Zhu, Y., Hu, Z., Peng, S., and R. Mwehair, "Signaling
Maximum Transmission Unit (MTU) using BGP-LS", Work in
Progress, Internet-Draft, draft-ietf-idr-bgp-ls-link-mtu-
05, 26 July 2023, <https://datatracker.ietf.org/doc/html/
draft-ietf-idr-bgp-ls-link-mtu-05>.
[I-D.ietf-idr-segment-routing-te-policy]
Previdi, S., Filsfils, C., Talaulikar, K., Mattes, P., and
D. Jain, "Advertising Segment Routing Policies in BGP",
Work in Progress, Internet-Draft, draft-ietf-idr-segment-
routing-te-policy-23, 25 July 2023,
<https://datatracker.ietf.org/doc/html/draft-ietf-idr-
segment-routing-te-policy-23>.
[I-D.ietf-idr-sr-policy-path-mtu]
Li, C., Zhu, Y., El Sawaf, A., and Z. Li, "Segment Routing
Path MTU in BGP", Work in Progress, Internet-Draft, draft-
ietf-idr-sr-policy-path-mtu-07, 4 May 2023,
<https://datatracker.ietf.org/doc/html/draft-ietf-idr-sr-
policy-path-mtu-07>.
[I-D.ietf-ippm-ioam-ipv6-options]
Bhandari, S. and F. Brockners, "In-situ OAM IPv6 Options",
Work in Progress, Internet-Draft, draft-ietf-ippm-ioam-
ipv6-options-12, 7 May 2023,
<https://datatracker.ietf.org/doc/html/draft-ietf-ippm-
ioam-ipv6-options-12>.
[I-D.ietf-pce-segment-routing-policy-cp]
Koldychev, M., Sivabalan, S., Barth, C., Peng, S., and H.
Bidgoli, "PCEP extension to support Segment Routing Policy
Shi, et al. Expires 7 March 2024 [Page 18]
Internet-Draft IPv6 based CON September 2023
Candidate Paths", Work in Progress, Internet-Draft, draft-
ietf-pce-segment-routing-policy-cp-12, 24 July 2023,
<https://datatracker.ietf.org/doc/html/draft-ietf-pce-
segment-routing-policy-cp-12>.
[I-D.ietf-rtgwg-net2cloud-problem-statement]
Dunbar, L., Malis, A. G., Jacquenet, C., Toy, M., and K.
Majumdar, "Dynamic Networks to Hybrid Cloud DCs: Problem
Statement and Mitigation Practices", Work in Progress,
Internet-Draft, draft-ietf-rtgwg-net2cloud-problem-
statement-29, 24 August 2023,
<https://datatracker.ietf.org/doc/html/draft-ietf-rtgwg-
net2cloud-problem-statement-29>.
[I-D.ietf-rtgwg-segment-routing-ti-lfa]
Litkowski, S., Bashandy, A., Filsfils, C., Francois, P.,
Decraene, B., and D. Voyer, "Topology Independent Fast
Reroute using Segment Routing", Work in Progress,
Internet-Draft, draft-ietf-rtgwg-segment-routing-ti-lfa-
11, 30 June 2023, <https://datatracker.ietf.org/doc/html/
draft-ietf-rtgwg-segment-routing-ti-lfa-11>.
[I-D.ietf-rtgwg-srv6-egress-protection]
Hu, Z., Chen, H., Toy, M., Cao, C., and T. He, "SRv6 Path
Egress Protection", Work in Progress, Internet-Draft,
draft-ietf-rtgwg-srv6-egress-protection-14, 29 August
2023, <https://datatracker.ietf.org/doc/html/draft-ietf-
rtgwg-srv6-egress-protection-14>.
[I-D.ietf-spring-nsh-sr]
Guichard, J. and J. Tantsura, "Integration of Network
Service Header (NSH) and Segment Routing for Service
Function Chaining (SFC)", Work in Progress, Internet-
Draft, draft-ietf-spring-nsh-sr-15, 6 June 2023,
<https://datatracker.ietf.org/doc/html/draft-ietf-spring-
nsh-sr-15>.
[I-D.ietf-spring-sr-service-programming]
Clad, F., Xu, X., Filsfils, C., Bernier, D., Li, C.,
Decraene, B., Ma, S., Yadlapalli, C., Henderickx, W., and
S. Salsano, "Service Programming with Segment Routing",
Work in Progress, Internet-Draft, draft-ietf-spring-sr-
service-programming-08, 21 August 2023,
<https://datatracker.ietf.org/doc/html/draft-ietf-spring-
sr-service-programming-08>.
Shi, et al. Expires 7 March 2024 [Page 19]
Internet-Draft IPv6 based CON September 2023
[I-D.ietf-teas-enhanced-vpn]
Dong, J., Bryant, S., Li, Z., Miyasaka, T., and Y. Lee, "A
Framework for Enhanced Virtual Private Network (VPN+)",
Work in Progress, Internet-Draft, draft-ietf-teas-
enhanced-vpn-14, 28 July 2023,
<https://datatracker.ietf.org/doc/html/draft-ietf-teas-
enhanced-vpn-14>.
[I-D.lc-6man-generalized-srh]
Li, Z., Li, C., Cheng, W., Xie, C., Li, C., Tian, H., and
F. Zhao, "Generalized Segment Routing Header", Work in
Progress, Internet-Draft, draft-lc-6man-generalized-srh-
03, 9 February 2021,
<https://datatracker.ietf.org/doc/html/draft-lc-6man-
generalized-srh-03>.
[I-D.li-6man-app-aware-ipv6-network]
Li, Z., Peng, S., Li, C., Xie, C., Voyer, D., Li, X., Liu,
P., Liu, C., and K. Ebisawa, "Application-aware IPv6
Networking (APN6) Encapsulation", Work in Progress,
Internet-Draft, draft-li-6man-app-aware-ipv6-network-03,
22 February 2021, <https://datatracker.ietf.org/doc/html/
draft-li-6man-app-aware-ipv6-network-03>.
[I-D.li-apn-framework]
Li, Z., Peng, S., Voyer, D., Li, C., Liu, P., Cao, C., and
G. S. Mishra, "Application-aware Networking (APN)
Framework", Work in Progress, Internet-Draft, draft-li-
apn-framework-07, 3 April 2023,
<https://datatracker.ietf.org/doc/html/draft-li-apn-
framework-07>.
[I-D.li-pce-pcep-pmtu]
Peng, S., Li, C., Han, L., and L. Ndifor, "Support for
Path MTU (PMTU) in the Path Computation Element (PCE)
communication Protocol (PCEP).", Work in Progress,
Internet-Draft, draft-li-pce-pcep-pmtu-05, 21 October
2021, <https://datatracker.ietf.org/doc/html/draft-li-pce-
pcep-pmtu-05>.
[I-D.li-spring-srv6-security-consideration]
Li, C., Geng, N., Xie, C., Tian, H., tongtian124, Li, Z.,
and J. Mao, "Security Considerations for SRv6 Networks",
Work in Progress, Internet-Draft, draft-li-spring-srv6-
security-consideration-11, 23 July 2023,
<https://datatracker.ietf.org/doc/html/draft-li-spring-
srv6-security-consideration-11>.
Shi, et al. Expires 7 March 2024 [Page 20]
Internet-Draft IPv6 based CON September 2023
[I-D.song-opsawg-ifit-framework]
Song, H., Qin, F., Chen, H., Jin, J., and J. Shin,
"Framework for In-situ Flow Information Telemetry", Work
in Progress, Internet-Draft, draft-song-opsawg-ifit-
framework-20, 24 April 2023,
<https://datatracker.ietf.org/doc/html/draft-song-opsawg-
ifit-framework-20>.
[I-D.srcompdt-spring-compression-requirement]
Cheng, W., Xie, C., Bonica, R., Dukes, D., Li, C., Peng,
S., and W. Henderickx, "Compressed SRv6 SID List
Requirements", Work in Progress, Internet-Draft, draft-
srcompdt-spring-compression-requirement-07, 11 July 2021,
<https://datatracker.ietf.org/doc/html/draft-srcompdt-
spring-compression-requirement-07>.
[RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function
Chaining (SFC) Architecture", RFC 7665,
DOI 10.17487/RFC7665, October 2015,
<https://www.rfc-editor.org/rfc/rfc7665>.
[RFC7799] Morton, A., "Active and Passive Metrics and Methods (with
Hybrid Types In-Between)", RFC 7799, DOI 10.17487/RFC7799,
May 2016, <https://www.rfc-editor.org/rfc/rfc7799>.
[RFC8201] McCann, J., Deering, S., Mogul, J., and R. Hinden, Ed.,
"Path MTU Discovery for IP version 6", STD 87, RFC 8201,
DOI 10.17487/RFC8201, July 2017,
<https://www.rfc-editor.org/rfc/rfc8201>.
[RFC8986] Filsfils, C., Ed., Camarillo, P., Ed., Leddy, J., Voyer,
D., Matsushima, S., and Z. Li, "Segment Routing over IPv6
(SRv6) Network Programming", RFC 8986,
DOI 10.17487/RFC8986, February 2021,
<https://www.rfc-editor.org/rfc/rfc8986>.
[RFC9252] Dawra, G., Ed., Talaulikar, K., Ed., Raszuk, R., Decraene,
B., Zhuang, S., and J. Rabadan, "BGP Overlay Services
Based on Segment Routing over IPv6 (SRv6)", RFC 9252,
DOI 10.17487/RFC9252, July 2022,
<https://www.rfc-editor.org/rfc/rfc9252>.
[RFC9326] Song, H., Gafni, B., Brockners, F., Bhandari, S., and T.
Mizrahi, "In Situ Operations, Administration, and
Maintenance (IOAM) Direct Exporting", RFC 9326,
DOI 10.17487/RFC9326, November 2022,
<https://www.rfc-editor.org/rfc/rfc9326>.
Shi, et al. Expires 7 March 2024 [Page 21]
Internet-Draft IPv6 based CON September 2023
[RFC9341] Fioccola, G., Ed., Cociglio, M., Mirsky, G., Mizrahi, T.,
and T. Zhou, "Alternate-Marking Method", RFC 9341,
DOI 10.17487/RFC9341, December 2022,
<https://www.rfc-editor.org/rfc/rfc9341>.
[RFC9343] Fioccola, G., Zhou, T., Cociglio, M., Qin, F., and R.
Pang, "IPv6 Application of the Alternate-Marking Method",
RFC 9343, DOI 10.17487/RFC9343, December 2022,
<https://www.rfc-editor.org/rfc/rfc9343>.
Contributors
TBD
Acknowledgements
Authors' Addresses
Hang Shi
Huawei Technologies
Email: shihang9@huawei.com
Cheng Li
Huawei Technologies
China
Email: c.l@huawei.com
Zhenbin Li
Huawei Technologies
China
Email: lizhenbin@huawei.com
Shi, et al. Expires 7 March 2024 [Page 22]
