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

Versions: 00

rtgwg
Internet-Draft                                            Anil Kumar S N
Intended Status: Informational                            Gaurav Agrawal
                                                           Vinod Kumar S
                                               Huawei Technologies India
Expires: March 19, 2016                               September 16, 2015


                  MRT OAM Requirements and Use cases
          draft-agv-rtgwg-mrt-oam-requirements-and-usecases-00


Abstract

   IP/LDP Fast-Reroute with Maximally Redundant Trees (MRT-FRR) is a
   technology that gives link-protection and node-protection with 100%
   coverage in any network topology that is still connected after the
   failure.

   MRT-FRR creates two alternate trees separate from the primary next-
   hop forwarding used during stable operation.  These two trees are
   maximally diverse from each other, providing link and node protection
   for 100% of paths and failures as long as the failure does not cut
   the network into multiple pieces.

   This document spcifies how data plane protocols can be applied to
   operations and maintenance procedures for MRT. The document is
   structured to outline how Operations and Management functionality can
   be used to assist in fault management.


Status of this Memo

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as
   Internet-Drafts.

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

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/1id-abstracts.html



<Author>                 Expires March 19, 2016                 [Page 1]


Internet-Draft               <OAM for MRT>            September 16, 2015


   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html


Copyright and License Notice

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



Table of Contents

   1  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . .  3
     1.1  Terminology . . . . . . . . . . . . . . . . . . . . . . . .  3
   2  MRT OAM Requirement list  . . . . . . . . . . . . . . . . . . .  4
   3  MRT OAM Use Cases . . . . . . . . . . . . . . . . . . . . . . .  6
     3.1  Introduction  . . . . . . . . . . . . . . . . . . . . . . .  6
     3.2  Fault detection for MRT backup paths (MRT Red/ MRT Blue
          topology) . . . . . . . . . . . . . . . . . . . . . . . . .  6
     3.3  Runtime Location of Cut-Vertices  . . . . . . . . . . . . .  6
     3.4  Runtime Location of Cut-Links . . . . . . . . . . . . . . .  7
     3.5  Locate overloaded nodes/links due to MRT backup paths . . .  7
   4  Security Considerations . . . . . . . . . . . . . . . . . . . .  8
   5  IANA Considerations . . . . . . . . . . . . . . . . . . . . . .  8
   6  References  . . . . . . . . . . . . . . . . . . . . . . . . . .  8
     6.1  Normative References  . . . . . . . . . . . . . . . . . . .  8
     6.2  Informative References  . . . . . . . . . . . . . . . . . .  8
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . .  9












<Author>                 Expires March 19, 2016                 [Page 2]


Internet-Draft               <OAM for MRT>            September 16, 2015


1  Introduction

   Maximally Redundant Trees (MRT) is a pair of trees where the path
   from any node X to the root R along the first tree and the path from
   the same node X to the root along the second tree share the minimum
   number of nodes and the minimum number of links.  Each such shared
   node is a cut-vertex.  Any shared links are cut-links. Any RT is an
   MRT but many MRTs are not RTs.

   Maximally Redundant Multicast Trees (MRMT) is A pair of multicast
   trees built of the sub-set of MRTs that is needed to reach all
   interested receivers.

   IP/LDP Fast-Reroute with MRT (MRT-FRR) uses two maximally diverse
   forwarding topologies to provide alternates.  A primary next-hop
   should be on only one of the diverse forwarding topologies; thus, the
   other can be used to provide an alternate.  Once traffic has been
   moved to one of MRTs, it is not subject to further repair actions.
   Thus, the traffic will not loop even if a worse failure (e.g. node)
   occurs when protection was only available for a simpler failure (e.g.
   link).

   There is a need for an administrator to verify MRT paths so that
   identifying bottle neck nodes/links, Low capacity link/node &
   important link/nodes which is not desired to be overloaded etc...

   This documents will help administrator to make a judicial decision to
   exclude few nodes/links from MRT as specified in "MRT-specific
   exclusion mechanism" in MRT FRR Architecture or to create new MRT
   profiles for better network design/planning.


1.1  Terminology

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














<Author>                 Expires March 19, 2016                 [Page 3]


