draft-ietf-spring-segment-routing-msdc-06.txt   draft-ietf-spring-segment-routing-msdc-07.txt 
Network Working Group C. Filsfils, Ed. Network Working Group C. Filsfils, Ed.
Internet-Draft S. Previdi, Ed. Internet-Draft S. Previdi
Intended status: Informational Cisco Systems, Inc. Intended status: Informational Cisco Systems, Inc.
Expires: May 3, 2018 J. Mitchell Expires: June 22, 2018 J. Mitchell
Unaffiliated Unaffiliated
E. Aries E. Aries
Juniper Networks Juniper Networks
P. Lapukhov P. Lapukhov
Facebook Facebook
October 30, 2017 December 19, 2017
BGP-Prefix Segment in large-scale data centers BGP-Prefix Segment in large-scale data centers
draft-ietf-spring-segment-routing-msdc-06 draft-ietf-spring-segment-routing-msdc-07
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.
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 Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 May 3, 2018. This Internet-Draft will expire on June 22, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 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. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Large Scale Data Center Network Design Summary . . . . . . . 3 2. Large Scale Data Center Network Design Summary . . . . . . . 3
2.1. Reference design . . . . . . . . . . . . . . . . . . . . 4 2.1. Reference design . . . . . . . . . . . . . . . . . . . . 4
3. Some open problems in large data-center networks . . . . . . 5 3. Some open problems in large data-center networks . . . . . . 5
4. Applying Segment Routing in the DC with MPLS dataplane . . . 6 4. Applying Segment Routing in the DC with MPLS dataplane . . . 6
4.1. BGP Prefix Segment (BGP-Prefix-SID) . . . . . . . . . . . 6 4.1. BGP Prefix Segment (BGP-Prefix-SID) . . . . . . . . . . . 6
4.2. eBGP Labeled Unicast (draft-ietf-mpls-rfc3107bis) . . . . 7 4.2. eBGP Labeled Unicast (RFC8277) . . . . . . . . . . . . . 6
4.2.1. Control Plane . . . . . . . . . . . . . . . . . . . . 8 4.2.1. Control Plane . . . . . . . . . . . . . . . . . . . . 7
4.2.2. Data Plane . . . . . . . . . . . . . . . . . . . . . 9 4.2.2. Data Plane . . . . . . . . . . . . . . . . . . . . . 9
4.2.3. Network Design Variation . . . . . . . . . . . . . . 10 4.2.3. Network Design Variation . . . . . . . . . . . . . . 10
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 . . . . . . . . . . . . . . . 11 4.2.5. Incremental Deployments . . . . . . . . . . . . . . . 11
4.3. iBGP Labeled Unicast (draft-ietf-mpls-rfc3107bis) . . . . 12 4.3. iBGP Labeled Unicast (draft-ietf-mpls-rfc3107bis) . . . . 12
5. Applying Segment Routing in the DC with IPv6 dataplane . . . 14 5. Applying Segment Routing in the DC with IPv6 dataplane . . . 14
6. Communicating path information to the host . . . . . . . . . 14 6. Communicating path information to the host . . . . . . . . . 14
7. Addressing the open problems . . . . . . . . . . . . . . . . 15 7. Addressing the open problems . . . . . . . . . . . . . . . . 15
7.1. Per-packet and flowlet switching . . . . . . . . . . . . 15 7.1. Per-packet and flowlet switching . . . . . . . . . . . . 15
7.2. Performance-aware routing . . . . . . . . . . . . . . . . 16 7.2. Performance-aware routing . . . . . . . . . . . . . . . . 16
skipping to change at page 7, line 4 skipping to change at page 6, line 41
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 9, 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.
4.2. eBGP Labeled Unicast (draft-ietf-mpls-rfc3107bis) 4.2. eBGP Labeled Unicast (RFC8277)
Referring to Figure 1 and [RFC7938], the following design Referring to Figure 1 and [RFC7938], the following design
modifications are introduced: modifications are introduced:
o Each node peers with its neighbors via a eBGP session with o Each node peers with its neighbors via a eBGP session with
extensions defined in [I-D.ietf-mpls-rfc3107bis] (named "eBGP3107" extensions defined in [RFC8277] (named "eBGP8277" throughout this
throughout this document) and with the BGP-Prefix-SID attribute document) and with the BGP-Prefix-SID attribute extension as
extension as defined in [I-D.ietf-idr-bgp-prefix-sid]. defined in [I-D.ietf-idr-bgp-prefix-sid].
o The forwarding plane at Tier-2 and Tier-1 is MPLS. o The forwarding plane at Tier-2 and Tier-1 is MPLS.
o The forwarding plane at Tier-3 is either IP2MPLS (if the host o The forwarding plane at Tier-3 is either IP2MPLS (if the host
sends IP traffic) or MPLS2MPLS (if the host sends MPLS- sends IP traffic) or MPLS2MPLS (if the host sends MPLS-
encapsulated traffic). encapsulated traffic).
Figure 2 zooms into a path from server A to server Z within the Figure 2 zooms into a path from server A to server Z within the
topology of Figure 1. topology of Figure 1.
skipping to change at page 8, line 10 skipping to change at page 7, line 43
Referring to Figure 1 and Figure 2 and assuming the IP address with Referring to Figure 1 and Figure 2 and assuming the IP address with
the AS and label-index allocation previously described, the following the AS and label-index allocation previously described, the following
sections detail the control plane operation and the data plane states sections detail the control plane operation and the data plane states
for the prefix 192.0.2.11/32 (loopback of Node11) for the prefix 192.0.2.11/32 (loopback of Node11)
4.2.1. Control Plane 4.2.1. Control Plane
Node11 originates 192.0.2.11/32 in BGP and allocates to it a BGP- Node11 originates 192.0.2.11/32 in BGP and allocates to it a BGP-
Prefix-SID with label-index: index11 [I-D.ietf-idr-bgp-prefix-sid]. Prefix-SID with label-index: index11 [I-D.ietf-idr-bgp-prefix-sid].
Node11 sends the following eBGP3107 update to Node10: Node11 sends the following eBGP8277 update to Node10:
. IP Prefix: 192.0.2.11/32 . IP Prefix: 192.0.2.11/32
. Label: Implicit-Null . Label: Implicit-Null
. Next-hop: Node11's interface address on the link to Node10 . Next-hop: Node11's interface address on the link to Node10
. AS Path: {11} . AS Path: {11}
. BGP-Prefix-SID: Label-Index 11 . BGP-Prefix-SID: Label-Index 11
Node10 receives the above update. As it is SR capable, Node10 is Node10 receives the above update. As it is SR capable, Node10 is
able to interpret the BGP-Prefix-SID and hence understands that it able to interpret the BGP-Prefix-SID and hence understands that it
should allocate the label from its own SRGB block, offset by the should allocate the label from its own SRGB block, offset by the
Label-Index received in the BGP-Prefix-SID (16000+11 hence 16011) to Label-Index received in the BGP-Prefix-SID (16000+11 hence 16011) to
the NLRI instead of allocating a non-deterministic label out of a the NLRI instead of allocating a non-deterministic label out of a
dynamically allocated portion of the local label space. The dynamically allocated portion of the local label space. The
implicit-null label in the NLRI tells Node10 that it is the implicit-null label in the NLRI tells Node10 that it is the
penultimate hop and must pop the top label on the stack before penultimate hop and must pop the top label on the stack before
forwarding traffic for this prefix to Node11. forwarding traffic for this prefix to Node11.
Then, Node10 sends the following eBGP3107 update to Node7: Then, Node10 sends the following eBGP8277 update to Node7:
. IP Prefix: 192.0.2.11/32 . IP Prefix: 192.0.2.11/32
. Label: 16011 . Label: 16011
. Next-hop: Node10's interface address on the link to Node7 . Next-hop: Node10's interface address on the link to Node7
. AS Path: {10, 11} . AS Path: {10, 11}
. BGP-Prefix-SID: Label-Index 11 . BGP-Prefix-SID: Label-Index 11
Node7 receives the above update. As it is SR capable, Node7 is able Node7 receives the above update. As it is SR capable, Node7 is able
to interpret the BGP-Prefix-SID and hence allocates the local to interpret the BGP-Prefix-SID and hence allocates the local
(incoming) label 16011 (16000 + 11) to the NLRI (instead of (incoming) label 16011 (16000 + 11) to the NLRI (instead of
allocating a "dynamic" local label from its label manager). Node7 allocating a "dynamic" local label from its label manager). Node7
uses the label in the received eBGP3107 NLRI as the outgoing label uses the label in the received eBGP8277 NLRI as the outgoing label
(the index is only used to derive the local/incoming label). (the index is only used to derive the local/incoming label).
Node7 sends the following eBGP3107 update to Node4: Node7 sends the following eBGP8277 update to Node4:
. IP Prefix: 192.0.2.11/32 . IP Prefix: 192.0.2.11/32
. Label: 16011 . Label: 16011
. Next-hop: Node7's interface address on the link to Node4 . Next-hop: Node7's interface address on the link to Node4
. AS Path: {7, 10, 11} . AS Path: {7, 10, 11}
. BGP-Prefix-SID: Label-Index 11 . BGP-Prefix-SID: Label-Index 11
Node4 receives the above update. As it is SR capable, Node4 is able Node4 receives the above update. As it is SR capable, Node4 is able
to interpret the BGP-Prefix-SID and hence allocates the local to interpret the BGP-Prefix-SID and hence allocates the local
(incoming) label 16011 to the NLRI (instead of allocating a "dynamic" (incoming) label 16011 to the NLRI (instead of allocating a "dynamic"
local label from its label manager). Node4 uses the label in the local label from its label manager). Node4 uses the label in the
received eBGP3107 NLRI as outgoing label (the index is only used to received eBGP8277 NLRI as outgoing label (the index is only used to
derive the local/incoming label). derive the local/incoming label).
Node4 sends the following eBGP3107 update to Node1: Node4 sends the following eBGP8277 update to Node1:
. IP Prefix: 192.0.2.11/32 . IP Prefix: 192.0.2.11/32
. Label: 16011 . Label: 16011
. Next-hop: Node4's interface address on the link to Node1 . Next-hop: Node4's interface address on the link to Node1
. AS Path: {4, 7, 10, 11} . AS Path: {4, 7, 10, 11}
. BGP-Prefix-SID: Label-Index 11 . BGP-Prefix-SID: Label-Index 11
Node1 receives the above update. As it is SR capable, Node1 is able Node1 receives the above update. As it is SR capable, Node1 is able
to interpret the BGP-Prefix-SID and hence allocates the local to interpret the BGP-Prefix-SID and hence allocates the local
(incoming) label 16011 to the NLRI (instead of allocating a "dynamic" (incoming) label 16011 to the NLRI (instead of allocating a "dynamic"
local label from its label manager). Node1 uses the label in the local label from its label manager). Node1 uses the label in the
received eBGP3107 NLRI as outgoing label (the index is only used to received eBGP8277 NLRI as outgoing label (the index is only used to
derive the local/incoming label). derive the local/incoming label).
4.2.2. Data Plane 4.2.2. Data Plane
Referring to Figure 1, and assuming all nodes apply the same Referring to Figure 1, and assuming all nodes apply the same
advertisement rules described above and all nodes have the same SRGB advertisement rules described above and all nodes have the same SRGB
(16000-23999), here are the IP/MPLS forwarding tables for prefix (16000-23999), here are the IP/MPLS forwarding tables for prefix
192.0.2.11/32 at Node1, Node4, Node7 and Node10. 192.0.2.11/32 at Node1, Node4, Node7 and Node10.
----------------------------------------------- -----------------------------------------------
skipping to change at page 11, line 27 skipping to change at page 11, line 19
show how the fabric connectivity is preserved. show how the fabric connectivity is preserved.
From a signaling viewpoint, nothing would change: even though Node7 From a signaling viewpoint, nothing would change: even though Node7
does not support the BGP-Prefix-SID, it does propagate the attribute does not support the BGP-Prefix-SID, it does propagate the attribute
unmodified to its neighbors. unmodified to its neighbors.
From a label allocation viewpoint, the only difference is that Node7 From a label allocation viewpoint, the only difference is that Node7
would allocate a dynamic (random) label to the prefix 192.0.2.11/32 would allocate a dynamic (random) label to the prefix 192.0.2.11/32
(e.g. 123456) instead of the "hinted" label as instructed by the BGP- (e.g. 123456) instead of the "hinted" label as instructed by the BGP-
Prefix-SID. The neighbors of Node7 adapt automatically as they Prefix-SID. The neighbors of Node7 adapt automatically as they
always use the label in the BGP3107 NLRI as outgoing label. always use the label in the BGP8277 NLRI as outgoing label.
Node4 does understand the BGP-Prefix-SID and hence allocates the Node4 does understand the BGP-Prefix-SID and hence allocates the
indexed label in the SRGB (16011) for 192.0.2.11/32. indexed label in the SRGB (16011) for 192.0.2.11/32.
As a result, all the data-plane entries across the network would be As a result, all the data-plane entries across the network would be
unchanged except the entries at Node7 and its neighbor Node4 as shown unchanged except the entries at Node7 and its neighbor Node4 as shown
in the figures below. in the figures below.
The key point is that the end-to-end Label Switched Path (LSP) is The key point is that the end-to-end Label Switched Path (LSP) is
preserved because the outgoing label is always derived from the preserved because the outgoing label is always derived from the
received label within the BGP3107 NLRI. The index in the BGP-Prefix- received label within the BGP8277 NLRI. The index in the BGP-Prefix-
SID is only used as a hint on how to allocate the local label (the SID is only used as a hint on how to allocate the local label (the
incoming label) but never for the outgoing label. incoming label) but never for the outgoing label.
------------------------------------------ ------------------------------------------
Incoming label | outgoing | Outgoing Incoming label | outgoing | Outgoing
or IP destination | label | Interface or IP destination | label | Interface
-------------------+---------------------- -------------------+----------------------
12345 | 16011 | 10 12345 | 16011 | 10
Figure 7: Node7 Forwarding Table Figure 7: Node7 Forwarding Table
skipping to change at page 12, line 22 skipping to change at page 12, line 11
The BGP-Prefix-SID can thus be deployed incrementally one node at a The BGP-Prefix-SID can thus be deployed incrementally one node at a
time. time.
When deployed together with a homogeneous SRGB (same SRGB across the When deployed together with a homogeneous SRGB (same SRGB across the
fabric), the operator incrementally enjoys the global prefix segment fabric), the operator incrementally enjoys the global prefix segment
benefits as the deployment progresses through the fabric. benefits as the deployment progresses through the fabric.
4.3. iBGP Labeled Unicast (draft-ietf-mpls-rfc3107bis) 4.3. iBGP Labeled Unicast (draft-ietf-mpls-rfc3107bis)
The same exact design as eBGP3107 is used with the following The same exact design as eBGP8277 is used with the following
modifications: modifications:
All nodes use the same AS number. All nodes use the same AS number.
Each node peers with its neighbors via an internal BGP session Each node peers with its neighbors via an internal BGP session
(iBGP) with extensions defined in [I-D.ietf-mpls-rfc3107bis] (iBGP) with extensions defined in [RFC8277] (named "iBGP8277"
(named "iBGP3107" throughout this document) and with the BGP- throughout this document).
Prefix-SID attribute extension defined in this document.
Each node acts as a route-reflector for each of its neighbors and Each node acts as a route-reflector for each of its neighbors and
with the next-hop-self option. Next-hop-self is a well known with the next-hop-self option. Next-hop-self is a well known
operational feature which consists of rewriting the next-hop of a operational feature which consists of rewriting the next-hop of a
BGP update prior to send it to the neighbor. Usually, it's a BGP update prior to send it to the neighbor. Usually, it's a
common practice to apply next-hop-self behavior towards iBGP peers common practice to apply next-hop-self behavior towards iBGP peers
for eBGP learned routes. In the case outlined in this section it for eBGP learned routes. In the case outlined in this section it
is proposed to use the next-hop-self mechanism also to iBGP is proposed to use the next-hop-self mechanism also to iBGP
learned routes. learned routes.
skipping to change at page 13, line 47 skipping to change at page 13, line 47
illustrated in Figure 9: illustrated in Figure 9:
Node5, Node6, Node7 and Node8 use the same Cluster ID (Cluster- Node5, Node6, Node7 and Node8 use the same Cluster ID (Cluster-
1) 1)
Node3 and Node4 use the same Cluster ID (Cluster-2) Node3 and Node4 use the same Cluster ID (Cluster-2)
Node9 and Node10 use the same Cluster ID (Cluster-3) Node9 and Node10 use the same Cluster ID (Cluster-3)
The control-plane behavior is mostly the same as described in the The control-plane behavior is mostly the same as described in the
previous section: the only difference is that the eBGP3107 path previous section: the only difference is that the eBGP8277 path
propagation is simply replaced by an iBGP3107 path reflection with propagation is simply replaced by an iBGP8277 path reflection with
next-hop changed to self. next-hop changed to self.
The data-plane tables are exactly the same. The data-plane tables are exactly the same.
5. Applying Segment Routing in the DC with IPv6 dataplane 5. Applying Segment Routing in the DC with IPv6 dataplane
The design described in [RFC7938] is reused with one single The design described in [RFC7938] is reused with one single
modification. It is highlighted using the example of the modification. It is highlighted using the example of the
reachability to Node11 via spine node Node5. reachability to Node11 via spine node Node5.
skipping to change at page 15, line 20 skipping to change at page 15, line 20
7. Addressing the open problems 7. Addressing the open problems
This section demonstrates how the problems described above (in This section demonstrates how the problems described above (in
section 3) could be solved using the segment routing concept. It is section 3) could be solved using the segment routing concept. It is
worth noting that segment routing signaling and data-plane are only worth noting that segment routing signaling and data-plane are only
parts of the solution. Additional enhancements, e.g., such as the parts of the solution. Additional enhancements, e.g., such as the
centralized controller mentioned previously, and host networking centralized controller mentioned previously, and host networking
stack support are required to implement the proposed solutions. Also stack support are required to implement the proposed solutions. Also
the applicability of the solutions described below are not restricted the applicability of the solutions described below are not restricted
to the data-center alone, the same could be re-used in context of to the data-center alone, the same could be re-used in context of
other domains as well. other domains as well
7.1. Per-packet and flowlet switching 7.1. Per-packet and flowlet switching
A flowlet is defined as a burst of packets from the same flow A flowlet is defined as a burst of packets from the same flow
followed by an idle interval. [KANDULA04] developed a scheme that followed by an idle interval. [KANDULA04] developed a scheme that
uses flowlets to split traffic across multiple parallel paths in uses flowlets to split traffic across multiple parallel paths in
order to optimize traffic load sharing. order to optimize traffic load sharing.
With the ability to choose paths on the host, one may go from per- With the ability to choose paths on the host, one may go from per-
flow load-sharing in the network to per-packet or per-flowlet. The flow load-sharing in the network to per-packet or per-flowlet. The
skipping to change at page 18, line 8 skipping to change at page 18, line 8
the possible paths, knowing exactly which links and devices these the possible paths, knowing exactly which links and devices these
packets will be crossing. Correlating results for multiple packets will be crossing. Correlating results for multiple
destinations with the topological data, it may automatically isolate destinations with the topological data, it may automatically isolate
possible problem to a link or device in the network. possible problem to a link or device in the network.
8. Additional Benefits 8. Additional Benefits
8.1. MPLS Dataplane with operational simplicity 8.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
(RFC3107 [RFC3107]). It applies either to eBGP or iBGP based (RFC8277 [RFC8277]). It applies either to eBGP or iBGP based
designs. 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 9
skipping to change at page 21, line 47 skipping to change at page 21, line 47
review of this document. review of this document.
14. Contributors 14. Contributors
Gaya Nagarajan Gaya Nagarajan
Facebook Facebook
US US
Email: gaya@fb.com Email: gaya@fb.com
Gaurav Dawra
Cisco Systems
US
Email: gdawra.ietf@gmail.com
Dmitry Afanasiev Dmitry Afanasiev
Yandex Yandex
RU RU
Email: fl0w@yandex-team.ru Email: fl0w@yandex-team.ru
Tim Laberge Tim Laberge
Cisco Cisco
US US
Email: tlaberge@cisco.com Email: tlaberge@cisco.com
Edet Nkposong Edet Nkposong
Salesforce.com Inc. Salesforce.com Inc.
US US
skipping to change at page 22, line 44 skipping to change at page 23, line 5
15. References 15. References
15.1. Normative References 15.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-07 (work in progress), BGP", draft-ietf-idr-bgp-prefix-sid-07 (work in progress),
October 2017. October 2017.
[I-D.ietf-mpls-rfc3107bis]
Rosen, E., "Using BGP to Bind MPLS Labels to Address
Prefixes", draft-ietf-mpls-rfc3107bis-04 (work in
progress), August 2017.
[I-D.ietf-spring-segment-routing] [I-D.ietf-spring-segment-routing]
Filsfils, C., Previdi, S., Decraene, B., Litkowski, S., Filsfils, C., Previdi, S., Ginsberg, L., Decraene, B.,
and R. Shakir, "Segment Routing Architecture", draft-ietf- Litkowski, S., and R. Shakir, "Segment Routing
spring-segment-routing-12 (work in progress), June 2017. Architecture", draft-ietf-spring-segment-routing-13 (work
in progress), October 2017.
[I-D.ietf-spring-segment-routing-central-epe] [I-D.ietf-spring-segment-routing-central-epe]
Filsfils, C., Previdi, S., Aries, E., and D. Afanasiev, Filsfils, C., Previdi, S., Dawra, G., Aries, E., and D.
"Segment Routing Centralized BGP Egress Peer Engineering", Afanasiev, "Segment Routing Centralized BGP Egress Peer
draft-ietf-spring-segment-routing-central-epe-06 (work in Engineering", draft-ietf-spring-segment-routing-central-
progress), June 2017. epe-07 (work in progress), October 2017.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <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>.
[RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A
Border Gateway Protocol 4 (BGP-4)", RFC 4271, Border Gateway Protocol 4 (BGP-4)", RFC 4271,
DOI 10.17487/RFC4271, January 2006, DOI 10.17487/RFC4271, January 2006,
<https://www.rfc-editor.org/info/rfc4271>. <https://www.rfc-editor.org/info/rfc4271>.
[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>.
[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
Prefixes", RFC 8277, DOI 10.17487/RFC8277, October 2017,
<https://www.rfc-editor.org/info/rfc8277>.
15.2. Informative References 15.2. Informative References
[GREENBERG09] [GREENBERG09]
Greenberg, A., Hamilton, J., Jain, N., Kadula, S., Kim, Greenberg, A., Hamilton, J., Jain, N., Kadula, S., Kim,
C., Lahiri, P., Maltz, D., Patel, P., and S. Sengupta, C., Lahiri, P., Maltz, D., Patel, P., and S. Sengupta,
"VL2: A Scalable and Flexible Data Center Network", 2009. "VL2: A Scalable and Flexible Data Center Network", 2009.
[I-D.ietf-6man-segment-routing-header] [I-D.ietf-6man-segment-routing-header]
Previdi, S., Filsfils, C., Raza, K., Leddy, J., Field, B., Previdi, S., Filsfils, C., Raza, K., Leddy, J., Field, B.,
daniel.voyer@bell.ca, d., daniel.bernier@bell.ca, d., daniel.voyer@bell.ca, d., daniel.bernier@bell.ca, d.,
Matsushima, S., Leung, I., Linkova, J., Aries, E., Kosugi, Matsushima, S., Leung, I., Linkova, J., Aries, E., Kosugi,
T., Vyncke, E., Lebrun, D., Steinberg, D., and R. Raszuk, T., Vyncke, E., Lebrun, D., Steinberg, D., and R. Raszuk,
"IPv6 Segment Routing Header (SRH)", draft-ietf-6man- "IPv6 Segment Routing Header (SRH)", draft-ietf-6man-
segment-routing-header-07 (work in progress), July 2017. segment-routing-header-07 (work in progress), July 2017.
[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.
[KANDULA04] [KANDULA04]
Sinha, S., Kandula, S., and D. Katabi, "Harnessing TCP's Sinha, S., Kandula, S., and D. Katabi, "Harnessing TCP's
Burstiness with Flowlet Switching", 2004. Burstiness with Flowlet Switching", 2004.
[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.
Brussels Brussels
BE BE
Email: cfilsfil@cisco.com Email: cfilsfil@cisco.com
Stefano Previdi (editor) Stefano Previdi
Cisco Systems, Inc. Cisco Systems, Inc.
Italy Italy
Email: stefano@previdi.net Email: stefano@previdi.net
Jon Mitchell Jon Mitchell
Unaffiliated Unaffiliated
Email: jrmitche@puck.nether.net Email: jrmitche@puck.nether.net
Ebben Aries Ebben Aries
Juniper Networks Juniper Networks
1133 Innovation Way 1133 Innovation Way
Sunnyvale CA 94089 Sunnyvale CA 94089
US US
Email: exa@juniper.net Email: exa@juniper.net
Petr Lapukhov Petr Lapukhov
Facebook Facebook
 End of changes. 36 change blocks. 
63 lines changed or deleted 48 lines changed or added

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