idnits 2.17.1 draft-filsfils-spring-segment-routing-mpls-03.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 doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (July 31, 2014) is 3557 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 425 -- Looks like a reference, but probably isn't: '1999' on line 425 ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) == Outdated reference: A later version (-03) exists of draft-filsfils-spring-segment-routing-ldp-interop-01 == Outdated reference: A later version (-01) exists of draft-filsfils-spring-segment-routing-use-cases-00 == Outdated reference: A later version (-25) exists of draft-ietf-isis-segment-routing-extensions-02 == Outdated reference: A later version (-27) exists of draft-ietf-ospf-segment-routing-extensions-01 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: February 1, 2015 Cisco Systems, Inc. 6 B. Decraene 7 S. Litkowski 8 Orange 9 M. Horneffer 10 Deutsche Telekom 11 I. Milojevic 12 Telekom Srbija 13 R. Shakir 14 British Telecom 15 S. Ytti 16 TDC Oy 17 W. Henderickx 18 Alcatel-Lucent 19 J. Tantsura 20 Ericsson 21 E. Crabbe 22 Google, Inc. 23 July 31, 2014 25 Segment Routing with MPLS data plane 26 draft-filsfils-spring-segment-routing-mpls-03 28 Abstract 30 Segment Routing (SR) leverages the source routing paradigm. A node 31 steers a packet through a controlled set of instructions, called 32 segments, by prepending the packet with an SR header. A segment can 33 represent any instruction, topological or service-based. SR allows 34 to enforce a flow through any topological path and service chain 35 while maintaining per-flow state only at the ingress node to the SR 36 domain. 38 Segment Routing can be directly applied to the MPLS architecture with 39 no change in the forwarding plane. This drafts describes how Segment 40 Routing operates on top of the MPLS data plane. 42 Requirements Language 44 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 45 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 46 document are to be interpreted as described in RFC 2119 [RFC2119]. 48 Status of This Memo 50 This Internet-Draft is submitted in full conformance with the 51 provisions of BCP 78 and BCP 79. 53 Internet-Drafts are working documents of the Internet Engineering 54 Task Force (IETF). Note that other groups may also distribute 55 working documents as Internet-Drafts. The list of current Internet- 56 Drafts is at http://datatracker.ietf.org/drafts/current/. 58 Internet-Drafts are draft documents valid for a maximum of six months 59 and may be updated, replaced, or obsoleted by other documents at any 60 time. It is inappropriate to use Internet-Drafts as reference 61 material or to cite them other than as "work in progress." 63 This Internet-Draft will expire on February 1, 2015. 65 Copyright Notice 67 Copyright (c) 2014 IETF Trust and the persons identified as the 68 document authors. All rights reserved. 70 This document is subject to BCP 78 and the IETF Trust's Legal 71 Provisions Relating to IETF Documents 72 (http://trustee.ietf.org/license-info) in effect on the date of 73 publication of this document. Please review these documents 74 carefully, as they describe your rights and restrictions with respect 75 to this document. Code Components extracted from this document must 76 include Simplified BSD License text as described in Section 4.e of 77 the Trust Legal Provisions and are provided without warranty as 78 described in the Simplified BSD License. 80 Table of Contents 82 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 83 2. Illustration . . . . . . . . . . . . . . . . . . . . . . . . 3 84 3. MPLS Instantiation of Segment Routing . . . . . . . . . . . . 4 85 4. IGP Segments Examples . . . . . . . . . . . . . . . . . . . . 6 86 4.1. Example 1 . . . . . . . . . . . . . . . . . . . . . . . . 7 87 4.2. Example 2 . . . . . . . . . . . . . . . . . . . . . . . . 7 88 4.3. Example 3 . . . . . . . . . . . . . . . . . . . . . . . . 7 89 4.4. Example 4 . . . . . . . . . . . . . . . . . . . . . . . . 7 90 4.5. Example 5 . . . . . . . . . . . . . . . . . . . . . . . . 8 91 5. Other Examples of MPLS Segments . . . . . . . . . . . . . . . 8 92 5.1. LDP LSP segment combined with IGP segments . . . . . . . 8 93 5.2. RSVP-TE LSP segment combined with IGP segments . . . . . 9 94 6. Segment List History . . . . . . . . . . . . . . . . . . . . 10 95 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 96 8. Manageability Considerations . . . . . . . . . . . . . . . . 11 97 9. Security Considerations . . . . . . . . . . . . . . . . . . . 11 98 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 99 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 100 11.1. Normative References . . . . . . . . . . . . . . . . . . 11 101 11.2. Informative References . . . . . . . . . . . . . . . . . 11 102 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 104 1. Introduction 106 The Segment Routing architecture 107 [I-D.filsfils-spring-segment-routing] can be directly applied to the 108 MPLS architecture with no change in the MPLS forwarding plane. This 109 drafts describes how Segment Routing operates on top of the MPLS data 110 plane. 112 The Segment Routing use cases are described in in 113 [I-D.filsfils-spring-segment-routing-use-cases]. 115 Link State protocol extensions for Segment Routing are described in 116 [I-D.ietf-isis-segment-routing-extensions], 117 [I-D.ietf-ospf-segment-routing-extensions] and 118 [I-D.psenak-ospf-segment-routing-ospfv3-extension]. 120 2. Illustration 122 Segment Routing, applied to the MPLS data plane, offers the ability 123 to tunnel services (VPN, VPLS, VPWS) from an ingress PE to an egress 124 PE, without any other protocol than ISIS or OSPF 125 ([I-D.ietf-isis-segment-routing-extensions] and 126 [I-D.ietf-ospf-segment-routing-extensions]). LDP and RSVP-TE 127 signaling protocols are not required. 129 Note that [I-D.filsfils-spring-segment-routing-ldp-interop] documents 130 SR co-existence and interworking with other MPLS signaling protocols, 131 if present in the network during a migration, or in case of non- 132 homogeneous deployments. 134 The operator only needs to allocate one node segment per PE and the 135 SR IGP control-plane automatically builds the required MPLS 136 forwarding constructs from any PE to any PE. 138 P1---P2 139 / \ 140 A---CE1---PE1 PE2---CE2---Z 141 \ / 142 P4---P4 144 Figure 1: IGP-based MPLS Tunneling 146 In Figure 1 above, the four nodes A, CE1, CE2 and Z are part of the 147 same VPN. 149 PE2 advertises (in the IGP) a host address 192.0.2.2/32 with its 150 attached node segment 102. 152 CE2 advertises to PE2 a route to Z. PE2 binds a local label LZ to 153 that route and propagates the route and its label via MPBGP to PE1 154 with nhop 192.0.2.2 (PE2 loopback address). 156 PE1 installs the VPN prefix Z in the appropriate VRF and resolves the 157 next-hop onto the node segment 102. Upon receiving a packet from A 158 destined to Z, PE1 pushes two labels onto the packet: the top label 159 is 102, the bottom label is LZ. 102 identifies the node segment to 160 PE2 and hence transports the packet along the ECMP-aware shortest- 161 path to PE2. PE2 then processes the VPN label LZ and forwards the 162 packet to CE2. 164 Supporting MPLS services (VPN, VPLS, VPWS) with SR has the following 165 benefits: 167 Simple operation: one single intra-domain protocol to operate: the 168 IGP. No need to support IGP synchronization extensions as 169 described in [RFC5443] and [RFC6138]. 171 Excellent scaling: one Node-SID per PE. 173 3. MPLS Instantiation of Segment Routing 175 MPLS instantiation of Segment Routing fits in the MPLS architecture 176 as defined in [RFC3031] both from a control plane and forwarding 177 plane perspective: 179 o From a control plane perspective [RFC3031]does not mandate a 180 single signaling protocol. Segment Routing proposes to use the 181 Link State IGP as its use of information flooding fits very well 182 with label stacking on ingress. 184 o From a forwarding plane perspective, Segment Routing does not 185 require any change to the forwarding plane. 187 When applied to MPLS, a Segment is a LSP and the 20 right-most bits 188 of the segment are encoded as a label. This implies that, in the 189 MPLS instantiation, the SID values are allocated within a reduced 190 20-bit space out of the 32-bit SID space. 192 The notion of indexed global segment fits the MPLS architecture 193 [RFC3031] as the absolute value allocated to any segment (global or 194 local) can be managed by a local allocation process (similarly to 195 other MPLS signaling protocols). 197 If present, SR can coexist and interwork with LDP and RSVP 198 [I-D.filsfils-spring-segment-routing-ldp-interop]. 200 The source routing model described in 201 [I-D.filsfils-spring-segment-routing] is inherited from the ones 202 proposed by [RFC1940] and [RFC2460]. The source routing model offers 203 the support for explicit routing capability. 205 Contrary to RSVP-based explicit routes where tunnel midpoints 206 maintain states, SR-based explicit routes only require per-flow 207 states at the ingress edge router where the traffic engineer policy 208 is applied. 210 Contrary to RSVP-based explicit routes which consist in non-ECMP 211 circuits (similar to ATM/FR), SR-based explicit routes can be built 212 as list of ECMP-aware node segments and hence ECMP-aware traffic 213 engineering is natively supported by SR. 215 When Segment Routing is instantiated over the MPLS data plane the 216 following applies: 218 A list of segments is represented as a stack of labels. 220 The active segment is the top label. 222 The CONTINUE operation is implemented as an MPLS swap operation. 223 When the same Segment Routing Global Block (SRGB, defined in 224 [I-D.filsfils-spring-segment-routing] is used throughout the SR 225 domain, the outgoing label value is equal to the incoming label 226 value . Else, the outgoing label value is [SRGB(next_hop)+index] 228 The NEXT operation is implemented as an MPLS pop operation. 230 The PUSH operation is implemented as an MPLS push of a label 231 stack. 233 In conclusion, there are no changes in the operations of the data- 234 plane currently used in MPLS networks. 236 4. IGP Segments Examples 238 Assuming the network diagram of Figure 2 and the IP address and IGP 239 Segment allocation of Figure 3, the following examples can be 240 constructed. 242 +--------+ 243 / \ 244 R1-----R2----------R3-----R8 245 | \ / | 246 | +--R4--+ | 247 | | 248 +-----R5-----+ 250 Figure 2: IGP Segments - Illustration 252 +-----------------------------------------------------------+ 253 | IP address allocated by the operator: | 254 | 192.0.2.1/32 as a loopback of R1 | 255 | 192.0.2.2/32 as a loopback of R2 | 256 | 192.0.2.3/32 as a loopback of R3 | 257 | 192.0.2.4/32 as a loopback of R4 | 258 | 192.0.2.5/32 as a loopback of R5 | 259 | 192.0.2.8/32 as a loopback of R8 | 260 | 198.51.100.9/32 as an anycast loopback of R4 | 261 | 198.51.100.9/32 as an anycast loopback of R5 | 262 | | 263 | SRGB defined by the operator as 1000-5000 | 264 | | 265 | Global IGP SID allocated by the operator: | 266 | 1001 allocated to 192.0.2.1/32 | 267 | 1002 allocated to 192.0.2.2/32 | 268 | 1003 allocated to 192.0.2.3/32 | 269 | 1004 allocated to 192.0.2.4/32 | 270 | 1008 allocated to 192.0.2.8/32 | 271 | 2009 allocated to 198.51.100.9/32 | 272 | | 273 | Local IGP SID allocated dynamically by R2 | 274 | for its "north" adjacency to R3: 9001 | 275 | for its "north" adjacency to R3: 9003 | 276 | for its "south" adjacency to R3: 9002 | 277 | for its "south" adjacency to R3: 9003 | 278 +-----------------------------------------------------------+ 280 Figure 3: IGP Address and Segment Allocation - Illustration 282 4.1. Example 1 284 R1 may send a packet P1 to R8 simply by pushing an SR header with 285 segment list {1008}. 287 1008 is a global IGP segment attached to the IP prefix 192.0.2.8/32. 288 Its semantic is global within the IGP domain: any router forwards a 289 packet received with active segment 1008 to the next-hop along the 290 ECMP-aware shortest-path to the related prefix. 292 In conclusion, the path followed by P1 is R1-R2--R3-R8. The ECMP- 293 awareness ensures that the traffic be load-shared between any ECMP 294 path, in this case the two north and south links between R2 and R3. 296 4.2. Example 2 298 R1 may send a packet P2 to R8 by pushing an SR header with segment 299 list {1002, 9001, 1008}. 301 1002 is a global IGP segment attached to the IP prefix 192.0.2.2/32. 302 Its semantic is global within the IGP domain: any router forwards a 303 packet received with active segment 1002 to the next-hop along the 304 shortest-path to the related prefix. 306 9001 is a local IGP segment attached by node R2 to its north link to 307 R3. Its semantic is local to node R2: R2 switches a packet received 308 with active segment 9001 towards the north link to R3. 310 In conclusion, the path followed by P2 is R1-R2-north-link-R3-R8. 312 4.3. Example 3 314 R1 may send a packet P3 along the same exact path as P1 using a 315 different segment list {1002, 9003, 1008}. 317 9003 is a local IGP segment attached by node R2 to both its north and 318 south links to R3. Its semantic is local to node R2: R2 switches a 319 packet received with active segment 9003 towards either the north or 320 south links to R3 (e.g. per-flow loadbalancing decision). 322 In conclusion, the path followed by P3 is R1-R2-any-link-R3-R8. 324 4.4. Example 4 326 R1 may send a packet P4 to R8 while avoiding the links between R2 and 327 R3 by pushing an SR header with segment list {1004, 1008}. 329 1004 is a global IGP segment attached to the IP prefix 192.0.2.4/32. 330 Its semantic is global within the IGP domain: any router forwards a 331 packet received with active segment 1004 to the next-hop along the 332 shortest-path to the related prefix. 334 In conclusion, the path followed by P4 is R1-R2-R4-R3-R8. 336 4.5. Example 5 338 R1 may send a packet P5 to R8 while avoiding the links between R2 and 339 R3 while still benefitting from all the remaining shortest paths (via 340 R4 and R5) by pushing an SR header with segment list {2009, 1008}. 342 2009 is a global IGP segment attached to the anycast IP prefix 343 198.51.100.9/32. Its semantic is global within the IGP domain: any 344 router forwards a packet received with active segment 2009 to the 345 next-hop along the shortest-path to the related prefix. 347 In conclusion, the path followed by P5 is either R1-R2-R4-R3-R8 or 348 R1-R2-R5-R3-R8 . 350 5. Other Examples of MPLS Segments 352 In addition to the IGP segments previously described, the SPRING 353 source routing policy applied to MPLS can include MPLS LSP's signaled 354 by LDP, RSVPTE and BGP. The list of examples is non exhaustive. 355 Other form of segments combination can be instantiated through 356 Segment Routing (e.g.: RSVP LSPs combined with LDP or IGP or BGP 357 LSPs). 359 5.1. LDP LSP segment combined with IGP segments 361 The example illustrates a segment-routing policy including IGP 362 segments and LDP LSP segments. 364 SL1---S2---SL3---L4---SL5---S6 365 | | 366 +---------------+ 368 Figure 4: LDP LSP segment combined with IGP segments 370 We assume that: 372 o All links have an IGP cost of 1 except SL3-S6 link which has cost 373 2. 375 o All nodes are in the same IGP area. 377 o Nodes SL1, S2, SL3, SL5 and S6 are IGP-SR capable. 379 o SL3 and S6 have, respectively, index 3 and 6 assigned to them. 381 o All SR nodes have the same SRGB consisting of: [1000, 1999] 383 o SL1, SL3, L4 and SL5 are LDP capable. 385 o SL1 has a directed LDP session with SL3 and is able to retrieve 386 the SL3 local LDP mapping for FEC SL5: 35 388 o The following source-routed policy is defined in S1 for the 389 traffic destined to S6: use path SL1-S2-SL3-L4-SL5-S6 (instead of 390 shortest-path SL1-S2-SL3-S6). 392 This is realized by programming the following segment-routing policy 393 at S1: for traffic destined to S6, push the ordered segment list: 394 {1003, 35, 1006}, where: 396 o 1003 gets the packets from S1 to SL3 via S2. 398 o 35 gets the packets from SL3 to SL5 via L4. 400 o 1006 gets the packets from SL5 to S6. 402 The above allows to steer the traffic into path SL1-S2-SL3-L4-SL5-S6 403 instead of the shortest path SL1-S2-SL3-S6. 405 5.2. RSVP-TE LSP segment combined with IGP segments 407 The example illustrates a segment-routing policy including IGP 408 segments and RSVP-TE LSP segments. 410 S1---S2---RS3---R4---RS5---S6 411 | | 412 +---------------+ 414 Figure 5: RSVP-TE LSP segment combined with IGP segments 416 We assume that: 418 o All links have an IGP cost of 1 except link RS3-S6 which has cost 419 2. 421 o All nodes are IGP-SR capable except R4. 423 o RS3 and R6 have, respectively, index 3 and 6 assigned to them. 425 o All SR nodes have the same SRGB consisting of: [1000, 1999] 427 o RS3, R4 and RS5 are RSVP-TE capable. 429 o An RSVP-TE LSP has been provisioned from RS3 to RS5 via R4. 431 o RS3 allocates a binding SID (with value of 135) for this RSVP-TE 432 LSP and signals it in the igp. 434 o The following source-routed policy is defined at S1 for the 435 traffic destined to S6: use path S1-S2-RS3-R4-RS5-S6 instead of 436 shortest-path S1-S2-RS3-S6. 438 This is realized by programming the following segment-routing policy 439 at S1: - for traffic destined to S6, push the ordered segment list: 440 {1003, 135, 1006}, where: 442 o 1003 gets the packets from S1 to RS3 via S2. 444 o 135 gets the packets from RS3 into the RSVP-TE LSP to RS5 via R4. 446 o 1006 gets the packets from RS5 to S6. 448 The above allows to steer the traffic into path S1-S2-RS3-R4-RS5-S6 449 instead of the shortest path S1-S2-RS3-S6. 451 6. Segment List History 453 In the abstract SR routing model 454 [I-D.filsfils-spring-segment-routing], any node N along the journey 455 of the packet is able to determine where the packet P entered the SR 456 domain and where it will exit. The intermediate node is also able to 457 determine the paths from the ingress edge router to itself, and from 458 itself to the egress edge router. 460 In the MPLS instantiation, as the packet travels through the SR 461 domain, the stack is depleted and the segment list history is 462 gradually lost. 464 Future version of this document will describe how this information 465 can be preserved in MPLS domains. 467 7. IANA Considerations 469 TBD 471 8. Manageability Considerations 473 TBD 475 9. Security Considerations 477 TBD 479 10. Acknowledgements 481 11. References 483 11.1. Normative References 485 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 486 Requirement Levels", BCP 14, RFC 2119, March 1997. 488 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 489 (IPv6) Specification", RFC 2460, December 1998. 491 [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol 492 Label Switching Architecture", RFC 3031, January 2001. 494 11.2. Informative References 496 [I-D.filsfils-spring-segment-routing] 497 Filsfils, C., Previdi, S., Bashandy, A., Decraene, B., 498 Litkowski, S., Horneffer, M., Milojevic, I., Shakir, R., 499 Ytti, S., Henderickx, W., Tantsura, J., and E. Crabbe, 500 "Segment Routing Architecture", draft-filsfils-spring- 501 segment-routing-04 (work in progress), July 2014. 503 [I-D.filsfils-spring-segment-routing-ldp-interop] 504 Filsfils, C., Previdi, S., Bashandy, A., Decraene, B., 505 Litkowski, S., Horneffer, M., Milojevic, I., Shakir, R., 506 Ytti, S., Henderickx, W., Tantsura, J., and E. Crabbe, 507 "Segment Routing interoperability with LDP", draft- 508 filsfils-spring-segment-routing-ldp-interop-01 (work in 509 progress), April 2014. 511 [I-D.filsfils-spring-segment-routing-use-cases] 512 Filsfils, C., Francois, P., Previdi, S., Decraene, B., 513 Litkowski, S., Horneffer, M., Milojevic, I., Shakir, R., 514 Ytti, S., Henderickx, W., Tantsura, J., Kini, S., and E. 515 Crabbe, "Segment Routing Use Cases", draft-filsfils- 516 spring-segment-routing-use-cases-00 (work in progress), 517 March 2014. 519 [I-D.ietf-isis-segment-routing-extensions] 520 Previdi, S., Filsfils, C., Bashandy, A., Gredler, H., 521 Litkowski, S., Decraene, B., and J. Tantsura, "IS-IS 522 Extensions for Segment Routing", draft-ietf-isis-segment- 523 routing-extensions-02 (work in progress), June 2014. 525 [I-D.ietf-ospf-segment-routing-extensions] 526 Psenak, P., Previdi, S., Filsfils, C., Gredler, H., 527 Shakir, R., Henderickx, W., and J. Tantsura, "OSPF 528 Extensions for Segment Routing", draft-ietf-ospf-segment- 529 routing-extensions-01 (work in progress), July 2014. 531 [I-D.psenak-ospf-segment-routing-ospfv3-extension] 532 Psenak, P., Previdi, S., Filsfils, C., Gredler, H., 533 Shakir, R., Henderickx, W., and J. Tantsura, "OSPFv3 534 Extensions for Segment Routing", draft-psenak-ospf- 535 segment-routing-ospfv3-extension-02 (work in progress), 536 July 2014. 538 [RFC1940] Estrin, D., Li, T., Rekhter, Y., Varadhan, K., and D. 539 Zappala, "Source Demand Routing: Packet Format and 540 Forwarding Specification (Version 1)", RFC 1940, May 1996. 542 [RFC5443] Jork, M., Atlas, A., and L. Fang, "LDP IGP 543 Synchronization", RFC 5443, March 2009. 545 [RFC6138] Kini, S. and W. Lu, "LDP IGP Synchronization for Broadcast 546 Networks", RFC 6138, February 2011. 548 [draft-filsfils-rtgwg-segment-routing-ldp-interop-00] 549 Filsfils, C. and S. Previdi, "Segment Routing 550 interoperability with LDP", October 2013. 552 Authors' Addresses 554 Clarence Filsfils (editor) 555 Cisco Systems, Inc. 556 Brussels 557 BE 559 Email: cfilsfil@cisco.com 560 Stefano Previdi (editor) 561 Cisco Systems, Inc. 562 Via Del Serafico, 200 563 Rome 00142 564 Italy 566 Email: sprevidi@cisco.com 568 Ahmed Bashandy 569 Cisco Systems, Inc. 570 170, West Tasman Drive 571 San Jose, CA 95134 572 US 574 Email: bashandy@cisco.com 576 Bruno Decraene 577 Orange 578 FR 580 Email: bruno.decraene@orange.com 582 Stephane Litkowski 583 Orange 584 FR 586 Email: stephane.litkowski@orange.com 588 Martin Horneffer 589 Deutsche Telekom 590 Hammer Str. 216-226 591 Muenster 48153 592 DE 594 Email: Martin.Horneffer@telekom.de 596 Igor Milojevic 597 Telekom Srbija 598 Takovska 2 599 Belgrade 600 RS 602 Email: igormilojevic@telekom.rs 603 Rob Shakir 604 British Telecom 605 London 606 UK 608 Email: rob.shakir@bt.com 610 Saku Ytti 611 TDC Oy 612 Mechelininkatu 1a 613 TDC 00094 614 FI 616 Email: saku@ytti.fi 618 Wim Henderickx 619 Alcatel-Lucent 620 Copernicuslaan 50 621 Antwerp 2018 622 BE 624 Email: wim.henderickx@alcatel-lucent.com 626 Jeff Tantsura 627 Ericsson 628 300 Holger Way 629 San Jose, CA 95134 630 US 632 Email: Jeff.Tantsura@ericsson.com 634 Edward Crabbe 635 Google, Inc. 636 1600 Amphitheatre Parkway 637 Mountain View, CA 94043 638 US 640 Email: edc@google.com