idnits 2.17.1 draft-chunduri-ospf-operator-defined-tlvs-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (January 5, 2016) is 3027 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: 'I-D.ietf-ospf-node-admin-tag' is defined on line 327, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-ospf-transport-instance' is defined on line 333, but no explicit reference was found in the text ** Obsolete normative reference: RFC 4970 (Obsoleted by RFC 7770) == Outdated reference: A later version (-09) exists of draft-ietf-ospf-node-admin-tag-02 Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group U. Chunduri, Ed. 3 Internet-Draft Ericsson Inc. 4 Intended status: Standards Track X. Xu 5 Expires: July 8, 2016 Huawei 6 L. Contreras 7 Telefonica I+D 8 M. Boucadair, Ed. 9 France Telecom 10 L. Jalil 11 Verizon 12 January 5, 2016 14 Using Operator-defined TLVs for Agile Service Deployment 15 draft-chunduri-ospf-operator-defined-tlvs-02 17 Abstract 19 This document proposes a TLV within the body of the OSPF Router 20 Information (RI) Opaque LSA, called Operator-defined Sub-TLV 21 Container TLV. Here the term OSPF means both OSPFv2 and OSPFv3.This 22 attribute is meant to accommodate policy-based and deployment- 23 specific use cases. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on July 8, 2016. 42 Copyright Notice 44 Copyright (c) 2016 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 respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 60 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 61 2. A Sample Use Case . . . . . . . . . . . . . . . . . . . . . . 3 62 3. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 4 63 4. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 64 5. Operator-defined Sub-TLV Container TLV . . . . . . . . . . . 4 65 6. Operator-defined Sub-TLV . . . . . . . . . . . . . . . . . . 5 66 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 67 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 68 9. Security Considerations . . . . . . . . . . . . . . . . . . . 7 69 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 70 10.1. Normative References . . . . . . . . . . . . . . . . . . 7 71 10.2. Informative References . . . . . . . . . . . . . . . . . 8 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 74 1. Introduction 76 There are some use cases where OSPF is used for service auto- 77 discovery by using node administrative tags [I-D.ietf-ospf-node- 78 admin-tag] . One major benefit of using administrative tags rather 79 than IANA defined TLVs or sub-TLVs to indicate different services is 80 to facilitate the rapid deployment of new services without any need 81 for the standardization of those TLVs or sub-TLVs. However, there 82 are some special use cases where the service to be advertised has one 83 or more attributes which need to be advertised as well. In such 84 case, the administrative tag is not much applicable anymore. 86 To inherit the benefit of administrative tags (i.e., allowing 87 operators to use OSPF for service auto-discovery without the need of 88 any standardization process) while meeting the requirement of 89 advertising services and their associated attributes, this document 90 proposes a TLV within the body of the OSPF Router Information (RI) 91 Opaque LSA, called Operator-defined Sub-TLV Container TLV. With such 92 TLV, operators could flexibly define one or more sub-TLVs indicating 93 one or more services and their associated attributes without relying 94 on any standardization process. This document gives a framework 95 where operator information can be transparently injected into the 96 routing domain. 98 The characterization of the TLV and its associated sub-SLVs is local 99 to the each administrative domain. Defining new sub-TLVs is 100 therefore deployment-specific and policy-based. OSPF here denotes 101 both OSPFv2 and OSPFv3. 103 1.1. Requirements Language 105 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 106 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 107 document are to be interpreted as described in RFC 2119 [RFC2119]. 109 2. A Sample Use Case 111 This section describes a use case example to illustrate the use of 112 the Operator-defined Sub-TLV Container TLV defined in Section 5. It 113 shows how operators can deploy services rapidly by advertising 114 associated attributes. It is out of scope of this section to 115 identify an exhaustive list of deployment use cases. 117 In the context of service function chaining ([RFC7665]), advertising 118 Service Functions and it's attributes will ease automating how 119 service chains are structured and will help policy decision engines 120 (typically, a controller) to selectively direct the traffic to 121 appropriate service function instances according to a set policy 122 guidelines and/or the information reported in the Operator-defined 123 Sub-TLV. 125 Particularly, Service Function nodes implementing various service 126 functions within the network need to advertise each service function 127 they are offering, so that a control and/or management entity can 128 decide which instance to invoke for the delivery of an added- value 129 service or to react to particular events (such as failure of a 130 service function instance). 132 Each service can be identified by a dedicated sub-TLV type while the 133 associated attributes/identifiers of the service are indicated by the 134 value part of the corresponding sub-TLV. These identifiers MAY not 135 be globally unique and MAY not be exposed outside of a given 136 administrative domain. 138 The Operator-defined sub-TLV Container TLV could appear multiple 139 times within a given Router Information (RI) Opaque LSA, when more 140 than one service function instances needs to be advertised by a given 141 node based on a local policy. 143 Advertising service functions and it's attributes also allow a 144 controller to adjust its policies and react dynamically. Typical 145 actions would be, to withdraw a service instance from being invoked 146 in the context of a service delivery, update load balancing polices, 147 dynamically activate a backup instance, etc. 149 The mechanisms, on how service information and attributes are used by 150 an external controller (for example to steer the traffic) is beyond 151 the scope of this document. 153 3. Applicability 155 This mechanism MUST only be used for local applications or non- 156 standard commercial applications. If the information injected in 157 this attribute requires a specific handling from an OSPF speaker 158 other than reading configuration parameters and encode it as 159 described in this document, then those MUST NOT be advertised through 160 this mechanism. 162 The attribute in this document is operator-defined. As such, it is 163 the responsibility of the provider to decide which information can be 164 conveyed as per the pre-defined format specific to the deployment by 165 means of the operator-defined attributes. 167 4. Terminology 169 This memo makes use of the terms defined in [RFC4970]. 171 5. Operator-defined Sub-TLV Container TLV 173 A new TLV within the body of the OSPFv2 and OSPFv3 RI Opaque LSA, 174 called Operator-defined Sub-TLV Container TLV is defined to carry one 175 or more operator-defined sub-TLVs. 177 The format of the Operator-defined Sub-TLV Container TLV is shown in 178 Figure 1. 180 0 1 2 3 181 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 182 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 183 | Type | Length | 184 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 185 | First Operator-defined Sub-TLV | 186 o o 187 | | 188 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 189 // ... // 190 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 191 | Last Operator-defined Sub-TLV | 192 o o 193 | | 194 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 196 Figure 1: Operator-defined Sub-TLV Container TLV 198 Type: TBD Section 8 200 Length: A 16-bit field that indicates the length of the value portion 201 in octets. It MUST be multiple of 4 octets dependent on the number 202 of Operator-defined Sub-TLVs advertised. 204 Value: Contains one or more nested TLV triplets of operator-defined 205 sub-TLVs as defined in Section 6. 207 There can be more than one TLV of these possible and the flooding 208 scope of this TLV depends on the application. Being part of the RI 209 Opaque LSA, the Operator-defined sub-TLV Container TLV inherits 210 applicability as well as restrictions as specified in Section 3 of 211 [RFC4970]. 213 6. Operator-defined Sub-TLV 215 The operator-defined sub-TLV has the following structure and can be 216 part of the Container TLV as defined in Section 5 within the body of 217 the OSPF RI LSA. 219 0 1 2 3 220 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 221 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 222 | Type | Length | 223 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 224 | Attribute Length | Attribute Value (variable) | 225 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 226 // ... // 227 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 228 | Attribute Length | Attribute Value (variable) | 229 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 231 Figure 2: Operator-defined Sub-TLV 233 Type: Per Operator/Local Policy. 235 Length: A 16-bit field that indicates the length of the value portion 236 in octets and will be padded/formatted as described in Section 2.1 of 237 [RFC4970]. 239 Value: Represents the associated attribute of the service or Type 240 defined locally (i.e., within a single administrative domain). The 241 Value field contains one or more {Attribute-Len, Attribute-value} 242 tuple. Attribute Length is of 2 bytes, for fixed formatting and 243 Attribute value as represented by attribute length. All multi byte 244 attribute values MUST be encoded in Network Byte Order (NBO). If 245 multiple fixed length values have to be represented, those SHOULD be 246 represented with multiple {Attribute-Len, Attribute-value} tuples. 248 The meaning of the operator-defined sub-TLV is totally opaque to OSPF 249 and is defined by the network local policy and is controlled via 250 configuration. The application that needs to consume the data 251 defined is likely to implement some validation checks. 253 Routers advertising the operator-defined sub-TLV are configured to do 254 so without knowing (or even explicitly supporting) functionality 255 implied by the sub-TLV. 257 How a receiving node communicates the operator-defined sub-TLVs with 258 the policy manager is outside the scope of this document. 260 The operator-defined TLV is formatted as described in Section 2.1 of 261 [RFC4970]. However, the code points of operator-defined sub-TLVs as 262 defined above are allocated by operators themselves, specific to the 263 deployment rather than IANA. Furthermore, the semantics of the 264 operator-defined sub-TLV order has no meaning. That is, there is no 265 implied meaning to the ordering of the operator-defined sub-TLV that 266 indicates a certain operation or set of operations that need to be 267 performed based on the ordering. The ordering of operator-defined 268 sub-TLVs and the interpretation of the operator-defined sub-TLV is 269 deployment-specific. Routers can be configured with local policies 270 if the order of sub-TLV must be preserved. How a router is 271 configured with additional instructions (such as order preservation) 272 is implementation-specific. 274 It is reasonable that non-routing information should be advertise in 275 a non-routing instance of OSPF as defined in [I-D.ietf-ospf- 276 transport-instance] so as to minimize the impact on the operation of 277 routing. However, since the information contained in the self- 278 defined sub-TLV may be related to the routing, whether or not using a 279 non-routing instance to flood the self-defined sub-TLVs should be 280 determined by operators according to the information to be conveyed 281 by the self-defined sub-TLV. 283 7. Acknowledgements 285 Authors would like to thank Acee Lindem for reviewing and providing 286 suggestions on the initial version of the document. Also thankful to 287 Anton Smirnov, Peter Psenak, Chris Bowers and Les Ginsberg for their 288 review and comments. 290 8. IANA Considerations 292 This document includes a request to IANA to allocate a TLV type code 293 for the new RI LSA TLV proposed in Section 5 of this document from 294 OSPF Router Information (RI) TLVs Registry defined by [RFC4970]. 296 9. Security Considerations 298 As Operator Defined TLV specified in this draft is part of RI LSA, 299 this document does not introduce any new security risk other than 300 what is specified by [RFC4970]. Security considerations for the base 301 OSPF protocol are covered in [RFC2328] and [RFC5340]. 303 10. References 305 10.1. Normative References 307 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 308 Requirement Levels", BCP 14, RFC 2119, 309 DOI 10.17487/RFC2119, March 1997, 310 . 312 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, 313 DOI 10.17487/RFC2328, April 1998, 314 . 316 [RFC4970] Lindem, A., Ed., Shen, N., Vasseur, JP., Aggarwal, R., and 317 S. Shaffer, "Extensions to OSPF for Advertising Optional 318 Router Capabilities", RFC 4970, DOI 10.17487/RFC4970, July 319 2007, . 321 [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF 322 for IPv6", RFC 5340, DOI 10.17487/RFC5340, July 2008, 323 . 325 10.2. Informative References 327 [I-D.ietf-ospf-node-admin-tag] 328 Hegde, S., Raghuveer, H., Gredler, H., Shakir, R., 329 Smirnov, A., Li, Z., and B. Decraene, "Advertising per- 330 node administrative tags in OSPF", draft-ietf-ospf-node- 331 admin-tag-02 (work in progress), June 2015. 333 [I-D.ietf-ospf-transport-instance] 334 Lindem, A., Roy, A., and S. Mirtorabi, "OSPF Transport 335 Instance Extensions", draft-ietf-ospf-transport- 336 instance-11 (work in progress), June 2014. 338 [RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function 339 Chaining (SFC) Architecture", RFC 7665, 340 DOI 10.17487/RFC7665, October 2015, 341 . 343 Authors' Addresses 345 Uma Chunduri (editor) 346 Ericsson Inc. 347 300 Holger Way, 348 San Jose, California 95134 349 USA 351 Phone: 408 750-5678 352 Email: uma.chunduri@ericsson.com 354 Xiaohu Xu 355 Huawei 357 Email: xuxiaohu@huawei.com 358 Luis M. Contreras 359 Telefonica I+D 360 Ronda de la Comunicacion, s/n 361 Sur-3 building, 3rd floor 362 Madrid 28050 363 Spain 365 Email: luismiguel.contrerasmurillo@telefonica.com 366 URI: http://people.tid.es/LuisM.Contreras/ 368 Mohamed Boucadair (editor) 369 France Telecom 370 Rennes 35000 371 France 373 Email: mohamed.boucadair@orange.com 375 Luay Jalil 376 Verizon 377 400 International Parkway 378 Richardson, Tx 75081 379 USA 381 Email: luay.jalil@verizon.com