idnits 2.17.1 draft-gandhi-ippm-stamp-srpm-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 (February 10, 2021) is 1142 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: 'IEEE802.1AX' is mentioned on line 153, but not defined == Outdated reference: A later version (-22) exists of draft-ietf-spring-segment-routing-policy-09 == Outdated reference: A later version (-16) exists of draft-ietf-pce-binding-label-sid-05 Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IPPM Working Group R. Gandhi, Ed. 3 Internet-Draft C. Filsfils 4 Intended status: Standards Track Cisco Systems, Inc. 5 Expires: August 14, 2021 D. Voyer 6 Bell Canada 7 M. Chen 8 Huawei 9 B. Janssens 10 Colt 11 February 10, 2021 13 Simple TWAMP (STAMP) Extensions for Segment Routing Networks 14 draft-gandhi-ippm-stamp-srpm-02 16 Abstract 18 Segment Routing (SR) leverages the source routing paradigm. SR is 19 applicable to both Multiprotocol Label Switching (SR-MPLS) and IPv6 20 (SRv6) data planes. This document specifies RFC 8762 (Simple Two-Way 21 Active Measurement Protocol (STAMP)) extensions for SR networks, for 22 both SR-MPLS and SRv6 data planes. 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 August 14, 2021. 41 Copyright Notice 43 Copyright (c) 2021 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 Used in This Document . . . . . . . . . . . . . . 3 60 2.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 61 2.2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 3 62 2.3. Reference Topology . . . . . . . . . . . . . . . . . . . 4 63 3. Destination Node Address TLV . . . . . . . . . . . . . . . . 4 64 4. Return Path TLV . . . . . . . . . . . . . . . . . . . . . . . 5 65 4.1. Return Path Sub-TLVs . . . . . . . . . . . . . . . . . . 6 66 4.1.1. Return Path Control Code Sub-TLV . . . . . . . . . . 6 67 4.1.2. Return Address Sub-TLV . . . . . . . . . . . . . . . 7 68 4.1.3. Return Segment List Sub-TLVs . . . . . . . . . . . . 8 69 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 70 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 71 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 72 7.1. Normative References . . . . . . . . . . . . . . . . . . 10 73 7.2. Informative References . . . . . . . . . . . . . . . . . 11 74 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 11 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 77 1. Introduction 79 Segment Routing (SR) leverages the source routing paradigm and 80 greatly simplifies network operations for Software Defined Networks 81 (SDNs). SR is applicable to both Multiprotocol Label Switching (SR- 82 MPLS) and IPv6 (SRv6) data planes [RFC8402]. SR Policies as defined 83 in [I-D.ietf-spring-segment-routing-policy] are used to steer traffic 84 through a specific, user-defined paths using a stack of Segments. 85 Built-in SR Performance Measurement (PM) is one of the essential 86 requirements to provide Service Level Agreements (SLAs). 88 The Simple Two-way Active Measurement Protocol (STAMP) provides 89 capabilities for the measurement of various performance metrics in IP 90 networks [RFC8762]. It eliminates the need for control protocol by 91 using configuration and management model to provision and manage test 92 sessions. [RFC8972] defines optional extensions for STAMP. 94 The STAMP supports two modes of STAMP Session-Reflector: Stateless 95 and Stateful as described in Section 4 of [RFC8762]. In Stateless 96 mode, maintenance of each STAMP test session on Session-Reflector is 97 avoided. In SR networks, as the state is in the packet, the 98 signaling of the parameters and creating extra states in the network 99 are undesired. Hence, Stateless mode of Session-Reflector is 100 preferred in SR networks. 102 For performance delay and packet loss measurement, STAMP Session- 103 Sender test packets are transmitted in-band on the same path as the 104 data traffic flow under measurement to measure the delay and packet 105 loss experienced by the data traffic flow. It is also desired in SR 106 networks that the Session-Reflector reply test packets are 107 transmitted in-band on the same path in the reverse direction. This 108 is achieved by using the STAMP extensions defined in this document. 110 This document specifies RFC 8762 (Simple Two-Way Active Measurement 111 Protocol (STAMP)) extensions for SR networks, for both SR-MPLS and 112 SRv6 data planes. 114 2. Conventions Used in This Document 116 2.1. Requirements Language 118 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 119 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 120 document are to be interpreted as described in [RFC2119] [RFC8174] 121 when, and only when, they appear in all capitals, as shown here. 123 2.2. Abbreviations 125 MPLS: Multiprotocol Label Switching. 127 PM: Performance Measurement. 129 SID: Segment ID. 131 SL: Segment List. 133 SR: Segment Routing. 135 SR-MPLS: Segment Routing with MPLS data plane. 137 SRv6: Segment Routing with IPv6 data plane. 139 SSID: STAMP Session Identifier. 141 STAMP: Simple Two-way Active Measurement Protocol. 143 2.3. Reference Topology 145 In the reference topology shown below, the STAMP Session-Sender R1 146 initiates a STAMP test packet and the STAMP Session-Reflector R3 147 transmits a reply test packet. The reply test packet is transmitted 148 back to the STAMP Session-Sender R1 on the same path or a different 149 path in the reverse direction. 151 The nodes R1 and R3 may be connected via a link or there exists an SR 152 path [RFC8402]. The link may be a physical interface, virtual link, 153 or Link Aggregation Group (LAG) [IEEE802.1AX], or LAG member link. 154 The SR path may be an SR Policy 155 [I-D.ietf-spring-segment-routing-policy] on node R1 (called head-end) 156 with destination to node R3 (called tail-end). 158 T1 T2 159 / \ 160 +-------+ Test Packet +-------+ 161 | | - - - - - - - - - ->| | 162 | R1 |=====================| R3 | 163 | |<- - - - - - - - - - | | 164 +-------+ Reply Test Packet +-------+ 165 \ / 166 T4 T3 168 STAMP Session-Sender STAMP Session-Reflector 170 Reference Topology 172 3. Destination Node Address TLV 174 The STAMP Session-Sender may need to transmit test packets to the 175 STAMP Session-Reflector with a different destination address (for 176 example IPv4 address from 127/8 range). In an error condition, the 177 STAMP test packet may not reach the intended STAMP Session-Reflector, 178 an un-intended node may transmit reply test packets resulting in 179 reporting of invalid measurement metrics. 181 [RFC8972] defines STAMP test packets that can include one or more 182 optional TLVs. In this document, Destination Node Address TLV (Type 183 TBA1) is defined for STAMP test packet [RFC8972] and has the 184 following format shown in Figure 1: 186 0 1 2 3 187 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 188 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 189 |STAMP TLV Flags| Type=TBA1 | Length | 190 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 191 | Reserved | Address Family | 192 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 193 . Address . 194 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 196 Figure 1: Destination Node Address TLV Format 198 The Address Family field indicates the type of the address, and it 199 SHALL be set to one of the assigned values in the "IANA Address 200 Family Numbers" registry. 202 The STAMP TLV Flags are set using the procedures described in 203 [RFC8972]. 205 The Destination Node Address TLV is optional. The Destination Node 206 Address TLV indicates the address of the intended destination node of 207 the test packet. The STAMP Session-Reflector that supports this TLV, 208 MUST NOT transmit reply test packet if it is not the intended 209 destination node of the received test packet. 211 4. Return Path TLV 213 For end-to-end SR paths, the STAMP Session-Reflector may need to 214 transmit the reply test packet on a specific return path. The STAMP 215 Session-Sender can request this in the test packet to the STAMP 216 Session-Reflector using a Return Path TLV. With this TLV carried in 217 the STAMP Session-Sender test packet, the STAMP Session-Reflector 218 (Stateless mode) does not require signaling and maintaining any 219 additional dynamic state for the STAMP sessions for the end-to-end SR 220 paths. 222 For links, the STAMP Session-Reflector may need to transmit the reply 223 test packet on the same incoming link in the reverse direction. The 224 STAMP Session-Sender can request this in the test packet to the STAMP 225 Session-Reflector using a Return Path TLV. With this TLV carried in 226 the STAMP Session-Sender test packet, the STAMP Session-Reflector 227 (Stateless mode) does not require maintenance of any additional state 228 for the STAMP sessions for the links. 230 [RFC8972] defines STAMP test packets that can include one or more 231 optional TLVs. In this document, the TLV Type (value TBA2) is 232 defined for the Return Path TLV that carries the return path for the 233 STAMP Session-Sender test packet. The format of the Return Path TLV 234 is shown in Figure 2: 236 0 1 2 3 237 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 238 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 239 |STAMP TLV Flags| Type=TBA2 | Length | 240 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 241 | Return Path Sub-TLVs | 242 . . 243 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 245 Figure 2: Return Path TLV 247 The STAMP TLV Flags are set using the procedures described in 248 [RFC8972]. 250 The Return Path TLV is optional. The STAMP Session-Sender MUST only 251 insert one Return Path TLV in the STAMP test packet. The STAMP 252 Session-Reflector that supports this TLV, MUST only process the first 253 Return Path TLV in the test packet and ignore other Return Path TLVs 254 if present, and it MUST NOT add Return Path TLV in the reply test 255 packet. 257 4.1. Return Path Sub-TLVs 259 The Return Path TLV contains one or more Sub-TLVs to carry the 260 information for the requested return path. A Return Path Sub-TLV can 261 either carry Return Path Control Code, Return Path IP Address or 262 Return Path Segment List. 264 The STAMP Sub-TLV Flags are set using the procedures described in 265 [RFC8972]. 267 When Return Path Sub-TLV is present in the Session-Sender test 268 packet, the STAMP Session-Reflector that supports this TLV, MUST 269 transmit reply test packet using the return path information 270 specified in the Return Path Sub-TLV. 272 4.1.1. Return Path Control Code Sub-TLV 274 The format of the Return Path Control Code Sub-TLV is shown in 275 Figure 3. The Type of the Return Path Control Code Sub-TLV is 276 defined as following: 278 o Type (value 1): Return Path Control Code. The STAMP Session- 279 Sender can request the STAMP Session-Reflector to transmit the 280 reply test packet based on the flags defined in the Control Code 281 field. 283 0 1 2 3 284 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 285 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 286 |STAMP TLV Flags| Type | Length | 287 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 288 | Control Code | 289 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 291 Figure 3: Control Code Sub-TLV in Return Path TLV 293 Control Code Flags (32-bit): Defined as follows. 295 0x0: No Reply Requested. 297 0x1: In-band Reply Requested. 299 When Control Code flag is set to 0x0 in the STAMP Session-Sender test 300 packet, the Session-Reflector does not transmit reply test packet to 301 the Session-Sender and terminates the STAMP test packet. Optionally, 302 the Session-Reflector may locally stream performance metrics via 303 telemetry using the information from the received test packet. All 304 other Return Path Sub-TLVs are ignored in this case. 306 When Control Code flag is set to 0x1 in the STAMP Session-Sender test 307 packet, the Session-Reflector transmits the reply test packet in-band 308 over the same incoming link where the test packet is received in the 309 reverse direction. 311 4.1.2. Return Address Sub-TLV 313 The STAMP reply test packet may be transmitted to a different node 314 than the Session-Sender (e.g. to a controller for telemetry use- 315 cases). For this, the Session-Sender can specify in the test packet 316 the receiving destination node address for the Session-Reflector 317 reply test packet. 319 The format of the Return Address Sub-TLV is shown in Figure 4. The 320 Address Family field indicates the type of the address, and it SHALL 321 be set to one of the assigned values in the "IANA Address Family 322 Numbers" registry. The Type of the Return Address Sub-TLV is defined 323 as following: 325 o Type (value 2): Return Address. Destination node address of the 326 STAMP Session-Reflector reply test packet different than the 327 Source Address in the Session-Sender test packet. 329 0 1 2 3 330 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 331 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 332 |STAMP TLV Flags| Type | Length | 333 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 334 | Reserved | Address Family | 335 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 336 . Address . 337 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 339 Figure 4: Return Address Sub-TLV in Return Path TLV 341 4.1.3. Return Segment List Sub-TLVs 343 The format of the Segment List Sub-TLVs in the Return Path TLV is 344 shown in Figure 5. The segment entries MUST be in network order. 345 The Segment List Sub-TLV can be one of the following Types: 347 o Type (value 3): SR-MPLS Label Stack of the Return Path 349 o Type (value 4): SR-MPLS Binding SID 350 [I-D.ietf-pce-binding-label-sid] of the Return SR Policy 352 o Type (value 5): SRv6 Segment List of the Return Path 354 o Type (value 6): SRv6 Binding SID [I-D.ietf-pce-binding-label-sid] 355 of the Return SR Policy 357 0 1 2 3 358 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 359 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 360 |STAMP TLV Flags| Type | Length | 361 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 362 | Segment(1) | 363 . . 364 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 365 . . 366 . . 367 . . 368 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 369 | Segment(n) (bottom of stack) | 370 . . 371 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 373 Figure 5: Segment List Sub-TLV in Return Path TLV 375 The STAMP Session-Sender MUST only insert one Segment List Return 376 Path Sub-TLV in the test packet. The STAMP Session-Reflector MUST 377 only process the first Segment List Return Path Sub-TLV in the test 378 packet and ignore other Segment List Return Path Sub-TLVs if present. 380 5. Security Considerations 382 The performance measurement is intended for deployment in well- 383 managed private and service provider networks. As such, it assumes 384 that a node involved in a measurement operation has previously 385 verified the integrity of the path and the identity of the STAMP 386 Session-Reflector. 388 If desired, attacks can be mitigated by performing basic validation 389 and sanity checks, at the STAMP Session-Sender, of the timestamp 390 fields in received measurement reply packets. The minimal state 391 associated with these protocols also limits the extent of measurement 392 disruption that can be caused by a corrupt or invalid packet to a 393 single test cycle. 395 The security considerations specified in [RFC8762] and [RFC8972] also 396 apply to the extensions defined in this document. 398 6. IANA Considerations 400 IANA will create a "STAMP TLV Type" registry for [RFC8972]. IANA is 401 requested to allocate a value for the following Destination Address 402 TLV Type from the IETF Review TLV range of this registry. This TLV 403 is to be carried in the STAMP test packets. 405 o Type TBA1: Destination Node Address TLV 407 IANA is also requested to allocate a value for the following Return 408 Path TLV Type from the IETF Review TLV range of the same registry. 409 This TLV is to be carried in the STAMP test packets. 411 o Type TBA2: Return Path TLV 413 IANA is requested to create a sub-registry for "Return Path Sub-TLV 414 Type". All code points in the range 1 through 175 in this registry 415 shall be allocated according to the "IETF Review" procedure as 416 specified in [RFC8126]. Code points in the range 176 through 239 in 417 this registry shall be allocated according to the "First Come First 418 Served" procedure as specified in [RFC8126]. Remaining code points 419 are allocated according to Table 1: 421 +-----------+--------------+---------------+ 422 | Value | Description | Reference | 423 +-----------+--------------+---------------+ 424 | 0 | Reserved | This document | 425 | 1 - 175 | Unassigned | This document | 426 | 176 - 239 | Unassigned | This document | 427 | 240 - 251 | Experimental | This document | 428 | 252 - 254 | Private Use | This document | 429 | 255 | Reserved | This document | 430 +-----------+--------------+---------------+ 432 Table 1: Return Path Sub-TLV Type Registry 434 IANA is requested to allocate the values for the following Sub-TLV 435 Types from this registry. 437 o Type (value 1): Return Path Control Code 439 o Type (value 2): Return Address 441 o Type (value 3): SR-MPLS Label Stack of the Return Path 443 o Type (value 4): SR-MPLS Binding SID of the Return SR Policy 445 o Type (value 5): SRv6 Segment List of the Return Path 447 o Type (value 6): SRv6 Binding SID of the Return SR Policy 449 7. References 451 7.1. Normative References 453 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 454 Requirement Levels", BCP 14, RFC 2119, 455 DOI 10.17487/RFC2119, March 1997, 456 . 458 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 459 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 460 May 2017, . 462 [RFC8762] Mirsky, G., Jun, G., Nydell, H., and R. Foote, "Simple 463 Two-Way Active Measurement Protocol", RFC 8762, 464 DOI 10.17487/RFC8762, March 2020, 465 . 467 [RFC8972] Mirsky, G., Min, X., Nydell, H., Foote, R., Masputra, A., 468 and E. Ruffini, "Simple Two-Way Active Measurement 469 Protocol Optional Extensions", RFC 8972, 470 DOI 10.17487/RFC8972, January 2021, 471 . 473 7.2. Informative References 475 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 476 Decraene, B., Litkowski, S., and R. Shakir, "Segment 477 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 478 July 2018, . 480 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 481 Writing an IANA Considerations Section in RFCs", BCP 26, 482 RFC 8126, DOI 10.17487/RFC8126, June 2017, 483 . 485 [I-D.ietf-spring-segment-routing-policy] 486 Filsfils, C., Talaulikar, K., Voyer, D., Bogdanov, A., and 487 P. Mattes, "Segment Routing Policy Architecture", draft- 488 ietf-spring-segment-routing-policy-09 (work in progress), 489 November 2020. 491 [I-D.ietf-pce-binding-label-sid] 492 Sivabalan, S., Filsfils, C., Tantsura, J., Hardwick, J., 493 Previdi, S., and C. Li, "Carrying Binding Label/Segment-ID 494 in PCE-based Networks.", draft-ietf-pce-binding-label- 495 sid-05 (work in progress), October 2020. 497 Acknowledgments 499 The authors would like to thank Thierry Couture for the discussions 500 on the use-cases for Performance Measurement in Segment Routing. The 501 authors would also like to thank Greg Mirsky, Mike Koldychev, Gyan 502 Mishra, Tianran Zhou, and Cheng Li for providing comments and 503 suggestions. 505 Authors' Addresses 507 Rakesh Gandhi (editor) 508 Cisco Systems, Inc. 509 Canada 511 Email: rgandhi@cisco.com 512 Clarence Filsfils 513 Cisco Systems, Inc. 515 Email: cfilsfil@cisco.com 517 Daniel Voyer 518 Bell Canada 520 Email: daniel.voyer@bell.ca 522 Mach(Guoyi) Chen 523 Huawei 525 Email: mach.chen@huawei.com 527 Bart Janssens 528 Colt 530 Email: Bart.Janssens@colt.net