< draft-filsfils-spring-large-scale-interconnect-13.txt   rfc8604.txt 
Network Working Group C. Filsfils, Ed. Independent Submission C. Filsfils, Ed.
Internet-Draft S. Previdi Request for Comments: 8604 Cisco Systems, Inc.
Intended status: Informational Cisco Systems, Inc. Category: Informational S. Previdi
Expires: September 6, 2019 G. Dawra, Ed. ISSN: 2070-1721 Huawei Technologies
G. Dawra, Ed.
LinkedIn LinkedIn
W. Henderickx W. Henderickx
Nokia Nokia
D. Cooper D. Cooper
Level 3 CenturyLink
March 5, 2019 June 2019
Interconnecting Millions Of Endpoints With Segment Routing Interconnecting Millions of Endpoints with Segment Routing
draft-filsfils-spring-large-scale-interconnect-13
Abstract Abstract
This document describes an application of Segment Routing to scale This document describes an application of Segment Routing to scale
the network to support hundreds of thousands of network nodes, and the network to support hundreds of thousands of network nodes, and
tens of millions of physical underlay endpoints. This use-case can tens of millions of physical underlay endpoints. This use case can
be applied to the interconnection of massive-scale DCs and/or large be applied to the interconnection of massive-scale Data Centers (DCs)
aggregation networks. Forwarding tables of midpoint and leaf nodes and/or large aggregation networks. Forwarding tables of midpoint and
only require a few tens of thousands of entries. This may be leaf nodes only require a few tens of thousands of entries. This may
achieved by inherert scaleable nature of Segment Routing and designed be achieved by the inherently scaleable nature of Segment Routing and
proposed in this document. the design proposed in this document.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This document is not an Internet Standards Track specification; it is
provisions of BCP 78 and BCP 79. published for informational purposes.
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 This is a contribution to the RFC Series, independently of any other
and may be updated, replaced, or obsoleted by other documents at any RFC stream. The RFC Editor has chosen to publish this document at
time. It is inappropriate to use Internet-Drafts as reference its discretion and makes no statement about its value for
material or to cite them other than as "work in progress." implementation or deployment. Documents approved for publication by
the RFC Editor are not candidates for any level of Internet Standard;
see Section 2 of RFC 7841.
This Internet-Draft will expire on September 6, 2019. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
https://www.rfc-editor.org/info/rfc8604.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document.
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 Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction ....................................................3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Terminology .....................................................3
3. Reference Design . . . . . . . . . . . . . . . . . . . . . . 3 3. Reference Design ................................................3
4. Control Plane . . . . . . . . . . . . . . . . . . . . . . . . 4 4. Control Plane ...................................................5
5. Illustration of the scale . . . . . . . . . . . . . . . . . . 5 5. Illustration of the Scale .......................................5
6. Design Options . . . . . . . . . . . . . . . . . . . . . . . 6 6. Design Options ..................................................6
6.1. Segment Routing Global Block(SRGB) Size . . . . . . . . . 6 6.1. Segment Routing Global Block (SRGB) Size ...................6
6.2. Redistribution of Agg nodes routes . . . . . . . . . . . 6 6.2. Redistribution of Routes for Agg Nodes .....................7
6.3. Sizing and hierarchy . . . . . . . . . . . . . . . . . . 6 6.3. Sizing and Hierarchy .......................................7
6.4. Local Segments to Hosts/Servers . . . . . . . . . . . . . 7 6.4. Local Segments to Hosts/Servers ............................7
6.5. Compressed SRTE policies . . . . . . . . . . . . . . . . 7 6.5. Compressed SRTE Policies ...................................7
7. Deployment Model . . . . . . . . . . . . . . . . . . . . . . 7 7. Deployment Model ................................................8
8. Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . 8 8. Benefits ........................................................8
8.1. Simplified operations . . . . . . . . . . . . . . . . . . 8 8.1. Simplified Operations ......................................8
8.2. Inter-domain SLA . . . . . . . . . . . . . . . . . . . . 8 8.2. Inter-domain SLAs ..........................................8
8.3. Scale . . . . . . . . . . . . . . . . . . . . . . . . . . 8 8.3. Scale ......................................................9
8.4. ECMP . . . . . . . . . . . . . . . . . . . . . . . . . . 8 8.4. ECMP .......................................................9
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 9. IANA Considerations .............................................9
10. Manageability Considerations . . . . . . . . . . . . . . . . 9 10. Manageability Considerations ...................................9
11. Security Considerations . . . . . . . . . . . . . . . . . . . 9 11. Security Considerations ........................................9
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 12. Informative References .........................................9
13. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 9 Acknowledgements ..................................................10
14. Informative References . . . . . . . . . . . . . . . . . . . 10 Contributors ......................................................10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 Authors' Addresses ................................................11
1. Introduction 1. Introduction
This document describes how SR can be used to interconnect millions This document describes how Segment Routing (SR) can be used to
of endpoints.The following terminology is used in this document: interconnect millions of endpoints.
2. Terminology 2. Terminology
The following terms and abbreviations are used in this document: The following terms and abbreviations are used in this document:
Term Definition Term Definition
--------------------------------------------------------- -------------------------------------------------------------
Agg Aggregation Agg Aggregation
BGP Border Gateway Protocol BGP Border Gateway Protocol
DC Data Center DC Data Center
DCI Data Center Interconnect DCI Data Center Interconnect
ECMP Equal Cost MultiPathing ECMP Equal-Cost Multipath
FIB Forwarding Information Base FIB Forwarding Information Base
LDP Label Distribution Protocol LDP Label Distribution Protocol
LFIB Label Forwarding Information Base LFIB Label Forwarding Information Base
MPLS Multi-Protocol Label Switching MPLS Multiprotocol Label Switching
PCE Path Computation Element PCE Path Computation Element
PCEP Path Computation Element Protocol PCEP Path Computation Element Communication Protocol
PW Pseudowire PW Pseudowire
SLA Service level Agreement SLA Service Level Agreement
SR Segment Routing SR Segment Routing
SRTE Policy Segment Routing Traffic Engineering Policy SRTE Policy Segment Routing Traffic Engineering Policy
TE Traffic Engineering TE Traffic Engineering
TI-LFA Topology Independent - Loop Free Alternative TI-LFA Topology Independent Loop-Free Alternate
3. Reference Design 3. Reference Design
The network diagram here below describes the reference network The network diagram below illustrates the reference network topology
topology used in this document: used in this document:
+-------+ +--------+ +--------+ +-------+ +-------+ +-------+ +--------+ +--------+ +-------+ +-------+
A DCI1 Agg1 Agg3 DCI3 Z A DCI1 Agg1 Agg3 DCI3 Z
| DC1 | | M1 | | C | | M2 | | DC2 | | DC1 | | M1 | | C | | M2 | | DC2 |
| DCI2 Agg2 Agg4 DCI4 | | DCI2 Agg2 Agg4 DCI4 |
+-------+ +--------+ +--------+ +-------+ +-------+ +-------+ +--------+ +--------+ +-------+ +-------+
Figure 1: Reference Topology Figure 1: Reference Topology
The following applies to the reference topology above: The following apply to the reference topology above:
Independent ISIS-OSPF/SR instance in core (C) region. o Independent ISIS-OSPF/SR instance in core (C) region.
Independent ISIS-OSPF/SR instance in Metro1 (M1) region. o Independent ISIS-OSPF/SR instance in Metro1 (M1) region.
Independent ISIS-OSPF/SR instance in Metro2 (M2) region. o Independent ISIS-OSPF/SR instance in Metro2 (M2) region.
BGP/SR in DC1. o BGP/SR in DC1.
BGP/SR in DC2. o BGP/SR in DC2.
Agg routes (Agg1, Agg2, Agg3, Agg4) are redistributed from C to M o Agg routes (Agg1, Agg2, Agg3, Agg4) are redistributed from C to M
(M1 and M2) and from M to DC domains. (M1 and M2) and from M to DC domains.
No other route is advertised or redistributed between regions. o No other route is advertised or redistributed between regions.
The same homogeneous SRGB is used throughout the domains (e.g. o The same homogeneous Segment Routing Global Block (SRGB) is used
16000-23999). throughout the domains (e.g., 16000-23999).
Unique SRGB sub-ranges are allocated to each metro (M) and core o Unique SRGB sub-ranges are allocated to each metro (M) and core
(C) domains: (C) domain:
16000-16999 range is allocated to the core (C) domain/region. * The 16000-16999 range is allocated to the core (C)
domain/region.
17000-17999 range is allocated to the M1 domain/region. * The 17000-17999 range is allocated to the M1 domain/region.
18000-18999 range is allocated to the M2 domain/region. * The 18000-18999 range is allocated to the M2 domain/region.
Specifically, Agg1 router has SID 16001 allocated and Agg2 * Specifically, the Agg1 router has Segment Identifier (SID)
router has SID 16002 allocated. 16001 allocated, and the Agg2 router has SID 16002 allocated.
Specifically, Agg3 router has SID 16003 allocated and the * Specifically, the Agg3 router has SID 16003 allocated, and the
anycast SID for Agg3 and Agg4 is 16006. anycast SID for Agg3 and Agg4 is 16006.
Specifically, DCI3 router has SID 18003 allocated and the * Specifically, the DCI3 router has SID 18003 allocated, and the
anycast SID for DCI3 and DCI4 is 18006. anycast SID for DCI3 and DCI4 is 18006.
Specifically, at Agg1 router Binding SID 4001 leads to DCI Pair * Specifically, at the Agg1 router, the binding SID 4001 leads to
DCI3, DCI4 via specific low-latency path {16002, 16003, 18006}. DCI pair (DCI3, DCI4) via a specific low-latency path {16002,
16003, 18006}.
The same SRGB sub-range is re-used within each DC (DC1 and DC2) o The same SRGB sub-range is reused within each DC (DC1 and DC2)
region. for each DC: e.g. 20000-23999. Specifically, nodes A and region for each DC (e.g., 20000-23999). Specifically, nodes A
Z both have SID 20001 allocated to them. and Z both have SID 20001 allocated to them.
4. Control Plane 4. Control Plane
This section provides a high-level description of a how a control This section provides a high-level description of how a control plane
plane could be implemented using protocol components already defined could be implemented using protocol components already defined in
in other RFCs. other RFCs.
The mechanism through which SRTE Policies are defined, computed and The mechanism through which SRTE Policies are defined, computed, and
programmed in the source nodes, are outside the scope of this programmed in the source nodes is outside the scope of this document.
document.
Typically, a controller or a service orchestration system programs Typically, a controller or a service orchestration system programs
node A with a pseudowire (PW) to a remote next-hop Z with a given SLA node A with a PW to a remote next-hop node Z with a given SLA
contract (e.g. low-latency path, be disjoint from a specific core contract (e.g., low-latency path, disjointness from a specific core
plane, be disjoint from a different PW service, etc.). plane, disjointness from a different PW service).
Node A automatically detects that it does not have reachability to Z. Node A automatically detects that node Z is not reachable. It then
It then automatically sends a PCEP request to an SR PCE for an SRTE automatically sends a PCEP request to an SR PCE for an SRTE policy
policy that provides reachability to Z with the requested SLA. that provides reachability information for node Z with the
requested SLA.
The SR PCE [RFC4655] is made of two components. A multi-domain The SR PCE [RFC4655] is made of two components: a multi-domain
topology and a computation engine. The multi-domain topology is topology and a computation engine. The multi-domain topology is
continuously refreshed through BGP-LS [RFC7752] feeds from each continuously refreshed through BGP - Link State (BGP-LS) feeds
domain. The computing engine is desined to implemet Traffic [RFC7752] from each domain. The computation engine is designed to
Engineering (TE) algorithms and provide output in SR Path format. implement TE algorithms and provide output in SR Path format. Upon
Upon receiving the PCEP [RFC5440] request, the SR PCE computes the receiving the PCEP request [RFC5440], the SR PCE computes the
requested path. The path is expressed through a list of segments requested path. The path is expressed through a list of segments
(e.g. {16003, 18006, 20001} and provided to node A. (e.g., {16003, 18006, 20001}) and provided to node A.
The SR PCE logs the request as a stateful query and hence is capable The SR PCE logs the request as a stateful query and hence is able to
to recompute the path at each network topology change. recompute the path at each network topology change.
Node A receives the PCEP reply with the path (expressed as a segment Node A receives the PCEP reply with the path (expressed as a segment
list). Node A installs the received SRTE policy in the dataplane. list). Node A installs the received SRTE policy in the data plane.
Node A then automatically steers the PW into that SRTE policy. Node A then automatically steers the PW into that SRTE policy.
5. Illustration of the scale 5. Illustration of the Scale
According to the reference topology described in Figure 1 the According to the reference topology shown in Figure 1, the following
following assumptions are made: assumptions are made:
There's 1 core domain and 100 leaf (metro) domains. o There is one core domain, and there are 100 leaf (metro) domains.
The core domain includes 200 nodes. o The core domain includes 200 nodes.
Two nodes connect each leaf (metro) domain. Each node connecting o Two nodes connect each leaf (metro) domain. Each node connecting
a leaf domain has a SID allocated. Each pair of nodes connecting a leaf domain has a SID allocated. Each pair of nodes connecting
a leaf domain also has a common anycast SID. This brings up to a leaf domain also has a common anycast SID. This yields up to
300 prefix segments in total. 300 prefix segments in total.
A core node connects only one leaf domain. o A core node connects only one leaf domain.
Each leaf domain has 6000 leaf node segments. Each leaf-node has o Each leaf domain has 6,000 leaf-node segments. Each leaf node has
500 endpoints attached, thus 500 adjacency segments. In total, it 500 endpoints attached and thus 500 adjacency segments. This
is 3 millions endpoints for a leaf domain. yields a total of 3 million endpoints for a leaf domain.
Based on the above, the network scaling numbers are as follows: Based on the above, the network scaling numbers are as follows:
6,000 leaf node segments multiplied by 100 leaf domains: 600,000 o 6,000 leaf-node segments multiplied by 100 leaf domains:
nodes. 600,000 nodes.
600,000 nodes multiplied by 500 endpoints: 300 millions of o 600,000 nodes multiplied by 500 endpoints: 300 million endpoints.
endpoints.
The node scaling numbers are as follows: The node scaling numbers are as follows:
Leaf node segment scale: 6,000 leaf node segments + 300 core node o Leaf-node segment scale: 6,000 leaf-node segments + 300 core-node
segments + 500 adjacency segments = 6,800 segments segments + 500 adjacency segments = 6,800 segments.
Core node segment scale: 6,000 leaf domain segments + 300 core
domain segments = 6,300 segments
In the above calculations, the link adjacency segments are not taken o Core-node segment scale: 6,000 leaf-domain segments +
300 core-domain segments = 6,300 segments.
In the above calculations, the link-adjacency segments are not taken
into account. These are local segments and, typically, less than 100 into account. These are local segments and, typically, less than 100
per node. per node.
It has to be noted that, depending on leaf node FIB capabilities, It has to be noted that, depending on leaf-node FIB capabilities,
leaf domains could be split into multiple smaller domains. In the leaf domains could be split into multiple smaller domains. In the
above example, the leaf domains could be split into 6 smaller domains above example, the leaf domains could be split into six smaller
so that each leaf node only need to learn 1000 leaf node segments + domains so that each leaf node only needs to learn 1,000 leaf-node
300 core node segments + 500 adjacency segments which gives a total segments + 300 core-node segments + 500 adjacency segments, yielding
of 1,800 segments. a total of 1,800 segments.
6. Design Options 6. Design Options
This section describes multiple design options to the illustration of This section describes multiple design options to illustrate scale as
previous section. described in the previous section.
6.1. Segment Routing Global Block(SRGB) Size 6.1. Segment Routing Global Block (SRGB) Size
In the simplified illustrations of this document, we picked a small In the simplified illustrations in this document, we picked a small
homogeneous SRGB range of 16000-23999. In practice, a large-scale homogeneous SRGB range of 16000-23999. In practice, a large-scale
design would use a bigger range such as 16000-80000, or even larger. design would use a bigger range, such as 16000-80000 or even larger.
Larger range provides allocations for various Traffic Engineering A larger range provides allocations for various TE applications
applications within a given domain within a given domain.
6.2. Redistribution of Agg nodes routes 6.2. Redistribution of Routes for Agg Nodes
The operator might choose to not redistribute the Agg nodes routes The operator might choose to not redistribute the routes for Agg
into the Metro/DC domains. In that case, more segments are required nodes into the Metro/DC domains. In that case, more segments are
in order to express an inter-domain path. required in order to express an inter-domain path.
For example, node A would use an SRTE Policy {DCI1, Agg1, Agg3, DCI3, For example, node A would use an SRTE Policy {DCI1, Agg1, Agg3,
Z} in order to reach Z instead of {Agg3, DCI3, Z} in the reference DCI3, Z} in order to reach Z instead of {Agg3, DCI3, Z} in the
design. reference design.
6.3. Sizing and hierarchy 6.3. Sizing and Hierarchy
The operator is free to choose among a small number of larger leaf The operator is free to choose among a small number of larger leaf
domains, a large number of small leaf domains or a mix of small and domains, a large number of small leaf domains, or a mix of small and
large core/leaf domains. large core/leaf domains.
The operator is free to use a 2-tier design (Core/Metro) or a 3-tier The operator is free to use a two-tier (Core/Metro) or three-tier
(Core/Metro/DC). (Core/Metro/DC) design.
6.4. Local Segments to Hosts/Servers 6.4. Local Segments to Hosts/Servers
Local segments can be programmed at any leaf node (e.g. node Z) in Local segments can be programmed at any leaf node (e.g., node Z) in
order to identify locally-attached hosts (or VM's). For example, if order to identify locally attached hosts (or Virtual Machines (VMs)).
node Z has bound a local segment 40001 to a local host ZH1, then node For example, if node Z has bound a local segment 40001 to a local
A uses the following SRTE Policy in order to reach that host: {16006, host ZH1, then node A uses the following SRTE Policy in order to
18006, 20001, 40001}. Such local segment could represent the NID reach that host: {16006, 18006, 20001, 40001}. Such a local segment
(Network Interface Device) in the context of the SP access network, could represent the NID (Network Interface Device) in the context of
or VM in the context of the DC network. the service provider access network, or a VM in the context of the DC
network.
6.5. Compressed SRTE policies 6.5. Compressed SRTE Policies
As an example and according to Section 3, we assume node A can reach As an example and according to Section 3, we assume that node A can
node Z (e.g., with a low-latency SLA contract) via the SRTE policy reach node Z (e.g., with a low-latency SLA contract) via the SRTE
consisting of the path: Agg1, Agg2, Agg3, DCI3/4(anycast), Z. The policy that consists of the path Agg1, Agg2, Agg3, DCI3/4(anycast),
path is represented by the segment list: {16001, 16002, 16003, 18006, Z. The path is represented by the segment list {16001, 16002, 16003,
20001}. 18006, 20001}.
It is clear that the control-plane solution can install an SRTE It is clear that the control-plane solution can install an SRTE
Policy {16002, 16003, 18006} at Agg1, collect the Binding SID Policy {16002, 16003, 18006} at Agg1, collect the binding SID
allocated by Agg1 to that policy (e.g. 4001) and hence program node A allocated by Agg1 to that policy (e.g., 4001), and hence program
with the compressed SRTE Policy {16001, 4001, 20001}. node A with the compressed SRTE Policy {16001, 4001, 20001}.
From node A, 16001 leads to Agg1. Once at Agg1, 4001 leads to the From node A, 16001 leads to Agg1. Once at Agg1, 4001 leads to the
DCI pair (DCI3, DCI4) via a specific low-latency path {16002, 16003, DCI pair (DCI3, DCI4) via a specific low-latency path {16002, 16003,
18006}. Once at that DCI pair, 20001 leads to Z. 18006}. Once at that DCI pair, 20001 leads to Z.
Binding SID's allocated to "intermediate" SRTE Policies allow to Binding SIDs allocated to "intermediate" SRTE Policies achieve the
compress end-to-end SRTE Policies. compression of end-to-end SRTE Policies.
The segment list {16001, 4001, 20001} expresses the same path as The segment list {16001, 4001, 20001} expresses the same path as
{16001, 16002, 16003, 18006, 20001} but with 2 less segments. {16001, 16002, 16003, 18006, 20001} but with two less segments.
The Binding SID also provides for an inherent churn protection. The binding SID also provides for inherent churn protection.
When the core topology changes, the control-plane can update the low- When the core topology changes, the control plane can update the
latency SRTE Policy from Agg1 to the DCI pair to DC2 without updating low-latency SRTE Policy from Agg1 to the DCI pair to DC2 without
the SRTE Policy from A to Z. updating the SRTE Policy from A to Z.
7. Deployment Model 7. Deployment Model
It is expected that this design be deployed as a green field but as It is expected that this design will be used in "green field"
well in interworking (brown field) with MPLS design across multiple deployments as well as interworking ("brown field") deployments with
domains. an MPLS design across multiple domains.
8. Benefits 8. Benefits
The design options illustrated in this document allow the The design options illustrated in this document allow
interconnection on a very large scale. Millions of endpoints across interconnections on a very large scale. Millions of endpoints across
different domains can be interconnected. different domains can be interconnected.
8.1. Simplified operations 8.1. Simplified Operations
Two protocols are not needed in this design: LDP and RSVP-TE. No new Two control-plane protocols not needed in this design are LDP and
protocol has been introduced. The design leverages the core IP RSVP-TE. No new protocol has been introduced. The design leverages
protocols: ISIS, OSPF, BGP, PCEP with straightforward SR extensions. the core IP protocols ISIS, OSPF, BGP, and PCEP with straightforward
SR extensions.
8.2. Inter-domain SLA 8.2. Inter-domain SLAs
Fast reroute and resiliency is provided by TI-LFA with sub-50msec FRR Fast reroute and resiliency are provided by TI-LFA with sub-50-ms
upon Link/Node/SRLG failure. TI-LFA is described in fast reroute upon failure of a link, node, or Shared Risk Link Group
[I-D.bashandy-rtgwg-segment-routing-ti-lfa]. (SRLG). TI-LFA is described in [SR-TI-LFA].
The use of anycast SIDs also provides an improvement in availability The use of anycast SIDs also provides improved availability and
and resiliency. resiliency.
Inter-domain SLA's can be delivered, e.g., latency vs. cost optimized Inter-domain SLAs can be delivered (e.g., latency vs. cost-optimized
path, disjointness from backbone planes, disjointness from other paths, disjointness from backbone planes, disjointness from other
services, disjointness between primary and backup paths. services, disjointness between primary and backup paths).
Existing inter-domain solutions do not provide any support for SLA Existing inter-domain solutions do not provide any support for SLA
contracts. They just provide a best-effort reachability across contracts. They just provide best-effort reachability across
domains. domains.
8.3. Scale 8.3. Scale
In addition to having eliminated two control plane protocols, per- In addition to having eliminated the need for LDP and RSVP-TE,
service midpoint states have also been removed from the network. per-service midpoint states have also been removed from the network.
8.4. ECMP 8.4. ECMP
Each policy (intra or inter-domain, with or without TE) is expressed Each policy (intra-domain or inter-domain, with or without TE) is
as a list of segments. Since each segment is optimized for ECMP, expressed as a list of segments. Since each segment is optimized for
then the entire policy is optimized for ECMP. The ECMP gain of ECMP, the entire policy is optimized for ECMP. The benefit of an
anycast prefix segment should also be considered (e.g. 16001 load- anycast prefix segment optimized for ECMP should also be considered
shares across any gateway from M1 leaf domain to Core and 16002 load- (e.g., 16001 load-shares across any gateway from the M1 leaf domain
shares across any gateway from Core to M1 leaf domain). to the Core and 16002 load-shares across any gateway from the Core to
the M1 leaf domain).
9. IANA Considerations 9. IANA Considerations
This document does not make any IANA request. This document has no IANA actions.
10. Manageability Considerations 10. Manageability Considerations
This document describes an application of Segment Routing over the This document describes an application of SR over the MPLS data
MPLS data plane. Segment Routing does not introduce any change in plane. SR does not introduce any changes in the MPLS data plane.
the MPLS data plane. Manageability considerations described in The manageability considerations described in [RFC8402] apply to the
[RFC8402] apply to the MPLS data plane when used with Segment MPLS data plane when used with SR.
Routing.
11. Security Considerations 11. Security Considerations
This document does not introduce additional security requirements and This document does not introduce additional security requirements and
mechanisms other than the ones described in [RFC8402]. mechanisms other than those described in [RFC8402].
12. Acknowledgements 12. Informative References
We would like to thank Giles Heron, Alexander Preusche, Steve Braaten [RFC4655] Farrel, A., Vasseur, J.-P., and J. Ash, "A Path
and Francis Ferguson for their contribution to the content of this Computation Element (PCE)-Based Architecture", RFC 4655,
document. DOI 10.17487/RFC4655, August 2006,
<https://www.rfc-editor.org/info/rfc4655>.
13. Contributors [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation
Element (PCE) Communication Protocol (PCEP)", RFC 5440,
DOI 10.17487/RFC5440, March 2009,
<https://www.rfc-editor.org/info/rfc5440>.
The following people have substantially contributed to the editing of [RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and
this document: S. Ray, "North-Bound Distribution of Link-State and
Traffic Engineering (TE) Information Using BGP", RFC 7752,
DOI 10.17487/RFC7752, March 2016,
<https://www.rfc-editor.org/info/rfc7752>.
[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>.
[SR-TI-LFA]
Litkowski, S., Bashandy, A., Filsfils, C.,
Decraene, B., Francois, P., Voyer, D., Clad, F., and
P. Camarillo, "Topology Independent Fast Reroute
using Segment Routing", Work in Progress,
draft-ietf-rtgwg-segment-routing-ti-lfa-01, March 2019.
Acknowledgements
We would like to thank Giles Heron, Alexander Preusche, Steve
Braaten, and Francis Ferguson for their contributions to the content
of this document.
Contributors
The following people substantially contributed to the editing of this
document:
Dennis Cai Dennis Cai
Individual Individual
Tim Laberge Tim Laberge
Individual Individual
Steven Lin Steven Lin
Google Inc. Google Inc.
Steven Lin
Google Inc.
Bruno Decraene Bruno Decraene
Orange Orange
Luay Jalil Luay Jalil
Verizon Verizon
Jeff Tantsura Jeff Tantsura
Individual Individual
Rob Shakir Rob Shakir
Google Google Inc.
14. Informative References
[I-D.bashandy-rtgwg-segment-routing-ti-lfa]
Bashandy, A., Filsfils, C., Decraene, B., Litkowski, S.,
Francois, P., daniel.voyer@bell.ca, d., Clad, F., and P.
Camarillo, "Topology Independent Fast Reroute using
Segment Routing", draft-bashandy-rtgwg-segment-routing-ti-
lfa-05 (work in progress), October 2018.
[RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation
Element (PCE)-Based Architecture", RFC 4655,
DOI 10.17487/RFC4655, August 2006,
<https://www.rfc-editor.org/info/rfc4655>.
[RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation
Element (PCE) Communication Protocol (PCEP)", RFC 5440,
DOI 10.17487/RFC5440, March 2009,
<https://www.rfc-editor.org/info/rfc5440>.
[RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and
S. Ray, "North-Bound Distribution of Link-State and
Traffic Engineering (TE) Information Using BGP", RFC 7752,
DOI 10.17487/RFC7752, March 2016,
<https://www.rfc-editor.org/info/rfc7752>.
[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>.
Authors' Addresses Authors' Addresses
Clarence Filsfils (editor) Clarence Filsfils (editor)
Cisco Systems, Inc. Cisco Systems, Inc.
Brussels Brussels
Belgium Belgium
Email: cfilsfil@cisco.com Email: cfilsfil@cisco.com
Stefano Previdi Stefano Previdi
Cisco Systems, Inc. Huawei Technologies
Via Del Serafico, 200
Rome 00142
Italy
Email: stefano@previdi.net Email: stefano@previdi.net
Gaurav Dawra (editor) Gaurav Dawra (editor)
LinkedIn LinkedIn
USA United States of America
Email: gdawra.ietf@gmail.com Email: gdawra.ietf@gmail.com
Wim Henderickx Wim Henderickx
Nokia Nokia
Copernicuslaan 50 Copernicuslaan 50
Antwerp 2018 Antwerp 2018
Belgium Belgium
Email: wim.henderickx@nokia.com Email: wim.henderickx@nokia.com
Dave Cooper Dave Cooper
Level 3 CenturyLink
Email: Dave.Cooper@Level3.com Email: Dave.Cooper@centurylink.com
 End of changes. 98 change blocks. 
275 lines changed or deleted 270 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/