idnits 2.17.1 draft-ietf-mpls-ldp-capabilities-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? 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 seems to contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (April 23, 2009) is 5482 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) -- Obsolete informational reference (is this intentional?): RFC 4447 (Obsoleted by RFC 8077) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Bob Thomas 2 Internet Draft Cisco Systems, Inc. 3 Updates: 5036 4 Intended Status: Proposed Standard S. Aggarwal 5 Expiration Date: October 22, 2009 Juniper Networks 7 R. Aggarwal 8 Juniper Networks 10 J.L. Le Roux 11 France Telecom 13 Syed Kamran Raza 14 Cisco Systems, Inc. 16 April 23, 2009 18 LDP Capabilities 20 draft-ietf-mpls-ldp-capabilities-04.txt 22 Status of this Memo 24 This Internet-Draft is submitted to IETF in full conformance with the 25 provisions of BCP 78 and BCP 79. This document may contain material 26 from IETF Documents or IETF Contributions published or made publicly 27 available before November 10, 2008. The person(s) controlling the 28 copyright in some of this material may not have granted the IETF 29 Trust the right to allow modifications of such material outside the 30 IETF Standards Process. Without obtaining an adequate license from 31 the person(s) controlling the copyright in such materials, this 32 document may not be modified outside the IETF Standards Process, and 33 derivative works of it may not be created outside the IETF Standards 34 Process, except to format it for publication as an RFC or to 35 translate it into languages other than English. 37 Internet-Drafts are working documents of the Internet Engineering 38 Task Force (IETF), its areas, and its working groups. Note that 39 other groups may also distribute working documents as Internet- 40 Drafts. 42 Internet-Drafts are draft documents valid for a maximum of six months 43 and may be updated, replaced, or obsoleted by other documents at any 44 time. It is inappropriate to use Internet-Drafts as reference 45 material or to cite them other than as "work in progress." 47 The list of current Internet-Drafts can be accessed at 48 http://www.ietf.org/ietf/1id-abstracts.txt. 50 The list of Internet-Draft Shadow Directories can be accessed at 51 http://www.ietf.org/shadow.html. 53 This Internet-Draft will expire on October 22, 2009. 55 Copyright 57 Copyright (c) 2009 IETF Trust and the persons identified as the 58 document authors. All rights reserved. 59 This document is subject to BCP 78 and the IETF Trust's Legal 60 Provisions Relating to IETF Documents in effect on the date of 61 publication of this document (http://trustee.ietf.org/license-info). 62 Please review these documents carefully, as they describe your rights 63 and restrictions with respect to this document. 65 Abstract 67 A number of enhancements to the Label Distribution Protocol (LDP) 68 have been proposed. Some have been implemented, and some are 69 advancing toward standardization. It is likely that additional 70 enhancements will be proposed in the future. This document defines a 71 mechanism for advertising LDP enhancements at session initialization 72 time, as well as a mechanism to enable and disable enhancements after 73 LDP session establishment. 75 Conventions used in this document 77 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 78 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 79 document are to be interpreted as described in [RFC2119]. 81 This document uses the terms "LDP speaker" and "speaker" 82 interchangably. 84 Table of Contents 86 1. Introduction...................................................3 87 2. The LDP Capability Mechanism...................................4 88 2.1. Capability Document.......................................5 89 3. Specifying Capabilities in LDP Messages........................5 90 3.1. Backward Compatibility TLVs...............................7 91 4. Capability Message.............................................7 92 5. Note on Terminology............................................8 93 6. Procedures for Capability Parameters in Initialization Messages8 94 7. Procedures for Capability Parameters in Capability Messages...10 95 8. Extensions to Error Handling..................................10 96 9. Dynamic Capability Announcement TLV...........................11 97 10. Backward Compatibility.......................................11 98 11. Security Considerations......................................12 99 12. IANA Considerations..........................................12 100 13. Acknowledgments..............................................12 101 14. References...................................................13 102 14.1. Normative References....................................13 103 14.2. Informative References..................................13 104 15. Author's Addresses...........................................14 106 1. Introduction 108 A number of enhancements to LDP as specified in [RFC5036] have been 109 proposed. These include LDP Graceful Restart [RFC3478], Fault 110 Tolerant LDP [RFC3479], multicast extensions [MLDP], signaling for 111 layer 2 circuits [RFC4447], a method for learning labels advertised 112 by next-next-hop routers in support of fast reroute node protection 113 [NNHOP], upstream label allocation [UPSTREAM_LDP], and extensions for 114 signaling inter-area LSPs [IALDP]. Some have been implemented, and 115 some are advancing toward standardization. It is also likely that 116 additional enhancements will be implemented and deployed in the 117 future. 119 This document proposes and defines a mechanism for advertising LDP 120 enhancements at session initialization time. It also defines a 121 mechanism to enable and disable these enhancements after LDP session 122 establishment. 124 LDP capability advertisement provides means for an LDP speaker to 125 announce what it can receive and process. It also provides means for 126 a speaker to inform peers of deviationts from behavior specified by 127 [RFC5036]. An example of such a deviation is LDP graceful restart 128 where a speaker retains MPLS forwarding state for LDP-signaled LSPs 129 when its LDP control plane goes down. It is important to point out 130 that not all LDP enhancements require capability advertisement. For 131 example, upstream label allocation does but inbound label filtering, 132 where a speaker installs forwarding state for only certain FECs, 133 does not. 135 2. The LDP Capability Mechanism 137 Enhancements are likely to be announced during LDP session 138 establishment as each LDP speaker advertises capabilities 139 corresponding to the enhancements it desires. 141 Beyond that, capability advertisements may be used to dynamically 142 modify the characteristics of the session to suit the changing 143 conditions. For example, an LSR capable of a particular enhancement 144 in support of some "feature" may not have advertised the 145 corresponding capability to its peers at session establishment time 146 because the feature was disabled at that time. Later, an operator 147 may enable the feature, at which time the LSR would react by 148 advertising the corresponding capability to its peers. Similarly, 149 when an operator disables a feature associated with a capability, the 150 LSR reacts by withdrawing the capability advertisement from its 151 peers. 153 The LDP capability advertisement mechanism operates as follows: 155 - Each LDP speaker is assumed to implement a set of enhancements, 156 each of which has an associated capability. At any time, a 157 speaker may have none, one, or more of those enhancements 158 "enabled". When an enhancement is enabled, the speaker 159 advertises the associated capability to its peers. By 160 advertising the capability to a peer, the speaker asserts that it 161 shall perform the protocol actions specified for the associated 162 enhancement. For example, the actions may require the LDP speaker 163 to receive and process enhancement-specific messages from its 164 peer. Unless the capability has been advertised, the speaker will 165 not perform protocol actions specified for the corresponding 166 enhancement. 168 - At session establishment time an LDP speaker MAY advertise a 169 particular capability by including an optional parameter 170 associated with the capability in its Initialization message. 172 - There is a well-known capability called Dynamic Capability 173 Announcement which an LDP speaker MAY advertise in its 174 Initialization message to indicate that it is capable of 175 processing capability announcements following a session 176 establishment. 178 If a peer had advertised the Dynamic Capability Announcement 179 capability in its Initialization message, then at any time 180 following session establishment an LDP speaker MAY announce 181 changes in its advertised capabilities to that peer. To do this, 182 the LDP speaker sends the peer a Capability message that 183 specifies the capabilities being advertised or withdrawn. 185 2.1. Capability Document 187 When the capability advertisement mechanism is in place, an LDP 188 enhancement requiring LDP capability advertisement will be specified 189 by a document that: 191 - Describes the motivation for the enhancement; 193 - Specifies the behavior of LDP when the enhancement is enabled. 194 This includes the procedures, parameters, messages, and TLVs 195 required by the enhancement; 197 - Includes an IANA considerations section that requests IANA 198 assignment of a code point (from TLV Type namespace) for the 199 optional capability parameter corresponding to the enhancement. 201 The capability document MUST also describe the interpretation and 202 processing of associated capability data, if present. 204 3. Specifying Capabilities in LDP Messages 206 This document uses the term "Capability Parameter" to refer to an 207 optional parameter that may be included in Initialization and 208 Capability messages to advertise a capability. 210 The format of a "Capability Parameter" TLV is as follows: 212 0 1 2 3 213 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 214 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 215 |U|F| TLV Code Point | Length | 216 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 217 |S| Reserved | | 218 +-+-+-+-+-+-+-+-+ Capability Data | 219 | +-+-+-+-+-+-+-+-+ 220 | | 221 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 223 where: 224 U-bit: 225 Unknown TLV bit, as described in [RFC5036]. The value could be 226 either 0 or 1 as specified in Capability document associated 227 with given capability. 229 F-bit: 230 Forward unknown TLV bit, as described in [RFC5036]. The value of 231 this bit MUST be 0 since a Capability Paramter TLV is sent only 232 in Initialization and Capability messages which are not 233 forwarded. 235 TLV Code Point: 236 The TLV type which identifies a specific capability. This is 237 IANA assigned code point (from TLV Type namespace) for given 238 capability as requested in the associated capability document. 240 S-bit: 241 The State Bit. It indicates whether the sender is advertising or 242 withdrawing the capability corresponding to the TLV Code Point. 243 The State bit value is used as follows: 245 1 - The TLV is advertising the capability specified by the 246 TLV Code Point. 247 0 - The TLV is withdrawing the capability specified by the 248 TLV Code Point. 250 Capability Data: 251 Information, if any, about the capability in addition to the TLV 252 Code Point required to fully specify the capability. 254 The method for interpreting and processing this data is specific 255 to the TLV Code Point and MUST be described in the document 256 specifying the capability. 258 An LDP speaker MUST NOT include more than one instance of a 259 Capability Parameter (as identified by the same TLV code point) in an 260 Initialization or Capability message. If an LDP speaker receives more 261 than one instance of the same Capability Parameter type in a message, 262 it SHOULD send a Notification message to peer before terminating the 263 session with peer. The Status Code in the Status TLV of the 264 Notification message MUST be Malformed TLV, and the message SHOULD 265 contain the second Capability Parameter TLV of the same type (Code 266 point) that is received in the message. 268 3.1. Backward Compatibility TLVs 270 LDP extensions that require advertisement or negotiation of some 271 capability at session establishment time typically use TLVs that are 272 included in an Initialization message. To ensure backward 273 compatibility with existing implementations, such TLVs continue to be 274 supported in an Initialization message and are known in this document 275 as "Backward Compatibility TLVs". A Backward Compatibility TLV plays 276 the role of a "Capability Parameter" TLV; that is the presence of a 277 Backward Compatibility TLV has the same meaning as a Capability 278 Parameter TLV with the S bit set for the same capability. 280 One example of a Backward Capability TLV is the "FT Session TLV" that 281 is exchanged in an Initialization message between peers to announce 282 LDP Fault Tolerance [RFC3479] capability. 284 4. Capability Message 286 The LDP Capability message is used by an LDP speaker to announce 287 changes in the state of one or more of its capabilities subsequent to 288 session establishment. 290 The format of the Capability message is as follows: 292 0 1 2 3 293 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 294 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 295 |0| Capability (IANA) | Length | 296 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 297 | Message ID | 298 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 299 | TLV_1 | 300 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 301 | . . . | 302 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 303 | TLV_N | 304 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 306 where TLV_1 through TLV_N are Capability Parameter TLVs. The S-bit 307 of each of the TLVs specifies the new state for the corresponding 308 capability. 310 Note that Backward Compatibility TLVs (see Section 3.1. ) MUST NOT be 311 included in Capability messages. 313 5. Note on Terminology 315 The following sections in this document talk about enabling and 316 disabling capabilities. The terminology "enabling (or disabling) a 317 capability" is short hand for "advertising (or withdrawing) a 318 capability associated with an enhancement". Bear in mind that it is 319 an LDP enhancement that is being enabled or disabled, and that it is 320 the corresponding capability that is being advertisted or withdrawn. 322 6. Procedures for Capability Parameters in Initialization Messages 324 The S-bit of a Capability Parameter in an Initialization message MUST 325 be 1 and SHOULD be ignored on receipt. This ensures that any 326 Capability Parameter in an Initialization message enables the 327 corresponding capability. 329 An LDP speaker determines the capabilities of a peer by examining the 330 set of of Capability Parameters present in the Initialization message 331 received from the peer. 333 An LDP speaker MAY use a particular capability with its peer after 334 the speaker determines that the peer has enabled that capability. 336 These procedures enable an LDP speaker S1, that advertises a specific 337 LDP capability C, to establish an LDP session with speaker S2 that 338 does not advertise C. In this situation whether or not capability C 339 may be used for the session depends on the semantics of the 340 enhancement associated with C. If the semantics do not require both 341 S1 and S2 advertise C to one another, then S2 could use it; i.e. S1's 342 advertisement of C permits S2 to send messages to S1 used by the 343 enhancement. 345 It is the responsibility of the capability designer to specify the 346 behavior of an LDP speaker that has enabled a certain enhancement, 347 advertised its capability and determines that its peer has not 348 advertised the corresponding capability. The document specifying 349 procedures for the capability MUST describe the behavior in this 350 situation. If the specified procedure is to terminate the session, 351 then the LDP speaker SHOULD send a Notification message to the peer 352 before terminating the session. The Status Code in the Status TLV 353 of the Notification message MUST be Unsupported Capability, and the 354 message SHOULD contain the unsupported capability (see Section 8. 355 for more details). 357 An LDP speaker that supports capability advertisement and includes a 358 Capability Parameter in its Initialization message MUST set the TLV 359 U-bit to 0 or 1, as specified by Capability document. LDP speaker 360 should set U-bit to 1 if the capability document allows to continue 361 with a peer that does not understand the enhancement, and set U-bit 362 to 0 otherwise. If a speaker receives a message containng unsupported 363 capability, it responds according to U-bit setting in the TLV. If U- 364 bit is 1, then speaker MUST silently ignore the Capability Parameter 365 and allow the session to be established. However, if U-bit is 0, then 366 speaker SHOULD send a Notification message to the peer before 367 terminating the session. The Status Code in the Status TLV of the 368 Notification message MUST be Unsupported Capability, and the 369 message SHOULD contain the unsupported capability (see Section 8. 370 for more details). 372 7. Procedures for Capability Parameters in Capability Messages 374 An LDP speaker MUST NOT send a Capability message to a peer unless 375 its peer had advertised the Dynamic Capability Announcement 376 capability in its session Initialization message. An LDP speaker MAY 377 send a Capability message to a peer if its peer had advertised the 378 Dynamic Capability Announcement capability in its session 379 Initialization message (see Section 9. ). 381 An LDP speaker determines the capabilities enabled by a peer by 382 determining the set of capabilities enabled at session initialization 383 (as specified in Section 6. ) and tracking changes to that set made 384 by Capability messages from the peer. 386 An LDP speaker that has enabled a particular capability MAY use the 387 enhancement corresponding to the capability with a peer after the 388 speaker determines that the peer has enabled the capability. 390 8. Extensions to Error Handling 392 This document defines a new LDP status code named Unsupported 393 Capability. The E-bit of the Status TLV carried in a Notification 394 message that includes this status code MUST be set to 0. 396 In addition, this document defines a new LDP TLV, named Returned 397 TLVs, that MAY be carried in a Notification message. The U-bit 398 setting for a Returned TLVs TLV in a Notification message SHOULD be 1 399 and the F-bit setting SHOULD be 0. 401 When the Status Code in a Notification message is Unsupported 402 Capability, the message SHOULD specify the capabilities that are 403 unsupported. When the Notification message specifies the unsupported 404 capabilities, it MUST include a Returned TLVs TLV. The Returned TLVs 405 TLV MUST include only the Capability Parameters for unsupported 406 capabilities, and the Capability Parameter for each such capability 407 SHOULD be encoded as received from the peer. 409 When the Status Code in a Notification Message is Unknown TLV, the 410 message SHOULD specify the TLV that was unknown. When the 411 Notification message specifies the TLV that was unknown, it MUST 412 include the unknown TLV in a Returned TLVs TLV. 414 9. Dynamic Capability Announcement TLV 416 The Dynamic Capability Announcement TLV is a Capability Parameter 417 defined by this document with following format: 419 0 1 2 3 420 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 421 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 422 |1|0| DynCap Announcement (IANA)| Length (1) | 423 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 424 |1| Reserved | 425 +-+-+-+-+-+-+-+-+ 427 The value of U-bit for Dynamic Capability Announcement Parameter TLV 428 MUST be set to 1 so that a receiver MUST silently ignore this TLV, if 429 unknown to it, and continue processing the rest of the message. There 430 is no "Capability Data" associated with this TLV and hence TLV length 431 MUST be set to 1. 433 The Dynamic Capability Announcement Parameter MAY be included by an 434 LDP speaker in an Initialization message to signal its peer that the 435 speaker is capable of processing Capability messages. 437 An LDP speaker MUST NOT include the Dynamic Capability Announcement 438 Parameter in Capability messages sent to its peers. Once enabled 439 during session initialization, the Dynamic Capability Announcement 440 capability cannot be disabled. This implies that S-bit is always 1 441 for Dynamic Capability Announcement. 443 An LDP speaker that receives a Capability message from a peer that 444 includes the Dynamic Capability Announcement Parameter SHOULD 445 silently ignore the parameter and process any other Capability 446 Parameters in the message. 448 10. Backward Compatibility 450 From the point of view of the LDP capability advertisement mechanism, 451 an [RFC5036] compliant peer has label distribution for IPv4 enabled 452 by default. To ensure compatibility with an [RFC5036] compliant 453 peer, LDP implementations that support capability advertisement have 454 label distribution for IPv4 enabled until it is explicitly disabled 455 and MUST assume that their peers do as well. 457 Section 3.1 introduces the concept of Backward Compatibility TLVs 458 that may appear in an Initialization message in the role of a 459 Capability Parameter. This permits existing LDP enhancements that 460 use an adhoc mechanism for enabling capabilities at sesssion 461 initialization time to continue to do so. 463 11. Security Considerations 465 [MPLS_SEC] describes the security framework for MPLS networks, 466 whereas [RFC5036] describes the security considerations that apply to 467 the base LDP specification. The same security framework and 468 considerations apply to the capability mechanism described in this 469 document. 471 12. IANA Considerations 473 This document specifies the following which require code points assigned 474 by IANA: 476 - LDP message code point for the Capability message. The authors 477 request message type 0x0202 for the Capability message. 479 - LDP TLV code point for the Dynamic Capability Announcemnt TLV. 480 The authors request TLV type code 0x0506. 482 - LDP TLV code point for the Returned TLVs TLV. The authors 483 request TLV type 0x304. 485 - LDP Status Code code point for the Unsupported Capability Status 486 Code. The authors request Status Code 0x0000002C. 488 13. Acknowledgments 490 The authors wish to thank Enke Chen, Vanson Lim, Ina Minei, Bin Mo, 491 Yakov Rekhter, and Eric Rosen for their comments. 493 This document was prepared using 2-Word-v2.0.template.dot. 495 14. References 497 14.1. Normative References 499 [RFC5036] Andersson, L., Menei, I., and Thomas, B., Editors, "LDP 500 Specification", RFC 5036, September 2007. 502 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 503 Requirement Levels", BCP 14, RFC2119, March 1997. 505 [RFC3479] Farrel, A., Editor, "Fault Tolerance for the Label 506 Distribution Protocol (LDP)", RFC 3479, February 2003. 508 14.2. Informative References 510 [IALDP] Decraene, B., Le Roux, JL., Minei, I, "LDP Extensions for 511 Inter-Area LSPs", draft-decraene-mpls-ldp-interarea-04.txt, 512 Work in Progress, March 2007 514 [MLDP] Minei, I., Wijnamds, I., Editors, "Label Distribution Protocol 515 Extensions for Point-to-Multipoint and Multipoint-to- 516 Multipoint Label Switched Paths", draft-minei-wijnands-mpls- 517 ldp-p2mp-00.txt, Work in Progress, September 2005 519 [NNHOP] Shen, N., Chen, E., Tian, A. "Discovery LDP Next-Nexthop 520 Labels", draft-shen-mpls-ldp-nnhop-label-02.txt, Work in 521 Progress, May 2005 522 [RFC4447] L. Martini, Editor, E. Rosen, El-Aawar, T. Smith, G. Heron, 523 "Pseudowire Setup and Maintenance using the Label Distribution 524 Protocol", RFC 4447, April 2006. 526 [RFC3478] Leelanivas, M., Rekhter, Y, Aggarwal, R., "Graceful Restart 527 Mechanism for Label Distribution Protocol (LDP)", RFC 3478, 528 February 2003. 530 [UPSTREAM_LDP] Aggarwal R., Le Roux, J.L., "MPLS Upstream Label 531 Assignment for LDP" draft-ietf-mpls-ldp-upstream-00.txt, Work 532 in Progress, February 2006. 534 [MPLS_SEC] Fang, L. et al., Security Framework for MPLS and GMPLS 535 Networks, draft-ietf-mpls-mpls-and-gmpls-security-framework- 536 05.txt, Work in Progress, March 2009. 538 15. Author's Addresses 540 Bob Thomas 541 Cisco Systems, Inc. 542 1414 Massachusetts Ave. 543 Boxborough, MA 01719 544 E-mail: bobthomas@alum.mit.edu 546 Shivani Aggarwal 547 Juniper Networks 548 1194 North Mathilda Ave. 549 Sunnyvale, CA 94089 550 Email: shivani@juniper.net 552 Rahul Aggarwal 553 Juniper Networks 554 1194 North Mathilda Ave. 555 Sunnyvale, CA 94089 556 Email: rahul@juniper.net 558 Jean-Louis Le Roux 559 France Telecom 560 2, Avenue Pierre-Marzin 561 22307 Lannion Cedex, France 562 E-mail: jeanlouis.leroux@orange-ftgroup.com 564 Syed Kamran Raza 565 Cisco Systems, Inc. 566 2000 Innovation Dr. 567 Kanata, ON K2K-3E8, Canada 568 E-mail: skraza@cisco.com