idnits 2.17.1 draft-ietf-ngtrans-bgp-tunnel-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There are 3 instances of too long lines in the document, the longest one being 20 characters in excess of 72. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 167: '... router MUST have at least one IPv4 ...' RFC 2119 keyword, line 168: '... The IPv4 address MUST be routable in...' RFC 2119 keyword, line 204: '...e DS-BGP routers MUST run MP-BGP over ...' RFC 2119 keyword, line 219: '... next hop MUST be encoded as an IPv4...' RFC 2119 keyword, line 221: '...ss DS-BGP Router MUST tunnel IPv6 data...' (19 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'KEYWRD' is mentioned on line 102, but not defined == Missing Reference: 'MP-BGP' is mentioned on line 183, but not defined == Missing Reference: 'V6ADDR' is mentioned on line 210, but not defined == Missing Reference: 'ISATAP' is mentioned on line 232, but not defined == Missing Reference: 'TUNNEL' is mentioned on line 267, but not defined ** Obsolete normative reference: RFC 2460 (ref. 'IPV6') (Obsoleted by RFC 8200) ** Obsolete normative reference: RFC 3107 (ref. 'LABEL') (Obsoleted by RFC 8277) -- Obsolete informational reference (is this intentional?): RFC 2893 (ref. 'TRANS') (Obsoleted by RFC 4213) -- No information found for draft-ietf-ppvpn-bgp-ipv6-vpn - is the name correct? -- No information found for draft-ietf-ppvpn-rfc2547bis - is the name correct? Summary: 6 errors (**), 0 flaws (~~), 6 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET DRAFT J. De Clercq, G. Gastaud 3 T. Nguyen, D. Ooms 4 Alcatel 5 S. Prevost 6 BTexact 7 F. Le Faucheur 8 Cisco 9 January, 2002 10 Expires July, 2002 12 Connecting IPv6 Islands across IPv4 Clouds with BGP 14 Status of this Memo 16 This document is an Internet-Draft and is in full conformance with 17 all provisions of Section 10 of RFC2026. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 Abstract 37 This document explains how to interconnect IPv6 islands over an IPv4 38 cloud, including the exchange of IPv6 reachability information using 39 BGP. Two approaches will be explained, both requiring a Dual Stack 40 MP-BGP-speaking edge router per IPv6 island. The hosts in the IPv6 41 islands can use native IPv6 addresses. 43 The first approach uses MP-BGP over IPv4, relies on identification of 44 the MP-BGP-speaking edge routers by their IPv4 address and uses a 45 trivial tunneling mechanism without any explicit tunnel 46 configuration. The second approach uses MP-BGP over IPv6 and relies 47 on existing ngtrans tunneling mechanisms to tunnel packets. 49 Table of Contents 51 1. Introduction 52 2. Terminology 53 3. Applicability 54 4. Description 55 4.1. "MP-BGP over IPv4" approach 56 4.2. "MP-BGP over IPv6" approach 57 4.3. Characteristics Common To Both Approaches 58 5. Tunneling 59 5.1. "MP-BGP over IPv4" approach 60 5.1.1. Tunneling over IPv4/GRE tunnels 61 5.1.2. Tunneling over MPLS LSPs 62 5.2. "MP-BGP over IPv6" approach 63 6. Crossing multiple IPv4 domains 64 7. Comparison 65 7.1. "MP-BGP over IPv4" approach versus "MP-BGP over IPv6" approach 66 7.2. "MP-BGP over IPv4" and "MP-BGP over IPv6" approaches versus other ngtrans mechanisms 67 7.3. "MP-BGP over IPv4" approach versus MPLS/BGP VPNs 68 8. Security considerations 70 Changes 71 00->01: editorial changes 72 extended section 4 73 01->02: editorial changes 74 added tunnel-specific considerations 75 added case of multiple IPv4 domains between IPv6 islands 76 added discussion on v6[v4]addresses in appendix A 77 02->03: complete rewrite: it turned out that two interpretations of the 78 previous drafts existed, the two different interpretations are 79 described explicitly in this version 80 03->04: renaming of the two approaches 81 editorial changes 82 clearly indicate which part requires standards track 84 1. Introduction 86 This document explains how to interconnect IPv6 islands over an IPv4 87 cloud, including the exchange of IPv6 reachability information using 88 BGP. Two approaches will be explained, both requiring a Dual Stack 89 MP-BGP-speaking edge router per IPv6 island. The hosts in the IPv6 90 islands can use native IPv6 addresses. 92 The first approach uses MP-BGP over IPv4, relies on identification of 93 the MP-BGP-speaking edge routers by their IPv4 address and uses a 94 trivial tunneling mechanism without any explicit tunnel 95 configuration. The second approach uses MP-BGP over IPv6 and relies 96 on existing ngtrans tunneling mechanisms to tunnel packets. 98 Most of the document is informational. Only section 4 and section 5 99 contain a parts that require standardization. Those are clearly 100 identified through the use of the keywords "MUST", "MAY", etc. in 101 accordance with [KEYWRD]. 103 2. Terminology 105 The terminology of [IPV6] and [TRANS] applies to this document. We 106 also use some of the terminology of [VPN]. 108 In this document an 'IPv6 island' is an IPv6-upgraded network (which 109 can be cross-AS). A typical example of one island would be one or 110 more Customer IPv6 sites connected via their Customer Edge (CE) 111 router to one (or more) Dual Stack Provider Edge (PE) router(s) of a 112 Service Provider. 114 +--------+ 115 |site A CE---+ +------------+ 116 +--------+ | | | +--------+ 117 PE-+ IPv4 core +-PE---CE site C | 118 +--------+ | | | +--------+ 119 |site B CE---+ +------------+ 120 +--------+ 122 IPv6 island IPv4 cloud IPv6 island 123 <-------------><----------------><-------------> 125 3. Applicability 127 The transition methods described in this document typically applies 128 to an ISP that is familiar with BGP (possibly already offering 129 BGP/MPLS VPN services) and that wants to offer IPv6 services to some 130 of its customers. However, the ISP does not (yet) want to upgrade 131 its network core to IPv6. With the mechanisms described here, the 132 provider only has to upgrade some PE routers in some POPs to Dual 133 Stack MP-BGP routers. The Dual Stack MP-BGP routers provide access to 134 IPv6 customers and may provide access to IPv4 customers in addition. 136 The ISP may also have access to the global IPv6 Internet. The ISP 137 provides global IPv6 connectivity through its peering relationship 138 with an upstream ISP, or by peering relationships with other IPv6 139 ISPs in the default free routing zone (DFZ). 141 A Dual Stack MP-BGP router in the provider's network is connected to 142 an upstream IPv6 ISP or forms part of the IPv6 backbone network, such 143 as the 6bone. The ISP advertises IPv6 reachability of its IPv6 144 allocated prefix using MP-BGP to its IPv6 upstream provider or into 145 the IPv6 DFZ. The IPv6 prefixes received from the upstream provider 146 or from the DFZ can be redistributed within the ISP using MP-BGP. 148 The interface between the CE router and the PE router is a native 149 IPv6 interface which can be physical or logical. A routing protocol 150 (IGP or EGP) may run between the CE router and the PE router for a 151 customer IPv6 site to exchange its reachability. Alternatively, 152 static routes and/or a default route may be used on PE and CE to 153 control reachability. A customer site may connect to the provider 154 network over more than one interface. 156 The methods in this document can be used for customers that already 157 have an IPv4 service from the network provider and additionally 158 require an IPv6 service, as well as for customers that require only 159 IPv6 connectivity. In both cases the network provider allocates IPv6 160 addresses to the site. 162 4. Description 164 Each IPv6 site is connected to at least one Dual Stack MP-BGP- 165 speaking edge router that is located on the border with the IPv4 166 cloud. We refer to such a router as a DS-BGP router. The DS-BGP 167 router MUST have at least one IPv4 address on the IPv4 side and one 168 IPv6 address on the IPv6 side. The IPv4 address MUST be routable in 169 the IPv4 cloud. 171 We refer to the DS-BGP router receiving IPv6 packets from an IPv6 172 site as an Ingress DS-BGP router (relative to these IPv6 packets). We 173 refer to a DS-BGP router sending IPv6 packets to an IPv6 site as an 174 Egress DS-BGP router (relative to these IPv6 packets). 176 No extra routes will be injected in the IPv4 cloud. 178 Interconnecting IPv6 islands over an IPv4 cloud requires following 179 steps: 181 (1) Exchange IPv6 reachability information among DS-BGP Routers: 183 (1.a) The DS-BGP routers exchange, via MP-BGP [MP-BGP], IPv6 184 reachability information over the IPv4 cloud with their peers. 186 (1.b) In doing so, the Egress DS-BGP routers announce themselves 187 as the BGP Next Hop. 189 (2) Tunnel IPv6 packets from Ingress DS-BGP Router to Egress DS-BGP 190 Router: the Ingress DS-BGP router tunnels an IPv6 packet over the 191 IPv4 cloud towards the Egress DS-BGP router identified as the BGP 192 Next Hop in step (1.b) for the packet's destination IPv6 address. 194 We distinguish two approaches for connecting IPv6 islands across IPv4 195 clouds via BGP, which are respectively referred to as the "MP-BGP 196 over IPv4" approach and the "MP-BGP over IPv6" approach. 198 Step (1.a) is identical for both approaches. 200 Steps (1.b) and (2) differ between the two approaches. 202 4.1. "MP-BGP over IPv4" approach 204 With this approach, the DS-BGP routers MUST run MP-BGP over an IPv4 205 stack (MP-BGP/TCP/IPv4). The DS-BGP router conveys to its peer its 206 IPv4 address as the BGP Next Hop. 208 Since MP-BGP requires that the BGP Next Hop is of the same address 209 family as the NLRI, this IPv4 address needs to be embedded in an IPv6 210 format. The IPv4-mapped IPv6 address is defined in [V6ADDR] as an 211 "address type used to represent the addresses of IPv4 nodes as IPv6 212 addresses", thus this precisely fits for the above purpose. Encoding 213 the routable IPv4 address into a IPv4-mapped IPv6 address allows the 214 remote DS-BGP router to automatically tunnel data over the IPv4 cloud 215 to the destination IPv6 island. Any type of encapsulation can be 216 used (IPv4, MPLS, GRE). 218 In the "MP-BGP over IPv4" approach the IPv4 address of the MP-BGP 219 next hop MUST be encoded as an IPv4-mapped IPv6 address. 221 The ingress DS-BGP Router MUST tunnel IPv6 data over the IPv4 cloud 222 towards the Egress DS-BGP router identified by the IPv4 address 223 advertised in the IPv4-mapped IPv6 address of the BGP Next Hop for 224 the corresponding IPv6 prefix. 226 4.2. "MP-BGP over IPv6" approach 228 With this approach, the DS-BGP routers MUST run MP-BGP over an IPv6 229 stack (MP-BGP/TCP/IPv6). The DS-BGP router conveys to its peer its 230 IPv6 address as the BGP Next Hop. The transport of MP-BGP messages as 231 well as IPv6 packets over the IPv4 cloud relies on any existing 232 ngtrans tunneling technique ([6TO4], [ISATAP], [TRANS], ...). Thus, 233 the IPv6 address of the BGP Next Hop MUST match the actual ngtrans 234 tunneling technique used. For example, if ISATAP is used as the IPv6 235 over IPv4 tunneling technique, then the IPv6 address of the BGP Next 236 Hop MUST be an ISATAP address. 238 The ingress DS-BGP Router MUST tunnel IPv6 data over the IPv4 cloud 239 towards the Egress DS-BGP Router using the relevant ngtrans 240 tunnelling technique applied to the IPv6 address advertised as the 241 BGP Next Hop for the corresponding IPv6 prefix. 243 4.3. Characteristics Common To Both Approaches 245 For both approaches, the MP-BGP AFI MUST be IPv6 (value 2). The SAFI 246 depends on the details of the tunneling technique used. This is 247 discussed below in the tunnel technique specific section. 249 When the number of PEs is not too high, PEs MAY peer in a meshed 250 fashion. Otherwise Route Reflectors MAY be used. 252 The hosts in the IPv6 island MAY have native IPv6 addresses. This is 253 different from e.g. 6to4 [6TO4], which requires that special 254 addresses (6to4 addresses) are allocated to the IPv6 hosts. 256 5. Tunneling 258 5.1. "MP-BGP over IPv4" approach 260 In the "MP-BGP over IPv4" approach, the IPv4-mapped IPv6 addresses 261 allow a DS-BGP router that has to forward a packet to automatically 262 determine the IPv4 endpoint of the tunnel by looking at the MP-BGP 263 routing info. 265 If this approach is used to connect to the public IPv6 Internet, 266 tunnels without special security mechanisms MAY be used (e.g. IPv4 267 tunnels [TUNNEL], GRE tunnels [GRE] or MPLS LSPs without IPSec). 269 Note that even when the number of peers is high, the number of 270 tunnels is not a scalability concern from an operational viewpoint 271 since those are automatic tunnels and thus require no configuration. 273 Considerations on 'common tunneling techniques' in [TRANS] are valid 274 for this approach. 276 5.1.1. Tunneling over IPv4/GRE tunnels 278 When tunneling is done using IPv4 or GRE Tunnels, the SAFI used in 279 MP-BGP MUST be one of the basic values: unicast, multicast or both 280 (1, 2 or 3). 282 The Ingress DS-BGP Router MUST simply use the IPv4 address of the BGP 283 next hop as the destination address of the prepended tunneling 284 header. It uses one of its IPv4 addresses as the source address of 285 the prepended tunneling header. 287 5.1.2. Tunneling over MPLS LSPs 289 When the IPv4 backbone supports MPLS, MPLS LSPs MAY be used as the 290 tunneling technique. These LSPs can be established using any 291 existing technique (LDP, RSVP, ...). 293 When MPLS LSPs are used with the "MP-BGP over IPv4" approach, rather 294 than successively prepend an IPv4 header and then perform label 295 imposition based on the IPv4 header, the ingress DS-BGP Router MAY 296 directly perform label imposition of the IPv6 header without 297 prepending any IPv4 header. The (outer) label imposed corresponds to 298 an LSP starting on the ingress DS-BGP Router and ending on the egress 299 DS-BGP Router. 301 While the "MP-BGP over IPv4" approach can operate using a single 302 level of labels, there are advantages in using a second level of 303 labels which are bound to IPv6 prefixes via MP-BGP advertisements in 304 accordance with [LABEL]. For instance, use of a second level label 305 allows Penultimate Hop Popping (PHP) on the Label Switch Router (LSR) 306 upstream of the egress DS-BGP router without any IPv6 307 capabilities/upgrade on the penultimate router even when the IPv6 308 packet is directly encapsulated in MPLS (without an IPv4 header); 309 since it still transmits MPLS packets even after the PHP (instead of 310 having to transmit IPv6 packets and encapsulate them appropriately). 311 Thus, the "MP-BGP over IPv4" approach MAY be used with a single label 312 and MAY also be used with a second label. 314 Where a single level of labels is used and no label is advertised by 315 MP-BGP, the SAFI used in MP-BGP MUST be one of the basic values: 316 unicast, multicast or both (1, 2 or 3). 318 Where two levels of labels are used and labels are advertised by MP- 319 BGP, the SAFI used in MP-BGP MUST be the "label" SAFI (4) or the 320 "VPN" SAFI (128) depending on the procedures for allocating these 321 labels. 323 5.2. "MP-BGP over IPv6" approach 325 As said before, the "MP-BGP over IPv6" approach relies on any 326 existing ngtrans tunneling mechanism to carry the IPv6 packets over 327 the IPv4 cloud. 329 To determine the IPv4 endpoint of the tunnel, the DS-BGP Router 330 applies the relevant ngtrans tunneling mechanism over the IPv6 331 address of the Egress DS-BGP Router. Thus, as said before, the IPv6 332 address of the Egress DS-BGP Router advertised in MP-BGP as the BGP 333 Next Hop MUST be compatible with the ngtrans mechanism used. 335 The SAFI used in MP-BGP MUST be one of the basic values: unicast, 336 multicast or both (1,2 or 3). 338 6. Crossing multiple IPv4 domains 340 When the IPv6 islands are separated by multiple IPv4 domains, two 341 cases can be distinguished: 343 1. The border routers between the IPv4 domains are not DS-BGP 344 routers, i.e they are IPv4-only BGP routers. The DS-BGP routers of 345 the IPv6 islands from the different IPv4 domains will be configured 346 as MP-BGP peers for the exchange of IPv6 reachability. Alternatively, 347 where the total number of such DS-BGP routers is high, IPv6 348 reachability across domains can be achieved via MP-BGP connection of 349 Route Reflectors in different domains. One direct inter-domain tunnel 350 per pair of such DS-BGP routers will effectively be created. Note 351 that the exchange of IPv6 routes can only start after BGP has created 352 IPv4 connectivity between the domains. 354 2. The border routers between the IPv4 domains are DS-BGP routers. 355 Each of these border DS-BGP routers will peer with the DS-BGP routers 356 in its domain and regular IPv6 routing will take place between the 357 two domains. No inter-domain tunnels are used. There is effectively a 358 separate mesh of tunnels across the DS-BGP Routers of each domain. 360 7. Comparison 362 7.1. "MP-BGP over IPv4" approach versus "MP-BGP over IPv6" approach 364 The "MP-BGP over IPv6" approach requires that an ngtrans tunneling 365 mechanism (eg. ISATAP, 6to4, automatic tunneling, ...) be supported 366 and activated on the DS-BGP Router ahead of time and that IPv6 367 addresses compatible with this tunneling mechanism be allocated to 368 the DS-BGP Routers. 370 In contrast, the "MP-BGP over IPv4" approach requires that no other 371 ngtrans mechanism be used. 373 Because it allows direct label imposition of IPv6 packets (i.e. 374 without prepending an IPv4 header), the "MP-BGP over IPv4" approach 375 can result in less overhead if applied in an MPLS backbone. However 376 it must be noted that, in that case, if for some reason, the LSP 377 fails, forwarding of IPv6 packets towards the corresponding Egress 378 DS-BGP Router will be interrupted. Forwarding of IPv6 packets is not 379 interrupted in case of LSP failure with the "MP-BGP over IPv6" 380 approach or with the "MP-BGP over IPv4" approach when an IPv4 header 381 is prepended before label imposition, since forwarding can fall back 382 to IPv4 forwarding. 384 7.2. "MP-BGP over IPv4" and "MP-BGP over IPv6" approaches versus other 385 ngtrans mechanisms 387 [TRANS] specifies a method to create automatic tunnels by using 388 IPv4-compatible IPv6 addresses. This method is restricted to the 389 case in which the destination coincides with the endpoint of the 390 tunnel (host-to-host or router-to-host tunnels). It has the 391 disadvantage that it requires an IPv4 address per host. "MP-BGP over 392 IPv4" and "MP-BGP over IPv6" approaches require only one IPv4 address 393 per island and enables automatic tunnels for the router-to-router 394 case in contrast to the automatic tunneling described in [TRANS] 395 where the tunnel end-point is the final destination. 397 With "MP-BGP over IPv4" and "MP-BGP over IPv6" approaches , the hosts 398 in the IPv6 island can have native IPv6 addresses. This is different 399 from e.g. 6to4 [6TO4], which requires that special addresses (6to4 400 addresses) are assigned to the IPv6 hosts. 402 7.3. "MP-BGP over IPv4" approach versus MPLS/BGP VPNs 404 "MP-BGP over IPv4" approach can also be viewed as an instantiation of 405 the solution proposed for IPv6 VPNs over an IPv4 backbone [V6VPN] 406 (the IPv6 Internet is considered as one large 'public' VPN) which is: 408 (i) generalized since it can also operate with other tunneling 409 techniques than MPLS. 411 (ii) simplified since it omits the VPN specific parts: 413 - No need for a Route Distinguisher (RD). 415 - VPN Routing and Forwarding (VRF) tables are not required. 417 - No need for a Route Target. 419 - Except when two (or more) levels of label are used, the basic SAFI 420 values (1, 2, 3) suffice. 422 - Except when two (or more) levels of label are used, there is no 423 need to carry labels in MP-BGP. 425 8. Security considerations 427 This proposal can use the security features of BGP and any policy 428 defined in the ISP domain. 430 Normative References 432 [GRE] Farinacci D., T. Li, S. Hanks, D. Meyer, P. Traina, "Generic 433 Routing Encapsulation (GRE)", RFC2784. 435 [IPV6] Deering, S. and R. Hinden, "Internet Protocol, Version 6 436 (IPv6) Specification", RFC2460. 438 [KEYWRD]S. Bradner, Key words for use in RFCs to Indicate Requirement 439 Levels, RFC2119, March 1997. 441 [LABEL] Rekhter Y., E. Rosen, "Carrying Label Information in BGP-4", 442 RFC 3107, May 2001. 444 [MP-BGP]T. Bates, R. Chandra, D. Katz, Y. Rekhter, "Multiprotocol 445 Extensions for BGP-4", RFC2858. 447 [TUNNEL]W. Simpson, "IP in IP Tunneling", RFC1853. 449 [V6ADDR]Deering, S., and R. Hinden, "IP Version 6 Addressing Archi- 450 tecture", draft-ietf-ipngwg-addr-arch-v3-07.txt (work in pro- 451 gress). 453 Informative References 455 [6TO4] B. Carpenter, K. Moore, "Connection of IPv6 domains via IPv4 456 Clouds", RFC3056, February 2001. 458 [ISATAP]F. Templin, "Intra-Site Automatic Tunnel Addressing Protocol 459 (ISATAP), draft-ietf-ngtrans-isatap-02.txt (work in pro- 460 gress). 462 [TRANS] R. Gilligan & E. Nordmark, "Transition Mechanisms for IPv6 463 Hosts and Routers", RFC2893. 465 [V6VPN] Nguyen T., Gastaud G., De Clercq J., Ooms D.,"BGP-MPLS VPN 466 extension for IPv6 VPN over an IPv4 infrastructure", draft- 467 ietf-ppvpn-bgp-ipv6-vpn-01.txt> (work in progress). 469 [VPN] Rosen E., Rekhter Y., Brannon S., Chase C., De Clercq J., 470 Hitchin P., Marshall , Srinivasan V., "BGP/MPLS VPNs", 471 draft-ietf-ppvpn-rfc2547bis-00.txt (work in progress). 473 Authors' Addresses 475 Tri T. Nguyen 476 Alcatel 477 Level 20 Noth Point Tower, 100 Miller Street, 478 North Sydney NSW 2060, Australia 479 E-mail: tri.t.nguyen@alcatel.com 481 Dirk Ooms 482 Alcatel 483 Fr. Wellesplein 1, 2018 Antwerp, Belgium 484 E-mail: dirk.ooms@alcatel.be 486 Gerard Gastaud 487 Alcatel 488 10 rue Latecoere, BP 57, 78141 Velizy Cedex, France 489 E-mail: gerard.gastaud@alcatel.fr 491 Jeremy De Clercq 492 Alcatel 493 Fr. Wellesplein 1, 2018 Antwerp, Belgium 494 E-mail: jeremy.de_clercq@alcatel.be 496 Stuart Prevost 497 BTexact Technologies 498 Room 136 Polaris House, Adastral Park, 499 Martlesham Heath, Ipswich, Suffolk IP5 3RE, England 500 E-mail: stuart.prevost@bt.com 502 Francois Le Faucheur 503 Cisco Systems 504 Domaine Green Side, 400, Avenue de Roumanille, Batiment T3 505 06 410 BIOT, SOPHIA ANTIPOLIS, FRANCE 506 E-mail: flefauch@cisco.com