idnits 2.17.1 draft-gredler-idr-bgplu-epe-14.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 : ---------------------------------------------------------------------------- -- The document has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 06, 2021) is 1019 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 3107 (Obsoleted by RFC 8277) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Inter-Domain Routing H. Gredler, Ed. 3 Internet-Draft RtBrick Inc. 4 Intended status: Informational K. Vairavakkalai 5 Expires: January 7, 2022 C. Ramachandran 6 B. Rajagopalan 7 E. Aries 8 Juniper Networks, Inc. 9 L. Fang 10 eBay 11 July 06, 2021 13 Egress Peer Engineering using BGP-LU 14 draft-gredler-idr-bgplu-epe-14 16 Abstract 18 The MPLS source routing paradigm provides path control for both 19 intra- and inter- Autonomous System (AS) traffic. RSVP-TE is 20 utilized for intra-AS path control. This documents outlines how MPLS 21 routers may use the BGP labeled unicast protocol (BGP-LU) for doing 22 traffic-engineering on inter-AS links. 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 https://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 January 7, 2022. 47 Copyright Notice 49 Copyright (c) 2021 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 (https://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 2. Motivation, Rationale and Applicability . . . . . . . . . . . 3 66 3. Sample Topology . . . . . . . . . . . . . . . . . . . . . . . 3 67 3.1. Loopback IP addresses and Router-IDs . . . . . . . . . . 4 68 3.2. Link IP addresses . . . . . . . . . . . . . . . . . . . . 4 69 4. Service Route Advertisement . . . . . . . . . . . . . . . . . 5 70 5. Egress Next-hop Advertisement . . . . . . . . . . . . . . . . 5 71 5.1. iBGP meshing and BGP nexthop rewrite policy . . . . . . . 6 72 5.2. Single-hop eBGP . . . . . . . . . . . . . . . . . . . . . 7 73 5.3. Multi-hop eBGP . . . . . . . . . . . . . . . . . . . . . 7 74 5.4. Grouping of Peers . . . . . . . . . . . . . . . . . . . . 8 75 6. Egress Link Protection . . . . . . . . . . . . . . . . . . . 9 76 6.1. FRR backup routes . . . . . . . . . . . . . . . . . . . . 9 77 6.1.1. Local links . . . . . . . . . . . . . . . . . . . . . 10 78 6.1.2. Remote BGP-LU labels . . . . . . . . . . . . . . . . 10 79 6.1.3. Local IP forwarding tables . . . . . . . . . . . . . 10 80 7. Dynamic link utilization . . . . . . . . . . . . . . . . . . 10 81 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 82 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 83 10. Security Considerations . . . . . . . . . . . . . . . . . . . 11 84 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 85 11.1. Normative References . . . . . . . . . . . . . . . . . . 11 86 11.2. Informative References . . . . . . . . . . . . . . . . . 11 87 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 89 1. Introduction 91 Today, BGP-LU [RFC3107] is used both as an intra-AS 92 [I-D.ietf-mpls-seamless-mpls] and inter-AS routing protocol. BGP-LU 93 may advertise a MPLS transport path between IGP regions and 94 Autonomous Systems. Those paths may span one or more router hops. 96 This document describes advertisement and use of one-hop MPLS label- 97 switched paths (LSPs) for traffic-engineering the links between 98 Autonomous Systems. 100 Consider Figure 1: an ASBR router (R2) advertises a labeled host 101 route for the remote-end IP address of its link (IP3). The BGP next- 102 hop gets set to R2s loopback IP address. For the advertised Label 103 a forwarding action of 'POP and forward' to next-hop (IP3) is 104 installed in R2's MPLS forwarding table. Now consider if R2 had 105 several links and R2 would advertise labels for all of its inter-AS 106 links. By pushing the corresponding MPLS label on the label- 107 stack an ingress router R1 may control the egress peer selection. 109 AS1 : AS2 110 : 111 +----+ iBGP +----+ : eBGP +----+ 112 | R1 |----------| R2 |-IP2----IP3-| R3 | 113 +----+ +----+ : +----+ 114 : 115 -----------traffic-flow----------> 116 <------------route-flow----------- 118 Figure 1: single-hop LSPs 120 Of course, since R1 and R2 may not be directly connected to each 121 other, if the interior routers within AS1 do not maintain routes to 122 external destinations, carrying traffic to such destinations would 123 require a tunnel from R1 to R2. Such tunnel could be realized as 124 either a MPLS Label Switched Path (LSP), or by GRE [RFC2784]. 126 2. Motivation, Rationale and Applicability 128 BGP-LU is often just seen as a 'stitching' protocol for connecting 129 Autonomous Systems. BGP-LU is often not viewed as a viable protocol 130 for solving the Inter-domain traffic-engineering problem. 132 With this document the authors want to clarify the use of BGP-LU for 133 Egress Peering traffic-engineering purposes and encourage both 134 implementers and network operators to use a widely deployed and 135 operationally well understood protocol, rather than inventing new 136 protocols or new extensions to the existing protocols. 138 3. Sample Topology 140 The following topology (Figure 2) and IP addresses shall be used 141 throughout the Egress Peering Engineering advertisement examples. 143 : : 144 AS 1 : AS 2 : AS 4 145 : : 146 : +-----+ : 147 /IP2--:-IP3--|ASBR3| : 148 +-----+ +-----+-IP4--:-IP5--+-----+-----------+-----+ 149 | R1 +-------------+ASBR1| : |ASBR6| 150 +--+--+ +--+--+-IP6--:-IP7--+-----+-----------+-----+ 151 | | \ : |ASBR4| : / 152 | | \ : +-----+ : / 153 | | IP8- --- 154 | | \ ................ / 155 | | IP9- --- 156 | | : \ / : 157 | | : \ / : 158 +--+--+ +--+--+ : +--+--+ : 159 | R2 +-------------+ASBR2|-IP10-:-IP11-|ASBR5| : 160 +-----+ +-----+ : +-----+ : 161 : : 162 : AS3 : 163 : : 165 Figure 2: Sample Topology 167 3.1. Loopback IP addresses and Router-IDs 169 o R1: 192.0.2.1/32 171 o R2: 192.0.2.2/32 173 o ASBR1: 192.0.2.11/32 175 o ASBR2: 192.0.2.12/32 177 o ASBR3: 192.0.2.13/32 179 o ASBR4: 192.0.2.14/32 181 o ASBR5: 192.0.2.15/32 183 o ASBR6: 192.0.2.16/32 185 3.2. Link IP addresses 187 o ASBR1 (203.0.113.2/31) to ASBR3 (203.0.113.3/31) link #1 189 o ASBR1 (203.0.113.4/31) to ASBR3 (203.0.113.5/31) link #2 190 o ASBR1 (203.0.113.6/31) to ASBR4 (203.0.113.7/31) 192 o ASBR1 (203.0.113.8/31) to ASBR5 (203.0.113.9/31) 194 o ASBR2 (203.0.113.10/31) to ASBR5 (203.0.113.11/31) 196 4. Service Route Advertisement 198 In Figure 3 a simple network layout is shown. There are two classes 199 of BGP speakers: 201 1. Ingress Routers 203 2. Controllers 205 Ingress routers receive BGP-LU routes from the ASBRs. Each BGP-LU 206 route corresponds to an egress link. Furthermore Ingress routers 207 receive their service routes using the BGP protocol. The BGP Add- 208 paths extension [I-D.ietf-idr-add-paths] ensures that multiple paths 209 to a given service route may get advertised. 211 As outlined in [I-D.filsfils-spring-segment-routing-central-epe], 212 Controllers receive BGP-LU routes from the ASBRs as well. However 213 the service routes may be received either using the BGP protocol plus 214 the BGP Add-paths extension [I-D.ietf-idr-add-paths] or alternatively 215 The BGP Monitoring protocol [I-D.ietf-grow-bmp] (BMP). BMP has 216 support for advertising the RIB-In of a BGP router. As such it might 217 be a suitable protocol for feeding all potential egress paths of a 218 service-route from a ASBR into a controller. 220 5. Egress Next-hop Advertisement 222 An ASBR assigns a distinct label for each of its next-hops facing an 223 eBGP peer and advertises it to its internal BGP mesh. The ASBR 224 programs a forwarding action 'POP and forward' into the MPLS 225 forwarding table. Note that the neighboring AS is not required to 226 support exchanging NLRIs with the local AS using BGP-LU. It is the 227 local ASBR (ASBR{1,2}) which generates the BGP-LU routes into its 228 iBGP mesh or controller facing session(s). The forwarding next-hop 229 for those routes points to the link-IP addresses of the remote ASBRs 230 (ASBR{3,4,5}). Note that the generated BGP-LU routes always match 231 the BGP next-hop that the remote ASBRs set their BGP service routes 232 to, such that the software component doing route-resolution 233 understands the association between the BGP service route and the 234 BGP-LU forwarding route. 236 5.1. iBGP meshing and BGP nexthop rewrite policy 238 Throughout this document we describe how the BGP next-hop of both BGP 239 Service Routes and BGP-LU routes shall be rewritten. This may clash 240 with existing network deployments and existing network configurations 241 guidelines which may mandate to rewrite the BGP next-hop when an BGP 242 update enters an AS. 244 The Egress peering use case assumes a central controller as shown 245 Figure 3. In order to support both existing BGP nexthop guidelines 246 and the suggestion described in this document, an implementation 247 SHOULD support several internal BGP peer-groups: 249 1. iBGP peer group for Ingress Routers 251 2. iBGP peer group for Controllers 253 The first peer group MAY be left unchanged and use any existing BGP 254 nexthop rewrite policy. The second peer group MUST use the BGP 255 rewrite policy described in this document for both service and BGP-LU 256 routes. 258 Of course a common iBGP peer group and a common rewrite policy may be 259 used if the proposed policy is compatible with existing routing 260 software implementations of BGP next-hop route resolution. 262 +-----------+ 263 | Ingress | 264 | Router | 265 +-----------+ 266 ^ 267 | 268 +-----------+ 269 | BGP | +------------+ 270 | Route |-------------->| Controller | 271 | Reflector | +------------+ 272 +-----------+ ^ 273 ^ ^ | 274 | | | 275 | +-------------------+ | 276 | | | 277 v v v 278 +-----------+ +-----------+ 279 | BGP | | BGP | 280 | ASBR1 | . . . | ASBR2 | 281 +-----------+ +-----------+ 283 Figure 3: Selective iBGP NH rewrite 285 5.2. Single-hop eBGP 287 In Figure 2 the ASBR{1,5} and ASBR{2,5} links are examples for 288 single-hop eBGP advertisements. 290 o ASBR5 advertises a BGP service (SAFI-1) route {172.16/12} to ASBR1 291 with a BGP next-hop of 203.0.113.9. When ASBR1 re-advertises this 292 BGP service route towards its iBGP mesh (R{1,2}) it does not 293 overwrite the BGP next-hop, but rather leaves it unchanged. 295 o ASBR1 advertises a BGP-LU route {203.0.113.9/32, label 100} with a 296 BGP next hop of 192.0.2.11. ASBR1 programs a MPLS forwarding 297 state of 'POP and forward' to 203.0.113.9 for the advertised label 298 100. 300 o ASBR5 advertises a BGP service (SAFI-1) route {172.16/12} to ASBR2 301 with a BGP next-hop of 203.0.113.11. When ASBR2 re-advertises 302 this BGP service route towards its iBGP mesh (R{1,2}) it does not 303 overwrite the BGP next-hop, but rather leaves it unchanged. 305 o ASBR2 advertises BGP-LU route {203.0.113.11/32, label 101} with a 306 BGP next hop of 192.0.2.12. ASBR2 programs a MPLS forwarding 307 state of 'POP and forward' to 203.0.113.11 for the advertised 308 label 101. 310 o Should the operator already be redistributing egress links into 311 the network for purposes of BGP next-hop resolution, the BGP-LU 312 route {203.0.113.9/32, label 100} will now take precedence due to 313 LPM over the previous redistributed prefix {203.0.113.8/31}. If 314 the BGP next-hop prefix {203.0.113.9/32} were to be redistributed 315 as-is, then standard protocol best-path and preference selection 316 mechanisms will be exhausted in order to select the best-path. 318 o In general, ASBR1 may receive advertisements for the route to 319 172.16/12 from ASBR3 and ASBR4, as well as from ASBR5. One of 320 these other advertisements may be chosen as the best path by the 321 BGP decision process. In order to allow ASBR1 to re-advertise the 322 route to 172.16/12 received from ASBR5 with next-hop 203.0.113.9, 323 independent of the other advertisements received, ASBR1 and R{1,2} 324 need to support the BGP add-paths extension. 325 [I-D.ietf-idr-add-paths]. 327 5.3. Multi-hop eBGP 329 Todays operational practice for load-sharing across parallel links is 330 to configure a single multi-hop eBGP session between a pair of 331 routers. The IP addresses for the Multi-hop eBGP session are 332 typically sourced from the loopback IP interfaces. Note that those 333 IP addresses do not share an IP subnet. Most often those loopback IP 334 addresses are most specific host routes. Since the BGP next-hops of 335 the received BGP service routes are typically rewritten to the remote 336 routers loopback IP address they cannot get immediatly resolved by 337 the receiving router. To overcome this, the operator configures a 338 static route with next-hops pointing to each of the remote-IP 339 addresses of the underlying links. 341 In Figure 2 both ASBR{1,3} links are examples of a multi-hop eBGP 342 advertisement. In order to advertise a distinct label for a common 343 FEC throughout the iBGP mesh, ASBR1 and all the receiving iBGP 344 routers need to support the BGP Add-paths extension. 345 [I-D.ietf-idr-add-paths]. 347 o ASBR3 advertises a BGP service (SAFI-1) route {172.16/12} over 348 multi-hop eBGP to ASBR1 with a BGP next-hop of 192.0.2.13. When 349 ASBR1 re-advertises this BGP service route towards its iBGP mesh 350 (R{1,2}) it does not overwrite the BGP next-hop, but rather leaves 351 it unchanged. Note that the iBGP routers SHOULD support the BGP 352 Add-paths extension [I-D.ietf-idr-add-paths] such that ASBR can 353 re-advertise all paths to the SAFI-1 route {172.16/12}. 355 o For link #1, ASBR1 advertises into its iBGP mesh a BGP-LU route 356 {192.0.2.13/32, label 102} with a BGP next hop of 192.0.2.11. To 357 differentiate this from the link #2 route-advertisement (which 358 contains the same FEC) it is setting the path-ID to 1. ASBR1 359 programs a MPLS forwarding state of 'POP and forward' to 360 203.0.113.3 for the advertised label 102. 362 o For link #2, ASBR1 advertises into its iBGP mesh a BGP-LU route 363 {192.0.2.13/32, label 103} with a BGP next hop of 192.0.2.11. To 364 differentiate this from the link #1 route-advertisement (which 365 contains the same FEC) it is setting the path-ID to 2. ASBR1 366 programs a MPLS forwarding state of 'POP and forward' to 367 203.0.113.5 for the advertised label 103. 369 o Should the operator already be redistributing static routes into 370 the network, the BGP next-hop {192.0.2.13} may already be 371 resolvable. It is then that standard protocol best-path and 372 preference selection mechanisms will be exhausted in order to 373 select the best-path. 375 5.4. Grouping of Peers 377 In addition to offering a distinct BGP-LU label for each egress link, 378 an ASBR MAY want to advertise a BGP-LU label which represents a load- 379 balancing forwarding action across a set of peers. The difference is 380 here that the ingress node gives up individual link control, but 381 rather delegates the load-balancing decision to a particular egress 382 router which has the freedom to send the traffic down to any link in 383 the Peer Set as identified by the BGP-LU label. 385 Assume that ASBR1 wants to advertise a label identifying the Peer Set 386 {ASBR3, ASBR4, ASBR5}. 388 o For the two ASBR{1,3} links in Figure 2, belonging to Peer Set 1, 389 ASBR1 advertises a single BGP-LU route {192.0.2.13/32, label 104} 390 with a BGP next hop of 192.0.2.11. To differentiate this from the 391 ASBR{1,3} single link route-advertisements (which contains the 392 same FEC) it is setting the path-ID to 3 and attaching a Peer-Set 393 Community 'Peer Set 1'. 395 o For the ASBR{1,4} link in Figure 2, ASBR1 advertises a BGP-LU 396 route {203.0.113.7/32, label 104} with a BGP next hop of 397 192.0.2.11. To differentiate this from the ASBR{1,4} single link 398 route-advertisements (which contains the same FEC) it is setting 399 the path-ID to 2 and attaching a Peer-Set Community 'Peer Set 1'. 401 o For the ASBR{1,5} link in Figure 2, ASBR1 advertises a BGP-LU 402 route {203.0.113.9/32, label 104} with a BGP next hop of 403 192.0.2.11. To differentiate this from the ASBR{1,5} single link 404 route-advertisements (which contains the same FEC) it is setting 405 the path-ID to 2 and attaching a Peer-Set Community 'Peer Set 1'. 407 Finally ASBR1 programs a MPLS forwarding state of 'POP and load- 408 balance' to {203.0.113.3, 203.0.113.5, 203.0.113.7, 203.0.113.9} for 409 the advertised label 104. 411 6. Egress Link Protection 413 It is desirable to provide a local-repair based protection scheme, in 414 case a redundant path is available to reach a peer AS. Protection 415 may be applied at multiple levels in the routing stack. Since the 416 ASBR has insight into both BGP-LU and BGP service advertisements, 417 protection can be provided at the BGP-LU, at the BGP service or both 418 levels. 420 6.1. FRR backup routes 422 Assume the network operator wants to provide a local-repair next-hop 423 for the 172.16/12 BGP service route at ASBR1. The active route 424 resolves over the parallel links towards ASBR3. In case the link #1 425 between ASBR{1,3} fails there are now several candidate backup paths 426 providing protection against link or node failure. 428 6.1.1. Local links 430 Assuming that the remaining link #2 between ASBR{1,3} has enough 431 capacity, and link-protection is sufficient, this link MAY serve as 432 temporary backup. 434 However if node-protection or additional capacity is desired, then 435 the local link between ASBR{1,4} or ASBR{1,5} MAY be used as 436 temporary backup. 438 6.1.2. Remote BGP-LU labels 440 ASBR1 is both originator and receiver of BGP routing information. 441 For this protection method it is required that the ASBRs support the 442 [I-D.ietf-idr-best-external] behavior. ASBR1 receives both the BGP- 443 LU and BGP service routes from ASBR2 and therefore can use the ASBR2 444 advertised label as a backup path given that ASBR1 has a tunnel 445 towards ASBR2. 447 6.1.3. Local IP forwarding tables 449 For protecting plain unicast (Internet) routing information a very 450 simple backup scheme could be to recurse to the relevant IP 451 forwarding table and do an IP lookup to further determine a new 452 egress link. 454 7. Dynamic link utilization 456 For a software component which controls the egress link selection it 457 may be desirable to know about a particular egress links current 458 utilization, such that it can adjust the traffic that gets sent to a 459 particular interface. 461 In [I-D.ietf-idr-link-bandwidth] a community for reporting link- 462 bandwidth is specified. Rather than reporting the static bandwidth 463 of the link, the ASBRs shall report the available bandwidth as seen 464 by the data-plane via the link-bandwidth community in their BGP-LU 465 update message. 467 It is crucial that ingress routers learn quickly about congestion of 468 an egress link and hence it is desired to get timely updates of the 469 advertised per-link BGP-LU routes carrying the available bandwidth 470 information when the available bandwidth crosses a certain 471 (preconfigured) threshold. 473 Controllers may also utilize the link-bandwidth community among other 474 common mechanisms to retrieve data-plane statistics (e.g. SNMP, 475 NETCONF) 477 8. Acknowledgements 479 Many thanks to Yakov Rekhter, Chris Bowers and Jeffrey (Zhaohui) 480 Zhang for their detailed review and insightful comments. 482 Special thanks to Richard Steenbergen and Tom Scholl who brought up 483 the original idea of using MPLS for BGP based egress load-balancing 484 at their inspiring talk at Nanog 48. 486 9. IANA Considerations 488 This documents does not request any action from IANA. 490 10. Security Considerations 492 This document does not introduce any change in terms of BGP security. 494 11. References 496 11.1. Normative References 498 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 499 Requirement Levels", BCP 14, RFC 2119, 500 DOI 10.17487/RFC2119, March 1997, 501 . 503 [RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. 504 Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, 505 DOI 10.17487/RFC2784, March 2000, 506 . 508 [RFC3107] Rekhter, Y. and E. Rosen, "Carrying Label Information in 509 BGP-4", RFC 3107, DOI 10.17487/RFC3107, May 2001, 510 . 512 11.2. Informative References 514 [I-D.filsfils-spring-segment-routing-central-epe] 515 Filsfils, C., Previdi, S., Patel, K., Aries, E., Shaw, S., 516 Ginsburg, D., and D. Afanasiev, "Segment Routing 517 Centralized Egress Peer Engineering", draft-filsfils- 518 spring-segment-routing-central-epe-05 (work in progress), 519 August 2015. 521 [I-D.ietf-grow-bmp] 522 Scudder, J., Fernando, R., and S. Stuart, "BGP Monitoring 523 Protocol (BMP)", draft-ietf-grow-bmp-17 (work in 524 progress), January 2016. 526 [I-D.ietf-idr-add-paths] 527 Walton, D., Retana, A., Chen, E., and J. Scudder, 528 "Advertisement of Multiple Paths in BGP", draft-ietf-idr- 529 add-paths-15 (work in progress), May 2016. 531 [I-D.ietf-idr-best-external] 532 Marques, P., Fernando, R., Chen, E., Mohapatra, P., and H. 533 Gredler, "Advertisement of the best external route in 534 BGP", draft-ietf-idr-best-external-05 (work in progress), 535 January 2012. 537 [I-D.ietf-idr-link-bandwidth] 538 Mohapatra, P. and R. Fernando, "BGP Link Bandwidth 539 Extended Community", draft-ietf-idr-link-bandwidth-07 540 (work in progress), March 2018. 542 [I-D.ietf-mpls-seamless-mpls] 543 Leymann, N., Decraene, B., Filsfils, C., Konstantynowicz, 544 M., and D. Steinberg, "Seamless MPLS Architecture", draft- 545 ietf-mpls-seamless-mpls-07 (work in progress), June 2014. 547 Authors' Addresses 549 Hannes Gredler (editor) 550 RtBrick Inc. 552 Email: hannes@rtbrick.com 554 Kaliraj Vairavakkalai 555 Juniper Networks, Inc. 556 1194 N. Mathilda Ave. 557 Sunnyvale, CA 94089 558 US 560 Email: kaliraj@juniper.net 562 Chandra Ramachandran 563 Juniper Networks, Inc. 564 Electra, Exora Business Park Marathahalli - Sarjapur Outer 565 Ring Road 566 Bangalore, KA 560103 567 India 569 Email: csekar@juniper.net 570 Balaji Rajagopalan 571 Juniper Networks, Inc. 572 Electra, Exora Business Park Marathahalli - Sarjapur Outer 573 Ring Road 574 Bangalore, KA 560103 575 India 577 Email: balajir@juniper.net 579 Ebben Aries 580 Juniper Networks, Inc. 581 1194 N. Mathilda Ave. 582 Sunnyvale, CA 94089 583 US 585 Email: earies@juniper.net 587 Luyuan Fang 588 eBay 589 411 108th Ave NE 590 Bellevue, WA 98004 591 US 593 Email: lufang@ebay.com