Internet-Draft               <OAM for MRT>            September 16, 2015


2  MRT OAM Requirement list

   This section list the MRT OAM requirement for MRT enabled network.
   The below listed requirement MUST be supported with MPLS, IP and IPv6
   data plane:


   REQ#1: MRT OAM MUST support both On-demand and Continuous validation
   of Red path.

   REQ#2: MRT OAM MUST support both On-demand and Continuous validation
   of Blue path.

   REQ#3: MRT OAM packet MUST follow exactly the same path as Red
   traffic till the destination when probing is initiated for Red
   topology.

   REQ#4:   MRT OAM packet MUST follow exactly the same path as Blue
   traffic till the destination when probing is initiated for Blue
   topology.

   REQ#5:   MRT OAM packet MUST have ability to exercise any available
   paths, not just path on which probe is initiated while returning
   response.

   REQ#6:   MRT OAM MUST support MPLS LSP ping for RED topology when LDP
   is used as forwarding plane.

   REQ#7:   MRT OAM MUST support MPLS SR ping for RED topology when SR
   is used as forwarding plane.

   REQ#8:   MRT OAM MUST support MPLS IP ping for RED topology when IP
   is used as forwarding plane.

   REQ#9:   MRT OAM MUST support MPLS IPv6 ping for RED topology when
   IPv6 is used as forwarding plane.

   REQ#10:  MRT OAM MUST support MPLS LSP ping for BLUE topology when
   LDP is used as forwarding plane.

   REQ#11:  MRT OAM MUST support MPLS SR ping for BLUE topology when SR
   is used as forwarding plane.

   REQ#12:  MRT OAM MUST support MPLS IP ping for BLUE topology when IP
   is used as forwarding plane.

   REQ#13:  MRT OAM MUST support MPLS IPv6 ping for BLUE topology when
   IPv6 is used as forwarding plane.



<Author>                 Expires March 19, 2016                 [Page 4]


Internet-Draft               <OAM for MRT>            September 16, 2015


   REQ#14:  MRT OAM MUST support MPLS LSP Trace Route for RED topology
   when LDP is used as forwarding plane.

   REQ#15:  MRT OAM MUST support MPLS SR Trace Route for RED topology
   when SR is used as forwarding plane.

   REQ#16:  MRT OAM MUST support MPLS IP Trace Route for RED topology
   when IP is used as forwarding plane.

   REQ#17:  MRT OAM MUST support MPLS IPv6 Trace Route for RED topology
   when IPv6 is used as forwarding plane.

   REQ#18:  MRT OAM MUST support MPLS LSP Trace Route for BLUE topology
   when LDP is used as forwarding plane.

   REQ#19:  MRT OAM MUST support MPLS SR Trace Route for BLUE topology
   when SR is used as forwarding plane.

   REQ#20:  MRT OAM MUST support MPLS IP Trace Route for BLUE topology
   when IP is used as forwarding plane.

   REQ#21:  MRT OAM MUST support MPLS IPv6 Trace Route for BLUE topology
   when IPv6 is used as forwarding plane.

   REQ#22:  MRT OAM SHOULD have the ability to allow the Initiator to
   control on which topology response should be received from any
   transit or egress responder.

   i.e., Let's say probe is initiated on Red topology then there should
   be option to get response on default topology which is a default
   behavior control is need to force the responder to send response in
   received topology i.e., Red Topology.

   REQ#23:  MRT OAM MUST have the ability to initialize probe from any
   arbitrary node to perform connectivity verification and continuity
   check to any other node within MRT domain.

    REQ#24:  In case of any failure with continuity check with respect
   to MRT Red or MRT Blue topology, MRT OAM SHOULD support rapid
   Connectivity Fault localization to take corrective measures (isolate
   node from MRT ISLAND, advertise link as MRT ineligible link etc...)
   failure occurs.

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






<Author>                 Expires March 19, 2016                 [Page 5]


Internet-Draft               <OAM for MRT>            September 16, 2015


3  MRT OAM Use Cases

   This section describes MRT OAM features and use cases of a MRT OAM.
   This document describes illustrates use-cases based on data plane
   path monitoring capabilities. The use case is limited to a single MRT
   domain.

