Internet Engineering Task Force (IETF) M. Zhang
Request for Comments: 8564 Huawei Technologies
Updates: 7175, 7177 S. Pallagatti
Category: Standards Track Vmware
ISSN: 2070-1721 V. Govindan
Cisco Systems
April 2019
Internet Engineering Task Force (IETF) M. Zhang
Request for Comments: 8564 Huawei Technologies
Updates: 7175, 7177 S. Pallagatti
Category: Standards Track Vmware
ISSN: 2070-1721 V. Govindan
Cisco Systems
April 2019
Support of Point-to-Multipoint Bidirectional Forwarding Detection (BFD) in Transparent Interconnection of Lots of Links (TRILL)
在多链路透明互连（TRILL）中支持点对多点双向转发检测（BFD）
Abstract
摘要
Point-to-multipoint (P2MP) Bidirectional Forwarding Detection (BFD) is designed to verify multipoint connectivity. This document specifies the support of P2MP BFD in Transparent Interconnection of Lots of Links (TRILL). Similar to TRILL point-to-point BFD, BFD Control packets in TRILL P2MP BFD are transmitted using RBridge Channel messages. This document updates RFCs 7175 and 7177.
点对多点（P2MP）双向转发检测（BFD）用于验证多点连接。本文件规定了P2MP BFD在大量链路透明互连（TRILL）中的支持。与TRILL点对点BFD类似，TRILL P2MP BFD中的BFD控制包使用RBridge信道消息进行传输。本文件更新了RFCs 7175和7177。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 7841第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8564.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问https://www.rfc-editor.org/info/rfc8564.
Copyright Notice
版权公告
Copyright (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved.
版权（c）2019 IETF信托基金和被确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(https://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Acronyms and Terminology . . . . . . . . . . . . . . . . . . 3
2.1. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . 3
2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
3. Bootstrapping . . . . . . . . . . . . . . . . . . . . . . . . 3
4. A New RBridge Channel Message for P2MP BFD . . . . . . . . . 4
5. Discriminators and Packet Demultiplexing . . . . . . . . . . 4
6. Tracking Active Tails . . . . . . . . . . . . . . . . . . . . 5
7. Security Considerations . . . . . . . . . . . . . . . . . . . 5
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 6
9.1. Normative References . . . . . . . . . . . . . . . . . . 6
9.2. Informative References . . . . . . . . . . . . . . . . . 7
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 7
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Acronyms and Terminology . . . . . . . . . . . . . . . . . . 3
2.1. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . 3
2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
3. Bootstrapping . . . . . . . . . . . . . . . . . . . . . . . . 3
4. A New RBridge Channel Message for P2MP BFD . . . . . . . . . 4
5. Discriminators and Packet Demultiplexing . . . . . . . . . . 4
6. Tracking Active Tails . . . . . . . . . . . . . . . . . . . . 5
7. Security Considerations . . . . . . . . . . . . . . . . . . . 5
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 6
9.1. Normative References . . . . . . . . . . . . . . . . . . 6
9.2. Informative References . . . . . . . . . . . . . . . . . 7
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 7
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8
TRILL supports multicast forwarding. Applications based on TRILL multicast may need quick detection of multicast failures using P2MP BFD [RFC8562]. This document specifies TRILL support of P2MP BFD.
TRILL支持多播转发。基于TRILL多播的应用程序可能需要使用P2MP BFD[RFC8562]快速检测多播故障。本文件规定了P2MP BFD的颤音支持。
To use P2MP BFD, the head end needs to periodically transmit BFD Control packets to all tails using TRILL multicast. A new RBridge Channel message is allocated for this purpose.
要使用P2MP BFD，前端需要使用TRILL多播定期向所有尾部发送BFD控制数据包。为此目的，分配了一个新的RBridge通道消息。
In order to execute the global protection of distribution used for multicast forwarding [TRILL-TREES], the head needs to track the active status of tails [RFC8563]. If the tail loses connectivity as detected by not receiving the new RBridge Channel message from the head, the tail should notify the head of the lack of multipoint
为了执行用于多播转发的分发的全局保护[TRILL-TREES]，头部需要跟踪尾部的活动状态[RFC8563]。如果尾部因未接收到来自头部的新RBridge通道消息而失去连接，则尾部应通知头部缺少多点
connectivity with unicast BFD Control packets. These unicast BFD Control packets are transmitted using the existing RBridge Channel message assigned to BFD Control [RFC7175].
与单播BFD控制数据包的连接。这些单播BFD控制包使用分配给BFD控制[RFC7175]的现有RBridge信道消息进行传输。
This document updates [RFC7177] as specified in Section 3 and updates [RFC7175] as specified in Sections 4 and 5.
本文件按照第3节的规定更新[RFC7177]，并按照第4节和第5节的规定更新[RFC7175]。
Data Label: VLAN or Fine-Grained Label [RFC7172].
数据标签：VLAN或细粒度标签[RFC7172]。
BFD: Bidirectional Forwarding Detection
双向转发检测
P2MP: Point to Multipoint
P2MP：点对多点
TRILL: Transparent Interconnection of Lots of Links or Tunneled Routing in the Link Layer
TRILL：大量链路的透明互连或链路层中的隧道路由
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“建议”、“不建议”、“可”和“可选”在所有大写字母出现时（如图所示）应按照BCP 14[RFC2119][RFC8174]所述进行解释。
Familiarity with [RFC6325], [RFC7175], and [RFC7178] is assumed in this document.
本文件假定熟悉[RFC6325]、[RFC7175]和[RFC7178]。
The TRILL adjacency mechanism bootstraps the establishment of one-hop TRILL BFD sessions [RFC7177]. Multi-hop sessions are expected to be configured by the network manager. A slight wording update to the second sentence in Section 6 of [RFC7177] is required.
颤音邻接机制引导一跳颤音BFD会话的建立[RFC7177]。多跳会话预期由网络管理器配置。需要对[RFC7177]第6节中的第二句进行轻微的措辞更新。
It currently reads:
目前案文如下：
If an RBridge supports BFD [RFC7175], it will have learned whether the other RBridge has BFD enabled by whether or not a BFD-Enabled TLV [RFC6213] was included in its Hellos.
如果一个RBridge支持BFD[RFC7175]，它将通过其hello中是否包含启用BFD的TLV[RFC6213]来了解另一个RBridge是否启用了BFD。
Now it should read:
现在应该是：
If an RBridge supports BFD (see [RFC7175] and [RFC8564]), it will have learned whether the other RBridge has BFD enabled by whether or not a BFD-Enabled TLV [RFC6213] was included in its Hellos.
如果一个RBridge支持BFD（请参见[RFC7175]和[RFC8564]），它将通过其hello中是否包含启用BFD的TLV[RFC6213]来了解另一个RBridge是否启用了BFD。
In addition, a normative reference to this document is added to RFC 7177 as a result of this update.
此外，由于本次更新，RFC 7177中增加了本文件的规范性参考。
RBridge Channel protocol number 0x002 is defined for TRILL point-to-point BFD Control packets in [RFC7175]. That RFC states that if the M bit of the TRILL Header of the RBridge Channel packet containing a BFD Control packet is nonzero, the packet is generally dropped. In P2MP BFD, the head is required to probe tails using multicast. This means the M bit will be set to 1. For this reason, a new RBridge Channel message (P2MP BFD Control), whose protocol code point is 0x007, is specified in this document. An RBridge that supports P2MP BFD MUST support the new RBridge Channel message for P2MP BFD. The capability to support the RBridge Channel message for P2MP BFD, and therefore support performing P2MP BFD, is announced within the RBridge Channel Protocols sub-TLV in Link State PDUs (LSPs) [RFC7176].
RBridge信道协议号0x002是为[RFC7175]中的TRILL点到点BFD控制数据包定义的。该RFC声明，如果包含BFD控制分组的RBridge信道分组的TRILL报头的M位为非零，则该分组通常被丢弃。在P2MP BFD中，头部需要使用多播探测尾部。这意味着M位将被设置为1。因此，本文档中指定了一个新的RBridge通道消息（P2MP BFD Control），其协议代码点为0x007。支持P2MP BFD的RBridge必须支持P2MP BFD的新RBridge通道消息。在链路状态PDU（LSP）下的RBRIGE信道协议子TLV中宣布了支持P2MP BFD的RBRIGE信道消息的能力，从而支持执行P2MP BFD[RFC7176]。
As specified in [RFC7178], when the tail receives TRILL Data packets sent as BFD RBridge Channel messages, it will absorb the packets itself rather than deliver these packets to its attached end stations.
如[RFC7178]所述，当tail接收到作为BFD RBridge信道消息发送的TRILL数据包时，它将吸收数据包本身，而不是将这些数据包发送到其连接的终端站。
The processing in Section 3.2 of [RFC7175] generally applies except that the test on the M bit in the TRILL Header is reversed. If the M bit is zero, the packet MUST be discarded. If the M bit is one, it is processed.
[RFC7175]第3.2节中的处理通常适用，但TRILL报头中M位的测试是反向的。如果M位为零，则必须丢弃数据包。如果M位为1，则对其进行处理。
After the processing per Section 3.2 of [RFC7175], the tail demultiplexes incoming BFD packets based on a combination of the source address and My Discriminator as specified in [RFC8562]. In addition to this combination, TRILL P2MP BFD requires that the tail use the Data Label, which is either the inner VLAN or the Fine-Grained Label [RFC7172], for demultiplexing. If the tail needs to notify the head about the failure of a multipath, the tail is required to send unicast BFD Control packets using the same Data Label as used by the head.
按照[RFC7175]第3.2节进行处理后，tail根据[RFC8562]中规定的源地址和我的鉴别器的组合，对传入的BFD数据包进行解复用。除此之外，TRILL P2MP BFD还要求尾部使用数据标签，即内部VLAN或细粒度标签[RFC7172]进行解复用。如果尾部需要通知头部多径故障，则尾部需要使用头部使用的相同数据标签发送单播BFD控制数据包。
According to [RFC8562], the head has a session of type MultipointHead that is bound to a multipoint path. Multipoint BFD Control packets are sent by this session over the multipoint path, and no BFD Control packets are received by it. Each tail dynamically creates a MultipointTail per a multipoint path. MultipointTail sessions receive BFD Control packets from the head over multipoint paths.
根据[RFC8562]，头部具有绑定到多点路径的MultipointHead类型的会话。此会话通过多点路径发送多点BFD控制数据包，但未接收任何BFD控制数据包。每个尾部在每个多点路径上动态创建一个多点尾部。多点尾会话通过多点路径从头部接收BFD控制数据包。
An example use is when a multicast tree root needs to keep track of all the receivers as in [TRILL-TREES]; this can be done by maintaining a session of type MultipointClient per receiver that is of interest, as described in [RFC8563]. See [RFC8563] for detailed operations of tracking active tails.
例如，当一个多播树根需要像在[TRILL-TREES]中一样跟踪所有接收器时；如[RFC8563]所述，这可以通过为每个感兴趣的接收器维护MultipointClient类型的会话来实现。有关跟踪活动尾翼的详细操作，请参见[RFC8563]。
Multipoint BFD provides its own authentication but does not provide encryption (see the Security Considerations in [RFC8562]). As specified in this document, the point-to-multipoint BFD payloads are encapsulated in RBridge Channel messages that have been extended by [RFC7978] to provide security. [RFC7978] provides encryption only for point-to-point extended RBridge Channel messages, so its encryption facilities are not applicable to this document. However, [RFC7978] provides stronger authentication than that currently provided in BFD. Thus, there is little reason to use the BFD security mechanisms if authentication per [RFC7978] is in use. It is expected that a future TRILL document will provide for group keying; when that occurs, the use of RBridge Channel security [RFC7978] will be able to provide both encryption and authentication.
多点BFD提供自己的身份验证，但不提供加密（请参阅[RFC8562]中的安全注意事项）。如本文件所述，点对多点BFD有效载荷封装在RBridge通道消息中，该消息已由[RFC7978]扩展以提供安全性。[RFC7978]仅为点对点扩展RBridge通道消息提供加密，因此其加密功能不适用于本文档。但是，[RFC7978]提供了比BFD中当前提供的更强的身份验证。因此，如果按照[RFC7978]进行身份验证，则几乎没有理由使用BFD安全机制。预计未来的TRILL文档将提供组键控；当这种情况发生时，使用RBridge通道安全[RFC7978]将能够提供加密和身份验证。
For general multipoint BFD security considerations, see [RFC8562].
有关一般多点BFD安全注意事项，请参阅[RFC8562]。
For general RBridge Channel security considerations, see [RFC7178].
有关一般RBridge通道安全注意事项，请参阅[RFC7178]。
IANA has allocated the following from the Standards Action [RFC8126] range of the "RBridge Channel Protocols" registry, which is part of the "Transparent Interconnection of Lots of Links (TRILL) Parameters" registry.
IANA已从“RBridge Channel Protocols”注册表的标准行动[RFC8126]范围中分配了以下内容，该注册表是“大量链路透明互连（TRILL）参数”注册表的一部分。
Protocol Number
---------------- ------
P2MP BFD Control 0x007
Protocol Number
---------------- ------
P2MP BFD Control 0x007
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，DOI 10.17487/RFC2119，1997年3月<https://www.rfc-editor.org/info/rfc2119>.
[RFC6325] Perlman, R., Eastlake 3rd, D., Dutt, D., Gai, S., and A. Ghanwani, "Routing Bridges (RBridges): Base Protocol Specification", RFC 6325, DOI 10.17487/RFC6325, July 2011, <https://www.rfc-editor.org/info/rfc6325>.
[RFC6325]Perlman，R.，Eastlake 3rd，D.，Dutt，D.，Gai，S.，和A.Ghanwani，“路由桥（RBridges）：基本协议规范”，RFC 6325DOI 10.17487/RFC6325，2011年7月<https://www.rfc-editor.org/info/rfc6325>.
[RFC7172] Eastlake 3rd, D., Zhang, M., Agarwal, P., Perlman, R., and D. Dutt, "Transparent Interconnection of Lots of Links (TRILL): Fine-Grained Labeling", RFC 7172, DOI 10.17487/RFC7172, May 2014, <https://www.rfc-editor.org/info/rfc7172>.
[RFC7172]Eastlake 3rd，D.，Zhang，M.，Agarwal，P.，Perlman，R.，和D.Dutt，“大量链接的透明互连（TRILL）：细粒度标记”，RFC 7172，DOI 10.17487/RFC7172，2014年5月<https://www.rfc-editor.org/info/rfc7172>.
[RFC7175] Manral, V., Eastlake 3rd, D., Ward, D., and A. Banerjee, "Transparent Interconnection of Lots of Links (TRILL): Bidirectional Forwarding Detection (BFD) Support", RFC 7175, DOI 10.17487/RFC7175, May 2014, <https://www.rfc-editor.org/info/rfc7175>.
[RFC7175]Manral，V.，Eastlake 3rd，D.，Ward，D.，和A.Banerjee，“大量链路的透明互连（TRILL）：双向转发检测（BFD）支持”，RFC 7175，DOI 10.17487/RFC7175，2014年5月<https://www.rfc-editor.org/info/rfc7175>.
[RFC7176] Eastlake 3rd, D., Senevirathne, T., Ghanwani, A., Dutt, D., and A. Banerjee, "Transparent Interconnection of Lots of Links (TRILL) Use of IS-IS", RFC 7176, DOI 10.17487/RFC7176, May 2014, <https://www.rfc-editor.org/info/rfc7176>.
[RFC7176]Eastlake 3rd，D.，Senevirathne，T.，Ghanwani，A.，Dutt，D.，和A.Banerjee，“IS-IS大量链路的透明互连（TRILL）使用”，RFC 7176，DOI 10.17487/RFC7176，2014年5月<https://www.rfc-editor.org/info/rfc7176>.
[RFC7177] Eastlake 3rd, D., Perlman, R., Ghanwani, A., Yang, H., and V. Manral, "Transparent Interconnection of Lots of Links (TRILL): Adjacency", RFC 7177, DOI 10.17487/RFC7177, May 2014, <https://www.rfc-editor.org/info/rfc7177>.
[RFC7177]Eastlake 3rd，D.，Perlman，R.，Ghanwani，A.，Yang，H.，和V.Manral，“大量链路的透明互连（颤音）：邻接”，RFC 7177，DOI 10.17487/RFC7177，2014年5月<https://www.rfc-editor.org/info/rfc7177>.
[RFC7178] Eastlake 3rd, D., Manral, V., Li, Y., Aldrin, S., and D. Ward, "Transparent Interconnection of Lots of Links (TRILL): RBridge Channel Support", RFC 7178, DOI 10.17487/RFC7178, May 2014, <https://www.rfc-editor.org/info/rfc7178>.
[RFC7178]Eastlake 3rd，D.，Manral，V.，Li，Y.，Aldrin，S.，和D.Ward，“大量链路的透明互连（TRILL）：RBridge通道支持”，RFC 7178，DOI 10.17487/RFC7178，2014年5月<https://www.rfc-editor.org/info/rfc7178>.
[RFC7978] Eastlake 3rd, D., Umair, M., and Y. Li, "Transparent Interconnection of Lots of Links (TRILL): RBridge Channel Header Extension", RFC 7978, DOI 10.17487/RFC7978, September 2016, <https://www.rfc-editor.org/info/rfc7978>.
[RFC7978]Eastlake 3rd，D.，Umair，M.，和Y.Li，“大量链路的透明互连（TRILL）：RBridge信道头扩展”，RFC 7978，DOI 10.17487/RFC7978，2016年9月<https://www.rfc-editor.org/info/rfc7978>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8174]Leiba，B.，“RFC 2119关键词中大写与小写的歧义”，BCP 14，RFC 8174，DOI 10.17487/RFC8174，2017年5月<https://www.rfc-editor.org/info/rfc8174>.
[RFC8562] Katz, D., Ward, D., Pallagatti, S., Ed., and G. Mirsky, Ed., "Bidirectional Forwarding Detection (BFD) for Multipoint Networks", RFC 8562, DOI 10.17487/RFC8562, April 2019, <https://www.rfc-editor.org/info/rfc8562>.
[RFC8562]Katz，D.，Ward，D.，Pallagatti，S.，Ed.，和G.Mirsky，Ed.，“多点网络的双向转发检测（BFD）”，RFC 8562，DOI 10.17487/RFC8562，2019年4月<https://www.rfc-editor.org/info/rfc8562>.
[RFC8563] Katz, D., Ward, D., Pallagatti, S., Ed., and G. Mirsky, Ed., "Bidirectional Forwarding Detection (BFD) Multipoint Active Tails", RFC 8563, DOI 10.17487/RFC8563, April 2019, <https://www.rfc-editor.org/info/rfc8563>.
[RFC8563]Katz，D.，Ward，D.，Pallagatti，S.，Ed.，和G.Mirsky，Ed.，“双向转发检测（BFD）多点活动尾”，RFC 8563，DOI 10.17487/RFC8563，2019年4月<https://www.rfc-editor.org/info/rfc8563>.
[RFC6213] Hopps, C. and L. Ginsberg, "IS-IS BFD-Enabled TLV", RFC 6213, DOI 10.17487/RFC6213, April 2011, <https://www.rfc-editor.org/info/rfc6213>.
[RFC6213]Hopps，C.和L.Ginsberg，“IS-IS BFD启用TLV”，RFC 6213，DOI 10.17487/RFC6213，2011年4月<https://www.rfc-editor.org/info/rfc6213>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, <https://www.rfc-editor.org/info/rfc8126>.
[RFC8126]Cotton，M.，Leiba，B.，和T.Narten，“在RFC中编写IANA考虑事项部分的指南”，BCP 26，RFC 8126，DOI 10.17487/RFC8126，2017年6月<https://www.rfc-editor.org/info/rfc8126>.
[TRILL-TREES] Zhang, M., Senevirathne, T., Pathangi, J., Banerjee, A., and A. Ghanwani, "TRILL: Resilient Distribution Trees", Work in Progress, draft-ietf-trill-resilient-trees-09, January 2018.
[TRILL-TREES]Zhang，M.，Senevirathne，T.，Pathangi，J.，Banerjee，A.，和A.Ghanwani，“TRILL:弹性分布树”，正在进行的工作，草案-ietf-TRILL-Resilience-TREES-092018年1月。
Acknowledgements
致谢
The authors would like to thank Gayle Noble and Donald Eastlake 3rd for their comments and suggestions.
作者要感谢Gayle Noble和Donald Eastlake 3rd的评论和建议。
Authors' Addresses
作者地址
Mingui Zhang Huawei Technologies No.156 Beiqing Rd. Haidian District Beijing 100095 China
中国北京市海淀区北青路156号华为技术有限公司张明贵100095
Email: zhangmingui@huawei.com
Email: zhangmingui@huawei.com
Santosh Pallagatti Vmware
桑托什·帕拉加蒂酒店
Email: santosh.pallagatti@gmail.com
Email: santosh.pallagatti@gmail.com
Vengada Prasad Govindan Cisco Systems
Vengada Prasad Govindan思科系统公司
Email: venggovi@cisco.com
Email: venggovi@cisco.com