idnits 2.17.1 draft-filsfils-spring-segment-routing-msdc-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 15 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (April 21, 2015) is 3287 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '16000' on line 202 -- Looks like a reference, but probably isn't: '23999' on line 202 ** Obsolete normative reference: RFC 3107 (Obsoleted by RFC 8277) == Outdated reference: A later version (-05) exists of draft-filsfils-spring-segment-routing-central-epe-03 == Outdated reference: A later version (-11) exists of draft-ietf-rtgwg-bgp-routing-large-dc-02 == Outdated reference: A later version (-05) exists of draft-keyupate-idr-bgp-prefix-sid-00 Summary: 1 error (**), 0 flaws (~~), 5 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group C. Filsfils, Ed. 3 Internet-Draft S. Previdi, Ed. 4 Intended status: Informational Cisco Systems, Inc. 5 Expires: October 23, 2015 J. Mitchell 6 B. Black 7 Microsoft Corporation 8 D. Afanasiev 9 Yandex 10 S. Ray 11 Unaffiliated 12 K. Patel 13 Cisco Systems, Inc. 14 April 21, 2015 16 BGP-Prefix Segment in large-scale data centers 17 draft-filsfils-spring-segment-routing-msdc-01 19 Abstract 21 This document describes a practical use case where BGP segment 22 routing can be used in a large-scale data center. 24 Requirements Language 26 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 27 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 28 document are to be interpreted as described in RFC 2119 [RFC2119]. 30 Status of This Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at http://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on October 23, 2015. 47 Copyright Notice 49 Copyright (c) 2015 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (http://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 65 1.1. Reference Diagram . . . . . . . . . . . . . . . . . . . . 3 66 2. BGP Prefix Segment . . . . . . . . . . . . . . . . . . . . . 5 67 3. Segment Routing Design . . . . . . . . . . . . . . . . . . . 5 68 3.1. Control Plane . . . . . . . . . . . . . . . . . . . . . . 6 69 3.2. Data Plane . . . . . . . . . . . . . . . . . . . . . . . 7 70 3.3. Network Design Variation . . . . . . . . . . . . . . . . 8 71 4. Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . 8 72 4.1. MPLS Dataplane with operational simplicity . . . . . . . 9 73 4.2. Minimizing the FIB table . . . . . . . . . . . . . . . . 9 74 4.3. Egress Peer Engineering . . . . . . . . . . . . . . . . . 10 75 4.4. Capacity Optimization . . . . . . . . . . . . . . . . . . 10 76 4.5. Incremental Deployments . . . . . . . . . . . . . . . . . 11 77 4.6. Anycast . . . . . . . . . . . . . . . . . . . . . . . . . 12 78 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 79 6. Manageability Considerations . . . . . . . . . . . . . . . . 12 80 7. Security Considerations . . . . . . . . . . . . . . . . . . . 12 81 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 82 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 83 9.1. Normative References . . . . . . . . . . . . . . . . . . 13 84 9.2. Informative References . . . . . . . . . . . . . . . . . 13 85 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 87 1. Introduction 89 Segment Routing (SR), as described in 90 [I-D.filsfils-spring-segment-routing] leverages the source routing 91 paradigm. A node steers a packet through an ordered list of 92 instructions, called segments. A segment can represent any 93 instruction, topological or service-based. A segment can have a 94 local semantic to an SR node or global within an SR domain. SR 95 allows to enforce a flow through any topological path and service 96 chain while maintaining per-flow state only at the ingress node to 97 the SR domain. Segment Routing can be applied to the MPLS and IPv6 98 dataplanes. 100 The use-case described in this document focuses on SR applied to the 101 MPLS dataplane. In this context, a segment is encoded as an MPLS 102 label. An ordered list of segments is encoded as a stack of labels. 103 The segment to process is on the top of the stack. Upon completion 104 of a segment, the related label is popped from the stack. No 105 forwarding change is required to the MPLS dataplane. 107 The use-case described in this document should be considered in the 108 context of the BGP-based large-scale data-center (DC) design 109 described in [I-D.ietf-rtgwg-bgp-routing-large-dc] where eBGP3107 110 described in [RFC3107] is used instead of eBGP. 112 1.1. Reference Diagram 114 We reuse the 5-stage topology diagram from 115 [I-D.ietf-rtgwg-bgp-routing-large-dc] while adapting the device 116 naming to simplify the text. 118 Tier-3 119 +-----+ 120 |NODE | 121 +->| 5 |--+ 122 | +-----+ | 123 Tier-2 | | Tier-2 124 +-----+ | +-----+ | +-----+ 125 +------------>|NODE |--+->|NODE |--+--|NODE |-------------+ 126 | +-----| 3 |--+ | 6 | +--| 9 |-----+ | 127 | | +-----+ +-----+ +-----+ | | 128 | | | | 129 | | +-----+ +-----+ +-----+ | | 130 | +-----+---->|NODE |--+ |NODE | +--|NODE |-----+-----+ | 131 | | | +---| 4 |--+->| 7 |--+--| 10 |---+ | | | 132 | | | | +-----+ | +-----+ | +-----+ | | | | 133 | | | | | | | | | | 134 +-----+ +-----+ | +-----+ | +-----+ +-----+ 135 |NODE | |NODE | Tier-1 +->|NODE |--+ Tier-1 |NODE | |NODE | 136 | 1 | | 2 | | 8 | | 11 | | 12 | 137 +-----+ +-----+ +-----+ +-----+ +-----+ 138 | | | | | | | | 139 A O B O <- Servers -> Z O O O 141 Figure 1: 5-stage Clos topology 143 Briefly, we remind the salient points of the eBGP-3107 large-scale DC 144 design ([I-D.ietf-rtgwg-bgp-routing-large-dc]) 146 o Each node is its own AS: 148 For simple and efficient route propagation filtering, Nodes 5, 149 6, 7 and 8 share the same AS, Nodes 3 and 4 share the same AS, 150 nodes 9 and 10 share the same AS. 152 For efficient usage of the scarce 2-byte private AS pool, 153 different tier-1 nodes might share the same AS. 155 Without loss of generality, we will simplify these details in 156 this document and assume that each node has its own AS. 158 o Each node peers with its neighbors via eBGP3107 session. 160 o Each node originates its loopback into BGP and announces it to its 161 neighbors. 163 o The forwarding plane at Tier-2 and Tier-1 is MPLS. 165 o The forwarding plane at Tier-3 is either IP2MPLS (if the host 166 sends IP traffic) or MPLS2MPLS (if the host sends MPLS- 167 encapsulated traffic). 169 For illustration purpose, we assume that: 171 o The AS of Node X is AS X. 173 o The loopback of Node X is 1.1.1.x/32. 175 In this document, we also refer to the Tier-3, Tier-2 and Tier-1 176 switches respectively as Spine, Leaf and ToR (top of rack) switches. 177 When a ToR switch acts as a gateway to the "outside world", we call 178 it a border switch. 180 +-----+ +-----+ +-----+ 181 +---------->|NODE | |NODE | |NODE | 182 | | 4 |--+->| 7 |--+--| 10 |---+ 183 | +-----+ +-----+ +-----+ | 184 | | 185 +-----+ +-----+ 186 |NODE | |NODE | 187 | 1 | | 11 | 188 +-----+ +-----+ 189 | | 190 A <- Servers -> Z 192 Figure 2: Path from A to Z via nodes 1, 4, 7, 10 and 11 194 2. BGP Prefix Segment 196 A BGP-Prefix Segment is a segment associated with a BGP prefix. A 197 BGP-Prefix Segment is a network-wide instruction to forward the 198 packet along the ECMP-aware best path to the related prefix 199 [I-D.keyupate-idr-bgp-prefix-sid]. 201 In this document, we make the network design decision to assume that 202 all the nodes are allocated the same SRGB, e.g. [16000, 23999]. This 203 is important to fulfill the requirement for operational 204 simplification as explained in [I-D.filsfils-spring-segment-routing] 205 and [I-D.filsfils-spring-segment-routing-use-cases]. 207 Note well that the use of a common SRGB in all nodes is not a 208 requirement, one could use a different SRGB at every node. However, 209 this would make the operation of the DC fabric more complex as the 210 label allocated to the loopback of a remote switch is then different 211 at every node. 213 For illustration purpose, we assume that the segment index allocated 214 to prefix 1.1.1.x/32 is X. 216 As a result, a local label 1600x is allocated for prefix 1.1.1.x/32 217 by each node throughout the DC fabric. 219 3. Segment Routing Design 221 Referring to Figure 1 and Figure 2 and assuming the IP address, AS 222 and index allocation previously described, this section details the 223 control plane operation and the data plane states for the prefix 224 1.1.1.11/32 (loopback of node 11). 226 3.1. Control Plane 228 Node 11 originates 1.1.1.11/32 in BGP and allocates to it the BGP- 229 Prefix Segment attribute (index11). 231 Node 11 sends the following eBGP3107 update to Node 10: 233 . NLRI: 1.1.1.11/32 234 . Label: Implicit-Null 235 . Next-hop: Node11's interface address on the link to Node10 236 . AS Path: {11} 237 . BGP-Prefix Attribute: Index 11 239 Node 10 receives the above update. As it is SR capable, Node10 is 240 able to interpret the BGP-Prefix Attribute and hence allocates the 241 label 16011 to the NLRI (instead of asking a "random/local" label 242 from its label manager). The implicit-null label in the update 243 signals to Node 10 that it is the penultimate hop and MUST pop the 244 top label on the stack before forwarding traffic for this prefix to 245 Node 11. 247 Then, Node 10 sends the following eBGP3107 update to Node 7: 249 . NLRI: 1.1.1.11/32 250 . Label: 16011 251 . Next-hop: Node10's interface address on the link to Node7 252 . AS Path: {10, 11} 253 . BGP-Prefix Attribute: Index 11 255 Node 7 receives the above update. As it is SR capable, Node 7 is 256 able to interpret the BGP-Prefix Attribute and hence allocates the 257 label 16011 to the NLRI (instead of asking a "random/local" label 258 from its label manager). 260 Node 7 sends the following eBGP3107 update to Node 4: 262 . NLRI: 1.1.1.11/32 263 . Label: 16011 264 . Next-hop: Node7's interface address on the link to Node4 265 . AS Path: {7, 10, 11} 266 . BGP-Prefix Attribute: Index 11 268 Node 4 receives the above update. As it is SR capable, Node 4 is 269 able to interpret the BGP-Prefix Attribute and hence allocates the 270 label 16011 to the NLRI (instead of asking a "random/local" label 271 from its label manager). 273 Node 4 sends the following eBGP3107 update to Node 1: 275 . NLRI: 1.1.1.11/32 276 . Label: 16011 277 . Next-hop: Node4's interface address on the link to Node1 278 . AS Path: {4, 7, 10, 11} 279 . BGP-Prefix Attribute: Index 11 281 Node 1 receives the above update. As it is SR capable, Node 1 is 282 able to interpret the BGP-Prefix Attribute and hence allocates the 283 label 16011 to the NLRI (instead of asking a "random/local" label 284 from its label manager). 286 3.2. Data Plane 288 Referring to figure 1, and assuming all nodes apply the same 289 advertisement rules described above, here are the IP/MPLS forwarding 290 tables for prefix 1.1.1.11/32 at nodes 1, 4, 7 and 10. 292 ----------------------------------------------- 293 Incoming label | outgoing label | Outgoing 294 or IP destination | | Interface 295 ------------------+----------------+----------- 296 16011 | 16011 | ECMP{3, 4} 297 1.1.1.11/32 | 16011 | ECMP{3, 4} 298 ------------------+----------------+----------- 300 Figure 3: Node 1 Forwarding Table 302 ----------------------------------------------- 303 Incoming label | outgoing label | Outgoing 304 or IP destination | | Interface 305 ------------------+----------------+----------- 306 16011 | 16011 | ECMP{7, 8} 307 1.1.1.11/32 | 16011 | ECMP{7, 8} 308 ------------------+----------------+----------- 310 Figure 4: Node-4 Forwarding Table 312 ----------------------------------------------- 313 Incoming label | outgoing label | Outgoing 314 or IP destination | | Interface 315 ------------------+----------------+----------- 316 16011 | 16011 | 10 317 1.1.1.11/32 | 16011 | 10 318 ------------------+----------------+----------- 320 Figure 5: Node-7 Forwarding Table 322 ----------------------------------------------- 323 Incoming label | outgoing label | Outgoing 324 or IP destination | | Interface 325 ------------------+----------------+----------- 326 16011 | POP | 11 327 1.1.1.11/32 | N/A | 11 328 ------------------+----------------+----------- 330 Node-10 Forwarding Table 332 3.3. Network Design Variation 334 A network design choice could consist of switching all the traffic 335 through tier-2 and tier-3 as MPLS traffic. In this case, one could 336 filter away the IP entries at nodes 4, 7 and 10. This might be 337 beneficial in order to optimize the forwarding table size. 339 A network design choice could consist in allowing the hosts to send 340 MPLS-encapsulated traffic (based on EPE use-case, 341 [I-D.filsfils-spring-segment-routing-central-epe]). For example, 342 Node 1 would receive Node11-destined MPLS-encapsulated traffic from 343 its attached host A and would switch this traffic on the basis of the 344 MPLS entry for 16011 (instead of classically receiving IP traffic 345 from A and performing an IPtoMPLS switching operation). 347 4. Benefits 349 The network design illustrated in this document retains all the 350 benefits explained in [I-D.ietf-rtgwg-bgp-routing-large-dc], namely: 352 o Bandwidth and traffic patterns 354 o Capex minimization 356 o Opex minimization 358 o Traffic Engineering 360 o Fast routing convergence 362 o Anycast for extra availability and load-balancing 364 Furthermore, it introduces the following benefits: 366 o MPLS dataplane with operational simplicity 368 o Minimization of the FIB table size 369 o Egress Peer Engineering 371 o Capacity Optimization 373 o Incremental Deployment 375 In the following sections, we detail the anycast benefit and the five 376 "additional" benefits introduced by the BGP-Prefix Segment 377 ([I-D.keyupate-idr-bgp-prefix-sid]). 379 4.1. MPLS Dataplane with operational simplicity 381 As required by [I-D.ietf-rtgwg-bgp-routing-large-dc], no new 382 signaling protocol is introduced. The Prefix Segment is a 383 lightweight extension to BGP3107 [RFC3107]. LDP and RSVP-TE are not 384 used. 386 Thanks to the BGP-Prefix Segment extension 387 ([I-D.keyupate-idr-bgp-prefix-sid]) and the design decision to use 388 the same SRGB at each node in the DC fabric, the troubleshooting of 389 the network is drastically simplified. At every node in the fabric, 390 the same label is associated to each remote prefix/switch. 392 When a controller (e.g. EPE controller in 393 [I-D.filsfils-spring-segment-routing-central-epe]) programs a host A 394 to send its traffic to host Z via the normal BGP multipath, the 395 controller uses label 16011 associated with the ToR switch connected 396 to the server Z. Specifically, the controller does not need to pick 397 the label based on the source ToR that the source host is connected 398 to. 400 In a classic BGP3107 design applied to the DC fabric illustrated in 401 Figure 1, the ToR switch 1 connected to server A would most likely 402 allocate a different label for 1.1.1.11/32 than the one allocated by 403 ToR switch 2. As a consequence, the controller would need to adapt 404 the SR policy to each host, based on the ToR switch that they are 405 connected to. This adds state maintenance and synchronization 406 problems. All this unnecessary complexity is eliminated thanks to 407 the BGP-Prefix Segment extension. Again, both the BGP-Prefix Segment 408 and the design decision to use a common SRGB on all nodes have made 409 this possible. 411 4.2. Minimizing the FIB table 413 The designer may decide to switch all the traffic at tier2 and 414 tier3's based on MPLS, hence drastically decreasing the IP table size 415 at these nodes. 417 This is easily accomplished by encapsulating the traffic directly at 418 the host, or at the source ToR switch by pushing the BGP-Prefix 419 Segment of the destination ToR for intra-DC traffic or border switch 420 for inter-DC or DC-to-outside-world traffic. 422 4.3. Egress Peer Engineering 424 It is straightforward to combine the design illustrated in this 425 document with the EPE use-case 426 [I-D.filsfils-spring-segment-routing-central-epe]. 428 In such case, the operator is able to engineer its outbound traffic 429 on a per host-flow basis, without incurring any additional state at 430 intermediate points in the DC fabric. 432 For example, the controller only needs to inject a per-flow state on 433 the host A to force it to send its traffic destined to a specific 434 internet destination D via a selected border switch (say 12 in 435 Figure 1instead of another border switch 13) and a specific egress 436 peer of border switch 12 (say peer AS 9999 of local PeerNode segment 437 9999 at border switch 12 instead of any other peer which provides a 438 path to the destination D). Any packet matching this state at host A 439 would be encapsulated with SR segment list (i.e.: label stack) 440 {16012, 9999}. 16012 would steer the flow through the DC fabric, 441 leveraging any ECMP, along the best path to border switch 12. Once 442 the flow gets to border switch 12, the active segment is 9999. This 443 EPE PeerNode segment forces border switch 12 to forward the packet to 444 peer AS 9999, without any IP lookup at the border switch. There is 445 no per-flow state for this engineered flow in the DC fabric. The 446 per-flow state is only required at the source (source routing 447 benefits). 449 Note as well, that on top of allowing full engineering control, such 450 a design also offer FIB table minimization benefits as the internet- 451 scale IP lookup at border switch 12 might be avoided. 453 4.4. Capacity Optimization 455 It is straightforward to combine the centralized capacity 456 optimization process described in 457 [I-D.filsfils-spring-segment-routing-use-cases] with the design 458 introduced in this document. 460 For example, in Figure 1, the controller may detect a hot spot on 461 node 5. One way to alleviate the load is to deploy a set of per- 462 destination flow states at a set of ToR switches such that they send 463 they traffic via fabric paths that avoid Node 5. 465 For example, host A could be forced to go to host Z via Node 4. This 466 is conveniently programmed by the controller as a flow state for Z at 467 host A which pushes the segment list {16004, 16011}. 16004 steers the 468 traffic to node 4 via any ECMP path (e.g. multiple parallel links 469 from Node 1 to Node 4). 16011 then steers the traffic from node 4 to 470 node 11 load-balancing the traffic via nodes 7 and 8, and any ECMP 471 along that path. This flow is thus avoiding Node 5 while still 472 leveraging the maximum number of available ECMP paths. This is 473 realized without any intermediate per-flow state. 475 Another alternative state at A could be {16008, 16011}. In this case, 476 this flow would use any ECMP path up to node 8 and then any ECMP path 477 up to node 11. 479 While traffic-engineering within a DC has been rarely used in the 480 past, it is expected to eventually be required as Clos topologies get 481 optimized for higher scale [DRAGONFLY]. 483 4.5. Incremental Deployments 485 Referring to , let us assume that node 7 does not support the BGP- 486 Prefix Segment attribute.Figure 2, let us assume that node 7 does not 487 support the BGP-Prefix Segment attribute. 489 From a signaling viewpoint, nothing would change as even if Node6 490 does not understand the BGP-Prefix Segment attribute, it does 491 propagate it unmodified to its neighbors. 493 From a label allocation viewpoint, the only difference is that Node7 494 would allocate a dynamic label to the prefix 1.1.1.11/32 (e.g. 495 12345) and would advertise that label to its neighbor Node4. 497 Let's highlight that Node4 does understand the BGP-Prefix Segment 498 attribute and hence allocates the indexed label in the SRGB (16011) 499 for 1.1.1.11/32. 501 As a result, all the dataplane entries across the network would be 502 unchanged except the entries at Node7 and its neighbor Node4 as shown 503 in the figures below. 505 ------------------------------------------ 506 Incoming label | outgoing | Outgoing 507 or IP destination | label | Interface 508 -------------------+---------------------- 509 12345 | 16011 | 10 511 Figure 7: Node 7 Forwarding Table 513 ------------------------------------------ 514 Incoming label | outgoing | Outgoing 515 or IP destination | label | Interface 516 -------------------+---------------------- 517 16011 | 12345 | 7 519 Figure 8: Node 4 Forwarding Table 521 The BGP-Prefix Segment functionality can thus be deployed 522 incrementally one node at a time. 524 Where it is deployed, the operator enjoys its benefits without any 525 dependency on the deployment state at any other node. 527 4.6. Anycast 529 The design presented in this document preserves the availability and 530 load-balancing properties of the base design presented in 531 [I-D.filsfils-spring-segment-routing]. 533 For example, one could assign an anycast loopback 1.1.1.20/32 to the 534 border switches 11 and 12 (on top of their node-specific loopbacks). 535 Doing so, the EPE controller could express a default "go-to-the- 536 internet via any border switch" policy as segment list {16020}. 537 Indeed, from any host in the DC fabric, from any ToR switch, 16020 538 steers the packet towards the border switches 11 or 12 leveraging any 539 ECMP along the best paths to these switches. 541 5. IANA Considerations 543 TBD 545 6. Manageability Considerations 547 TBD 549 7. Security Considerations 551 TBD 553 8. Acknowledgements 555 TBD 557 9. References 559 9.1. Normative References 561 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 562 Requirement Levels", BCP 14, RFC 2119, March 1997. 564 [RFC3107] Rekhter, Y. and E. Rosen, "Carrying Label Information in 565 BGP-4", RFC 3107, May 2001. 567 9.2. Informative References 569 [DRAGONFLY] 570 Kim, J., Dally, W., Scott, S., and D. Abts, "Cost- 571 Efficient Dragonfly Topology for Large-Scale Systems", 572 2009. 574 [I-D.filsfils-spring-segment-routing] 575 Filsfils, C., Previdi, S., Bashandy, A., Decraene, B., 576 Litkowski, S., Horneffer, M., Milojevic, I., Shakir, R., 577 Ytti, S., Henderickx, W., Tantsura, J., and E. Crabbe, 578 "Segment Routing Architecture", draft-filsfils-spring- 579 segment-routing-04 (work in progress), July 2014. 581 [I-D.filsfils-spring-segment-routing-central-epe] 582 Filsfils, C., Previdi, S., Patel, K., Aries, E., 583 shaw@fb.com, s., Ginsburg, D., and D. Afanasiev, "Segment 584 Routing Centralized Egress Peer Engineering", draft- 585 filsfils-spring-segment-routing-central-epe-03 (work in 586 progress), January 2015. 588 [I-D.filsfils-spring-segment-routing-use-cases] 589 Filsfils, C., Francois, P., Previdi, S., Decraene, B., 590 Litkowski, S., Horneffer, M., Milojevic, I., Shakir, R., 591 Ytti, S., Henderickx, W., Tantsura, J., Kini, S., and E. 592 Crabbe, "Segment Routing Use Cases", draft-filsfils- 593 spring-segment-routing-use-cases-01 (work in progress), 594 October 2014. 596 [I-D.ietf-rtgwg-bgp-routing-large-dc] 597 Lapukhov, P., Premji, A., and J. Mitchell, "Use of BGP for 598 routing in large-scale data centers", draft-ietf-rtgwg- 599 bgp-routing-large-dc-02 (work in progress), April 2015. 601 [I-D.keyupate-idr-bgp-prefix-sid] 602 Patel, K., Ray, S., Previdi, S., and C. Filsfils, "Segment 603 Routing Prefix SID extensions for BGP", draft-keyupate- 604 idr-bgp-prefix-sid-00 (work in progress), October 2014. 606 Authors' Addresses 608 Clarence Filsfils (editor) 609 Cisco Systems, Inc. 610 Brussels 611 BE 613 Email: cfilsfil@cisco.com 615 Stefano Previdi (editor) 616 Cisco Systems, Inc. 617 Via Del Serafico, 200 618 Rome 00142 619 Italy 621 Email: sprevidi@cisco.com 623 Jon Mitchell 624 Microsoft Corporation 625 One Microsoft Way 626 Redmond, WA 98052 627 United States 629 Email: Jon.Mitchell@microsoft.com 631 Benjamin Black 632 Microsoft Corporation 633 One Microsoft Way 634 Redmond, WA 98052 635 United States 637 Email: benblack@microsoft.com 639 Dmitry Afanasiev 640 Yandex 641 RU 643 Email: fl0w@yandex-team.ru 645 Saikat Ray 646 Unaffiliated 648 Email: raysaikat@gmail.com 649 Keyur Patel 650 Cisco Systems, Inc. 651 US 653 Email: keyupate@cisco.com