3.1  Introduction

   MRT enables forwarding of packets along pre-defined paths in a
   specific topology. It is essential for a network operator to monitor
   MRT backup paths (MRT Red and MRT Blue). The monitoring flow is
   expected to be forwarded in data plane in a similar way as user
   packets on primary path failure. One of the major output of MRT OAM
   would be preparing MRT ineligible link list and MRT ineligible node
   list or adding more nodes to MRT ISLAND.

3.2  Fault detection for MRT backup paths (MRT Red/ MRT Blue topology)
   Fault detection for MRT Backup Paths (Red & Blue Topology) is
   required to make sure backup paths are UP and Running. It's required
   to diagnose fault related to multiple scenarios :

   1) Manual errors such as miss configuration

     a) Inconsistent GADAG root selection

     b) Non MRT supporting routers being part of MRT ISLAND (Missing
   configuration)

   2) Connectivity issues

   3) Low end devices memory saturation (new addition to fib in case if
   its gets rejected)

   4) Misbehaving devices

   5) Forwarding protocol issues

   6) MRT algorithms issues

3.3  Runtime Location of Cut-Vertices

   Cut-vertex is a vertex whose removal partitions the network. Its
   important to find out any cut-vertex at run time created due to
   network changes. Any corrective actions can be taken by administrator
   one such example is adding new vertices to remove such bottle necks





<Author>                 Expires March 19, 2016                 [Page 6]


Internet-Draft               <OAM for MRT>            September 16, 2015


3.4  Runtime Location of Cut-Links

   Cut-link is a link whose removal partitions the network.  A cut-link
   by definition must be connected between two cut-vertices.  If there
   are multiple parallel links, then they are referred to as cut-links
   in this document if removing the set of parallel links would
   partition the network. Its important to find out any cut-links at run
   time created due to network changes. any corrective actions can be
   taken by administrator one such example is adding new vertices to
   remove such bottle necks.

3.5  Locate overloaded nodes/links due to MRT backup paths

   Its important to find out at run time about the intermediate transit
   nodes which is been used by multiple MRT Red and MRT blue paths. This
   becomes a bottle neck, it would be better to offload backup paths
   from overloaded links or nodes by adding new nodes into MRT.


































<Author>                 Expires March 19, 2016                 [Page 7]


Internet-Draft               <OAM for MRT>            September 16, 2015


4  Security Considerations

   There are no security considerations


5  IANA Considerations

   There are no IANA considerations


6  References

6.1  Normative References

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

   [RFC1776]  Crocker, S., "The Address is the Message", RFC 1776, April
              1 1995.

   [TRUTHS]   Callon, R., "The Twelve Networking Truths", RFC 1925,
              April 1 1996.


6.2  Informative References

   [EVILBIT]  Bellovin, S., "The Security Flag in the IPv4 Header",
              RFC 3514, April 1 2003.

   [RFC5513]  Farrel, A., "IANA Considerations for Three Letter
              Acronyms", RFC 5513, April 1 2009.

   [RFC5514]  Vyncke, E., "IPv6 over Social Networks", RFC 5514, April 1
              2009.

















<Author>                 Expires March 19, 2016                 [Page 8]


Internet-Draft               <OAM for MRT>            September 16, 2015


Authors' Addresses


   Anil Kumar S N
   Huawei Technologies India Pvt. Ltd,
   Near EPIP Industrial Area,
   Kundalahalli Village,
   Whitefield,
   Bangalore - 560037

   EMail: anil.sn@huawei.com



   Gaurav Agrawal
   Huawei Technologies India Pvt. Ltd,
   Near EPIP Industrial Area,
   Kundalahalli Village,
   Whitefield,
   Bangalore - 560037

   EMail: gaurav.agrawal@huawei.com




   Vinod Kumar S
   Huawei Technologies India Pvt. Ltd,
   Near EPIP Industrial Area,
   Kundalahalli Village,
   Whitefield,
   Bangalore - 560037

   EMail: vinods.kumar@huawei.com

















<Author>                 Expires March 19, 2016                 [Page 9]


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