Internet DRAFT - draft-chunduri-ospf-operator-defined-tlvs

draft-chunduri-ospf-operator-defined-tlvs







Network Working Group                                   U. Chunduri, Ed.
Internet-Draft                                             Ericsson Inc.
Intended status: Standards Track                                   X. Xu
Expires: July 8, 2016                                             Huawei
                                                            L. Contreras
                                                          Telefonica I+D
                                                       M. Boucadair, Ed.
                                                          France Telecom
                                                                L. Jalil
                                                                 Verizon
                                                         January 5, 2016


        Using Operator-defined TLVs for Agile Service Deployment
              draft-chunduri-ospf-operator-defined-tlvs-02

Abstract

   This document proposes a TLV within the body of the OSPF Router
   Information (RI) Opaque LSA, called Operator-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 July 8, 2016.

Copyright Notice

   Copyright (c) 2016 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



Chunduri, et al.          Expires July 8, 2016                  [Page 1]

Internet-Draft          Operator-defined Sub-TLVs           January 2016


   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   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.  A Sample Use Case . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Applicability . . . . . . . . . . . . . . . . . . . . . . . .   4
   4.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   4
   5.  Operator-defined Sub-TLV Container TLV  . . . . . . . . . . .   4
   6.  Operator-defined Sub-TLV  . . . . . . . . . . . . . . . . . .   5
   7.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   7
   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   7
   9.  Security Considerations . . . . . . . . . . . . . . . . . . .   7
   10. References  . . . . . . . . . . . . . . . . . . . . . . . . .   7
     10.1.  Normative References . . . . . . . . . . . . . . . . . .   7
     10.2.  Informative References . . . . . . . . . . . . . . . . .   8
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   8

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 Operator-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.  This document gives a framework
   where operator information can be transparently injected into the
   routing domain.



Chunduri, et al.          Expires July 8, 2016                  [Page 2]

Internet-Draft          Operator-defined Sub-TLVs           January 2016


   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 here denotes
   both OSPFv2 and OSPFv3.

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.  A Sample Use Case

   This section describes a use case example to illustrate the use of
   the Operator-defined Sub-TLV Container TLV defined in Section 5.  It
   shows how operators can deploy services rapidly by advertising
   associated attributes.  It is out of scope of this section to
   identify an exhaustive list of deployment use cases.

   In the context of service function chaining ([RFC7665]), advertising
   Service Functions and it's attributes will ease automating how
   service chains are structured and will help policy decision engines
   (typically, a controller) to selectively direct the traffic to
   appropriate service function instances according to a set policy
   guidelines and/or the information reported in the Operator-defined
   Sub-TLV.

   Particularly, 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 Operator-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 a
   controller to adjust its policies and react dynamically.  Typical
   actions would be, to withdraw a service instance from being invoked



Chunduri, et al.          Expires July 8, 2016                  [Page 3]

Internet-Draft          Operator-defined Sub-TLVs           January 2016


   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.

3.  Applicability

   This mechanism MUST only be used for local applications or non-
   standard commercial applications.  If the information injected in
   this attribute requires a specific handling from an OSPF speaker
   other than reading configuration parameters and encode it as
   described in this document, then those MUST NOT be advertised through
   this mechanism.

   The attribute in this document is operator-defined.  As such, it is
   the responsibility of the provider to decide which information can be
   conveyed as per the pre-defined format specific to the deployment by
   means of the operator-defined attributes.

4.  Terminology

   This memo makes use of the terms defined in [RFC4970].

5.  Operator-defined Sub-TLV Container TLV

   A new TLV within the body of the OSPFv2 and OSPFv3 RI Opaque LSA,
   called Operator-defined Sub-TLV Container TLV is defined to carry one
   or more operator-defined sub-TLVs.

   The format of the Operator-defined Sub-TLV Container TLV is shown in
   Figure 1.


















Chunduri, et al.          Expires July 8, 2016                  [Page 4]

Internet-Draft          Operator-defined Sub-TLVs           January 2016


        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 Operator-defined Sub-TLV                 |
       o                                                               o
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       // ...                                                         //
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |             Last Operator-defined Sub-TLV                     |
       o                                                               o
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

             Figure 1: Operator-defined Sub-TLV Container TLV

   Type: TBD Section 8

   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 Operator-defined Sub-TLVs advertised.

   Value: Contains one or more nested TLV triplets of operator-defined
   sub-TLVs as defined in Section 6.

   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 Operator-defined sub-TLV Container TLV inherits
   applicability as well as restrictions as specified in Section 3 of
   [RFC4970].

6.  Operator-defined Sub-TLV

   The operator-defined sub-TLV has the following structure and can be
   part of the Container TLV as defined in Section 5 within the body of
   the OSPF RI LSA.













