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

Versions: 00 01 02 03 draft-ietf-spring-sr-oam-requirement

spring                                                          N. Kumar
Internet-Draft                                              C. Pignataro
Intended status: Informational                                  N. Akiya
Expires: January 2, 2015                             Cisco Systems, Inc.
                                                                 R. Geib
                                                        Deutsche Telekom
                                                               G. Mirsky
                                                                Ericsson
                                                            July 1, 2014


              OAM Requirements for Segment Routing Network
                draft-kumar-spring-sr-oam-requirement-01

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 January 2, 2015.

Copyright Notice

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



Kumar, et al.            Expires January 2, 2015                [Page 1]


Internet-DraftOAM Requirements for Segment Routing Network     July 2014


   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 . . . . . . . . . . . . . . . . . . . . . . .   4
   8.  Contributing Authors  . . . . . . . . . . . . . . . . . . . .   4
   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   5
     9.1.  Normative References  . . . . . . . . . . . . . . . . . .   5
     9.2.  Informative References  . . . . . . . . . . . . . . . . .   5
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   5

1.  Introduction

   [I-D.filsfils-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

   UCMP: Unequal Cost Multipath





Kumar, et al.            Expires January 2, 2015                [Page 2]


Internet-DraftOAM Requirements for Segment Routing Network     July 2014


   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 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#8:   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#9:   SR OAM SHOULD also have the ability to be initialized from a
            centralized controller.

   REQ#10:  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.





Kumar, et al.            Expires January 2, 2015                [Page 3]


Internet-DraftOAM Requirements for Segment Routing Network     July 2014


   REQ#11:  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#12:  SR OAM MUST have the ability to measure Packet loss, Packet
            Delay or Delay variation.

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

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

   REQ#15:  SR OAM SHOULD NOT create or maintain per path state entry in
            any other nodes other than the Initiator.

   REQ#16:  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#17:  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.

7.  Acknowledgement

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

8.  Contributing Authors

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





Kumar, et al.            Expires January 2, 2015                [Page 4]


Internet-DraftOAM Requirements for Segment Routing Network     July 2014


9.  References

9.1.  Normative References

   [I-D.filsfils-spring-segment-routing]
              Filsfils, C., Previdi, S., Bashandy, A., Decraene, B.,
              Litkowski, S., Horneffer, M., Milojevic, I., Shakir, R.,
              Ytti, S., Henderickx, W., Tantsura, J., and E. Crabbe,
              "Segment Routing Architecture", draft-filsfils-spring-
              segment-routing-04 (work in progress), July 2014.

   [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-02 (work
              in progress), July 2014.

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

9.2.  Informative References

   [RFC4379]  Kompella, K. and G. Swallow, "Detecting Multi-Protocol
              Label Switched (MPLS) Data Plane Failures", RFC 4379,
              February 2006.

   [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, June 2011.

   [RFC6424]  Bahadur, N., Kompella, K., and G. Swallow, "Mechanism for
              Performing Label Switched Path Ping (LSP Ping) over MPLS
              Tunnels", RFC 6424, November 2011.

   [RFC6425]  Saxena, S., 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, November 2011.

Authors' Addresses

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

   Email: naikumar@cisco.com



Kumar, et al.            Expires January 2, 2015                [Page 5]


Internet-DraftOAM Requirements for Segment Routing Network     July 2014


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

   Email: cpignata@cisco.com


   Nobo Akiya
   Cisco Systems, Inc.
   2000 Innovation Drive
   Kanata, ON  K2K 3E8
   Canada

   Email: nobo@cisco.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 January 2, 2015                [Page 6]


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