Network Working Group U. Chunduri Internet-Draft Ericsson Inc. Intended status: Standards Track X. Xu Expires: September 10, 2015 Huawei L. Contreras Telefonica I+D M. Boucadair France Telecom March 9, 2015 Using Self-defined Sub-TLVs for Agile Service Deployment draft-chunduri-ospf-self-defined-sub-tlvs-03 Abstract This document proposes a TLV within the body of the OSPF Router Information (RI) Opaque LSA, called Self-defined Sub-TLV Container TLV. Here the term OSPF means both OSPFv2 and OSPFv3.This attribute is meant to accommodate policy-based and deployment-specific use cases. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on September 10, 2015. Copyright Notice Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents Chunduri, et al. Expires September 10, 2015 [Page 1] Internet-Draft Self-defined Sub-TLVs March 2015 carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 2. Sample Use Cases . . . . . . . . . . . . . . . . . . . . . . 3 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 4. Self-defined Sub-TLV Container TLV . . . . . . . . . . . . . 4 5. Self-defined Sub-TLV . . . . . . . . . . . . . . . . . . . . 5 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 8. Security Considerations . . . . . . . . . . . . . . . . . . . 6 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 9.1. Normative References . . . . . . . . . . . . . . . . . . 6 9.2. Informative References . . . . . . . . . . . . . . . . . 6 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 1. Introduction There are some use cases where OSPF is used for service auto- discovery by using node administrative tags [I-D.ietf-ospf-node- admin-tag] . One major benefit of using administrative tags rather than IANA defined TLVs or sub-TLVs to indicate different services is to facilitate the rapid deployment of new services without any need for the standardization of those TLVs or sub-TLVs. However, there are some special use cases where the service to be advertised has one or more attributes which need to be advertised as well. In such case, the administrative tag is not much applicable anymore. To inherit the benefit of administrative tags (i.e., allowing operators to use OSPF for service auto-discovery without the need of any standardization process) while meeting the requirement of advertising services and their associated attributes, this document proposes a TLV within the body of the OSPF Router Information (RI) Opaque LSA, called Self-defined Sub-TLV Container TLV. With such TLV, operators could flexibly define one or more sub-TLVs indicating one or more services and their associated attributes without relying on any standardization process. The characterization of the TLV and its associated sub-SLVs is local to the each administrative domain. Defining new sub-TLVs is therefore deployment-specific and policy-based. OSPF denotes both OSPFv2 and OSPFv3. Chunduri, et al. Expires September 10, 2015 [Page 2] Internet-Draft Self-defined Sub-TLVs March 2015 1.1. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. 2. Sample Use Cases There can be several possible use cases and applications for Self- defined Sub-TLV Container TLV defined in Section 4. This section provides few examples how operators can deploy services rapidly by advertising associated attributes. However, the illustrations listed below are not meant to be restrictive or exhaustive. o Advertising Service Functions and it's attributes Service Function nodes implementing various service functions within the network need to advertise each service function they are offering so that a control and/or management entity can decide which instance to invoke for the delivery of an added- value service or to react to particular events (such as failure of a service function instance). Each service can be identified by a dedicated sub-TLV type while the associated attributes/identifiers of the service are indicated by the value part of the corresponding sub-TLV. These identifiers MAY not be globally unique and MAY not be exposed outside of a given administrative domain. The Self-defined sub-TLV Container TLV could appear multiple times within a given Router Information (RI) Opaque LSA, when more than one service function instances needs to be advertised by a given node based on a local policy. Advertising service functions and it's attributes also allow the controller to adjust its policies and react dynamically. Typical actions would be, to withdraw a service instance from being invoked in the context of a service delivery, update load balancing polices, dynamically activate a backup instance, etc. The mechanisms, on how service information and attributes are used by an external controller (for example to steer the traffic) is beyond the scope of this document. o Dissemination of dynamic information It's possible for operators to disseminate the node local information like energy efficiency, congestion information, certain critical node statistics periodically to an external controller managing the network. How a Controller uses this information is beyond the scope of this document. Chunduri, et al. Expires September 10, 2015 [Page 3] Internet-Draft Self-defined Sub-TLVs March 2015 3. Terminology This memo makes use of the terms defined in [RFC4970]. 4. Self-defined Sub-TLV Container TLV A new TLV within the body of the OSPFv2 and OSPFv3 RI Opaque LSA, called Self-defined Sub-TLV Container TLV is defined to carry one or more self-defined sub-TLVs. The format of the Self-defined Sub-TLV Container TLV is shown in Figure 1. 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | First Self-defined Sub-TLV | o o | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ // ... // +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Last Self-defined Sub-TLV | o o | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1: Self-defined Sub-TLV Container TLV Type: TBD Section 7 Length: A 16-bit field that indicates the length of the value portion in octets. It MUST be multiple of 4 octets dependent on the number of Self-defined Sub-TLVs advertised. Value: Contains one or more nested TLV triplets of self-defined sub- TLVs as defined in Section 5. There can be more than one TLV of these possible and the flooding scope of this TLV depends on the application. Being part of the RI Opaque LSA, the Self-defined sub-TLV Container TLV inherits applicability as well as restrictions as specified in Section 3 of [RFC4970]. Chunduri, et al. Expires September 10, 2015 [Page 4] Internet-Draft Self-defined Sub-TLVs March 2015 5. Self-defined Sub-TLV The self-defined sub-TLV has the following structure and can be part of the Container TLV as defined in Section 4 within the body of the OSPF RI LSA. 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Attribute Length | Attribute Value (variable) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Attribute Length | Attribute Value (variable) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2: Self-defined Sub-TLV Type: Per Operator/Local Policy. Length: A 16-bit field that indicates the length of the value portion in octets and will be padded/formatted as described in Section 2.1 of [RFC4970]. Value: Represents the associated attribute of the service or Type defined locally (i.e., within a single administrative domain). The Value field contains one or more {Attribute-Len, Attribute-value} tuple. Attribute Length is of 2 bytes, for fixed formatting and Attribute value as represented by attribute length. The meaning of the self-defined sub-TLV is totally opaque to OSPF. Routers advertising the self-defined sub-TLV are configured to do so without knowing (or even explicitly supporting) functionality implied by the sub-TLV. The meaning of a self-defined sub-TLV is defined by the network local policy and is controlled via configuration. How a receiving node communicates the self-defined sub-TLVs with the policy manager is outside the scope of this document. There is no need for any specification to define any self-defined sub-TLV. Furthermore, the semantics of the self-defined sub-TLV order has no meaning. That is, there is no implied meaning to the ordering of the self-defined sub-TLV that indicates a certain operation or set of operations that need to be performed based on the Chunduri, et al. Expires September 10, 2015 [Page 5] Internet-Draft Self-defined Sub-TLVs March 2015 ordering. The ordering of self-defined sub-TLVs and the interpretation of the self-defined sub-TLV is deployment-specific. Routers can be configured with local policies if the order of sub-TLV must be preserved. How a router is configured with additional instructions (such as order preservation) is implementation-specific. 6. Acknowledgements Authors would like to thank Acee Lindem for reviewing and providing suggestions on the initial version of the document. Also thankful to Anton Smirnov, Peter Psenak and Les Ginsberg for their review and comments. 7. IANA Considerations This document includes a request to IANA to allocate a TLV type code for the new RI LSA TLV proposed in Section 4 of this document from OSPF Router Information (RI) TLVs Registry defined by [RFC4970]. 8. Security Considerations This document does not introduce any new security risk other than what is specified by [RFC4970]. 9. References 9.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC4970] Lindem, A., Shen, N., Vasseur, JP., Aggarwal, R., and S. Shaffer, "Extensions to OSPF for Advertising Optional Router Capabilities", RFC 4970, July 2007. [RFC5838] Lindem, A., Mirtorabi, S., Roy, A., Barnes, M., and R. Aggarwal, "Support of Address Families in OSPFv3", RFC 5838, April 2010. 9.2. Informative References [I-D.ietf-ospf-node-admin-tag] Hegde, S., Raghuveer, H., Gredler, H., Shakir, R., Smirnov, A., Li, Z., and B. Decraene, "Advertising per- node administrative tags in OSPF", draft-ietf-ospf-node- admin-tag-00 (work in progress), October 2014. Chunduri, et al. Expires September 10, 2015 [Page 6] Internet-Draft Self-defined Sub-TLVs March 2015 Authors' Addresses Uma Chunduri Ericsson Inc. 300 Holger Way, San Jose, California 95134 USA Phone: 408 750-5678 Email: uma.chunduri@ericsson.com Xiaohu Xu Huawei Email: xuxiaohu@huawei.com Luis M. Contreras Telefonica I+D Ronda de la Comunicacion, s/n Sur-3 building, 3rd floor Madrid 28050 Spain Email: luismiguel.contrerasmurillo@telefonica.com URI: http://people.tid.es/LuisM.Contreras/ Mohamed Boucadair France Telecom Rennes 35000 France Email: mohamed.boucadair@orange.com Chunduri, et al. Expires September 10, 2015 [Page 7]