SPRING S. Hegde
Internet-Draft C. Bowers
Intended status: Informational Juniper Networks Inc.
Expires: January 9, 2023 X. Xu
Capital Online Inc.
A. Gulko
EdwardJones
A. Bogdanov
Google Inc.
J. Uttaro
ATT
L. Jalil
Verizon
M. Khaddam
Cox communications
A. Alston
Liquid Telecom
LM. Contreras
Telefonica
July 8, 2022
Seamless SR Problem Statement
draft-hegde-spring-mpls-seamless-sr-07
Abstract
This draft documents a set of use cases and requirements for end-to-
end intent-based paths spanning multi-domain packet networks. The
document explicitly focuses on use cases that require high scale and
availability, which will likely benefit from distributed solutions.
It is intended that the requirements in this document serve as a
basis for future IETF work to develop distributed solutions for
inter-domain intent-based transport paths.
Requirements Language
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 RFC 2119 [RFC2119].
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
Hegde, et al. Expires January 9, 2023 [Page 1]
Internet-Draft Seamless SR Problem Statement July 2022
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 January 9, 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
(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 Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Large scale networks . . . . . . . . . . . . . . . . . . . . 4
2.1. Service provider networks . . . . . . . . . . . . . . . . 4
2.2. Cloud provider WAN networks . . . . . . . . . . . . . . . 5
2.3. Data Center WAN Networks . . . . . . . . . . . . . . . . 6
3. Use Cases for Inter-domain Intent-based Transport . . . . . . 6
3.1. Inter-domain Data Sovereignty . . . . . . . . . . . . . . 6
3.2. Inter-domain Low-Latency Services . . . . . . . . . . . . 7
3.3. Network Mergers . . . . . . . . . . . . . . . . . . . . . 7
3.4. Inter-domain Service Function Chaining . . . . . . . . . 8
3.5. AS Confederation . . . . . . . . . . . . . . . . . . . . 8
3.6. Inter-domain Multicast Use cases . . . . . . . . . . . . 8
4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 9
4.1. AS and IGP Domain Models . . . . . . . . . . . . . . . . 9
4.1.1. Multiple ASes connected with E-BGP . . . . . . . . . 9
4.1.2. Single AS multiple IGP domains . . . . . . . . . . . 10
4.1.3. Single AS, Multiple IGP domains with no common border
node . . . . . . . . . . . . . . . . . . . . . . . . 11
4.2. Transport tunneling Requirements . . . . . . . . . . . . 11
4.2.1. Unicast tunneling Requirements . . . . . . . . . . . 11
4.2.2. Multicast tunneling Requirements . . . . . . . . . . 12
Hegde, et al. Expires January 9, 2023 [Page 2]
Internet-Draft Seamless SR Problem Statement July 2022
4.3. Inter-domain SLA Requirements . . . . . . . . . . . . . . 13
4.3.1. Latency, Delay Variation, and Link Loss Constraints . 13
4.3.2. Bandwidth Constraints . . . . . . . . . . . . . . . . 13
4.3.3. Link Inclusion/Exclusion Constraints . . . . . . . . 13
4.3.4. Node Inclusion/Exclusion Constraints . . . . . . . . 14
4.3.5. Domain Inclusion/Exclusion Constraints . . . . . . . 14
4.3.6. Diverse Paths . . . . . . . . . . . . . . . . . . . . 14
4.3.7. Constraint applicability to a subset of domains . . . 15
4.3.8. Service function chaining . . . . . . . . . . . . . . 15
4.4. Multicast specific requirements . . . . . . . . . . . . . 15
4.5. Interoperate with BGP-LU . . . . . . . . . . . . . . . . 15
4.6. Merger and Migration Requirements . . . . . . . . . . . . 16
4.6.1. Option A and Option B Usecases . . . . . . . . . . . 16
4.6.2. Inter-Domain Intent Translation . . . . . . . . . . . 16
4.6.3. Native Support for Best Effort Paths . . . . . . . . 16
4.6.4. Interoperate with Other tunneling Mechanisms . . . . 16
4.7. Scalability Requirements . . . . . . . . . . . . . . . . 16
4.8. Availability Requirements . . . . . . . . . . . . . . . . 17
4.9. Operations and Automation Requirements . . . . . . . . . 17
4.10. Service Mapping Requirements . . . . . . . . . . . . . . 18
4.10.1. Traffic service mapping . . . . . . . . . . . . . . 18
4.10.2. 1 to N service mapping . . . . . . . . . . . . . . . 19
4.11. Interaction with Other Approaches . . . . . . . . . . . . 19
5. Backward Compatibility . . . . . . . . . . . . . . . . . . . 20
6. Security Considerations . . . . . . . . . . . . . . . . . . . 20
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 20
9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 20
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 20
10.1. Normative References . . . . . . . . . . . . . . . . . . 20
10.2. Informative References . . . . . . . . . . . . . . . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25
1. Introduction
Evolving trends in wireless access technology, cloud applications,
virtualization, and network consolidation all contribute to the
increasing demands being placed on a common packet network. In order
to meet these demands, a given network will need to scale
horizontally in terms of its bandwidth, absolute number of nodes, and
geographical extent. The same network will need to scale vertically
in terms of the different services that it needs to simultaneously
support.
In order to operate networks with large numbers of devices, network
operators organize networks into multiple smaller network domains.
Each network domain typically runs an IGP which has complete
visibility within its own domain, but limited visibility outside of
Hegde, et al. Expires January 9, 2023 [Page 3]
Internet-Draft Seamless SR Problem Statement July 2022
its domain. Network operators will continue to use multiple domains
to scale horizontally. These multi-domain networks will also need to
scale vertically, to allow a common multi-domain network to carry all
of an organization's services.
Evolving network requirements (e.g., 5G, native cloud) motivate
network operators to deploy tunnels that span multiple AS's and
maintain specific transport characteristics (e.g., bandwidth,
latency). There is a need to provide flexible, scalable, and
reliable end-to-end connectivity for multiple services across
independent network domains.
2. Large scale networks
2.1. Service provider networks
Service Provider networks can contain many nodes distributed over a
large geographic area. 5G networks can include as many as one million
nodes, with the majority of those being radio access nodes. Radio
and access nodes may be constrained by their memory and processing
capabilities.
Service provider transport networks use multiple domains to support
scalability. For this analysis, we consider a representative network
design with four level of hierarchy: access domains, pre-aggregation
domains, aggregation domains and a core. (See Figure 1). The
separation of domains internal to the service provider can be
performed by using either IGP or BGP.
+-------+ +-------+ +------+ +------+
| | | | | | | |
+--+ P-AGG1+---+ AGG1 +---+ ABR1 +---+ LSR1 +--> to ABR
/ | | /| | | | | |
+----+/ +-------+\/ +-------+ +------+ /+------+
| AN | /\ \/
+----+\ +-------+ \+-------+ +------+/\ +------+
\ | | | | | | \| |
+--+ P-AGG2+---+ AGG2 +---+ ABR2 +---+ LSR2 +--> to ABR
| | | | | | | |
+-------+ +-------+ +------+ +------+
ISIS L1 ISIS L2 ISIS L2
|-Access-|--Aggregation Domain--|---------Core-----------------|
Figure 1: 5G network
Hegde, et al. Expires January 9, 2023 [Page 4]
Internet-Draft Seamless SR Problem Statement July 2022
5G networks support a variety of service use cases that require end-
to-end slicing. In certain cases the end-to-end connectivity
requires the ability to forward over intent-based paths. The inter-
domain solution should support end-to-end Service Level
Objectives(SLO) to allow the creation of network slices.
2.2. Cloud provider WAN networks
As WAN networks grow beyond several thousand nodes, it is often
useful to divide the network into multiple IGP domains, as
illustrated in Figure 2. Separate IGP domains increase service
availability by establishing a constrained failure domain. Smaller
IGP domains may also improve network performance and health by
reducing the device scale profile (including protocol and FIB scale).
+-------+ +-------+ +-------+
| | | | | |
| ABR1 ABR2 ABR3 ABR4 |
| | | | | |
PE1+ D1 +-----+ D2 +-----+ D3 +PE2
| | | | | |
| ABR11 ABR22 ABR33 ABR44 |
| | | | | |
+-------+ +-------+ +-------+
|-ISIS1-| |-ISIS2-| |-ISIS3-|
Figure 2: WAN Network
These large WAN networks often cross national boundaries. In order
to meet data sovereignty requirements, operators need to maintain
strict control over end-to-end traffic-engineered (TE) paths. A goal
of a distributed inter-domain solution is to be able to create highly
constrained inter-domain TE paths in a scalable manner.
Some deployments may use a centralized controller to acquire the
topologies of multiple domains and build end-to-end constrained
paths. This centralized approach can be scaled with hierarchical
controllers. However, there is still significant risk of a loss of
network connectivity to one or more controllers, which can result in
a failure to satisfy the strict requirements of data sovereignty.
The network should have pre-established TE paths end-to-end that
don't rely on controllers in order to address these failure
scenarios.
Hegde, et al. Expires January 9, 2023 [Page 5]
Internet-Draft Seamless SR Problem Statement July 2022
2.3. Data Center WAN Networks
Data centers are playing an increasingly important role in providing
access to information and applications. Geographically diverse data
centers usually connect via a high speed, reliable and secure DC WAN
core network.
+-------+ +-------+ +-------+
| ASBR1 ASBR2 ASBR3 ASBR4 |
| | | DC WAN| | |
PE1+ DC1 +-----+ CORE +-----+ DC2 +PE2
| ASBR11 ASBR22 ASBR33 ASBR44 |
| | | | | |
+-------+ +-------+ +-------+
|-ISIS1-| |-ISIS2-| |-ISIS3-|
Figure 3: DCI Network
In many DC WAN deployments, applications require end-to-end path
diversity and end-to-end low latency paths. The DC WAN networks may
consist of large number of devices owing to global presence. In some
DC WAN deployments the tunneling mechanisms used within the data
centers are the same as those used in the DC WAN core. For example,
a network may use MPLS in both data center and DC WAN core. Or it
may use SRv6 in both data center and DC WAN core. This can simplify
network deployments.
However, in some DC WAN deployments the traffic within data centers
and the traffic over the DC WAN core use different tunneling
mechanisms, such as SRv6 in the data center and MPLS in the DC WAN
core. It is important for DC WAN network operators to have
flexibility in the choice of tunneling mechanisms across domains.
3. Use Cases for Inter-domain Intent-based Transport
The use cases for inter-domain intent-based packet transport
described in this section are intended to provide motivation for the
requirements that follow.
3.1. Inter-domain Data Sovereignty
Hegde, et al. Expires January 9, 2023 [Page 6]
Internet-Draft Seamless SR Problem Statement July 2022
+-----------+ +-----------+ +-----------+
| | | +-+ AS2 | | |
| A1+--+A2 | | A3+--+A4 |
PE1+ AS1 | | |Z| | | AS3 +PE3
| A5+--+A6 | | A7+--+A8 |
| | | +-+ | | |
+--A13--A15-+ +-A17--A19--+ +-----------+
| | | |
| | | |
| | | |
+--A14--A16-+ +-A18--A20--+
| | | |
| A9+--+A10 |
PE4+ AS4 | | AS5 |
| A11+-+A12 |
| | | |
+-----------+ +-----------+
Figure 4: Multi domain Network
Figure Figure 4 depicts a WAN with multiple ASes. Each AS is resides
serves a continent (e.g., Asia). Certain traffic from PE1 (in AS1)
to PE3 (in AS3) must not traverse country Z in AS2. However, all
paths from AS1 to AS3 traverse AS 2. The inter-domain solution
should provide end-to-end path creation that traverses AS 2 but
avoids country Z.
3.2. Inter-domain Low-Latency Services
Service provider networks running L2 and L3VPNs carry traffic for
particular VPNs on low-latency paths that traverse multiple domains.
3.3. Network Mergers
+-----------+ +-----------+
| ASBR1 ASBR2 |
| | | |
PE1+ AS1 +----------------+ AS2 +PE2
| ASBR11 ASBR22 |
| | | |
+-----------+ +-----------+
Figure 5: Network Mergers
Hegde, et al. Expires January 9, 2023 [Page 7]
Internet-Draft Seamless SR Problem Statement July 2022
In diagram Figure 5 above, AS1 and AS2 which were previously under
independent administration, merge to come under a single
administration. The network operator may decide to merge the two
domains into single AS which would need bigger operational effort.
Network operators may also retain the two ASes and build end-to-end
paths across the two Ases. In this case, the paths in AS1 and AS2
corresponding to the same intent may use different representations in
the two ASes. In some cases, organizations may continue to use
option A or option B [RFC4364] style interconnectivity in which case
the inter-domain solution should satisfy intent of the path on inter-
domain links for the service prefixes. In other cases, organizations
may prefer to use option C style connectivity from PE1 to PE2. In
this case, an inter-domain solution should provide effective
mechanisms to translate intent across domains without requiring
renumbering of the intent representation.
3.4. Inter-domain Service Function Chaining
[RFC7665] defines service function chaining as an ordered set of
service functions and automated steering of traffic through this set
of service functions. There could be a variety of service functions
such as firewalls, parental control, CGNAT etc. In 5G networks these
functions may be completely virtualized or could be a mix of
virtualized functions and physical appliances. It is required that
the inter-domain solution caters to the service function chaining
requirements. The service functions may be virtualized and spread
across different data centers attached to different domains.
3.5. AS Confederation
BGP confederation allows the division of a public AS in multiple sub-
AS, usually with private identifiers. From outside, the
confederation is seen as a single and common AS, the public one. BGP
sessions are maintained among sub-AS. In the internals of the
confederation, each sub-AS can be configured and run autonomously,
even though some BGP parameters (like e.g. LOCAL_PREF or MED) are
preserved across sub-AS. Thus, it can be of interest to define end-
to-end paths of specific characteristics in terms of SLOs across the
sub-AS as well as internally to each sub-AS.
3.6. Inter-domain Multicast Use cases
Multicast services such as IPTV and multicast VPN also need to be
supported across a multi-domain service provider network.
Hegde, et al. Expires January 9, 2023 [Page 8]
Internet-Draft Seamless SR Problem Statement July 2022
+---------+---------+---------+
| | | |
S1 ABR1 ABR2 R1
| Metro1 | Core | Metro2 |
| | | |
S2 ABR11 ABR22 R2
| | | |
+---------+---------+---------+
|-ISIS1-| |-ISIS2-| |-ISIS3-|
Figure 6: Multicast usecases
Figure 6 shows a simplified multi-domain network supporting
multicast. Multicast sources S1 and S2 lie in a different domain
from the receivers R1 and R2. Using multiple IGP domains presents a
problem for the establishment of multicast replication trees.
Typically, a multicast receiver does a reverse path forwarding (RPF)
lookup for a multicast source. One solution is to leak the routes
for multicast sources across the IGP domains. However, this can
compromise the scaling properties of the multi-domain architecture.
A distributed inter-domain solution should accommodate a mixture of
existing and newer technologies to better facilitate coexistence and
migration. A distributed solution should avoid leaking RPF routes
into the IGP domains.
4. Requirements
The requirements described in this document are mostly applicable to
network under a single administrative domain that are organized into
multiple network domains. The requirements are also applicable to
multi-AS networks with closely cooperating administration.
4.1. AS and IGP Domain Models
This section describes three different ways that multi-domain
networks are organized today. The requirements in subsequent
sections are applicable to all three types of multi-domain networks
described below.
4.1.1. Multiple ASes connected with E-BGP
Hegde, et al. Expires January 9, 2023 [Page 9]
Internet-Draft Seamless SR Problem Statement July 2022
----IBGP------EBGP----IBGP------EBGP-----IBGP---
| | | | | |
+-----------+ +-----------+ +-----------+
| | | | | |
| ASBR1+--+ASBR2 ASBR3+--+ASBR4 |
PE1+ AS1 | X | AS2 | X | AS3 +PE2
| ASBR5+--+ASBR6 ASBR7+--+ASBR8 |
| | | | | |
+-----+-----+ +-----------+ +-----------+
PE3
|---ISIS1---| |---ISIS2---| |---ISIS3---|
Figure 7: Multiple ASes connected with E-BGP
The above diagram Figure 7 shows three different ASes (AS1, AS2 and
AS3.) ASBR1 to ASBR8 are border nodes between the ASes. A given
ASBR runs E-BGP sessions with the ASBRs in adjacent ASes. The ASBR
also runs I-BGP sessions with other ASBRs in the same AS. Route
reflectors can also be used to achieve this full mesh of I-BGP
information exchange.Similar scenario applies when considering BGP
confederations [RFC5065].
4.1.2. Single AS multiple IGP domains
----IBGP-----------IBGP-------------IBGP----
| | | |
+-----------+ +------------+ +-----------+
/ \ / \/ \
| ABR1 ABR3 |
| | | |
PE1+ Metro1 + Core + Metro2 +PE2
| | | |
| ABR2 ABR4 |
\ /\ /\ /
+------------+ +-----------+ +------------+
Figure 8: Single AS with Multiple IGP domains
The above diagram Figure 8 shows three different IGP domains, Metro1,
Core, and Metro2. The three IGP domains may be realized with
Hegde, et al. Expires January 9, 2023 [Page 10]
Internet-Draft Seamless SR Problem Statement July 2022
multiple levels in ISIS or multiple areas in OSPF. They can also be
realized using separate IGP instances.
This single-AS network uses I-BGP sessions. ABRs and PEs achieve a
full mesh of I-BGP information sharing by configuring the ABRs as
inline route reflectors.
4.1.3. Single AS, Multiple IGP domains with no common border node
----IBGP-----IBGP----IBGP------IBGP-----IBGP---
| | | | | |
+-----------+ +-----------+ +-----------+
| | | | | |
| ABR1+--+ABR2 ABR3+--+ABR4 |
PE1+ AS1:D1 | X | AS1:D2 | X | AS1:D3 +PE2
| ABR5+--+ABR6 ABR7+--+ABR8 |
| | | | | |
+-----+-----+ +-----------+ +-----------+
PE3
|---ISIS1---| |---ISIS2---| |---ISIS3---|
Figure 9: Single AS multiple IGP domains with no common Border node
The above diagram Figure 9 shows a single AS1 with three different
IGP domains, D1, D2, and D3. ABR1 to ABR8 are border nodes for the
IGP domains and they participate in only one IGP domain.
This single-AS network uses I-BGP sessions. ABRs and PEs achieve a
full mesh of I-BGP information sharing by configuring the ABRs as
inline route reflectors.
4.2. Transport tunneling Requirements
4.2.1. Unicast tunneling Requirements
The inter-domain solution should support the following unicast
tunneling mechanisms:
SR-MPLS tunnels with IPv4 underlay
SR-MPLS tunnels with IPv6 underlay
SR-MPLS tunnels with dual stack underlay
Hegde, et al. Expires January 9, 2023 [Page 11]
Internet-Draft Seamless SR Problem Statement July 2022
SRv6 tunneling end-to-end
Segment routing TE tunnels and color-only policies as described in
[I-D.ietf-idr-segment-routing-te-policy] (both SR-MPLS and SRv6)
Flex-algo [I-D.ietf-lsr-flex-algo] (both SR-MPLS and SRv6)
Pure IP fabric (incapable of supporting MPLS or SRv6 tunneling
mechanisms)
RSVP and LDP based tunnels
The inter-domain solution should support the ability to have
different domains running different unicast tunneling mechanisms.
The solution should support inter-domain paths that fulfil a common
intent using different unicast tunneling mechanisms in different
domains.
4.2.2. Multicast tunneling Requirements
The inter-domain solution should support the following multicast
tunneling mechanisms:
All of the unicast tunneling mechanisms described in Section 4.2.1
should be supported for multicast service for the purpose of
ingress replication.
SR-P2MP as defined in [I-D.voyer-pim-sr-p2mp-policy]
PIM based multicast
RSVP-P2MP and mLDP [RFC6388] based tunnels
BGP based multicast (hop-by-hop or controller-driven, for native
IP, labelled, or SRv6 forwarding planes)
The inter-domain solution should support the ability to have
different domains running different multicast tunneling mechanisms
and should not require to leak RPF routes into IGP domains.
The solution should support inter-domain paths that fulfil a common
intent using different multicast tunneling mechanisms in different
domains.
Hegde, et al. Expires January 9, 2023 [Page 12]
Internet-Draft Seamless SR Problem Statement July 2022
4.3. Inter-domain SLA Requirements
This section discusses the end-to-end constraints that intent-based
inter-domain path may have to adhere to. The requirements described
in this section are applicable to the three types of AS and IGP
domain partitioning described in Section 4.1.
4.3.1. Latency, Delay Variation, and Link Loss Constraints
Link delay, delay variation and link loss values can be advertised
within a domain using the IGP as described in [RFC8570]. Within an
IGP domain, minimum latency, minimum delay variation, and minimum
link loss paths can be built using flex-algo
[I-D.ietf-lsr-flex-algo]. The end-to-end low latency, low delay
variation, or low link loss path requires accumulated metrics for
latency, delay variation, and link loss.
The solution should allow the creation of inter-domain paths with low
values of latency as calculated over the end-to-end path. It is not
necessary that the solution produce the absolute minimum end-to-end
latency, delay variation, or link loss path. However, the solution
should provide the ability to balance scalability with optimality.
Best path selection at any intermediate border node should be
allowed.
The inter-domain solution should allow advertising multiple paths
end-to-end and compare the accumulated metric across all of the paths
at the ingress.
4.3.2. Bandwidth Constraints
A distributed solution should support the creation of inter-domain
paths using intra-domain bandwidth guaranteed paths.
A distributed solution may support optimized path placement with end-
to-end bandwidth guarantees.
4.3.3. Link Inclusion/Exclusion Constraints
The links are associated with link-affinity or admin-groups. The
link-affinity can be used to indicate a characteristic of a link,
such as capacity, encryption, geography, etc. The inter-domain
solution should support the creation of paths across different
domains that satisfy link inclusion/exclusion constraints. The link
constraints should also be satisfied for inter-domain links, such as
those between ASBRs.
Hegde, et al. Expires January 9, 2023 [Page 13]
Internet-Draft Seamless SR Problem Statement July 2022
4.3.4. Node Inclusion/Exclusion Constraints
Creating an inter-domain path that includes or excludes a certain set
of nodes in each domain should be supported. The inter-domain
solution should be independent of the mechanisms used to achieve the
node inclusion/exclusion constraints within a domain. For example,
an RSVP-based domain may use link affinities to achieve node
exclusion constraints, while an SR-based domain may use flex-algo,
which natively supports excluding nodes.
4.3.5. Domain Inclusion/Exclusion Constraints
+-----------+ +-----------+ +-----------+
| | | AS2 | | |
| A1+--+A2 A3+--+A4 |
PE1+ AS1 | | | | AS3 +PE3
| A5+--+A6 A7+--+A8 |
| | | | | |
+--A13--A15-+ +-A17--A19--+ +-AS22--AS23+
| | | |
| | | |
| | | |
+--A14--A16-+ +-A18--A20--+ | |
| | | | | |
| A9+--+A10 AS20---- |
PE4+ AS4 | | AS5 | |
| A11+-+A12 AS21------------
| | | |
+-----------+ +-----------+
Figure 10: Multi-domain Network
Diagram Figure 10 shows a multi-domain, multi-AS network with the
possibility for AS-diverse paths. The inter-domain solution should
support creation of end-to-end paths that includes/excludes a certain
domain entirely. For example, a network operator should be able to
use the solution to create a path from PE1 to PE3 that automatically
avoids passing through nodes belonging to AS2.
4.3.6. Diverse Paths
The solution should support the creation of node and link-diverse
inter-domain paths.
Hegde, et al. Expires January 9, 2023 [Page 14]
Internet-Draft Seamless SR Problem Statement July 2022
The intra-domain portion of the end-to-end paths should make use of
existing mechanisms for computing and instantiating diverse paths
within a domain.
Inter-domain links (such as those connecting ASBRs) should also be
taken into account for diverse inter-domain paths.
The solution should support SRLG-aware inter-domain diverse paths.
4.3.7. Constraint applicability to a subset of domains
Use cases such as data sovereignty described in Section 3.1 require
that the paths with certain constraints are applicable to only a
subset of domains. In domains where a constraint is not applicable,
the end-to-end path should not create any state on the internal
nodes.
4.3.8. Service function chaining
Support the case where the set of service functions to be applied
are deployed in single domain.
Support the case where the set of service functions to be applied
are deployed across multiple domains.
Support virtualized service functions as well as service functions
based on physical appliances.
Support the movement of a virtualized service function from one
location to another.
Support high availability for service functions.
4.4. Multicast specific requirements
Many of the requirements above are applicable to multicast traffic as
well. Some requirements need to be refined with respect to
multicast. Multicast also has some unique requirements not shared by
unicast. These requirements will be covered in a future version of
this document.
4.5. Interoperate with BGP-LU
Seamless MPLS architecture is widely deployed and BGP-LU [RFC3107] is
used to connect different domains. The inter-domain solution for
intent-based paths should be interoperable with BGP-LU.
Hegde, et al. Expires January 9, 2023 [Page 15]
Internet-Draft Seamless SR Problem Statement July 2022
4.6. Merger and Migration Requirements
4.6.1. Option A and Option B Usecases
Options A and B require additional state on border nodes, so they are
typically less scalable than option C. However, options A and B can
be advantageous when it is necessary to do filtering or policing on
border nodes. When option A or B is deployed, the solution should
still meet the SLA requirements described in Section 4.3.
4.6.2. Inter-Domain Intent Translation
In cases where two network domains previously under different
administrations merge to come under a single administration, it may
be preferable to use option C connectivity between the domains. The
paths that fulfill the same intent may be represented using different
conventions in each domain. The inter-domain solution should support
efficient translation of intent from one representation to another.
4.6.3. Native Support for Best Effort Paths
The inter-domain solution for intent-based paths should also provide
the ability to create end-to-end best effort paths with accumulated
IGP metric across the domains. A deployment should not require two
different mechanisms to be deployed for best effort and intent-based
paths.
4.6.4. Interoperate with Other tunneling Mechanisms
As described in Section 4.2.1 and Section 3.6 the inter-domain
solution should support one domain having one type of tunneling
mechanism and another domain having another type of tunneling
mechanism. The different tunneling mechanisms may completely differ
in control plane and data plane operations (e.g. SRv6 and MPLS.)
The inter-domain solution should provide interoperability between
various tunneling mechanisms and provide the ability to create end-
to-end intent-based paths.
4.7. Scalability Requirements
The inter-domain solution should be able to support up to 1
million nodes.
The inter-domain solution should facilitate the use of access
nodes with low RIB/FIB and low CPU capabilities.
The inter-domain solution should facilitate the use of access
nodes with low label stacking capability.
Hegde, et al. Expires January 9, 2023 [Page 16]
Internet-Draft Seamless SR Problem Statement July 2022
The inter-domain solution should allow for a scalable response to
network events. An individual node should only need to respond to
a limited subset of network events.
Service routes on the border nodes should be minimized.
Non-MPLS versions of the inter-domain solution should support
summarization of prefixes in order achieve scalability.
The inter-domain solution should facilitate filtering in order to
ensure the access nodes need to receive and process only the
endpoint prefixes that the access node needs to send traffic to.
The inter-domain solution should minimize state on the border
nodes in order to reduce label and FIB resource consumption on
border nodes.
4.8. Availability Requirements
Traffic should be Fast Reroute (FRR) protected against link, node,
and SRLG failures within a domain.
Traffic should be FRR protected against border node failures.
Traffic should be FRR protected against inter-domain link
failures.
Traffic should be FRR protected against egress node and egress
link failures.
4.9. Operations and Automation Requirements
Each domain should be independent and should not depend on the
transport technology in another domain. This allows for more
flexible evolution of the network.
Basic MPLS OAM mechanisms described in [RFC8029] should be
supported for MPLS based solutions.
End-to-end ping and traceroute procedures should be supported.
The ability to validate the path inside each domain should be
supported.
Statistics for inter-domain intent-based paths should be supported
on a per path basis on the ingress and egress PE nodes as well as
border nodes.
Hegde, et al. Expires January 9, 2023 [Page 17]
Internet-Draft Seamless SR Problem Statement July 2022
The choice of transport tunnels that make up the inter-domain path
should be derived automatically from the intent that the path
fulfills.
The intent defined as color in the SR-TE architecture
[I-D.ietf-idr-segment-routing-te-policy] should map automatically
for all controller to router protocols such as BGP-SR-TE
[I-D.ietf-idr-segment-routing-te-policy], PCEP-SR
[I-D.ietf-pce-segment-routing-policy-cp], and NETCONF.
The intent should be mapped automatically from flex-algo number
[I-D.ietf-lsr-flex-algo].
When access devices have CPU and memory constraints, it is useful
to be able to filter prefix advertisements using policies as
described in Section 4.7 For large networks it is operationally a
tedious and erroneous process to manage this. The inter-domain
solution should facilitate filtering the advertisements
automatically, based on the service prefixes it receives from end-
points.
4.10. Service Mapping Requirements
The above requirements focus on the service independent aspects of
inter-domain intent-based paths. In order for different services to
effectively use these paths, flexible service mapping is required.
The sections below summarize the requirements needed to achieve
flexible service mapping.
4.10.1. Traffic service mapping
Automated steering of traffic onto transport paths based on
communities carried in the service prefix advertisements should be
supported.
Steering of traffic on to transport paths based on the DSCP value
carried in IPv4/IPv6 packets should be supported.
Traffic steering based on EXP bits in the MPLS header should be
supported.
Traffic steering based on 5-tuple packet filter should be
supported. Source address, destination address, source port,
destination port and protocol fields should be allowed.
All the above traffic steering mechanisms should be supported for
all common types of service traffic, including L2 VPN and L3 VPN
traffic and global internet traffic.
Hegde, et al. Expires January 9, 2023 [Page 18]
Internet-Draft Seamless SR Problem Statement July 2022
When a path that fulfills the desired intent is not available,
fallback to a path that fulfills a secondary intent should be
supported.
When a path that fulfills the desired intent is not available,
fallback to a best-effort path should be supported.
When a path that fulfills the desired intent is not available, the
option of not using a fallback path (i,e. dropping the traffic)
should be supported.
4.10.2. 1 to N service mapping
The core domain is expected to have more traffic engineering
constraints as compared to metros. The ability to map the services
to appropriate transport tunnels at service attachment points should
be supported.
4.11. Interaction with Other Approaches
This document focuses on use cases and requirements that may benefit
from a distributed solution. Many of these same use cases and
requirements can be addressed with centralized approaches or other
distributed TE solutions. One example of a centralized approach is
described in "Interconnecting Millions of Endpoints with Segment
Routing" ([RFC8604]).
Distributed and centralized approaches have inherent tradeoffs. Some
networks may use a single approach. Other networks may choose to use
both distributed and centralized approaches to get the benefits of
both. A distributed inter-domain solution should support the
requirements below:
Support scenarios where some traffic uses paths created using a
centralized approach, and other traffic uses paths created using
the distributed solution.
Support scenarios where part of the distributed inter-domain path
is created using a centralized approach.
Support scenarios where traffic uses a centralized inter-domain
solution for primary traffic, and uses a distributed inter-domain
solution as a backup.
The distributed solution should not have any inherent dependencies
on centralized approaches.
Hegde, et al. Expires January 9, 2023 [Page 19]
Internet-Draft Seamless SR Problem Statement July 2022
The distributed solution should co-exist with other distributed TE
solutions.
5. Backward Compatibility
6. Security Considerations
TBD
7. IANA Considerations
8. Acknowledgements
Many thanks to Kireeti Kompella, Ron Bonica, Krzysztof Szarcowitz,
Srihari Sangli, Julian Lucek, Ram Santhanakrishnan, for discussions
and inputs. Thanks to Colby Barth, John Scudder, Joel Halpern for
review and comments.
9. Contributors
1.Kaliraj Vairavakkalai
Juniper Networks
kaliraj@juniper.net
2. Jeffrey Zhang
Juniper Networks
zzhang@juniper.net
10. References
10.1. Normative References
[I-D.hegde-rtgwg-egress-protection-sr-networks]
Hegde, S., Lin, W., and P. Shaofu, "Egress Protection for
Segment Routing (SR) networks", draft-hegde-rtgwg-egress-
protection-sr-networks-02 (work in progress), March 2022.
[I-D.ietf-idr-performance-routing]
Xu, X., Hegde, S., Talaulikar, K., Boucadair, M., and C.
Jacquenet, "Performance-based BGP Routing Mechanism",
draft-ietf-idr-performance-routing-03 (work in progress),
December 2020.
Hegde, et al. Expires January 9, 2023 [Page 20]
Internet-Draft Seamless SR Problem Statement July 2022
[I-D.kaliraj-idr-bgp-classful-transport-planes]
Vairavakkalai, K., Venkataraman, N., Rajagopalan, B.,
Mishra, G., Khaddam, M., Xu, X., Szarecki, R. J., Gowda,
D. J., Yadlapalli, C., and I. Means, "BGP Classful
Transport Planes", draft-kaliraj-idr-bgp-classful-
transport-planes-17 (work in progress), June 2022.
[I-D.zzhang-bess-bgp-multicast]
Zhang, Z., Giuliano, L., Patel, K., Wijnands, I., Mishra,
M., and A. Gulko, "BGP Based Multicast", draft-zzhang-
bess-bgp-multicast-03 (work in progress), October 2019.
[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/info/rfc2119>.
[RFC3107] Rekhter, Y. and E. Rosen, "Carrying Label Information in
BGP-4", RFC 3107, DOI 10.17487/RFC3107, May 2001,
<https://www.rfc-editor.org/info/rfc3107>.
[RFC8669] Previdi, S., Filsfils, C., Lindem, A., Ed., Sreekantiah,
A., and H. Gredler, "Segment Routing Prefix Segment
Identifier Extensions for BGP", RFC 8669,
DOI 10.17487/RFC8669, December 2019,
<https://www.rfc-editor.org/info/rfc8669>.
10.2. Informative References
[I-D.hegde-spring-node-protection-for-sr-te-paths]
Hegde, S., Bowers, C., Litkowski, S., Xu, X., and F. Xu,
"Node Protection for SR-TE Paths", draft-hegde-spring-
node-protection-for-sr-te-paths-07 (work in progress),
July 2020.
[I-D.ietf-idr-link-bandwidth]
Mohapatra, P. and R. Fernando, "BGP Link Bandwidth
Extended Community", draft-ietf-idr-link-bandwidth-07
(work in progress), March 2018.
[I-D.ietf-idr-segment-routing-te-policy]
Previdi, S., Filsfils, C., Talaulikar, K., Mattes, P.,
Jain, D., and S. Lin, "Advertising Segment Routing
Policies in BGP", draft-ietf-idr-segment-routing-te-
policy-18 (work in progress), June 2022.
Hegde, et al. Expires January 9, 2023 [Page 21]
Internet-Draft Seamless SR Problem Statement July 2022
[I-D.ietf-idr-tunnel-encaps]
Patel, K., Velde, G. V. D., Sangli, S. R., and J. Scudder,
"The BGP Tunnel Encapsulation Attribute", draft-ietf-idr-
tunnel-encaps-22 (work in progress), January 2021.
[I-D.ietf-lsr-flex-algo]
Psenak, P., Hegde, S., Filsfils, C., Talaulikar, K., and
A. Gulko, "IGP Flexible Algorithm", draft-ietf-lsr-flex-
algo-20 (work in progress), May 2022.
[I-D.ietf-mpls-seamless-mpls]
Leymann, N., Decraene, B., Filsfils, C., Konstantynowicz,
M., and D. Steinberg, "Seamless MPLS Architecture", draft-
ietf-mpls-seamless-mpls-07 (work in progress), June 2014.
[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
Candidate Paths", draft-ietf-pce-segment-routing-policy-
cp-07 (work in progress), April 2022.
[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", draft-ietf-rtgwg-segment-
routing-ti-lfa-08 (work in progress), January 2022.
[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-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",
draft-ietf-spring-sr-service-programming-06 (work in
progress), June 2022.
[I-D.ietf-spring-srv6-network-programming]
Filsfils, C., Garvia, P. C., Leddy, J., Voyer, D.,
Matsushima, S., and Z. Li, "Segment Routing over IPv6
(SRv6) Network Programming", draft-ietf-spring-srv6-
network-programming-28 (work in progress), December 2020.
Hegde, et al. Expires January 9, 2023 [Page 22]
Internet-Draft Seamless SR Problem Statement July 2022
[I-D.saad-sr-fa-link]
Saad, T., Beeram, V. P., Barth, C., and S. Sivabalan,
"Segment-Routing over Forwarding Adjacency Links", draft-
saad-sr-fa-link-03 (work in progress), February 2021.
[I-D.voyer-pim-sr-p2mp-policy]
Voyer, D., Filsfils, C., Parekh, R., Bidgoli, H., and Z.
Zhang, "Segment Routing Point-to-Multipoint Policy",
draft-voyer-pim-sr-p2mp-policy-02 (work in progress), July
2020.
[RFC1997] Chandra, R., Traina, P., and T. Li, "BGP Communities
Attribute", RFC 1997, DOI 10.17487/RFC1997, August 1996,
<https://www.rfc-editor.org/info/rfc1997>.
[RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private
Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February
2006, <https://www.rfc-editor.org/info/rfc4364>.
[RFC4684] Marques, P., Bonica, R., Fang, L., Martini, L., Raszuk,
R., Patel, K., and J. Guichard, "Constrained Route
Distribution for Border Gateway Protocol/MultiProtocol
Label Switching (BGP/MPLS) Internet Protocol (IP) Virtual
Private Networks (VPNs)", RFC 4684, DOI 10.17487/RFC4684,
November 2006, <https://www.rfc-editor.org/info/rfc4684>.
[RFC5065] Traina, P., McPherson, D., and J. Scudder, "Autonomous
System Confederations for BGP", RFC 5065,
DOI 10.17487/RFC5065, August 2007,
<https://www.rfc-editor.org/info/rfc5065>.
[RFC5357] Hedayat, K., Krzanowski, R., Morton, A., Yum, K., and J.
Babiarz, "A Two-Way Active Measurement Protocol (TWAMP)",
RFC 5357, DOI 10.17487/RFC5357, October 2008,
<https://www.rfc-editor.org/info/rfc5357>.
[RFC6388] Wijnands, IJ., Ed., Minei, I., Ed., Kompella, K., and B.
Thomas, "Label Distribution Protocol Extensions for Point-
to-Multipoint and Multipoint-to-Multipoint Label Switched
Paths", RFC 6388, DOI 10.17487/RFC6388, November 2011,
<https://www.rfc-editor.org/info/rfc6388>.
[RFC7311] Mohapatra, P., Fernando, R., Rosen, E., and J. Uttaro,
"The Accumulated IGP Metric Attribute for BGP", RFC 7311,
DOI 10.17487/RFC7311, August 2014,
<https://www.rfc-editor.org/info/rfc7311>.
Hegde, et al. Expires January 9, 2023 [Page 23]
Internet-Draft Seamless SR Problem Statement July 2022
[RFC7471] Giacalone, S., Ward, D., Drake, J., Atlas, A., and S.
Previdi, "OSPF Traffic Engineering (TE) Metric
Extensions", RFC 7471, DOI 10.17487/RFC7471, March 2015,
<https://www.rfc-editor.org/info/rfc7471>.
[RFC7510] Xu, X., Sheth, N., Yong, L., Callon, R., and D. Black,
"Encapsulating MPLS in UDP", RFC 7510,
DOI 10.17487/RFC7510, April 2015,
<https://www.rfc-editor.org/info/rfc7510>.
[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/info/rfc7665>.
[RFC8029] Kompella, K., Swallow, G., Pignataro, C., Ed., Kumar, N.,
Aldrin, S., and M. Chen, "Detecting Multiprotocol Label
Switched (MPLS) Data-Plane Failures", RFC 8029,
DOI 10.17487/RFC8029, March 2017,
<https://www.rfc-editor.org/info/rfc8029>.
[RFC8287] Kumar, N., Ed., Pignataro, C., Ed., Swallow, G., Akiya,
N., Kini, S., and M. Chen, "Label Switched Path (LSP)
Ping/Traceroute for Segment Routing (SR) IGP-Prefix and
IGP-Adjacency Segment Identifiers (SIDs) with MPLS Data
Planes", RFC 8287, DOI 10.17487/RFC8287, December 2017,
<https://www.rfc-editor.org/info/rfc8287>.
[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>.
[RFC8570] Ginsberg, L., Ed., Previdi, S., Ed., Giacalone, S., Ward,
D., Drake, J., and Q. Wu, "IS-IS Traffic Engineering (TE)
Metric Extensions", RFC 8570, DOI 10.17487/RFC8570, March
2019, <https://www.rfc-editor.org/info/rfc8570>.
[RFC8604] Filsfils, C., Ed., Previdi, S., Dawra, G., Ed.,
Henderickx, W., and D. Cooper, "Interconnecting Millions
of Endpoints with Segment Routing", RFC 8604,
DOI 10.17487/RFC8604, June 2019,
<https://www.rfc-editor.org/info/rfc8604>.
[RFC8679] Shen, Y., Jeganathan, M., Decraene, B., Gredler, H.,
Michel, C., and H. Chen, "MPLS Egress Protection
Framework", RFC 8679, DOI 10.17487/RFC8679, December 2019,
<https://www.rfc-editor.org/info/rfc8679>.
Hegde, et al. Expires January 9, 2023 [Page 24]
Internet-Draft Seamless SR Problem Statement July 2022
[TS.23.501-3GPP]
3rd Generation Partnership Project (3GPP), "System
Architecture for 5G System; Stage 2, 3GPP TS 23.501
v16.4.0", March 2020.
Authors' Addresses
Shraddha Hegde
Juniper Networks Inc.
Exora Business Park
Bangalore, KA 560103
India
Email: shraddha@juniper.net
Chris Bowers
Juniper Networks Inc.
Email: cbowers@juniper.net
Xiaohu Xu
Capital Online Inc.
Beijing
China
Email: xiaohu.xu@capitalonline.net
Arkadiy Gulko
EdwardJones
Email: arkadiy.gulko@edwardjones.com
Alex Bogdanov
Google Inc.
Email: bogdanov@google.com
James Uttaro
ATT
Email: ju1738@att.com
Hegde, et al. Expires January 9, 2023 [Page 25]
Internet-Draft Seamless SR Problem Statement July 2022
Luay Jalil
Verizon
Email: luay.jalil@verizon.com
Mazen Khaddam
Cox communications
Email: mazen.khaddam@cox.com
Andrew Alston
Liquid Telecom
Email: andrew.alston@liquidtelecom.com
Luis M. Contreras
Telefonica
Ronda de la Comunicacion, s/n
Sur-3 building, 3rd floor
Madrid 28050
Spain
Email: luismiguel.contrerasmurillo@telefonica.com
URI: http://lmcontreras.com/
Hegde, et al. Expires January 9, 2023 [Page 26]