idnits 2.17.1 draft-gandhi-mpls-ioam-sr-02.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 (March 17, 2020) is 1501 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) == Outdated reference: A later version (-17) exists of draft-ietf-ippm-ioam-data-09 == Outdated reference: A later version (-11) exists of draft-ietf-ippm-ioam-direct-export-00 == Outdated reference: A later version (-10) exists of draft-ietf-ippm-ioam-flags-01 == Outdated reference: A later version (-06) exists of draft-ietf-mpls-spl-terminology-01 == Outdated reference: A later version (-22) exists of draft-ietf-spring-mpls-path-segment-02 Summary: 0 errors (**), 0 flaws (~~), 6 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MPLS Working Group R. Gandhi, Ed. 3 Internet-Draft Z. Ali 4 Intended status: Standards Track C. Filsfils 5 Expires: September 18, 2020 F. Brockners 6 Cisco Systems, Inc. 7 B. Wen 8 V. Kozak 9 Comcast 10 March 17, 2020 12 MPLS Data Plane Encapsulation for In-situ OAM Data 13 draft-gandhi-mpls-ioam-sr-02 15 Abstract 17 In-situ Operations, Administration, and Maintenance (IOAM) records 18 operational and telemetry information in the data packet while the 19 packet traverses a path between two nodes in the network. This 20 document defines how IOAM data fields are transported using the MPLS 21 data plane encapsulation, including Segment Routing (SR) with MPLS 22 data plane (SR-MPLS). 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 https://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 September 18, 2020. 41 Copyright Notice 43 Copyright (c) 2020 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 (https://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. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 59 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 2.1. Requirement Language . . . . . . . . . . . . . . . . . . 3 61 2.2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 3 62 3. IOAM Data Field Encapsulation in MPLS Header . . . . . . . . 3 63 3.1. Indicator Labels . . . . . . . . . . . . . . . . . . . . 5 64 4. Procedure for Edge-to-Edge IOAM . . . . . . . . . . . . . . . 5 65 4.1. Edge-to-Edge IOAM Indicator Label Allocation . . . . . . 6 66 5. Procedure for Hop-by-Hop IOAM . . . . . . . . . . . . . . . . 6 67 5.1. Hop-by-Hop IOAM Indicator Label Allocation . . . . . . . 7 68 6. Considerations for ECMP . . . . . . . . . . . . . . . . . . . 7 69 7. Node Capability . . . . . . . . . . . . . . . . . . . . . . . 8 70 8. Data Packets with SR-MPLS Header . . . . . . . . . . . . . . 8 71 9. Security Considerations . . . . . . . . . . . . . . . . . . . 9 72 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 73 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 74 11.1. Normative References . . . . . . . . . . . . . . . . . . 10 75 11.2. Informative References . . . . . . . . . . . . . . . . . 11 76 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 11 77 Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 11 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 80 1. Introduction 82 In-situ Operations, Administration, and Maintenance (IOAM) records 83 operational and telemetry information within the packet while the 84 packet traverses a particular network domain. The term "in-situ" 85 refers to the fact that the IOAM data fields are added to the data 86 packets rather than being sent within the probe packets specifically 87 dedicated to OAM or Performance Measurement (PM). The IOAM data 88 fields are defined in [I-D.ietf-ippm-ioam-data], and can be used for 89 various use-cases for OAM and PM. The IOAM data fields are further 90 updated in [I-D.ietf-ippm-ioam-direct-export] for direct export use- 91 cases and in [I-D.ietf-ippm-ioam-flags] for Loopback and Active 92 flags. 94 This document defines how IOAM data fields are transported using the 95 MPLS data plane encapsulations, including Segment Routing (SR) with 96 MPLS data plane (SR-MPLS). 98 2. Conventions 100 2.1. Requirement Language 102 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 103 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 104 document are to be interpreted as described in [RFC2119] [RFC8174] 105 when, and only when, they appear in all capitals, as shown here. 107 2.2. Abbreviations 109 Abbreviations used in this document: 111 ECMP Equal Cost Multi-Path 113 IOAM In-situ Operations, Administration, and Maintenance 115 MPLS Multiprotocol Label Switching 117 OAM Operations, Administration, and Maintenance 119 PM Performance Measurement 121 POT Proof-of-Transit 123 PSID Path Segment Identifier 125 SR Segment Routing 127 SR-MPLS Segment Routing with MPLS Data plane 129 3. IOAM Data Field Encapsulation in MPLS Header 131 The IOAM data fields defined in [I-D.ietf-ippm-ioam-data] are used. 132 IOAM data fields are carried in the MPLS header as shown in Figure 1 133 and Figure 2. More than one trace options can be present in the IOAM 134 data fields. The Indicator Label is added at the bottom of the MPLS 135 label stack (S flag set to 1) to indicate the presence of the IOAM 136 data field(s) in the MPLS header. 138 The data packets with IOAM data fields carry only one Indicator Label 139 in the MPLS header. Any intermediate node that adds additional MPLS 140 encapsulation in the MPLS header may further update the IOAM data 141 fields in the header without inserting another Indicator Label. 143 0 1 2 3 144 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 145 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 146 | IOAM Indicator Label | TC |1| TTL | 147 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<-+ 148 | IOAM-Type | IOAM HDR LEN | RESERVED | | 149 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ I 150 | | O 151 | | A 152 ~ IOAM Option and Data Space ~ M 153 | | | 154 | | | 155 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<-+ 156 | | 157 | | 158 | Payload + Padding | 159 | | 160 | | 161 | | 162 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 164 Figure 1: IOAM Encapsulation in MPLS Header 166 0 1 2 3 167 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 168 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 169 | IOAM and Flow Indicator Label | TC |1| TTL | 170 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 171 |0 0 0 0| Flow label | Block Number | 172 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<-+ 173 | IOAM-Type | IOAM HDR LEN | RESERVED | | 174 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ I 175 | | O 176 | | A 177 ~ IOAM Option and Data Space ~ M 178 | | | 179 | | | 180 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<-+ 181 | | 182 | | 183 | Payload + Padding | 184 | | 185 | | 186 | | 187 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 189 Figure 2: IOAM Encapsulation with Flow Label in MPLS Header 191 IOAM Indicator Label (IIL) and IOAM and Flow Indicator Label (IFIL) 192 used are defined in this document. 194 The fields related to the encapsulation of IOAM data fields in the 195 MPLS header are defined as follows: 197 IOAM-Type: 8-bit field defining the IOAM Option type, as defined in 198 Section 7.2 of [I-D.ietf-ippm-ioam-data]. 200 IOAM HDR LEN: 8-bit unsigned integer. Length of the IOAM HDR in 201 4-octet units. 203 RESERVED: 8-bit reserved field MUST be set to zero upon transmission 204 and ignored upon receipt. 206 IOAM Option and Data Space: IOAM option header and data is present 207 as defined by the IOAM-Type field, and is defined in Section 4 of 208 [I-D.ietf-ippm-ioam-data]. 210 3.1. Indicator Labels 212 IOAM Indicator Label (value TBA1 or TBA3) and IOAM and Flow Indicator 213 Label (value TBA2 or TBA4) are used to indicate the presence of the 214 IOAM data field in the MPLS header. 216 The IOAM and Flow Indicator Label (value TBA2 or TBA4) is used to 217 carry a second label underneath with protocol value 0000b, 20-bit 218 Flow Label and 8-bit Block Number. 220 o The protocol value 0000b allows to avoid incorrect IP header-based 221 hashing over ECMP paths that uses the value 0x4 (for IPv4) and 222 value 0x6 (for IPv6) [RFC4928]. 224 o The Flow Label identifies the traffic flow that can be used for 225 IOAM purpose, e.g. monitoring a specific traffic flow for latency. 227 o The Block Number can be used to aggregate the IOAM data collected 228 in data plane, e.g. compute measurement metrics for each block of 229 a flow. 231 4. Procedure for Edge-to-Edge IOAM 233 The Edge-to-Edge (E2E) IOAM includes IOAM Option-Type as Edge-to-Edge 234 Option-Type [I-D.ietf-ippm-ioam-data]. This section summarizes the 235 procedure for data encapsulation and decapsulation for Edge-to-Edge 236 IOAM in MPLS header. 238 o The encapsulating node inserts the IOAM Indicator Label or IOAM 239 Flow Indicator Label with Flow Label and one or more IOAM data 240 field(s) in the MPLS header. The procedure to generate the Flow 241 Label is outside the scope of this document. 243 o The decapsulating node "forwards and punts the timestamped copy" 244 of the data packet including IOAM data fields when the node 245 recognizes the IOAM Indicator Label and IOAM Flow Indicator Label. 246 The copy of the data packet is punted to the slow path for OAM 247 processing and is not necessarily punted to the control-plane. 248 The receive timestamp is required by various E2E OAM use-cases. 250 o The decapsulating node processes the IOAM data field(s) using the 251 procedures defined in [I-D.ietf-ippm-ioam-data]. An example of 252 IOAM processing may be to export the data fields, send data fields 253 via Telemetry, etc. 255 o The decapsulating node also pops the Indicator Label and the IOAM 256 data fields from the MPLS header. 258 4.1. Edge-to-Edge IOAM Indicator Label Allocation 260 IOAM Indicator Label (value TBA1) and IOAM and Flow Indicator Label 261 (value TBA2) are used to indicate the presence of the E2E IOAM data 262 field in the MPLS header. The E2E IOAM Indicator Label and IOAM and 263 Flow Indicator Label can be allocated using one of the following 264 methods: 266 o Labels assigned by IANA with value TBA1 and TBA2 from the Extended 267 Special-Purpose MPLS Values [I-D.ietf-mpls-spl-terminology]. 269 o Labels allocated by a Controller from the global table of the 270 decapsulating node. The Controller provisions the label on both 271 encapsulating and decapsulating nodes. 273 o Labels allocated by the decapsulating node. The signaling 274 extension for this is outside the scope of this document. 276 5. Procedure for Hop-by-Hop IOAM 278 The Hop-by-Hop (HbH) IOAM includes IOAM Option-Types IOAM Pre- 279 allocated Trace Option-Type, IOAM Incremental Trace Option-Type and 280 IOAM Proof of Transit (POT) Option-Type [I-D.ietf-ippm-ioam-data]. 281 This section summarizes the procedure for data encapsulation and 282 decapsulation for Hop-by-hop IOAM in MPLS header. 284 o The encapsulating node inserts the IOAM Indicator Label or IOAM 285 Flow Indicator Label with Flow Label and one or more IOAM data 286 field(s) in the MPLS header. The procedure to generate the Flow 287 Label is outside the scope of this document. 289 o The intermediate and decapsulating node enabled with IOAM 290 functions "forwards and punts the timestamped copy" of the data 291 packet including IOAM data fields when the node recognizes the 292 IOAM Indicator Label and IOAM Flow Indicator Label. The copy of 293 the data packet is punted to the slow path for OAM processing and 294 is not necessarily punted to the control-plane. The receive 295 timestamp is required by various hop-by-hop OAM use-cases. 297 o The intermediate and decapsulating node processes the IOAM data 298 field(s) using the procedures defined in 299 [I-D.ietf-ippm-ioam-data]. An example of IOAM processing may be 300 to export the data fields, send data fields via Telemetry, etc. 302 o The decapsulating node pops the Indicator Label and the IOAM data 303 fields from the MPLS header. 305 5.1. Hop-by-Hop IOAM Indicator Label Allocation 307 IOAM Indicator Label (value TBA3) and IOAM and Flow Indicator Label 308 (value TBA4) are used to indicate the presence of the HbH IOAM data 309 field in the MPLS header. The HbH IOAM Indicator Label and IOAM and 310 Flow Indicator Label can be allocated using one of the following 311 methods: 313 o Labels assigned by IANA with value TBA3 and TBA4 from the Extended 314 Special-Purpose MPLS Values [I-D.ietf-mpls-spl-terminology]. 316 o Labels allocated by a Controller from the network-wide global 317 table. The Controller provisions the labels on all nodes 318 participating in IOAM functions along the data traffic path. 320 6. Considerations for ECMP 322 The encapsulating node needs to make sure the IOAM data field does 323 not start with a well known IP protocol value (e.g. 0x4 for IPv4 and 324 0x6 for IPv6) as it can alter the hashing function for ECMP that uses 325 the IP header. This can be achieved by using the IOAM and Flow 326 Indicator Label (value TBA2 and TBA4) that follows by protocol value 327 0000b. This approach is consistent with utilizing 0000b as the first 328 nibble after the MPLS label stack, as described in [RFC4928] 329 [RFC4385]. 331 Note that the hashing function for ECMP that uses the labels from the 332 MPLS header may now include the Indicator Label. 334 When entropy label [RFC6790] is used for hashing function for ECMP, 335 the procedure defined in this document does not alter the hashing 336 function. 338 7. Node Capability 340 The decapsulating node that has to pop the Indicator Label, data 341 fields, and perform the IOAM function may not be capable of 342 supporting it. The encapsulating node needs to know if the 343 decapsulating node can support the IOAM function. The signaling 344 extension for this capability exchange is outside the scope of this 345 document. 347 The intermediate node that is not capable of supporting the IOAM 348 functions defined in this document, can simply skip the IOAM 349 processing of the MPLS header. 351 8. Data Packets with SR-MPLS Header 353 Segment Routing (SR) technology leverages the source routing paradigm 354 [RFC8660]. A node steers a packet through a controlled set of 355 instructions, called segments, by pre-pending the packet with an SR 356 header. In the SR with MPLS data plane (SR-MPLS), the SR header is 357 instantiated through a label stack. 359 An example of data packet carrying the SR-MPLS header with Path 360 Segment Identifier (PSID) [I-D.ietf-spring-mpls-path-segment] with 361 IOAM encapsulation is shown in Figure 3. The Path Segment Identifier 362 allows to identify the path associated with the data traffic being 363 monitored for IOAM on the decapsulating node. 365 0 1 2 3 366 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 367 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 368 | Label(1) | TC |S| TTL | 369 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 370 . . 371 . . 372 . . 373 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 374 | Label(n) | TC |S| TTL | 375 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 376 | PSID | TC |S| TTL | 377 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 378 | Packet as shown in Figure 1 or Figure 2 | 379 . . 380 +---------------------------------------------------------------+ 382 Figure 3: Data Packet with SR-MPLS Header 384 9. Security Considerations 386 The security considerations of SR-MPLS are discussed in [RFC8660], 387 and the security considerations of IOAM in general are discussed in 388 [I-D.ietf-ippm-ioam-data]. 390 IOAM is considered a "per domain" feature, where one or several 391 operators decide on leveraging and configuring IOAM according to 392 their needs. Still, operators need to properly secure the IOAM 393 domain to avoid malicious configuration and use, which could include 394 injecting malicious IOAM packets into a domain. 396 10. IANA Considerations 398 IANA maintains the "Special-Purpose Multiprotocol Label Switching 399 (MPLS) Label Values" registry (see ). IANA is requested to 401 allocate IOAM Indicator Label value and IOAM and Flow Indicator value 402 from the "Extended Special-Purpose MPLS Label Values" registry: 404 +--------+-----------------------------------+---------------+ 405 | Value | Description | Reference | 406 +--------+-----------------------------------+---------------+ 407 | TBA1 | E2E IOAM Indicator Label | This document | 408 +--------+-----------------------------------+---------------+ 409 | TBA2 | E2E IOAM and Flow Indicator Label | This document | 410 +--------+-----------------------------------+---------------+ 411 | TBA3 | HbH IOAM Indicator Label | This document | 412 +--------+-----------------------------------+---------------+ 413 | TBA4 | HbH IOAM and Flow Indicator Label | This document | 414 +--------+-----------------------------------+---------------+ 416 11. References 418 11.1. Normative References 420 [I-D.ietf-ippm-ioam-data] 421 Brockners, F., Bhandari, S., Pignataro, C., Gredler, H., 422 Leddy, J., Youell, S., Mizrahi, T., Mozes, D., Lapukhov, 423 P., remy@barefootnetworks.com, r., daniel.bernier@bell.ca, 424 d., and J. Lemon, "Data Fields for In-situ OAM", draft- 425 ietf-ippm-ioam-data-09 (work in progress), March 2020. 427 [I-D.ietf-ippm-ioam-direct-export] 428 Song, H., Gafni, B., Zhou, T., Li, Z., Brockners, F., 429 Bhandari, S., Sivakolundu, R., and T. Mizrahi, "In-situ 430 OAM Direct Exporting", draft-ietf-ippm-ioam-direct- 431 export-00 (work in progress), February 2020. 433 [I-D.ietf-ippm-ioam-flags] 434 Mizrahi, T., Brockners, F., Bhandari, S., Sivakolundu, R., 435 Pignataro, C., Kfir, A., Gafni, B., Spiegel, M., and J. 436 Lemon, "In-situ OAM Flags", draft-ietf-ippm-ioam-flags-01 437 (work in progress), January 2020. 439 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 440 Requirement Levels", BCP 14, RFC 2119, 441 DOI 10.17487/RFC2119, March 1997, 442 . 444 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 445 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 446 May 2017, . 448 [RFC8660] Bashandy, A., Ed., Filsfils, C., Ed., Previdi, S., 449 Decraene, B., Litkowski, S., and R. Shakir, "Segment 450 Routing with the MPLS Data Plane", RFC 8660, 451 DOI 10.17487/RFC8660, December 2019, 452 . 454 11.2. Informative References 456 [I-D.ietf-mpls-spl-terminology] 457 Andersson, L., Kompella, K., and A. Farrel, "Special 458 Purpose Label terminology", draft-ietf-mpls-spl- 459 terminology-01 (work in progress), November 2019. 461 [I-D.ietf-spring-mpls-path-segment] 462 Cheng, W., Li, H., Chen, M., Gandhi, R., and R. Zigler, 463 "Path Segment in MPLS Based Segment Routing Network", 464 draft-ietf-spring-mpls-path-segment-02 (work in progress), 465 February 2020. 467 [RFC4385] Bryant, S., Swallow, G., Martini, L., and D. McPherson, 468 "Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for 469 Use over an MPLS PSN", RFC 4385, DOI 10.17487/RFC4385, 470 February 2006, . 472 [RFC4928] Swallow, G., Bryant, S., and L. Andersson, "Avoiding Equal 473 Cost Multipath Treatment in MPLS Networks", BCP 128, 474 RFC 4928, DOI 10.17487/RFC4928, June 2007, 475 . 477 [RFC6790] Kompella, K., Drake, J., Amante, S., Henderickx, W., and 478 L. Yong, "The Use of Entropy Labels in MPLS Forwarding", 479 RFC 6790, DOI 10.17487/RFC6790, November 2012, 480 . 482 Acknowledgements 484 The authors would like to thank Patrick Khordoc, Shwetha Bhandari and 485 Vengada Prasad Govindan for the discussions on IOAM. The authors 486 would also like to thank Tarek Saad, Loa Andersson and Cheng Li for 487 providing many useful comments. 489 Contributors 490 Sagar Soni 491 Cisco Systems, Inc. 493 Email: sagsoni@cisco.com 495 Authors' Addresses 497 Rakesh Gandhi (editor) 498 Cisco Systems, Inc. 499 Canada 501 Email: rgandhi@cisco.com 503 Zafar Ali 504 Cisco Systems, Inc. 506 Email: zali@cisco.com 508 Clarence Filsfils 509 Cisco Systems, Inc. 510 Belgium 512 Email: cf@cisco.com 514 Frank Brockners 515 Cisco Systems, Inc. 516 Hansaallee 249, 3rd Floor 517 DUESSELDORF, NORDRHEIN-WESTFALEN 40549 518 Germany 520 Email: fbrockne@cisco.com 522 Bin Wen 523 Comcast 525 Email: Bin_Wen@cable.comcast.com 527 Voitek Kozak 528 Comcast 530 Email: Voitek_Kozak@comcast.com