Seamless SR Problem Statement
draft-hegde-spring-mpls-seamless-sr-05

Document Type Active Internet-Draft (individual)
Authors Shraddha Hegde  , Chris Bowers  , Xiaohu Xu  , Arkadiy Gulko  , Alex Bogdanov  , Jim Uttaro  , Luay Jalil  , Mazen Khaddam  , Andrew Alston  , Luis Contreras 
Last updated 2021-02-22
Stream (None)
Intended RFC status (None)
Formats plain text xml pdf htmlized bibtex
Stream Stream state (No stream defined)
Consensus Boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date
Responsible AD (None)
Send notices to (None)
SPRING                                                          S. Hegde
Internet-Draft                                                 C. Bowers
Intended status: Informational                     Juniper Networks Inc.
Expires: August 26, 2021                                           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
                                                       February 22, 2021

                     Seamless SR Problem Statement
                 draft-hegde-spring-mpls-seamless-sr-05

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 August 26, 2021                [Page 1]
Internet-Draft        Seamless SR Problem Statement        February 2021

   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 August 26, 2021.

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 . . . . . .   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 August 26, 2021                [Page 2]
Internet-Draft        Seamless SR Problem Statement        February 2021

     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 August 26, 2021                [Page 3]
Internet-Draft        Seamless SR Problem Statement        February 2021

   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 August 26, 2021                [Page 4]
Internet-Draft        Seamless SR Problem Statement        February 2021

   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 August 26, 2021                [Page 5]
Internet-Draft        Seamless SR Problem Statement        February 2021

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 August 26, 2021                [Page 6]
Internet-Draft        Seamless SR Problem Statement        February 2021

                 +-----------+     +-----------+     +-----------+
                 |           |     |  +-+  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 August 26, 2021                [Page 7]
Internet-Draft        Seamless SR Problem Statement        February 2021

   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 August 26, 2021                [Page 8]
Internet-Draft        Seamless SR Problem Statement        February 2021

                 +---------+---------+---------+
                 |         |         |         |
                 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 August 26, 2021                [Page 9]
Internet-Draft        Seamless SR Problem Statement        February 2021

                    ----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 August 26, 2021               [Page 10]
Internet-Draft        Seamless SR Problem Statement        February 2021

   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 August 26, 2021               [Page 11]
Internet-Draft        Seamless SR Problem Statement        February 2021

      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 August 26, 2021               [Page 12]
Internet-Draft        Seamless SR Problem Statement        February 2021

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 August 26, 2021               [Page 13]
Internet-Draft        Seamless SR Problem Statement        February 2021

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 August 26, 2021               [Page 14]
Internet-Draft        Seamless SR Problem Statement        February 2021

   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 August 26, 2021               [Page 15]
Internet-Draft        Seamless SR Problem Statement        February 2021

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 August 26, 2021               [Page 16]
Internet-Draft        Seamless SR Problem Statement        February 2021

      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 August 26, 2021               [Page 17]
Internet-Draft        Seamless SR Problem Statement        February 2021

      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 August 26, 2021               [Page 18]
Internet-Draft        Seamless SR Problem Statement        February 2021

      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 August 26, 2021               [Page 19]
Internet-Draft        Seamless SR Problem Statement        February 2021

      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 S. Peng, "Egress Protection for
              Segment Routing (SR) networks", draft-hegde-rtgwg-egress-
              protection-sr-networks-01 (work in progress), November
              2020.

   [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 August 26, 2021               [Page 20]
Internet-Draft        Seamless SR Problem Statement        February 2021

   [I-D.kaliraj-idr-bgp-classful-transport-planes]
              Vairavakkalai, K., Venkataraman, N., Rajagopalan, B.,
              Mishra, G., Khaddam, M., and X. Xu, "BGP Classful
              Transport Planes", draft-kaliraj-idr-bgp-classful-
              transport-planes-06 (work in progress), January 2021.

   [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.,
              Rosen, E., Jain, D., and S. Lin, "Advertising Segment
              Routing Policies in BGP", draft-ietf-idr-segment-routing-
              te-policy-11 (work in progress), November 2020.

Hegde, et al.            Expires August 26, 2021               [Page 21]
Internet-Draft        Seamless SR Problem Statement        February 2021

   [I-D.ietf-idr-tunnel-encaps]
              Patel, K., Velde, G., Sangli, S., and J. Scudder, "The BGP
              Tunnel Encapsulation Attribute", draft-ietf-idr-tunnel-
              encaps-21 (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-13 (work in progress), October 2020.

   [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-02 (work in progress), January 2021.

   [I-D.ietf-rtgwg-segment-routing-ti-lfa]
              Litkowski, S., Bashandy, A., Filsfils, C., Decraene, B.,
              and D. Voyer, "Topology Independent Fast Reroute using
              Segment Routing", draft-ietf-rtgwg-segment-routing-ti-
              lfa-05 (work in progress), November 2020.

   [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-09 (work in progress),
              November 2020.

   [I-D.ietf-spring-sr-service-programming]
              Clad, F., Xu, X., Filsfils, C., daniel.bernier@bell.ca,
              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-03 (work in progress), September 2020.

   [I-D.ietf-spring-srv6-network-programming]
              Filsfils, C., Camarillo, P., Leddy, J., Voyer, D.,
              Matsushima, S., and Z. Li, "SRv6 Network Programming",
              draft-ietf-spring-srv6-network-programming-28 (work in
              progress), December 2020.

Hegde, et al.            Expires August 26, 2021               [Page 22]
Internet-Draft        Seamless SR Problem Statement        February 2021

   [I-D.saad-sr-fa-link]
              Saad, T., Beeram, V., Barth, C., and S. Sivabalan,
              "Segment-Routing over Forwarding Adjacency Links", draft-
              saad-sr-fa-link-02 (work in progress), July 2020.

   [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 August 26, 2021               [Page 23]
Internet-Draft        Seamless SR Problem Statement        February 2021

   [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 August 26, 2021               [Page 24]
Internet-Draft        Seamless SR Problem Statement        February 2021

   [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
   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

Hegde, et al.            Expires August 26, 2021               [Page 25]
Internet-Draft        Seamless SR Problem Statement        February 2021

   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 August 26, 2021               [Page 26]