SFC WG                                                         G. Mirsky
Internet-Draft                                                 ZTE Corp.
Intended status: Standards Track                                   T. Ao
Expires: December 5, 2020                         Individual contributor
                                                                 Z. Chen
                                                           China Telecom
                                                                K. Leung
                                                            Cisco System
                                                            June 3, 2020


                      SFC OAM for path consistency
                  draft-ao-sfc-oam-path-consistency-08

Abstract

   Service Function Chain (SFC) defines an ordered set of service
   functions (SFs) to be applied to packets and/or frames and/or flows
   selected as a result of classification.  SFC Operation,
   Administration and Maintenance can monitor the continuity of the SFC,
   i.e., that all elements of the SFC are reachable to each other in the
   downstream direction.  But SFC OAM must support verification that the
   order of traversing these SFs corresponds to the state defined by the
   SFC control plane or orchestrator, the metric referred in this
   document as the path consistency of the SFC.  This document defines a
   new SFC active OAM method to support SFC consistency check, i.e.
   verification that all elements of the given SFC are being traversed
   in the expected order.

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 https://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 December 5, 2020.






Mirsky, et al.          Expires December 5, 2020                [Page 1]


Internet-Draft        SFC OAM for path consistency             June 2020


Copyright Notice

   Copyright (c) 2020 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
   (https://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
   2.  Conventions used in this document . . . . . . . . . . . . . .   3
     2.1.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   3
     2.2.  Requirements Language . . . . . . . . . . . . . . . . . .   3
   3.  Consistency OAM: Theory of Operation  . . . . . . . . . . . .   3
     3.1.  COAM packet . . . . . . . . . . . . . . . . . . . . . . .   4
     3.2.  SFF Information Record TLV  . . . . . . . . . . . . . . .   4
     3.3.  SF Information Sub-TLV  . . . . . . . . . . . . . . . . .   5
     3.4.  SF Information Sub-TLV Construction . . . . . . . . . . .   6
       3.4.1.  Multiple SFs as hops of SFP . . . . . . . . . . . . .   6
       3.4.2.  Multiple SFs for load balance . . . . . . . . . . . .   7
   4.  Security Considerations . . . . . . . . . . . . . . . . . . .   7
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   8
     5.1.  COAM Message Types  . . . . . . . . . . . . . . . . . . .   8
     5.2.  SFF Information Record TLV Type . . . . . . . . . . . . .   8
     5.3.  SF Information Sub-TLV Type . . . . . . . . . . . . . . .   8
     5.4.  SF Identifier Types . . . . . . . . . . . . . . . . . . .   9
   6.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   9
   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   9
     7.1.  Normative References  . . . . . . . . . . . . . . . . . .   9
     7.2.  Informational References  . . . . . . . . . . . . . . . .  10
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  10

1.  Introduction

   Service Function Chain (SFC) is a chain with a series of ordered
   Service Functions (SFs).  Service Function Path (SFP) is a path of a
   SFC.  SFC is described in detail in the SFC architecture document
   [RFC7665].  The SFs in the SFC are ordered, i.e., only when an SF
   processes traffic, then it can be processed by the next SF.  Changes
   in the order are very likely to cause errors.  That's why an operator



Mirsky, et al.          Expires December 5, 2020                [Page 2]


Internet-Draft        SFC OAM for path consistency             June 2020


   needs to ensure that the order of traversing the SFs is as defined by
   the control plane or the orchestrator.  This document refers to the
   correlation between the state of the control plane and the SFP itself
   as the SFP consistency.  The need for the ability to verify the
   consistency of the particular SFP, using a mechanism of an active OAM
   protocol, is noted in [I-D.ietf-sfc-oam-framework].

   This document defines the method to check the path consistency of the
   SFP.  It is an extension of the SFC Echo-request/Echo-reply specified
   in the [I-D.ietf-sfc-multi-layer-oam].

2.  Conventions used in this document

2.1.  Terminology

   SFC: Service Function Chain.  An ordered set of some abstract SFs.

   SFF: Service Function Forwarder

   SF: Service Function

   OAM: Operation, Administration and Maintenance

   SFP: Service Function Path

   COAM: Consistency OAM, OAM that can be used to check the consistency
   of the Service Function Path.

2.2.  Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in BCP
   14 [RFC2119] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.

3.  Consistency OAM: Theory of Operation

   Consistency OAM (COAM) uses two functions: COAM Request and COAM
   Reply.  Every SFF that receives the COAM Request MUST perform the
   following actions:

   o  Collect information of traversed by the COAM Request packet SFs
      and send it to the ingress SFF as COAM Reply packet over IP
      network [I-D.ietf-sfc-multi-layer-oam];

   o  Forward the COAM Request to next downstream SFF if the one exists.




Mirsky, et al.          Expires December 5, 2020                [Page 3]


Internet-Draft        SFC OAM for path consistency             June 2020


   As a result, the ingress SFF collects information about all traversed
   SFFs and SFs, information on the actual path the COAM packet has
   traveled.  That information used to verify the SFC's path
   consistency.  The mechanism for the SFP consistency verification is
   outside the scope of this document.

3.1.  COAM packet

   Consistency OAM introduces two new types of messages to the SFC Echo
   request/reply operation [I-D.ietf-sfc-multi-layer-oam] with the
   following values detailed in Section 5.1:

   o  TBA1 - COAM Request

   o  TBA2 - COAM Reply

   Upon receiving the COAM Request, the SFF MUST respond with the COAM
   Reply.  The SFF MUST include the SFs information, as described in
   Section 3.3 and Section 3.2.

   The COAM packet is displayed in Figure 1.


      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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | Message Type  |   Reply mode  |  Return Code  | Return S.code |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                         Sender's Handle                       |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                         Sequence Number                       |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |              Type             |             Length            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     ~                             Value                             ~
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                       Figure 1: COAM Packet Header

3.2.  SFF Information Record TLV

   For COAM Request, the SFF MUST include the Information of SFs into
   the SF Information Record TLV in the COAM Reply message.  Every SFF
   sends back a single COAM Reply Message, including information on all
   the SFs attached to the SFF on the SFP as requested in the COAM
   Request message.






Mirsky, et al.          Expires December 5, 2020                [Page 4]


Internet-Draft        SFC OAM for path consistency             June 2020


        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
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |     SFF Record TLV Type           |          Length           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |       Service Path Identifier(SPI)            |   Reserved    |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       |                   SF Information  Sub-TLV                     |
       ~                                                               ~
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                   Figure 2: SFF Information Record TLV

   Service Path Identifier(SPI): The identifier of SFP to which all the
   SFs in this TLV belong.

   SF Information Sub-TLV: The Sub-TLV as defined in Figure 3.

3.3.  SF Information Sub-TLV

   Every SFF receiving COAM Request packet MUST include the SF
   characteristic data into the COAM Reply packet.  The data format of
   an SF sub-TLV, included in a COAM Reply packet, is displayed in
   Figure 3.

   After the COAM Request message traverses the SFP, all the information
   of the SFs on the SFP is collected from the TLVs included in COAM
   Reply messages.


        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
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |     SF sub-TLV Type           |          Length               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |Service Index  |          SF Type              |   SF ID Type  |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                          SF Identifiers                       |
       ~                                                               ~
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

              Figure 3: Service Function information sub-TLV

   SF sub-TLV Type: Two octets long field.  It indicates that the TLV is
   an SF TLV which contains the information of one SF.



Mirsky, et al.          Expires December 5, 2020                [Page 5]


Internet-Draft        SFC OAM for path consistency             June 2020


   Length: Two octets long field.  The value of the field is the length
   of the data following the Length field counted in octets.

   Service Index: Indicates the SF's position on the SFP.

   SF Type: Two octets long field.  It is defined in
   [I-D.ietf-bess-nsh-bgp-control-plane] and indicates the type of SF,
   e.g., Firewall, Deep Packet Inspection, WAN optimization controller,
   etc.

   Reserved: For future use.  MUST be zeroed on transmission and MUST be
   ignored on receipt.

   SF ID Type: One octet-long field with values defined as Section 5.4.

   SF Identifier: An identifier of the SF.  The length of the SF
   Identifier depends on the type of the SF ID Type.  For example, if
   the SF Identifier is its IPv4 address, the SF Identifier should be 32
   bits.  SF ID Type and SF Identifier may be a list, indicating the
   list of the SFs are which are included in a load balance group.

3.4.  SF Information Sub-TLV Construction

   Each SFF in the SFP MUST send one and only one COAM Reply
   corresponding to the COAM Request.  If there is only one SF attached
   to the SFF in such SFP, only one SF information sub-TLV is included
   in the on COAM Reply.  If there are several SFs attached to the SFF
   in the SFP, SF Information Sub-TLV MUST be constructed as described
   below in either Section 3.4.1 and Section 3.4.2.

3.4.1.  Multiple SFs as hops of SFP

   Multiple SFs attached to one SFF are the hops of the SFP, the service
   indexes of these SFs are different.  Service function types of these
   SFs could be different or be the same.  Information about all SFs MAY
   be included in the COAM Reply message.  Information about each SF
   MUST be listed as separate SF Information Sub-TLVs in the COAM Reply
   message.

   An example of the COAM procedure for this case is shown in Figure 4.
   The Service Function Path(SPI=x) is SF1->SF2->SF4->SF3.  The SF1, SF2
   and SF3 are attached to SFF1, and SF4 is attached to SFF2.  The COAM
   Request message is sent to the SFFs in the sequence of the
   SFP(SFF1->SFF2->SFF1).  Every SFF(SFF1, SFF2) replies with the
   information of SFs belonging to the SFP.  The SF information Sub-TLV
   in Figure 3 contains information for each SF(SF1, SF2, SF3 and SF4).





Mirsky, et al.          Expires December 5, 2020                [Page 6]


Internet-Draft        SFC OAM for path consistency             June 2020


                    SF1         SF2           SF4                SF3
                    +------+------+            |                  |
       COAM Req  ......>  SFF1       ......>  SFF2       ......> SFF1
       (SPI=x)             .                   .                  .
               <............         <..........       <...........
               COAM Reply1(SF1,SF2)  COAM Reply2(SF4)  COAM Reply3(SF3)


           Figure 4: Example 1 for COAM Reply with multiple SFs

3.4.2.  Multiple SFs for load balance

   Multiple SFs may be attached to one SFF to balance the load; in other
   words, that means that the particular traffic flow will traverse only
   one of these SFs.  These SFs have the same Service Function Type and
   Service Index.  For this case, the SF identifiers and SF ID Type of
   all these SFs will be listed in the SF Identifiers field and SF ID
   Type in a single SF information sub-TLV of COAM Reply message.  The
   number of these SFs can be calculated according to SF ID Type and the
   value of the Length field of the sub-TLV.

   An example of the COAM procedure for this case is shown in Figure 4.
   The Service Function Path (SPI=x) is SF1a/SF1b->SF2a/SF2b.  The
   Service Functions SF1a and SF1b are attached to SFF1, which balances
   the load among them The Service Functions SF2a and SF2b are attached
   to SFF2, which also balances its load between them.  The COAM Request
   message is sent to the SFFs in the sequence of the SFP (i.e.
   SFF1->SFF2).  Every SFF (SFF1, SFF2) replies with the information of
   SFs belonging to the SFP.  The SF information Sub-TLV in Figure 3
   contains information for all SFs at that hop.

                               /SF1a                   /SF2a
                               \SF1b                   \SF2b
                                 |                       |
                                SFF1                    SFF2
            COAM Req   .........>  .           .........>  .
            (SPI=x)                .                       .
                       <............        <...............
              COAM Reply1({SF1a,SF1b})   COAM Reply2({SF2a,SF2b})


           Figure 5: Example 2 for COAM Reply with multiple SFs

4.  Security Considerations

   Security considerations discussed in [RFC8300] and
   [I-D.ietf-sfc-multi-layer-oam] apply to this document.




Mirsky, et al.          Expires December 5, 2020                [Page 7]


Internet-Draft        SFC OAM for path consistency             June 2020


   Also, since Service Function sub-TLV discloses information about the
   SFP the spoofed COAM Request packet may be used to obtain network
   information, it is RECOMMENDED that implementations provide a means
   of checking the source addresses of COAM Request messages, specified
   in SFC Source TLV [I-D.ietf-sfc-multi-layer-oam], against an access
   list before accepting the message.

5.  IANA Considerations

5.1.  COAM Message Types

   IANA is requested to assign values from its Message Types sub-
   registry in SFC Echo Request/Echo Reply Message Types registry as
   follows:

         +-------+------------------------------+---------------+
         | Value |         Description          | Reference     |
         +-------+------------------------------+---------------+
         | TBA1  | SFP Consistency Echo Request | This document |
         | TBA2  |  SFP Consistency Echo Reply  | This document |
         +-------+------------------------------+---------------+

      Table 1: SFP Consistency Echo Request/Echo Reply Message Types

5.2.  SFF Information Record TLV Type

   IANA is requested to assign new type value from SFC OAM TLV Type
   registry as follows:

          +-------+-----------------------------+---------------+
          | Value |         Description         | Reference     |
          +-------+-----------------------------+---------------+
          | TBA3  | SFF Information Record Type | This document |
          +-------+-----------------------------+---------------+

                      Table 2: SFF-Information Record

5.3.  SF Information Sub-TLV Type

   IANA is requested to assign new type value from SFC OAM TLV Type
   registry as follows:










Mirsky, et al.          Expires December 5, 2020                [Page 8]


Internet-Draft        SFC OAM for path consistency             June 2020


                +-------+----------------+---------------+
                | Value |  Description   | Reference     |
                +-------+----------------+---------------+
                | TBA4  | SF Information | This document |
                +-------+----------------+---------------+

                   Table 3: SF-Information Sub-TLV Type

5.4.  SF Identifier Types

   IANA is requested to create in the registry SF Types the new sub-
   registry SF Identifier Types.  All code points in the range 1 through
   191 in this registry shall be allocated according to the "IETF
   Review" procedure as specified in [RFC8126] and assign values as
   follows:

          +------------+-------------+-------------------------+
          | Value      | Description | Reference               |
          +------------+-------------+-------------------------+
          | 0          |   Reserved  | This document           |
          | TBA6       |     IPv4    | This document           |
          | TBA7       |     IPv6    | This document           |
          | TBA8       |     MAC     | This document           |
          | TBA8+1-191 |  Unassigned | IETF Review             |
          | 192-251    |  Unassigned | First Come First Served |
          | 252-254    |  Unassigned | Private Use             |
          | 255        |   Reserved  | This document           |
          +------------+-------------+-------------------------+

                        Table 4: SF Identifier Type

6.  Acknowledgements

   The authors are thankful to John Drake for his review and the
   reference to the work on BGP Control Plane for NSH SFC.  The authors
   express their appreciation to Joel M.  Halpern for his suggestion
   about the load balance scenario.  The authors also thank Dirk von
   Hugo for his useful comments.

7.  References

7.1.  Normative References

   [I-D.ietf-sfc-multi-layer-oam]
              Mirsky, G., Meng, W., Khasnabish, B., and C. Wang, "Active
              OAM for Service Function Chains in Networks", draft-ietf-
              sfc-multi-layer-oam-06 (work in progress), June 2020.




Mirsky, et al.          Expires December 5, 2020                [Page 9]


Internet-Draft        SFC OAM for path consistency             June 2020


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

   [RFC8126]  Cotton, M., Leiba, B., and T. Narten, "Guidelines for
              Writing an IANA Considerations Section in RFCs", BCP 26,
              RFC 8126, DOI 10.17487/RFC8126, June 2017,
              <https://www.rfc-editor.org/info/rfc8126>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

   [RFC8300]  Quinn, P., Ed., Elzur, U., Ed., and C. Pignataro, Ed.,
              "Network Service Header (NSH)", RFC 8300,
              DOI 10.17487/RFC8300, January 2018,
              <https://www.rfc-editor.org/info/rfc8300>.

7.2.  Informational References

   [I-D.ietf-bess-nsh-bgp-control-plane]
              Farrel, A., Drake, J., Rosen, E., Uttaro, J., and L.
              Jalil, "BGP Control Plane for the Network Service Header
              in Service Function Chaining", draft-ietf-bess-nsh-bgp-
              control-plane-14 (work in progress), June 2020.

   [I-D.ietf-sfc-oam-framework]
              Aldrin, S., Pignataro, C., Nainar, N., Krishnan, R., and
              A. Ghanwani, "Service Function Chaining (SFC) Operations,
              Administration and Maintenance (OAM) Framework", draft-
              ietf-sfc-oam-framework-15 (work in progress), May 2020.

   [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

   Greg Mirsky
   ZTE Corp.
   1900 McCarthy Blvd. #205
   Milpitas, CA  95035
   USA

   Email: gregimirsky@gmail.com




Mirsky, et al.          Expires December 5, 2020               [Page 10]


Internet-Draft        SFC OAM for path consistency             June 2020


   Ting Ao
   Individual contributor
   No.889, BiBo Road
   Shanghai  201203
   China

   Phone: +86 17721209283
   Email: 18555817@qq.com


   Zhonghua Chen
   China Telecom
   No.1835, South PuDong Road
   Shanghai  201203
   China

   Phone: +86 18918588897
   Email: 18918588897@189.cn


   Kent Leung
   Cisco System
   170 West Tasman Drive
   San Jose, CA 95134
   USA

   Email: kleung@cisco.com
























Mirsky, et al.          Expires December 5, 2020               [Page 11]