idnits 2.17.1 draft-ietf-bier-pim-signaling-03.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 (June 21, 2018) is 2130 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 403 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: December 23, 2018 June 21, 2018 16 PIM Signaling Through BIER Core 17 draft-ietf-bier-pim-signaling-03 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 . . . . . . . . . . . . . . . . . . . . . . 7 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 . . . . . . . . . . . . . . . . . . . . . . . 8 90 6. Applicability to MVPN . . . . . . . . . . . . . . . . . . . . . 9 91 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 9 92 8. Security Considerations . . . . . . . . . . . . . . . . . . . . 9 93 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 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 . . . . . . . . . . . . . . . . . . . . . 10 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 . . . . . . . . . . . . 11 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 dataplain packets. BFIR is 158 term used for dataplain packet forwarding. 160 BBR: 162 BIER Boundary router. The router between the PIM domain and 163 BIER domain. Maintains PIM adjacency for all routers attached 164 to it on the PIM domain and terminates the PIM adjacency 165 toward the BIER domain. 167 IBBR: 169 Ingress BIER Boundary Router. The ingress router from 170 signaling point of view. It maintains PIM adjacency toward the 171 PIM domain and determines if PIM joins and prunes arriving 172 from PIM domain need to be signaled across the BIER domain. If 173 so 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. The 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-------->|-------------> Datapatah 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 attach 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 attach pim domain. 238 The BFER and BFIR are BBR from datapath point of view. It should be 239 noted the new procedures in this draft are only applicable to 240 signaling and there are no changes from datapath point of view. 242 3.1. Ingress BBR procedure 244 IBBR will create pim adjacency to all pim routers attach to it toward 245 the pim domain. 247 When a PIM join or prune for certain (S,G) arrives, the IBBR first 248 determines weather the join or prune is meant for a source that is 249 reachable through the bier domain. As an example, this source is 250 located on a disjoint PIM domain that is reachable through the BIER 251 domain. If so the ibbr will try to resolve the source via an ebbr 252 closest to the source. 254 The procedure to find the ebbr (BFIR from datapath point of view) can 255 be via many mechanisms explained in more detail in upcoming section. 257 After discovering the EBBR and its BFR-ID (flooded via IGP BIER 258 extension), the IBBR will construct the BIER header. The signaling 259 packet, in this case the PIM join/prune packet, is encapsulated in 260 the BIER header and transported through BIER domain to EBBR. 262 The IBBR will track all the PIM interfaces on the attach pim domain 263 which are interested in a certain (S,G). It creates multicast states 264 for arriving (S,G)s from pim domain, with incoming interface as BIER 265 "tunnel" interface and outgoing interface as the pim domain 266 interface(s) on which PIM Join(s) were received on. 268 3.1.1. Determining EBBR on IBBR 270 As it was explained in previous section, IBBR needs to determine the 271 EBBR closest to the source. This is needed to encode the BIER header 272 BitString field to forward the signaling packet through the BIER 273 domain. 275 It should be noted, the PIM domains can be either part of the same 276 IGP area as BIER domain(single area) or are stitched to the BIER 277 domain via an ABR or ASBR routers. As such on IBBR, there can be many 278 different procedures to determine the EBBR. Some examples of these 279 procedures have been provided in Appendix A. 281 3.1.4. BIER packet construction at IBBR 283 The BIER header will be encoded with the BFR-id of the IBBR(with 284 appropriate bit set in the bitstring) and the PIM signaling packet is 285 then encapsulated in the packet. 287 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 288 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 289 | BIFT-id | TC |S| TTL | 290 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 291 |Nibble | Ver | BSL | Entropy | 292 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 293 |OAM|Rsv| DSCP | Proto | BFIR-id | 294 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 295 | BitString (first 32 bits) ~ 296 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 297 ~ ~ 298 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 299 ~ BitString (last 32 bits) | 300 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 302 BIERHeader.Proto = IPv4 or IPv6 304 BIERHeader.BitString= Bit corresponding to the BFR-ID of the EBBR 306 BIERHeader.BFIR-id = BFR-Id of the BER originating the encapsulated 307 PIM packet, i.e. the IBBR. 309 Rest of the values in the BIER header are determined based on the 310 network (MPLS/non-MPLS), capabilities (BSL), and network 311 configuration. 313 3.2. Signaling PIM through the BIER domain procedure 315 Throughout the BIER domain the BIER forwarding procedure is in par 316 with RFC 8279. No BIER router will examine the BIER packet 317 encapsulating the PIM signaling packet. As such there is no multicast 318 state build in the BIER domain. 320 The packet will be forwarded through the BIER domain until it reaches 321 the BER with matching BFR-ID as in the BIERHeader.Bitstring. EBBR 322 will remove the BIER header and examine the PIM IPv4 or IPv6 323 signaling packet farther as per EBBR Procedure section. 325 3.3. EBBR procedure 326 After receiving the BIER packet and determining this packet is a 327 signaling packet, EBBR will remove the BIER header from PIM packet. 328 It will do a route lookup for the source of the pim signaling packet. 329 If the source is on a locally attach pim domain, it forwards the PIM 330 packet toward the source. 332 With same token the EBBR creates a multicast state with incoming 333 interface as same interface that PIM join packet was forwarded and 334 outgoing interfaces of BIER tunnel with BIER-Header.BFIR-id and its 335 corresponding Sub-Domain as one of the BFER of the tunnel. 337 The EBBR will also build a forwarding table for the arriving (S,G) 338 using the BIERHeader.BFIR-id and the Sub-Domain they arrived on, in 339 short it tracks all IBBRs interested in this (S,G). This is explained 340 in section 4.1. 342 It should be noted EBBR will maintain PIM adjacency toward the PIM 343 domain and all PIM routers which are connected to it. 345 At this point the end-to-end multicast traffic flow setup is 346 complete. 348 4. Datapath Forwarding 350 4.1. BFIR tracking of (S,G) 352 For a specific Source and Group, BFIR (EBBR)should track all the 353 interested BFERs (IBBRs) via arriving PIM signaling from BIER Domain. 354 BFIR should build its multicast tree with incoming interface (IIF) as 355 PIM interface (in PIM domain) and out going interfaces OIFs set as 356 the of the interested BFERs (in BIER Domain). 358 4.2. Datapath traffic flow 360 When the multicast data traffic arrives on the BFIR (EBBR) the router 361 will find all the interested BFERs for that specific (S,G). The 362 router then constructs the BIERHeader.BitString with all the BFER 363 interested in the group and will forward the packet to the BIER 364 domain. The BFER(s) will accept the packets and remove the BIER 365 header and forward the multicast packet as per pre-build multicast 366 state for (G) and its outgoing interfaces. 368 5. PIM-ASM behavior 370 In case of PIM ASM the procedure for LEAFs joining RP is same as 371 above. It should be noted that for ASM, the EBBR is determined with 372 respect to the RP instead of the source. 374 6. Applicability to MVPN 376 With just minor changes, the above procedures apply to MVPN as well, 377 with BFIR/BFER/EBBR/IBBR being VPN PEs. 379 All the PIM related procedures, and the determination of EBBR happens 380 in the context of a VRF, following procedures for PIM-MVPN. 382 When a PIM packet arrives from PIM domain attached to the vrf (IBBR), 383 and it is determine that the source is reachable via the vrf through 384 the BIER domain, a PIM signaling message is sent via BIER to the 385 EBBR. In this case usually the PE terminating the PIM-MVPN is the 386 EBBR. A label is imposed before the BIER header is imposed, and the 387 "proto" field in the BIER header is set to 1 (for "MPLS packet with 388 downstream-assigned label at top of stack"). The label is advertised 389 by the EBBR/BFIR to associate incoming packets to its correct VRF. In 390 many scenarios a label is already bound to the VRF loopback address 391 on the EBBR/BFIR and it can be used. 393 When a multicast data packet is sent via BIER by an EBBR/BFIR, a 394 label is imposed before the BIER packet is imposed, and the "proto" 395 field in the BIER header is set to 1 (for "MPLS packet with 396 downstream-assigned label at top of stack"). The label is assigned to 397 the VPN consistently on all VRFs [draft-zzhang-bess-mvpn-evpn- 398 aggregation-label]. 400 If the more complicated label allocation scheme is needed for the 401 data packets as specified in [draft-zzhang-bess-mvpn-evpn- 402 aggregation-label], then additional PMSI signaling is needed as 403 specified in [RFC6513]. 405 To support per-area subdomain in this case, the ABRs would need to 406 become VPN PEs and maintain per-VPN state so it is unlikely 407 practical. 409 7. IANA Considerations 411 This document contains no actions for IANA. 413 8. Security Considerations 415 The procedures of this document do not, in themselves, provide 416 privacy, integrity, or authentication for the control plane or the 417 data plane. For a discussion of the security considerations regarding 418 the use of BIER, please see RFC8279 and RFC8296. Security 419 considerations regarding PIM protocol is based on RFC4601. 421 9. References 422 9.1. Normative References 424 [BIER_ARCH] Wijnands, IJ., Rosen, E., Dolganow, A., Przygienda, T., 425 and S. Aldrin, "Multicast using Bit Index Explicit Replication", rfc 426 8279, October 2016. 428 9.2. Informative References 430 [BIER_MVPN] Rosen, E., Ed., Sivakumar, M., Wijnands, IJ., Aldrin, S., 431 Dolganow, A., and T. Przygienda, "Multicast VPN Using Bier", 432 internet-draft draft-ietf-bier-mvpn-11, March 2018. 434 [ISIS_BIER_EXTENSIONS] Ginsberg, L., Przygienda, T., Aldrin, S., and 435 Z. Zhang, "BIER Support via ISIS", internet-draft draft-ietf-bier- 436 isis-extensions-11.txt, June 2018. 438 [OSPF_BIER_EXTENSIONS] Psenak, P., Kumar, N., Wijnands, IJ., 439 Dolganow, A., Przygienda, T., Zhang, Z., and S. Aldrin, "OSPF 440 Extensions for Bit Index Explicit Replication", internet-draft draft- 441 ietf-ospf-bier-extensions-18.txt, June 2018. 443 10. Acknowledgments 445 Appendix A 447 This section provides some examples and routing procedures that can 448 be used to determine the EBBR on IBBR. It should be noted, the PIM 449 domains can be either part of the same IGP area as BIER domain(single 450 area) or are stitched to the BIER domain via an ABR or ASBR routers. 451 As such on IBBR, there can be many different procedures to determine 452 the EBBR. Not all procedures are listed below. 454 A.1. SPF 456 On IBBR SPF procedures can be used to find the EBBR closest to the 457 source. 459 Assuming the BIER domain is consist of all BIER forwarding routers, 460 SPF calculation can identify the router advertising the prefix for 461 the source. A post process can find the EBBR by walking from the 462 advertising router back to the IBBR in the reverse direction of 463 shortest path tree branch until the first BFR is encountered. 465 A.2. Indirect next-hop 467 Alternatively, the route to the source could have an indirect next- 468 hop that identifies the EBBR. These methods are explained in the 469 following sections. 471 A.2.1. Static Route 473 On IBBR there can be a static route configured for the source, with 474 source next-hop set as EBBR BIER prefix. 476 A.2.2. Interior Border Gateway Protocol (iBGP) 478 Consider the following topology: 480 bbr bbr 481 ebbr ibbr 482 |--pim Domain--|-----bier domain-----|--pim domain--| 483 S--( A )----------( B ) ---- ( C ) ---- ( D )----------( E )--h 485 Figure 2 487 Suppose BGP is enable between EBBR (B) and IBBR (D) and the PIM 488 Domain routes are redistributed to the BIER domain via BGP. This 489 would include the Multicast Source IP address (S), which resides in 490 the PIM Domain. In such case BGP should use the same loopback 491 interface as its next-hop as the BBR prefix. This will ensure that 492 all PIM domain routes, including the Multicast Source IP address (S) 493 are resolve via BBR's bier prefix id as thier next-hop. When the host 494 (h) triggers a PIM join message to IBBR (D), IBBR tries to resolve 495 (S). It resolves (S) via BGP installed route and realizes its next- 496 hop is EBBR (B). IBBR will use this next-hop (B) to find its 497 corresponding BIER bit index. 499 This procedure is inline with RFC6826 mLDP in-band signaling section 500 2. 502 A.3. Inter-area support 504 If each area has its own BIER sub-domain, the above procedure for 505 post-SPF could identify one of the ABRs and the EBBR. If a sub-domain 506 spans multiple areas, then additional procedures as described in A.2 507 is needed. 509 A.3.1. Inter-area Route summarization 511 In a multi-area topology, a BIER sub-domain can span a single area. 512 Suppose this single area is constructed entirely of Bier capable 513 routers and the ABRs are the BIER Boundary Routers attaching the BIER 514 sub-domain in this area to PIM domains in adjacent areas. These BBRs 515 can summarize the PIM domain routes via summary routes, as an example 516 for OSPF, a type 3 summary LSAs can be used to advertise summary 517 routes from a PIM domain area to the BIER area. In such scenarios the 518 IBBR can be configured to look up the Source via IGP database and use 519 the summary routes and its Advertising Router field to resolve the 520 EBBR. The IBBR needs to ensure that the IGP summary route is 521 generated by a BFR. This can be achieved by ensuring that bier sub- 522 tlv exists for this route. If multiple BBRs (ABRs) have generated the 523 same summary route the lowest Advertising Router IP can be selected 524 or a vendor specific hashing algorithm can select the summary route 525 from one of the BBRs. 527 Hooman Bidgoli (editor) 528 Nokia 529 600 March Rd. 530 Ottawa, Ontario K2K 2E6 531 Canada 533 Email: hooman.bidgoli@nokia.com 535 Fengman Xu 536 Verizon 537 400 International PKWY 538 Richardson, Tx 75081 539 US 541 Email: fengman.xu@verizon.com 543 Jayant Kotalwar 544 Nokia 545 380 N Bernardo Ave 546 Mountain View, CA 94043 547 US 549 Email: jayant.kotalwar@nokia.com 551 Andrew Dolganow 552 Nokia 553 750D Chai Chee Rd 554 06-06, Viva Business Park 555 Singapore 469004 557 Email: Andrew.dolganow@nokia.com 559 IJsbrand Wijnands 560 Cisco System 561 De Kleetlaan 6a 562 Diegem 1831 563 Belgium 564 Email: ice@cisco.com 566 Mankamana Mishra 567 Cisco System 568 821 alder drive 569 Milpitas California 570 USA 572 Email: mankamis@cisco.com 574 Zhaohui Zhang 575 Juniper Networks 576 USA 578 EMail: zzhang@juniper.net