| L3VPN | P. Jain |
| Internet-Draft | K. Singh |
| Intended status: Standards Track | J. Kotalwar |
| Expires: October 21, 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
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.
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 21, 2012.
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 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.
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].
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:-
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.
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].
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.
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.
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.
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.
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 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.
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.
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.
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.
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.
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.
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.
None
The authors want to thank Wim Henderickx, Sandeep Bishnoi and Tony Dilliott of Alcatel-Lucent, Inc for significant contribution and feedback.
| [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. |
| [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", Internet-Draft draft-morin-l3vpn-mvpn-fast-failover-05, September 2011. |
| [I-D.katz-ward-bfd-multipoint] | Katz, D and D Ward, "BFD for Multipoint Networks", Internet-Draft draft-katz-ward-bfd-multipoint-02, February 2009. |
| [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. |