One document matched: draft-jain-mvpn-bfd-fast-upstream-failover-00.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!-- edited with XMLSPY v5 rel. 4 U (http://www.xmlspy.com) by Fred Baker (private) -->
<!DOCTYPE rfc SYSTEM "http://xml.resource.org/authoring/rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc tocompact="no"?>
<?rfc tocdepth="6"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<rfc category="std" docName="draft-jain-mvpn-bfd-fast-upstream-failover-00"
ipr="trust200902">
<front>
<title abbrev="BGP Extensions for MVPN Fast Failover">BGP Extensions for
Multicast VPN Fast Upstream Failover</title>
<author fullname="Pradeep Jain" initials="P." surname="Jain">
<organization>Alcatel-Lucent, Inc.</organization>
<address>
<postal>
<street>701 E Middlefield Rd</street>
<city>Mountain View, CA</city>
<code>94043</code>
<country>USA</country>
</postal>
<email>pradeep.jain@alcatel-lucent.com</email>
</address>
</author>
<author fullname="Kanwar Singh" initials="K." surname="Singh">
<organization>Alcatel-Lucent, Inc.</organization>
<address>
<postal>
<street>701 E Middlefield Rd</street>
<city>Mountain View, CA</city>
<code>94043</code>
<country>USA</country>
</postal>
<email>kanwar.singh@alcatel-lucent.com</email>
</address>
</author>
<author fullname="Jayant Kotalwar" initials="J." surname="Kotalwar">
<organization>Alcatel-Lucent, Inc.</organization>
<address>
<postal>
<street>701 E Middlefield Rd</street>
<city>Mountain View, CA</city>
<code>94043</code>
<country>USA</country>
</postal>
<email>Jayant.Kotalwar@alcatel-lucent.com</email>
</address>
</author>
<author fullname="Nehal Bhau" initials="N." surname="Bhau">
<organization>Alcatel-Lucent, Inc.</organization>
<address>
<postal>
<street>701 E Middlefield Rd</street>
<city>Mountain View, CA</city>
<code>94043</code>
<country>USA</country>
</postal>
<email>Nehal.Bhau@alcatel-lucent.com</email>
</address>
</author>
<author fullname="Clayton Hassen" initials="C."
surname="Hassen">
<organization>Bell Canada</organization>
<address>
<postal>
<street>2955 Virtual Way</street>
<city>Vancouver</city>
<code></code>
<country>CANADA</country>
</postal>
<email>Clayton.Hassen@bell.ca</email>
</address>
</author>
<date day="21" month="April" year="2012" />
<area>Internet Area</area>
<workgroup>L3VPN</workgroup>
<abstract>
<t>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.</t>
</abstract>
</front>
<middle>
<t>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 <xref
target="RFC2119" />.</t>
<t>When used in lower case, these words convey their typical use in common
language, and are not to be interpreted as described in RFC2119 <xref
target="RFC2119" />.</t>
<section title="Introduction">
<t>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 <xref
target="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:-</t>
<list style="numbers">
<t>Failure of any network element in the provider network between Root
PE and Leaf PE.</t>
<t>Failure of any network element between the Multicast Source and the
Root PEs.</t>
</list>
<t>It is desirable to achieve fast failure detection and switchover for
any failure from above scenarios.</t>
<t>This document addresses both the above failure scenarios by using BFD
for Multipoint Networks <xref target="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.</t>
</section>
<section title="Terminology">
<t>Terminology used in this document:</t>
<t>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.</t>
<t>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.</t>
<t>BFD : Bidirectional Forwarding Detection.</t>
<t>Other terminologies are as defined in <xref target="RFC6513" /> and
<xref target="RFC6514" />.</t>
</section>
<section title="Rapid Failure Detection">
<t>Multiple Multicast Sources Dual-Homed to PE Nodes</t>
<figure>
<artwork>
+---+
| |
+--------------------|PE1|- + .--. .--.
/ +------------------| | \ ( ' '.--. +-|-+
/ / +---+ \.-.' IP-MPLS '----| |
(S1)..(Sn) ( network ) |PE3|--(Receiever)
\ \ +---+ / ( .'-' ----| |
\ +------------------| | / '--'. .'. ) +-|-+
+--------------------|PE2|-+ '--''--'
| |
+---+
<--Source to Root Network--><---------MVPN Context------------>
</artwork>
</figure>
<t>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).</t>
<t>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
<xref target="I-D.draft-morin-l3vpn-mvpn-fast-failover" />.</t>
<t>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.</t>
<t>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.</t>
<t>This document defines new BGP extensions for advertising the BFD parameters
to bring up BFD for Multipoint Networks session <xref target="I-D.katz-ward-bfd-multipoint"/>
which would be used to track and addresses both the above failure scenarios.
</t>
</section>
<section title="BGP-BFD Attribute">
<t>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:</t>
<figure>
<artwork>
+-------------------------------+
| Flags (1 octet) |
+-------------------------------+
| BFD Discriminator (2 octets) |
+-------------------------------+
</artwork>
</figure>
<t>The Flags field has the following format:</t>
<figure>
<artwork>
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
| reserved |
+-+-+-+-+-+-+-+-+
</artwork>
</figure>
<t>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.</t>
</section>
<section title="Signaling procedures and usage considerations">
<t>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.</t>
<section title="Tunnel Status Tracking for I-PMSI P-tunnel">
<section title="Root PE Procedures">
<t>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 <xref target="RFC6514" /> Section 4.1.</t>
<t>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.</t>
<t>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.</t>
</section>
<section title="Leaf PE Procedures">
<t>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.</t>
<t>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.</t>
<t>Leaf PE then can then initiate a switchover of the traffic from
the Primary Tunnel, to the Standby Tunnel.</t>
<t>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.</t>
<t>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.</t>
</section>
</section>
<section title="Tunnel Status Tracking for S-PMSI P-tunnel">
<t>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.</t>
<section title="Root PE Procedures">
<t>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 <xref target="RFC6514" /> Section 4.4.</t>
<t>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.</t>
<t>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.</t>
</section>
<section title="Leaf PE Procedures">
<t>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.</t>
<t>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.</t>
<t>Leaf PE then can then initiate a switchover of the traffic from
the Primary Tunnel, to the Standby Tunnel.</t>
<t>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.</t>
<t>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.</t>
</section>
</section>
<section title="Multicast Source Status Tracking">
<section title="Root PE Procedures">
<t>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 <xref
target="RFC6514" /> Section 4.5.</t>
<t>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.</t>
<t>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.</t>
<t>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.</t>
</section>
<section title="Leaf PE Procedures">
<t>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.</t>
<t>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.</t>
</section>
</section>
</section>
<section title="Management Considerations">
<t>None</t>
</section>
<section anchor="Security" title="Security Considerations" />
<section anchor="Ack" title="Acknowledgements">
<t>The authors want to thank Wim Henderickx, Sandeep Bishnoi and Tony Dilliott of
Alcatel-Lucent, Inc for significant contribution and feedback.</t>
</section>
<section anchor="IANA" title="IANA Considerations" />
</middle>
<back>
<references title="Normative References">
<?rfc include='reference.RFC.6513'?>
<?rfc include='reference.RFC.6514'?>
<!--
Begin inclusion reference.I-D.draft-morin-l3vpn-mvpn-fast-failover.xml.
-->
<reference anchor="I-D.draft-morin-l3vpn-mvpn-fast-failover">
<front>
<title>Multicast VPN fast upstream failover</title>
<author fullname="Thomas Morin" initials="T" surname="Morin">
<organization></organization>
</author>
<author fullname="Yakov Rekhter" initials="Y" surname="Rekhter">
<organization></organization>
</author>
<author fullname="Rahul Aggarwal" initials="R" surname="Aggarwal">
<organization></organization>
</author>
<author fullname="Wim Henderickx" initials="W" surname="Henderickx">
<organization></organization>
</author>
<author fullname="Praveen Muley" initials="P" surname="Muley">
<organization></organization>
</author>
<author fullname="Ray (Lei) Qiu" initials="R" surname="Qiu">
<organization></organization>
</author>
<date day="15" month="September" year="2011" />
<abstract>
<t>This document defines multicast VPN extensions and procedures
that allow fast failover for upstream failures, by allowing
downstream PEs to take into account the status of Provider-Tunnels
(P-tunnels) when selecting the upstream PE for a VPN multicast
flow, and extending BGP MVPN routing so that a C-multicast route
can be advertised toward a standby upstream PE.</t>
</abstract>
</front>
<seriesInfo name="Internet-Draft"
value="draft-morin-l3vpn-mvpn-fast-failover-05" />
<format target="http://www.ietf.org/internet-drafts/draft-morin-l3vpn-mvpn-fast-failover-05.txt"
type="TXT" />
</reference>
<!--
End inclusion reference.I-D.draft-morin-l3vpn-mvpn-fast-failover.xml.
-->
<!--
Begin inclusion reference.I-D.katz-ward-bfd-multipoint.xml.
-->
<reference anchor="I-D.katz-ward-bfd-multipoint">
<front>
<title>BFD for Multipoint Networks</title>
<author fullname="Dave Katz" initials="D" surname="Katz">
<organization></organization>
</author>
<author fullname="David Ward" initials="D" surname="Ward">
<organization></organization>
</author>
<date day="5" month="February" year="2009" />
<abstract>
<t>This document describes extensions to the Bidirectional
Forwarding Detection (BFD) protocol for its use in multipoint and
multicast networks. Comments on this draft should be directed to
rtg- bfd@ietf.org.</t>
</abstract>
</front>
<seriesInfo name="Internet-Draft"
value="draft-katz-ward-bfd-multipoint-02" />
<format target="http://www.ietf.org/internet-drafts/draft-katz-ward-bfd-multipoint-02.txt"
type="TXT" />
</reference>
<!--
End inclusion reference.I-D.katz-ward-bfd-multipoint.xml.
-->
</references>
<references title="Informative References">
<?rfc include='reference.RFC.2119'?>
<?rfc include='reference.RFC.2205'?>
<?rfc include='reference.RFC.4875'?>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 20:48:50 |