idnits 2.17.1 draft-ietf-pce-lsp-setup-type-10.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 (May 4, 2018) is 2178 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 (-16) exists of draft-ietf-pce-segment-routing-11 Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PCE Working Group S. Sivabalan 3 Internet-Draft Cisco Systems, Inc. 4 Intended status: Standards Track J. Tantsura 5 Expires: November 5, 2018 Nuage Networks 6 I. Minei 7 Google, Inc. 8 R. Varga 9 Pantheon Technologies SRO 10 J. Hardwick 11 Metaswitch Networks 12 May 4, 2018 14 Conveying path setup type in PCEP messages 15 draft-ietf-pce-lsp-setup-type-10 17 Abstract 19 A Path Computation Element (PCE) can compute Traffic Engineering (TE) 20 paths through a network that are subject to various constraints. 21 Currently, TE paths are Label Switched Paths (LSPs) which are set up 22 using the RSVP-TE signaling protocol. However, other TE path setup 23 methods are possible within the PCE architecture. This document 24 proposes an extension to the PCE communication protocol (PCEP) to 25 allow support for different path setup methods over a given PCEP 26 session. 28 Status of This Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at https://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on November 5, 2018. 45 Copyright Notice 47 Copyright (c) 2018 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (https://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 63 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 64 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 65 3. Path Setup Type Capability TLV . . . . . . . . . . . . . . . 4 66 4. Path Setup Type TLV . . . . . . . . . . . . . . . . . . . . . 6 67 5. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 6 68 6. Manageability Considerations . . . . . . . . . . . . . . . . 8 69 7. Security Considerations . . . . . . . . . . . . . . . . . . . 8 70 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 71 8.1. PCEP TLV Type Indicators . . . . . . . . . . . . . . . . 9 72 8.2. New Path Setup Type Registry . . . . . . . . . . . . . . 9 73 8.3. PCEP-Error Object . . . . . . . . . . . . . . . . . . . . 10 74 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 10 75 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 76 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 77 11.1. Normative References . . . . . . . . . . . . . . . . . . 10 78 11.2. Informative References . . . . . . . . . . . . . . . . . 11 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 81 1. Introduction 83 [RFC5440] describes the Path Computation Element communication 84 Protocol (PCEP) for communication between a Path Computation Client 85 (PCC) and a Path Computation Element (PCE), or between a PCE and a 86 PCE. A PCC requests a path subject to various constraints and 87 optimization criteria from a PCE. The PCE responds to the PCC with a 88 hop-by-hop path in an Explicit Route Object (ERO). The PCC uses the 89 ERO to set up the path in the network. 91 [RFC8231] specifies extensions to PCEP that allow a PCC to delegate 92 its LSPs to a PCE. The PCE can then update the state of LSPs 93 delegated to it. In particular, the PCE may modify the path of an 94 LSP by sending a new ERO. The PCC uses this ERO to re-route the LSP 95 in a make-before-break fashion. [RFC8281] specifies a mechanism 96 allowing a PCE to dynamically instantiate an LSP on a PCC by sending 97 the ERO and the characteristics of the LSP. The PCC creates the LSP 98 using the ERO and other attributes sent by the PCE. 100 So far, PCEP and its extensions have assumed that the TE paths are 101 label switched and are established via the RSVP-TE protocol. 102 However, other methods of LSP setup are possible in the PCE 103 architecture (see [RFC4655] and [RFC4657]). This document 104 generalizes PCEP to allow other LSP setup methods to be used. It 105 defines two new TLVs and specifies the base procedures to facilitate 106 this, as follows. 108 o The PATH-SETUP-TYPE-CAPABILITY TLV, which allows a PCEP speaker to 109 announce which LSP setup methods it supports when the PCEP session 110 is established. 112 o The PATH-SETUP-TYPE TLV, which allows a PCEP speaker to specify 113 which setup method should be used for a given LSP. When multiple 114 path setup types are deployed in a network, a given PCEP session 115 may have to simultaneously support more than one path setup type. 116 A PCEP speaker uses the PATH-SETUP-TYPE TLV to explicitly indicate 117 the intended path setup type in the appropriate PCEP messages, 118 unless the path setup type is RSVP-TE (which is assumed to be the 119 path setup type if no other setup type is indicated). This is so 120 that both the PCC and the PCE can take the necessary steps to set 121 up the path. 123 This document defines a path setup type code for RSVP-TE. When a new 124 path setup type (other than RSVP-TE) is introduced for setting up a 125 path, a path setup type code and, optionally, a sub-TLV pertaining to 126 the new path setup type will be defined by the document that 127 specifies the new path setup type. 129 1.1. Requirements Language 131 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 132 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 133 "OPTIONAL" in this document are to be interpreted as described in BCP 134 14 [RFC2119] [RFC8174] when, and only when, they appear in all 135 capitals, as shown here. 137 2. Terminology 139 The following terminologies are used in this document: 141 ERO: Explicit Route Object. 143 LSR: Label Switching Router. 145 PCC: Path Computation Client. 147 PCE: Path Computation Element. 149 PCEP: Path Computation Element Protocol. 151 PST: Path Setup Type. 153 TLV: Type, Length, and Value. 155 3. Path Setup Type Capability TLV 157 A PCEP speaker indicates which PSTs it supports during the PCEP 158 initialization phase, as follows. When the PCEP session is created, 159 it sends an Open message with an OPEN object containing the PATH- 160 SETUP-TYPE-CAPABILITY TLV. The format of this TLV is as follows. 162 0 1 2 3 163 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 164 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 165 | Type (TBD1) | Length | 166 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 167 | Reserved | Num of PSTs | 168 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 169 | PST#1 | ... | PST#N | Padding | 170 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 171 | | 172 // Optional sub-TLVs (variable) // 173 | | 174 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 176 Figure 1: PATH-SETUP-TYPE-CAPABILITY TLV 178 The TLV type is TBD1 (to be assigned by IANA). Its reserved field 179 MUST be set to zero by the sender and MUST be ignored by the 180 receiver. The other fields in the TLV are as follows. 182 Length: The total length in bytes of the remainder of the TLV, that 183 is, excluding the Type and Length fields. 185 Number of PSTs: The number of PSTs in the following list, excluding 186 padding. 188 List of PSTs: A list of the PSTs that the PCEP speaker supports. 189 Each PST is a single byte in length. Duplicate entries in this 190 list MUST be ignored. The PCEP speaker MUST pad the list with 191 zeros so that it is a muliple of four bytes in length. This 192 document defines the following PST value: 194 * PST = 0: Path is setup using the RSVP-TE signaling protocol. 196 Optional sub-TLVs: A list of sub-TLVs associated with the supported 197 PSTs. Each PST has zero or one sub-TLVs associated with it, and 198 each sub-TLV is associated with exactly one PST. Each sub-TLV 199 MUST obey the rules for TLV formatting defined in ([RFC5440]). 200 That is, each sub-TLV is padded to a four byte alignment, and the 201 length field of each sub-TLV does not include the padding bytes. 202 This document does not define any sub-TLVs; an example can be 203 found in [I-D.ietf-pce-segment-routing]. 205 A PCEP speaker MUST check that this TLV is correctly formatted, as 206 follows. 208 o If there are no sub-TLVs, then the TLV length field MUST be equal 209 to four bytes plus the size of the PST list, excluding any padding 210 bytes. 212 o If there are sub-TLVs then the TLV Length field MUST be equal to 213 four bytes plus the size of the PST list (rounded up to the 214 nearest multiple of four) plus the size of the appended sub-TLVs 215 excluding any padding bytes in the final sub-TLV. 217 o The Number of PSTs field MUST be greater than zero. 219 If a PCEP speaker receives a PATH-SETUP-TYPE-CAPABILITY TLV which 220 violates these rules, then the PCEP speaker MUST send a PCErr message 221 with Error-Type = 10 (Reception of an invalid object) and Error-Value 222 = 11 (Malformed object) and MUST close the PCEP session. The PCEP 223 speaker MAY include the malformed OPEN object in the PCErr message as 224 well. 226 If a PCEP speaker receives an OPEN object with more than one PATH- 227 SETUP-TYPE-CAPABILITY TLV then it MUST ignore all but the first 228 instance of this TLV. 230 The absence of the PATH-SETUP-TYPE-CAPABILITY TLV from the OPEN 231 object is equivalent to a PATH-SETUP-TYPE-CAPABILITY TLV containing a 232 single PST of 0 (RSVP-TE signaling protocol) and no sub-TLVs. A PCEP 233 speaker MAY omit the PATH-SETUP-TYPE-CAPABILITY TLV if the only PST 234 it supports is RSVP-TE. If a PCEP speaker supports other PSTs 235 besides RSVP-TE, then it SHOULD include the PATH-SETUP-TYPE- 236 CAPABILITY TLV in its OPEN object. 238 If a PCEP speaker does not recognize the PATH-SETUP-TYPE-CAPABILITY 239 TLV, it will ignore the TLV in accordance with [RFC5440]. 241 4. Path Setup Type TLV 243 When a PCEP session is used to set up TE paths using different 244 methods, the corresponding PCE and PCC must be aware of the path 245 setup method used. That means, a PCE must be able to specify paths 246 in the correct format and a PCC must be able to take control plane 247 and forwarding plane actions appropriate to the PST. 249 0 1 2 3 250 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 251 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 252 | Type (28) | Length (4) | 253 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 254 | Reserved | PST | 255 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 257 Figure 2: PATH-SETUP-TYPE TLV 259 PATH-SETUP-TYPE TLV is an optional TLV associated with the RP 260 ([RFC5440]) and the SRP ([RFC8231]) objects. Its format is shown in 261 the above figure. The TLV type is 28. Its reserved field MUST be 262 set to zero. The one byte value contains the PST as defined for the 263 PATH-SETUP-TYPE-CAPABILITY TLV. 265 The absence of the PATH-SETUP-TYPE TLV is equivalent to a PATH-SETUP- 266 TYPE TLV with a PST value of 0 (RSVP-TE). A PCEP speaker MAY omit 267 the TLV if the PST is RSVP-TE. If the RP or SRP object contains more 268 than one PATH-SETUP-TYPE TLV, only the first TLV MUST be processed 269 and the rest MUST be ignored. 271 If a PCEP speaker does not recognize the PATH-SETUP-TYPE TLV, it will 272 ignore the TLV in accordance with [RFC5440], and will use RSVP-TE to 273 set up the path. 275 5. Operation 277 During the PCEP initialization phase, if a PCEP speaker receives a 278 PATH-SETUP-TYPE-CAPABILITY TLV from its peer, it MUST assume that the 279 peer supports only the PSTs listed in the TLV. If the PCEP speaker 280 and its peer have no PSTs in common, then the PCEP speaker MUST send 281 a PCErr message with Error-Type = 21 (Invalid traffic engineering 282 path setup type) and Error-Value = 2 (Mismatched path setup type) and 283 close the PCEP session. 285 If the peer has sent no PATH-SETUP-TYPE-CAPABILITY TLV, then the PCEP 286 speaker MUST infer that the peer supports path setup using at least 287 RSVP-TE. The PCEP speaker MAY also infer that the peer supports 288 other path setup types, but the means of inference are outside the 289 scope of this document. 291 When a PCC sends a PCReq message to a PCE ([RFC5440]), it MUST 292 include the PATH-SETUP-TYPE TLV in the RP object, unless the intended 293 PST is RSVP-TE, in which case it MAY omit the PATH-SETUP-TYPE TLV. 294 If the PCE is capable of expressing the path in a format appropriate 295 to the intended PST, it MUST use the appropriate ERO format in the 296 PCRep message. 298 When a PCE sends a PCRep message to a PCC ([RFC5440]), it MUST 299 include the PATH-SETUP-TYPE TLV in the RP object, unless the PST is 300 RSVP-TE, in which case it MAY omit the PATH-SETUP-TYPE TLV. If the 301 PCE does not support the intended PST, it MUST send a PCErr message 302 with Error-Type = 21 (Invalid traffic engineering path setup type) 303 and Error-Value = 1 (Unsupported path setup type) and close the PCEP 304 session. If the PSTs corresponding to the PCReq and PCRep messages 305 do not match, the PCC MUST send a PCErr message with Error-Type = 21 306 (Invalid traffic engineering path setup type) and Error-Value = 2 307 (Mismatched path setup type) and close the PCEP session. 309 When a stateful PCE sends a PCUpd message ([RFC8231]) or a PCInitiate 310 message ([RFC8281]) to a PCC, it MUST include the PATH-SETUP-TYPE TLV 311 in the SRP object, unless the intended PST is RSVP-TE, in which case 312 it MAY omit the PATH-SETUP-TYPE TLV. If the PCC does not support the 313 PST associated with the PCUpd or PCInitiate message, it MUST send a 314 PCErr message with Error-Type = 21 (Invalid traffic engineering path 315 setup type) and Error-Value = 1 (Unsupported path setup type) and 316 close the PCEP session. 318 When a PCC sends a PCRpt message to a stateful PCE ([RFC8231]), it 319 MUST include the PATH-SETUP-TYPE TLV in the SRP object, unless the 320 PST is RSVP-TE, in which case it MAY omit the PATH-SETUP-TYPE TLV. 321 The PCC MUST include the SRP object in the PCRpt message if the PST 322 is not RSVP-TE, even when the SRP-ID-number is the reserved value of 323 0x00000000. If the PCRpt message is triggered by a PCUpd or 324 PCInitiate message, then the PST that the PCC indicates in the PCRpt 325 MUST match the PST that the stateful PCE intended in the PCUpd or 326 PCInitiate. If it does not, then the PCE MUST send a PCErr message 327 with Error-Type = 21 (Invalid traffic engineering path setup type) 328 and Error-Value = 2 (Mismatched path setup type) and close the PCEP 329 session. 331 6. Manageability Considerations 333 This document generalises PCEP to allow path setup methods other than 334 RSVP-TE to be used by the network (but does not define any new path 335 setup types, besides RSVP-TE). It is possible that, in a given 336 network, multiple path setup methods will be used. It is also 337 possible that not all devices will support the same set of path setup 338 methods. Managing networks that combine multiple path setup methods 339 may therefore raise some challenges from a configuration and 340 observability point of view. 342 Each document that defines a new Path Setup Type in the Path Setup 343 Type Registry (Section 8.2) must include a manageability section. 344 The manageability section must explain how operators can manage PCEP 345 with the new path setup type. It must address the following 346 questions, which are generally applicable when working with multiple 347 path setup types in PCEP. 349 o What are the criteria for when devices will use the new path setup 350 type in PCEP, and how can the operator control this? 352 o How can the network be migrated to the new path setup type, and 353 are there any backwards compatibility issues that operators need 354 to be aware of? 356 o Are paths set up using the new path setup type intended to coexist 357 with other paths over the long term and, if so, how is this 358 situation managed with PCEP? 360 o How can operators verify the correct operation of PCEP in the 361 network with respect to the new path setup type? Which fault 362 conditions must be reported to the operators? 364 o Are there any existing management interfaces (such as YANG models) 365 that must be extended to model the operation of PCEP in the 366 network with respect to the new path setup type? 368 See [RFC5706] for further guidance on how to write manageability 369 sections in standards-track documents. 371 7. Security Considerations 373 The security considerations described in [RFC5440] and [RFC8281] are 374 applicable to this specification. No additional security measure is 375 required. 377 Note that, if the security mechanisms of [RFC5440] and [RFC8281] are 378 not used, then the protocol described by this draft could be attacked 379 in the following new way. An attacker, using a TCP man-in-the-middle 380 attack, could inject error messages into the PCEP session when a 381 particular PST is (or is not) used. By doing so, the attacker could 382 potentially force the use of a specific PST, which may allow them to 383 subsequently attack a weakness in that PST. 385 8. IANA Considerations 387 8.1. PCEP TLV Type Indicators 389 IANA is requested to confirm the early allocation of the following 390 code point in the PCEP TLV Type Indicators registry. 392 Value Description Reference 394 28 PATH-SETUP-TYPE This document 396 IANA is requested to allocate a new code point for the following TLV 397 in the PCEP TLV Type Indicators registry. 399 Value Description Reference 401 TBD1 PATH-SETUP-TYPE-CAPABILITY This document 403 Note to IANA: The above TLV type was not part of the early code point 404 allocation that was done for this draft. It was added to the draft 405 after the early code point allocation had taken place. Please assign 406 a code point from the indicated registry and replace each instance of 407 "TBD1" in this document with the allocated code point. 409 8.2. New Path Setup Type Registry 411 IANA is requested to create a new sub-registry within the "Path 412 Computation Element Protocol (PCEP) Numbers" registry called "PCEP 413 Path Setup Types". The allocation policy for this new registry 414 should be by IETF Review. The new registry should contain the 415 following value: 417 Value Description Reference 419 0 Path is setup using the RSVP- This document 420 TE signaling protocol. 422 8.3. PCEP-Error Object 424 IANA is requested to confirm the early allocation of the following 425 code-points in the PCEP-ERROR Object Error Types and Values registry. 427 Error-Type Meaning 428 10 Reception of an invalid object 430 Error-value=11: Malformed object 432 Error-Type Meaning 433 21 Invalid traffic engineering path setup type 435 Error-value=0: Unassigned 436 Error-value=1: Unsupported path setup type 437 Error-value=2: Mismatched path setup type 439 Note to IANA: the early allocation for Error-Type=10, Error-value=11 440 was originally done by draft-ietf-pce-segment-routing. However, we 441 have since moved its definition into this document. Therefore, 442 please update the reference for this Error-value in the indicated 443 registry to point to RFC.ietf-pce-lsp-setup-type. 445 9. Contributors 447 The following people contributed to this document: 449 - Jan Medved 450 - Edward Crabbe 452 10. Acknowledgements 454 We like to thank Marek Zavodsky for valuable comments. 456 11. References 458 11.1. Normative References 460 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 461 Requirement Levels", BCP 14, RFC 2119, 462 DOI 10.17487/RFC2119, March 1997, 463 . 465 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 466 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 467 DOI 10.17487/RFC5440, March 2009, 468 . 470 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 471 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 472 May 2017, . 474 [RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path 475 Computation Element Communication Protocol (PCEP) 476 Extensions for Stateful PCE", RFC 8231, 477 DOI 10.17487/RFC8231, September 2017, 478 . 480 [RFC8281] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "Path 481 Computation Element Communication Protocol (PCEP) 482 Extensions for PCE-Initiated LSP Setup in a Stateful PCE 483 Model", RFC 8281, DOI 10.17487/RFC8281, December 2017, 484 . 486 11.2. Informative References 488 [I-D.ietf-pce-segment-routing] 489 Sivabalan, S., Filsfils, C., Tantsura, J., Henderickx, W., 490 and J. Hardwick, "PCEP Extensions for Segment Routing", 491 draft-ietf-pce-segment-routing-11 (work in progress), 492 November 2017. 494 [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation 495 Element (PCE)-Based Architecture", RFC 4655, 496 DOI 10.17487/RFC4655, August 2006, 497 . 499 [RFC4657] Ash, J., Ed. and J. Le Roux, Ed., "Path Computation 500 Element (PCE) Communication Protocol Generic 501 Requirements", RFC 4657, DOI 10.17487/RFC4657, September 502 2006, . 504 [RFC5706] Harrington, D., "Guidelines for Considering Operations and 505 Management of New Protocols and Protocol Extensions", 506 RFC 5706, DOI 10.17487/RFC5706, November 2009, 507 . 509 Authors' Addresses 511 Siva Sivabalan 512 Cisco Systems, Inc. 513 2000 Innovation Drive 514 Kanata, Ontario K2K 3E8 515 Canada 517 Email: msiva@cisco.com 518 Jeff Tantsura 519 Nuage Networks 520 755 Ravendale Drive 521 Mountain View, CA 94043 522 USA 524 Email: jefftant.ietf@gmail.com 526 Ina Minei 527 Google, Inc. 528 1600 Amphitheatre Parkway 529 Mountain View, CA 94043 530 USA 532 Email: inaminei@google.com 534 Robert Varga 535 Pantheon Technologies SRO 536 Mlynske Nivy 56 537 Bratislava, 821 05 538 Slovakia 540 Email: nite@hq.sk 542 Jon Hardwick 543 Metaswitch Networks 544 100 Church Street 545 Enfield, Middlesex 546 UK 548 Email: jonathan.hardwick@metaswitch.com