idnits 2.17.00 (12 Aug 2021) /tmp/idnits50913/draft-wijnands-mpls-mldp-vpn-in-band-signaling-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 abstract seems to contain references ([RFC4364], [I-D.ietf-mpls-mldp-in-band-signaling]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 7, 2011) is 3879 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) ** Obsolete normative reference: RFC 4601 (Obsoleted by RFC 7761) == Outdated reference: draft-ietf-mpls-ldp-p2mp has been published as RFC 6388 == Outdated reference: draft-ietf-mpls-mldp-in-band-signaling has been published as RFC 6826 == Outdated reference: draft-ietf-mpls-mldp-recurs-fec has been published as RFC 6512 == Outdated reference: draft-ietf-l3vpn-2547bis-mcast has been published as RFC 6513 == Outdated reference: A later version (-03) exists of draft-napierala-mpls-targeted-mldp-00 Summary: 2 errors (**), 0 flaws (~~), 6 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group IJ. Wijnands, Ed. 3 Internet-Draft Cisco Systems, Inc. 4 Intended status: Standards Track P. Hitchen 5 Expires: April 9, 2012 BT 6 N. Leymann 7 Deutsche Telekom 8 W. Henderickx 9 Alcatel-Lucent 10 October 7, 2011 12 Multipoint Label Distribution Protocol 13 In-Band Signaling in a VPN Context 14 draft-wijnands-mpls-mldp-vpn-in-band-signaling-00 16 Abstract 18 Sometimes an IP multicast distribution tree (MDT) traverses both 19 MPLS-enabled and non-MPLS-enabled regions of a network. Typically 20 the MDT begins and ends in non-MPLS regions, but travels through an 21 MPLS region. In such cases, it can be useful to begin building the 22 MDT as a pure IP MDT, then convert it to an MPLS Multipoint LSP 23 (Label Switched Path) when it enters an MPLS-enabled region, and then 24 convert it back to a pure IP MDT when it enters a non-MPLS-enabled 25 region. [I-D.ietf-mpls-mldp-in-band-signaling] specifies the 26 procedures for building such a hybrid MDT, using Protocol Independent 27 Multicast (PIM) as the control protocol in the non-MPLS region of the 28 network, and using Multipoint Extensions to Label Distribution 29 Protocol (mLDP) in the MPLS region. This document extends those 30 procedures so that they will work when the links between the MPLS and 31 non-MPLS regions are [RFC4364] interfaces. While these procedures do 32 not provide a good general multicast VPN solution, they are useful in 33 certain specific situations. 35 Status of this Memo 37 This Internet-Draft is submitted in full conformance with the 38 provisions of BCP 78 and BCP 79. 40 Internet-Drafts are working documents of the Internet Engineering 41 Task Force (IETF). Note that other groups may also distribute 42 working documents as Internet-Drafts. The list of current Internet- 43 Drafts is at http://datatracker.ietf.org/drafts/current/. 45 Internet-Drafts are draft documents valid for a maximum of six months 46 and may be updated, replaced, or obsoleted by other documents at any 47 time. It is inappropriate to use Internet-Drafts as reference 48 material or to cite them other than as "work in progress." 49 This Internet-Draft will expire on April 9, 2012. 51 Copyright Notice 53 Copyright (c) 2011 IETF Trust and the persons identified as the 54 document authors. All rights reserved. 56 This document is subject to BCP 78 and the IETF Trust's Legal 57 Provisions Relating to IETF Documents 58 (http://trustee.ietf.org/license-info) in effect on the date of 59 publication of this document. Please review these documents 60 carefully, as they describe your rights and restrictions with respect 61 to this document. Code Components extracted from this document must 62 include Simplified BSD License text as described in Section 4.e of 63 the Trust Legal Provisions and are provided without warranty as 64 described in the Simplified BSD License. 66 Table of Contents 68 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 69 1.1. Conventions used in this document . . . . . . . . . . . . 5 70 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 71 2. VPN In-band signaling for MP LSPs . . . . . . . . . . . . . . 6 72 3. Encoding the Opaque Value of an LDP MP FEC . . . . . . . . . . 7 73 3.1. Transit VPNv4 Source TLV . . . . . . . . . . . . . . . . . 7 74 3.2. Transit VPNv6 Source TLV . . . . . . . . . . . . . . . . . 8 75 3.3. Transit VPNv4 bidir TLV . . . . . . . . . . . . . . . . . 9 76 3.4. Transit VPNv6 bidir TLV . . . . . . . . . . . . . . . . . 10 77 4. Security Considerations . . . . . . . . . . . . . . . . . . . 11 78 5. IANA considerations . . . . . . . . . . . . . . . . . . . . . 11 79 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 80 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 81 7.1. Normative References . . . . . . . . . . . . . . . . . . . 11 82 7.2. Informative References . . . . . . . . . . . . . . . . . . 12 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 85 1. Introduction 87 Sometimes an IP multicast distribution tree (MDT) traverses both 88 MPLS-enabled and non-MPLS-enabled regions of a network. In such 89 cases, it can be useful to begin building the MDT as a pure IP MDT, 90 then convert it to an MPLS Multipoint LSP (Label Switched Path) when 91 it enters an MPLS-enabled region, and then convert it back to a pure 92 IP MDT when it enters a non-MPLS-enabled region. 93 [I-D.ietf-mpls-mldp-in-band-signaling] specifies the procedures for 94 building such a hybrid MDT, using Protocol Independent Multicast 95 (PIM) [RFC4601] as the control protocol in the non-MPLS region of the 96 network, and using Multipoint Extensions to Label Distribution 97 Protocol (mLDP) [I-D.ietf-mpls-ldp-p2mp] in the MPLS region. 99 For a given tree, one or more routers that are at the border between 100 a non-MPLS-enabled region and an MPLS-enabled region receive PIM 101 control messages from the non-MPLS-enabled region, and convert them 102 to mLDP control messages to be sent into the MPLS-enabled region. 103 Another router that is at the border between a non-MPLS-enabled 104 region and an MPLS-enabled region receives mLDP control messages from 105 the MPLS-enabled region and converts them to PIM control messages to 106 be sent into a non-MPLS-enabled region. 108 In PIM, a tree is identified by a source address (or in the case of 109 bidirectional trees [RFC5015], a rendezvous point address or "RPA") 110 and a group address. The tree is built from the leaves up, by 111 sending PIM control messages in the direction of the source address 112 or the RPA. In mLDP, a tree is identified by a root address and an 113 "opaque value", and is built by sending mLDP control messages in the 114 direction of the root. The procedures of 115 [I-D.ietf-mpls-mldp-in-band-signaling] explain how to convert a PIM 116 pair into an mLDP pair;, and how to convert the mLDP pair back into the original PIM pair. 121 However, those procedures assume that the routers doing the PIM/mLDP 122 conversion have routes to the source address or RPA in their global 123 routing tables. Thus the procedures cannot be applied exactly as 124 specified when the interfaces connecting the non-MPLS-enabled region 125 to the MPLS-enabled region are interfaces that belong to a VPN as 126 described in [RFC4364]. This specification extends the procedures of 127 [I-D.ietf-mpls-mldp-in-band-signaling] so that they may be applied in 128 the VPN context. 130 As in [I-D.ietf-mpls-mldp-in-band-signaling], the scope of this 131 document is limited to the case where the multicast content is 132 distributed in the non-MPLS-enabled regions via PIM-created Source- 133 Specific or Bidirectional trees. Bidirectional trees are always 134 mapped onto Multipoint-to-Multipoint LSPs, and source-specific trees 135 are always mapped onto Point-to-Multipoint LSPs. 137 Each multicast tree in the non-MPLS enabled region is mapped 1-1 onto 138 a multipoint LSP in the MPLS-enabled region. For a variety of 139 reasons (discussed in [I-D.ietf-l3vpn-2547bis-mcast]), this is not a 140 suitable for a general purpose multicast VPN solution. But the 141 procedures described herein are much simpler than the general purpose 142 MVPN procedures, and are applicable when the 1-1 mapping is 143 acceptable, and when it is acceptable to use mLDP as the protocol for 144 setting up the multipoint LSPs. For example, some service providers 145 offer multicast content to their customers, but have chosen to use 146 VPNs to isolate the various customers and services. This is a very 147 different scenario than the general MVPN scenario, in which the 148 customers provide their own multicast content, out of the control of 149 the service provider. 151 Due to the 1-1 mapping and the multicast source and group information 152 being encoded in the mLDP FEC, there is deterministic mapping beween 153 the multicast tree and the mLDP LSP in the core network. This 154 improves and simplifies fault resolution. 156 In order to use the mLDP in-band signaling procedures for a 157 particular group address in a particular VPN, the Provider Edge (PE) 158 routers that attach to that VPN MUST be configured with a range of 159 multicast group addresses for which mLDP in-band signaling is to be 160 enabled. This configuration is per VRF ("Virtual Routing and 161 Forwarding table", defined in [RFC4364]). For those groups, and 162 those groups only, the procedures of this document are used instead 163 of the general purpose Multicast VPN procedures. This configuration 164 must be present in all PE routers that attach to sites containing 165 senders or receivers for the given set of group addresses. 167 1.1. Conventions used in this document 169 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 170 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 171 document are to be interpreted as described in RFC 2119 [RFC2119]. 173 1.2. Terminology 175 IP multicast tree : An IP multicast distribution tree identified by 176 an source IP address and/or IP multicast destination address, also 177 referred to as (S,G) and (*,G). 179 mLDP : Multicast LDP. 181 In-band signaling : Using the opaque value of a mLDP FEC element to 182 encode the (S,G) or (*,G) identifying a particular IP multicast 183 tree. 185 P2MP LSP: An LSP that has one Ingress LSR and one or more Egress 186 LSRs (see [I-D.ietf-mpls-ldp-p2mp]). 188 MP2MP LSP: An LSP that connects a set of leaf nodes, acting 189 indifferently as ingress or egress (see [I-D.ietf-mpls-ldp-p2mp]). 191 MP LSP: A multipoint LSP, either a P2MP or an MP2MP LSP. 193 Ingress LSR: Source of a P2MP LSP, also referred to as root node. 195 2. VPN In-band signaling for MP LSPs 197 Suppose that a PE router, PE1, attaching to a particular VPN, 198 receives a PIM Join(S,G) message over one of its VRF interfaces. 199 Following the procedure of section 5.1 of 200 [I-D.ietf-l3vpn-2547bis-mcast], PE1 determines the "upstream RD", the 201 "upstream PE", and the "upstream multicast hop" (UMH) for the source 202 address S. Please note that sections 5.1.1 and 5.1.2 of 203 [I-D.ietf-l3vpn-2547bis-mcast] are applicable. 205 In order to transport the multicast tree via a MP LSP using VPN in- 206 band signaling, an mLDP Label Mapping Message is sent by PE1. This 207 message will contain either a P2MP FEC or an MP2MP FEC (see 208 [I-D.ietf-mpls-ldp-p2mp], depending upon whether the PIM tree being 209 transported is a source-specific tree, or a bidirectional tree, 210 respectively. The FEC contains a "root" and an "opaque value". 212 If the UMH and the upstream PE have the same IP address (i.e., the 213 Upstream PE is the UMH), then the root of the Multipoint FEC is set 214 to the IP address of the Upstream PE. If, in the context of this 215 VPN, (S,G) refers to a source-specific MDT, then the values of S, G, 216 and the upstream RD are encoded into the opaque value. If, in the 217 context of this VPN, G is a bidirectional group address, then S is 218 replaced with the value of the RPA associated with G. The coding 219 details are specified in Section 3. Conceptually, the Multipoint FEC 220 can be thought of as an ordered pair: . The mLDP Label Mapping 222 Message is then sent by PE1 on its LDP session to the "next hop" on 223 its path to the upstream PE. The "next hop" is usually the IGP next 224 hop, but see [I-D.napierala-mpls-targeted-mldp] for cases in which 225 the next hop is not the IGP next hop. 227 If the UMH and the upstream PE do not have the same IP address, the 228 procedures of section 2 of [I-D.ietf-mpls-mldp-recurs-fec] should be 229 applied. The root node of the multipoint FEC is set to the UMH. The 230 recursive opaque value is then set as follows: the root node is set 231 to the upstream PE, and the opaque value is set to the multipoint FEC 232 described in the previous paragraph. That is, the multipoint FEC can 233 be thought of as the following recursive ordered pair: >. 237 The encoding of the multipoint FEC also specifies the "type" of PIM 238 MDT being spliced onto the multipoint LSP. Four types of MDT are 239 defined: IPv4 source-specific tree, IPv6 source-specific tree, IPv4 240 bidirectional tree, and IPv6 bidirectional tree. 242 When a PE router receives an mLDP message with a P2MP or MP2MP FEC, 243 where the PE router itself is the root node, and the opaque value is 244 one of the types defined in Section 3, then it uses the RD encoded in 245 the opaque value field to determine the VRF context. (This RD will 246 be associated with one of the PEs VRFs.) Then, in the context of 247 that VRF, the PE follows the procedure specified in section 2 of 248 [I-D.ietf-mpls-mldp-in-band-signaling]. 250 3. Encoding the Opaque Value of an LDP MP FEC 252 This section documents the different transit opaque encodings. 254 3.1. Transit VPNv4 Source TLV 256 This opaque value type is used when transporting a source-specific 257 mode multicast tree whose source and group addresses are IPv4 258 addresses. 260 0 1 2 3 261 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 262 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 263 | Type | Length | Source 264 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 265 | Group 266 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 267 | ~ 268 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 269 ~ RD | 270 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 272 Type: (to be assigned by IANA). 274 Length: 16 276 Source: IPv4 multicast source address, 4 octets. 278 Group: IPv4 multicast group address, 4 octets. 280 RD: Route Distinguisher, 8 octets. 282 3.2. Transit VPNv6 Source TLV 284 This opaque value type is used when transporting a source-specific 285 mode multicast tree whose source and group addresses are IPv6 286 addresses. 288 0 1 2 3 289 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 290 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 291 | Type | Length | Source ~ 292 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 293 ~ | Group ~ 294 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 295 ~ | ~ 296 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 297 ~ RD | 298 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 300 Type: (to be assigned by IANA). 302 Length: 40 304 Source: IPv6 multicast source address, 16 octets. 306 Group: IPv6 multicast group address, 16 octets. 308 RD: Route Distinguisher, 8 octets. 310 3.3. Transit VPNv4 bidir TLV 312 This opaque value type is used when transporting a bidirectional 313 multicast tree whose group address is an IPv4 address. The RP 314 address is also an IPv4 address in this case. 316 0 1 2 3 317 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 318 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 319 | Type | Length | Mask Len | 320 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 321 | RP | 322 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 323 | Group | 324 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 325 ~ RD | 326 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 328 Type: (to be assigned by IANA). 330 Length: 17 332 Mask Len: The number of contiguous one bits that are left justified 333 and used as a mask, 1 octet. 335 RP: Rendezvous Point (RP) IPv4 address used for encoded Group, 4 336 octets. 338 Group: IPv4 multicast group address, 4 octets. 340 RD: Route Distinguisher, 8 octets. 342 3.4. Transit VPNv6 bidir TLV 344 This opaque value type is used when transporting a bidirectional 345 multicast tree whose group address is an IPv6 address. The RP 346 address is also an IPv6 address in this case. 348 0 1 2 3 349 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 350 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 351 | Type | Length | Mask Len | 352 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 353 | RP ~ 354 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 355 ~ | 356 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 357 | Group ~ 358 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 359 ~ | 360 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 361 ~ RD | 362 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 364 Type: (to be assigned by IANA). 366 Length: 41 368 Mask Len: The number of contiguous one bits that are left justified 369 and used as a mask, 1 octet. 371 RP: Rendezvous Point (RP) IPv6 address used for encoded group, 16 372 octets. 374 Group: IPv6 multicast group address, 16 octets. 376 RD: Route Distinguisher, 8 octets. 378 4. Security Considerations 380 The same security considerations apply as for the base LDP 381 specification, described in [RFC5036], and the base mLDP 382 specification, described in [I-D.ietf-mpls-ldp-p2mp] 384 5. IANA considerations 386 [I-D.ietf-mpls-ldp-p2mp] defines a registry for "The LDP MP Opaque 387 Value Element Basic Type". This document requires the assignment of 388 four new code points in this registry: 390 Transit VPNv4 Source TLV type - requested 10 392 Transit VPNv6 Source TLV type - requested 11 394 Transit VPNv4 Bidir TLV type - requested 12 396 Transit VPNv6 Bidir TLV type - requested 13 398 6. Acknowledgments 400 Thanks to Eric Rosen and Andy Green for their comments on the draft. 402 7. References 404 7.1. Normative References 406 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 407 Networks (VPNs)", RFC 4364, February 2006. 409 [RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, 410 "Protocol Independent Multicast - Sparse Mode (PIM-SM): 411 Protocol Specification (Revised)", RFC 4601, August 2006. 413 [RFC5015] Handley, M., Kouvelas, I., Speakman, T., and L. Vicisano, 414 "Bidirectional Protocol Independent Multicast (BIDIR- 415 PIM)", RFC 5015, October 2007. 417 [RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP 418 Specification", RFC 5036, October 2007. 420 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 421 Requirement Levels", BCP 14, RFC 2119, March 1997. 423 [I-D.ietf-mpls-ldp-p2mp] 424 Minei, I., Kompella, K., Wijnands, I., and B. Thomas, 425 "Label Distribution Protocol Extensions for Point-to- 426 Multipoint and Multipoint-to-Multipoint Label Switched 427 Paths", draft-ietf-mpls-ldp-p2mp-11 (work in progress), 428 October 2010. 430 [I-D.ietf-mpls-mldp-in-band-signaling] 431 Wijnands, I., Eckert, T., Leymann, N., and M. Napierala, 432 "mLDP based in-band signaling for Point-to-Multipoint and 433 Multipoint-to- Multipoint Label Switched Paths", 434 draft-ietf-mpls-mldp-in-band-signaling-02 (work in 435 progress), July 2010. 437 [I-D.ietf-mpls-mldp-recurs-fec] 438 Wijnands, I., Rosen, E., Napierala, M., and N. Leymann, 439 "Using mLDP through a Backbone where there is no Route to 440 the Root", draft-ietf-mpls-mldp-recurs-fec-00 (work in 441 progress), October 2010. 443 [I-D.ietf-l3vpn-2547bis-mcast] 444 Aggarwal, R., Bandi, S., Cai, Y., Morin, T., Rekhter, Y., 445 Rosen, E., Wijnands, I., and S. Yasukawa, "Multicast in 446 MPLS/BGP IP VPNs", draft-ietf-l3vpn-2547bis-mcast-10 (work 447 in progress), January 2010. 449 7.2. Informative References 451 [I-D.napierala-mpls-targeted-mldp] 452 Napierala, M., Rosen, E., and I. Wijnands, "Using LDP 453 Multipoint Extensions on Targeted LDP Sessions", 454 draft-napierala-mpls-targeted-mldp-00 (work in progress), 455 January 2011. 457 Authors' Addresses 459 IJsbrand Wijnands (editor) 460 Cisco Systems, Inc. 461 De kleetlaan 6a 462 Diegem 1831 463 Belgium 465 Email: ice@cisco.com 467 Paul Hitchen 468 BT 469 BT Adastral Park 470 Ipswich IP53RE 471 UK 473 Email: paul.hitchen@bt.com 475 Nicolai Leymann 476 Deutsche Telekom 477 Winterfeldtstrasse 21 478 Berlin 10781 479 Germany 481 Email: n.leymann@telekom.de 483 Wim Henderickx 484 Alcatel-Lucent 485 Copernicuslaan 50 486 Antwerp 2018 487 Belgium 489 Email: wim.henderickx@alcatel-lucent.com