idnits 2.17.00 (12 Aug 2021) /tmp/idnits46041/draft-yizhou-trill-traceable-oam-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 : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC7455]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: A new flag 'T' is defined in TRILL OAM message header [RFC7455] as an indicator for traceable message in figure 2. T flag is applicable to Path Trace Message (PTM) and Multi-Destination Tree Verification Message (MTVM). Loopback message and Continuity Check Message SHOULD not set T flag to 1. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: The originator RBridge SHOULD not expect the replies for the Path Trace Message with Traceable Flag set it sent. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: - RBridge Scope TLV - Tree Trace Mode TLV: When RBridge Scope TLV is present, E flag of this TLV SHOULD not be set to 1. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: The originator RBridge SHOULD not expect the replies for the Multicast Tree Verification Message with Traceable Flag it sent. -- The document date (July 6, 2015) is 2504 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: 'Openflow' is mentioned on line 150, but not defined == Missing Reference: 'RFC2119' is mentioned on line 182, but not defined == Unused Reference: 'RFC6439' is defined on line 468, but no explicit reference was found in the text == Unused Reference: 'RFC6905' is defined on line 471, but no explicit reference was found in the text == Unused Reference: 'RFC7180' is defined on line 485, but no explicit reference was found in the text == Unused Reference: 'OpenFlow' is defined on line 497, but no explicit reference was found in the text ** Obsolete normative reference: RFC 6439 (Obsoleted by RFC 8139) ** Downref: Normative reference to an Informational RFC: RFC 6905 ** Downref: Normative reference to an Informational RFC: RFC 7174 ** Obsolete normative reference: RFC 7180 (Obsoleted by RFC 7780) Summary: 5 errors (**), 0 flaws (~~), 11 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 TRILL Working Group Y. Li 3 INTERNET-DRAFT D. Eastlake 4 Intended Status: Standard Track H. Chen 5 Huawei Technologies 6 D. Kumar 7 Cisco 8 S. Gupta 9 IP Infusion 10 Expires: January 6, 2016 July 6, 2015 12 TRILL: Traceable OAM 13 draft-yizhou-trill-traceable-oam-00 15 Abstract 17 TRILL fault management [RFC7455] specifies the messages and 18 operations for OAM in TRILL network. The sender collects the replies 19 for the OAM-relevant request it sent and uses the replies as the 20 indication of the network faults. In certain circumstances the sender 21 needs to collect multiple replies to isolate the fault, e.g. 22 repetitively sending Path Trace Messages (PTM) with increasing value 23 of hop count and collecting the replies on them to figure out the 24 fault point of certain path. 26 With the increasing deployment of Software Defined Network (SDN), a 27 centralized management server can be used to help with fault 28 management. The server then is responsible to collect OAM messages 29 and analyze them to either isolate the network fault or compile 30 overall OAM information. It naturally uses SDN structure to alleviate 31 the effort of the requester node and provide a centralized solution 32 to produce the operation and management feedback of the network. 34 This document specifies the extensions of TRILL OAM message and the 35 operations about the network nodes and the centralized management 36 server to trace and collect OAM relevant messages for further 37 analysis. 39 Status of this Memo 41 This Internet-Draft is submitted to IETF in full conformance with the 42 provisions of BCP 78 and BCP 79. 44 Internet-Drafts are working documents of the Internet Engineering 45 Task Force (IETF), its areas, and its working groups. Note that 46 other groups may also distribute working documents as 47 Internet-Drafts. 49 Internet-Drafts are draft documents valid for a maximum of six months 50 and may be updated, replaced, or obsoleted by other documents at any 51 time. It is inappropriate to use Internet-Drafts as reference 52 material or to cite them other than as "work in progress." 54 The list of current Internet-Drafts can be accessed at 55 http://www.ietf.org/1id-abstracts.html 57 The list of Internet-Draft Shadow Directories can be accessed at 58 http://www.ietf.org/shadow.html 60 Copyright and License Notice 62 Copyright (c) 2015 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 . . . . . . . . . . . . . . . . . . . . . . . . . 4 78 2. Terminology Used in This Document . . . . . . . . . . . . . . . 5 79 3. Traceable Flag . . . . . . . . . . . . . . . . . . . . . . . . 5 80 4. Operation Theory . . . . . . . . . . . . . . . . . . . . . . . 6 81 4.1 Path Trace Message (PTM) with Traceable Flag . . . . . . . . 6 82 4.1.1 Actions by Originator RBridge . . . . . . . . . . . . . 7 83 4.1.2 Intermediate RBridge . . . . . . . . . . . . . . . . . . 8 84 4.1.3 Destination RBridge . . . . . . . . . . . . . . . . . . 8 85 4.1.4 Centralized Management Server . . . . . . . . . . . . . 8 86 4.2 Multi-Destination Tree Verification Message (MTVM) with 87 Traceable Flag . . . . . . . . . . . . . . . . . . . . . . . 8 88 4.2.1 Actions by Originator RBridge . . . . . . . . . . . . . 9 89 4.2.2 Receiving RBridge . . . . . . . . . . . . . . . . . . . 10 90 4.2.3 In-Scope RBridges . . . . . . . . . . . . . . . . . . . 10 91 4.2.4 Centralized Management Server . . . . . . . . . . . . . 11 93 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 11 94 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 11 95 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 96 7.1 Normative References . . . . . . . . . . . . . . . . . . . 11 97 7.2 Informative References . . . . . . . . . . . . . . . . . . 12 98 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 12 99 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 101 1. Introduction 103 TRILL fault management [RFC7455] specifies OAM messages, TLVs and 104 operations for fault detection and isolation in TRILL network. 105 Requester collects the replies of the OAM requests it sent and tries 106 to analyze the potential faults from them. For path tracing, the 107 sending RBridge utilizes a Hop Count Expiry approach [RFC7455] which 108 is similar as IP trace-route. The sending RBridge sends multiple 109 requests in sequence with incrementing value of Hop Count field and 110 collects the returning responses to construct the path and isolate 111 the fault. 113 With the deployment of centralized management server in TRILL 114 network, new requirements and approaches for fault isolation and path 115 tracing are emerging. Figure 1 shows a TRILL network with a 116 centralized management server. 118 +----------+ 119 |management| 120 ************|server |*********** 121 * +----------+ * 122 * * * 123 * * * 124 * * * 125 * * * 126 * __*_ _ * 127 * --.--/ * \./ \._ * 128 * ./ * \. * 129 * .-- *********** \__ * 130 * / * * \ * 131 +-----+ +---+ +---+ +-----+ 132 | RB1 |----|RB3|-----|RB4|-------| RB2 | 133 +-----+ +---+ +---+ +-----+ 134 | \._ ./ | 135 | \.__ Trill Network ._/ | 136 | \. / | 137 +-----+ \../ \.--/''-' +-----+ 138 |host1| |host2| 139 +-----+ +-----+ 141 Figure 1. TRILL network with a centralized management server 143 The centralized management server is capable to construct the OAM 144 messages of a specified flow and feed them into an ingress RBridge, 145 say RB1. When the message is delivered to the egress RBridge RB2, the 146 intermediate RBridges RB3 and RB4 are able to replicate the messages 147 to the management server. The server is responsible to do all the 148 analysis to trace the path and isolate the fault. Such approach is 149 easily deployable in a network with a controller. For instance, if 150 the management server is an Openflow [Openflow] controller, RBridges 151 may use Packet-in message to send the packets to the Openflow 152 controller and the controller may use Packet-out message to feed the 153 constructed OAM messages into the ingress RB at the beginning. 155 The document defines the flags and TLVs to help the RBridges to 156 identify the received OAM messages destined for a centralized 157 management server and provides the server with sufficient information 158 for further analysis. 160 2. Terminology Used in This Document 162 This document uses the terminology from [RFC6325], [RFC7174] and 163 [RFC7455]. Some additional terms listed below: 165 campus: Name for a TRILL network, like "bridged LAN" is a name for a 166 bridged network. It does not have any academic implication. 168 Data Label: VLAN or FGL. 170 ECMP: Equal Cost Multi-Path [RFC6325]. 172 FGL: Fine Grained Label [RFC7172]. 174 RBridge: An alternative name for a TRILL switch. 176 TRILL switch: A device implementing the TRILL protocol. Sometimes 177 called an RBridge. 179 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 180 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 181 document are to be interpreted as described in RFC-2119 [RFC2119]. 183 3. Traceable Flag 185 A new flag 'T' is defined in TRILL OAM message header [RFC7455] as an 186 indicator for traceable message in figure 2. T flag is applicable to 187 Path Trace Message (PTM) and Multi-Destination Tree Verification 188 Message (MTVM). Loopback message and Continuity Check Message SHOULD 189 not set T flag to 1. 191 1 2 3 192 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 193 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 194 |MD-L | Version | OpCode | Flags |T|FirstTLVOffset | 195 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 196 | | 197 . OpCode-Specific Information . 198 | | 199 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 200 | | 201 . TLVs . 202 | | 203 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 205 Figure 2. T Flag in TRILL OAM Message Header 207 o T (1 bit): Traceable flag. When set, indicates no response 208 should be sent back to the requester and the entire TRILL frame 209 should be sent to a centralized management server for tracing. 211 Basically the traceable flag implies three functions in the trill 212 campus: 214 1. To indicate the intermediate RBs to capture the frames and 215 replicate it to CPU. 217 2. To guide the intermediate RB to perform certain operations which 218 may be different from the traditional OAM operations. For example, as 219 we can use packet-in to send the whole packet to openflow controller, 220 it is not necessary to add Original Data Payload TLV to the packet. 222 3. To make sure the sender will not expect any response and turn off 223 certain mechanisms like time out. 225 4. Operation Theory 227 OAM message with Traceable flag is most useful in functionalities 228 requiring tracing, e.g., trace route like behaviors. 230 4.1 Path Trace Message (PTM) with Traceable Flag 232 TRILL fault management [RFC7455] adopts an IP trace-route like 233 approach which relies on the hop count expiry to send the PTM message 234 to RBridge for further handling. The sender needs to repetitively 235 send the requests with increasing value of hop count. With traceable 236 flag on, the centralized management server may collect the replicated 237 frame along the path and check the hop count value in TRILL header 238 directly. By sorting the hop count value decreasingly, it is easy to 239 plot the path taken for a specific flow or figure out the break point 240 for fault isolation. 242 As a centralized management server normally has more memory space 243 than an RBridge, the server may choose to record the flow entropy to 244 path mapping information. When a fault is suspected between two 245 RBridges, the sever may optimally choose minimum number of flow 246 entropies from the records it saved to feed into the ingress RBridge 247 to spread over the paths. 249 4.1.1 Actions by Originator RBridge 251 The originator RBridge takes the following actions: 253 o Identifies the destination RBridge based on user specification 254 or based on location of the specified destination MAC address. 256 o Constructs the Flow Entropy based on user-specified parameters 257 or implementation-specific default parameters. 259 o Specifies the Hop Count of the TRILL Data frame to be larger 260 than the expected number of hops. 262 o Constructs the TRILL OAM header: set the OpCode to Path Trace 263 Message type (65). Assign an applicable Session Identification 264 number for the request. Return Code and Return Sub-code MUST be 265 set to zero. Set Traceable flags to 1. 267 o Includes the following OAM TLVs, where applicable: 269 - Out-of-Band Reply Address TLV: When Traceable flag is set, 270 Out-of-Band Reply Address TLV needs to be set to the address 271 that the traced message should be sent. It is normally the IP 272 address of the centralized management server. This address may 273 be absent if the default centralized management server address 274 has been configured on every RBridge. 276 - Diagnostic Label TLV 278 - Sender ID TLV 280 o Dispatches the OAM frame to the TRILL data plane for 281 transmission. 283 The originator RBridge SHOULD not expect the replies for the Path 284 Trace Message with Traceable Flag set it sent. 286 4.1.2 Intermediate RBridge 288 The intermediate RBridges need to be configured properly as MIP for 289 VLAN/FGL based MA. The TRILL OAM application layer validates the 290 received OAM frame by examining the presence of the TRILL Alert flag, 291 OAM Ethertype at the end of the Flow Entropy, the OpCode being PTM 292 and Traceable Flag set, the intermediate RBridges take the following 293 actions: 295 o Optionally include the following TLVs: 297 - Previous RBridge Nickname TLV (69) 299 - Interface Status TLV (4) 301 - Next-Hop RBridge List TLV (70) 303 - Sender ID TLV (1) 305 o Forward the received message including the TRILL header, the 306 payload and the appended TLVs (if any) to the address specified in 307 Out-of-Band Reply Address TLV. If Out-of-Band Reply Address TLV is 308 not present, either forward it to a system default centralized 309 management server or discard it. 311 4.1.3 Destination RBridge 313 Processing is identical to that in Section 4.1.2. The Destination 314 RBridge should not further forward the message in order to prevent 315 leaking of the packet out of the TRILL campus 317 4.1.4 Centralized Management Server 319 The centralized management server is normally served as an SDN 320 controller, e.g. an Openflow controller. It is up to the 321 implementation how to deal with the collected packets of PTM with 322 traceable flag from RBridges. The common logic is the centralized 323 management server compares the Session Identification Number and hop 324 count value in TRILL header to trace the path the packet taken. 326 4.2 Multi-Destination Tree Verification Message (MTVM) with Traceable 327 Flag 329 MVTM can be used by the OAM tools for plotting the entire or VLAN/FGL 330 pruned distribution tree, reachability verification for set of 331 RBridges on a given tree or trace along a specified tree to a set of 332 RBridges. 334 A new TLV is defined as shown in figure 3. 336 1 2 3 337 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 338 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 339 | Type | Length | Reserved |E| 340 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 342 Figure 3. Tree Trace Mode TLV 344 o Type (1 octet): 75 (TBD), Tree Trace Mode TLV 346 o Length (2 octets): 1 348 o E (1 bit): Egress Flag. When RBridge Scope TLV is not present 349 and E flag is 1, trace the receiving RBridge which are egress 350 RBridges on the tree of the specified VLAN/FGL or multicast group; 351 otherwise, ignore this flag. 353 4.2.1 Actions by Originator RBridge 355 The originator RBridge takes the following actions: 357 o Identifies the nickname of distribution tree to be traced. 359 o Constructs the Flow Entropy based on user-specified parameters 360 or implementation-specific default parameters. 362 o Specifies the applicable Hop Count value. 364 o Constructs the TRILL OAM header: set the OpCode to Multicast 365 Tree Verification Message type (67). Assign an applicable Session 366 Identification number for the request. Return Code and Return Sub- 367 code MUST be set to zero. Set Traceable flags to 1. 369 o Includes the following OAM TLVs, where applicable: 371 - Out-of-Band Reply Address TLV: When Traceable flag is set, 372 Out-of-Band Reply Address TLV needs to be set to the address 373 that the traced message should be sent. It is normally the 374 address of the centralized management server 376 - RBridge Scope TLV 377 - Tree Trace Mode TLV: When RBridge Scope TLV is present, E flag 378 of this TLV SHOULD not be set to 1. 380 - Diagnostic Label TLV 382 - Sender ID TLV 384 o Dispatches the OAM frame to the TRILL data plane for 385 transmission. 387 The originator RBridge SHOULD not expect the replies for the 388 Multicast Tree Verification Message with Traceable Flag it sent. 390 4.2.2 Receiving RBridge 392 The TRILL OAM application layer validates the received OAM frame by 393 examining the presence of the TRILL Alert flag and OAM Ethertype at 394 the end of the Flow Entropy. If Traceable Flag is set to 1 in MTVM, 395 the RBridge validates the frame and analyzes if it is an in-scope 396 RBridge. 398 If the RBridge Scope TLV is present and the local RBridge nickname is 399 specified in the scope list, the receiving RBridge proceeds with 400 further processing as defined in Section 4.1.3. 402 If the RBridge Scope TLV is absent, the receiving RBridge SHOULD 403 check the Tree Trace Mode TLV. If E flag is 0, the receiving RBridge 404 proceeds with further processing as defined in Section 4.1.3. If E 405 flag is 1 and the receiving RBridge is an egress BRidge for the 406 specified VLAN/FGL or multicast group, the receiving RBridge proceeds 407 with further processing as defined in Section 4.1.3. 409 For other cases, the receiving RBridge is not considered as in-scope 410 RBridge and should not perform as per section 4.2.3. 412 4.2.3 In-Scope RBridges 414 In-Scope RBridges refers to those should tentatively take actions for 415 MTVM request. They are part of receiving RBridges as described in 416 last sub-section. 418 o Optionally include the following TLVs: 420 - Previous RBridge Nickname TLV (69) 422 - Interface Status TLV (4) 424 - Next-Hop RBridge List TLV (70) 425 - Sender ID TLV (1) 427 - Multicast Receiver Port Count TLV (71) 429 o Forward the received message including the TRILL header, the 430 payload and the appended TLVs (if any) to the address specified in 431 Out-of-Band Reply Address TLV. If Out-of-Band Reply Address TLV is 432 not present, either forward it to a system default centralized 433 management server or discard it. 435 4.2.4 Centralized Management Server 437 The centralized management server is normally served as an SDN 438 controller, e.g. an Openflow controller. It is up to the 439 implementation how to deal with the collected packets of MTVM with 440 traceable flag from RBridges. The common logic is the centralized 441 management server compares the Session Identification Number and hop 442 count value in TRILL header to trace the path the packet taken along 443 a distribution tree. It can be used to plot the entire tree or pruned 444 tree or to find out who are the edge RBridges connecting users for a 445 specified VLAN/FGL. 447 5. Security Considerations 449 For general TRILL fault management security considerations, please 450 refer to [RFC7455]. 452 6. IANA Considerations 454 One TLV Type is required to be assigned from the "CFM OAM IETF TLV 455 Types" sub-registry as follows: 457 Value Assignment 458 ----- ---------- 459 75 Tree Trace Mode TLV 461 7. References 463 7.1 Normative References 465 [RFC6325] Perlman, R., et.al. "RBridge: Base Protocol Specification", 466 RFC 6325, July 2011. 468 [RFC6439] Eastlake, D. et.al., "RBridge: Appointed Forwarder", RFC 469 6439, November 2011. 471 [RFC6905] Senevirathne, T., Bond, D., Aldrin, S., Li, Y., and R. 472 Watve, "Requirements for Operations, Administration, and 473 Maintenance (OAM) in Transparent Interconnection of Lots 474 of Links (TRILL)", RFC 6905, March 2013. 476 [RFC7172] Eastlake 3rd, D., Zhang, M., Agarwal, P., Perlman, R., and 477 D. Dutt, "Transparent Interconnection of Lots of Links 478 (TRILL): Fine-Grained Labeling", RFC 7172, May 2014. 480 [RFC7174] Salam, S., Senevirathne, T., Aldrin, S., and D. Eastlake 481 3rd, "Transparent Interconnection of Lots of Links (TRILL) 482 Operations, Administration, and Maintenance (OAM) 483 Framework", RFC 7174, May 2014, 485 [RFC7180] Eastlake 3rd, D., Zhang, M., Ghanwani, A., Manral, V., and 486 A. Banerjee, "Transparent Interconnection of Lots of Links 487 (TRILL): Clarifications, Corrections, and Updates", RFC 488 7180, May 2014. 490 [RFC7455] Senevirathne, T., Finn, N., Salam, S., Kumar, D., Eastlake 491 3rd, D., Aldrin, S., and Y. Li, "Transparent 492 Interconnection of Lots of Links (TRILL): Fault 493 Management", RFC 7455, March 2015. 495 7.2 Informative References 497 [OpenFlow] OpenFlow Switch Specification Version, March 26, 2015. 498 (https://www.opennetworking.org/images/stories/downloads/ 499 sdn-resources/ onf-specifications/openflow/openflow- 500 switch-v1.5.1.pdf) 502 8. Acknowledgments 504 TBD 506 Authors' Addresses 508 Yizhou Li 509 Huawei Technologies 510 101 Software Avenue, 511 Nanjing 210012 512 China 514 Phone: +86-25-56624629 515 Email: liyizhou@huawei.com 516 Donald Eastlake 517 Huawei R&D USA 518 155 Beaver Street 519 Milford, MA 01757 USA 521 Phone: +1-508-333-2270 522 Email: d3e3e3@gmail.com 524 Hao Chen 525 Huawei Technologies 526 101 Software Avenue, 527 Nanjing 210012 528 China 530 Email: philips.chenhao@huawei.com 532 Deepak Kumar 533 CISCO Systems 534 510 McCarthy Blvd, 535 Milpitas, CA 95035, USA 537 Phone : +1 408-853-9760 538 Email: dekumar@cisco.com 540 Sujay Gupta 541 IP Infusion 542 RMZ Centennial 543 Mahadevapura Post 544 Bangalore - 560048 545 India 547 Email: sujay.gupta@ipinfusion.com