idnits 2.17.1 draft-zhang-ccamp-route-exclusion-pathkey-01.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 : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. (A line matching the expected section header was found, but with an unexpected indentation: ' 1. Introduction' ) ** The document seems to lack an Authors' Addresses Section. ** There is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 29 has weird spacing: '... months and ...' == Line 30 has weird spacing: '... at any time...' == Line 31 has weird spacing: '...ference mate...' -- Couldn't find a document date in the document -- date freshness check skipped. 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: 'RFC4655' is mentioned on line 256, but not defined == Outdated reference: A later version (-21) exists of draft-ietf-pce-stateful-pce-06 Summary: 3 errors (**), 0 flaws (~~), 6 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 CCAMP Working Group Xian Zhang 2 Internet Draft Fatai Zhang 3 Category: Standards track Huawei 4 O. Gonzalez de Dios 5 Telefonica I+D 6 Igor Bryskin 7 ADVA Optical Networking 8 Dhruv Dhody 9 Huawei 11 Expires: August 13, 2014 February 14, 2014 13 Extensions to Resource ReSerVation Protocol-Traffic Engineering (RSVP- 14 TE) to Support Route Exclusion Using Path Key Subobject 16 draft-zhang-ccamp-route-exclusion-pathkey-01.txt 18 Status of this Memo 20 This Internet-Draft is submitted to IETF in full conformance with 21 the provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF), its areas, and its working groups. Note that 25 other groups may also distribute working documents as Internet- 26 Drafts. 28 Internet-Drafts are draft documents valid for a maximum of six 29 months and may be updated, replaced, or obsoleted by other 30 documents at any time. It is inappropriate to use Internet-Drafts 31 as reference material or to cite them other than as "work in 32 progress." 34 The list of current Internet-Drafts can be accessed at 35 http://www.ietf.org/ietf/1id-abstracts.txt. 37 The list of Internet-Draft Shadow Directories can be accessed at 38 http://www.ietf.org/shadow.html. 40 This Internet-Draft will expire on August 13, 2014. 42 Copyright Notice 44 Copyright (c) 2014 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with 52 respect to this document. Code Components extracted from this 53 document must include Simplified BSD License text as described in 54 Section 4.e of the Trust Legal Provisions and are provided without 55 warranty as described in the Simplified BSD License. 57 Requirements Language 59 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 60 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 61 document are to be interpreted as described in [RFC2119]. 63 Abstract 65 This document extends the Resource ReSerVation Protocol-Traffic 66 Engineering (RSVP-TE) eXclude Route Object (XRO) and Explicit 67 eXclusion Route Subobject (EXRS) within Explicit Route Object (ERO) 68 to support specifying route exclusion requirement using Path Key 69 Subobject (PKS). 71 Table of Contents 73 1. Introduction ................................................ 3 74 1.1. Example Use ............................................ 3 75 2. RSVP-TE Extensions .......................................... 4 76 2.1. Path Key Subobject (PKS)................................ 4 77 2.2. PKS Processing Rules.................................... 5 78 3. Other considerations......................................... 6 79 3.1. Path-Key Retention and Reuse............................ 6 80 3.2. Path-Key Uniqueness..................................... 7 81 3.3. PKS Update ............................................. 7 82 4. Manageability Considerations .................................7 83 4.1. Control of Function through Configuration and Policy.....7 84 5. Security Considerations...................................... 8 85 6. IANA Considerations ......................................... 8 86 6.1. New Subobject Type...................................... 8 87 6.2. New Error Code ......................................... 8 88 7. Acknowledgments ............................................. 9 89 8. References .................................................. 9 90 8.1. Normative References.................................... 9 91 8.2. Informative References.................................. 9 92 9. Contributors ................................................ 9 93 10. Authors' Addresses ......................................... 9 95 1. Introduction 97 [RFC5520] defines the concept of a Path Key for confidentiality in a 98 multi-domain environment. This can be used by a Path Computation 99 Element (PCE) in place of a segment of a path that it wishes to keep 100 confidential. The Path Key can be signaled in Resource ReSerVation 101 Protocol-Traffic Engineering (RSVP-TE) protocol by placing it in an 102 Explicit Route Object (ERO) as described in [RFC5553]. 104 When establishing a set of LSPs to provide protection services 105 [RFC4427], it is often desirable that the LSPs should take different 106 paths through the network. This can be achieved by path computation 107 entities that have full end-to-end visibility, but it is more 108 complicated in multi-domain environments when segments of the path 109 may be hidden so that they are not visible outside the domain they 110 traverse. 112 This document describes how the Path Key object can be used in the 113 RSVP-TE eXclude Route Object (XRO), and the Explicit eXclusion Route 114 subobject (EXRS) of the ERO in order to facilitate path hiding, but 115 allow diverse end-to-end paths to be established in multi-domain 116 environments. 118 1.1. Example Use 120 Figure 1 shows a simple network with two domains. It is desired to 121 set up a pair of path-disjoint LSPs from the source in Domain 1 to 122 the destination in Domain 2, but the domains keep strict 123 confidentiality about all path and topology information. 125 The first LSP will be signaled by the source with ERO {A, B, loose 126 Dst} and will be set up with the path {Src, A, B, U, V, W, Dst}. But 127 when sending the RRO out of Domain 2, node U would normally strip 128 the path and replace it with a loose hop to the destination. With 129 this limited information, the source is unable to include enough 130 detail in the ERO of the second LSP to avoid it taking, for example, 131 the path {Src, C, D, X, V, W, Dst} which is not path-disjoint. 133 --------------------- ----------------------------- 134 | Domain 1 | | Domain 2 | 135 | | | | 136 | --- --- | | --- --- --- | 137 | | A |--| B |--+--+--| U |--| V |---| W | | 138 | / --- --- | | --- --- --- \ | 139 | ---/ | | / / \--- | 140 | |Src| | | / / |Dst| | 141 | ---\ | | / / /--- | 142 | \ --- --- | | --- / --- / --- / | 143 | | C |--| D |--+--+--| X |---| Y |--| Z | | 144 | --- --- | | --- --- --- | 145 | | | | 146 --------------------- ----------------------------- 148 Figure 1: A Simple Multi-Domain Network 150 In order to improve the outcome, node U can replace the path segment 151 {U, V, W} in the RRO with a Path Key Suboject. The Path Key 152 Subobject assigns an identifier to the key and also indicates that 153 it was node U that made the replacement. 155 With this additional information, the source is able to signal the 156 second LSP with ERO set to {C, D, exclude Path Key(EXRS), loose Dst}. 157 When the signaling message reaches node X, it can consult node U to 158 expand the Path Key and so know to avoid the path of the first LSP. 159 Alternatively, the source could use an ERO of {C, D, loose Dst} and 160 include an XRO containing the Path Key. 162 This example uses a PCE deployed in each border router, having at 163 least the capability to expand PKS. Other deployment scenarios 164 (Domain PCE, PCE being part of the Management system) may be used. 166 2. RSVP-TE Extensions 168 This section defines the Path Key Subobject that can be either in 169 the XRO object or Explicit eXclusion Route subobject (EXRS) as 170 defined in [RFC4874]. 172 2.1. Path Key Subobject (PKS) 174 The IPv4 PKS has the same format as defined in [RFC5553] and is 175 detailed as below: 177 0 1 2 3 178 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 179 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 180 |L| Type | Length | Path Key | 181 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 182 | PCE-ID (4 bytes) | 183 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 185 The meaning of the field Length and Path Key is defined in [RFC5553]. 187 L: 0 indicates that the path or path segment hidden with the Path 188 Key specified MUST be excluded. 1 indicates that the path or path 189 segment hidden with the Path Key specified SHOULD be avoided. 191 Type: sub-object type for XRO Path Key; TBD. 193 PCE-ID: The IPv4 address of a node that assigned the Path Key 194 identifier and that can return an expansion of the Path Key or use 195 the Path Key as an exclusion in a path computation. Note this draft 196 does not confine whether it is the network element or a dedicated 197 server for path key generation and decoding. 199 Similarly, the format of IPv6 PKS is as follows: 201 0 1 2 3 202 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 203 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 204 |L| Type | Length | Path Key | 205 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 206 | PCE-ID (16 bytes) | 207 | | 208 | | 209 | | 210 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 212 2.2. PKS Processing Rules 214 The exclude route list is encoded as a series of subobjects 215 contained in an EXCLUDE_ROUTE object or an EXRS of the ERO. Multiple 216 Path-Keys may be included in XRO or EXRO of ERO if more than segment 217 of a path are kept hidden during diverse path establishment. The 218 procedure defined in [RFC4874] for processing XRO and EXRS is not 219 changed by this document. 221 Irrespective of the L flag, if the node, receiving the PKS, cannot 222 recognize the subobject, it will react according to [RFC4874] and 223 SHOULD ignore the constraint. 225 Otherwise, if it decodes the PKS but cannot find a route/route 226 segment meeting the constraint: 228 -if L flag is set to 0, it will react according to [RFC4874] and 229 SHOULD send a PathErr message with the error code/value 230 combination "Routing Problem" / "Route Blocked by Exclude Route". 232 -if L flag is set to 1, which means the node SHOULD try to be as 233 much diversified as possible with the specified resource. If it 234 cannot fully support the constraint, it SHOULD send a PathErr 235 message with the error code/value combination "Notify Error" / 236 "Fail to find diversified path" (TBD). 238 If it cannot decode the PKS, the error handling procedure defined in 239 Section 3.1 of [RFC5553] is not changed by this document. 241 This mechanism can work with all the PKS resolution mechanism, as 242 detailed in [RFC5553] section 3.1. A PCE, co-located or not, may be 243 used to resolve the PKS, but the node (i.e., a Label Switcher 244 Router(LSR)) can also use the PKS information to index a Path 245 Segment previously supplied to it by the entity that originated the 246 PKS, for example the LSR that inserted the PKS in the RRO or a 247 management system. 249 3. Other considerations 251 3.1. Path-Key Retention and Reuse 253 The use of the path key relies on the availability of a PCE function 254 supporting [RFC5520] functionality. 256 Following [RFC4655] a simple deployment option is when the PCE 257 function is collocated with each border domain node generating the 258 RRO. This collocated PCE functionality can be restricted to only 259 serve the PKS resolution. This PCE function is only required to be 260 accessible to the nodes excluding this PKS, so this can be 261 restricted to one domain. This option can very easily tie the 262 lifetime of the PKS to the lifetime of the LSP. 264 Alternatively, if a dedicated server, such as a PCE, is in charge of 265 this, it may need to be explicitly informed of the LSP tear-down in 266 order to recycle the path key allocated already. This can be easily 267 supported by a stateful PCE [Stateful-PCE]. Note this draft does not 268 confine the methods for path key generation and decoding. 270 Last, options including allowing a LSR can use the PKS information 271 to index a Path Segment previously supplied to it by the entity that 272 originated the PKS, for example the LSR that inserted the PKS in the 273 RRO or a management system, can also be used. 275 3.2. Path-Key Uniqueness 277 In the CCAMP mailing list, there is concern about whether 16-bit 278 Path key is still enough and future proof. This can be easily solved 279 by confining the scope of a path key. If an ingress node is 280 responsible for managing the Path Key, it should not be an issue 281 since the LSP across domains do not expected to be larger than 65535. 282 On the other hand, if a dedicated entity, such as a PCE server, is 283 used to allocate and recycle the Path Key, it is advised to allocate 284 the Path Key per ingress node basis to avoid the limitation of Path 285 Key numbers facing a domain-based allocation space. These are only 286 illustrative examples and other methods that can guarantee the 287 uniqueness of Path-Key are not precluded. 289 3.3. PKS Update 291 When the information of a path is changed, the LSPs using that path 292 and corresponding PKS should be aware of the changes. The 293 procedures defined in Section 4.4.3 of RFC 3209 [RFC3209] MUST be 294 used to refresh the PKS information if the PKS change is to be 295 communicated to other nodes according to the local node's policy. 296 If local policy is that the PKS change should be suppressed or would 297 result in no change to the PKS expansion, the node does not need to 298 send an update. This procedure allows for ingress node to react on 299 path change. 301 4. Manageability Considerations 303 4.1. Control of Function through Configuration and Policy 305 In addition to the set of policies described in [RFC5553] the 306 following policies (are local and domain-wide) SHOULD be available 307 for configuration in an implementation: 309 - Handling a XRO or EXRS containing a PKS. As described in Section 310 2.2, an LSR that receives a Path message containing a PKS exclusion 311 can be configured to reject the Path message according to policy. 313 - Hiding of reason codes. The policy described in [RFC5553] section 314 5.1 is also applicable to policies for PKS in XRO or EXRS. 316 This document makes no other new management consideration to RSVP 317 and PCE, the existing consideration applies. 319 5. Security Considerations 321 The use of path keys proposed in this draft allows nodes to hide 322 parts of the path as it is signaled. This can be used to improve the 323 confidentially of the LSP setup. Moreover, it may serve to improve 324 security of the control plane for the LSP as well as data plane 325 traffic carried on this LSP. However, the benefits of using path key 326 are lost unless there is an appropriate access control of any tool 327 that allows expansion of the path key. 329 6. IANA Considerations 331 6.1. New Subobject Type 333 IANA registry: RSVP PARAMETERS 334 Subsection: Class Names, Class Numbers, and Class Types 336 This document introduces two new subobjects for the EXCLUDE_ROUTE 337 object [RFC4874], C-Type 1. 339 Subobject Type Subobject Description 341 -------------- --------------------- 343 64(TBD by IANA) IPv4 Path Key Subobject 345 65(TBD By IANA) IPv6 Path Key Subobject 347 Note: [RFC5520] defines the PKS for use in PCEP. The above number 348 suggestions for use in RSVP-TE follow that assigned for the PKS in 349 PCEP [RFC5520]. 351 6.2. New Error Code 353 IANA registry: RSVP PARAMETERS 355 Subsection: Error Codes and Globally-Defined Error Value Sub-Codes 357 New Error Values sub-codes have been registered for the Error Code 358 'Notify Error' (25). 360 TBD = "Fail to find diversified path" 362 7. Acknowledgments 364 The authors would like to thank John Drake, Daniele Ceccarelli and 365 Zafar Ali for their comments and dicussions. 367 8. References 369 8.1. Normative References 371 [RFC2119] Bradner, S., "Key words for use in RFCs to indicate 372 requirements levels", RFC 2119, March 1997. 374 [RFC3209] D. Awduche et al, "RSVP-TE: Extensions to RSVP for LSP 375 Tunnels", RFC3209, December 2001. 377 [RFC4874] CY. Lee, A. Farrel, S. De Cnodder, "Exclude Routes - 378 Extension to Resource ReserVation Protocol-Traffic 379 Engineering (RSVP-TE), RFC4874, April 2007. 381 [RFC5553] A. Farrel, Ed., "Resource Reservation Protocol (RSVP) 382 Extensions for Path Key Support", RFC5553, May 2009. 384 8.2. Informative References 386 [RFC5520] R. Bradford, Ed., "Preserving Topology Confidentiality 387 in Inter-Domain Path Computation Using a Path-Key-Based 388 Mechanism", RFC5520, April 2009. 390 [RFC4427] E. Mannie, Ed., "Recovery (Protection and Restoration) 391 Terminology for Generalized Multi-Protocol Label 392 Switching (GMPLS)", RFC4427, March 2006. 394 [Stateful-PCE] Crabbe, E., Medved, J., Minei, I., and R. Varga, 395 "PCEP Extensions for Stateful PCE", draft-ietf-pce- 396 stateful-pce-06 (work in progress), August 2013. 398 9. Contributors 400 Cyril 401 cyril.margaria@gmail.com 403 10. Authors' Addresses 404 Xian Zhang 405 Huawei Technologies 407 Email: zhang.xian@huawei.com 409 Fatai Zhang 410 Huawei Technologies 412 Email: zhangfatai@huawei.com 414 Oscar Gonzalez de Dios 415 Telefonica I+D 416 Don Ramon de la Cruz 417 Madrid, 28006 418 Spain 420 Phone: +34 913328832 421 Email: ogondio@tid.es 423 Igor Bryskin 424 ADVA Optical Networking 426 Email: ibryskin@advaoptical.com 428 Dhruv Dhody 429 Huawei Technologies 430 Leela Palace 431 Bangalore, Karnataka 560008 432 INDIA 434 EMail: dhruv.ietf@gmail.com