idnits 2.17.1 draft-ietf-i2rs-traceability-03.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 document has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (May 27, 2015) is 3258 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-15) exists of draft-ietf-i2rs-architecture-07 == Outdated reference: A later version (-11) exists of draft-ietf-i2rs-problem-statement-04 -- Obsolete informational reference (is this intentional?): RFC 6536 (Obsoleted by RFC 8341) Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 I2RS J. Clarke 3 Internet-Draft G. Salgueiro 4 Intended status: Informational C. Pignataro 5 Expires: November 28, 2015 Cisco 6 May 27, 2015 8 Interface to the Routing System (I2RS) Traceability: Framework and 9 Information Model 10 draft-ietf-i2rs-traceability-03 12 Abstract 14 This document describes a framework for traceability in the Interface 15 to the Routing System (I2RS) and information model for that 16 framework. It specifies the motivation, requirements, use cases, and 17 defines an information model for recording interactions between 18 elements implementing the I2RS protocol. This framework provides a 19 consistent tracing interface for components implementing the I2RS 20 architecture to record what was done, by which component, and when. 21 It aims to improve the management of I2RS implementations, and can be 22 used for troubleshooting, auditing, forensics, and accounting 23 purposes. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on November 28, 2015. 42 Copyright Notice 44 Copyright (c) 2015 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 60 2. Terminology and Conventions . . . . . . . . . . . . . . . . . 3 61 3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 4. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 3 63 5. Information Model . . . . . . . . . . . . . . . . . . . . . . 4 64 5.1. I2RS Traceability Framework . . . . . . . . . . . . . . . 4 65 5.2. I2RS Trace Log Mandatory Fields . . . . . . . . . . . . . 5 66 5.3. End of Message Marker . . . . . . . . . . . . . . . . . . 7 67 5.4. I2RS Trace Log Extensibility and Optional Fields . . . . 8 68 6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 8 69 7. Operational Guidance . . . . . . . . . . . . . . . . . . . . 8 70 7.1. Trace Log Creation . . . . . . . . . . . . . . . . . . . 8 71 7.2. Trace Log Temporary Storage . . . . . . . . . . . . . . . 9 72 7.3. Trace Log Rotation . . . . . . . . . . . . . . . . . . . 9 73 7.4. Trace Log Retrieval . . . . . . . . . . . . . . . . . . . 9 74 7.4.1. Retrieval Via Syslog . . . . . . . . . . . . . . . . 10 75 7.4.2. Retrieval Via I2RS Information Collection . . . . . . 10 76 7.4.3. Retrieval Via I2RS Pub-Sub . . . . . . . . . . . . . 10 77 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 78 9. Security Considerations . . . . . . . . . . . . . . . . . . . 11 79 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 80 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 81 11.1. Normative References . . . . . . . . . . . . . . . . . . 12 82 11.2. Informative References . . . . . . . . . . . . . . . . . 12 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 85 1. Introduction 87 The architecture for the Interface to the Routing System 88 ([I-D.ietf-i2rs-architecture]) specifies that I2RS Clients wishing to 89 retrieve or change routing state on a routing element MUST 90 authenticate to an I2RS Agent. The I2RS Client will have a unique 91 identity it provides for authentication, and should provide another, 92 opaque identity for applications communicating through it. The 93 programming of routing state will produce a return code containing 94 the results of the specified operation and associated reason(s) for 95 the result. All of this is critical information to be used for 96 understanding the history of I2RS interactions. 98 This document describes use cases for I2RS traceability. Based on 99 these use cases, the document proposes an information model and 100 reporting requirements to provide for effective recording of I2RS 101 interactions. In this context, effective troubleshooting means being 102 able to identify what operation was performed by a specific I2RS 103 Client, what was the result of the operation, and when that operation 104 was performed. 106 Discussions about the retention of the data logged as part of I2RS 107 traceability, while important, are outside of the scope of this 108 document. 110 2. Terminology and Conventions 112 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 113 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 114 document are to be interpreted as described in [RFC2119]. 116 The architecture specification for I2RS [I-D.ietf-i2rs-architecture] 117 defines additional terms used in this document that are specific to 118 the I2RS domain, such as "I2RS Agent", "I2RS Client", etc. The 119 reader is expected to be familiar with the terminology and concepts 120 defined in [I-D.ietf-i2rs-architecture]. 122 The IP addresses used in the example in this document correspond to 123 the documentation address blocks 192.0.2.0/24 (TEST-NET-1), 124 198.51.100.0/24 (TEST-NET-2) and 203.0.113.0/24 (TEST-NET-3) as 125 described in [RFC5737]. 127 3. Motivation 129 As networks scale and policy becomes an increasingly important part 130 of the control plane that creates and maintains the forwarding state, 131 operational complexity increases as well. I2RS offers more granular 132 and coherent control over policy and control plane state, but it also 133 removes or reduces the locality of the policy that has been applied 134 to the control plane at any individual forwarding device. The 135 ability to automate and abstract even complex policy-based controls 136 highlights the need for an equally scalable traceability function to 137 provide event-level granularity of the routing system compliant with 138 the requirements of I2RS (Section 5 of 139 [I-D.ietf-i2rs-problem-statement]). 141 4. Use Cases 143 An obvious motivation for I2RS traceability is the need to 144 troubleshoot and identify root-causes of problems in these 145 increasingly complex routing systems. For example, since I2RS is a 146 high-throughput multi-channel, full duplex and highly responsive 147 interface, I2RS Clients may be performing a large number of 148 operations on I2RS Agents concurrently or at nearly the same time and 149 quite possibly in very rapid succession. As these many changes are 150 made, the network reacts accordingly. These changes might lead to a 151 race condition, performance issues, data loss, or disruption of 152 services. In order to isolate the root cause of these issues it is 153 critical that a network operator or administrator has visibility into 154 what changes were made via I2RS at a specific time. 156 Some network environments have strong auditing requirements for 157 configuration and runtime changes. Other environments have policies 158 that require saving logging information for operational or regulatory 159 compliance considerations. These requirements therefore demand that 160 I2RS provides an account of changes made to network element routing 161 systems. 163 As I2RS becomes increasingly pervasive in routing environments, a 164 traceability model offers significant advantages and facilitates the 165 following use cases: 167 o Automated event correlation, trend analysis, and anomaly 168 detection. 170 o Trace log storage for offline (manual or tools) analysis. 172 o Improved accounting of routing system operations. 174 o Standardized structured data format for writing common tools. 176 o Common reference for automated testing and incident reporting. 178 o Real-time monitoring and troubleshooting. 180 o Enhanced network audit, management and forensic analysis 181 capabilities. 183 5. Information Model 185 5.1. I2RS Traceability Framework 187 This section describes a framework for I2RS traceability based on the 188 I2RS Architecture. Some notable elements on the architecture are 189 highlighted herein. 191 The interaction between the optional northbound application, I2RS 192 Client, I2RS Agent, the Routing System and the data captured in the 193 I2RS trace log is shown in Figure 1. 195 +----------------+ 196 |Application | 197 |.............. | 198 | Application ID | 199 +----------------+ 200 ^ 201 | 0 .. N 202 | 203 V 204 +-------------+ 205 |I2RS Client | 206 |.............| 207 | Client ID | 208 +-------------+ 209 ^ 210 | 1 .. N 211 | 212 V 213 +-------------+ +-----------------------------+ 214 |I2RS Agent |---------------->|Trace Log | 215 | | |.............................| 216 +-------------+ |Log Entry [1 .. N] | 217 ^ |.............................| 218 | |Request Timestamp | 219 | |Client ID | 220 | |Client Priority | 221 | ^ |Secondary ID | 222 Operation + | Result Code |Client Address | 223 Op Data | |Operation | 224 V | |Operation Data Present | 225 | |Operation Data | 226 | |Transaction ID | 227 | |Result Code | 228 | |Result Timestamp | 229 V |End Of Message | 230 +-------------+ +-----------------------------+ 231 |Routing | 232 |System | 233 +-------------+ 235 Figure 1: I2RS Interaction Trace Log Capture 237 5.2. I2RS Trace Log Mandatory Fields 239 In order to ensure that each I2RS interaction can be properly traced 240 back to the Client that made the request at a specific point in time, 241 the following information MUST be collected and stored by the Agent. 243 The list below describes the fields captured in the I2RS trace log. 245 Entry ID: This is a unique identifier for each entry in the I2RS 246 trace log. Since multiple operations can occur from the same 247 Client at the same time, it is important to have an identifier 248 that can be unambiguously associated to a specific entry. 250 Request Timestamp: The specific time, adhering to [RFC3339] format, 251 at which the I2RS operation was received by the Agent. Given that 252 many I2RS operations can occur in rapid succession, the use of 253 fractional seconds MUST be used to provide adequate granularity. 254 Fractional seconds SHOULD be expressed using human-readable 32-bit 255 second and 32-bit microsecond granularity in second.microsecond 256 format. 258 Client Identity: The I2RS Client identity used to authenticate the 259 Client to the I2RS Agent. 261 Client Priority: The I2RS Client priority assigned by the access 262 control model that authenticates the Client. For example, this 263 can be set by the NETCONF Access Control Model (NACM) as described 264 in [RFC6536]. 266 Secondary Identity: This is an opaque identity that may be known to 267 the Client from a northbound controlling application. This is 268 used to trace the northbound application driving the actions of 269 the Client. The Client may not provide this identity to the Agent 270 if there is no external application driving the Client. However, 271 this field MUST be logged. If the Client does not provide an 272 application ID, then the Agent MUST log an UNAVAILABLE value in 273 the field. 275 Client Address: This is the network address of the Client that 276 connected to the Agent. For example, this may be an IPv4 or IPv6 277 address. [Note: will I2RS support interactions that have no 278 network address? If so this field will need to be updated.] 280 Operation: This is the I2RS operation performed. For example, this 281 may be an add route operation if a route is being inserted into a 282 routing table. 284 Operation Data Present: This is a Boolean field that indicates 285 whether or not addition per-Operation Data is present. 287 Operation Data: This field comprises the data passed to the Agent 288 to complete the desired operation. For example, if the operation 289 is a route add operation, the Operation Data would include the 290 route prefix, prefix length, and next hop information to be 291 inserted as well as the specific routing table to which the route 292 will be added. The operation data can also include interface 293 information. If Operation Data is provided, then the Operation 294 Data Present field MUST be set to TRUE. Some operations may not 295 provide operation data. In those cases, the Operation Data 296 Present field MUST be set to FALSE, and this field MUST be empty. 298 Transaction ID: The Transaction Identity is an opaque string that 299 represents this particular operation is part of a long-running 300 I2RS transaction that can consist of multiple, related I2RS 301 operations. Using this value, one can relate multiple log entries 302 together as they are part of a single, overall I2RS operation. 303 [NOTE: The requirements for transactions and long-running requests 304 are being discussed in the NETCONF working group, and this text 305 will follow the requirements set forth there.] 307 Result Code: This field holds the result of the operation. In the 308 case of RIB operations, this MUST be the return code as specified 309 in Section 4 of [I-D.nitinb-i2rs-rib-info-model]. The operation 310 may not complete with a result code in the case of a timeout. If 311 the operation fails to complete, it MUST still log the attempted 312 operation with an appropriate result code (e.g., a result code 313 indicating a timeout). 315 Result Timestamp: The specific time, adhering to [RFC3339] format, 316 at which the I2RS operation was completed by the Agent. If the 317 operation timed out, then this field will contain an all-zeroes 318 value of "0000-00-00T00:00:00.00". Given that many I2RS 319 operations can occur in rapid succession, the use of fractional 320 seconds MUST be used to provide adequate granularity. Fractional 321 seconds SHOULD be expressed using human-readable 32-bit second and 322 32-bit microsecond granularity in second.microsecond format. 324 End Of Message: Each log entry SHOULD have an appropriate End Of 325 Message (EOM) indicator. See section Section 5.3 below for more 326 details. 328 5.3. End of Message Marker 330 Because of variability within I2RS trace log fields, implementors 331 MUST use a format-appropriate end of message (EOM) indicator in order 332 to signify the end of a particular record. That is, regardless of 333 format, the I2RS trace log MUST provide a distinct way of 334 distinguishing between the end of one record and the beginning of 335 another. For example, in a linear formated log (similar to syslog) 336 the EOM marker may be a newline character. In an XML formated log, 337 the schema would provide for element tags that denote beginning and 338 end of records. In a JSON formated log, the syntax would provide 339 record separation (likely by comma-separated array elements). 341 5.4. I2RS Trace Log Extensibility and Optional Fields 343 [NOTE: This section is TBD based on further development of I2RS WG 344 milestones.] 346 6. Examples 348 Here is a proposed sample of what the fields might look like in an 349 I2RS trace log. This is only an early proposal. These values are 350 subject to change. 352 Entry ID: 1 353 Request Timestamp: 2013-09-03T12:00:01.21+00:00 354 Client ID: 5CEF1870-0326-11E2-A21F-0800200C9A66 355 Client Priority: 100 356 Secondary ID com.example.RoutingApp 357 Client Address: 192.0.2.2 358 Operation: ROUTE_ADD 359 Operation Data Present: TRUE 360 Operation Data: PREFIX 203.0.113.0 PREFIX-LEN 24 NEXT-HOP 361 198.51.100.1 362 Transaction ID: 2763461 363 Result Code: SUCCESS(0) 364 Result Timestamp: 2013-09-03T12:00:01.23+00:00 366 7. Operational Guidance 368 Specific operational procedures regarding temporary log storage, 369 rollover, retrieval, and access of I2RS trace logs is out of scope 370 for this document. Organizations employing I2RS trace logging are 371 responsible for establishing proper operational procedures that are 372 appropriately suited to their specific requirements and operating 373 environment. In this section we only provide fundamental and 374 generalized operational guidelines that are implementation- 375 independent. 377 7.1. Trace Log Creation 379 The I2RS Agent interacts with the Routing and Signaling functions of 380 the Routing Element. Since the I2RS Agent is responsible for 381 actually making the routing changes on the associated network device, 382 it creates and maintains a log of operations that can be retrieved to 383 troubleshoot I2RS-related impact to the network. 385 7.2. Trace Log Temporary Storage 387 The trace information may be temporarily stored either in an in- 388 memory buffer or as a file local to the Agent. Care should be given 389 to the number of I2RS operations expected on a given Agent so that 390 the appropriate storage medium is used and to maximize the 391 effectiveness of the log while not impacting the performance and 392 health of the Agent. Another noteworthy consideration is that Client 393 requests may not always be processed synchronously or within a 394 bounded time period. Consequently, to ensure that trace log fields, 395 such as "Operation" and "Result Code", are part of the same trace log 396 record it may require buffering of the trace log entries. This 397 buffering may result in additional resource load on the Agent and the 398 network element. 400 Section 7.3 talks about rotating the trace log in order to preserve 401 the operation history without exhausting Agent or network device 402 resources. It is perfectly acceptable, therefore, to use both an in- 403 memory buffer for recent operations while rotating or archiving older 404 operations to a local file. 406 It is outside the scope of this document to specify the 407 implementation details (i.e., size, throughput, data protection, 408 privacy, etc.) for the physical storage of the I2RS log file. Data 409 retention policies of the I2RS traceability log is also outside the 410 scope of this document. 412 7.3. Trace Log Rotation 414 In order to prevent the exhaustion of resources on the I2RS Agent or 415 its associated network device, it is RECOMMENDED that the I2RS Agent 416 implements trace log rotation. The details on how this is achieved 417 are left to the implementation and outside the scope of this 418 document. However, it should be possible to do file rotation based 419 on either time or size of the current trace log. If file rollover is 420 supported, multiple archived log files should be supported in order 421 to maximize the troubleshooting and accounting benefits of the trace 422 log. 424 7.4. Trace Log Retrieval 426 Implementors are free to provide their own, proprietary interfaces 427 and develop custom tools to retrieve and display the I2RS trace log. 428 These may include the display of the I2RS trace log as Command Line 429 Interface (CLI) output. However, a key intention of defining this 430 information model is to establish an vendor-agnostic and consistent 431 interface to collect I2RS trace data. Correspondingly, retrieval of 432 the data should also be made vendor-agnostic. 434 Despite the fact that export of I2RS trace log information could be 435 an invaluable diagnostic tool for off-box analysis, exporting this 436 information MUST NOT interfere with the ability of the Agent to 437 process new incoming operations. 439 The following three sections describe potential ways the trace log 440 can be accessed. At least one of these three MUST be used, with the 441 I2RS mechanisms being preferred as they are vendor-independent 442 approaches to retrieving the data. 444 7.4.1. Retrieval Via Syslog 446 The syslog protocol [RFC5424] is a standard way of sending event 447 notification messages from a host to a collector. However, the 448 protocol does not define any standard format for storing the 449 messages, and thus implementors of I2RS tracing would be left to 450 define their own format. So, while the data contained within the 451 syslog message would adhere to this information model, and may be 452 consumable by a human operator, it would not be easily parseable by a 453 machine. Therefore, syslog MAY be employed as a means of retrieving 454 or disseminating the I2RS trace log contents. 456 If syslog is used for trace log retrieval, then existing logging 457 infrastructure and capabilities of syslog [RFC5424] should be 458 leveraged without the need to define or extend existing formats. For 459 example, the various fields described in Section 5.2 SHOULD be 460 modeled and encoded as Structured Data Elements (referred to as "SD- 461 ELEMENT"), as described in Section 6.3.1 of [RFC5424]. 463 7.4.2. Retrieval Via I2RS Information Collection 465 Section 6.7 of the I2RS architecture [I-D.ietf-i2rs-architecture] 466 defines a mechanism for information collection. The information 467 collected includes obtaining a snapshot of a large amount of data 468 from the network element. It is the intent of I2RS to make this data 469 available in an implementor-agnostic fashion. Therefore, the I2RS 470 trace log SHOULD be made available via the I2RS information 471 collection mechanism either as a single snapshot or via a 472 subscription stream. 474 7.4.3. Retrieval Via I2RS Pub-Sub 476 Section 6.7 of the I2RS architecture [I-D.ietf-i2rs-architecture] 477 goes on to define a publish-subscribe mechanism for a feed of changes 478 happening within the I2RS layer. I2RS Agents SHOULD support 479 publishing I2RS trace log information to that feed as described in 480 that document. Subscribers would then receive a live stream of I2RS 481 interactions in trace log format and could flexibly choose to do a 482 number of things with the log messages. For example, the subscribers 483 could log the messages to a datastore, aggregate and summarize 484 interactions from a single Client, etc. Using pub-sub for the 485 purpose of logging I2RS interactions augments the areas described by 486 [I-D.camwinget-i2rs-pubsub-sec]. The full range of potential 487 activites is virtually limitless and the details of how they are 488 performed are outside the scope of this document, however. 490 8. IANA Considerations 492 This document makes no request of IANA. 494 9. Security Considerations 496 The I2RS trace log, like any log file, reveals the state of the 497 entity producing it as well as the identifying information elements 498 and detailed interactions of the system containing it. The 499 information model described in this document does not itself 500 introduce any security issues, but it does define the set of 501 attributes that make up an I2RS log file. These attributes may 502 contain sensitive information and thus should adhere to the security, 503 privacy and permission policies of the organization making use of the 504 I2RS log file. 506 It is outside the scope of this document to specify how to protect 507 the stored log file, but it is expected that adequate precautions and 508 security best practices such as disk encryption, appropriately 509 restrictive file/directory permissions, suitable hardening and 510 physical security of logging entities, mutual authentication, 511 transport encryption, channel confidentiality, and channel integrity 512 if transferring log files. Additionally, the potentially sensitive 513 information contained in a log file SHOULD be adequately anonymized 514 or obfuscated by operators to ensure its privacy. 516 10. Acknowledgments 518 The authors would like to thank Alia Atlas for her initial feedback 519 and overall support for this work. Additionally, the authors 520 acknowledge Alvaro Retana, Russ White, Matt Birkner, Jeff Haas, Joel 521 Halpern, Dean Bogdanovich, Ignas Bagdonas, Nobo Akiya, Kwang-koog 522 Lee, and Alex Clemm for their reviews, contributed text, and 523 suggested improvements to this document. 525 11. References 526 11.1. Normative References 528 [I-D.ietf-i2rs-architecture] 529 Atlas, A., Halpern, J., Hares, S., Ward, D., and T. 530 Nadeau, "An Architecture for the Interface to the Routing 531 System", draft-ietf-i2rs-architecture-07 (work in 532 progress), December 2014. 534 [I-D.ietf-i2rs-problem-statement] 535 Atlas, A., Nadeau, T., and D. Ward, "Interface to the 536 Routing System Problem Statement", draft-ietf-i2rs- 537 problem-statement-04 (work in progress), June 2014. 539 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 540 Requirement Levels", BCP 14, RFC 2119, March 1997. 542 11.2. Informative References 544 [I-D.camwinget-i2rs-pubsub-sec] 545 Beck, K., Cam-Winget, N., and D. McGrew, "Using the 546 Publish-Subscribe Model in the Interface to the Routing 547 System", draft-camwinget-i2rs-pubsub-sec-00 (work in 548 progress), July 2013. 550 [I-D.nitinb-i2rs-rib-info-model] 551 Bahadur, N., Folkes, R., Kini, S., and J. Medved, "Routing 552 Information Base Info Model", draft-nitinb-i2rs-rib-info- 553 model-02 (work in progress), August 2013. 555 [RFC3339] Klyne, G., Ed. and C. Newman, "Date and Time on the 556 Internet: Timestamps", RFC 3339, July 2002. 558 [RFC5424] Gerhards, R., "The Syslog Protocol", RFC 5424, March 2009. 560 [RFC5737] Arkko, J., Cotton, M., and L. Vegoda, "IPv4 Address Blocks 561 Reserved for Documentation", RFC 5737, January 2010. 563 [RFC6536] Bierman, A. and M. Bjorklund, "Network Configuration 564 Protocol (NETCONF) Access Control Model", RFC 6536, March 565 2012. 567 Authors' Addresses 568 Joe Clarke 569 Cisco Systems, Inc. 570 7200-12 Kit Creek Road 571 Research Triangle Park, NC 27709 572 US 574 Phone: +1-919-392-2867 575 Email: jclarke@cisco.com 577 Gonzalo Salgueiro 578 Cisco Systems, Inc. 579 7200-12 Kit Creek Road 580 Research Triangle Park, NC 27709 581 US 583 Email: gsalguei@cisco.com 585 Carlos Pignataro 586 Cisco Systems, Inc. 587 7200-12 Kit Creek Road 588 Research Triangle Park, NC 27709 589 US 591 Email: cpignata@cisco.com