SPRING S. Hegde Internet-Draft C. Bowers Intended status: Informational Juniper Networks Inc. Expires: 28 March 2022 X. Xu Alibaba 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 24 September 2021 Seamless SR Problem Statement draft-hegde-spring-mpls-seamless-sr-06 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. Hegde, et al. Expires 28 March 2022 [Page 1] Internet-Draft Seamless SR Problem Statement September 2021 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 28 March 2022. Copyright Notice Copyright (c) 2021 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 . . . . . . 7 3.1. Inter-domain Data Sovereignty . . . . . . . . . . . . . . 7 3.2. Inter-domain Low-Latency Services . . . . . . . . . . . . 7 3.3. Network Mergers . . . . . . . . . . . . . . . . . . . . . 8 3.4. Inter-domain Service Function Chaining . . . . . . . . . 8 3.5. AS Confederation . . . . . . . . . . . . . . . . . . . . 9 3.6. Inter-domain Multicast Use cases . . . . . . . . . . . . 9 4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 10 4.1. AS and IGP Domain Models . . . . . . . . . . . . . . . . 10 4.1.1. Multiple ASes connected with E-BGP . . . . . . . . . 10 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 . . . . . . . . . . . . 12 4.2.1. Unicast tunneling Requirements . . . . . . . . . . . 12 Hegde, et al. Expires 28 March 2022 [Page 2] Internet-Draft Seamless SR Problem Statement September 2021 4.2.2. Multicast tunneling Requirements . . . . . . . . . . 12 4.3. Inter-domain SLA Requirements . . . . . . . . . . . . . . 13 4.3.1. Latency, Delay Variation, and Link Loss Constraints . . . . . . . . . . . . . . . . . . . . . 13 4.3.2. Bandwidth Constraints . . . . . . . . . . . . . . . . 14 4.3.3. Link Inclusion/Exclusion Constraints . . . . . . . . 14 4.3.4. Node Inclusion/Exclusion Constraints . . . . . . . . 14 4.3.5. Domain Inclusion/Exclusion Constraints . . . . . . . 14 4.3.6. Diverse Paths . . . . . . . . . . . . . . . . . . . . 15 4.3.7. Constraint applicability to a subset of domains . . . 16 4.3.8. Service function chaining . . . . . . . . . . . . . . 16 4.4. Multicast specific requirements . . . . . . . . . . . . . 16 4.5. Interoperate with BGP-LU . . . . . . . . . . . . . . . . 16 4.6. Merger and Migration Requirements . . . . . . . . . . . . 16 4.6.1. Option A and Option B Usecases . . . . . . . . . . . 16 4.6.2. Inter-Domain Intent Translation . . . . . . . . . . . 17 4.6.3. Native Support for Best Effort Paths . . . . . . . . 17 4.6.4. Interoperate with Other tunneling Mechanisms . . . . 17 4.7. Scalability Requirements . . . . . . . . . . . . . . . . 17 4.8. Availability Requirements . . . . . . . . . . . . . . . . 18 4.9. Operations and Automation Requirements . . . . . . . . . 18 4.10. Service Mapping Requirements . . . . . . . . . . . . . . 19 4.10.1. Traffic service mapping . . . . . . . . . . . . . . 19 4.10.2. 1 to N service mapping . . . . . . . . . . . . . . . 20 4.11. Interaction with Other Approaches . . . . . . . . . . . . 20 5. Backward Compatibility . . . . . . . . . . . . . . . . . . . 20 6. Security Considerations . . . . . . . . . . . . . . . . . . . 21 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 21 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 21 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 10.1. Normative References . . . . . . . . . . . . . . . . . . 21 10.2. Informative References . . . . . . . . . . . . . . . . . 22 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26 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. Hegde, et al. Expires 28 March 2022 [Page 3] Internet-Draft Seamless SR Problem Statement September 2021 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 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. Hegde, et al. Expires 28 March 2022 [Page 4] Internet-Draft Seamless SR Problem Statement September 2021 +-------+ +-------+ +------+ +------+ | | | | | | | | +--+ 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 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-| Hegde, et al. Expires 28 March 2022 [Page 5] Internet-Draft Seamless SR Problem Statement September 2021 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. 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. Hegde, et al. Expires 28 March 2022 [Page 6] Internet-Draft Seamless SR Problem Statement September 2021 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 +-----------+ +-----------+ +-----------+ | | | +-+ 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. Hegde, et al. Expires 28 March 2022 [Page 7] Internet-Draft Seamless SR Problem Statement September 2021 3.3. Network Mergers +-----------+ +-----------+ | ASBR1 ASBR2 | | | | | PE1+ AS1 +----------------+ AS2 +PE2 | ASBR11 ASBR22 | | | | | +-----------+ +-----------+ Figure 5: Network Mergers 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. Hegde, et al. Expires 28 March 2022 [Page 8] Internet-Draft Seamless SR Problem Statement September 2021 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. +---------+---------+---------+ | | | | 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. Hegde, et al. Expires 28 March 2022 [Page 9] Internet-Draft Seamless SR Problem Statement September 2021 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 ----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 Hegde, et al. Expires 28 March 2022 [Page 10] Internet-Draft Seamless SR Problem Statement September 2021 ----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 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 Hegde, et al. Expires 28 March 2022 [Page 11] Internet-Draft Seamless SR Problem Statement September 2021 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 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. Hegde, et al. Expires 28 March 2022 [Page 12] Internet-Draft Seamless SR Problem Statement September 2021 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. 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. Hegde, et al. Expires 28 March 2022 [Page 13] Internet-Draft Seamless SR Problem Statement September 2021 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. 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 Hegde, et al. Expires 28 March 2022 [Page 14] Internet-Draft Seamless SR Problem Statement September 2021 +-----------+ +-----------+ +-----------+ | | | 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. 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. Hegde, et al. Expires 28 March 2022 [Page 15] Internet-Draft Seamless SR Problem Statement September 2021 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. 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. Hegde, et al. Expires 28 March 2022 [Page 16] Internet-Draft Seamless SR Problem Statement September 2021 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. 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. Hegde, et al. Expires 28 March 2022 [Page 17] Internet-Draft Seamless SR Problem Statement September 2021 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. 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. Hegde, et al. Expires 28 March 2022 [Page 18] Internet-Draft Seamless SR Problem Statement September 2021 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. 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. Hegde, et al. Expires 28 March 2022 [Page 19] Internet-Draft Seamless SR Problem Statement September 2021 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. The distributed solution should co-exist with other distributed TE solutions. 5. Backward Compatibility Hegde, et al. Expires 28 March 2022 [Page 20] Internet-Draft Seamless SR Problem Statement September 2021 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", Work in Progress, Internet-Draft, draft-hegde-rtgwg-egress-protection-sr- networks-01, 15 November 2020, . [I-D.ietf-idr-performance-routing] Xu, X., Hegde, S., Talaulikar, K., Boucadair, M., and C. Jacquenet, "Performance-based BGP Routing Mechanism", Work in Progress, Internet-Draft, draft-ietf-idr-performance- routing-03, 22 December 2020, . Hegde, et al. Expires 28 March 2022 [Page 21] Internet-Draft Seamless SR Problem Statement September 2021 [I-D.kaliraj-idr-bgp-classful-transport-planes] Vairavakkalai, K., Venkataraman, N., Rajagopalan, B., Mishra, G., Khaddam, M., Xu, X., Szarecki, R. J., and D. J. Gowda, "BGP Classful Transport Planes", Work in Progress, Internet-Draft, draft-kaliraj-idr-bgp-classful- transport-planes-12, 25 August 2021, . [I-D.zzhang-bess-bgp-multicast] Zhang, Z., Giuliano, L., Patel, K., Wijnands, I., Mishra, M., and A. Gulko, "BGP Based Multicast", Work in Progress, Internet-Draft, draft-zzhang-bess-bgp-multicast-03, 29 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, . [RFC3107] Rekhter, Y. and E. Rosen, "Carrying Label Information in BGP-4", RFC 3107, DOI 10.17487/RFC3107, May 2001, . [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, . 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", Work in Progress, Internet-Draft, draft-hegde-spring-node-protection-for-sr- te-paths-07, 30 July 2020, . [I-D.ietf-idr-link-bandwidth] Mohapatra, P. and R. Fernando, "BGP Link Bandwidth Extended Community", Work in Progress, Internet-Draft, draft-ietf-idr-link-bandwidth-07, 5 March 2018, . Hegde, et al. Expires 28 March 2022 [Page 22] Internet-Draft Seamless SR Problem Statement September 2021 [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", Work in Progress, Internet- Draft, draft-ietf-idr-segment-routing-te-policy-13, 7 June 2021, . [I-D.ietf-idr-tunnel-encaps] Patel, K., Velde, G. V. D., Sangli, S. R., and J. Scudder, "The BGP Tunnel Encapsulation Attribute", Work in Progress, Internet-Draft, draft-ietf-idr-tunnel-encaps-22, 7 January 2021, . [I-D.ietf-lsr-flex-algo] Psenak, P., Hegde, S., Filsfils, C., Talaulikar, K., and A. Gulko, "IGP Flexible Algorithm", Work in Progress, Internet-Draft, draft-ietf-lsr-flex-algo-17, 6 July 2021, . [I-D.ietf-mpls-seamless-mpls] Leymann, N., Decraene, B., Filsfils, C., Konstantynowicz, M., and D. Steinberg, "Seamless MPLS Architecture", Work in Progress, Internet-Draft, draft-ietf-mpls-seamless- mpls-07, 28 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", Work in Progress, Internet-Draft, draft- ietf-pce-segment-routing-policy-cp-05, 23 May 2021, . [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- 07, 29 June 2021, . [I-D.ietf-spring-segment-routing-policy] Filsfils, C., Talaulikar, K., Voyer, D., Bogdanov, A., and P. Mattes, "Segment Routing Policy Architecture", Work in Hegde, et al. Expires 28 March 2022 [Page 23] Internet-Draft Seamless SR Problem Statement September 2021 Progress, Internet-Draft, draft-ietf-spring-segment- routing-policy-13, 28 May 2021, . [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-05, 10 September 2021, . [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", Work in Progress, Internet- Draft, draft-ietf-spring-srv6-network-programming-28, 29 December 2020, . [I-D.saad-sr-fa-link] Saad, T., Beeram, V. P., Barth, C., and S. Sivabalan, "Segment-Routing over Forwarding Adjacency Links", Work in Progress, Internet-Draft, draft-saad-sr-fa-link-03, 15 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", Work in Progress, Internet-Draft, draft-voyer-pim-sr-p2mp- policy-02, 10 July 2020, . [RFC1997] Chandra, R., Traina, P., and T. Li, "BGP Communities Attribute", RFC 1997, DOI 10.17487/RFC1997, August 1996, . [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 2006, . Hegde, et al. Expires 28 March 2022 [Page 24] Internet-Draft Seamless SR Problem Statement September 2021 [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, . [RFC5065] Traina, P., McPherson, D., and J. Scudder, "Autonomous System Confederations for BGP", RFC 5065, DOI 10.17487/RFC5065, August 2007, . [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, . [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, . [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, . [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, . [RFC7510] Xu, X., Sheth, N., Yong, L., Callon, R., and D. Black, "Encapsulating MPLS in UDP", RFC 7510, DOI 10.17487/RFC7510, April 2015, . [RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function Chaining (SFC) Architecture", RFC 7665, DOI 10.17487/RFC7665, October 2015, . [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, . Hegde, et al. Expires 28 March 2022 [Page 25] Internet-Draft Seamless SR Problem Statement September 2021 [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, . [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, . [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, . [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, . [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, . [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 560103 KA India Email: shraddha@juniper.net Chris Bowers Juniper Networks Inc. Hegde, et al. Expires 28 March 2022 [Page 26] Internet-Draft Seamless SR Problem Statement September 2021 Email: cbowers@juniper.net Xiaohu Xu Alibaba Inc. Beijing China Email: xiaohu.xxh@alibaba-inc.com Arkadiy Gulko EdwardJones Email: arkadiy.gulko@edwardjones.com Alex Bogdanov Google Inc. Email: bogdanov@google.com James Uttaro ATT Email: ju1738@att.com 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 Hegde, et al. Expires 28 March 2022 [Page 27] Internet-Draft Seamless SR Problem Statement September 2021 Luis M. Contreras Telefonica Ronda de la Comunicacion, s/n Sur-3 building, 3rd floor 28050 Madrid Spain Email: luismiguel.contrerasmurillo@telefonica.com URI: http://lmcontreras.com/ Hegde, et al. Expires 28 March 2022 [Page 28]