idnits 2.17.1 draft-sajassi-bess-evpn-ac-aware-bundling-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 11, 2021) is 1019 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) == Missing Reference: 'RFC4364' is mentioned on line 263, but not defined == Missing Reference: 'EVPN-PREFIX' is mentioned on line 292, but not defined == Outdated reference: A later version (-21) exists of draft-ietf-bess-evpn-igmp-mld-proxy-00 == Outdated reference: A later version (-08) exists of draft-ietf-bess-evpn-vpws-fxc-03 Summary: 0 errors (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 BESS WorkGroup A. Sajassi 3 Internet-Draft P. Brissette 4 Intended status: Standards Track M. Mishra 5 Expires: January 12, 2022 S. Thoria 6 Cisco Systems 7 J. Rabadan 8 Nokia 9 J. Drake 10 Juniper Networks 11 July 11, 2021 13 AC-Aware Bundling Service Interface in EVPN 14 draft-sajassi-bess-evpn-ac-aware-bundling-04 16 Abstract 18 EVPN provides an extensible and flexible multi-homing VPN solution 19 over an MPLS/IP network for intra-subnet connectivity among Tenant 20 Systems and End Devices that can be physical or virtual. 22 EVPN multihoming with IRB is one of the common deployment scenarios. 23 There are deployments which requires capability to have multiple 24 subnets designated with multiple VLAN IDs in single Broadcast Domain. 26 EVPN technology defines three different types of service interface 27 which serve different requirements but none of them address the 28 requirement of supporting multiple subnets within single Broadcast 29 Domain. In this draft we define new service interface type to 30 support multiple subnets in single Broadcast Domain. Service 31 interface proposed in this draft will be applicable to multihoming 32 case only. 34 Requirements Language 36 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 37 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 38 document are to be interpreted as described in RFC 2119 [RFC2119] and 39 RFC 8174 [RFC8174]. 41 Status of This Memo 43 This Internet-Draft is submitted in full conformance with the 44 provisions of BCP 78 and BCP 79. 46 Internet-Drafts are working documents of the Internet Engineering 47 Task Force (IETF). Note that other groups may also distribute 48 working documents as Internet-Drafts. The list of current Internet- 49 Drafts is at https://datatracker.ietf.org/drafts/current/. 51 Internet-Drafts are draft documents valid for a maximum of six months 52 and may be updated, replaced, or obsoleted by other documents at any 53 time. It is inappropriate to use Internet-Drafts as reference 54 material or to cite them other than as "work in progress." 56 This Internet-Draft will expire on January 12, 2022. 58 Copyright Notice 60 Copyright (c) 2021 IETF Trust and the persons identified as the 61 document authors. All rights reserved. 63 This document is subject to BCP 78 and the IETF Trust's Legal 64 Provisions Relating to IETF Documents 65 (https://trustee.ietf.org/license-info) in effect on the date of 66 publication of this document. Please review these documents 67 carefully, as they describe your rights and restrictions with respect 68 to this document. Code Components extracted from this document must 69 include Simplified BSD License text as described in Section 4.e of 70 the Trust Legal Provisions and are provided without warranty as 71 described in the Simplified BSD License. 73 Table of Contents 75 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 76 1.1. Problem with Unicast MAC route . . . . . . . . . . . . . 6 77 1.2. Problem with Multicast route synchronization . . . . . . 6 78 1.3. Potential Security concern caused by misconfiguration . . 6 79 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 80 3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 7 81 4. Solution Description . . . . . . . . . . . . . . . . . . . . 8 82 4.1. Control Plane Operation . . . . . . . . . . . . . . . . . 8 83 4.1.1. MAC/IP Address Advertisement . . . . . . . . . . . . 8 84 4.1.1.1. Local Unicast MAC learning . . . . . . . . . . . 8 85 4.1.1.2. Remote Unicast MAC learning . . . . . . . . . . . 8 86 4.1.2. Multicast route Advertisement . . . . . . . . . . . . 8 87 4.1.2.1. Local multicast state . . . . . . . . . . . . . . 9 88 4.1.2.2. Remote multicast state . . . . . . . . . . . . . 9 89 4.2. Data Plane Operation . . . . . . . . . . . . . . . . . . 9 90 4.2.1. Unicast Forwarding . . . . . . . . . . . . . . . . . 9 91 4.2.2. Multicast Forwarding . . . . . . . . . . . . . . . . 10 92 5. Mis-configuration across multihoming peers . . . . . . . . . 10 93 6. BGP Encoding . . . . . . . . . . . . . . . . . . . . . . . . 10 94 6.1. Attachment Circuit ID Extended Community . . . . . . . . 10 95 6.2. Ethernet-tag field vs AC ID Extended Community . . . . . 11 97 7. Security Considerations . . . . . . . . . . . . . . . . . . . 11 98 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 99 9. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 11 100 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 101 10.1. Normative References . . . . . . . . . . . . . . . . . . 11 102 10.2. Informative References . . . . . . . . . . . . . . . . . 12 103 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 105 1. Introduction 107 EVPN based All-Active multi-homing is becoming the basic building 108 block for providing redundancy in next generation data center 109 deployments as well as service provider access/aggregation network. 110 For EVPN IRB mode, there are deployments which expect to be able to 111 support multiple subnets within single Broadcast Domain. Each subnet 112 would be differentiated by VLAN. Thus, single IRB interface can 113 still serve multiple subnet. 115 Motivation behind such deployments are 117 1. Manageability: The support to have multiple subnets using single 118 Broadcast Domain requires only one Broadcast Domain and one IRB 119 for "N" subnets compare to "N" Broadcast Domain and "N" IRB 120 interface to manage. 122 2. Simplicity: It avoids extra configuration by configuring VLAN 123 Range with single BD and IRB as compare to individual VLAN, BD 124 and IRB interface per subnet. 126 [RFC7432] defines three types of service interface. None of them 127 provide flexibility to achieve multiple subnets within single 128 Broadcast Domain. The different types of service interface from 129 [RFC7432] are: 131 1. VLAN-Based Service Interface: With this service interface, an 132 EVPN instance consists of only a single broadcast domain (e.g., a 133 single VLAN). Therefore, there is a one-to-one mapping between a 134 VID on this interface and a MAC-VRF. 136 2. VLAN Bundle Service Interface: With this service interface, an 137 EVPN instance corresponds to multiple broadcast domains (e.g., 138 multiple VLANs); however, only a single bridge table is 139 maintained per MAC-VRF, which means multiple VLANs share the same 140 bridge table. The MPLS-encapsulated frames MUST remain tagged 141 with the originating VID. Tag translation is NOT permitted. The 142 Ethernet Tag ID in all EVPN routes MUST be set to 0. 144 3. VLAN-Aware Bundle Service Interface: With this service interface, 145 an EVPN instance consists of multiple broadcast domains (e.g., 146 multiple VLANs) with each VLAN having its own bridge table -- 147 i.e., multiple bridge tables (one per VLAN) are maintained by a 148 single MAC-VRF corresponding to the EVPN instance. 150 From definition, it seems like VLAN Bundle Service Interface does 151 provide flexibility to support multiple subnets within single 152 Broadcast Domain. However, the requirement is to have multiple 153 subnets from same ES on multi-homing all active mode; that would not 154 work. For example, lets take the case from Figure 1 where PE1 learns 155 MAC of H1 on VLAN 1 (subnet S1). PE1 originates EVPN MAC route, as 156 per [RFC7432], where the Ethernet Tag would be set to 0. Incoming 157 packets from IRB interface, at PE2, are untagged packet. PE2 does 158 not have any associated AC information from EVPN MAC routes 159 advertised by PE1. PE2 can not forward traffic which is destined to 160 H1. 162 This draft proposes an extension to existing service interface types 163 defined in [RFC7432] and defines AC-aware Bundling service interface. 164 AC-aware Bundling service interface would provide mechanism to have 165 multiple subnets in single Broadcast Domain. This extension is 166 applicable only for multi-homed EVPN peers. 168 H3 169 | 170 +---+---+ 171 | PE3 | EVI-1 172 +---+---+ 173 | 174 +-----------------------+--------------------+ 175 | | 176 | IP MPLS core | 177 | | 178 +------+------------------------------+------+ 179 | | 180 +--------------+----+ +----+--------------+ 181 | PE1 | | PE2 | 182 | | | | 183 | +-----+ | | +-----+ | 184 | | IRB | | | | IRB | | 185 | +--+-----+--+ | | +--+-----+--+ | 186 | | BD & EVI | | | | BD & EVI | | 187 | +--+--+--+--+ | | +-----------+ | 188 | |S1|S2|S3|S4| | | |S1|S2|S3|S4| | 189 +---+--+-X+--+--+---+ +---+--+--+X-+--+---+ 190 X X 191 X X 192 X X ESI-100 193 X X EVI-1 194 X X BD-1 195 X X 196 XX 197 +------+ 198 | CE | 199 +-+--+-+ 200 | | 201 H1 H2 202 MAC-1 MAC-2 203 VLAN-1 VLAN-2 204 (S,G) (S,G) 206 EVPN topology with multi-homing and non multihoming peer. 208 Figure 1 210 Figure 1 shows sample EVPN topology where PE1 and PE2 are multihomed 211 peers. PE3 is remote peer participating in the same EVPN instance 212 (EVI-1). It illustrates four subnets S1, S2, S3 and S4 where 213 numerical value provides associated VLAN information. 215 1.1. Problem with Unicast MAC route 217 BD-1 has multiple subnets where each subnet is distinguished by VLAN 218 1, 2 ,3 and 4. PE1 learns MAC address MAC-1 from AC associated with 219 subnet S1. PE1 uses MAC route to advertise MAC-1 presence to peer 220 PEs. As per [RFC7432] MAC route advertisement from PE1 does not 221 carry any context providing information about MAC address association 222 with AC. When PE2 receives MAC route with MAC-2 it can not determine 223 which AC this MAC belongs too. 225 Since PE2 could not bind MAC-1 with correct AC, when it receives data 226 traffic destined to MAC-1, it does not know the destination AC since 227 multiple bridge ports have the same ESI assignment. 229 1.2. Problem with Multicast route synchronization 231 [I-D.ietf-bess-evpn-igmp-mld-proxy] defines mechanism to synchronize 232 multicast routes between multihome peers. In above case, if receiver 233 behind S1 send IGMP membership request, CE could hash it to either of 234 the PEs. When multicast route is originated, it does not contain any 235 AC information. Once it reaches to peering PE, it does not have any 236 information about which subnet this IGMP membership request belong 237 to. Similarly to unicast traffic problem, the incoming multicast 238 traffic from IRB cannot be forearded to proper AC. 240 1.3. Potential Security concern caused by misconfiguration 242 In case of single subnet per Broadcast Domain, there is potential 243 case of security issue. For example, PE1 has BD1 configured with 244 VLAN-1 where as multihome peer PE2 has BD1 configured VLAN-2. Each 245 of the IGMP membership requests on PE1 would be synchronized to PE2 246 and PE2 would process multicast routes and start forwarding multicast 247 traffic on VLAN-2, which was not intended. Again, similar issue can 248 potentially be seen with unicast traffic. 250 2. Terminology 252 o AC: Attachment Circuit. 254 o ARP: Address Resolution Protocol. 256 o BD: Broadcast Domain. As per [RFC7432], an EVI consists of a 257 single or multiple BDs. In case of VLAN-bundle and VLAN-based 258 service models (see [RFC7432]), a BD is equivalent to an EVI. In 259 case of VLAN-aware bundle service model, an EVI contains multiple 260 BDs. Also, in this document, BD and subnet are equivalent terms. 262 o BD Route Target: refers to the Broadcast Domain assigned Route 263 Target [RFC4364]. In case of VLAN-aware bundle service model, all 264 the BD instances in the MAC-VRF share the same Route Target. 266 o BT: Bridge Table. The instantiation of a BD in a MAC-VRF, as per 267 [RFC7432]. 269 o Ethernet A-D route: Ethernet Auto-Discovery (A-D) route, as per 270 [RFC7432]. 272 o EVI: EVPN Instance spanning the NVE/PE devices that are 273 participating on that EVPN, as per [RFC7432]. 275 o EVPN: Ethernet Virtual Private Networks, as per [RFC7432]. 277 o IRB: Integrated Routing and Bridging interface. It connects an 278 IP-VRF to a BD (or subnet). 280 o MAC-VRF: A Virtual Routing and Forwarding table for Media Access 281 Control (MAC) addresses on an NVE/PE, as per [RFC7432]. A MAC-VRF 282 is also an instantiation of an EVI in an NVE/PE. 284 o ND: Neighbor Discovery Protocol. 286 o RD: BGP Route Distinguisher. 288 o RT-2: EVPN route type 2, i.e., MAC/IP advertisement route, as 289 defined in [RFC7432]. 291 o RT-5: EVPN route type 5, i.e., IP Prefix route. As defined in 292 Section 3 of [EVPN-PREFIX]. 294 o SN: Subnet. 296 o TS: Tenant System. 298 o VLAN: The usage of VLAN refers to 802.1Q or 802.1AD tag. 300 o (S,G): Multicast membership request 302 o This document also assumes familiarity with the terminology of 303 [RFC7432],[RFC8365], [RFC7365]. 305 3. Requirements 307 1. A service interface represents an attachement-circuit where 308 multiple VLAN are configured on. Each of these VLANs are 309 represented by a different AC under a single Broadcast Domain. 311 2. Single Broadcast Domain MUST support service interfaces. 313 3. Service interface MUST be applicable to multihomed peers only. 315 4. Service interface MUST have an Ethernet-Segment identifier 316 assignement. 318 5. New service interface handling procedures MUST be backward 319 compatible with implementation procedures defined in [RFC7432] 321 6. New service interface MUST support EVPN multicast routes defined 322 in [I-D.ietf-bess-evpn-igmp-mld-proxy] too. 324 4. Solution Description 326 4.1. Control Plane Operation 328 4.1.1. MAC/IP Address Advertisement 330 4.1.1.1. Local Unicast MAC learning 332 [RFC7432] section 9.1 describes different mechanism to learn Unicast 333 MAC address locally. PEs where AC aware bundling is supported, MAC 334 address is learnt along with VLAN associated with AC. 336 MAC/IP route construction follows mechanism defined in [RFC7432] 337 section 9.2.1. An attach Attachment Circuit ID Extended Community 338 (Section 6.1) must be attached to EVPN RT-2. 340 4.1.1.2. Remote Unicast MAC learning 342 Presence of Attachment Circuit ID Extended Community (Section 6.1) 343 MUST be ignored by non multihoming PEs. Remote PE (non-multihome PE) 344 MUST process MAC route as defined in [RFC7432] 346 Multihoming peer MUST process Attachment Circuit ID Extended 347 Community (Section 6.1) to attach remote MAC address to appropriate 348 AC. 350 From Figure 1, PE2 receives MAC route for MAC-1. It MUST get 351 Attachment Circuit ID from Attachment Circuit ID Extended Community 352 (Section 6.1) in RT-2 and associate MAC address with specific subnet. 354 4.1.2. Multicast route Advertisement 355 4.1.2.1. Local multicast state 357 When a local multihomed AC in given Broadcast Domain receives IGMP 358 membership request, it MUST synchronize multicast state by 359 originating multicast route defined in 360 [I-D.ietf-bess-evpn-igmp-mld-proxy]. When Service interface is AC 361 aware it MUST attach Attachment Circuit ID Extended Community 362 (Section 6.1) along with multicast route. For example in Figure 1 363 when H2 sends IGMP membership request for (S,G), CE hashed it to one 364 of the PE. Lets say PE1 received IGMP membership request. PE1 MUST 365 originate multicast route to synchronize multicast state with PE2. 366 Multicast route MUST contain Attachment Circuit ID Extended Community 367 (Section 6.1) along with multicast route. 369 PE1 must originate multicast route updates for any subsequent IGMP 370 membership requests under same or different subnet attaching adequate 371 Attachment Circuit ID Extended Community (Section 6.1). 373 4.1.2.2. Remote multicast state 375 If multihomed PE receives remote multicast route on Broadcast Domain 376 for given ES, route MUST be programmed to correct subnet. Subnet 377 information MUST be extracted from Attachment Circuit ID Extended 378 Community. That value maps to the VLAN of a local AC where the 379 multicast route is associated to. 381 4.2. Data Plane Operation 383 4.2.1. Unicast Forwarding 385 Packet received from CE must follow same procedure as defined in 386 [RFC7432] section 13.1 388 Unknown Unicast packets from a Remote PE MUST follow procedure as per 389 [RFC7432] section 13.2.1. 391 Known unicast Received on a remote PE MUST follow procedure as per 392 [RFC7432] section 13.2.2. In Figure 1, if PE3 receives known unicast 393 packet for destination MAC MAC-1, it MUST follow procedure defined in 394 [RFC7432] section 13.2.2. 396 If destination MAC lookup is performed on known unicast packet, 397 destination MAC lookup MUST provide VLAN and local AC information. 398 For example if PE2 receives unicast packet which is destined to MAC-1 399 (packet might be coming from IRB or remote PE with EVPN tunnel), 400 destination MAC lookup on PE2 MUST provide outgoing port along with 401 associated VLAN value. 403 4.2.2. Multicast Forwarding 405 Multicast traffic from CE and remote PE MUST follow procedure defined 406 in [RFC7432] 408 Multicast traffic received from IRB interface or EVPN tunnel, route 409 lookup would be performed based on IGMP snooping state and traffic 410 would be forwarded to appropriate AC. 412 5. Mis-configuration across multihoming peers 414 If there is mis-configuration of VLAN or VLAN range across 415 multihoming peers, same MAC address would be learnt with different 416 VLAN per Broadcast Domain. In this case Error message MUST be thrown 417 for operator to make configuration changes. Furthermore, the errored 418 MAC route MUST be ignored. 420 6. BGP Encoding 422 This document defines one new BGP Extended Community for EVPN. 424 6.1. Attachment Circuit ID Extended Community 426 A new EVPN BGP Extended Community called Attachment Circuit ID is 427 introduced. This new extended community is a transitive extended 428 community with the Type field of 0x06 (EVPN) and the Sub-Type of TBD. 429 It is advertised along with EVPN MAC/IP Advertisement Route (Route 430 Type 2) per [RFC7432] for AC-Aware Bundling Service Interface. It 431 may also be advertised along with EVPN Multicast Route (Route Type 7 432 and 8) as per [I-D.ietf-bess-evpn-igmp-mld-proxy]. Generically 433 speaking, the new extended community must be attached to any routes 434 which require specific VLAN identification. 436 The Attachment Circuit ID Extended Community is encoded as an 8-octet 437 value as follows: 439 0 1 2 3 440 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 441 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 442 | Type=0x06 | Sub-Type=TBD | Reserved (16 bits) | 443 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 444 | Attachment Circuit ID (32 bits) | 445 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 447 Attachment Circuit ID Extended Community 449 The attachment circuit ID plays the role of normalized VID. It is 450 defined as per [I-D.ietf-bess-evpn-vpws-fxc]. 452 6.2. Ethernet-tag field vs AC ID Extended Community 454 The current proposal is entirely backward compabitible with [RFC7432] 455 VLAN-aware bundling mode since the Ethernet-tag field remains intact. 456 However, it has its own drawbacks. For instance with multicast, the 457 same (S,G) maybe be used over different subnets. In that case, the 458 same route MUST carry multiple AC ID Extended Community; one per 459 attachment Circuit ID / VLAN. It may happen that the number of VLAN 460 is faily large. Multiple routes with different RD may be required to 461 carry such amount of Extended Community. This approach is 462 complexifying the overall solution and implementation. 464 To remedy to that situation, the attachment Circuit ID MAY be set to 465 0xFFFF_FFFF. That value tells peer PE that the attachment Circuit ID 466 is carried has part of the Ethernet Tag field of the associated 467 route. Since the key of the EVPN route is unique, multiple AC ID 468 Extended Community per route is no longer required. There is 469 drawback. It pose backward interoperability issue with PE expecting 470 a zero Ethernet-TAG ID. 472 7. Security Considerations 474 The same Security Considerations described in [RFC7432] are valid for 475 this document. 477 8. IANA Considerations 479 A new transitive extended community Type of 0x06 and Sub-Type of TBD 480 for EVPN Attachment Circuit Extended Community needs to be allocated 481 by IANA. 483 9. Acknowledgement 485 10. References 487 10.1. Normative References 489 [I-D.ietf-bess-evpn-igmp-mld-proxy] 490 Sajassi, A., Thoria, S., Patel, K., Yeung, D., Drake, J., 491 and W. Lin, "IGMP and MLD Proxy for EVPN", draft-ietf- 492 bess-evpn-igmp-mld-proxy-00 (work in progress), March 493 2017. 495 [I-D.ietf-bess-evpn-vpws-fxc] 496 Sajassi, A., Brissette, P., Uttaro, J., Drake, J., 497 Boutros, S., and J. Rabadan, "EVPN VPWS Flexible Cross- 498 Connect Service", draft-ietf-bess-evpn-vpws-fxc-03 (work 499 in progress), June 2021. 501 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 502 Requirement Levels", BCP 14, RFC 2119, 503 DOI 10.17487/RFC2119, March 1997, 504 . 506 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 507 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 508 May 2017, . 510 10.2. Informative References 512 [RFC7365] Lasserre, M., Balus, F., Morin, T., Bitar, N., and Y. 513 Rekhter, "Framework for Data Center (DC) Network 514 Virtualization", RFC 7365, DOI 10.17487/RFC7365, October 515 2014, . 517 [RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A., 518 Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based 519 Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February 520 2015, . 522 [RFC8365] Sajassi, A., Ed., Drake, J., Ed., Bitar, N., Shekhar, R., 523 Uttaro, J., and W. Henderickx, "A Network Virtualization 524 Overlay Solution Using Ethernet VPN (EVPN)", RFC 8365, 525 DOI 10.17487/RFC8365, March 2018, 526 . 528 Authors' Addresses 530 Ali Sajassi 531 Cisco Systems 533 Email: sajassi@cisco.com 535 Patrice Brissette 536 Cisco Systems 538 Email: pbrisset@cisco.com 540 Mankamana Mishra 541 Cisco Systems 543 Email: mankamis@cisco.com 544 Samir Thoria 545 Cisco Systems 547 Email: sthoria@cisco.com 549 Jorge Rabadan 550 Nokia 552 Email: jorge.rabadan@nokia.com 554 John Drake 555 Juniper Networks 557 Email: jdrake@juniper.net