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