[Docs] [txt|pdf|xml|html] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: (draft-kumar-spring-sr-oam-requirement) 00 01 02 03

spring                                                          N. Kumar
Internet-Draft                                              C. Pignataro
Intended status: Informational                       Cisco Systems, Inc.
Expires: July 6, 2017                                           N. Akiya
                                                     Big Switch Networks
                                                                 R. Geib
                                                        Deutsche Telekom
                                                               G. Mirsky
                                                                Ericsson
                                                            S. Litkowski
                                                                  Orange
                                                         January 2, 2017


              OAM Requirements for Segment Routing Network
                draft-ietf-spring-sr-oam-requirement-03

Abstract

   This document describes a list of functional requirement for OAM in
   Segment Routing (SR) based network.

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 6, 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



Kumar, et al.             Expires July 6, 2017                  [Page 1]


Internet-DraftOAM Requirements for Segment Routing Network  January 2017


   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.  Requirements notation . . . . . . . . . . . . . . . . . . . .   2
   3.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   2
   4.  Detailed Requirement list . . . . . . . . . . . . . . . . . .   3
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   4
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .   4
   7.  Acknowledgement . . . . . . . . . . . . . . . . . . . . . . .   5
   8.  Contributing Authors  . . . . . . . . . . . . . . . . . . . .   5
   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   5
     9.1.  Normative References  . . . . . . . . . . . . . . . . . .   5
     9.2.  Informative References  . . . . . . . . . . . . . . . . .   5
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   6

1.  Introduction

   [I-D.ietf-spring-segment-routing] introduces and explains Segment
   Routing architecture that leverages source routing and tunneling
   standards which can be applied directly to MPLS dataplane with no
   changes on forwarding plane and on IPv6 dataplane with new Routing
   Extension Header.

   This document list the OAM requirements for Segment Routing based
   network which can further be used to produce OAM tools, either
   through enhancing existing OAM tools or constructing new OAM tools,
   for path liveliness and service validation.

2.  Requirements notation

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

3.  Terminology

   SR OAM Packet: OAM probe originated and processed within SR domain(s)

   ECMP: Equal Cost Multipath

   SR: Segment Routing




Kumar, et al.             Expires July 6, 2017                  [Page 2]


Internet-DraftOAM Requirements for Segment Routing Network  January 2017


   UCMP: Unequal Cost Multipath

   Initiator: Centralized OAM initiator or PMS as referred in
   [I-D.geib-spring-oam-usecase]

4.  Detailed Requirement list

   This section list the OAM requirement for Segment Routing based
   network.  The below listed requirement MUST be supported with both
   MPLS and IPv6 dataplane:

   REQ#1:   SR OAM MUST support both On-demand and Continuous OAM
            functionality.

   REQ#2:   The SR OAM packet MUST follow exactly the same path as
            dataplane traffic.

   REQ#3:   The SR OAM packet MUST have the ability to discover and
            exercise equal cost multipath (ECMP) paths.

   REQ#4:   The SR OAM packet MUST have the ability to discover and
            exercise unequal cost multipath (UCMP) paths.

   REQ#5:   The SR OAM packet MUST have ability to exercise any
            available paths, not just best path available.

   REQ#6:   The forwarding semantic of adjacency Segment ID raises a
            need for additional consideration to detect any failure in
            forwarding to the right adjacency.  SR OAM MUST have the
            ability to detect any failure in Node SID and adjacency
            segment based forwarding.

   REQ#7:   SR OAM SHOULD have the ability to allow the Initiator to
            control the return path from any transit or egress
            responder.

   REQ#8:   SR OAM MUST have the ability to be initialized from an
            arbitrary node to perform connectivity verification and
            continuity check to any other node within SR domain.

   REQ#9:   In case of any failure with continuity check, SR OAM SHOULD
            support rapid Connectivity Fault localization to isolate the
            node on which the failure occurs.

   REQ#10:  SR OAM SHOULD also have the ability to be initialized from a
            centralized controller.





Kumar, et al.             Expires July 6, 2017                  [Page 3]


