[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00

INTERNET-DRAFT                                              Sami Boutros
Intended Status: Standard Track                             Dharma Rajan
                                                           Philip Kippen
                                                                  VMware


Expires: April 30, 2018                                 October 27, 2017


          Geneve applicability for service function chaining
           draft-boutros-nvo3-geneve-applicability-for-sfc-00


Abstract

   This document describes the applicability of using Generic Network
   Virtualization Encapsulation (Geneve), to carry the service function
   path (SFP) information, and the network service header (NSH) metadata
   (MD) type 1 and type 2. The SFP information and MD types will be
   carried in Geneve option TLV(s).


Status of this Memo

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as
   Internet-Drafts.

   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."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/1id-abstracts.html

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html


Copyright and License Notice

   Copyright (c) 2017 IETF Trust and the persons identified as the
   document authors. All rights reserved.



Boutros                  Expires April 30, 2018                 [Page 1]


INTERNET DRAFT     NVO3 Geneve applicability for SFC    October 27, 2017


   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
   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  . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . .  3
   3. Abbreviations . . . . . . . . . . . . . . . . . . . . . . . . .  3
   4. Geneve Option TLV(s)  . . . . . . . . . . . . . . . . . . . . .  4
     4.1 Geneve Service Function List (SFL) Option TLV  . . . . . . .  4
     4.2 Geneve NSH metadata Option TLV . . . . . . . . . . . . . . .  6
   5. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . .  7
     5.1 Operation at Ingress . . . . . . . . . . . . . . . . . . . .  7
     5.2 Operation at each NVE along the service function path  . . .  8
     5.3 Operation at Egress  . . . . . . . . . . . . . . . . . . . .  9
   6. Security Considerations . . . . . . . . . . . . . . . . . . . .  9
   7. Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . 10
   8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 10
   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
     9.1  Normative References  . . . . . . . . . . . . . . . . . . . 11
     9.2  Informative References  . . . . . . . . . . . . . . . . . . 11
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12




















Boutros                  Expires April 30, 2018                 [Page 2]


INTERNET DRAFT     NVO3 Geneve applicability for SFC    October 27, 2017


1. Introduction

   The Service Function Chaining (SFC) Architecture [rfc7665] defines a
   service function chain (SFC) as (1) the instantiation of an ordered
   set of service functions and (2) the subsequent "steering" of traffic
   through them.

   SFC defines a Service Function Path (SFP) as the exact set of service
   function forwarders (SFF)/service functions (SF)s the packet will
   visit when it actually traverses the network.

   An optimized SFP helps to build an efficient Service function chain
   (SFC) that can be used to steer traffic based on classification
   rules, and metadata information to provide services for Network
   Function Virtualization (NFV).  Metadata are typically passed between
   service functions and Service function forwarders SFF(s) along a
   service function path.

   The metadata can be encoded in packets using encapsulation protocols
   as per network service header (NSH) [draft-ietf-sfc-nsh] definition
   or simply using VLAN or Q-in-Q based encoding.

   This document specifies the applicability of using Generic Network
   Virtualization Encapsulation (Geneve), to carry the service function
   path (SFP) information, and the network service header (NSH) metadata
   (MD) types in Geneve option TLV(s).

   The SFP will be implemented using a new Geneve Service Function List
   option for use strictly between Network Virtualization Edges (NVEs)
   performing the service forwarding function (SFF) in the same Network
   Virtualization Overlay over Layer 3 NVO3 domain. The NSH Metadata
   will be encoded in a new Geneve NSH metadata option TLV.

2. Terminology

   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].

3. Abbreviations

   NVO3 Network Virtualization Overlays over Layer 3

   OAM Operations, Administration, and Maintenance

   TLV Type, Length, and Value

   VNI Virtual Network Identifier



Boutros                  Expires April 30, 2018                 [Page 3]


