Internet DRAFT - draft-jain-mvpn-bfd-fast-upstream-failover
draft-jain-mvpn-bfd-fast-upstream-failover
L3VPN P. Jain
Internet-Draft K. Singh
Intended status: Standards Track J. Kotalwar
Expires: October 23, 2012 N. Bhau
Alcatel-Lucent, Inc.
C. Hassen
Bell Canada
April 21, 2012
BGP Extensions for Multicast VPN Fast Upstream Failover
draft-jain-mvpn-bfd-fast-upstream-failover-00
Abstract
This document defines BGP extensions and procedures that allows use
of BFD for Multi Point Networks for fast detection and failover for
upstream faults in Multicast VPNs. The upstream failures addressed
in this proposal can be failure of any node between the Root PE and
Leaf PE or failure between the Multicast Source and Root PE.
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 October 23, 2012.
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
Jain, et al. Expires October 23, 2012 [Page 1]
Internet-Draft BGP Extensions for MVPN Fast Failover April 2012
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 . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Rapid Failure Detection . . . . . . . . . . . . . . . . . . . 6
4. BGP-BFD Attribute . . . . . . . . . . . . . . . . . . . . . . 7
5. Signaling procedures and usage considerations . . . . . . . . 8
5.1. Tunnel Status Tracking for I-PMSI P-tunnel . . . . . . . . 8
5.1.1. Root PE Procedures . . . . . . . . . . . . . . . . . . 8
5.1.2. Leaf PE Procedures . . . . . . . . . . . . . . . . . . 8
5.2. Tunnel Status Tracking for S-PMSI P-tunnel . . . . . . . . 9
5.2.1. Root PE Procedures . . . . . . . . . . . . . . . . . . 9
5.2.2. Leaf PE Procedures . . . . . . . . . . . . . . . . . . 9
5.3. Multicast Source Status Tracking . . . . . . . . . . . . . 10
5.3.1. Root PE Procedures . . . . . . . . . . . . . . . . . . 10
5.3.2. Leaf PE Procedures . . . . . . . . . . . . . . . . . . 10
6. Management Considerations . . . . . . . . . . . . . . . . . . 11
7. Security Considerations . . . . . . . . . . . . . . . . . . . 12
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
10.1. Normative References . . . . . . . . . . . . . . . . . . . 15
10.2. Informative References . . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16
Jain, et al. Expires October 23, 2012 [Page 2]
Internet-Draft BGP Extensions for MVPN Fast Failover April 2012
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 [RFC2119].
When used in lower case, these words convey their typical use in
common language, and are not to be interpreted as described in
RFC2119 [RFC2119].
Jain, et al. Expires October 23, 2012 [Page 3]
Internet-Draft BGP Extensions for MVPN Fast Failover April 2012
1. Introduction
In case of multicast in BGP/MPLS VPNs deployment, for purpose of
redundancy the multicast source could be dual-homed to the Root
PE(s). The dual-homed Root PE(s) could individually originate
P-Tunnel towards the Leaf PE. This mechanism is described in
[I-D.draft-morin-l3vpn-mvpn-fast-failover]. The Leaf PE can source
the traffic from either of the upstream dual-homed Root PE node. In
such a deployment, there could be two types of failure scenarios:-
1. Failure of any network element in the provider network between
Root PE and Leaf PE.
2. Failure of any network element between the Multicast Source and
the Root PEs.
It is desirable to achieve fast failure detection and switchover for
any failure from above scenarios.
This document addresses both the above failure scenarios by using BFD
for Multipoint Networks [I-D.katz-ward-bfd-multipoint] and defining
new BGP extensions for advertising the BFD parameters which will be
used for fast failure detection of scenarios mentioned above.
Jain, et al. Expires October 23, 2012 [Page 4]
Internet-Draft BGP Extensions for MVPN Fast Failover April 2012
2. Terminology
Terminology used in this document:
Root PE: PE closest to the Multicast Source (This could be either
directly connected to Multicast Source or via some network).
P-Tunnel would be originating at this node. This P-Tunnel could be
Inclusive or Selective.
Leaf PE: PE Node closest to the Multicast Receiver (This could be
either directly connected to Multicast Source or via some network).
P-Tunnel would be terminating at this node.
BFD : Bidirectional Forwarding Detection.
Other terminologies are as defined in [RFC6513] and [RFC6514].
Jain, et al. Expires October 23, 2012 [Page 5]
Internet-Draft BGP Extensions for MVPN Fast Failover April 2012
3. Rapid Failure Detection
Multiple Multicast Sources Dual-Homed to PE Nodes
+---+
| |
+--------------------|PE1|- + .--. .--.
/ +------------------| | \ ( ' '.--. +-|-+
/ / +---+ \.-.' IP-MPLS '----| |
(S1)..(Sn) ( network ) |PE3|--(Receiever)
\ \ +---+ / ( .'-' ----| |
\ +------------------| | / '--'. .'. ) +-|-+
+--------------------|PE2|-+ '--''--'
| |
+---+
<--Source to Root Network--><---------MVPN Context------------>
As seen in the above diagram, all the PEs would be part of same
multicast VPN. Multiple multicast sources (S1..Sn) could be dual-
homed to two PEs (PE1 and PE2), referenced as Root PEs. Both the
Root PEs would originate P-tunnel, which would terminate at Leaf PE
(PE3).
As long as C-S is reachable via both Root PEs, the Leaf PE will
select one of the PEs connected to C-S as its Upstream PE with
respect to C-S, this PE would be referred as "Primary Upstream PE".
We will refer to the other PE connected to C-S as the "Standby
Upstream PE". Note that if the connectivity to C-S through the
Primary Upstream PE becomes unavailable, then the PE will select the
Standby Upstream PE as its Upstream PE with respect to C-S. This
procedure is described in [I-D.draft-morin-l3vpn-mvpn-fast-failover].
If it is desired to use BFD to monitor the status of the P-Tunnel,
then there is a need to exchange the BFD discriminator between the
Root PE node and Leaf PE.
If it is desired to use BFD to monitor the status of individual
Multicast Source and P-Tunnel pair, then there is also a need to
exchange the BFD discriminator between the Root PE node and Leaf PE
to track the Multicast-Source and P-Tunnel pair status.
This document defines new BGP extensions for advertising the BFD
parameters to bring up BFD for Multipoint Networks session
[I-D.katz-ward-bfd-multipoint] which would be used to track and
addresses both the above failure scenarios.
Jain, et al. Expires October 23, 2012 [Page 6]
Internet-Draft BGP Extensions for MVPN Fast Failover April 2012
4. BGP-BFD Attribute
This document defines and uses a new BGP attribute called the "BGP-
BFD attribute". This is an optional transitive BGP attribute. The
format of this attribute is defined as follows:
+-------------------------------+
| Flags (1 octet) |
+-------------------------------+
| BFD Discriminator (2 octets) |
+-------------------------------+
The Flags field has the following format:
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
| reserved |
+-+-+-+-+-+-+-+-+
BFD Discriminator: This is the local discriminator for this BFD
session, and is used to uniquely identify it. It MUST be unique
across all BFD sessions on this system, and nonzero. It SHOULD be
set to a random (but still unique) value to improve security. The
value is otherwise outside the scope of this specification.
Jain, et al. Expires October 23, 2012 [Page 7]
Internet-Draft BGP Extensions for MVPN Fast Failover April 2012
5. Signaling procedures and usage considerations
If it is desired to track the P-tunnel status or status of the
Multicast Source connected to Root PE using BFD. It could be
explicitly configured under the MVPN Service.
5.1. Tunnel Status Tracking for I-PMSI P-tunnel
5.1.1. Root PE Procedures
When it is desired to track the P-Tunnel status using BFD, the Root
PE MUST include the BGP-BFD Attribute in the I-PMSI A-D Route
specified in [RFC6514] Section 4.1.
If a P-Tunnel is already signaled, and then it is desired to track
the P-Tunnel status using BFD, I-PMSI A-D Route must be re-sent with
the same attributes as before, but the BGP-BFD Attribute MUST be
included.
If P-Tunnel is already signaled, and P-Tunnel status tracked using
BFD and it is desired to stop tracking P-Tunnel status using BFD,
then I-PMSI A-D Route MUST be re-sent with the same attributes as
before, but the BGP-BFD Attribute MUST be excluded.
5.1.2. Leaf PE Procedures
On receiving the BFD attribute in the I-PMSI A-D Route, the Leaf PE
MUST associate the received discriminator with the P-Tunnel
originating from the Root PE. Once the Leaf PE start getting the BFD
probes from the Root PE with the said discriminator, the BFD session
will be declared up and will then be used to track the health of the
P-Tunnel.
If the Leaf PE does not receive BFD probes for a P-Tunnel from give
Root PE for Detection Time, the BFD session would be brought down.
And, it would declare the P-tunnel associated with the discriminator
as down.
Leaf PE then can then initiate a switchover of the traffic from the
Primary Tunnel, to the Standby Tunnel.
When Leaf PE's P-Tunnel is already up, it receives new I-PMSI A-D
Route with BGP-BFD attribute, it must accept the I-PMSI A-D Route and
associate the discriminator with the P-tunnel. When the BFD probes
are received with the said discriminator, the BFD session is declared
up.
When Leaf PE's P-Tunnel is already up, and is tracked with BFD, and
Jain, et al. Expires October 23, 2012 [Page 8]
Internet-Draft BGP Extensions for MVPN Fast Failover April 2012
it receives new I-PMSI A-D Route without BGP-BFD attribute, it must
accept the I-PMSI A-D Route the BFD session should be declared admin
down. Receiver node SHOULD not switch the traffic to the Standby
P-tunnel.
5.2. Tunnel Status Tracking for S-PMSI P-tunnel
All procedures mentioned in this section are same as of tracking of
I-PMSI P-Tunnel, except that the BGP-BFD Attribute would be sent in
S-PMSI A-D Route.
5.2.1. Root PE Procedures
When is desired to track the P-Tunnel status using BFD, the Root PE
MUST include the BGP-BFD Attribute in the S-PMSI A-D Route specified
in [RFC6514] Section 4.4.
If a P-Tunnel is already signaled, and then it is desired to track
the P-Tunnel status using BFD, S-PMSI A-D Route must be re-sent with
the same attributes as before, but the BGP-BFD Attribute MUST be
included.
If P-Tunnel is already signaled, and P-Tunnel status tracked using
BFD and it is desired to stop tracking P-Tunnel status using BFD,
then S-PMSI A-D Route MUST be re-sent with the same attributes as
before, but the BGP-BFD Attribute MUST be excluded.
5.2.2. Leaf PE Procedures
On receiving the BFD attribute in the S-PMSI A-D Route, the Leaf PE
MUST associate the received discriminator with the P-Tunnel
originating from the Root PE. Once the Leaf PE start getting the BFD
probes from the Root PE with the said discriminator, the BFD session
will be declared up and will then be used to track the health of the
P-Tunnel.
If the Leaf PE does not receive BFD probes from give Detection Time
for a give P-Tunnel, it would declare the P-tunnel associated with
the discriminator as down.
Leaf PE then can then initiate a switchover of the traffic from the
Primary Tunnel, to the Standby Tunnel.
When Leaf PE's P-Tunnel is already up, it receives new S-PMSI A-D
Route with BGP-BFD attribute, it must accept the S-PMSI A-D Route and
associate the discriminator with the P-tunnel. When the BFD probes
are received with the said discriminator, the BFD session is declared
up.
Jain, et al. Expires October 23, 2012 [Page 9]
Internet-Draft BGP Extensions for MVPN Fast Failover April 2012
When Leaf PE's P-Tunnel is already up, and is tracked with BFD, and
it receives new S-PMSI A-D Route without BGP-BFD attribute, it must
accept the S-PMSI A-D Route the BFD session should be declared admin
down. Receiver node SHOULD not switch the traffic to the Standby
P-tunnel.
5.3. Multicast Source Status Tracking
5.3.1. Root PE Procedures
When is desired to track the connectivity status of Multicast-Source
at the Root PE(s), the Root PE MUST include the BGP-BFD Attribute in
the Source Active A-D Route specified in [RFC6514] Section 4.5.
The discriminator advertised in BGP-BFD Attribute in the Source
Active A-D Route, would be used track the Multicast Source and the
P-Tunnel from the Root PE that originated the Source Active A-D
Route.
When the Root PE detects that Multicast Source is reachable, it will
start BFD probes over the P-Tunnel, for P-Tunnel and Multicast Source
combination.
The procedure or techniques used for tracking the Multicast-Source
reachibility at the Root PE(s) could be router reachibility,
interface tracking for directly connected Multicast Source, BFD,
traffic monitoring from a given Multicast Source etc. The details of
the above techniques is outside the scope of this document.
5.3.2. Leaf PE Procedures
On receiving the BFD attribute in the Source Active A-D Route, the
Leaf PE MUST associate the received discriminator with the P-Tunnel
and Multicast Source combination. Once the Leaf PE start getting the
BFD probes from the Root PE with the said discriminator, the BFD
session will be declared up and will then be used to track the health
of the P-Tunnel and Multicast Source combination.
When the Root PE detects that Multicast Source is no longer
reachable, it will advertise the BFD Status for P-Tunnel and
Multicast Source combination to be down by signaling it in DIAG field
of BFD. Leaf PE on receipt of BFD status down for P-Tunnel and
Multicast Source combination, SHOULD declare the source un-reachable
through the given PMSI and can then initiate a switchover of the
traffic from the Primary Tunnel, to the Standby Tunnel.
Jain, et al. Expires October 23, 2012 [Page 10]
Internet-Draft BGP Extensions for MVPN Fast Failover April 2012
6. Management Considerations
None
Jain, et al. Expires October 23, 2012 [Page 11]
Internet-Draft BGP Extensions for MVPN Fast Failover April 2012
7. Security Considerations
Jain, et al. Expires October 23, 2012 [Page 12]
Internet-Draft BGP Extensions for MVPN Fast Failover April 2012
8. Acknowledgements
The authors want to thank Wim Henderickx, Sandeep Bishnoi and Tony
Dilliott of Alcatel-Lucent, Inc for significant contribution and
feedback.
Jain, et al. Expires October 23, 2012 [Page 13]
Internet-Draft BGP Extensions for MVPN Fast Failover April 2012
9. IANA Considerations
Jain, et al. Expires October 23, 2012 [Page 14]
Internet-Draft BGP Extensions for MVPN Fast Failover April 2012
10. References
10.1. Normative References
[I-D.draft-morin-l3vpn-mvpn-fast-failover]
Morin, T., Rekhter, Y., Aggarwal, R., Henderickx, W.,
Muley, P., and R. Qiu, "Multicast VPN fast upstream
failover", draft-morin-l3vpn-mvpn-fast-failover-05 (work
in progress), September 2011.
[I-D.katz-ward-bfd-multipoint]
Katz, D. and D. Ward, "BFD for Multipoint Networks",
draft-katz-ward-bfd-multipoint-02 (work in progress),
February 2009.
[RFC6513] Rosen, E. and R. Aggarwal, "Multicast in MPLS/BGP IP
VPNs", RFC 6513, February 2012.
[RFC6514] Aggarwal, R., Rosen, E., Morin, T., and Y. Rekhter, "BGP
Encodings and Procedures for Multicast in MPLS/BGP IP
VPNs", RFC 6514, February 2012.
10.2. Informative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S.
Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1
Functional Specification", RFC 2205, September 1997.
[RFC4875] Aggarwal, R., Papadimitriou, D., and S. Yasukawa,
"Extensions to Resource Reservation Protocol - Traffic
Engineering (RSVP-TE) for Point-to-Multipoint TE Label
Switched Paths (LSPs)", RFC 4875, May 2007.
Jain, et al. Expires October 23, 2012 [Page 15]
Internet-Draft BGP Extensions for MVPN Fast Failover April 2012
Authors' Addresses
Pradeep Jain
Alcatel-Lucent, Inc.
701 E Middlefield Rd
Mountain View, CA 94043
USA
Email: pradeep.jain@alcatel-lucent.com
Kanwar Singh
Alcatel-Lucent, Inc.
701 E Middlefield Rd
Mountain View, CA 94043
USA
Email: kanwar.singh@alcatel-lucent.com
Jayant Kotalwar
Alcatel-Lucent, Inc.
701 E Middlefield Rd
Mountain View, CA 94043
USA
Email: Jayant.Kotalwar@alcatel-lucent.com
Nehal Bhau
Alcatel-Lucent, Inc.
701 E Middlefield Rd
Mountain View, CA 94043
USA
Email: Nehal.Bhau@alcatel-lucent.com
Clayton Hassen
Bell Canada
2955 Virtual Way
Vancouver
CANADA
Email: Clayton.Hassen@bell.ca
Jain, et al. Expires October 23, 2012 [Page 16]