Chunduri, et al.          Expires July 8, 2016                  [Page 5]

Internet-Draft          Operator-defined Sub-TLVs           January 2016


        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: Operator-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.  All multi byte
   attribute values MUST be encoded in Network Byte Order (NBO).  If
   multiple fixed length values have to be represented, those SHOULD be
   represented with multiple {Attribute-Len, Attribute-value} tuples.

   The meaning of the operator-defined sub-TLV is totally opaque to OSPF
   and is defined by the network local policy and is controlled via
   configuration.  The application that needs to consume the data
   defined is likely to implement some validation checks.

   Routers advertising the operator-defined sub-TLV are configured to do
   so without knowing (or even explicitly supporting) functionality
   implied by the sub-TLV.

   How a receiving node communicates the operator-defined sub-TLVs with
   the policy manager is outside the scope of this document.

   The operator-defined TLV is formatted as described in Section 2.1 of
   [RFC4970].  However, the code points of operator-defined sub-TLVs as
   defined above are allocated by operators themselves, specific to the
   deployment rather than IANA.  Furthermore, the semantics of the
   operator-defined sub-TLV order has no meaning.  That is, there is no
   implied meaning to the ordering of the operator-defined sub-TLV that
   indicates a certain operation or set of operations that need to be



Chunduri, et al.          Expires July 8, 2016                  [Page 6]

Internet-Draft          Operator-defined Sub-TLVs           January 2016


   performed based on the ordering.  The ordering of operator-defined
   sub-TLVs and the interpretation of the operator-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.

   It is reasonable that non-routing information should be advertise in
   a non-routing instance of OSPF as defined in [I-D.ietf-ospf-
   transport-instance] so as to minimize the impact on the operation of
   routing.  However, since the information contained in the self-
   defined sub-TLV may be related to the routing, whether or not using a
   non-routing instance to flood the self-defined sub-TLVs should be
   determined by operators according to the information to be conveyed
   by the self-defined sub-TLV.

7.  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, Chris Bowers and Les Ginsberg for their
   review and comments.

8.  IANA Considerations

   This document includes a request to IANA to allocate a TLV type code
   for the new RI LSA TLV proposed in Section 5 of this document from
   OSPF Router Information (RI) TLVs Registry defined by [RFC4970].

9.  Security Considerations

   As Operator Defined TLV specified in this draft is part of RI LSA,
   this document does not introduce any new security risk other than
   what is specified by [RFC4970].  Security considerations for the base
   OSPF protocol are covered in [RFC2328] and [RFC5340].

10.  References

10.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <http://www.rfc-editor.org/info/rfc2119>.

   [RFC2328]  Moy, J., "OSPF Version 2", STD 54, RFC 2328,
              DOI 10.17487/RFC2328, April 1998,
              <http://www.rfc-editor.org/info/rfc2328>.



Chunduri, et al.          Expires July 8, 2016                  [Page 7]

Internet-Draft          Operator-defined Sub-TLVs           January 2016


   [RFC4970]  Lindem, A., Ed., Shen, N., Vasseur, JP., Aggarwal, R., and
              S. Shaffer, "Extensions to OSPF for Advertising Optional
              Router Capabilities", RFC 4970, DOI 10.17487/RFC4970, July
              2007, <http://www.rfc-editor.org/info/rfc4970>.

   [RFC5340]  Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF
              for IPv6", RFC 5340, DOI 10.17487/RFC5340, July 2008,
              <http://www.rfc-editor.org/info/rfc5340>.

10.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-02 (work in progress), June 2015.

   [I-D.ietf-ospf-transport-instance]
              Lindem, A., Roy, A., and S. Mirtorabi, "OSPF Transport
              Instance Extensions", draft-ietf-ospf-transport-
              instance-11 (work in progress), June 2014.

   [RFC7665]  Halpern, J., Ed. and C. Pignataro, Ed., "Service Function
              Chaining (SFC) Architecture", RFC 7665,
              DOI 10.17487/RFC7665, October 2015,
              <http://www.rfc-editor.org/info/rfc7665>.

Authors' Addresses

   Uma Chunduri (editor)
   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








Chunduri, et al.          Expires July 8, 2016                  [Page 8]

Internet-Draft          Operator-defined Sub-TLVs           January 2016


   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 (editor)
   France Telecom
   Rennes  35000
   France

   Email: mohamed.boucadair@orange.com


   Luay Jalil
   Verizon
   400 International Parkway
   Richardson, Tx  75081
   USA

   Email: luay.jalil@verizon.com

























Chunduri, et al.          Expires July 8, 2016                  [Page 9]