INTERNET DRAFT     NVO3 Geneve applicability for SFC    October 27, 2017


   NVE Network Virtualization Edge

   NVA Network Virtualization Authority

   NIC Network interface card

   VTEP Virtual Tunnel End Point

   Transit device Underlay network devices between NVE(s).

   Service Function (SF):  Defined in [RFC7665].

   Service Function Chain (SFC):  Defined in [RFC7665].

   Service Function Forwarder (SFF):  Defined in [RFC7665].

   Service Function Path (SFP):  Defined in [RFC7665].

   Metadata: Defined in [[draft-ietf-sfc-nsh]

   NFV: Network function virtualization.

   VNF: Virtual network function

4. Geneve Option TLV(s)

4.1 Geneve Service Function List (SFL) Option TLV


   Geneve Header:

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |Ver|  Opt Len  |O|C|    Rsvd.  |          Protocol Type        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |        Virtual Network Identifier (VNI)       |    Reserved   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Geneve Option Header:

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          Option Class         |      Type     |R|R|R| Length  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      Variable Option Data                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Option Class = To be assigned by IANA



Boutros                  Expires April 30, 2018                 [Page 4]


INTERNET DRAFT     NVO3 Geneve applicability for SFC    October 27, 2017


      Type = To be assigned by IANA

      'C' bit set, indicating endpoints must drop if they do not
   recognize   this option)

      Length = variable.

      Variable option data:

     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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |Version|Flags          |Reserved               |   SF Index    |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     ~            SF List[0] (32 or 128 bits IPv4/6 address)         ~
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     |                                                               |
                                   ...
     |                                                               |
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     ~            SF List [n] (32 or 128 bits IPv4/6 address)        ~
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     //                                                             //
     //         Optional sub-Type Length Value objects (variable)   //
     //                                                             //
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     Figure 1: Service Function List (SFL) Option TLV.

   Reserved: 12 bits. SHOULD be unset on transmission and MUST be
   ignored on receipt.

   Flags:
             0 1 2 3 4 5 6 7
            +-+-+-+-+-+-+-+-+
            |H| Unused      |
            +-+-+-+-+-+-+-+-+
            Figure 2: SFL flags


   H-flag: HMAC flag.  If set, the HMAC sub-TLV is present and is
   encoded as the last sub-TLV.

   SF Index: It contains the service function (SF) index, in SF List, it
   is decremented after the packet is inspected by the service function.




Boutros                  Expires April 30, 2018                 [Page 5]


INTERNET DRAFT     NVO3 Geneve applicability for SFC    October 27, 2017


   SF List[n]: 32 or 128 bits IPv4/6 addresses representing the nth
   service function ip address in the List.

   The SF List is encoded starting from the last hop of the path.  I.e.,
   the first element of the list (SF List [0]) contains the last service
   function of the path while the last element of the SF List (SF
   List[n]) contains the first service function in the path.

   HMAC sub-TLV is optional and contains the HMAC information.  The HMAC
   sub-TLV has the following format:

       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    |          Reserved             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                      HMAC Key ID (4 octets)                   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                              //
      |                      HMAC (32 octets)                        //
      |                                                              //
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      Figure 3: SFL HMAC sub-TLV.

   Type: to be assigned by IANA (suggested value 1). Length: 38.
   Reserved: 2 octets.  SHOULD be unset on transmission and MUST be
   ignored on receipt. HMAC Key ID: 4 octets. HMAC: 32 octets. HMAC and
   HMAC Key ID usage is described in Operation section.

   The Following applies to the HMAC TLV:

   When present, the HMAC sub-TLV MUST be encoded as the last sub-TLV.

   If the HMAC sub-TLV is present, the H-Flag (Figure 2) MUST be set.

   When the H-flag is set, the NVE inspecting the Geneve Service
   Function List Option TLV MUST find the HMAC sub-TLV in the last 38
   octets of the option TLV.

4.2 Geneve NSH metadata Option TLV

   Geneve Option Header:

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |          Option Class         |      Type     |R|R|R| Length  |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



Boutros                  Expires April 30, 2018                 [Page 6]


INTERNET DRAFT     NVO3 Geneve applicability for SFC    October 27, 2017


      |                      Variable Option Data                     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      Figure 4: NSH Metadata Option TLV

      Option Class = NSH metadata, to be assigned by IANA.

      Type = 1 for MD type 1   Type = 2 for MD type 2

      'C' bit set, indicating endpoints must drop if they do not
   recognize   this option)

      Length = 4 (16 bytes) for fixed or variable length.

      Option data for MD-Type 1 will be a fixed 16 bytes value.
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |                                                               |
        |                 Fixed Length Context Header                   |
        |                                                               |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      Option data for MD-Type 2 will be of variable size.

        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |                                                               |
        ~              Variable Length Context Headers  (opt.)          ~
        |                                                               |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

5. Operation

