Internet DRAFT - draft-hc-mpls-mpoint-bfd-for-mpls
draft-hc-mpls-mpoint-bfd-for-mpls
Network Working Group V. Hegde
Internet-Draft R. Chandrasekar
Expires: March 11, 2013 Juniper Networks
September 7, 2012
Multipoint BFD for MPLS
draft-hc-mpls-mpoint-bfd-for-mpls-00.txt
Abstract
Recent proposals have extended the use of Bidirectional Forwarding
Detection to detect data plane failures in multipoint networks. One
desirable application of Multipoint BFD [MP-BFD] is to detect data
path failures in point-to-multipoint Label Switched Paths (P2MP
LSPs). The scope of this document is to discuss the applicability of
multipoint BFD for fault detection in the data plane of P2MP LSPs.
The document extends the techniques and mechanisms mentioned in
[RFC5884] and applies them to MPLS P2MP environment.
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 March 11, 2013.
Copyright Notice
Copyright (c) 2012 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
Hegde & Chandrasekar Expires March 11, 2013 [Page 1]
Internet-Draft Multipoint BFD for MPLS September 2012
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.
This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
than English.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Conventions . . . . . . . . . . . . . . . . . . . . . . . 3
2. BFD for P2MP LSPs: Motivation . . . . . . . . . . . . . . . . 4
3. Notes on bootstrapping Multipoint BFD for P2MP LSPs . . . . . 5
4. Proposed Solutions . . . . . . . . . . . . . . . . . . . . . . 6
4.1. Periodic echo requests with "Do not reply" . . . . . . . . 6
4.2. Application driven Ping . . . . . . . . . . . . . . . . . 6
5. Security Considerations . . . . . . . . . . . . . . . . . . . 8
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10
8. Normative References . . . . . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12
Hegde & Chandrasekar Expires March 11, 2013 [Page 2]
Internet-Draft Multipoint BFD for MPLS September 2012
1. Introduction
Application of BFD for fault detection in the data path of point-to-
point MPLS LSPs is addressed in [RFC5884]. Since point-to-multipoint
LSPs are not less vulnerable to data path failures than their point-
to-point counterparts, this document extends the techniques used in
[RFC5884] such that they can be applied to P2MP LSPs. This document
stresses the reuse of existing LSP ping mechanism to bootstrap the
BFD sessions for point-to-point LSPs and its application to point-to-
multipoint LSPs and multipoint BFD in order to simplify
implementation and network operations.
1.1. Terminology
The terminology used in this document for MPLS OAM can be found in
[RFC4379].
The terminology for multipoint BFD can be found in [MP-BFD].
1.2. Conventions
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 [RFC5884].
Hegde & Chandrasekar Expires March 11, 2013 [Page 3]
Internet-Draft Multipoint BFD for MPLS September 2012
2. BFD for P2MP LSPs: Motivation
As with P2P LSPs, there is a requirement for faster detection of data
plane failures in P2MP LSPs. Existing mechanisms like P2MP LSP ping
and P2MP trace route are expensive in terms of the amount of control
plane processing required and are catered towards fault isolation or
on-demand fault detection at or by the ingress LSR. Multipoint BFD
offers a way for the egress LSR to detect a loss of connectivity to a
particular ingress along the multicast data path. Some of the
advantages of BFD as listed in [RFC5884] which also apply to P2MP
LSPs are:
a) Support for fault detection for a greater number of LSPs.
b) Fast detection. Considering how BFD is most suitable to be
implemented in the hardware or firmware due to its fixed packet
format, BFD can be used to achieve fault detection with sub-second
granularity. There are several advantages of sub-second detection of
data plane failures in any P2MP LSP at the the egress LSR, a couple
of them being:
1) Multicast Live-Live
For applications that make use of multicast live-live where traffic
is pulled from two different streams and merged at the egress, fast
detection of failures on any one of the streams at the egress of the
P2MP LSP might be desirable to provide seamless service by switching
over to the backup stream to avoid traffic interruptions. Multipoint
BFD is a suitable choice to detect these kinds of data path failures
and to notify the applications of these failures.
2) LSPs with discontinuous traffic flow
One way of doing OAM over a P2MP LSP today is for an application to
monitor the data traffic coming over the P2MP LSP and correlate that
with the health of the data path. For applications that do not have
continuous traffic flowing, it is desirable to monitor the
connectivity of the data path by some other means. Multipoint BFD
can be used for this purpose and the detection can be done at the LHR
instead of the receiver.
Hegde & Chandrasekar Expires March 11, 2013 [Page 4]
Internet-Draft Multipoint BFD for MPLS September 2012
3. Notes on bootstrapping Multipoint BFD for P2MP LSPs
The procedures of Multipoint BFD are described in [MP-BFD]. Although
Multipoint BFD tries to be generic in nature regardless of the
technology used to establish the multipoint tunnel, for P2MP LSPs
there are certain scenarios where making the association of an
incoming BFD packet with its corresponding P2MP LSP becomes a
challenge at the egress. For example in case of Penultimate Hop
Popping (PHP) for a single label stack P2MP LSP, incoming BFD packets
at the egress do not contain enough information to associate them
with a particular P2MP LSP.
A similar problem of bootstrapping was encountered when attempting to
run BFD over P2P LSPs. These problems have been resolved by
following the procedures mentioned in [RFC5884].The procedures
explained in [RFC5884] can be applied to P2MP LSP ping to bootstrap
the multipoint BFD session. Although the mechanisms of [RFC5884]
when appliedto P2MP LSP Ping and Multipoint BFD would work, it may
not necessarily be optimal for a P2MP environment, primarily because:
a) Unidirectional Nature.
Multipoint BFD by nature can be unidirectional. Multipoint BFD in
its primary form is designed for the egress LSR to detect a loss of
connectivity to the ingress along the multipoint path along with
providing the ingress with some optional mechanisms to track the
connectivity to certain egress LSRs. When running multipoint BFD in
this form, the ingress does not have any need to learn the BFD
discriminator of the egress to establish the BFD session. Even if
the ingress does wish to track the connectivity to certain egress
LSRs, this would happen over the unicast path and if the procedures
of [MP-BFD] are followed then the unicast BFD sessions can be
established without any explicit out of band bootstrapping.
b) Scalability
The procedures of P2MP LSP ping are described in [RFC6425]. Although
[RFC6425] talks about various mechanisms to rate limit the echo reply
messages coming into the ingress, in a large deployment, it may not
be optimal to solicit echo replies from all the egress LSRs.
Soliciting replies from all the egress routers may lead to the
ingress being flooded by a large number of messages in a short
duration.
Hegde & Chandrasekar Expires March 11, 2013 [Page 5]
Internet-Draft Multipoint BFD for MPLS September 2012
4. Proposed Solutions
4.1. Periodic echo requests with "Do not reply"
Applying the procedures of [RFC5884]to P2MP LSPs, periodic P2MP LSP
Ping echo request messages MUST be sent by the ingress LSR to the
egress LSR along the same data path as the P2MP LSP. These echo
messages SHOULD contain the local discriminator of the Multipoint BFD
session established by the ingress LSR for the P2MP LSP. The rate of
generation of echo request messages must be considerably slower than
the rate of generation of BFD packets at the ingress LSR. If the
primary purpose of running P2MP LSP Ping is to facilitate the
establishment of the BFD session and its association with the
corresponding P2MP LSP at the egress LSR, then an implementation MAY
set the value of the Reply Mode field in the message to 1 (Do Not
Reply) thus indicating the egress LSRs to suppress the generation of
echo reply messages. By doing so, an implementation avoids the
possibility of congestion at the ingress LSR by not soliciting reply
messages from all the egress LSRs.
Note that even when P2MP LSP Ping is used for bootstrapping BFD
sessions, periodic transmission of the echo request messages are
required by the ingress LSR primarily because in a P2MP LSP
environment, there are valid scenarios where the ingress LSR may not
be aware of the existence of different egress LSRs. In such a case,
the ingress LSR may not have sufficient information to decide when to
send out the LSP ping with the BFD discriminator to bootstrap the BFD
session at the newly attached egress LSRs. By periodically
transmitting LSP Ping echo request messages, the ingress LSR ensures
that any newly attached egress LSR will be able to bind the BFD
session to the P2MP LSP when it receives the next periodic echo
request message.
It is highly possible that an egress LSR will start receiving the
multipoint BFD packets befo \re the LSP ping from the ingress. How
an implementation chooses to handle these incoming BFD packets is
outside the scope of this document and is left to the implementation.
The egress LSR SHOULD follow the procedures mentioned in [RFC5884] to
validate the PING packet and then use the discriminator in the P2MP
echo request message to either bind an existing BFD session to the
P2MP LSP or setup a new BFD session by accepting BFD packets with the
discriminator value it has received in the echo request message from
the ingress.
4.2. Application driven Ping
The rate of generation of periodic echo requests by the ingress LSR
is considerably slower than the rate of generation of BFD packets
Hegde & Chandrasekar Expires March 11, 2013 [Page 6]
Internet-Draft Multipoint BFD for MPLS September 2012
because the processing of PING packet is a control plane processing
extensive operation. For P2MP LSPs, if an implementation of P2MP
ping which is used for bootstrapping the BFD session has chosen to
solicit replies from all the egress LSRs, then it is crucial that
these ping packets are rate limited to avoid congestion at the
ingress LSR. Slowing down the rate of generation of Ping packets
also in turn slows down the bootstrapping of the BFD sessions at the
egress LSRs who might have newly attached themselves to the P2MP LSP.
This may not be desirable for certain applications which may want to
leverage Multipoint BFD to fast detect failures on the data path of a
P2MP LSP at the egress.
Application driven expedited PING is one way to solve this problem.
The decision as to when to send the expedited PING is left to the
implementation and outside the scope of this document, one use of
expedited ping is that if an application running on the ingress LSR
can detect a new node attaching itself as the egress to its P2MP LSP,
then an implementation MAY choose to send an expedited PING packet
over the P2MP data path. An implementation MAY also choose to
solicit an echo reply from one or a subset of egress LSRs using the
Egress Address P2MP Responder Sub-TLV(as described in [RFC6425]) in
the expedited echo request messages, however if an implementation
chooses to solicit replies from a subset of egress LSRs using the
P2MP LSP Ping, then it MUST ensure to avoid congestion at or near the
ingress when the replies arrive.
Periodic echo requests as described in section 4.1 can be used in
conjunction with application driven epedited ping to provide an
optimal solution to bootstrap BFD sessions.Periodic messages ensures
that in a dynamic P2MP LSP environment, where the egress LSRs are
constantly attaching or detaching themselves from the P2MP LSPs, the
association of BFD packets to a P2MP LSP is possible at the egress
LSR. For applications running in the ingress that do track the
egress LSRs of a P2MP LSP, expedited PING could be used to quickly
bootstrap the BFD session at the egress without having to wait for
the next periodic PING, while doing so the application MAY also
choose to solicit replies from a subset of the egress LSRs.
Hegde & Chandrasekar Expires March 11, 2013 [Page 7]
Internet-Draft Multipoint BFD for MPLS September 2012
5. Security Considerations
No new security issues are introduced beyond those that are described
in [RFC6425] and [MP-BFD].
Hegde & Chandrasekar Expires March 11, 2013 [Page 8]
Internet-Draft Multipoint BFD for MPLS September 2012
6. IANA Considerations
This draft does not have any request for IANA.
Hegde & Chandrasekar Expires March 11, 2013 [Page 9]
Internet-Draft Multipoint BFD for MPLS September 2012
7. Acknowledgments
The authors would like to acknowledge the authors of [RFC6425] and
the authors of [RFC5884] for their work, which is substantially re-
used in this document. The authors would like to thank Santosh PK,
Shivakumar Channalli and Harish Sitaraman for their reviews and
feedback on this material.
Hegde & Chandrasekar Expires March 11, 2013 [Page 10]
Internet-Draft Multipoint BFD for MPLS September 2012
8. Normative References
[MP-BFD] Katz, D. and D. Ward, "BFD for Multipoint Networks",
draft-ietf-bfd-multipoint-00 (work in progress),
October 2011.
[RFC5884] Aggarwal, R., Kompella, K., Nadeau, T., and G. Swallow,
"Bidirectional Forwarding Detection (BFD) for MPLS Label
Switched Paths (LSPs)", RFC 5884, June 2010.
[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.
[RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-Protocol
Label Switched (MPLS) Data Plane Failures", RFC 4379,
February 2006.
Hegde & Chandrasekar Expires March 11, 2013 [Page 11]
Internet-Draft Multipoint BFD for MPLS September 2012
Authors' Addresses
Vikas Hegde
Juniper Networks
Embassy Business Park
Bangalore, KA 560093
India
Email: vikashegde@juniper.net
Chandrasekar R
Juniper Networks
Embassy Business Park
Bangalore 560093
India
Email: csekar@juniper.net
Hegde & Chandrasekar Expires March 11, 2013 [Page 12]