Internet-DraftOAM Requirements for Segment Routing Network  January 2017


   REQ#11:  When SR OAM is initialized from centralized controller, it
            MUST have the ability to alert any edge node in SR domain
            about the corresponding path or service failure.  The node
            on receiving the alert MAY take a local protection action or
            pop an informational message.

   REQ#12:  When SR OAM is initialized from centralized controller, it
            SHOULD support node redundancy.  If primary Initiator fails,
            secondary one MUST take over the responsibility without
            having any impact on customer traffic.

   REQ#13:  SR OAM MUST have the ability to measure Packet loss, Packet
            Delay or Delay variation using Active (using synthetic
            probe) and Passive (using data stream) mode.

   REQ#14:  When a new path is instantiated, SR OAM SHOULD allow path
            verification without noticeable delay.

   REQ#15:  The above listed requirements SHOULD be supported without
            any scalability limitation imposed and SHOULD be extensible
            to accommodate any new SR functionality.

   REQ#16:  SR OAM SHOULD minimize the need to create or maintain per
            path state entry in any other nodes other than the
            Initiator.

   REQ#17:  When traffic engineering is initiated by centralized
            controller device, and when SR OAM is performed by
            individual nodes, there MUST be a mechanism to communicate
            failure to centralized controller device.

   REQ#18:  When service instruction is present in SR OAM packet header,
            there MUST be a method to disallow applying the service to
            the OAM packet to handle cases where that may result in
            unintended corruption of the OAM packet.

5.  IANA Considerations

   This document does not propose any IANA consideration.

6.  Security Considerations

   This document list the OAM requirement for Segment Routing network
   and does not raise any security considerations.







Kumar, et al.             Expires July 6, 2017                  [Page 4]


Internet-DraftOAM Requirements for Segment Routing Network  January 2017


7.  Acknowledgement

   The authors would like to thank Stefano Previdi for his review.

8.  Contributing Authors

   Sriganesh Kini
   Ericsson
   Email: sriganesh.kini@ericsson.com

9.  References

9.1.  Normative References

   [I-D.geib-spring-oam-usecase]
              Geib, R., Filsfils, C., Pignataro, C., and N. Kumar, "Use
              case for a scalable and topology aware MPLS data plane
              monitoring system", draft-geib-spring-oam-usecase-06 (work
              in progress), July 2015.

   [I-D.ietf-spring-segment-routing]
              Filsfils, C., Previdi, S., Decraene, B., Litkowski, S.,
              and R. Shakir, "Segment Routing Architecture", draft-ietf-
              spring-segment-routing-10 (work in progress), November
              2016.

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

9.2.  Informative References

   [RFC4379]  Kompella, K. and G. Swallow, "Detecting Multi-Protocol
              Label Switched (MPLS) Data Plane Failures", RFC 4379,
              DOI 10.17487/RFC4379, February 2006,
              <http://www.rfc-editor.org/info/rfc4379>.

   [RFC6291]  Andersson, L., van Helvoort, H., Bonica, R., Romascanu,
              D., and S. Mansfield, "Guidelines for the Use of the "OAM"
              Acronym in the IETF", BCP 161, RFC 6291,
              DOI 10.17487/RFC6291, June 2011,
              <http://www.rfc-editor.org/info/rfc6291>.

   [RFC6424]  Bahadur, N., Kompella, K., and G. Swallow, "Mechanism for
              Performing Label Switched Path Ping (LSP Ping) over MPLS
              Tunnels", RFC 6424, DOI 10.17487/RFC6424, November 2011,
              <http://www.rfc-editor.org/info/rfc6424>.



Kumar, et al.             Expires July 6, 2017                  [Page 5]


Internet-DraftOAM Requirements for Segment Routing Network  January 2017


   [RFC6425]  Saxena, S., Ed., Swallow, G., Ali, Z., Farrel, A.,
              Yasukawa, S., and T. Nadeau, "Detecting Data-Plane
              Failures in Point-to-Multipoint MPLS - Extensions to LSP
              Ping", RFC 6425, DOI 10.17487/RFC6425, November 2011,
              <http://www.rfc-editor.org/info/rfc6425>.

Authors' Addresses

   Nagendra Kumar
   Cisco Systems, Inc.
   7200 Kit Creek Road
   Research Triangle Park, NC  27709
   US

   Email: naikumar@cisco.com


   Carlos Pignataro
   Cisco Systems, Inc.
   7200 Kit Creek Road
   Research Triangle Park, NC  27709-4987
   US

   Email: cpignata@cisco.com


   Nobo Akiya
   Big Switch Networks
   Japan

   Email: nobo.akiya.dev@gmail.com


   Ruediger Geib
   Deutsche Telekom
   Heinrich Hertz Str. 3-7
   Darmstadt  64295
   Germany

   Email: Ruediger.Geib@telekom.de


   Greg Mirsky
   Ericsson

   Email: gregory.mirsky@ericsson.com





Kumar, et al.             Expires July 6, 2017                  [Page 6]


Internet-DraftOAM Requirements for Segment Routing Network  January 2017


   Stephane Litkowski
   Orange

   Email: stephane.litkowski@orange.com















































Kumar, et al.             Expires July 6, 2017                  [Page 7]


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