idnits 2.17.1 draft-ietf-spring-segment-routing-mpls-00.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 (November 24, 2014) is 3441 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 424 -- Looks like a reference, but probably isn't: '1999' on line 424 ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) == Outdated reference: A later version (-03) exists of draft-filsfils-spring-segment-routing-ldp-interop-02 == Outdated reference: A later version (-25) exists of draft-ietf-isis-segment-routing-extensions-03 == Outdated reference: A later version (-27) exists of draft-ietf-ospf-segment-routing-extensions-02 Summary: 1 error (**), 0 flaws (~~), 4 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: May 28, 2015 Cisco Systems, Inc. 6 B. Decraene 7 S. Litkowski 8 Orange 9 M. Horneffer 10 Deutsche Telekom 11 R. Shakir 12 British Telecom 13 J. Tantsura 14 Ericsson 15 E. Crabbe 16 Individual 17 November 24, 2014 19 Segment Routing with MPLS data plane 20 draft-ietf-spring-segment-routing-mpls-00 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 May 28, 2015. 59 Copyright Notice 61 Copyright (c) 2014 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 . . . . . . . . . . . . . . . . . . . . 5 80 4.1. Example 1 . . . . . . . . . . . . . . . . . . . . . . . . 6 81 4.2. Example 2 . . . . . . . . . . . . . . . . . . . . . . . . 7 82 4.3. Example 3 . . . . . . . . . . . . . . . . . . . . . . . . 7 83 4.4. Example 4 . . . . . . . . . . . . . . . . . . . . . . . . 7 84 4.5. Example 5 . . . . . . . . . . . . . . . . . . . . . . . . 8 85 5. Other Examples of MPLS Segments . . . . . . . . . . . . . . . 8 86 5.1. LDP LSP segment combined with IGP segments . . . . . . . 8 87 5.2. RSVP-TE LSP segment combined with IGP segments . . . . . 9 88 6. Segment List History . . . . . . . . . . . . . . . . . . . . 10 89 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 90 8. Manageability Considerations . . . . . . . . . . . . . . . . 10 91 9. Security Considerations . . . . . . . . . . . . . . . . . . . 10 92 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 11 93 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 94 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 95 12.1. Normative References . . . . . . . . . . . . . . . . . . 11 96 12.2. Informative References . . . . . . . . . . . . . . . . . 11 98 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 100 1. Introduction 102 The Segment Routing architecture 103 [I-D.filsfils-spring-segment-routing] can be directly applied to the 104 MPLS architecture with no change in the MPLS forwarding plane. This 105 drafts describes how Segment Routing operates on top of the MPLS data 106 plane. 108 The Segment Routing use cases are described in in 109 [I-D.filsfils-spring-segment-routing-use-cases]. 111 Link State protocol extensions for Segment Routing are described in 112 [I-D.ietf-isis-segment-routing-extensions], 113 [I-D.ietf-ospf-segment-routing-extensions] and 114 [I-D.psenak-ospf-segment-routing-ospfv3-extension]. 116 2. Illustration 118 Segment Routing, applied to the MPLS data plane, offers the ability 119 to tunnel services (VPN, VPLS, VPWS) from an ingress PE to an egress 120 PE, without any other protocol than ISIS or OSPF 121 ([I-D.ietf-isis-segment-routing-extensions] and 122 [I-D.ietf-ospf-segment-routing-extensions]). LDP and RSVP-TE 123 signaling protocols are not required. 125 Note that [I-D.filsfils-spring-segment-routing-ldp-interop] documents 126 SR co-existence and interworking with other MPLS signaling protocols, 127 if present in the network during a migration, or in case of non- 128 homogeneous deployments. 130 The operator only needs to allocate one node segment per PE and the 131 SR IGP control-plane automatically builds the required MPLS 132 forwarding constructs from any PE to any PE. 134 P1---P2 135 / \ 136 A---CE1---PE1 PE2---CE2---Z 137 \ / 138 P4---P4 140 Figure 1: IGP-based MPLS Tunneling 142 In Figure 1 above, the four nodes A, CE1, CE2 and Z are part of the 143 same VPN. 145 PE2 advertises (in the IGP) a host address 192.0.2.2/32 with its 146 attached node segment 102. 148 CE2 advertises to PE2 a route to Z. PE2 binds a local label LZ to 149 that route and propagates the route and its label via MPBGP to PE1 150 with nhop 192.0.2.2 (PE2 loopback address). 152 PE1 installs the VPN prefix Z in the appropriate VRF and resolves the 153 next-hop onto the node segment 102. Upon receiving a packet from A 154 destined to Z, PE1 pushes two labels onto the packet: the top label 155 is 102, the bottom label is LZ. 102 identifies the node segment to 156 PE2 and hence transports the packet along the ECMP-aware shortest- 157 path to PE2. PE2 then processes the VPN label LZ and forwards the 158 packet to CE2. 160 Supporting MPLS services (VPN, VPLS, VPWS) with SR has the following 161 benefits: 163 Simple operation: one single intra-domain protocol to operate: the 164 IGP. No need to support IGP synchronization extensions as 165 described in [RFC5443] and [RFC6138]. 167 Excellent scaling: one Node-SID per PE. 169 3. MPLS Instantiation of Segment Routing 171 MPLS instantiation of Segment Routing fits in the MPLS architecture 172 as defined in [RFC3031] both from a control plane and forwarding 173 plane perspective: 175 o From a control plane perspective [RFC3031]does not mandate a 176 single signaling protocol. Segment Routing proposes to use the 177 Link State IGP as its use of information flooding fits very well 178 with label stacking on ingress. 180 o From a forwarding plane perspective, Segment Routing does not 181 require any change to the forwarding plane. 183 When applied to MPLS, a Segment is a LSP and the 20 right-most bits 184 of the segment are encoded as a label. This implies that, in the 185 MPLS instantiation, the SID values are allocated within a reduced 186 20-bit space out of the 32-bit SID space. 188 The notion of indexed global segment fits the MPLS architecture 189 [RFC3031] as the absolute value allocated to any segment (global or 190 local) can be managed by a local allocation process (similarly to 191 other MPLS signaling protocols). 193 If present, SR can coexist and interwork with LDP and RSVP 194 [I-D.filsfils-spring-segment-routing-ldp-interop]. 196 The source routing model described in 197 [I-D.filsfils-spring-segment-routing] is inherited from the ones 198 proposed by [RFC1940] and [RFC2460]. The source routing model offers 199 the support for explicit routing capability. 201 Contrary to RSVP-based explicit routes where tunnel midpoints 202 maintain states, SR-based explicit routes only require per-flow 203 states at the ingress edge router where the traffic engineer policy 204 is applied. 206 Contrary to RSVP-based explicit routes which consist in non-ECMP 207 circuits (similar to ATM/FR), SR-based explicit routes can be built 208 as list of ECMP-aware node segments and hence ECMP-aware traffic 209 engineering is natively supported by SR. 211 When Segment Routing is instantiated over the MPLS data plane the 212 following applies: 214 A list of segments is represented as a stack of labels. 216 The active segment is the top label. 218 The CONTINUE operation is implemented as an MPLS swap operation. 219 When the same Segment Routing Global Block (SRGB, defined in 220 [I-D.filsfils-spring-segment-routing] is used throughout the SR 221 domain, the outgoing label value is equal to the incoming label 222 value . Else, the outgoing label value is [SRGB(next_hop)+index] 224 The NEXT operation is implemented as an MPLS pop operation. 226 The PUSH operation is implemented as an MPLS push of a label 227 stack. 229 The SRGB values MUST by greater than 15 in order to preserve 230 values 0-15 as defined in [RFC3032]. 232 In conclusion, there are no changes in the operations of the data- 233 plane currently used in MPLS networks. 235 4. IGP Segments Examples 237 Assuming the network diagram of Figure 2 and the IP address and IGP 238 Segment allocation of Figure 3, the following examples can be 239 constructed. 241 +--------+ 242 / \ 243 R1-----R2----------R3-----R8 244 | \ / | 245 | +--R4--+ | 246 | | 247 +-----R5-----+ 249 Figure 2: IGP Segments - Illustration 251 +-----------------------------------------------------------+ 252 | IP address allocated by the operator: | 253 | 192.0.2.1/32 as a loopback of R1 | 254 | 192.0.2.2/32 as a loopback of R2 | 255 | 192.0.2.3/32 as a loopback of R3 | 256 | 192.0.2.4/32 as a loopback of R4 | 257 | 192.0.2.5/32 as a loopback of R5 | 258 | 192.0.2.8/32 as a loopback of R8 | 259 | 198.51.100.9/32 as an anycast loopback of R4 | 260 | 198.51.100.9/32 as an anycast loopback of R5 | 261 | | 262 | SRGB defined by the operator as 1000-5000 | 263 | | 264 | Global IGP SID allocated by the operator: | 265 | 1001 allocated to 192.0.2.1/32 | 266 | 1002 allocated to 192.0.2.2/32 | 267 | 1003 allocated to 192.0.2.3/32 | 268 | 1004 allocated to 192.0.2.4/32 | 269 | 1008 allocated to 192.0.2.8/32 | 270 | 2009 allocated to 198.51.100.9/32 | 271 | | 272 | Local IGP SID allocated dynamically by R2 | 273 | for its "north" adjacency to R3: 9001 | 274 | for its "north" adjacency to R3: 9003 | 275 | for its "south" adjacency to R3: 9002 | 276 | for its "south" adjacency to R3: 9003 | 277 +-----------------------------------------------------------+ 279 Figure 3: IGP Address and Segment Allocation - Illustration 281 4.1. Example 1 283 R1 may send a packet P1 to R8 simply by pushing an SR header with 284 segment list {1008}. 286 1008 is a global IGP segment attached to the IP prefix 192.0.2.8/32. 287 Its semantic is global within the IGP domain: any router forwards a 288 packet received with active segment 1008 to the next-hop along the 289 ECMP-aware shortest-path to the related prefix. 291 In conclusion, the path followed by P1 is R1-R2--R3-R8. The ECMP- 292 awareness ensures that the traffic be load-shared between any ECMP 293 path, in this case the two north and south links between R2 and R3. 295 4.2. Example 2 297 R1 may send a packet P2 to R8 by pushing an SR header with segment 298 list {1002, 9001, 1008}. 300 1002 is a global IGP segment attached to the IP prefix 192.0.2.2/32. 301 Its semantic is global within the IGP domain: any router forwards a 302 packet received with active segment 1002 to the next-hop along the 303 shortest-path to the related prefix. 305 9001 is a local IGP segment attached by node R2 to its north link to 306 R3. Its semantic is local to node R2: R2 switches a packet received 307 with active segment 9001 towards the north link to R3. 309 In conclusion, the path followed by P2 is R1-R2-north-link-R3-R8. 311 4.3. Example 3 313 R1 may send a packet P3 along the same exact path as P1 using a 314 different segment list {1002, 9003, 1008}. 316 9003 is a local IGP segment attached by node R2 to both its north and 317 south links to R3. Its semantic is local to node R2: R2 switches a 318 packet received with active segment 9003 towards either the north or 319 south links to R3 (e.g. per-flow loadbalancing decision). 321 In conclusion, the path followed by P3 is R1-R2-any-link-R3-R8. 323 4.4. Example 4 325 R1 may send a packet P4 to R8 while avoiding the links between R2 and 326 R3 by pushing an SR header with segment list {1004, 1008}. 328 1004 is a global IGP segment attached to the IP prefix 192.0.2.4/32. 329 Its semantic is global within the IGP domain: any router forwards a 330 packet received with active segment 1004 to the next-hop along the 331 shortest-path to the related prefix. 333 In conclusion, the path followed by P4 is R1-R2-R4-R3-R8. 335 4.5. Example 5 337 R1 may send a packet P5 to R8 while avoiding the links between R2 and 338 R3 while still benefitting from all the remaining shortest paths (via 339 R4 and R5) by pushing an SR header with segment list {2009, 1008}. 341 2009 is a global IGP segment attached to the anycast IP prefix 342 198.51.100.9/32. Its semantic is global within the IGP domain: any 343 router forwards a packet received with active segment 2009 to the 344 next-hop along the shortest-path to the related prefix. 346 In conclusion, the path followed by P5 is either R1-R2-R4-R3-R8 or 347 R1-R2-R5-R3-R8 . 349 5. Other Examples of MPLS Segments 351 In addition to the IGP segments previously described, the SPRING 352 source routing policy applied to MPLS can include MPLS LSP's signaled 353 by LDP, RSVPTE and BGP. The list of examples is non exhaustive. 354 Other form of segments combination can be instantiated through 355 Segment Routing (e.g.: RSVP LSPs combined with LDP or IGP or BGP 356 LSPs). 358 5.1. LDP LSP segment combined with IGP segments 360 The example illustrates a segment-routing policy including IGP 361 segments and LDP LSP segments. 363 SL1---S2---SL3---L4---SL5---S6 364 | | 365 +---------------+ 367 Figure 4: LDP LSP segment combined with IGP segments 369 We assume that: 371 o All links have an IGP cost of 1 except SL3-S6 link which has cost 372 2. 374 o All nodes are in the same IGP area. 376 o Nodes SL1, S2, SL3, SL5 and S6 are IGP-SR capable. 378 o SL3 and S6 have, respectively, index 3 and 6 assigned to them. 380 o All SR nodes have the same SRGB consisting of: [1000, 1999] 382 o SL1, SL3, L4 and SL5 are LDP capable. 384 o SL1 has a directed LDP session with SL3 and is able to retrieve 385 the SL3 local LDP mapping for FEC SL5: 35 387 o The following source-routed policy is defined in SL1 for the 388 traffic destined to S6: use path SL1-S2-SL3-L4-SL5-S6 (instead of 389 shortest-path SL1-S2-SL3-S6). 391 This is realized by programming the following segment-routing policy 392 at S1: for traffic destined to S6, push the ordered segment list: 393 {1003, 35, 1006}, where: 395 o 1003 gets the packets from S1 to SL3 via S2. 397 o 35 gets the packets from SL3 to SL5 via L4. 399 o 1006 gets the packets from SL5 to S6. 401 The above allows to steer the traffic into path SL1-S2-SL3-L4-SL5-S6 402 instead of the shortest path SL1-S2-SL3-S6. 404 5.2. RSVP-TE LSP segment combined with IGP segments 406 The example illustrates a segment-routing policy including IGP 407 segments and RSVP-TE LSP segments. 409 S1---S2---RS3---R4---RS5---S6 410 | | 411 +---------------+ 413 Figure 5: RSVP-TE LSP segment combined with IGP segments 415 We assume that: 417 o All links have an IGP cost of 1 except link RS3-S6 which has cost 418 2. 420 o All nodes are IGP-SR capable except R4. 422 o RS3 and R6 have, respectively, index 3 and 6 assigned to them. 424 o All SR nodes have the same SRGB consisting of: [1000, 1999] 426 o RS3, R4 and RS5 are RSVP-TE capable. 428 o An RSVP-TE LSP has been provisioned from RS3 to RS5 via R4. 430 o RS3 allocates a binding SID (with value of 135) for this RSVP-TE 431 LSP and signals it in the igp. 433 o The following source-routed policy is defined at S1 for the 434 traffic destined to S6: use path S1-S2-RS3-R4-RS5-S6 instead of 435 shortest-path S1-S2-RS3-S6. 437 This is realized by programming the following segment-routing policy 438 at S1: - for traffic destined to S6, push the ordered segment list: 439 {1003, 135, 1006}, where: 441 o 1003 gets the packets from S1 to RS3 via S2. 443 o 135 gets the packets from RS3 into the RSVP-TE LSP to RS5 via R4. 445 o 1006 gets the packets from RS5 to S6. 447 The above allows to steer the traffic into path S1-S2-RS3-R4-RS5-S6 448 instead of the shortest path S1-S2-RS3-S6. 450 6. Segment List History 452 In the abstract SR routing model 453 [I-D.filsfils-spring-segment-routing], any node N along the journey 454 of the packet is able to determine where the packet P entered the SR 455 domain and where it will exit. The intermediate node is also able to 456 determine the paths from the ingress edge router to itself, and from 457 itself to the egress edge router. 459 In the MPLS instantiation, as the packet travels through the SR 460 domain, the stack is depleted and the segment list history is 461 gradually lost. 463 Future version of this document will describe how this information 464 can be preserved in MPLS domains. 466 7. IANA Considerations 468 TBD 470 8. Manageability Considerations 472 TBD 474 9. Security Considerations 476 TBD 478 10. Contributors 480 The following contributors have substantially helped the definition 481 and editing of the content of this document: 483 Wim Henderickx 484 Email: wim.henderickx@alcatel-lucent.com 486 Igor Milojevic 487 Email: milojevicigor@gmail.com 489 Saku Ytti 490 Email: saku@ytti.fi 492 11. Acknowledgements 494 12. References 496 12.1. Normative References 498 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 499 Requirement Levels", BCP 14, RFC 2119, March 1997. 501 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 502 (IPv6) Specification", RFC 2460, December 1998. 504 [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol 505 Label Switching Architecture", RFC 3031, January 2001. 507 [RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., 508 Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack 509 Encoding", RFC 3032, January 2001. 511 12.2. Informative References 513 [I-D.filsfils-spring-segment-routing] 514 Filsfils, C., Previdi, S., Bashandy, A., Decraene, B., 515 Litkowski, S., Horneffer, M., Milojevic, I., Shakir, R., 516 Ytti, S., Henderickx, W., Tantsura, J., and E. Crabbe, 517 "Segment Routing Architecture", draft-filsfils-spring- 518 segment-routing-04 (work in progress), July 2014. 520 [I-D.filsfils-spring-segment-routing-ldp-interop] 521 Filsfils, C., Previdi, S., Bashandy, A., Decraene, B., 522 Litkowski, S., Horneffer, M., Milojevic, I., Shakir, R., 523 Ytti, S., Henderickx, W., Tantsura, J., and E. Crabbe, 524 "Segment Routing interoperability with LDP", draft- 525 filsfils-spring-segment-routing-ldp-interop-02 (work in 526 progress), September 2014. 528 [I-D.filsfils-spring-segment-routing-use-cases] 529 Filsfils, C., Francois, P., Previdi, S., Decraene, B., 530 Litkowski, S., Horneffer, M., Milojevic, I., Shakir, R., 531 Ytti, S., Henderickx, W., Tantsura, J., Kini, S., and E. 532 Crabbe, "Segment Routing Use Cases", draft-filsfils- 533 spring-segment-routing-use-cases-01 (work in progress), 534 October 2014. 536 [I-D.ietf-isis-segment-routing-extensions] 537 Previdi, S., Filsfils, C., Bashandy, A., Gredler, H., 538 Litkowski, S., Decraene, B., and J. Tantsura, "IS-IS 539 Extensions for Segment Routing", draft-ietf-isis-segment- 540 routing-extensions-03 (work in progress), October 2014. 542 [I-D.ietf-ospf-segment-routing-extensions] 543 Psenak, P., Previdi, S., Filsfils, C., Gredler, H., 544 Shakir, R., Henderickx, W., and J. Tantsura, "OSPF 545 Extensions for Segment Routing", draft-ietf-ospf-segment- 546 routing-extensions-02 (work in progress), August 2014. 548 [I-D.psenak-ospf-segment-routing-ospfv3-extension] 549 Psenak, P., Previdi, S., Filsfils, C., Gredler, H., 550 Shakir, R., Henderickx, W., and J. Tantsura, "OSPFv3 551 Extensions for Segment Routing", draft-psenak-ospf- 552 segment-routing-ospfv3-extension-02 (work in progress), 553 July 2014. 555 [RFC1940] Estrin, D., Li, T., Rekhter, Y., Varadhan, K., and D. 556 Zappala, "Source Demand Routing: Packet Format and 557 Forwarding Specification (Version 1)", RFC 1940, May 1996. 559 [RFC5443] Jork, M., Atlas, A., and L. Fang, "LDP IGP 560 Synchronization", RFC 5443, March 2009. 562 [RFC6138] Kini, S. and W. Lu, "LDP IGP Synchronization for Broadcast 563 Networks", RFC 6138, February 2011. 565 Authors' Addresses 567 Clarence Filsfils (editor) 568 Cisco Systems, Inc. 569 Brussels 570 BE 572 Email: cfilsfil@cisco.com 574 Stefano Previdi (editor) 575 Cisco Systems, Inc. 576 Via Del Serafico, 200 577 Rome 00142 578 Italy 580 Email: sprevidi@cisco.com 582 Ahmed Bashandy 583 Cisco Systems, Inc. 584 170, West Tasman Drive 585 San Jose, CA 95134 586 US 588 Email: bashandy@cisco.com 590 Bruno Decraene 591 Orange 592 FR 594 Email: bruno.decraene@orange.com 596 Stephane Litkowski 597 Orange 598 FR 600 Email: stephane.litkowski@orange.com 601 Martin Horneffer 602 Deutsche Telekom 603 Hammer Str. 216-226 604 Muenster 48153 605 DE 607 Email: Martin.Horneffer@telekom.de 609 Rob Shakir 610 British Telecom 611 London 612 UK 614 Email: rob.shakir@bt.com 616 Jeff Tantsura 617 Ericsson 618 300 Holger Way 619 San Jose, CA 95134 620 US 622 Email: Jeff.Tantsura@ericsson.com 624 Edward Crabbe 625 Individual 627 Email: edward.crabbe@gmail.com