5.1 Operation at Ingress

   A Source NVE acting as a service function classifier and a service
   function forwarder can be any node in an NVO3 domain, originating
   based on a classification policy for some customer inner payload an
   IP Geneve tunnel packet with the service function list (SFL) option
   TLV. The service functions in the SFL represent the IP addresses of
   the service functions that the inner customer packets needs to be
   inspected by. A controller can program the ingress NVE node to
   classify traffic and identify a service function paths i.e the set of
   service functions in the path. The mechanism through which an SFL is
   derived by a controller or any other mechanisms is outside of the
   scope of this document.

   The ingress NVE node fills in the list of service functions in the
   path, to the Geneve Service Function List option TLV, putting the
   first service function ip address as the last element in the list and
   the last service function ip address as the first element, setting of
   the service function index to the first element. The ingress NVE



Boutros                  Expires April 30, 2018                 [Page 7]


INTERNET DRAFT     NVO3 Geneve applicability for SFC    October 27, 2017


   node, then, resolves the service first function ip address, to the
   NVE virtual tunnel endpoint node hosting or directly connected to the
   service function.

   The Geneve tunnel destination is then set to the NVE tunnel endpoint
   hosting the first service function, and the service function index is
   decremented to n-1 (where n is the number of elements in the SFL),
   and set on the SFL option TLV. A metadata option TLV can also be set
   on the packet by the NVE ingress node.

   The Geneve packet is sent out towards the first NVE.

   HMAC optional sub-TLV may be set too.

5.2 Operation at each NVE along the service function path

   The NVE node along the service function path corresponding to the
   Geneve tunnel destination of the packet, receives the packet, perform
   the service function forwarder function and identifies the SFL
   option, and locates the service function in the list based on the
   service function index.

   The Geneve tunnel header and option TLV(s) will be stripped and the
   packet will be delivered to the service function or virtual network
   function (VNF), possibly along with some metadata that can identify
   the SFL option TLV. The NVE maintains state related to the inner
   packet, or some metadata association with the SFL option TLV. The
   packet passed to the service function can possibly be encaped with
   the NSH header, encoding in it a metadata TLV if the metadata
   approach is used, and if the SF is NSH aware, other encapsulations
   like vlan or q-in-q encap may be used to pass the metadata to the SF
   too. The metadata passed to the SF can be associated with the SFL
   option TLV.

   When the packet comes back from the service function along with the
   metadata context, based on the metadata on the packet or based on the
   inner packet flow information the NVE acting as the SFF will be able
   to locate the SFL option TLV.

   If the metadata context indicate (1) that some service functions need
   to be bypassed the NVE should bypass in the SFL the service functions
   to be skipped and update the service function index accordingly. (2)
   A new classification need to be performed on the packet, in that case
   the NVE can re-classify the packet or sent it to an NVE node capable
   of classification.

   The NVE node, then, resolves the next service function ip address, to
   the NVE virtual tunnel endpoint node hosting or directly connected to



Boutros                  Expires April 30, 2018                 [Page 8]


INTERNET DRAFT     NVO3 Geneve applicability for SFC    October 27, 2017


   the service function.

   The NVE then sets the Geneve tunnel destination to the next NVE
   tunnel endpoint, and the service function index is decremented by 1
   and set on the SFL option TLV, along with other NSH metadata option
   TLV.

   The Geneve packet is sent out towards the next NVE.

5.3 Operation at Egress

   At the last NVE node along the service function path, the NVE locates
   the service function in the SFL option TLV based on the service
   function index. The service function index received at the last NVE
   node will be set to 1.

   The Geneve tunnel header and option TLV(s) will be stripped and the
   packet will be delivered to the service function, possibly along with
   some metadata that can identify the SFL option TLV, the NVE can
   maintain state related to the inner packet, or some metadata
   association with the SFL option TLV.

   When the packet comes back from the service function, based on some
   metadata on the packet or based on the inner packet flow information
   the NVE will be able to locate the SFL option TLV.

   Given that the service function index will be set to 1, the last NVE
   will now deliver the packet to the NVE hosting or directly connected
   to the inner packet destination.

   A packet received with a service function index of 0 MUST be dropped.

6. Security Considerations

   Only NVE(s) that are the destinations of the Geneve tunnel packet
   will be inspecting the  List of Service Function next hops Option. A
   Source routing option has some well-known security issues as
   described in [RFC4942] and [RFC5095].

   The main use case for the use of the Geneve List of Service Function
   next hops Option will be within a single NVO3 administrative domain
   where only trusted NVE nodes are enabled and configured participate,
   this is the same model as in [RFC6554].

   NVE nodes MUST ignore the Geneve List of Service Function next hops
   Option created by outsiders based on NVA or trusted control plane
   information.




