idnits 2.17.1 draft-mcbride-bier-ipv6-requirements-01.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 doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (May 9, 2019) is 1806 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) == Unused Reference: 'RFC2473' is defined on line 500, but no explicit reference was found in the text == Outdated reference: A later version (-10) exists of draft-xie-bier-ipv6-encapsulation-00 == Outdated reference: A later version (-09) exists of draft-zhang-bier-bierin6-02 ** Downref: Normative reference to an Informational RFC: RFC 8354 Summary: 1 error (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 BIER M. McBride 3 Internet-Draft J. Xie 4 Intended status: Standards Track S. Dhanaraj 5 Expires: November 10, 2019 Huawei 6 R. Asati 7 Cisco 8 May 9, 2019 10 BIER IPv6 Requirements 11 draft-mcbride-bier-ipv6-requirements-01 13 Abstract 15 The BIER WG has a charter item to work on mechanisms which use BIER 16 natively in IPv6. This document is intended to help the WG with this 17 effort by specifying requirements for transporting packets, with Bit 18 Index Explicit Replication (BIER) headers, in an IPv6 environment. 19 There will be a need to send IPv6 payloads, to multiple IPv6 20 destinations, using BIER. There have been several proposed solutions 21 in this area. But there hasn't been a document which describes the 22 problem and lists the requirements. The goal of this document is to 23 describe the BIER IPv6 requirements and summarize the pro's and con's 24 of the proposed solutions. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at https://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on November 10, 2019. 43 Copyright Notice 45 Copyright (c) 2019 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (https://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 61 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 62 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 63 2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 3 64 3. BIER IPv6 Scenario's . . . . . . . . . . . . . . . . . . . . 3 65 3.1. BIERv6 for Access Network . . . . . . . . . . . . . . . . 4 66 3.2. BIERv6 for Data Center . . . . . . . . . . . . . . . . . 4 67 3.3. BIERv6 for Core Networks . . . . . . . . . . . . . . . . 5 68 3.4. Implications for BIER in SRv6 . . . . . . . . . . . . . . 5 69 4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 5 70 4.1. L2 Agnostic . . . . . . . . . . . . . . . . . . . . . . . 5 71 4.2. Hop by hop DA modification . . . . . . . . . . . . . . . 5 72 4.3. L4 Inspection . . . . . . . . . . . . . . . . . . . . . . 5 73 4.4. Multicast address in SA field . . . . . . . . . . . . . . 5 74 4.5. Incorrect bits . . . . . . . . . . . . . . . . . . . . . 6 75 4.6. SA filtering . . . . . . . . . . . . . . . . . . . . . . 6 76 4.7. BIER architecture support . . . . . . . . . . . . . . . . 6 77 4.8. Keep it simple . . . . . . . . . . . . . . . . . . . . . 6 78 4.9. Hardware fast path . . . . . . . . . . . . . . . . . . . 6 79 5. Solutions Evaluation . . . . . . . . . . . . . . . . . . . . 6 80 5.1. BIER-ETH encapsulation in IPv6 networks . . . . . . . . . 6 81 5.2. Encode Bitstring in IPv6 destination address . . . . . . 8 82 5.3. Add BIER header into IPv6 Extension Header . . . . . . . 8 83 5.4. Transport BIER as IPv6 payload . . . . . . . . . . . . . 9 84 5.5. Tunneling BIER in a IPv6 tunnel . . . . . . . . . . . . . 10 85 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 86 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10 87 8. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 11 88 9. Normative References . . . . . . . . . . . . . . . . . . . . 11 89 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 91 1. Introduction 93 Bit Index Explicit Replication (BIER) [RFC8279] is an architecture 94 that provides optimal multicast forwarding, without requiring 95 intermediate routers to maintain per-flow state, through the use of a 96 multicast-specific BIER header. [RFC8296] defines two types of BIER 97 encapsulation to run on physical links: one is BIER MPLS 98 encapsulation to run on various physical links that support MPLS, the 99 other is non-MPLS BIER Ethernet encapsulation to run on ethernet 100 links, with an ethertype 0xAB37. This document describes using BIER 101 in non-MPLS IPv6 environments. We explain the requirements of 102 transporting IPv4/IPv6 multicast payloads, from an IPv6 router (BFIR) 103 to multicast IPv6 destinations (BFERs), using BIER. This can include 104 native IPv6 encapsulation and generic tunneling. The goal of this 105 document is to help the BIER WG evaluate the BIER v6 requirements and 106 solutions. 108 1.1. Requirements Language 110 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 111 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 112 document are to be interpreted as described in RFC 2119 [RFC2119]. 114 1.2. Terminology 116 o BIER: Bit Index Explicit Replication. Provides optimal multicast 117 forwarding through adding a BIER header and removing state in 118 intermediate routers. 120 o BUM: Broadcast, Unknown Unicast, Multicast. Term used to describe 121 the three types of Ethernet modes that will be forwarded to 122 multiple destinations 124 2. Problem Statement 126 The problem is the ability of the network to transport BUM packets, 127 with BIER headers, in an IPv6 environment. In an IPv6 network, many 128 deployments consider using a non-MPLS encapsulation for unicast as 129 the data-plane. In such case, it may be expected to have a BIER IPv6 130 encapsulation which is compliant with various kinds of physical 131 links, perhaps in a hop-by-hop manner, and maintain the benefit of 132 "fast reroute" of an IPv6 tunnel. Evaluating the BIER IPv6 133 requirements will help determine the best solutions to address these 134 problems. 136 3. BIER IPv6 Scenario's 137 +--------------------------------------------+ 138 | | 139 | +------+ 140 | | BFER | 141 +------+ IPv6 +------+ 142 | BFIR | | 143 +------+ Network +------+ 144 | | BFER | 145 | +------+ 146 | | 147 +--------------------------------------------+ 149 This basic scenario depicts the need to replicate bier packets from a 150 BFIR to BFERs across an IPv6 core. The IPv6 environment may include 151 a variety of link types, may be entirely IPv6, may be dual stack or 152 any type of combination which includes IPv6. Regardless of the 153 environment, there are times when a BIER header, including the BIER 154 bitstring used to determine the set of BIER forwarding egress 155 routers, will need to traverse a IPv6 domain. The ways in which BIER 156 will function in an IPv6 environment is the problem that needs to be 157 solved. [RFC8354] lists some good IPv6 related use cases which we 158 will similarly reference in this document. 160 3.1. BIERv6 for Access Network 162 Access networks deliver a variety of types of multicast video traffic 163 from the service provider's network to the home (or Enterprise) 164 environment and from the home towards the service provider's network. 166 There will be a need to send traffic from the IPv4 access towards the 167 service provider's IPv6 network and vice versa. A packet could be 168 mapped into a providers IPv6 network through the use of a BIERv6 169 header. The access devices would not need to know specific details 170 about the packet to perform this mapping; instead the access device 171 would only need to know how to process a BIER header unless there is 172 end to end IPv6. 174 3.2. BIERv6 for Data Center 176 Some Data Center operators are transitioning their Data Center 177 infrastructure from IPv4 to native IPv6 only, in order to cope with 178 IPv4 address depletion and to achieve larger scale. In such 179 environment, BIERv6, can be used to natively steer multicast data 180 across an IPv6 data center. 182 3.3. BIERv6 for Core Networks 184 While the overall amount of traffic offered to the network continues 185 to grow and considering that multiple types of traffic with different 186 characteristics and requirements are quickly converging over single 187 network architecture, the network operators are starting to face new 188 challenges. 190 Some operators are currently building, or plan to build in the near 191 future, an IPv6 only native infrastructure for their core network. 192 Having a native BIERv6 infrastructure will help maintain simplicity 193 of the network and reduce state versus traditional IP Multicast. 195 3.4. Implications for BIER in SRv6 197 The Source Packet Routing in Networking (SPRING) architecture 198 describes how Segment Routing can be used to steer packets through an 199 IPv6 or MPLS network using the source routing paradigm. [RFC8354] 200 focuses on use cases for Segment Routing in an IPv6 only environment, 201 something which is equially important for BIER in an IPv6 only 202 environment. 204 4. Requirements 206 There have been several suggested requirements, on the BIER email 207 list, which we will use to form the BIER IPv6 requirements and to 208 help evaluate the proposed solutions: 210 4.1. L2 Agnostic 212 The solution should be agnostic to the underlying L2 data link type. 214 4.2. Hop by hop DA modification 216 The solution should not require hop-by-hop modification of the IP 217 destination address field. 219 4.3. L4 Inspection 221 The solution should not require the BFRs to inspect layer 4 or 222 require any changes to layer 4. 224 4.4. Multicast address in SA field 226 The solution should not allow a multicast address to be put in the IP 227 source address field. 229 4.5. Incorrect bits 231 The solution should not assume that bits never get set incorrectly. 233 4.6. SA filtering 235 The solution should not require changes in source address filtering 236 procedures. 238 4.7. BIER architecture support 240 The solution should be possible to be used to support the entire BIER 241 architecture. 243 4.8. Keep it simple 245 The solution should avoid having to use different encapsulation 246 types, or use complex tunneling techniques, to support BIER as a E2E 247 multicast transport. 249 4.9. Hardware fast path 251 The solution should enable the processing and forwarding of BIER 252 packets in hardware fast path. 254 5. Solutions Evaluation 256 The following are solutions that have been proposed to solve BIER in 257 IPv6 environments. 259 As illustrated in these examples, the BIER header, or the BitString, 260 may appear in the IPv6 Header, IPv6 Extension Header, IPv6 Payload, 261 or IPv6 Tunnel Packet: 263 5.1. BIER-ETH encapsulation in IPv6 networks 265 +---------------+-----------------+------------------- 266 | Ethernet | BIER header | payload 267 | (ethType = | (BIFT-id, ...) | 268 | 0xAB37) | | 269 | | Next Header | 270 +---------------+-----------------+------------------- 272 BIER-ETH encapsulation (BIER header for Non-MPLS networks as defined 273 in [RFC8296]) can be used to transport the multicast data in the IPv6 274 network by encapsulating the multicast user data payload within the 275 BIER-ETH header. However, using BIER-ETH in IPv6 networks is not 276 considered to be a native IPv6 solution which utilizes the IPv6 277 header to forward the packet. Below listed are some of the 278 properties of BIER-ETH encapsulation which could be seen as the 279 reasons for the same, 281 o BIER-ETH is not agnostic to the underlying (L2) data link type. 282 It can be deployed only in the networks with Ethernet data link 283 and cannot be deployed in an network which deploys any other data 284 link types. Use of BIER-ETH in IPv6 networks might also result in 285 using different BIER encapsulations, when BIER is used as a E2E 286 multicast transport across a larger heterogeneous IPv6 networks 287 with different data link types used in different layers of the 288 network. 290 o BIER-ETH in IPv6 networks is considered similar to 6PE solution 291 where-in the multicast user data packet is encapsulated with-in 292 the BIER-MPLS header. 294 * It is worth noting that the only major difference between BIER- 295 MPLS and BIER-Non-MPLS header is that BIER-MPLS uses downstream 296 assigned MPLS label while BIER-Non-MPLS header uses a domain- 297 wide-unique BIFT-id. While the use of domain-wide-unique BIFT- 298 id in BIER-ETH header takes away the complexity of allocation 299 and state maintenance from the network, it still requires some 300 sort of ID (similar to label) to identify the application 301 context after the decapsulation of BIER header (example: MVPN 302 VRF Label). Encoding of such an ID/LABEL before encapsulating 303 the multicast user data payload with BIER-ETH header cannot be 304 avoided. 306 * The absence of an IPv6 header, and the optional IPv6 extension 307 headers, deprives BIER of some of the useful cases (ex: Use of 308 IPv6 address for identification of network function or service 309 mapping) that is otherwise possible in native IPv6 310 encapsulation which utilizes a IPv6 header. 312 * Tunneling of BIER packets is one common technique used for FRR, 313 to tunnel over BIER incapable nodes etc. While it is possible 314 for the BIER-ETH encapsulated packet to be further encapsulated 315 within a GRE6 or SRv6, etc tunnel, it might not be possible to 316 parse and decapsulate different types of tunnel headers and 317 forward the BIER packet completely in hardware fast path 318 similar to the label stack processing in BIER-MPLS networks. 319 It would be useful to select an encapsulation which could help 320 in processing the tunnel and BIER header and make the 321 forwarding decision completely in hardware fast path, which is 322 lacking in BIER-ETH encapsulation if chosen to be deployed in 323 pure IPv6 networks. 325 5.2. Encode Bitstring in IPv6 destination address 327 +---------------+------------------- 328 | IPv6 header | payload 329 | (BitString in | 330 | DA lower bits)| 331 | Next Header | 332 +---------------+------------------- 334 As described in [I-D.pfister-bier-over-ipv6], The information 335 required by BIER is stored in the destination IPv6 address. The BIER 336 BitString is encoded in the low-order bits of the IPv6 destination 337 address of each packet. The high-order bits of the IPv6 destination 338 address are used by intermediate routers for unicast forwarding, 339 deciding whether a packet is a BIER packet, and if so, to identify 340 the BIER Sub-Domain, Set Identifier and BitString length. No 341 additional extension or encapsulation header is required. Instead of 342 encapsulating the packet in IPv6, the payload is attached to the BIER 343 IPv6 header and the IPv6 protocol number is set to the type of the 344 payload. If the payload is UDP, the UDP checksum needs to change 345 when the BitString in the IPv6 destination address changes. 347 5.3. Add BIER header into IPv6 Extension Header 349 +---------------+-----------------+------------------- 350 | IPv6 header | IPv6 Ext header | payload 351 |(Multicast DA) | (BIER header in | 352 | | TLV Type = X) | 353 | Next Header | Next Header | 354 +---------------+-----------------+------------------- 356 According to [RFC8200] In IPv6, optional internet-layer information 357 is encoded in separate headers that may be placed between the IPv6 358 header and the upper- layer header in a packet. There is a small 359 number of such extension headers, each one identified by a distinct 360 Next Header value. An IPv6 packet may carry zero, one, or more 361 extension headers, each identified by the Next Header field of the 362 preceding header. Extension headers (except for the Hop-by-Hop 363 Options header) are not processed, inserted, or deleted by any node 364 along a packet's delivery path, until the packet reaches the node (or 365 each of the set of nodes, in the case of multicast) identified in the 366 Destination Address field of the IPv6 header. The Hop-by-Hop Options 367 header is not inserted or deleted, but may be examined or processed 368 by any node along a packet's delivery path, until the packet reaches 369 the node (or each of the set of nodes, in the case of multicast) 370 identified in the Destination Address field of the IPv6 header. The 371 Hop-by-Hop Options header, when present, must immediately follow the 372 IPv6 header. Its presence is indicated by the value zero in the Next 373 Header field of the IPv6 header. 375 Two of the currently-defined extension headers are the Hop-by-Hop 376 Options header and the Destination Options header which carry a 377 variable number of type-length-value (TLV) encoded "options". 379 In [I-D.xie-bier-ipv6-encapsulation] an IPv6 BIER Destination Option 380 is carried by the IPv6 Destination Option Header (indicated by a Next 381 Header value 60). It is initialized in a packet sent by an IPv6 BFIR 382 router to inform the following BFR routers in an IPv6 BIER domain to 383 replicate to destination BFER routers hop-by-hop. BIER is generally 384 a hop-by-hop and one-to-many architecture and it is required for a 385 BIER IPv6 encapsulation to include the BIER Header ([RFC8296]) as an 386 IPv6 Extension Header, to pilot the hop-by-hop BIER replication. 388 Hop by hop Options Headers may be considered. The Hop-by-Hop Options 389 header is used to carry optional information that may be examined and 390 processed by every node along a packet's delivery path. The Hop-by- 391 Hop Options header is identified by a Next Header value of 0 in the 392 IPv6 header. 394 Defining New Extension Headers and Options may also be considered, if 395 the IPv6 Destination Option Header is not good enough and new 396 extension headers can solve the problem better. 398 Such proposals may include requests to IANA to allocate a "BIER 399 Option" code from "Destination Options and Hop-by-Hop Options", and/ 400 or a "BIER Option Header" code from "IPv6 Extension Header Types". 402 5.4. Transport BIER as IPv6 payload 404 +---------------+-----------------+------------------- 405 | IPv6 header | IPv6 Ext header | BIER Hdr + payload 406 | | (optional) | as IPv6 payload 407 | | | 408 | Next Header | Next Header = X | 409 +---------------+-----------------+------------------- 411 There is a proposal for a transport-independent BIER encapsulation 412 header which is applicable regardless of the underlying transport 413 technology. As described in [I-D.xu-bier-encapsulation] and 414 [I-D.zhang-bier-bierin6], the BIER header, and the payload following 415 it, can be combined as an IPv6 payload, and be indicated by a new 416 Upper-layer IPv6 Next-Header value. A unicast IPv6 destination 417 address is used for the replication and changes when replicating a 418 packet out to a neighbor. 420 Such proposals may include a request to IANA to allocate an IPv6 421 Next-Header code from "Assigned Internet Protocol Numbers". 423 5.5. Tunneling BIER in a IPv6 tunnel 425 +---------------+-----------------+------------+---------------- 426 | IPv6 header | IPv6 Ext header | GRE header | 427 | | (optional) | | BIER Hdr + 428 | | | | payload as GRE 429 | Next Header | Next Header | Proto = X | Payload 430 +---------------+-----------------+------------+---------------- 432 A generic IPv6 Tunnel could be used to encapsulate the bier packet 433 within an IPv6 domain. 435 GRE is a mechanism by which any ethernet payload can be carried by an 436 IP GRE tunnel due to the 16-bits 'Protocol Type' field. Both IPv4 437 and IPv6 can be used to carry GRE. The Ethernet type codepoint 438 0xAB37, defined for BIER, can be used in a GRE header to indicate the 439 subsequent BIER header and payload in an IPv6 network. 441 +---------------+-----------------+------------+---------------- 442 | IPv6 header | IPv6 Ext header | UDP header | 443 | | (optional) | | BIER Hdr + 444 | | | | payload as UDP 445 | Next Header | Next Header | DPort = X | Payload 446 +---------------+-----------------+------------+---------------- 448 UDP-based tunneling is another mechanism which uses a specific UDP 449 port to indicate a UDP payload format. Both IPv4 and IPv6 can 450 support UDP. Such UDP-based tunnels can be used for BIER in a IPv6 451 network by defining a new UDP port to indicate the BIER header and 452 payload. 454 6. IANA Considerations 456 Some BIERv6 encapsulation proposals do not require any action from 457 IANA while other proposals require new BIER Destination Option 458 codepoints from IPv6 sub-registries, new "Next header" values, or 459 require new IP Protocol codes. This document, however, does not 460 require anything from IANA. 462 7. Security Considerations 464 There are no security issues introduced by this draft. 466 8. Acknowledgement 468 Thank you to Eric Rosen for his listed set of requirements on the 469 bier wg list. 471 9. Normative References 473 [I-D.pfister-bier-over-ipv6] 474 Pfister, P. and I. Wijnands, "An IPv6 based BIER 475 Encapsulation and Encoding", draft-pfister-bier-over- 476 ipv6-01 (work in progress), October 2016. 478 [I-D.xie-bier-ipv6-encapsulation] 479 Xie, J., Geng, L., McBride, M., Dhanaraj, S., Yan, G., and 480 Y. Xia, "Encapsulation for BIER in Non-MPLS IPv6 481 Networks", draft-xie-bier-ipv6-encapsulation-00 (work in 482 progress), March 2019. 484 [I-D.xu-bier-encapsulation] 485 Xu, X., somasundaram.s@alcatel-lucent.com, s., Jacquenet, 486 C., Raszuk, R., and Z. Zhang, "A Transport-Independent Bit 487 Index Explicit Replication (BIER) Encapsulation Header", 488 draft-xu-bier-encapsulation-06 (work in progress), 489 September 2016. 491 [I-D.zhang-bier-bierin6] 492 Zhang, Z. and T. Przygienda, "BIER in IPv6", draft-zhang- 493 bier-bierin6-02 (work in progress), October 2018. 495 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 496 Requirement Levels", BCP 14, RFC 2119, 497 DOI 10.17487/RFC2119, March 1997, 498 . 500 [RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in 501 IPv6 Specification", RFC 2473, DOI 10.17487/RFC2473, 502 December 1998, . 504 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 505 (IPv6) Specification", STD 86, RFC 8200, 506 DOI 10.17487/RFC8200, July 2017, 507 . 509 [RFC8279] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A., 510 Przygienda, T., and S. Aldrin, "Multicast Using Bit Index 511 Explicit Replication (BIER)", RFC 8279, 512 DOI 10.17487/RFC8279, November 2017, 513 . 515 [RFC8296] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A., 516 Tantsura, J., Aldrin, S., and I. Meilik, "Encapsulation 517 for Bit Index Explicit Replication (BIER) in MPLS and Non- 518 MPLS Networks", RFC 8296, DOI 10.17487/RFC8296, January 519 2018, . 521 [RFC8354] Brzozowski, J., Leddy, J., Filsfils, C., Maglione, R., 522 Ed., and M. Townsley, "Use Cases for IPv6 Source Packet 523 Routing in Networking (SPRING)", RFC 8354, 524 DOI 10.17487/RFC8354, March 2018, 525 . 527 Authors' Addresses 529 Mike McBride 530 Huawei 532 Email: michael.mcbride@huawei.com 534 Jingrong Xie 535 Huawei 537 Email: xiejingrong@huawei.com 539 Senthil Dhanaraj 540 Huawei 542 Email: senthil.dhanaraj@huawei.com 544 Rajiv Asati 545 Cisco 547 Email: rajiva@cisco.com