idnits 2.17.1 draft-ietf-spring-segment-routing-mpls-04.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 (March 18, 2016) is 2954 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '1000' on line 439 -- Looks like a reference, but probably isn't: '1999' on line 439 ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) == Outdated reference: A later version (-25) exists of draft-ietf-isis-segment-routing-extensions-06 == Outdated reference: A later version (-23) exists of draft-ietf-ospf-ospfv3-segment-routing-extensions-04 == Outdated reference: A later version (-27) exists of draft-ietf-ospf-segment-routing-extensions-06 == Outdated reference: A later version (-08) exists of draft-ietf-spring-problem-statement-07 == Outdated reference: A later version (-15) exists of draft-ietf-spring-segment-routing-07 Summary: 1 error (**), 0 flaws (~~), 6 warnings (==), 4 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: Standards Track A. Bashandy 5 Expires: September 19, 2016 Cisco Systems, Inc. 6 B. Decraene 7 S. Litkowski 8 Orange 9 M. Horneffer 10 Deutsche Telekom 11 R. Shakir 12 Jive Communications 13 J. Tantsura 14 Ericsson 15 E. Crabbe 16 Individual 17 March 18, 2016 19 Segment Routing with MPLS data plane 20 draft-ietf-spring-segment-routing-mpls-04 22 Abstract 24 Segment Routing (SR) leverages the source routing paradigm. A node 25 steers a packet through a controlled set of instructions, called 26 segments, by prepending the packet with an SR header. A segment can 27 represent any instruction, topological or service-based. SR allows 28 to enforce a flow through any topological path and service chain 29 while maintaining per-flow state only at the ingress node to the SR 30 domain. 32 Segment Routing can be directly applied to the MPLS architecture with 33 no change in the forwarding plane. This drafts describes how Segment 34 Routing operates on top of the MPLS data plane. 36 Requirements Language 38 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 39 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 40 document are to be interpreted as described in RFC 2119 [RFC2119]. 42 Status of This Memo 44 This Internet-Draft is submitted in full conformance with the 45 provisions of BCP 78 and BCP 79. 47 Internet-Drafts are working documents of the Internet Engineering 48 Task Force (IETF). Note that other groups may also distribute 49 working documents as Internet-Drafts. The list of current Internet- 50 Drafts is at http://datatracker.ietf.org/drafts/current/. 52 Internet-Drafts are draft documents valid for a maximum of six months 53 and may be updated, replaced, or obsoleted by other documents at any 54 time. It is inappropriate to use Internet-Drafts as reference 55 material or to cite them other than as "work in progress." 57 This Internet-Draft will expire on September 19, 2016. 59 Copyright Notice 61 Copyright (c) 2016 IETF Trust and the persons identified as the 62 document authors. All rights reserved. 64 This document is subject to BCP 78 and the IETF Trust's Legal 65 Provisions Relating to IETF Documents 66 (http://trustee.ietf.org/license-info) in effect on the date of 67 publication of this document. Please review these documents 68 carefully, as they describe your rights and restrictions with respect 69 to this document. Code Components extracted from this document must 70 include Simplified BSD License text as described in Section 4.e of 71 the Trust Legal Provisions and are provided without warranty as 72 described in the Simplified BSD License. 74 Table of Contents 76 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 77 2. Illustration . . . . . . . . . . . . . . . . . . . . . . . . 3 78 3. MPLS Instantiation of Segment Routing . . . . . . . . . . . . 4 79 4. IGP Segments Examples . . . . . . . . . . . . . . . . . . . . 6 80 4.1. Example 1 . . . . . . . . . . . . . . . . . . . . . . . . 7 81 4.2. Example 2 . . . . . . . . . . . . . . . . . . . . . . . . 8 82 4.3. Example 3 . . . . . . . . . . . . . . . . . . . . . . . . 8 83 4.4. Example 4 . . . . . . . . . . . . . . . . . . . . . . . . 8 84 4.5. Example 5 . . . . . . . . . . . . . . . . . . . . . . . . 8 85 5. Other Examples of MPLS Segments . . . . . . . . . . . . . . . 9 86 5.1. LDP LSP segment combined with IGP segments . . . . . . . 9 87 5.2. RSVP-TE LSP segment combined with IGP segments . . . . . 10 88 6. Segment List History . . . . . . . . . . . . . . . . . . . . 11 89 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 90 8. Manageability Considerations . . . . . . . . . . . . . . . . 11 91 9. Security Considerations . . . . . . . . . . . . . . . . . . . 11 92 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 11 93 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 94 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 95 12.1. Normative References . . . . . . . . . . . . . . . . . . 12 96 12.2. Informative References . . . . . . . . . . . . . . . . . 12 98 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 100 1. Introduction 102 The Segment Routing architecture [I-D.ietf-spring-segment-routing] 103 can be directly applied to the MPLS architecture with no change in 104 the MPLS forwarding plane. This drafts describes how Segment Routing 105 operates on top of the MPLS data plane. 107 The Segment Routing problem statement is described in 108 [I-D.ietf-spring-problem-statement]. 110 Link State protocol extensions for Segment Routing are described in 111 [I-D.ietf-isis-segment-routing-extensions], 112 [I-D.ietf-ospf-segment-routing-extensions] and 113 [I-D.ietf-ospf-ospfv3-segment-routing-extensions]. 115 2. Illustration 117 Segment Routing, applied to the MPLS data plane, offers the ability 118 to tunnel services (VPN, VPLS, VPWS) from an ingress PE to an egress 119 PE, without any other protocol than ISIS or OSPF 120 ([I-D.ietf-isis-segment-routing-extensions] and 121 [I-D.ietf-ospf-segment-routing-extensions]). LDP and RSVP-TE 122 signaling protocols are not required. 124 Note that [I-D.filsfils-spring-segment-routing-ldp-interop] documents 125 SR co-existence and interworking with other MPLS signaling protocols, 126 if present in the network during a migration, or in case of non- 127 homogeneous deployments. 129 The operator only needs to allocate one node segment per PE and the 130 SR IGP control-plane automatically builds the required MPLS 131 forwarding constructs from any PE to any PE. 133 P1---P2 134 / \ 135 A---CE1---PE1 PE2---CE2---Z 136 \ / 137 P3---P4 139 Figure 1: IGP-based MPLS Tunneling 141 In Figure 1 above, the four nodes A, CE1, CE2 and Z are part of the 142 same VPN. 144 PE2 advertises (in the IGP) a host address 192.0.2.2/32 with its 145 attached node segment 102. 147 CE2 advertises to PE2 a route to Z. PE2 binds a local label LZ to 148 that route and propagates the route and its label via MPBGP to PE1 149 with nhop 192.0.2.2 (PE2 loopback address). 151 PE1 installs the VPN prefix Z in the appropriate VRF and resolves the 152 next-hop onto the node segment 102. Upon receiving a packet from A 153 destined to Z, PE1 pushes two labels onto the packet: the top label 154 is 102, the bottom label is LZ. 102 identifies the node segment to 155 PE2 and hence transports the packet along the ECMP-aware shortest- 156 path to PE2. PE2 then processes the VPN label LZ and forwards the 157 packet to CE2. 159 Supporting MPLS services (VPN, VPLS, VPWS) with SR has the following 160 benefits: 162 Simple operation: one single intra-domain protocol to operate: the 163 IGP. No need to support IGP synchronization extensions as 164 described in [RFC5443] and [RFC6138]. 166 Excellent scaling: one Node-SID per PE. 168 3. MPLS Instantiation of Segment Routing 170 MPLS instantiation of Segment Routing fits in the MPLS architecture 171 as defined in [RFC3031] both from a control plane and forwarding 172 plane perspective: 174 o From a control plane perspective [RFC3031] does not mandate a 175 single signaling protocol. Segment Routing proposes to use the 176 Link State IGP as its use of information flooding fits very well 177 with label stacking on ingress. 179 o From a forwarding plane perspective, Segment Routing does not 180 require any change to the forwarding plane. 182 When applied to MPLS, a Segment is a LSP and the 20 right-most bits 183 of the segment are encoded as a label. This implies that, in the 184 MPLS instantiation, the SID values are allocated within a reduced 185 20-bit space out of the 32-bit SID space. 187 The notion of indexed global segment fits the MPLS architecture 188 [RFC3031] as the absolute value allocated to any segment (global or 189 local) can be managed by a local allocation process (similarly to 190 other MPLS signaling protocols). 192 If present, SR can coexist and interworks with LDP and RSVP 193 [I-D.filsfils-spring-segment-routing-ldp-interop]. 195 The source routing model described in 196 [I-D.ietf-spring-segment-routing] is inherited from the ones proposed 197 by [RFC1940] and [RFC2460]. The source routing model offers the 198 support for explicit routing capability. 200 Contrary to RSVP-based explicit routes where tunnel midpoints 201 maintain states, SR-based explicit routes only require per-flow 202 states at the ingress edge router where the traffic engineer policy 203 is applied. 205 Contrary to RSVP-based explicit routes which consist in non-ECMP 206 circuits (similar to ATM/FR), SR-based explicit routes can be built 207 as list of ECMP-aware node segments and hence ECMP-aware traffic 208 engineering is natively supported by SR. 210 When Segment Routing is instantiated over the MPLS data plane the 211 following applies: 213 o A list of segments is represented as a stack of labels. 215 o The active segment is the top label. 217 o The CONTINUE operation is implemented as an MPLS swap operation. 218 The outgoing label value is computed as follows: 220 * When the same Segment Routing Global Block (SRGB, defined in 221 [I-D.ietf-spring-segment-routing] is used throughout the SR 222 domain, the outgoing label value is equal to the incoming label 223 value. 225 * When different SRGBs are used, the outgoing label value is set 226 as: [SRGB(next_hop)+index]. If the index can't be applied to 227 the SRGB (i.e.: if the index points outside the SRGB of the 228 next-hop or the next-hop has not advertised a valid SRGB), then 229 no outgoing label value can be computed and the next-hop MUST 230 be considered as not supporting the MPLS operations for that 231 particular SID. 233 o The NEXT operation is implemented as an MPLS pop operation. The 234 NEXT operation does not require any mapping to an outgoing label 235 hence the SRGB is irrelevant for this operation. 237 o The PUSH operation is implemented as an MPLS push of a label 238 stack. 240 o The Segment Routing Global Block (SRGB) values MUST be greater 241 than 15 in order to preserve values 0-15 as defined in [RFC3032]. 243 o As described in [I-D.ietf-spring-segment-routing], using the same 244 SRGB on all nodes within the SR domain eases operations and 245 troubleshooting and is expected to be a deployment guideline. 247 In conclusion, there are no changes in the operations of the data- 248 plane currently used in MPLS networks. 250 4. IGP Segments Examples 252 Assuming the network diagram of Figure 2 and the IP address and IGP 253 Segment allocation of Figure 3, the following examples can be 254 constructed. 256 +--------+ 257 / \ 258 R1-----R2----------R3-----R8 259 | \ / | 260 | +--R4--+ | 261 | | 262 +-----R5-----+ 264 Figure 2: IGP Segments - Illustration 266 +-----------------------------------------------------------+ 267 | IP address allocated by the operator: | 268 | 192.0.2.1/32 as a loopback of R1 | 269 | 192.0.2.2/32 as a loopback of R2 | 270 | 192.0.2.3/32 as a loopback of R3 | 271 | 192.0.2.4/32 as a loopback of R4 | 272 | 192.0.2.5/32 as a loopback of R5 | 273 | 192.0.2.8/32 as a loopback of R8 | 274 | 198.51.100.9/32 as an anycast loopback of R4 | 275 | 198.51.100.9/32 as an anycast loopback of R5 | 276 | | 277 | SRGB defined by the operator as 1000-5000 | 278 | | 279 | Global IGP SID allocated by the operator: | 280 | 1001 allocated to 192.0.2.1/32 | 281 | 1002 allocated to 192.0.2.2/32 | 282 | 1003 allocated to 192.0.2.3/32 | 283 | 1004 allocated to 192.0.2.4/32 | 284 | 1008 allocated to 192.0.2.8/32 | 285 | 2009 allocated to 198.51.100.9/32 | 286 | | 287 | Local IGP SID allocated dynamically by R2 | 288 | for its "north" adjacency to R3: 9001 | 289 | for its "north" adjacency to R3: 9003 | 290 | for its "south" adjacency to R3: 9002 | 291 | for its "south" adjacency to R3: 9003 | 292 +-----------------------------------------------------------+ 294 Figure 3: IGP Address and Segment Allocation - Illustration 296 4.1. Example 1 298 R1 may send a packet P1 to R8 simply by pushing an SR header with 299 segment list {1008}. 301 1008 is a global IGP segment attached to the IP prefix 192.0.2.8/32. 302 Its semantic is global within the IGP domain: any router forwards a 303 packet received with active segment 1008 to the next-hop along the 304 ECMP-aware shortest-path to the related prefix. 306 In conclusion, the path followed by P1 is R1-R2--R3-R8. The ECMP- 307 awareness ensures that the traffic be load-shared between any ECMP 308 path, in this case the two north and south links between R2 and R3. 310 4.2. Example 2 312 R1 may send a packet P2 to R8 by pushing an SR header with segment 313 list {1002, 9001, 1008}. 315 1002 is a global IGP segment attached to the IP prefix 192.0.2.2/32. 316 Its semantic is global within the IGP domain: any router forwards a 317 packet received with active segment 1002 to the next-hop along the 318 shortest-path to the related prefix. 320 9001 is a local IGP segment attached by node R2 to its north link to 321 R3. Its semantic is local to node R2: R2 switches a packet received 322 with active segment 9001 towards the north link to R3. 324 In conclusion, the path followed by P2 is R1-R2-north-link-R3-R8. 326 4.3. Example 3 328 R1 may send a packet P3 along the same exact path as P1 using a 329 different segment list {1002, 9003, 1008}. 331 9003 is a local IGP segment attached by node R2 to both its north and 332 south links to R3. Its semantic is local to node R2: R2 switches a 333 packet received with active segment 9003 towards either the north or 334 south links to R3 (e.g. per-flow loadbalancing decision). 336 In conclusion, the path followed by P3 is R1-R2-any-link-R3-R8. 338 4.4. Example 4 340 R1 may send a packet P4 to R8 while avoiding the links between R2 and 341 R3 by pushing an SR header with segment list {1004, 1008}. 343 1004 is a global IGP segment attached to the IP prefix 192.0.2.4/32. 344 Its semantic is global within the IGP domain: any router forwards a 345 packet received with active segment 1004 to the next-hop along the 346 shortest-path to the related prefix. 348 In conclusion, the path followed by P4 is R1-R2-R4-R3-R8. 350 4.5. Example 5 352 R1 may send a packet P5 to R8 while avoiding the links between R2 and 353 R3 while still benefitting from all the remaining shortest paths (via 354 R4 and R5) by pushing an SR header with segment list {2009, 1008}. 356 2009 is a global IGP segment attached to the anycast IP prefix 357 198.51.100.9/32. Its semantic is global within the IGP domain: any 358 router forwards a packet received with active segment 2009 to the 359 next-hop along the shortest-path to the related prefix. 361 In conclusion, the path followed by P5 is either R1-R2-R4-R3-R8 or 362 R1-R2-R5-R3-R8 . 364 5. Other Examples of MPLS Segments 366 In addition to the IGP segments previously described, the SPRING 367 source routing policy applied to MPLS can include MPLS LSP's signaled 368 by LDP, RSVPTE and BGP. The list of examples is non exhaustive. 369 Other form of segments combination can be instantiated through 370 Segment Routing (e.g.: RSVP LSPs combined with LDP or IGP or BGP 371 LSPs). 373 5.1. LDP LSP segment combined with IGP segments 375 The example illustrates a segment-routing policy including IGP 376 segments and LDP LSP segments. 378 SL1---S2---SL3---L4---SL5---S6 379 | | 380 +---------------+ 382 Figure 4: LDP LSP segment combined with IGP segments 384 We assume that: 386 o All links have an IGP cost of 1 except SL3-S6 link which has cost 387 2. 389 o All nodes are in the same IGP area. 391 o Nodes SL1, S2, SL3, SL5 and S6 are IGP-SR capable. 393 o SL3 and S6 have, respectively, index 3 and 6 assigned to them. 395 o All SR nodes have the same SRGB consisting of: [1000, 1999] 397 o SL1, SL3, L4 and SL5 are LDP capable. 399 o SL1 has a directed LDP session with SL3 and is able to retrieve 400 the SL3 local LDP mapping for FEC SL5: 35 402 o The following source-routed policy is defined in SL1 for the 403 traffic destined to S6: use path SL1-S2-SL3-L4-SL5-S6 (instead of 404 shortest-path SL1-S2-SL3-S6). 406 This is realized by programming the following segment-routing policy 407 at SL1: for traffic destined to S6, push the ordered segment list: 408 {1003, 35, 1006}, where: 410 o 1003 gets the packets from SL1 to SL3 via S2. 412 o 35 gets the packets from SL3 to SL5 via L4. 414 o 1006 gets the packets from SL5 to S6. 416 The above allows to steer the traffic into path SL1-S2-SL3-L4-SL5-S6 417 instead of the shortest path SL1-S2-SL3-S6. 419 5.2. RSVP-TE LSP segment combined with IGP segments 421 The example illustrates a segment-routing policy including IGP 422 segments and RSVP-TE LSP segments. 424 S1---S2---RS3---R4---RS5---S6 425 | | 426 +---------------+ 428 Figure 5: RSVP-TE LSP segment combined with IGP segments 430 We assume that: 432 o All links have an IGP cost of 1 except link RS3-S6 which has cost 433 2. 435 o All nodes are IGP-SR capable except R4. 437 o RS3 and S6 have, respectively, index 3 and 6 assigned to them. 439 o All SR nodes have the same SRGB consisting of: [1000, 1999] 441 o RS3, R4 and RS5 are RSVP-TE capable. 443 o An RSVP-TE LSP has been provisioned from RS3 to RS5 via R4. 445 o RS3 allocates a binding SID (with value of 135) for this RSVP-TE 446 LSP and signals it in the igp. 448 o The following source-routed policy is defined at S1 for the 449 traffic destined to S6: use path S1-S2-RS3-R4-RS5-S6 instead of 450 shortest-path S1-S2-RS3-S6. 452 This is realized by programming the following segment-routing policy 453 at S1: - for traffic destined to S6, push the ordered segment list: 454 {1003, 135, 1006}, where: 456 o 1003 gets the packets from S1 to RS3 via S2. 458 o 135 gets the packets from RS3 into the RSVP-TE LSP to RS5 via R4. 460 o 1006 gets the packets from RS5 to S6. 462 The above allows to steer the traffic into path S1-S2-RS3-R4-RS5-S6 463 instead of the shortest path S1-S2-RS3-S6. 465 6. Segment List History 467 In the abstract SR routing model [I-D.ietf-spring-segment-routing], 468 any node N along the journey of the packet is able to determine where 469 the packet P entered the SR domain and where it will exit. The 470 intermediate node is also able to determine the paths from the 471 ingress edge router to itself, and from itself to the egress edge 472 router. 474 In the MPLS instantiation, as the packet travels through the SR 475 domain, the stack is depleted and the segment list history is 476 gradually lost. 478 7. IANA Considerations 480 This document doesn't introduce any codepoint. 482 8. Manageability Considerations 484 TBD 486 9. Security Considerations 488 TBD 490 10. Contributors 492 The following contributors have substantially helped the definition 493 and editing of the content of this document: 495 Wim Henderickx 496 Email: wim.henderickx@alcatel-lucent.com 498 Igor Milojevic 499 Email: milojevicigor@gmail.com 500 Saku Ytti 501 Email: saku@ytti.fi 503 11. Acknowledgements 505 The authors would like to thank Les Ginsberg and Shah Himanshu for 506 their comments on this document. 508 12. References 510 12.1. Normative References 512 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 513 Requirement Levels", BCP 14, RFC 2119, 514 DOI 10.17487/RFC2119, March 1997, 515 . 517 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 518 (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, 519 December 1998, . 521 [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol 522 Label Switching Architecture", RFC 3031, 523 DOI 10.17487/RFC3031, January 2001, 524 . 526 [RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., 527 Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack 528 Encoding", RFC 3032, DOI 10.17487/RFC3032, January 2001, 529 . 531 12.2. Informative References 533 [I-D.filsfils-spring-segment-routing-ldp-interop] 534 Filsfils, C., Previdi, S., Bashandy, A., Decraene, B., 535 Litkowski, S., Horneffer, M., Milojevic, I., Shakir, R., 536 Ytti, S., Henderickx, W., Tantsura, J., and E. Crabbe, 537 "Segment Routing interoperability with LDP", draft- 538 filsfils-spring-segment-routing-ldp-interop-03 (work in 539 progress), March 2015. 541 [I-D.ietf-isis-segment-routing-extensions] 542 Previdi, S., Filsfils, C., Bashandy, A., Gredler, H., 543 Litkowski, S., Decraene, B., and J. Tantsura, "IS-IS 544 Extensions for Segment Routing", draft-ietf-isis-segment- 545 routing-extensions-06 (work in progress), December 2015. 547 [I-D.ietf-ospf-ospfv3-segment-routing-extensions] 548 Psenak, P., Previdi, S., Filsfils, C., Gredler, H., 549 Shakir, R., Henderickx, W., and J. Tantsura, "OSPFv3 550 Extensions for Segment Routing", draft-ietf-ospf-ospfv3- 551 segment-routing-extensions-04 (work in progress), December 552 2015. 554 [I-D.ietf-ospf-segment-routing-extensions] 555 Psenak, P., Previdi, S., Filsfils, C., Gredler, H., 556 Shakir, R., Henderickx, W., and J. Tantsura, "OSPF 557 Extensions for Segment Routing", draft-ietf-ospf-segment- 558 routing-extensions-06 (work in progress), December 2015. 560 [I-D.ietf-spring-problem-statement] 561 Previdi, S., Filsfils, C., Decraene, B., Litkowski, S., 562 Horneffer, M., and R. Shakir, "SPRING Problem Statement 563 and Requirements", draft-ietf-spring-problem-statement-07 564 (work in progress), March 2016. 566 [I-D.ietf-spring-segment-routing] 567 Filsfils, C., Previdi, S., Decraene, B., Litkowski, S., 568 and R. Shakir, "Segment Routing Architecture", draft-ietf- 569 spring-segment-routing-07 (work in progress), December 570 2015. 572 [RFC1940] Estrin, D., Li, T., Rekhter, Y., Varadhan, K., and D. 573 Zappala, "Source Demand Routing: Packet Format and 574 Forwarding Specification (Version 1)", RFC 1940, 575 DOI 10.17487/RFC1940, May 1996, 576 . 578 [RFC5443] Jork, M., Atlas, A., and L. Fang, "LDP IGP 579 Synchronization", RFC 5443, DOI 10.17487/RFC5443, March 580 2009, . 582 [RFC6138] Kini, S., Ed. and W. Lu, Ed., "LDP IGP Synchronization for 583 Broadcast Networks", RFC 6138, DOI 10.17487/RFC6138, 584 February 2011, . 586 Authors' Addresses 588 Clarence Filsfils (editor) 589 Cisco Systems, Inc. 590 Brussels 591 BE 593 Email: cfilsfil@cisco.com 594 Stefano Previdi (editor) 595 Cisco Systems, Inc. 596 Via Del Serafico, 200 597 Rome 00142 598 Italy 600 Email: sprevidi@cisco.com 602 Ahmed Bashandy 603 Cisco Systems, Inc. 604 170, West Tasman Drive 605 San Jose, CA 95134 606 US 608 Email: bashandy@cisco.com 610 Bruno Decraene 611 Orange 612 FR 614 Email: bruno.decraene@orange.com 616 Stephane Litkowski 617 Orange 618 FR 620 Email: stephane.litkowski@orange.com 622 Martin Horneffer 623 Deutsche Telekom 624 Hammer Str. 216-226 625 Muenster 48153 626 DE 628 Email: Martin.Horneffer@telekom.de 630 Rob Shakir 631 Jive Communications, Inc. 632 1275 West 1600 North, Suite 100 633 Orem, UT 84057 635 Email: rjs@rob.sh 636 Jeff Tantsura 637 Ericsson 638 300 Holger Way 639 San Jose, CA 95134 640 US 642 Email: Jeff.Tantsura@ericsson.com 644 Edward Crabbe 645 Individual 647 Email: edward.crabbe@gmail.com