idnits 2.17.1 draft-dawra-spring-bgp-sr-service-chaining-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 12 instances of too long lines in the document, the longest one being 4 characters in excess of 72. ** The abstract seems to contain references ([I-D.ietf-idr-segment-routing-te-policy], [RFC7752]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (October 30, 2017) is 2341 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) == Unused Reference: 'RFC4272' is defined on line 382, but no explicit reference was found in the text == Unused Reference: 'RFC4364' is defined on line 386, but no explicit reference was found in the text == Unused Reference: 'RFC6952' is defined on line 395, but no explicit reference was found in the text == Unused Reference: 'I-D.dawra-bgp-srv6-vpn' is defined on line 409, but no explicit reference was found in the text == Unused Reference: 'I-D.filsfils-spring-segment-routing-policy' is defined on line 418, but no explicit reference was found in the text == Unused Reference: 'I-D.filsfils-spring-srv6-network-programming' is defined on line 426, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-6man-segment-routing-header' is defined on line 437, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-bess-evpn-prefix-advertisement' is defined on line 445, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-idr-bgp-ls-segment-routing-ext' is defined on line 451, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-idr-bgp-prefix-sid' is defined on line 457, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-isis-segment-routing-extensions' is defined on line 469, but no explicit reference was found in the text == Unused Reference: 'RFC2119' is defined on line 482, but no explicit reference was found in the text == Unused Reference: 'RFC4271' is defined on line 487, but no explicit reference was found in the text == Unused Reference: 'RFC4659' is defined on line 492, but no explicit reference was found in the text == Unused Reference: 'RFC5549' is defined on line 497, but no explicit reference was found in the text == Outdated reference: A later version (-06) exists of draft-dawra-idr-bgpls-srv6-ext-00 ** Downref: Normative reference to an Informational RFC: RFC 4272 ** Downref: Normative reference to an Informational RFC: RFC 5706 ** Downref: Normative reference to an Informational RFC: RFC 6952 ** Obsolete normative reference: RFC 7752 (Obsoleted by RFC 9552) == Outdated reference: A later version (-06) exists of draft-filsfils-spring-segment-routing-policy-01 == Outdated reference: A later version (-07) exists of draft-filsfils-spring-srv6-network-programming-01 == Outdated reference: A later version (-26) exists of draft-ietf-6man-segment-routing-header-07 == Outdated reference: A later version (-11) exists of draft-ietf-bess-evpn-prefix-advertisement-08 == Outdated reference: A later version (-18) exists of draft-ietf-idr-bgp-ls-segment-routing-ext-03 == Outdated reference: A later version (-27) exists of draft-ietf-idr-bgp-prefix-sid-07 == Outdated reference: A later version (-26) exists of draft-ietf-idr-segment-routing-te-policy-00 == Outdated reference: A later version (-25) exists of draft-ietf-isis-segment-routing-extensions-13 == Outdated reference: A later version (-15) exists of draft-ietf-spring-segment-routing-13 -- Obsolete informational reference (is this intentional?): RFC 5549 (Obsoleted by RFC 8950) Summary: 6 errors (**), 0 flaws (~~), 27 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Inter-Domain Routing 3 Internet-Draft 4 Intended status: Standards Track G. Dawra, Ed. 5 Expires: May 3, 2018 C. Filsfils 6 Cisco Systems 7 D. Bernier 8 Bell Canada 9 H. Elmalky 10 Ericsson 11 X. Xu 12 Huawei 13 F. Clad 14 Cisco Systems 15 October 30, 2017 17 BGP Control Plane for Segment Routing based Service Chaining 18 draft-dawra-spring-bgp-sr-service-chaining-00 20 Abstract 22 The BGP Control Plane for the SR service-chaining solution is 23 consistent with the BGP Control Plane for the topological Segment 24 Routing Traffic Engineering (SR-TE) solution. 26 o BGP Link-State(BGP-LS) address-family/sub-address-family[RFC7752] 27 is used to discover service and topological characteristics from 28 the network. 30 o SR-TE policies[I-D.ietf-idr-segment-routing-te-policy] instantiate 31 source-routed policies that may mix service and topological 32 segments. 34 Status of This Memo 36 This Internet-Draft is submitted in full conformance with the 37 provisions of BCP 78 and BCP 79. 39 Internet-Drafts are working documents of the Internet Engineering 40 Task Force (IETF). Note that other groups may also distribute 41 working documents as Internet-Drafts. The list of current Internet- 42 Drafts is at https://datatracker.ietf.org/drafts/current/. 44 Internet-Drafts are draft documents valid for a maximum of six months 45 and may be updated, replaced, or obsoleted by other documents at any 46 time. It is inappropriate to use Internet-Drafts as reference 47 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on May 3, 2018. 50 Copyright Notice 52 Copyright (c) 2017 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (https://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 68 2. BGP-LS Extensions for Service Chaining . . . . . . . . . . . 3 69 3. Illustration . . . . . . . . . . . . . . . . . . . . . . . . 6 70 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 71 4.1. Service Type Table . . . . . . . . . . . . . . . . . . . 7 72 4.2. Segment routing function Identifier(SFI) . . . . . . . . 7 73 5. Manageability Considerations . . . . . . . . . . . . . . . . 8 74 6. Operational Considerations . . . . . . . . . . . . . . . . . 8 75 6.1. Operations . . . . . . . . . . . . . . . . . . . . . . . 8 76 7. Security Considerations . . . . . . . . . . . . . . . . . . . 8 77 8. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 8 78 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 79 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 80 10.1. Normative References . . . . . . . . . . . . . . . . . . 9 81 10.2. Informative References . . . . . . . . . . . . . . . . . 9 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 84 1. Introduction 86 Segments are introduced in the SR architecture 87 [I-D.ietf-spring-segment-routing]. Segment Routing based Service 88 chaining is well described in Section 6 of 89 [I-D.clad-spring-segment-routing-service-chaining] document with an 90 example network and services. 92 Let's extend the example to add a Segment Routing Controller (SR-C) 93 to the network, for the purpose of service discovery and SR policy 94 instantiation. 96 Let's consider the network represented in Figure 1 below where: 98 o A and B are two end hosts using IPv4. 100 o S1 is an SR-aware firewall Service. 102 o S2 is an SR-unaware DPI Service. 104 SR-C --3-- 105 | / \ 106 | / \ 107 A----1----2----4----5----6----B 108 | | 109 | | 110 S1 S2 112 Figure 1: Network with Services 114 SR Controller (SR-C) is connected to Node 1, but may be attached to 115 any node 1-6 in the network. 117 SR-C is capable of receiving BGP-LS updates to discover topology, and 118 calculating constrained paths between 1 and 6. 120 However, if SR-C is configured to computation a constrained path from 121 1 and 6, including a DPI service (i.e., S2) it is not yet possible 122 due to the lack of service distribution. SR-C does not know where a 123 DPI Service is nor the SID for it. It does not know that S2 is a 124 service it needs. 126 Let's propose an extension to BGP-LS for Service Chaining to 127 distribute the service information to SR-C. There are no extensions 128 required in SR-TE Policy SAFI. 130 2. BGP-LS Extensions for Service Chaining 132 For an attached service, following data needs to be shared with SR-C: 134 o Service SID value (e.g. MPLS label or IPv6 address). 136 o Function Identifier (Static Proxy, Dynamic Proxy, Shared Memory 137 Proxy, Masquerading Proxy, SR Aware Service etc). 139 o Service Type (DPI, Firewall, Classifier, LB etc). 141 o Traffic Type (IPv4 OR IPv6 OR Ethernet) 143 o Opaque Data (Such as brand and version, other extra information) 145 [I-D.clad-spring-segment-routing-service-chaining]defines SR-aware 146 and SR-unaware services. Let's reuse these definitions. Per 147 [RFC7752] Node Attributes are ONLY associated with the Node NLRI. 148 All non-VPN information SHALL be encoded using AFI 16388 / SAFI 71. 149 VPN information SHALL be encoded using AFI 16388 / SAFI 72 with 150 associated RTs. 152 This document extends Node SID TLV [I-D.dawra-idr-bgpls-srv6-ext] to 153 associate the Service SID Value with Service-related Information 154 using Service Chaining(SC) Sub-TLV. 156 Function Sub-TLV [I-D.dawra-idr-bgpls-srv6-ext] of Node SID TLV 157 encodes Identifier(Function ID) along with associated Function Flags. 159 A Service Chaining (SC) Sub-TLV in Figure 2 is defined as: 161 +---------------------------------------+ 162 | Type (2 octet) | 163 +---------------------------------------+ 164 | Length (2 octet) | 165 +---------------------------------------+ 166 | Service Type(ST) (2 octet | 167 +---------------------------------------+ 168 | Flags (1 octet) | 169 +---------------------------------------+ 170 | Traffic Type(1 octet) | 171 +---------------------------------------+ 172 | RESERVED (2 octet) | 173 +---------------------------------------+ 175 Figure 2: Service Chaining(SC) Sub-TLV 177 Where: 179 Type: 16 bit field. TBD 181 Length: 16 bit field. The total length of the value portion of 182 the TLV. 184 Service Type(ST): 16bit field. Service Type: categorizes the 185 Service: (such as "Firewall", "Classifier" etc). 187 Flags: 8 bit field. Bits SHOULD be 0 on transmission and MUST be 188 ignored on reception. 190 Traffic Type: 8 Bit field. A bit to identify if Service is IPv4 191 OR IPv6 OR L2 Ethernet Capable. Where: 193 Bit 0(LSB): Set to 1 if Service is IPv4 Capable 195 Bit 1: Set to 1 if Service is IPv6 Capable 197 Bit 2: Set to 1 if Service is Ethernet Capable 199 RESERVED: 16bit field. SHOULD be 0 on transmission and MUST be 200 ignored on reception. 202 Service Type(ST) MUST be encoded as part of SC Sub-TLV. 204 There may be multiple instances of similar Services that needs to be 205 distinguished. For example, firewalls made by different vendors A 206 and B may need to be identified differently because, while they have 207 similar functionality, their behavior is not identical. 209 In order for SDN Controller to identify the categories of Services 210 and their associated SIDs, this section defines the BGP-LS extensions 211 required to encode these characteristics and other relevant 212 information about these Services. 214 Another Optional Opaque Metadata(OM) Sub-TLV of Node SID TLV may 215 encode vendor specific information. Multiple of OM Sub-TLVs may be 216 encoded. 218 +---------------------------------------+ 219 | Type (2 octet) | 220 +---------------------------------------+ 221 | Length (2 octet) | 222 +---------------------------------------+ 223 | Opaque Type (2 octet) | 224 +---------------------------------------+ 225 | Flags (1 octet) | 226 +---------------------------------------+ 227 | Value (variable) | 228 +---------------------------------------+ 230 Figure 3: Opaque Metadata(OM) Sub-TLV 232 o Type: 16 bit field. TBD. 234 o Length: 16 bit field. The total length of the value portion of 235 the TLV. 237 o Opaque Type: 8-bit field. Only publishers and consumers of the 238 opaque data are supposed to understand the data. 240 o Flags: 8 bit field. Bits SHOULD be 0 on transmission and MUST be 241 ignored on reception. 243 o Value: Variable Length. Based on the data being encoded and 244 length is recorded in length field. 246 Opaque Metadata(OM) Sub-TLV defined in Figure 3 may encode propriety 247 or Service Opaque information such as: 249 o Vendor specific Service Information. 251 o Traffic Limiting Information to particular Service Type. 253 o Opaque Information unique to the Service 255 o Propriety Enterprise Service specific Information. 257 3. Illustration 259 In our SRv6 example above Figure 1 , Node 5 is configured with an 260 SRv6 dynamic proxy segments (End.AD) C5::AD:F2 for S2. 262 The BGP-LS advertisement MUST contain and Node SID TLV: 264 o Service SID: C5::AD:F2 SID 266 o Function ID: END.AD 268 The BGP-LS advertisement MUST contain a SC Sub-TLV with: 270 o Service Type: Deep Packet Inspection(DPI) 272 o Traffic Type: IPv4 Capable. 274 The BGP-LS advertisement MAY contain a OM Sub-TLV with: 276 o Opaque Type: Cisco DPI Version 278 o Value: 3.5 280 In our example in Figure 1, using BGP SR-TE SAFI Update 281 [I-D.ietf-idr-segment-routing-te-policy], SR Controller computes the 282 candidate path and pushes the Policy. 284 SRv6 encapsulation policy < CF1::, C3::, C5::AD:F2, C6::D4:B > is 285 signaled to Node 1 which has mix of service and topological segments. 287 4. IANA Considerations 289 This document requests assigning code-points from the registry "BGP- 290 LS Node Descriptor, Link Descriptor, Prefix Descriptor, and Attribute 291 TLVs". 293 4.1. Service Type Table 295 IANA is request to create a new top-level registry called "Service 296 Type Table (STT)". Valid values are in the range 0 to 65535. Values 297 0 and 65535 are to be marked "Reserved, not to be allocated". 299 +--------------+---------------------------+--------------+----------------+ 300 | Service | Service | Reference | Date | 301 | Value(TBD) | | | | 302 +--------------+---------------------------+--------------+----------------+ 303 | 32 | Classifier | ref-to-set | date-to-set | 304 +--------------+---------------------------+--------------+----------------+ 305 | 33 | Firewall | ref-to-set | date-to-set | 306 +--------------+---------------------------+--------------+----------------+ 307 | 34 | Load Balancer | ref-to-set | date-to-set | 308 +--------------+---------------------------+--------------+----------------+ 309 | 35 | DPI | ref-to-set | date-to-set | 310 +--------------+---------------------------+--------------+----------------+ 312 Figure 4 314 4.2. Segment routing function Identifier(SFI) 316 IANA is request to extend a top-level registry called "Segment 317 Routing Function Identifier(SFI)" with new code points. This 318 document extends the SFI values defined in 319 [I-D.dawra-idr-bgpls-srv6-ext]. Details about the Service functions 320 are defined in[I-D.clad-spring-segment-routing-service-chaining]. 322 +--------------------------+---------------------------+ 323 | Function | Function Identifier | 324 | | | 325 +--------------------------+---------------------------+ 326 | Static Proxy | 8 | 327 +--------------------------+---------------------------+ 328 | Dynamic Proxy | 9 | 329 +--------------------------+---------------------------+ 330 | Shared Memory Proxy | 10 | 331 +--------------------------+---------------------------+ 332 | Masquerading Proxy | 11 | 333 +--------------------------+---------------------------+ 334 | SRv6 Aware Service | 12 | 335 +--------------------------+---------------------------+ 337 5. Manageability Considerations 339 This section is structured as recommended in[RFC5706] 341 6. Operational Considerations 343 6.1. Operations 345 Existing BGP and BGP-LS operational procedures apply. No additional 346 operation procedures are defined in this document. 348 7. Security Considerations 350 Procedures and protocol extensions defined in this document do not 351 affect the BGP security model. See the 'Security Considerations' 352 section of [RFC4271]for a discussion of BGP security. Also refer 353 to[RFC4272]and[RFC6952]for analysis of security issues for BGP. 355 8. Conclusions 357 This document proposes extensions to the BGP-LS to allow discovery of 358 Services using Segment Routing. 360 9. Acknowledgements 362 The authors would like to thank Krishnaswamy Ananthamurthy for his 363 review of this document. 365 10. References 366 10.1. Normative References 368 [I-D.clad-spring-segment-routing-service-chaining] 369 Clad, F., Filsfils, C., Camarillo, P., 370 daniel.bernier@bell.ca, d., Decraene, B., Peirens, B., 371 Yadlapalli, C., Xu, X., Salsano, S., Abdelsalam, A., and 372 G. Dawra, "Segment Routing for Service Chaining", draft- 373 clad-spring-segment-routing-service-chaining-00 (work in 374 progress), October 2017. 376 [I-D.dawra-idr-bgpls-srv6-ext] 377 Dawra, G., Filsfils, C., Talaulikar, K., Sreekantiah, A., 378 and L. Ginsberg, "BGP Link State extensions for IPv6 379 Segment Routing(SRv6)", draft-dawra-idr-bgpls-srv6-ext-00 380 (work in progress), October 2017. 382 [RFC4272] Murphy, S., "BGP Security Vulnerabilities Analysis", 383 RFC 4272, DOI 10.17487/RFC4272, January 2006, 384 . 386 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 387 Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 388 2006, . 390 [RFC5706] Harrington, D., "Guidelines for Considering Operations and 391 Management of New Protocols and Protocol Extensions", 392 RFC 5706, DOI 10.17487/RFC5706, November 2009, 393 . 395 [RFC6952] Jethanandani, M., Patel, K., and L. Zheng, "Analysis of 396 BGP, LDP, PCEP, and MSDP Issues According to the Keying 397 and Authentication for Routing Protocols (KARP) Design 398 Guide", RFC 6952, DOI 10.17487/RFC6952, May 2013, 399 . 401 [RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and 402 S. Ray, "North-Bound Distribution of Link-State and 403 Traffic Engineering (TE) Information Using BGP", RFC 7752, 404 DOI 10.17487/RFC7752, March 2016, 405 . 407 10.2. Informative References 409 [I-D.dawra-bgp-srv6-vpn] 410 (Unknown), (., Dawra, G., Filsfils, C., Dukes, D., 411 Brissette, P., Camarillo, P., Leddy, J., 412 daniel.voyer@bell.ca, d., daniel.bernier@bell.ca, d., 413 Steinberg, D., Raszuk, R., Decraene, B., and S. 414 Matsushima, "BGP Signaling of IPv6-Segment-Routing-based 415 VPN Networks", draft-dawra-bgp-srv6-vpn-00 (work in 416 progress), March 2017. 418 [I-D.filsfils-spring-segment-routing-policy] 419 Filsfils, C., Sivabalan, S., Raza, K., Liste, J., Clad, 420 F., Lin, S., bogdanov@google.com, b., Horneffer, M., 421 Steinberg, D., Decraene, B., and S. Litkowski, "Segment 422 Routing Policy for Traffic Engineering", draft-filsfils- 423 spring-segment-routing-policy-01 (work in progress), July 424 2017. 426 [I-D.filsfils-spring-srv6-network-programming] 427 Filsfils, C., Leddy, J., daniel.voyer@bell.ca, d., 428 daniel.bernier@bell.ca, d., Steinberg, D., Raszuk, R., 429 Matsushima, S., Lebrun, D., Decraene, B., Peirens, B., 430 Salsano, S., Naik, G., Elmalky, H., Jonnalagadda, P., 431 Sharif, M., Ayyangar, A., Mynam, S., Henderickx, W., 432 Bashandy, A., Raza, K., Dukes, D., Clad, F., and P. 433 Camarillo, "SRv6 Network Programming", draft-filsfils- 434 spring-srv6-network-programming-01 (work in progress), 435 June 2017. 437 [I-D.ietf-6man-segment-routing-header] 438 Previdi, S., Filsfils, C., Raza, K., Leddy, J., Field, B., 439 daniel.voyer@bell.ca, d., daniel.bernier@bell.ca, d., 440 Matsushima, S., Leung, I., Linkova, J., Aries, E., Kosugi, 441 T., Vyncke, E., Lebrun, D., Steinberg, D., and R. Raszuk, 442 "IPv6 Segment Routing Header (SRH)", draft-ietf-6man- 443 segment-routing-header-07 (work in progress), July 2017. 445 [I-D.ietf-bess-evpn-prefix-advertisement] 446 Rabadan, J., Henderickx, W., Drake, J., Lin, W., and A. 447 Sajassi, "IP Prefix Advertisement in EVPN", draft-ietf- 448 bess-evpn-prefix-advertisement-08 (work in progress), 449 October 2017. 451 [I-D.ietf-idr-bgp-ls-segment-routing-ext] 452 Previdi, S., Psenak, P., Filsfils, C., Gredler, H., and M. 453 Chen, "BGP Link-State extensions for Segment Routing", 454 draft-ietf-idr-bgp-ls-segment-routing-ext-03 (work in 455 progress), July 2017. 457 [I-D.ietf-idr-bgp-prefix-sid] 458 Previdi, S., Filsfils, C., Lindem, A., Sreekantiah, A., 459 and H. Gredler, "Segment Routing Prefix SID extensions for 460 BGP", draft-ietf-idr-bgp-prefix-sid-07 (work in progress), 461 October 2017. 463 [I-D.ietf-idr-segment-routing-te-policy] 464 Previdi, S., Filsfils, C., Mattes, P., Rosen, E., and S. 465 Lin, "Advertising Segment Routing Policies in BGP", draft- 466 ietf-idr-segment-routing-te-policy-00 (work in progress), 467 July 2017. 469 [I-D.ietf-isis-segment-routing-extensions] 470 Previdi, S., Filsfils, C., Bashandy, A., Gredler, H., 471 Litkowski, S., Decraene, B., and j. jefftant@gmail.com, 472 "IS-IS Extensions for Segment Routing", draft-ietf-isis- 473 segment-routing-extensions-13 (work in progress), June 474 2017. 476 [I-D.ietf-spring-segment-routing] 477 Filsfils, C., Previdi, S., Ginsberg, L., Decraene, B., 478 Litkowski, S., and R. Shakir, "Segment Routing 479 Architecture", draft-ietf-spring-segment-routing-13 (work 480 in progress), October 2017. 482 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 483 Requirement Levels", BCP 14, RFC 2119, 484 DOI 10.17487/RFC2119, March 1997, 485 . 487 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 488 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 489 DOI 10.17487/RFC4271, January 2006, 490 . 492 [RFC4659] De Clercq, J., Ooms, D., Carugi, M., and F. Le Faucheur, 493 "BGP-MPLS IP Virtual Private Network (VPN) Extension for 494 IPv6 VPN", RFC 4659, DOI 10.17487/RFC4659, September 2006, 495 . 497 [RFC5549] Le Faucheur, F. and E. Rosen, "Advertising IPv4 Network 498 Layer Reachability Information with an IPv6 Next Hop", 499 RFC 5549, DOI 10.17487/RFC5549, May 2009, 500 . 502 Authors' Addresses 504 Gaurav Dawra (editor) 505 Cisco Systems 506 USA 508 Email: gdawra@cisco.com 510 Clarence Filsfils 511 Cisco Systems 512 Belgium 514 Email: cfilsfil@cisco.com 516 Daniel Bernier 517 Bell Canada 518 Canada 520 Email: daniel.bernier@bell.ca 522 Hani Elmalky 523 Ericsson 524 USA 526 Email: hani.elmalky@gmail.com 528 Xiaohu Xu 529 Huawei 531 Email: xuxiaohu@huawei.com 533 Francois Clad 534 Cisco Systems 535 France 537 Email: fclad@cisco.com