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 Expires March 19, 2016 [Page 1] Internet-Draft 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 Expires March 19, 2016 [Page 2] Internet-Draft 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]. Expires March 19, 2016 [Page 3] Internet-Draft 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. Expires March 19, 2016 [Page 4] Internet-Draft 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. Expires March 19, 2016 [Page 5] Internet-Draft 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 Expires March 19, 2016 [Page 6] Internet-Draft 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. Expires March 19, 2016 [Page 7] Internet-Draft 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. Expires March 19, 2016 [Page 8] Internet-Draft 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 Expires March 19, 2016 [Page 9]