Internet DRAFT - draft-agv-rtgwg-mrt-oam-requirements-and-usecases
draft-agv-rtgwg-mrt-oam-requirements-and-usecases
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]
