Multi-Layering OAM for Service function Chaining
draft-wang-sfc-multi-layer-oam-06

Document Type Active Internet-Draft (individual)
Last updated 2017-02-09
Stream (None)
Intended RFC status (None)
Formats plain text pdf html bibtex
Stream Stream state (No stream defined)
Consensus Boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date
Responsible AD (None)
Send notices to (None)
SFC WG                                                           C. Wang
Internet-Draft                                                   W. Meng
Intended status: Standards Track                         ZTE Corporation
Expires: August 13, 2017                                   B. Khasnabish
                                                            ZTE TX, Inc.
                                                        February 9, 2017

            Multi-Layering OAM for Service function Chaining
                   draft-wang-sfc-multi-layer-oam-06

Abstract

   This document tries to discuss some problems in SFC OAM framework
   document and proposes the SFC OAM multi-layering requirements in SFC
   domain to improve the troubleshooting efficiency.

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 August 13, 2017.

Copyright Notice

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

Wang, et al.             Expires August 13, 2017                [Page 1]
Internet-Draft           Multi-Layer OAM for SFC           February 2017

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Convention and Terminology  . . . . . . . . . . . . . . . . .   3
   3.  SFC Layering model  . . . . . . . . . . . . . . . . . . . . .   3
   4.  Requirements for SFC OAM multi-layering model . . . . . . . .   3
   5.  SFC OAM multi-layering model  . . . . . . . . . . . . . . . .   4
   6.  Gap analysis  . . . . . . . . . . . . . . . . . . . . . . . .   5
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .   5
   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   5
   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   5
     9.1.  Normative References  . . . . . . . . . . . . . . . . . .   5
     9.2.  Informative References  . . . . . . . . . . . . . . . . .   6
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   6

1.  Introduction

   In [SFC-arch], it defines several requisite components to implement
   SFC, including classifier, which performs classification for incoming
   packets, and Service Function Forwarder/SFF, which is responsible for
   forwarding traffic to one or more connected service functions
   according to the information carried in the SFC encapsulation, as
   well as handling traffic coming back from the SF and transporting
   traffic to another SFF and terminating the SFP.  And what!_s more,
   another significant component is Service Function/SF, which is
   responsible for specific treatment of received packets.

   Based on these SFC components, there are different notions for
   differentiated level of service chains, such as fully abstract notion
   named SFC, which defines an ordered set of service functions that
   must be applied to packets selected as a result of classification.
   But, SFC doesn!_t define the exactly SFFs/SFs.  And another notion is
   half-fully abstraction notion named SFP, which is the instantiation
   of a SFC in the network and provides a level of indirection between
   the fully abstract SFC and a fully specified RSP.  The mean is that
   SFP defines some SFFs/SFs, not every SFFs/SFs.  As well, there is a
   fully specific notion named RSP, which defines exactly which SFFs/SFs
   the packet will visit when it actually traverses the network.  The
   main difference between SFP and RSP is that whether delegate the SFF/
   SF selection authority to the network or not.

   This document tries to discuss some problems in basic SFC OAM
Show full document text