idnits 2.17.1 draft-ietf-spring-oam-usecase-04.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 date (October 20, 2016) is 2744 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 4379 (Obsoleted by RFC 8029) == Outdated reference: A later version (-25) exists of draft-ietf-isis-segment-routing-extensions-08 == Outdated reference: A later version (-13) exists of draft-ietf-mpls-spring-lsp-ping-00 == Outdated reference: A later version (-27) exists of draft-ietf-ospf-segment-routing-extensions-09 == Outdated reference: A later version (-15) exists of draft-ietf-spring-segment-routing-09 == Outdated reference: A later version (-03) exists of draft-ietf-spring-sr-oam-requirement-02 Summary: 1 error (**), 0 flaws (~~), 6 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 spring R. Geib, Ed. 3 Internet-Draft Deutsche Telekom 4 Intended status: Informational C. Filsfils 5 Expires: April 23, 2017 C. Pignataro, Ed. 6 N. Kumar 7 Cisco 8 October 20, 2016 10 A Scalable and Topology-Aware MPLS Dataplane Monitoring System 11 draft-ietf-spring-oam-usecase-04 13 Abstract 15 This document describes features of a path monitoring system and 16 related use cases. Segment based routing enables a scalable and 17 simple method to monitor data plane liveliness of the complete set of 18 paths belonging to a single domain. The MPLS monitoring system adds 19 features to the traditional MPLS ping and LSP trace, in a very 20 complementary way. MPLS topology awareness reduces management and 21 control plane involvement of OAM measurements while enabling new OAM 22 features. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on April 23, 2017. 41 Copyright Notice 43 Copyright (c) 2016 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . . 2 59 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 60 3. An MPLS Topology-Aware Path Monitoring System . . . . . . . . 4 61 4. SR-based Path Monitoring Use Case Illustration . . . . . . . 6 62 4.1. Use Case 1 - LSP Dataplane Monitoring . . . . . . . . . . 6 63 4.2. Use Case 2 - Monitoring a Remote Bundle . . . . . . . . . 8 64 4.3. Use Case 3 - Fault Localization . . . . . . . . . . . . . 9 65 5. Failure Notification from PMS to LERi . . . . . . . . . . . . 9 66 6. Applying SR to Monitoring non-SR based LSPs (LDP and possibly 67 RSVP-TE) . . . . . . . . . . . . . . . . . . . . . . . . . . 9 68 7. PMS Monitoring of Different Segment ID Types . . . . . . . . 10 69 8. Connectivity Verification Using PMS . . . . . . . . . . . . . 10 70 9. Extensions of Specifications Relevant to this Use Case . . . 10 71 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 72 11. Security Considerations . . . . . . . . . . . . . . . . . . . 10 73 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 74 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 75 13.1. Normative References . . . . . . . . . . . . . . . . . . 11 76 13.2. Informative References . . . . . . . . . . . . . . . . . 11 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 79 1. Acronyms 81 ECMP Equal-Cost Multi-Path 82 IGP Interionr Gateway Protocol 83 LER Label Edge Router 84 LSP Label Switched Path 85 LSR Label Switching Router 86 OAM Operations, Administration, and Maintenance 87 PMS Path Monitoring System 88 SID Segment Identifier 89 SR Segment Routing 90 SRGB Segment Routing Global Block 92 2. Introduction 94 It is essential for a network operator to monitor all the forwarding 95 paths observed by the transported user packets. The monitoring 96 packet is expected to be forwarded in dataplane in a similar way as 97 user packets. Segment Routing enables forwarding of packets along 98 pre-defined paths and segments and thus a Segment Routed monitoring 99 packet can stay in dataplane while passing along one or more segments 100 to be monitored. 102 This document describes a system using MPLS data plane path 103 monitoring capabilities. The use cases introduced here is limited to 104 a single IGP MPLS domain. 106 The system applies to monitoring of LDP LSP's as well as to 107 monitoring of Segment Routed LSP's. As compared to LDP, Segment 108 Routing is expected to simplify the system by enabling MPLS topology 109 detection based on IGP signaled segments as specified at 110 [I-D.ietf-isis-segment-routing-extensions] and 111 [I-D.ietf-ospf-segment-routing-extensions]. Thus a centralised and 112 MPLS topology aware monitoring unit can be realized in a Segment 113 Routed domain. This topology awareness can be used for OAM purposes 114 as described by this document. 116 The MPLS path monitoring system described by this document can be 117 realised with pre-Segment Routing (SR) based technology. Making such 118 a pre-SR MPLS monitoring system aware of a domain's complete MPLS 119 topology requires e.g. management plane access. To avoid the use of 120 stale MPLS label information, IGP must be monitored and MPLS topology 121 must be timely aligned with IGP topology. Obviously, enhancing IGPs 122 to exchange of MPLS topology information as done by SR significantly 123 simplifies and stabilises such an MPLS path monitoring system. 125 This document adopts the terminology and framework described in 126 [I-D.ietf-spring-segment-routing]. 128 The system offers several benefits for network monitoring. A single 129 centralized monitoring device is able to monitor the complete set of 130 a domain's forwarding paths. Monitoring packets never leave data 131 plane. MPLS path trace function (whose specification and features 132 are not part of this use case) is required, if the actual data plane 133 of a router should be checked against its control plane. SR 134 capabilities allow to direct MPLS OAM packets from a centralized 135 monitoring system to any router within a domain whose path should be 136 traced. 138 In addition to monitoring paths, problem localization is required. 139 Faults can be localized: 141 o by IGP LSA analysis. 143 o correlation between different SR based monitoring probes. 145 o by any MPLS traceroute method (possibly in combination with SR 146 based path stacks). 148 Topology awareness is an essential part of link state IGPs. Adding 149 MPLS topology awareness to an IGP speaking device hence enables a 150 simple and scalable data plane based monitoring mechanism. 152 MPLS OAM offers flexible features to recognise and execute data paths 153 of an MPLS domain. By utilising the ECMP related tool set offered 154 e.g. by RFC 4379 [RFC4379], a segment based routing LSP monitoring 155 system may: 157 o easily detect ECMP functionality and properties of paths at data 158 level. 160 o construct monitoring packets executing desired paths also if ECMP 161 is present. 163 o limit the MPLS label stack of an OAM packet to a minmum of 3 164 labels. 166 Alternatively, any path may be executed by building suitable label 167 stacks. This allows path execution without ECMP awareness. 169 The MPLS Path Monitoring System (PMS) may be any server residing at a 170 single interface of the domain to be monitored. It doesn't have to 171 support any specialised protocol stack, it just should be capable of 172 understanding the topology and building the monitoring probe packet 173 with the right segment stack. The monitoring probe packet could be 174 BFD or LSP Ping packet or any other OAM format that PMS supports. As 175 long as the monitoring packet returns back to the server, the path 176 can be considered as validated. The MPLS monitoring servers are the 177 single entities pushing monitoring packet label stacks. If the depth 178 of label stacks to be pushed by a path monitoring system (PMS) are of 179 concern for a domain, a dedicated server based path monitoring 180 architecture allows limiting monitoring related label stack pushes to 181 these servers. 183 Documents discussing SR OAM requirements and possible solutions to 184 allow SR usage as described by this document have been submitted 185 already, see [I-D.ietf-spring-sr-oam-requirement] and 186 [I-D.ietf-mpls-spring-lsp-ping]. 188 3. An MPLS Topology-Aware Path Monitoring System 190 An MPLS PMS which is able to learn the IGP LSDB (including the SID's) 191 is able to execute arbitrary chains of label switched paths. It can 192 send pure monitoring packets along such a path chain or it can direct 193 suitable MPLS OAM packets to any node along a path segment. Segment 194 Routing here is used as a means of adding label stacks and hence 195 transport to standard MPLS OAM packets, which then detect 196 correspondence of control and data plane of this (or any other 197 addressed) path. Any node connected to an SR domain is MPLS topology 198 aware (the node knows all related IP addresses, SR SIDs and MPLS 199 labels). Thus a PMS connected to an MPLS SR domain just needs to set 200 up a topology data base for monitoring purposes. 202 Let us describe how the PMS constructs a labels stack to transport a 203 packet to LER i, monitor its path to LER j and then receive the 204 packet back. 206 The PMS may do so by sending packets carrying the following MPLS 207 label stack infomation: 209 o Top Label: a path from PMS to LER i, which is expressed as Node 210 SID of LER i. 212 o Next Label: the path that needs to be monitored from LER i to LER 213 j. If this path is a single physical interface (or a bundle of 214 connected interfaces), it can be expressed by the related AdjSID. 215 If the shortest path from LER i to LER j is supposed to be 216 monitored, the Node-SID (LER j) can be used. Another option is to 217 insert a list of segments expressing the desired path (hop by hop 218 as an extreme case). If LER i pushes a stack of Labels based on a 219 SR policy decision and this stack of LSPs is to be monitored, the 220 PMS needs an interface to collect the information enabling it to 221 address this SR created path. 223 o Next Label or address: the path back to the PMS. Likely, no 224 further segment/label is required here. Indeed, once the packet 225 reaches LER j, the 'steering' part of the solution is done and the 226 probe just needs to return to the PMS. This is best achieved by 227 popping the MPLS stack and revealing a probe packet with PMS as 228 destination address (note that in this case, the source and 229 destination addresses could be the same). If an IP address is 230 applied, no SID/label has to be assigned to the PMS (if it is a 231 host/server residing in an IP subnet outside the MPLS domain). 233 Note: a deployment might prefer not to connect the PMS to the MPLS 234 domain. if the PMS is an IP host not connected to the MPLS domain, 235 the PMS can send its probe with the list of SIDs/Labels onto a 236 suitable tunnel providing an MPLS access to a router which is part of 237 the monitored MPLS domain. 239 4. SR-based Path Monitoring Use Case Illustration 241 4.1. Use Case 1 - LSP Dataplane Monitoring 243 +---+ +----+ +-----+ 244 |PMS| |LSR1|-----|LER i| 245 +---+ +----+ +-----+ 246 | / \ / 247 | / \__/ 248 +-----+/ /| 249 |LER m| / | 250 +-----+\ / \ 251 \ / \ 252 \+----+ +-----+ 253 |LSR2|-----|LER j| 254 +----+ +-----+ 256 Example of a PMS based LSP dataplane monitoring 258 Figure 1 260 For the sake of simplicity, let's assume that all the nodes are 261 configured with the same SRGB [I-D.ietf-spring-segment-routing]. 263 Let's assign the following Node SIDs to the nodes of the figure: PMS 264 = 10, LER i = 20, LER j = 30. 266 To be able to work with the smallest possible SR label stack, first a 267 suitable MPLS OAM method is used to detect the ECMP routed path 268 between LER i to LER j which is to be monitored (and the required 269 address information to direct a packet along it). Afterwards the PMS 270 sets up and sends packets to monitor availability of the detected 271 path. The PMS does this by creating a measurement packet with the 272 following label stack (top to bottom): 20 - 30 - 10. The packet will 273 only reliably use the monitored path, if the label and address 274 information used in combination with the MPLS OAM method of choice is 275 identical to that of the monitoring packet. 277 LER m forwards the packet received from the PMS to LSR1. Assuming 278 Pen-ultimate Hop Popping to be deployed, LSR1 pops the top label and 279 forwards the packet to LER i. There the top label has a value 30 and 280 LER i forwards it to LER j. This will be done transmitting the 281 packet via LSR1 or LSR2. The LSR will again pop the top label. LER 282 j will forward the packet now carrying the top label 10 to the PMS 283 (and it will pass a LSR and LER m). 285 A few observations on the example given in figure 1: 287 o The path PMS to LER i must be available. This path must be 288 detectable, but it is usually sufficient to apply a Shortest Path 289 First algorithm based path. 291 o If ECMP is deployed, it may be desired to measure along both 292 possible paths which a packet may use between LER i and LER j. To 293 do so, the MPLS OAM mechanism chosen to detect ECMP must reveal 294 the required information (an example is a so called tree trace) 295 between LER i and LER j. This method of dealing with ECMP based 296 load balancing paths requires the smallest SR label stacks if 297 monitoring of paths is applied after the tree trace completion. 299 o The path LER j to PMS must be available. This path must be 300 detectable, but it is usually sufficient to apply an SPF based 301 path. 303 Once the MPLS paths (Node SIDs) and the required information to deal 304 with ECMP has been detected, the paths of LER i to LER j can be 305 monitored by the PMS. Monitoring itself does not require MPLS OAM 306 functionality. All monitoring packets stay on dataplane, hence path 307 monitoring does no longer require control plane interaction in any 308 LER or LSR of the domain. To ensure reliable results, the PMS should 309 be aware of any changes in IGP or MPLS topology. Further changes in 310 ECMP functionality at LER i will impact results. Either the PMS 311 should be notified of such changes or they should be limited to 312 planned maintenance. After a topology change, a suitable MPLS OAM 313 mechanism may be useful to detect the impact of the change. 315 Determining a path to be executed prior to a measurement may also be 316 done by setting up a label stack including all Node SIDs along that 317 path (if LSR1 has Node SID 40 in the example and it should be passed 318 between LER i and LER j, the label stack is 20 - 40 - 30 - 10). The 319 advantage of this method is, that it does not involve MPLS OAM 320 functionality and it is independent of ECMP functionalities. The 321 method still is able to monitor all link combinations of all paths of 322 an MPLS domain. If correct forwarding along the desired paths has to 323 be checked, some suitable MPLS OAM mechanism may be applied also in 324 this case. 326 In theory at least, a single PMS is able to monitor data plane 327 availability of all LSPs in the domain. The PMS may be a router, but 328 could also be dedicated monitoring system. If measurement system 329 reliability is an issue, more than a single PMS may be connected to 330 the MPLS domain. 332 Monitoring an MPLS domain by a PMS based on SR offers the option of 333 monitoring complete MPLS domains with little effort and very 334 excellent scalability. Data plane failure detection by circulating 335 monitoring packets can be executed at any time. The PMS further 336 could be enabled to send MPLS OAM packets with the label stacks and 337 address information identical to those of the monitoring packets to 338 any node of the MPLS domain. Prior to monitoring a path, MPLS OAM 339 may be used to detect ECMP dependant forwarding of a packet. A PMS 340 may be designed to learn the IP address information required to 341 execute a particular ECMP routed path and interfaces along that path. 342 This allows to monitor these paths with label stacks reduced to a 343 limited number of Node-SIDs resulting from SPF routing. The PMS does 344 not require access to LSR/LER management interfaces or their control 345 plane to do so. 347 4.2. Use Case 2 - Monitoring a Remote Bundle 349 +---+ _ +--+ +-------+ 350 | | { } | |---991---L1---662---| | 351 |PMS|--{ }-|R1|---992---L2---663---|R2 (72)| 352 | | {_} | |---993---L3---664---| | 353 +---+ +--+ +-------+ 355 SR based probing of all the links of a remote bundle 357 Figure 2 359 R1 addresses Lx by the Adjacency SID 99x, while R2 addresses Lx by 360 the Adjacency SID 66(x+1). 362 In the above figure, the PMS needs to assess the dataplane 363 availability of all the links within a remote bundle connected to 364 routers R1 and R2. 366 The monitoring system retrieves the SID/Label information from the 367 IGP LSDB and appends the following segment list/label stack: {72, 368 662, 992, 664} on its IP probe (whose source and destination 369 addresses are the address of the PMS). 371 PMS sends the probe to its connected router. If the connected router 372 is not SR compliant, a tunneling technique can be used to tunnel the 373 probe and its MPLS stack to the first SR router. The MPLS/SR domain 374 then forwards the probe to R2 (72 is the Node SID of R2). R2 375 forwards the probe to R1 over link L1 (Adjacency SID 662). R1 376 forwards the probe to R2 over link L2 (Adjacency SID 992). R2 377 forwards the probe to R1 over link L3 (Adjacency SID 664). R1 then 378 forwards the IP probe to PMS as per classic IP forwarding. 380 4.3. Use Case 3 - Fault Localization 382 In the previous example, a uni-directional fault on the middle link 383 in direction of R2 to R1 would be localized by sending the following 384 two probes with respective segment lists: 386 o 72, 662, 992, 664 388 o 72, 663, 992, 664 390 The first probe would fail while the second would succeed. 391 Correlation of the measurements reveals that the only difference is 392 using the Adjacency SID 662 of the middle link from R1 to R2 in the 393 non successful measurement. Assuming the second probe has been 394 routed correctly, the fault must have been occurring in R2 which 395 didn't forward the packet to the interface identified by its 396 Adjacency SID 662. 398 5. Failure Notification from PMS to LERi 400 PMS on detecting any failure in the path liveliness may use any out- 401 of-band mechanism to signal the failure to LER i. This document does 402 not propose any specific mechanism and operators can choose any 403 existing or new approach. 405 Alternately, the Operator may log the failure in local monitoring 406 system and take necessary action by manual intervention. 408 6. Applying SR to Monitoring non-SR based LSPs (LDP and possibly RSVP- 409 TE) 411 A SR based PMS connected to a MPLS domain consisting of LER and LSR 412 supporting SR and LDP or RSVP-TE in parallel in all nodes may use SR 413 paths to transmit packets to and from start and end points of non-SR 414 based LSP paths to be monitored. In the above example, the label 415 stack top to bottom may be as follows, when sent by the PMS: 417 o Top: SR based Node-SID of LER i at LER m. 419 o Next: LDP or RSVP-TE label identifying the path to LER j at LER i. 421 o Bottom: SR based Node-SID identifying the path to the PMS at LER j 423 While the mixed operation shown here still requires the PMS to be 424 aware of the LER LDP-MPLS or RSVP-TE topology, the PMS may learn the 425 SR MPLS topology by IGP and use this information. 427 An implementation report on a PMS operating in an LDP domain is given 428 in [I-D.leipnitz-spring-pms-implementation-report]. 430 7. PMS Monitoring of Different Segment ID Types 432 MPLS SR topology awareness should allow the SID to monitor liveliness 433 of most types of SIDs (this may not be recommendable if a SID 434 identifies an inter domain interface). 436 To match control plane information with data plane information, MPLS 437 OAM functions as defined for example by RFC 4379 [RFC4379] should be 438 enhanced to allow collection of data relevant to check all relevant 439 types of Segment IDs. 441 8. Connectivity Verification Using PMS 443 While the PMS based use cases explained in Section 3 are sufficient 444 to provide continuity check between LER i and LER j, it may not help 445 perform connectivity verification. So in some cases like data plane 446 programming corruption, it is possible that a transit node between 447 LER i and LER j erroneously removes the top segment ID and forwards a 448 monitoring packet to the PMS based on the bottom segment ID leading 449 to a falsified path liveliness indication by the PMS. 451 There are various method to perform basic connectivity verification 452 like intermittently setting the TTL to 1 in bottom label so LER j 453 selectively perform connectivity verification. Other methods are 454 possible and may be added when requirements and solutions are 455 specified. 457 9. Extensions of Specifications Relevant to this Use Case 459 The following activities are welcome enhancements supporting this use 460 case, but they are not part of it: 462 RFC 4379 [RFC4379] functions should be extended to support Flow- and 463 Entropy Label based ECMP. 465 10. IANA Considerations 467 This memo includes no request to IANA. 469 11. Security Considerations 471 As mentioned in the introduction, a PMS monitoring packet should 472 never leave the domain where it originated. It therefore should 473 never use stale MPLS or IGP routing information. Further, assigning 474 different label ranges for different purposes may be useful. A well 475 known global service level range may be excluded for utilisation 476 within PMS measurement packets. These ideas shouldn't start a 477 discussion. They rather should point out, that such a discussion is 478 required when SR based OAM mechanisms like a SR are standardised. 480 12. Acknowledgements 482 The authors would like to thank Nobo Akiya for his contribution. 483 Raik Leipnitz kindly provided an editorial review. The authors would 484 also like to thank Faisal Iqbal for an insightful review and a useful 485 set of comments and suggestions. 487 13. References 489 13.1. Normative References 491 [RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-Protocol 492 Label Switched (MPLS) Data Plane Failures", RFC 4379, 493 DOI 10.17487/RFC4379, February 2006, 494 . 496 13.2. Informative References 498 [I-D.ietf-isis-segment-routing-extensions] 499 Previdi, S., Filsfils, C., Bashandy, A., Gredler, H., 500 Litkowski, S., Decraene, B., and j. jefftant@gmail.com, 501 "IS-IS Extensions for Segment Routing", draft-ietf-isis- 502 segment-routing-extensions-08 (work in progress), October 503 2016. 505 [I-D.ietf-mpls-spring-lsp-ping] 506 Kumar, N., Swallow, G., Pignataro, C., Akiya, N., Kini, 507 S., Gredler, H., and M. Chen, "Label Switched Path (LSP) 508 Ping/Trace for Segment Routing Networks Using MPLS 509 Dataplane", draft-ietf-mpls-spring-lsp-ping-00 (work in 510 progress), May 2016. 512 [I-D.ietf-ospf-segment-routing-extensions] 513 Psenak, P., Previdi, S., Filsfils, C., Gredler, H., 514 Shakir, R., Henderickx, W., and J. Tantsura, "OSPF 515 Extensions for Segment Routing", draft-ietf-ospf-segment- 516 routing-extensions-09 (work in progress), July 2016. 518 [I-D.ietf-spring-segment-routing] 519 Filsfils, C., Previdi, S., Decraene, B., Litkowski, S., 520 and R. Shakir, "Segment Routing Architecture", draft-ietf- 521 spring-segment-routing-09 (work in progress), July 2016. 523 [I-D.ietf-spring-sr-oam-requirement] 524 Kumar, N., Pignataro, C., Akiya, N., Geib, R., Mirsky, G., 525 and S. Litkowski, "OAM Requirements for Segment Routing 526 Network", draft-ietf-spring-sr-oam-requirement-02 (work in 527 progress), July 2016. 529 [I-D.leipnitz-spring-pms-implementation-report] 530 Leipnitz, R. and R. Geib, "A scalable and topology aware 531 MPLS data plane monitoring system", draft-leipnitz-spring- 532 pms-implementation-report-00 (work in progress), June 533 2016. 535 Authors' Addresses 537 Ruediger Geib (editor) 538 Deutsche Telekom 539 Heinrich Hertz Str. 3-7 540 Darmstadt 64295 541 Germany 543 Phone: +49 6151 5812747 544 Email: Ruediger.Geib@telekom.de 546 Clarence Filsfils 547 Cisco Systems, Inc. 548 Brussels 549 Belgium 551 Email: cfilsfil@cisco.com 553 Carlos Pignataro (editor) 554 Cisco Systems, Inc. 555 7200 Kit Creek Road 556 Research Triangle Park, NC 27709-4987 557 US 559 Email: cpignata@cisco.com 561 Nagendra Kumar 562 Cisco Systems, Inc. 563 7200 Kit Creek Road 564 Research Triangle Park, NC 27709 565 US 567 Email: naikumar@cisco.com