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

Versions: 00 01

SFC WG                                                             T. Ao
Internet-Draft                                           ZTE Corporation
Intended status: Standards Track                               G. Mirsky
Expires: April 30, 2018                                        ZTE Corp.
                                                                 Z. Chen
                                                           China Telecom
                                                        October 27, 2017


      Controlled Return Path for Service Function Chain (SFC) OAM
               draft-ao-sfc-oam-return-path-specified-01

Abstract

   This document defines extensions to the Service Function Chain (SFC)
   Operation, Administration and Maintenance (OAM) that enable control
   of the Echo Reply return path by specifying it as Reverse Service
   Function Path.  Enforcing the specific return path can be used to
   verify bidirectional connectivity of SFC and increase robustness of
   SFC OAM.

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 April 30, 2018.

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
   (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



Ao, et al.               Expires April 30, 2018                 [Page 1]


Internet-Draft     Controlled Return Path for SFC OAM       October 2017


   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.  Extension . . . . . . . . . . . . . . . . . . . . . . . . . .   3
   4.  SFC Reply Path TLV  . . . . . . . . . . . . . . . . . . . . .   4
   5.  Theory of Operation . . . . . . . . . . . . . . . . . . . . .   5
     5.1.  Case of Bi-directional SFC  . . . . . . . . . . . . . . .   5
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .   5
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   6
     7.1.  SFC Return Path Type  . . . . . . . . . . . . . . . . . .   6
     7.2.  New Return Codes  . . . . . . . . . . . . . . . . . . . .   6
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   6
     8.1.  Normative References  . . . . . . . . . . . . . . . . . .   6
     8.2.  Informative References  . . . . . . . . . . . . . . . . .   7
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   7

1.  Introduction

   While Service Function Chain (SFC) Echo Request, defined in
   [I-D.wang-sfc-multi-layer-oam], always traverses the SFC it directed
   to, the corresponding Echo Reply is sent over IP network
   [I-D.wang-sfc-multi-layer-oam].  There are scenarios when it is
   beneficial to direct the responder to use path other than the IP
   network.  This document defines extensions to the Service Function
   Chain (SFC) Operation, Administration and Maintenance (OAM) that
   enable control of the Echo Reply return path by specifying it as
   Reply Service Function Path.  This document defines a new Type-
   Length-Value (TLV), Reply Service Function Path TLV, for Reply via
   Specified Path mode of SFC Echo Reply (Section 4).

   The Reply Service Function Path TLV provides efficient mechanism to
   test bidirectional and hybrid SFCs, as these were defined in
   Section 2.2 [RFC7665], that allows an operator to test both
   directions of the bidirectional or hybrid SFP with a single SFC Echo
   Request/Echo Reply operation.








Ao, et al.               Expires April 30, 2018                 [Page 2]


Internet-Draft     Controlled Return Path for SFC OAM       October 2017


2.  Conventions used in this document

2.1.  Terminology

   SF - Service Function

   SFF - Service Function Forwarder

   SFC - Service Function Chain, an ordered set of some abstract SFs.

   SFP - Service Function Path

   SPI - Service Path Index

   OAM - Operation, Administration, and Maintenance

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

   Following reply modes had been defined in
   [I-D.wang-sfc-multi-layer-oam]:

   o  Do Not Reply

   o  Reply via an IPv4/IPv6 UDP Packet

   o  Reply via Application Level Control Channel

   o  Reply via Specified Path

   The Reply via Specified Path mode is intended to enforce use of the
   particular return path specified in the included TLV.  This mode may
   help to verify bidirectional continuity or increase robustness of the
   monitoring of the SFC by selecting more stable path.  In case of SFC,
   the sender of Echo Request instructs the egress SFF to send Echo
   Reply message along the SFP specified in the SFC Reply Path TLV
   Section 4.







Ao, et al.               Expires April 30, 2018                 [Page 3]


Internet-Draft     Controlled Return Path for SFC OAM       October 2017


4.  SFC Reply Path TLV

   The SFC Reply Path TLV carries the information that sufficiently
   identifies the return SFP that the SFC Echo Reply message is expected
   to follow.  The format of SFC Reply Path TLV is display 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
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |     SFC Reply Path Type       |          Length               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                 Reply Service Function Path                   |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                      Figure 1: SFC Reply TLV Format

   where:

   o  Reply Path TLV Type: is 2 octets long, indicates the TLV that
      contains a information about the SFC Reply path.

   o  Length: is 2 octets long, MUST be equal to 4

   o  Reply Service Function Path is used to describe the return path
      that an SFC Echo Reply is requested to follow.

   The format of the Reply Service Function Path field displayed in
   Figure 2

        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
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |    Reply Service Function Path Identifier     | Service Index |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

            Figure 2: Reply Service Function Path Field Format

   where:

   o  Reply Service Path Identifier: is SFP identifier for the path that
      the SFC Echo Reply message is requested to be sent over.

   o  Service Index: used for forwarding in the reply SFP.








Ao, et al.               Expires April 30, 2018                 [Page 4]


Internet-Draft     Controlled Return Path for SFC OAM       October 2017


5.  Theory of Operation

   [RFC7110] defined mechanism to control return path for MPLS LSP Echo
   Reply.  In case of SFC, the return path is a SFP along which SFC Echo
   Reply message MUST be transmitted.  Hence, the SFC Reply Path TLV
   included in the SFC Echo Request message MUST sufficiently identify
   the SFP that the sender of the Echo Request message expects the
   receiver to use for the corresponding SFC Echo Reply.

   When sending an Echo Request the sender MUST set the value of Reply
   Mode field to "Reply via Specified Path", defined in
   [I-D.wang-sfc-multi-layer-oam], and MUST include SFC Reply Path TLV.
   The SFC Reply Path TLV includes identifier of the reverse SFP and an
   appropriate Service Index.

   Echo Reply is expected to be sent by the egress SFF of the SFP being
   tested or by the SFF at which SFC TTL expires as defined
   [I-D.ietf-sfc-nsh].  Processing described below equally applies in
   both cases and referred as responding SFF.

   If the Echo Request message with SFC Reply Path TLV, received by the
   responding SFF, has Reply Mode value of "Reply via Specified Path"
   but no SFC Reply Path TLV is present, then the responding SFF MUST
   send Echo Reply with Return Code set to "Reply Path TLV is missing"
   value (TBA2).  If the responding SFF cannot find requested SFP it
   MUST send Echo Reply with Return Code set to "Reply SFP was not
   found" and include the SFC Reply Path TLV from the Echo Request
   message.

5.1.  Case of Bi-directional SFC

   Ability to specify the return path to be used for Echo Reply is very
   useful in bi-directional SFC.  For bi-directional SFC, since the last
   SFF of the forward SFP may not co-locate with classifier of the
   reverse SFP,it is assumed that last SFF doesn't know the reply path
   of a SFC.  So even for bi-directional SFC, a reverse SFP also need to
   be indicated in reply path TLV in echo request message.

6.  Security Considerations

   Security considerations discussed in [I-D.ietf-sfc-nsh] apply to this
   document..

   In addition, the SFC Return Path extension, defined in this document,
   may be used for potential "proxying" attacks.  For example, an echo
   request initiator may specify a return path that has a destination
   different from that of the initiator.  But normally, such attacks
   will not happen in an SFC domain where the initiators and receivers



Ao, et al.               Expires April 30, 2018                 [Page 5]


Internet-Draft     Controlled Return Path for SFC OAM       October 2017


   belong to the same domain, as specified in [RFC7665].  Even if the
   attack happens, in order to prevent using the SFC Return Path
   extension for proxying any possible attacks, the return path SFP
   SHOULD have destination to the sender of the echo request, identified
   in SFC Source TLV [I-D.wang-sfc-multi-layer-oam].  The receiver may
   drop the echo request when it cannot determine whether the return
   path SFP has the destination to the initiator.  That means, when
   sending echo request, the sender SHOULD choose a proper source
   address according the specified return path SFP to help the receiver
   to make the decision.

7.  IANA Considerations

7.1.  SFC Return Path Type

   IANA is requested to assign from its SFC Echo Request/Echo Reply TLV
   registry new type as following:

             +-------+----------------------+---------------+
             | Value | Description          | Reference     |
             +-------+----------------------+---------------+
             | TBA1  | SFC Reply Path Type  | This document |
             +-------+----------------------+---------------+

                       Table 1: SFC Return Path Type

7.2.  New Return Codes

   IANA is requested to assign new return codes from the SFC Echo
   Request/Echo Reply Return Codes registry as following:

          +-------+----------------------------+---------------+
          | Value | Description                | Reference     |
          +-------+----------------------------+---------------+
          | TBA2  | Reply Path TLV is missing  | This document |
          | TBA3  | Reply SFP was not found    | This document |
          +-------+----------------------------+---------------+

                   Table 2: SFC Echo Reply Return Codes

8.  References

8.1.  Normative References

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



Ao, et al.               Expires April 30, 2018                 [Page 6]


Internet-Draft     Controlled Return Path for SFC OAM       October 2017


   [I-D.wang-sfc-multi-layer-oam]
              Mirsky, G., Meng, W., Khasnabish, B., and C. Wang, "Multi-
              Layer Active OAM for Service Function Chains in Networks",
              draft-wang-sfc-multi-layer-oam-10 (work in progress),
              September 2017.

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

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

8.2.  Informative References

   [RFC7110]  Chen, M., Cao, W., Ning, S., Jounay, F., and S. Delord,
              "Return Path Specified Label Switched Path (LSP) Ping",
              RFC 7110, DOI 10.17487/RFC7110, January 2014,
              <https://www.rfc-editor.org/info/rfc7110>.

   [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

   Ting Ao
   ZTE Corporation
   No.889, BiBo Road
   Shanghai  201203
   China

   Phone: +86 21 68897642
   Email: ao.ting@zte.com.cn


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

   Email: gregimirsky@gmail.com





Ao, et al.               Expires April 30, 2018                 [Page 7]


Internet-Draft     Controlled Return Path for SFC OAM       October 2017


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

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











































Ao, et al.               Expires April 30, 2018                 [Page 8]


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