draft-ietf-spring-segment-routing-msdc-10.txt   draft-ietf-spring-segment-routing-msdc-11.txt 
Network Working Group C. Filsfils, Ed. Network Working Group C. Filsfils, Ed.
Internet-Draft S. Previdi Internet-Draft S. Previdi
Intended status: Informational Cisco Systems, Inc. Intended status: Informational Cisco Systems, Inc.
Expires: April 18, 2019 G. Dawra Expires: June 2, 2019 G. Dawra
LinkedIn LinkedIn
E. Aries E. Aries
Juniper Networks Juniper Networks
P. Lapukhov P. Lapukhov
Facebook Facebook
October 15, 2018 November 29, 2018
BGP-Prefix Segment in large-scale data centers BGP-Prefix Segment in large-scale data centers
draft-ietf-spring-segment-routing-msdc-10 draft-ietf-spring-segment-routing-msdc-11
Abstract Abstract
This document describes the motivation and benefits for applying This document describes the motivation and benefits for applying
segment routing in BGP-based large-scale data-centers. It describes segment routing in BGP-based large-scale data-centers. It describes
the design to deploy segment routing in those data-centers, for both the design to deploy segment routing in those data-centers, for both
the MPLS and IPv6 dataplanes. the MPLS and IPv6 dataplanes.
Status of This Memo Status of This Memo
skipping to change at page 1, line 39 skipping to change at page 1, line 39
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 18, 2019. This Internet-Draft will expire on June 2, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 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
skipping to change at page 2, line 27 skipping to change at page 2, line 27
4.1. BGP Prefix Segment (BGP-Prefix-SID) . . . . . . . . . . . 6 4.1. BGP Prefix Segment (BGP-Prefix-SID) . . . . . . . . . . . 6
4.2. eBGP Labeled Unicast (RFC8277) . . . . . . . . . . . . . 6 4.2. eBGP Labeled Unicast (RFC8277) . . . . . . . . . . . . . 6
4.2.1. Control Plane . . . . . . . . . . . . . . . . . . . . 7 4.2.1. Control Plane . . . . . . . . . . . . . . . . . . . . 7
4.2.2. Data Plane . . . . . . . . . . . . . . . . . . . . . 8 4.2.2. Data Plane . . . . . . . . . . . . . . . . . . . . . 8
4.2.3. Network Design Variation . . . . . . . . . . . . . . 9 4.2.3. Network Design Variation . . . . . . . . . . . . . . 9
4.2.4. Global BGP Prefix Segment through the fabric . . . . 10 4.2.4. Global BGP Prefix Segment through the fabric . . . . 10
4.2.5. Incremental Deployments . . . . . . . . . . . . . . . 10 4.2.5. Incremental Deployments . . . . . . . . . . . . . . . 10
4.3. iBGP Labeled Unicast (RFC8277) . . . . . . . . . . . . . 11 4.3. iBGP Labeled Unicast (RFC8277) . . . . . . . . . . . . . 11
5. Applying Segment Routing in the DC with IPv6 dataplane . . . 13 5. Applying Segment Routing in the DC with IPv6 dataplane . . . 13
6. Communicating path information to the host . . . . . . . . . 13 6. Communicating path information to the host . . . . . . . . . 13
7. Addressing the open problems . . . . . . . . . . . . . . . . 14 7. Additional Benefits . . . . . . . . . . . . . . . . . . . . . 14
7.1. Per-packet and flowlet switching . . . . . . . . . . . . 14 7.1. MPLS Dataplane with operational simplicity . . . . . . . 14
7.2. Performance-aware routing . . . . . . . . . . . . . . . . 15 7.2. Minimizing the FIB table . . . . . . . . . . . . . . . . 14
7.3. Deterministic network probing . . . . . . . . . . . . . . 16 7.3. Egress Peer Engineering . . . . . . . . . . . . . . . . . 15
8. Additional Benefits . . . . . . . . . . . . . . . . . . . . . 17 7.4. Anycast . . . . . . . . . . . . . . . . . . . . . . . . . 15
8.1. MPLS Dataplane with operational simplicity . . . . . . . 17 8. Preferred SRGB Allocation . . . . . . . . . . . . . . . . . . 16
8.2. Minimizing the FIB table . . . . . . . . . . . . . . . . 17 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
8.3. Egress Peer Engineering . . . . . . . . . . . . . . . . . 17 10. Manageability Considerations . . . . . . . . . . . . . . . . 17
8.4. Anycast . . . . . . . . . . . . . . . . . . . . . . . . . 18 11. Security Considerations . . . . . . . . . . . . . . . . . . . 17
9. Preferred SRGB Allocation . . . . . . . . . . . . . . . . . . 18 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 18
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 13. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 18
11. Manageability Considerations . . . . . . . . . . . . . . . . 20 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 19
12. Security Considerations . . . . . . . . . . . . . . . . . . . 20 14.1. Normative References . . . . . . . . . . . . . . . . . . 19
13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 21 14.2. Informative References . . . . . . . . . . . . . . . . . 20
14. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 21 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20
15. References . . . . . . . . . . . . . . . . . . . . . . . . . 22
15.1. Normative References . . . . . . . . . . . . . . . . . . 22
15.2. Informative References . . . . . . . . . . . . . . . . . 23
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23
1. Introduction 1. Introduction
Segment Routing (SR), as described in Segment Routing (SR), as described in
[I-D.ietf-spring-segment-routing] leverages the source routing [I-D.ietf-spring-segment-routing] leverages the source routing
paradigm. A node steers a packet through an ordered list of paradigm. A node steers a packet through an ordered list of
instructions, called segments. A segment can represent any instructions, called segments. A segment can represent any
instruction, topological or service-based. A segment can have a instruction, topological or service-based. A segment can have a
local semantic to an SR node or global within an SR domain. SR local semantic to an SR node or global within an SR domain. SR
allows to enforce a flow through any topological path while allows to enforce a flow through any topological path while
skipping to change at page 5, line 50 skipping to change at page 5, line 50
o Isolating faults in the network with multiple parallel paths and o Isolating faults in the network with multiple parallel paths and
ECMP-based routing is non-trivial due to lack of determinism. ECMP-based routing is non-trivial due to lack of determinism.
Specifically, the connections from HostA to HostB may take a Specifically, the connections from HostA to HostB may take a
different path every time a new connection is formed, thus making different path every time a new connection is formed, thus making
consistent reproduction of a failure much more difficult. This consistent reproduction of a failure much more difficult. This
complexity scales linearly with the number of parallel paths in complexity scales linearly with the number of parallel paths in
the network, and stems from the random nature of path selection by the network, and stems from the random nature of path selection by
the network devices. the network devices.
Further in this document (Section 7), it is demonstrated how these
problems could be addressed within the framework of Segment Routing.
First, it will be explained how to apply SR in the DC, for MPLS and First, it will be explained how to apply SR in the DC, for MPLS and
IPv6 data-planes. IPv6 data-planes.
4. Applying Segment Routing in the DC with MPLS dataplane 4. Applying Segment Routing in the DC with MPLS dataplane
4.1. BGP Prefix Segment (BGP-Prefix-SID) 4.1. BGP Prefix Segment (BGP-Prefix-SID)
A BGP Prefix Segment is a segment associated with a BGP prefix. A A BGP Prefix Segment is a segment associated with a BGP prefix. A
BGP Prefix Segment is a network-wide instruction to forward the BGP Prefix Segment is a network-wide instruction to forward the
packet along the ECMP-aware best path to the related prefix. packet along the ECMP-aware best path to the related prefix.
The BGP Prefix Segment is defined as the BGP-Prefix-SID Attribute in The BGP Prefix Segment is defined as the BGP-Prefix-SID Attribute in
[I-D.ietf-idr-bgp-prefix-sid] which contains an index. Throughout [I-D.ietf-idr-bgp-prefix-sid] which contains an index. Throughout
this document the BGP Prefix Segment Attribute is referred as the this document the BGP Prefix Segment Attribute is referred as the
BGP-Prefix-SID and the encoded index as the label-index. BGP-Prefix-SID and the encoded index as the label-index.
In this document, the network design decision has been made to assume In this document, the network design decision has been made to assume
that all the nodes are allocated the same SRGB (Segment Routing that all the nodes are allocated the same SRGB (Segment Routing
Global Block), e.g. [16000, 23999]. This provides operational Global Block), e.g. [16000, 23999]. This provides operational
simplification as explained in Section 9, but this is not a simplification as explained in Section 8, but this is not a
requirement. requirement.
For illustration purpose, when considering an MPLS data-plane, it is For illustration purpose, when considering an MPLS data-plane, it is
assumed that the label-index allocated to prefix 192.0.2.x/32 is X. assumed that the label-index allocated to prefix 192.0.2.x/32 is X.
As a result, a local label (16000+x) is allocated for prefix As a result, a local label (16000+x) is allocated for prefix
192.0.2.x/32 by each node throughout the DC fabric. 192.0.2.x/32 by each node throughout the DC fabric.
When IPv6 data-plane is considered, it is assumed that Node X is When IPv6 data-plane is considered, it is assumed that Node X is
allocated IPv6 address (segment) 2001:DB8::X. allocated IPv6 address (segment) 2001:DB8::X.
skipping to change at page 14, line 21 skipping to change at page 14, line 21
It is also noted, that when disseminating network-related data to the It is also noted, that when disseminating network-related data to the
end-hosts a trade-off is made to balance the amount of information end-hosts a trade-off is made to balance the amount of information
Vs. the level of visibility in the network state. This applies both Vs. the level of visibility in the network state. This applies both
to push and pull models. In the extreme case, the host would request to push and pull models. In the extreme case, the host would request
path information on every flow, and keep no local state at all. On path information on every flow, and keep no local state at all. On
the other end of the spectrum, information for every prefix in the the other end of the spectrum, information for every prefix in the
network along with available paths could be pushed and continuously network along with available paths could be pushed and continuously
updated on all hosts. updated on all hosts.
7. Addressing the open problems 7. Additional Benefits
This section demonstrates how the problems described above (in
section 3) could be solved using the segment routing concept. It is
worth noting that segment routing signaling and data-plane are only
parts of the solution. Additional enhancements, e.g., such as the
centralized controller mentioned previously, and host networking
stack support are required to implement the proposed solutions. Also
the applicability of the solutions described below are not restricted
to the data-center alone, the same could be re-used in context of
other domains as well
7.1. Per-packet and flowlet switching
A flowlet is defined here as a burst of packets from the 5-tuple flow
followed by a significant idle interval for application to detect
path issues and re-steer the packet.
With some ability to choose paths on the host, one may go from per-
flow load-sharing in the network to possible per-packet or per-
flowlet. The host may select different segment routing instructions
either per packet, or per flowlet, and route them over different
paths. This allows for solving the problem of avoiding link
imbalances in the data-center.
Note that traditional ECMP routing could be easily simulated with on-
host path selection, using method proposed in [GREENBERG09]. The
hosts would randomly pick a Tier-2 or Tier-1 device to "bounce" the
packet off of, depending on whether the destination is under the same
Tier-2 nodes, or has to be reached across Tier-1. The host would use
a hash function that operates on per-flow invariants, to simulate
per-flow load-sharing in the network.
Using Figure 1 as reference, let us illustrate this concept assuming
that HostA has a flow to HostZ called Flow-f.
Normally, a flow is hashed on to a single path. Let's assume HostA
sends its packets associated with Flow-f with top label 16011 (the
label for the remote ToR, Node11, where HostZ is connected) and Node1
would hash all the packets of Flow-F via the same next-hop (e.g.
Node3). Similarly, let's assume that leaf Node3 would hash all the
packets of Flow-F via the same next-hop (e.g.: spine node Node5).
This normal operation would restrict the flow on a small subset of
the ECMP paths to HostZ and potentially create imbalance and
congestion in the fabric.
Leveraging the flowlet proposal, assuming HostA is made aware of 4
disjoint paths via intermediate segment 16005, 16006, 16007 and 16008
(the BGP prefix SID's of the 4 spine nodes) and also made aware of
the prefix segment of the remote ToR connected to the destination
(16011), then the application optimially uses the paths by sending
flowlets F1, F2, F3, F4 and associate each flowlet with one of the
following 4 label stacks: {16005, 16011}, {16006, 16011}, {16007,
16011} and {16008, 16011}. This would spread the load of the flow
through all the ECMP paths available in the fabric.
7.2. Performance-aware routing
Knowing the path associated with flows/packets, the end host may
leverage an external mechanism to deduce certain characteristics of
the path, and additionally use the information supplied with path
information pushed from the controller or received via pull request.
The host may further share its application observations with the
centralized agent, so that the latter may keep up-to-date network
health map to assist other hosts with this information.
For example, an application A.1 at HostA may pin a flow destined to
HostZ via Spine node Node5 using label stack {16005, 16011}. The
application A.1 may collect information on packet loss or other
metrics on a particular path using external mechanism. A.1 may also
look locally at the application performance information. The
application A.1 may additionally publish this information to a
centralized agent, e.g. after a flow completes, or periodically for
longer lived flows. Next, using both local and/or global performance
data, application A.1 as well as other applications sharing the same
resources in the DC fabric may pick up the best path for the new
flow, or update an existing path (e.g.: when informed of congestion
on an existing path). The mechanisms for collecting the flow
metrics, their publishing to a centralized agent and the decision
process at the centralized agent and the application/host to pick a
path through the network based on this collected information is
outside the scope of this document.
One particularly interesting instance of performance-aware routing is
dynamic fault-avoidance. If some links or devices in the network
start discarding packets due to a fault, the end-hosts may receive
updated information from controller, published by external mechanisms
and detect the path(s) that are affected and hence steer the affected
flows away from the problem spot. Similar logic applies to failure
cases where packets get completely black-holed, e.g., when a link
goes down and the failure is detected by the host while probing the
path.
For example, an application A.1 informed about 5 paths to Z {16005,
16011}, {16006, 16011}, {16007, 16011}, {16008, 16011} and {16011}
might use the last one by default (for simplicity). When performance
is degrading, A.1 might then start to pin flows to each of the 4
other paths (each via a distinct spine) and monitor the performance.
It would then detect the faulty path and assign a negative preference
to the faulty path to avoid further flows using it. Gradually, over
time, it may re-assign flows on the faulty path to eventually detect
the resolution of the trouble and start reusing the path. The
mechanisms for monitoring performance for a specific flow and for the
various paths and the deduction of optimal paths to improve the same
for the flow are outside the scope of this document.
By leveraging Segment Routing, one avoids issues associated with
oblivious ECMP hashing. For example, if in the topology depicted on
Figure 1 a link between spine node Node5 and leaf node Node9 fails,
HostA may exclude the segment corresponding to Node5 from the prefix
matching the servers under Tier-2 devices Node9. In the push path
discovery model, the affected path mappings may be explicitly pushed
to all the servers for the duration of the failure. The new mapping
would instruct them to avoid the particular Tier-1 node until the
link has recovered. Alternatively, in pull path, the centralized
controller may start steering new flows immediately after it
discovers the issue. Until then, the existing flows may recover
using local detection of the path issues.
7.3. Deterministic network probing
Active probing is a well-known technique for monitoring network
elements' health, constituting of sending continuous packet streams
simulating network traffic to the hosts in the data-center. Segment
routing makes possible to prescribe the exact paths that each probe
or series of probes would be taking toward their destination. This
allows for fast correlation and detection of failed paths, by
processing information from multiple actively probing agents. This
complements the data collected from the hosts routing stacks as
described in Section 7.2.
For example, imagine a probe agent sending packets to all machines in
the data-center. For every host, it may send packets over each of
the possible paths, knowing exactly which links and devices these
packets will be crossing. Correlating results for multiple
destinations with the topological data, it may automatically isolate
possible problem to a link or device in the network.
8. Additional Benefits
8.1. MPLS Dataplane with operational simplicity 7.1. MPLS Dataplane with operational simplicity
As required by [RFC7938], no new signaling protocol is introduced. As required by [RFC7938], no new signaling protocol is introduced.
The BGP-Prefix-SID is a lightweight extension to BGP Labeled Unicast The BGP-Prefix-SID is a lightweight extension to BGP Labeled Unicast
[RFC8277]. It applies either to eBGP or iBGP based designs. [RFC8277]. It applies either to eBGP or iBGP based designs.
Specifically, LDP and RSVP-TE are not used. These protocols would Specifically, LDP and RSVP-TE are not used. These protocols would
drastically impact the operational complexity of the Data Center and drastically impact the operational complexity of the Data Center and
would not scale. This is in line with the requirements expressed in would not scale. This is in line with the requirements expressed in
[RFC7938]. [RFC7938].
Provided the same SRGB is configured on all nodes, all nodes use the Provided the same SRGB is configured on all nodes, all nodes use the
same MPLS label for a given IP prefix. This is simpler from an same MPLS label for a given IP prefix. This is simpler from an
operation standpoint, as discussed in Section 9 operation standpoint, as discussed in Section 8
8.2. Minimizing the FIB table 7.2. Minimizing the FIB table
The designer may decide to switch all the traffic at Tier-1 and Tier- The designer may decide to switch all the traffic at Tier-1 and Tier-
2's based on MPLS, hence drastically decreasing the IP table size at 2's based on MPLS, hence drastically decreasing the IP table size at
these nodes. these nodes.
This is easily accomplished by encapsulating the traffic either This is easily accomplished by encapsulating the traffic either
directly at the host or the source ToR node by pushing the BGP- directly at the host or the source ToR node by pushing the BGP-
Prefix-SID of the destination ToR for intra-DC traffic, or the BGP- Prefix-SID of the destination ToR for intra-DC traffic, or the BGP-
Prefix-SID for the the border node for inter-DC or DC-to-outside- Prefix-SID for the the border node for inter-DC or DC-to-outside-
world traffic. world traffic.
8.3. Egress Peer Engineering 7.3. Egress Peer Engineering
It is straightforward to combine the design illustrated in this It is straightforward to combine the design illustrated in this
document with the Egress Peer Engineering (EPE) use-case described in document with the Egress Peer Engineering (EPE) use-case described in
[I-D.ietf-spring-segment-routing-central-epe]. [I-D.ietf-spring-segment-routing-central-epe].
In such case, the operator is able to engineer its outbound traffic In such case, the operator is able to engineer its outbound traffic
on a per host-flow basis, without incurring any additional state at on a per host-flow basis, without incurring any additional state at
intermediate points in the DC fabric. intermediate points in the DC fabric.
For example, the controller only needs to inject a per-flow state on For example, the controller only needs to inject a per-flow state on
skipping to change at page 18, line 31 skipping to change at page 15, line 37
border node Node12 to forward the packet to peer AS 9999, without any border node Node12 to forward the packet to peer AS 9999, without any
IP lookup at the border node. There is no per-flow state for this IP lookup at the border node. There is no per-flow state for this
engineered flow in the DC fabric. A benefit of segment routing is engineered flow in the DC fabric. A benefit of segment routing is
the per-flow state is only required at the source. the per-flow state is only required at the source.
As well as allowing full traffic engineering control such a design As well as allowing full traffic engineering control such a design
also offers FIB table minimization benefits as the Internet-scale FIB also offers FIB table minimization benefits as the Internet-scale FIB
at border node Node12 is not required if all FIB lookups are avoided at border node Node12 is not required if all FIB lookups are avoided
there by using EPE. there by using EPE.
8.4. Anycast 7.4. Anycast
The design presented in this document preserves the availability and The design presented in this document preserves the availability and
load-balancing properties of the base design presented in load-balancing properties of the base design presented in
[I-D.ietf-spring-segment-routing]. [I-D.ietf-spring-segment-routing].
For example, one could assign an anycast loopback 192.0.2.20/32 and For example, one could assign an anycast loopback 192.0.2.20/32 and
associate segment index 20 to it on the border Node11 and Node12 (in associate segment index 20 to it on the border Node11 and Node12 (in
addition to their node-specific loopbacks). Doing so, the EPE addition to their node-specific loopbacks). Doing so, the EPE
controller could express a default "go-to-the-Internet via any border controller could express a default "go-to-the-Internet via any border
node" policy as segment list {16020}. Indeed, from any host in the DC node" policy as segment list {16020}. Indeed, from any host in the DC
fabric or from any ToR node, 16020 steers the packet towards the fabric or from any ToR node, 16020 steers the packet towards the
border Node11 or Node12 leveraging ECMP where available along the border Node11 or Node12 leveraging ECMP where available along the
best paths to these nodes. best paths to these nodes.
9. Preferred SRGB Allocation 8. Preferred SRGB Allocation
In the MPLS case, it is recommend to use same SRGBs at each node. In the MPLS case, it is recommend to use same SRGBs at each node.
Different SRGBs in each node likely increase the complexity of the Different SRGBs in each node likely increase the complexity of the
solution both from an operational viewpoint and from a controller solution both from an operational viewpoint and from a controller
viewpoint. viewpoint.
From an operation viewpoint, it is much simpler to have the same From an operation viewpoint, it is much simpler to have the same
global label at every node for the same destination (the MPLS global label at every node for the same destination (the MPLS
troubleshooting is then similar to the IPv6 troubleshooting where troubleshooting is then similar to the IPv6 troubleshooting where
skipping to change at page 19, line 46 skipping to change at page 17, line 5
for FA1 while it would have to instruct B to use {2011} for FB1 for FA1 while it would have to instruct B to use {2011} for FB1
(while with the same SRGB, both policies are the same {16011}). (while with the same SRGB, both policies are the same {16011}).
Even worse, the controller would instruct A to use {1005, 5011} for Even worse, the controller would instruct A to use {1005, 5011} for
FA1 while it would instruct B to use {2011, 8011} for FB1 (while with FA1 while it would instruct B to use {2011, 8011} for FB1 (while with
the same SRGB, the second segment is the same across both policies: the same SRGB, the second segment is the same across both policies:
16011). When combining segments to create a policy, one need to 16011). When combining segments to create a policy, one need to
carefully update the label of each segment. This is obviously more carefully update the label of each segment. This is obviously more
error-prone, more complex and more difficult to troubleshoot. error-prone, more complex and more difficult to troubleshoot.
10. IANA Considerations 9. IANA Considerations
This document does not make any IANA request. This document does not make any IANA request.
11. Manageability Considerations 10. Manageability Considerations
The design and deployment guidelines described in this document are The design and deployment guidelines described in this document are
based on the network design described in [RFC7938]. based on the network design described in [RFC7938].
The deployment model assumed in this document is based on a single The deployment model assumed in this document is based on a single
domain where the interconnected DCs are part of the same domain where the interconnected DCs are part of the same
administrative domain (which, of course, is split into different administrative domain (which, of course, is split into different
autonomous systems). The operator has full control of the whole autonomous systems). The operator has full control of the whole
domain and the usual operational and management mechanisms and domain and the usual operational and management mechanisms and
procedures are used in order to prevent any information related to procedures are used in order to prevent any information related to
internal prefixes and topology to be leaked outside the domain. internal prefixes and topology to be leaked outside the domain.
As recommended in [I-D.ietf-spring-segment-routing], the same SRGB As recommended in [I-D.ietf-spring-segment-routing], the same SRGB
should be allocated in all nodes in order to facilitate the design, should be allocated in all nodes in order to facilitate the design,
deployment and operations of the domain. deployment and operations of the domain.
When EPE ([I-D.ietf-spring-segment-routing-central-epe]) is used (as When EPE ([I-D.ietf-spring-segment-routing-central-epe]) is used (as
explained in Section 8.3, the same operational model is assumed. EPE explained in Section 7.3, the same operational model is assumed. EPE
information is originated and propagated throughout the domain information is originated and propagated throughout the domain
towards an internal server and unless explicitly configured by the towards an internal server and unless explicitly configured by the
operator, no EPE information is leaked outside the domain boundaries. operator, no EPE information is leaked outside the domain boundaries.
12. Security Considerations 11. Security Considerations
This document proposes to apply Segment Routing to a well known This document proposes to apply Segment Routing to a well known
scalability requirement expressed in [RFC7938] using the BGP-Prefix- scalability requirement expressed in [RFC7938] using the BGP-Prefix-
SID as defined in [I-D.ietf-idr-bgp-prefix-sid]. SID as defined in [I-D.ietf-idr-bgp-prefix-sid].
It has to be noted, as described in Section 11 that the design It has to be noted, as described in Section 10 that the design
illustrated in [RFC7938] and in this document, refer to a deployment illustrated in [RFC7938] and in this document, refer to a deployment
model where all nodes are under the same administration. In this model where all nodes are under the same administration. In this
context, it is assumed that the operator doesn't want to leak outside context, it is assumed that the operator doesn't want to leak outside
of the domain any information related to internal prefixes and of the domain any information related to internal prefixes and
topology. The internal information includes prefix-sid and EPE topology. The internal information includes prefix-sid and EPE
information. In order to prevent such leaking, the standard BGP information. In order to prevent such leaking, the standard BGP
mechanisms (filters) are applied on the boundary of the domain. mechanisms (filters) are applied on the boundary of the domain.
Therefore, the solution proposed in this document does not introduce Therefore, the solution proposed in this document does not introduce
any additional security concerns from what expressed in [RFC7938] and any additional security concerns from what expressed in [RFC7938] and
[I-D.ietf-idr-bgp-prefix-sid]. It is assumed that the security and [I-D.ietf-idr-bgp-prefix-sid]. It is assumed that the security and
confidentiality of the prefix and topology information is preserved confidentiality of the prefix and topology information is preserved
by outbound filters at each peering point of the domain as described by outbound filters at each peering point of the domain as described
in Section 11. in Section 10.
13. Acknowledgements 12. Acknowledgements
The authors would like to thank Benjamin Black, Arjun Sreekantiah, The authors would like to thank Benjamin Black, Arjun Sreekantiah,
Keyur Patel, Acee Lindem and Anoop Ghanwani for their comments and Keyur Patel, Acee Lindem and Anoop Ghanwani for their comments and
review of this document. review of this document.
14. Contributors 13. Contributors
Gaya Nagarajan Gaya Nagarajan
Facebook Facebook
US US
Email: gaya@fb.com Email: gaya@fb.com
Gaurav Dawra Gaurav Dawra
Cisco Systems Cisco Systems
US US
skipping to change at page 22, line 22 skipping to change at page 19, line 22
US US
Email: raysaikat@gmail.com Email: raysaikat@gmail.com
Jon Mitchell Jon Mitchell
Unaffiliated Unaffiliated
US US
Email: jrmitche@puck.nether.net Email: jrmitche@puck.nether.net
15. References 14. References
15.1. Normative References 14.1. Normative References
[I-D.ietf-idr-bgp-prefix-sid] [I-D.ietf-idr-bgp-prefix-sid]
Previdi, S., Filsfils, C., Lindem, A., Sreekantiah, A., Previdi, S., Filsfils, C., Lindem, A., Sreekantiah, A.,
and H. Gredler, "Segment Routing Prefix SID extensions for and H. Gredler, "Segment Routing Prefix SID extensions for
BGP", draft-ietf-idr-bgp-prefix-sid-27 (work in progress), BGP", draft-ietf-idr-bgp-prefix-sid-27 (work in progress),
June 2018. June 2018.
[I-D.ietf-spring-segment-routing] [I-D.ietf-spring-segment-routing]
Filsfils, C., Previdi, S., Ginsberg, L., Decraene, B., Filsfils, C., Previdi, S., Ginsberg, L., Decraene, B.,
Litkowski, S., and R. Shakir, "Segment Routing Litkowski, S., and R. Shakir, "Segment Routing
skipping to change at page 23, line 19 skipping to change at page 20, line 19
[RFC7938] Lapukhov, P., Premji, A., and J. Mitchell, Ed., "Use of [RFC7938] Lapukhov, P., Premji, A., and J. Mitchell, Ed., "Use of
BGP for Routing in Large-Scale Data Centers", RFC 7938, BGP for Routing in Large-Scale Data Centers", RFC 7938,
DOI 10.17487/RFC7938, August 2016, DOI 10.17487/RFC7938, August 2016,
<https://www.rfc-editor.org/info/rfc7938>. <https://www.rfc-editor.org/info/rfc7938>.
[RFC8277] Rosen, E., "Using BGP to Bind MPLS Labels to Address [RFC8277] Rosen, E., "Using BGP to Bind MPLS Labels to Address
Prefixes", RFC 8277, DOI 10.17487/RFC8277, October 2017, Prefixes", RFC 8277, DOI 10.17487/RFC8277, October 2017,
<https://www.rfc-editor.org/info/rfc8277>. <https://www.rfc-editor.org/info/rfc8277>.
15.2. Informative References 14.2. Informative References
[GREENBERG09]
Greenberg, A., Hamilton, J., Jain, N., Kadula, S., Kim,
C., Lahiri, P., Maltz, D., Patel, P., and S. Sengupta,
"VL2: A Scalable and Flexible Data Center Network", 2009.
[I-D.ietf-6man-segment-routing-header] [I-D.ietf-6man-segment-routing-header]
Filsfils, C., Previdi, S., Leddy, J., Matsushima, S., and Filsfils, C., Previdi, S., Leddy, J., Matsushima, S., and
d. daniel.voyer@bell.ca, "IPv6 Segment Routing Header d. daniel.voyer@bell.ca, "IPv6 Segment Routing Header
(SRH)", draft-ietf-6man-segment-routing-header-14 (work in (SRH)", draft-ietf-6man-segment-routing-header-15 (work in
progress), June 2018. progress), October 2018.
[RFC6793] Vohra, Q. and E. Chen, "BGP Support for Four-Octet [RFC6793] Vohra, Q. and E. Chen, "BGP Support for Four-Octet
Autonomous System (AS) Number Space", RFC 6793, Autonomous System (AS) Number Space", RFC 6793,
DOI 10.17487/RFC6793, December 2012, DOI 10.17487/RFC6793, December 2012,
<https://www.rfc-editor.org/info/rfc6793>. <https://www.rfc-editor.org/info/rfc6793>.
Authors' Addresses Authors' Addresses
Clarence Filsfils (editor) Clarence Filsfils (editor)
Cisco Systems, Inc. Cisco Systems, Inc.
 End of changes. 26 change blocks. 
190 lines changed or deleted 40 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/