idnits 2.17.1 draft-ietf-bier-pim-signaling-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 : ---------------------------------------------------------------------------- ** The document seems to lack an Authors' Addresses Section. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (October 17, 2018) is 2015 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 section? 'RFC2119' on line 125 looks like a reference -- Missing reference section? 'RFC6513' on line 409 looks like a reference Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 BIER Workgroup H. Bidgoli, Ed. 3 Internet Draft A. Dolganow 4 Intended status: Standard Track J. Kotalwar 5 Nokia 6 Fengman Xu 7 Verizon 8 IJ. Wijnand 9 Mankamana Mishra 10 Cisco Systems, Inc. 11 Z. Zhang 12 Juniper Networks 14 Expires: April 20, 2019 October 17, 2018 16 PIM Signaling Through BIER Core 17 draft-ietf-bier-pim-signaling-04 19 Abstract 21 Bit Index Explicit Replication (BIER) is an architecture that 22 provides multicast forwarding through a "BIER domain" without 23 requiring intermediate routers to maintain multicast related per-flow 24 state. Neither does BIER require an explicit tree-building protocol 25 for its operation. A multicast data packet enters a BIER domain at a 26 "Bit-Forwarding Ingress Router" (BFIR), and leaves the BIER domain at 27 one or more "Bit-Forwarding Egress Routers" (BFERs). The BFIR router 28 adds a BIER header to the packet. Such header contains a bit-string 29 in which each bit represents exactly one BFER to forward the packet 30 to. The set of BFERs to which the multicast packet needs to be 31 forwarded is expressed by the according set of bits switched on in 32 BIER packet header. 34 This document describes the procedure needed for PIM Joins and Prunes 35 to be signaled through a BIER core. Allowing PIM routers to run 36 traditional PIM multicast services through a BIER core. 38 Status of this Memo 40 This Internet-Draft is submitted in full conformance with the 41 provisions of BCP 78 and BCP 79. 43 Internet-Drafts are working documents of the Internet Engineering 44 Task Force (IETF), its areas, and its working groups. Note that 45 other groups may also distribute working documents as Internet- 46 Drafts. 48 Internet-Drafts are draft documents valid for a maximum of six months 49 and may be updated, replaced, or obsoleted by other documents at any 50 time. It is inappropriate to use Internet-Drafts as reference 51 material or to cite them other than as "work in progress." The list 52 of current Internet-Drafts can be accessed at 53 http://www.ietf.org/ietf/1id-abstracts.txt 55 The list of Internet-Draft Shadow Directories can be accessed at 56 http://www.ietf.org/shadow.html 58 This Internet-Draft will expire on October 8, 2017. 60 Copyright Notice 62 Copyright (c) 2018 IETF Trust and the persons identified as the 63 document authors. All rights reserved. 65 This document is subject to BCP 78 and the IETF Trust's Legal 66 Provisions Relating to IETF Documents 67 (http://trustee.ietf.org/license-info) in effect on the date of 68 publication of this document. Please review these documents 69 carefully, as they describe your rights and restrictions with respect 70 to this document. Code Components extracted from this document must 71 include Simplified BSD License text as described in Section 4.e of 72 the Trust Legal Provisions and are provided without warranty as 73 described in the Simplified BSD License. 75 Table of Contents 77 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 78 2. Conventions used in this document . . . . . . . . . . . . . . . 3 79 2.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . . 3 80 3. PIM Signaling Through BIER domain . . . . . . . . . . . . . . . 5 81 3.1. Ingress BBR procedure . . . . . . . . . . . . . . . . . . . 6 82 3.1.1. Determining EBBR on IBBR . . . . . . . . . . . . . . . 6 83 3.1.4. BIER packet construction at IBBR . . . . . . . . . . . 7 84 3.2. Signaling PIM through the BIER domain procedure . . . . . . 7 85 3.3. EBBR procedure . . . . . . . . . . . . . . . . . . . . . . 8 86 4. Datapath Forwarding . . . . . . . . . . . . . . . . . . . . . . 8 87 4.1. BFIR tracking of (S,G) . . . . . . . . . . . . . . . . . . 8 88 4.2. Datapath traffic flow . . . . . . . . . . . . . . . . . . . 8 89 5. PIM-ASM behavior . . . . . . . . . . . . . . . . . . . . . . . 9 90 6. Applicability to MVPN . . . . . . . . . . . . . . . . . . . . . 9 91 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 9 92 8. Security Considerations . . . . . . . . . . . . . . . . . . . . 9 93 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 94 9.1. Normative References . . . . . . . . . . . . . . . . . . . 10 95 9.2. Informative References . . . . . . . . . . . . . . . . . . 10 96 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10 97 Appendix A . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 98 A.1. SPF . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 99 A.2. Indirect next-hop . . . . . . . . . . . . . . . . . . . . . 11 100 A.2.1. Static Route . . . . . . . . . . . . . . . . . . . . . 11 101 A.2.2. Interior Border Gateway Protocol (iBGP) . . . . . . . . 11 102 A.3. Inter-area support . . . . . . . . . . . . . . . . . . . . 11 103 A.3.1. Inter-area Route summarization . . . . . . . . . . . . 12 105 1. Introduction 107 Consider large networks deploying traditional PIM multicast service. 108 Typically, each portion of these large networks have their own 109 mandates and requirements. 111 It might be desirable to deploy BIER technology in some part of these 112 networks to replace traditional PIM services. In such cases 113 downstream PIM states need to be signaled over BIER Domain toward the 114 source. 116 This draft explains the procedure to signal PIM joins and prunes 117 through a BIER Domain, as such enable provisioning of traditional PIM 118 services through a BIER Domain. 120 2. Conventions used in this document 122 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 123 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 124 document are to be interpreted as described in RFC 2119 [RFC2119]. 126 2.1. Definitions 128 Some of the terminology specified in [I-D. rfc8279] is replicated 129 here and extended by necessary definitions: 131 BIER: 133 Bit Index Explicit Replication (The overall architecture of 134 forwarding multicast using a Bit Position). 136 BFR: 138 Bit Forwarding Router (A router that participates in Bit Index 139 Multipoint Forwarding).A BFR is identified by a unique BFR- 140 prefix in a BIER domain. 142 BFIR: 144 Bit Forwarding Ingress Router (The ingress border router that 145 inserts the BM into the packet). Each BFIR must have a valid 146 BFR-id assigned. In this draft BIER will be used for 147 forwarding and tunneling of control plain packet (i.e. PIM) 148 and forwarding dataplane packets. BFIR is term used for 149 dataplane packet forwarding. 151 BFER: 153 Bit Forwarding Egress Router. A router that participates in 154 Bit Index Forwarding as leaf. Each BFER must be a BFR. Each 155 BFER must have a valid BFR-id assigned. In this draft BIER 156 will be used for forwarding and tunneling of control plain 157 packet (i.e. PIM) and forwarding dataplane packets. BFIR is 158 term used for dataplane packet forwarding. 160 BBR: 162 BIER Boundary router. A router between the PIM domain and BIER 163 domain. Maintains PIM adjacency for all routers attached to it 164 on the PIM domain and terminates the PIM adjacency toward the 165 BIER domain. 167 IBBR: 169 Ingress BIER Boundary Router. An ingress router from signaling 170 point of view. It maintains PIM adjacency toward the PIM 171 domain and determines if PIM joins and prunes arriving from 172 PIM domain need to be signaled across the BIER domain. If so 173 it terminates the PIM adjacency toward the BIER domain and 174 signals the PIM joins/prunes through the BIER core. 176 EBBR: 178 Egress BIER Boundary Router. An egress router in BIER domain 179 from signaling point of view. It terminates the BIER packet 180 and forwards the signaled joins and prunes into PIM Domain. 182 BFT: 184 Bit Forwarding Tree used to reach all BFERs in a domain. 186 BIFT: 188 Bit Index Forwarding Table. 190 BIER sub-domain: 192 A further distinction within a BIER domain identified by its 193 unique sub-domain identifier. A BIER sub-domain can support 194 multiple BitString Lengths. 196 BFR-id: 198 An optional, unique identifier for a BFR within a BIER sub- 199 domain. 201 3. PIM Signaling Through BIER domain 203 BBR BBR 204 |--PIM Domain--|-----BIER domain-----|--PIM domain--| 205 S--( A )----------( B ) ---- ( C ) ---- ( D )----------( E )--h 207 EBBR IBBR 208 Sig <-----PIM-----|<--BIER Tunneling----|<----PIM------ 209 (new) 211 bfir bfer 212 ------------->|--------BIER-------->|-------------> Datapath 213 (no change) 215 Figure 1: BIER boundary router 217 As per figure 1, the procedures of PIM signaling is done at the BIER 218 boundary router. The BIER boundary router (BBR) are connected to PIM 219 capable routers toward the PIM domain and BIER routers toward the 220 BIER domain. PIM routers in PIM domain continue to send PIM state 221 messages to the BBR. The BBR will create PIM adjacency between all 222 the PIM routers attached to it on the PIM domain. That said the BBR 223 does not propagate all PIM packets natively into the BIER domain. 224 Instead when it determines that the PIM join or prune messages needs 225 to be signaled through the BIER domain it will tunnel the PIM packet 226 through the BIER network. This tunneling is only done for signaling 227 purposes and not for creating a PIM adjacency between the two 228 disjoint PIM domains through the BIER domain. 230 The terminology ingress BBR (IBBR) and egress BBR (EBBR) are relative 231 from signaling point of view. 233 The ingress BBR will determine if an arriving PIM join or prune needs 234 to be signaled across the BIER domain. While the egress BBR will 235 determine if the arriving BIER packet is a signaling packet and if so 236 it will generate a PIM signaling packet toward its attached PIM 237 domain. 239 The BFER and BFIR are BBR from datapath point of view. It should be 240 noted the new procedures in this draft are only applicable to 241 signaling and there are no changes from datapath point of view. 243 3.1. Ingress BBR procedure 245 IBBR will create PIM adjacency to all PIM routers attached to it 246 toward the PIM domain. 248 When a PIM join or prune for certain (S,G) arrives, the IBBR first 249 determines weather the join or prune is meant for a source that is 250 reachable through the BIER domain. As an example, this source is 251 located on a disjoint PIM domain that is reachable through the BIER 252 domain. If so the IBBR will try to resolve the source via an EBBR 253 closest to the source. 255 The procedure to find the EBBR (BFIR from datapath point of view) can 256 be via many mechanisms explained in more detail in upcoming section. 258 After discovering the EBBR and its BFR-ID (flooded via IGP BIER 259 extension), the IBBR will change the PIM signaling packet source IP 260 address to its BIER prefix address (standard PIM procedure). It will 261 also keep the destination address as the well known multicast IP 262 address. It then will construct the BIER header. The signaling 263 packet, in this case the PIM join/prune packet, is encapsulated in 264 the BIER header and transported through BIER domain to EBBR. 266 The IBBR will track all the PIM interfaces on the attached PIM domain 267 which are interested in a certain (S,G). It creates multicast states 268 for arriving (S,G)s from PIM domain, with incoming interface as BIER 269 "tunnel" interface and outgoing interface as the PIM domain 270 interface(s) on which PIM Join(s) were received on. 272 3.1.1. Determining EBBR on IBBR 274 As it was explained in previous section, IBBR needs to determine the 275 EBBR closest to the source. This is needed to encode the BIER header 276 BitString field to forward the signaling packet through the BIER 277 domain. 279 It should be noted, the PIM domains can be either part of the same 280 IGP area as BIER domain(single area) or are stitched to the BIER 281 domain via an ABR or ASBR routers. As such on IBBR, there can be many 282 different procedures to determine the EBBR. Some examples of these 283 procedures have been provided in Appendix A. 285 3.1.4. BIER packet construction at IBBR 287 The BIER header will be encoded with the BFR-id of the IBBR(with 288 appropriate bit set in the bitstring) and the PIM signaling packet is 289 then encapsulated in the packet. 291 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 292 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 293 | BIFT-id | TC |S| TTL | 294 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 295 |Nibble | Ver | BSL | Entropy | 296 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 297 |OAM|Rsv| DSCP | Proto | BFIR-id | 298 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 299 | BitString (first 32 bits) ~ 300 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 301 ~ ~ 302 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 303 ~ BitString (last 32 bits) | 304 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 306 BIERHeader.Proto = IPv4 or IPv6 308 BIERHeader.BitString= Bit corresponding to the BFR-ID of the EBBR 310 BIERHeader.BFIR-id = BFR-Id of the BER originating the encapsulated 311 PIM packet, i.e. the IBBR. 313 Rest of the values in the BIER header are determined based on the 314 network (MPLS/non-MPLS), capabilities (BSL), and network 315 configuration. 317 3.2. Signaling PIM through the BIER domain procedure 319 Throughout the BIER domain the BIER forwarding procedure is in par 320 with RFC 8279. No BIER router will examine the BIER packet 321 encapsulating the PIM signaling packet. As such there is no multicast 322 state build in the BIER domain. 324 The packet will be forwarded through the BIER domain until it reaches 325 the BER with matching BFR-ID as in the BIERHeader.Bitstring. EBBR 326 will remove the BIER header and examine the PIM IPv4 or IPv6 327 signaling packet farther as per EBBR Procedure section. 329 3.3. EBBR procedure 331 After receiving the BIER packet and determining this packet is a 332 signaling packet, EBBR will remove the BIER header from PIM packet. 333 ok will change to "Received PIM join/prune Signaling packet is 334 processed as if it were received from neighbors on a virtual 335 interface, (i.e. as if the pim adjacency was presents, regardless of 336 the fact there is no adjacency) 338 With same token the EBBR creates a multicast state with incoming 339 interface as same interface that PIM join packet was forwarded and 340 outgoing interfaces of BIER tunnel with BIER-Header.BFIR-id and its 341 corresponding Sub-Domain as one of the BFER of the tunnel. 343 The EBBR will also build a forwarding table for the arriving (S,G) 344 using the BIERHeader.BFIR-id and the Sub-Domain they arrived on, in 345 short it tracks all IBBRs interested in this (S,G). This is explained 346 in section 4.1. 348 It should be noted EBBR will maintain PIM adjacency toward the PIM 349 domain and all PIM routers which are connected to it. 351 At this point the end-to-end multicast traffic flow setup is 352 complete. 354 4. Datapath Forwarding 356 4.1. BFIR tracking of (S,G) 358 For a specific Source and Group, BFIR (EBBR)should track all the 359 interested BFERs (IBBRs) via arriving PIM signaling from BIER Domain. 360 BFIR builds its (s,g)forwarding state with incoming interface (IIF) 361 as the RPF interface (in PIM domain) towards the source and one of 362 the outgoing interfaces as for sending to tracked BFERs in the SD. 364 4.2. Datapath traffic flow 366 When the multicast data traffic arrives on the BFIR (EBBR) the router 367 will find all the interested BFERs for that specific (S,G). The 368 router then constructs the BIERHeader.BitString with all the BFER 369 interested in the group and will forward the packet to the BIER 370 domain. The BFER(s) will accept the packets and remove the BIER 371 header and forward the multicast packet as per pre-build multicast 372 state for (S,G) and its outgoing interfaces. 374 5. PIM-ASM behavior 376 In case of PIM ASM the procedure for LEAFs joining RP is same as 377 above. It should be noted that for ASM, the EBBR is determined with 378 respect to the RP instead of the source. 380 6. Applicability to MVPN 382 With just minor changes, the above procedures apply to MVPN as well, 383 with BFIR/BFER/EBBR/IBBR being VPN PEs. 385 All the PIM related procedures, and the determination of EBBR happens 386 in the context of a VRF, following procedures for PIM-MVPN. 388 When a PIM packet arrives from PIM domain attached to the vrf (IBBR), 389 and it is determine that the source is reachable via the vrf through 390 the BIER domain, a PIM signaling message is sent via BIER to the 391 EBBR. In this case usually the PE terminating the PIM-MVPN is the 392 EBBR. A label is imposed before the BIER header is imposed, and the 393 "proto" field in the BIER header is set to 1 (for "MPLS packet with 394 downstream-assigned label at top of stack"). The label is advertised 395 by the EBBR/BFIR to associate incoming packets to its correct VRF. In 396 many scenarios a label is already bound to the VRF loopback address 397 on the EBBR/BFIR and it can be used. 399 When a multicast data packet is sent via BIER by an EBBR/BFIR, a 400 label is imposed before the BIER packet is imposed, and the "proto" 401 field in the BIER header is set to 1 (for "MPLS packet with 402 downstream-assigned label at top of stack"). The label is assigned to 403 the VPN consistently on all VRFs [draft-zzhang-bess-mvpn-evpn- 404 aggregation-label]. 406 If the more complicated label allocation scheme is needed for the 407 data packets as specified in [draft-zzhang-bess-mvpn-evpn- 408 aggregation-label], then additional PMSI signaling is needed as 409 specified in [RFC6513]. 411 To support per-area subdomain in this case, the ABRs would need to 412 become VPN PEs and maintain per-VPN state so it is unlikely 413 practical. 415 7. IANA Considerations 417 This document contains no actions for IANA. 419 8. Security Considerations 420 The procedures of this document do not, in themselves, provide 421 privacy, integrity, or authentication for the control plane or the 422 data plane. For a discussion of the security considerations regarding 423 the use of BIER, please see RFC8279 and RFC8296. Security 424 considerations regarding PIM protocol is based on RFC4601. 426 9. References 428 9.1. Normative References 430 [BIER_ARCH] Wijnands, IJ., Rosen, E., Dolganow, A., Przygienda, T., 431 and S. Aldrin, "Multicast using Bit Index Explicit Replication", rfc 432 8279, October 2016. 434 9.2. Informative References 436 [BIER_MVPN] Rosen, E., Ed., Sivakumar, M., Wijnands, IJ., Aldrin, S., 437 Dolganow, A., and T. Przygienda, "Multicast VPN Using Bier", 438 internet-draft draft-ietf-bier-mvpn-11, March 2018. 440 [ISIS_BIER_EXTENSIONS] Ginsberg, L., Przygienda, T., Aldrin, S., and 441 Z. Zhang, "BIER Support via ISIS", internet-draft draft-ietf-bier- 442 isis-extensions-11.txt, June 2018. 444 [OSPF_BIER_EXTENSIONS] Psenak, P., Kumar, N., Wijnands, IJ., 445 Dolganow, A., Przygienda, T., Zhang, Z., and S. Aldrin, "OSPF 446 Extensions for Bit Index Explicit Replication", internet-draft draft- 447 ietf-ospf-bier-extensions-18.txt, June 2018. 449 10. Acknowledgments 451 Appendix A 453 This section provides some examples and routing procedures that can 454 be used to determine the EBBR on IBBR. It should be noted, the PIM 455 domains can be either part of the same IGP area as BIER domain(single 456 area) or are stitched to the BIER domain via an ABR or ASBR routers. 457 As such on IBBR, there can be many different procedures to determine 458 the EBBR. Not all procedures are listed below. 460 A.1. SPF 462 On IBBR SPF procedures can be used to find the EBBR closest to the 463 source. 465 Assuming the BIER domain is consist of all BIER forwarding routers, 466 SPF calculation can identify the router advertising the prefix for 467 the source. A post process can find the EBBR by walking from the 468 advertising router back to the IBBR in the reverse direction of 469 shortest path tree branch until the first BFR is encountered. 471 A.2. Indirect next-hop 473 Alternatively, the route to the source could have an indirect next- 474 hop that identifies the EBBR. These methods are explained in the 475 following sections. 477 A.2.1. Static Route 479 On IBBR there can be a static route configured for the source, with 480 source next-hop set as EBBR BIER prefix. 482 A.2.2. Interior Border Gateway Protocol (iBGP) 484 Consider the following topology: 486 BBR BBR 487 EBBR IBBR 488 |--PIM Domain--|-----bier domain-----|--PIM domain--| 489 S--( A )----------( B ) ---- ( C ) ---- ( D )----------( E )--h 491 Figure 2 493 Suppose BGP is enable between EBBR (B) and IBBR (D) and the PIM 494 Domain routes are redistributed to the BIER domain via BGP. This 495 would include the Multicast Source IP address (S), which resides in 496 the PIM Domain. In such case BGP should use the same loopback 497 interface as its next-hop as the BBR prefix. This will ensure that 498 all PIM domain routes, including the Multicast Source IP address (S) 499 are resolve via BBR's bier prefix id as their next-hop. When the host 500 (h) triggers a PIM join message to IBBR (D), IBBR tries to resolve 501 (S). It resolves (S) via BGP installed route and realizes its next- 502 hop is EBBR (B). IBBR will use this next-hop (B) to find its 503 corresponding BIER bit index. 505 This procedure is inline with RFC6826 mLDP in-band signaling section 506 2. 508 A.3. Inter-area support 510 If each area has its own BIER sub-domain, the above procedure for 511 post-SPF could identify one of the ABRs and the EBBR. If a sub-domain 512 spans multiple areas, then additional procedures as described in A.2 513 is needed. 515 A.3.1. Inter-area Route summarization 517 In a multi-area topology, a BIER sub-domain can span a single area. 518 Suppose this single area is constructed entirely of Bier capable 519 routers and the ABRs are the BIER Boundary Routers attaching the BIER 520 sub-domain in this area to PIM domains in adjacent areas. These BBRs 521 can summarize the PIM domain routes via summary routes, as an example 522 for OSPF, a type 3 summary LSAs can be used to advertise summary 523 routes from a PIM domain area to the BIER area. In such scenarios the 524 IBBR can be configured to look up the Source via IGP database and use 525 the summary routes and its Advertising Router field to resolve the 526 EBBR. The IBBR needs to ensure that the IGP summary route is 527 generated by a BFR. This can be achieved by ensuring that bier sub- 528 tlv exists for this route. If multiple BBRs (ABRs) have generated the 529 same summary route the lowest Advertising Router IP can be selected 530 or a vendor specific hashing algorithm can select the summary route 531 from one of the BBRs. 533 Hooman Bidgoli (editor) 534 Nokia 535 600 March Rd. 536 Ottawa, Ontario K2K 2E6 537 Canada 539 Email: hooman.bidgoli@nokia.com 541 Fengman Xu 542 Verizon 543 400 International PKWY 544 Richardson, Tx 75081 545 US 547 Email: fengman.xu@verizon.com 549 Jayant Kotalwar 550 Nokia 551 380 N Bernardo Ave 552 Mountain View, CA 94043 553 US 555 Email: jayant.kotalwar@nokia.com 557 Andrew Dolganow 558 Nokia 559 750D Chai Chee Rd 560 06-06, Viva Business Park 561 Singapore 469004 562 Email: Andrew.dolganow@nokia.com 564 IJsbrand Wijnands 565 Cisco System 566 De Kleetlaan 6a 567 Diegem 1831 568 Belgium 570 Email: ice@cisco.com 572 Mankamana Mishra 573 Cisco System 574 821 alder drive 575 Milpitas California 576 USA 578 Email: mankamis@cisco.com 580 Zhaohui Zhang 581 Juniper Networks 582 USA 584 EMail: zzhang@juniper.net