Boutros                  Expires April 30, 2018                 [Page 9]


INTERNET DRAFT     NVO3 Geneve applicability for SFC    October 27, 2017


   There is a need to prevent non-participating NVE node from using the
   Geneve Service Function List option TLV, as described in [draft-ietf-
   6man-segment-routing-header], we will use a security sub-TLV in the
   Service Function List option TLV, the security sub-TLV will be based
   on a key-hashed message authentication code (HMAC).

   HMAC sub-TLV will contain:

   HMAC Key-id, 32 bits wide;

   HMAC, 256 bits wide (optional, exists only if HMAC Key-id is not 0).

   The HMAC field is the output of the HMAC computation (per RFC 2104
   [RFC2104]) using a pre-shared key identified by HMAC Key-id and of
   the text which consists of the concatenation of:

   The source IPv4/IPv6 Geneve tunnel address

   Version and Flags

   HMAC Key-id.

   All addresses in the List.

   The purpose of the HMAC optional sub-TLV is to verify the validity,
   the integrity and the authorization of the Geneve Service Function
   List option TLV itself.

   The HMAC optional sub-TLV is located at the end of the Geneve Service
   Function List option TLV.

   The HMAC Key-id field serves as an index to the right combination of
   pre-shared key and hash algorithm and except that a value of 0 means
   that there is no HMAC field.

   The HMAC Selection of a hash algorithm and Pre-shared key management
   will follow the procedures described in [draft-ietf-6man-segment-
   routing-header] section 6.2.

7. Acknowledgements

8. IANA Considerations

   This document makes the following registrations in the "Geneve Option
   Class" registry maintained by IANA:

   Suggested            Description                Reference
   Value



Boutros                  Expires April 30, 2018                [Page 10]


INTERNET DRAFT     NVO3 Geneve applicability for SFC    October 27, 2017


   ----------------------------------------------------------
   XX   Geneve List of Service Function next hops  This document
   XX   Geneve NSH Metadata                        This document

   In addition, this document request IANA to create and maintain a new
   Registry: "Geneve List of Service Function next hops Type-Value
   Objects".

   The following code-point are requested from the registry:

   Registry: Geneve List of Service Function next hops Type-Value
   Objects

   Suggested         Description            Reference
   Value
   -----------------------------------------------------
        1         HMAC TLV                  This document
9.  References

9.1  Normative References

   [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
   Requirement Levels", BCP 14, RFC 2119, March 1997.

9.2  Informative References

   [Geneve] "Generic Network Virtualization Encapsulation", [I-D.ietf-
   nvo3-geneve]

   [I-D.ietf-sfc-nsh] Quinn, P., Elzur, U., and C. Pignataro, "Network
   Service Header (NSH)", draft-ietf-sfc-nsh-16 (work in progress), July
   2017.

   [RFC4942]  Davies, E., Krishnan, S., and P. Savola, "IPv6
   Transition/Co-existence Security Considerations", RFC 4942, DOI
   10.17487/RFC4942, September 2007, <http://www.rfc-
   editor.org/info/rfc4942>.

   [RFC6554]  Hui, J., Vasseur, JP., Culler, D., and V. Manral, "An IPv6
   Routing Header for Source Routes with the Routing Protocol for Low-
   Power and Lossy Networks (RPL)", RFC 6554, DOI 10.17487/RFC6554,
   March 2012, <http://www.rfc-editor.org/info/rfc6554>.

   [draft-ietf-6man-segment-routing-header] Previdi, S., et all, "IPv6
   Segment Routing Header (SRH)",  July 20, 2017, draft-ietf-6man-
   segment-routing-header-07

   [RFC5095]  Abley, J., Savola, P., and G. Neville-Neil, "Deprecation



Boutros                  Expires April 30, 2018                [Page 11]


INTERNET DRAFT     NVO3 Geneve applicability for SFC    October 27, 2017


   of Type 0 Routing Headers in IPv6", RFC 5095, DOI 10.17487/RFC5095,
   December 2007, <http://www.rfc-editor.org/info/rfc5095>.

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


Authors' Addresses

   Sami Boutros
   VMware
   Email: sboutros@vmware.com

   Dharma Rajan
   VMware
   Email: drajan@vmware.com

   Philip Kippen
   VMware
   Email: pkippen@vmware.com






























Boutros                  Expires April 30, 2018                [Page 12]


Html markup produced by rfcmarkup 1.124, available from https://tools.ietf.org/tools/rfcmarkup/