draft-ietf-bess-mvpn-fast-failover-06.txt   draft-ietf-bess-mvpn-fast-failover-07.txt 
Network Working Group T. Morin, Ed. Network Working Group T. Morin, Ed.
Internet-Draft Orange Internet-Draft Orange
Intended status: Standards Track R. Kebler, Ed. Intended status: Standards Track R. Kebler, Ed.
Expires: January 3, 2020 Juniper Networks Expires: February 25, 2020 Juniper Networks
G. Mirsky, Ed. G. Mirsky, Ed.
ZTE Corp. ZTE Corp.
July 2, 2019 August 24, 2019
Multicast VPN fast upstream failover Multicast VPN fast upstream failover
draft-ietf-bess-mvpn-fast-failover-06 draft-ietf-bess-mvpn-fast-failover-07
Abstract Abstract
This document defines multicast VPN extensions and procedures that This document defines multicast VPN extensions and procedures that
allow fast failover for upstream failures, by allowing downstream PEs allow fast failover for upstream failures, by allowing downstream PEs
to take into account the status of Provider-Tunnels (P-tunnels) when to take into account the status of Provider-Tunnels (P-tunnels) when
selecting the upstream PE for a VPN multicast flow, and extending BGP 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 MVPN routing so that a C-multicast route can be advertised toward a
standby upstream PE. standby upstream PE.
skipping to change at page 1, line 46 skipping to change at page 1, line 46
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 3, 2020. This Internet-Draft will expire on February 25, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 25 skipping to change at page 2, line 25
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. UMH Selection based on tunnel status . . . . . . . . . . . . 3 3. UMH Selection based on tunnel status . . . . . . . . . . . . 3
3.1. Determining the status of a tunnel . . . . . . . . . . . 5 3.1. Determining the status of a tunnel . . . . . . . . . . . 4
3.1.1. mVPN tunnel root tracking . . . . . . . . . . . . . . 5 3.1.1. mVPN tunnel root tracking . . . . . . . . . . . . . . 5
3.1.2. PE-P Upstream link status . . . . . . . . . . . . . . 5 3.1.2. PE-P Upstream link status . . . . . . . . . . . . . . 5
3.1.3. P2MP RSVP-TE tunnels . . . . . . . . . . . . . . . . 6 3.1.3. P2MP RSVP-TE tunnels . . . . . . . . . . . . . . . . 5
3.1.4. Leaf-initiated P-tunnels . . . . . . . . . . . . . . 6 3.1.4. Leaf-initiated P-tunnels . . . . . . . . . . . . . . 6
3.1.5. (C-S, C-G) counter information . . . . . . . . . . . 6 3.1.5. (C-S, C-G) counter information . . . . . . . . . . . 6
3.1.6. BFD Discriminator . . . . . . . . . . . . . . . . . . 7 3.1.6. BFD Discriminator . . . . . . . . . . . . . . . . . . 6
3.1.7. Per PE-CE link BFD Discriminator . . . . . . . . . . 9 3.1.7. Per PE-CE link BFD Discriminator . . . . . . . . . . 9
4. Standby C-multicast route . . . . . . . . . . . . . . . . . . 10 4. Standby C-multicast route . . . . . . . . . . . . . . . . . . 9
4.1. Downstream PE behavior . . . . . . . . . . . . . . . . . 11 4.1. Downstream PE behavior . . . . . . . . . . . . . . . . . 10
4.2. Upstream PE behavior . . . . . . . . . . . . . . . . . . 12 4.2. Upstream PE behavior . . . . . . . . . . . . . . . . . . 11
4.3. Reachability determination . . . . . . . . . . . . . . . 13 4.3. Reachability determination . . . . . . . . . . . . . . . 12
4.4. Inter-AS . . . . . . . . . . . . . . . . . . . . . . . . 13 4.4. Inter-AS . . . . . . . . . . . . . . . . . . . . . . . . 12
4.4.1. Inter-AS procedures for downstream PEs, ASBR fast 4.4.1. Inter-AS procedures for downstream PEs, ASBR fast
failover . . . . . . . . . . . . . . . . . . . . . . 14 failover . . . . . . . . . . . . . . . . . . . . . . 13
4.4.2. Inter-AS procedures for ASBRs . . . . . . . . . . . . 14 4.4.2. Inter-AS procedures for ASBRs . . . . . . . . . . . . 13
5. Hot Root Standby . . . . . . . . . . . . . . . . . . . . . . 15 5. Hot Root Standby . . . . . . . . . . . . . . . . . . . . . . 14
6. Duplicate packets . . . . . . . . . . . . . . . . . . . . . . 15 6. Duplicate packets . . . . . . . . . . . . . . . . . . . . . . 14
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
8. Security Considerations . . . . . . . . . . . . . . . . . . . 16 8. Security Considerations . . . . . . . . . . . . . . . . . . . 15
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15
10. Contributor Addresses . . . . . . . . . . . . . . . . . . . . 16 10. Contributor Addresses . . . . . . . . . . . . . . . . . . . . 15
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 17
11.1. Normative References . . . . . . . . . . . . . . . . . . 18 11.1. Normative References . . . . . . . . . . . . . . . . . . 17
11.2. Informative References . . . . . . . . . . . . . . . . . 19 11.2. Informative References . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18
1. Introduction 1. Introduction
In the context of multicast in BGP/MPLS VPNs, it is desirable to In the context of multicast in BGP/MPLS VPNs, it is desirable to
provide mechanisms allowing fast recovery of connectivity on provide mechanisms allowing fast recovery of connectivity on
different types of failures. This document addresses failures of different types of failures. This document addresses failures of
elements in the provider network that are upstream of PEs connected elements in the provider network that are upstream of PEs connected
to VPN sites with receivers. to VPN sites with receivers.
Section 3 describes local procedures allowing an egress PE (a PE Section 3 describes local procedures allowing an egress PE (a PE
skipping to change at page 3, line 45 skipping to change at page 3, line 45
x-PMSI: I-PMSI or S-PMSI x-PMSI: I-PMSI or S-PMSI
3. UMH Selection based on tunnel status 3. UMH Selection based on tunnel status
Current multicast VPN specifications [RFC6513], section 5.1, describe Current multicast VPN specifications [RFC6513], section 5.1, describe
the procedures used by a multicast VPN downstream PE to determine the procedures used by a multicast VPN downstream PE to determine
what the upstream multicast hop (UMH) is for a given (C-S, C-G). what the upstream multicast hop (UMH) is for a given (C-S, C-G).
The procedure described here is an OPTIONAL procedure that consists The procedure described here is an OPTIONAL procedure that consists
of having a downstream PE take into account the status of P-tunnels of having a downstream PE take into account the status of P-tunnels
rooted at each possible upstream PEs, for including or not including rooted at each possible upstream PEs, Because all PEs could arrive at
each given PE in the list of candidate UMHs for a given (C-S, C-G) a different conclusion regarding the state of the tunnel, procedures
state. The result is that, if a P-tunnel is "down" (see described in Section 9.1.1 of [RFC6513] MUST be used when using
Section 3.1), the PE that is the root of the P-tunnel will not be inclusive tunnels.
considered for UMH selection, which will result in the downstream PE
to failover to the upstream PE which is next in the list of
candidates. Because all PEs could arrive at a different conclusion
regarding the state of the tunnel, procedures described in
Section 9.1.1 of [RFC6513] MUST be used when using inclusive tunnels.
A downstream PE monitors the status of the tunnels of UMHs that are For a given downstream PE and a given VRF, the P-tunnel corresponding
ahead of the current one. Whenever the downstream PE determines that to a given upstream PE for a given (C-S, C-G) state is the S-PMSI
one of these tunnels is no longer "known to down", the PE selects the tunnel advertised by that upstream PE for this (C-S, C-G) and
UMH corresponding to that as the new UMH. imported into that VRF, or if there isn't any such S-PMSI, the I-PMSI
tunnel advertised by that PE and imported into that VRF.
More precisely, UMH determination for a given (C-S, C-G) will There are three options specified in Section 5.1 of [RFC6513] for a
consider the UMH candidates in the following order: downstream PE to select an Upstream PE.
o First, the UMH candidates that either o The first two options select the Upstream PE from a candidate PE
set either based on IP address or a hashing algorithm. When used
together with the optional procedure of considering the P-tunnel
status as in this document, a candidate upstream PE is included in
the set if it either:
A. advertise a PMSI bound to a tunnel, where the specified tunnel A. advertise a PMSI bound to a tunnel, where the specified tunnel
is not known to be down or is not known to be down or up
B. do not advertise any x-PMSI applicable to the given (C-S, C-G) B. do not advertise any x-PMSI applicable to the given (C-S, C-G)
but have associated a VRF Route Import BGP attribute to the but have associated a VRF Route Import BGP attribute to the
unicast VPN route for S (this is necessary to avoid unicast VPN route for S (this is necessary to avoid
incorrectly invalidating a UMH PE that would use a policy incorrectly invalidating a UMH PE that would use a policy
where no I-PMSI is advertised for a given VRF and where only where no I-PMSI is advertised for a given VRF and where only
S-PMSI are used, the S-PMSI advertisement being possibly done S-PMSI are used, the S-PMSI advertisement being possibly done
only after the upstream PE receives a C-multicast route for only after the upstream PE receives a C-multicast route for
(C-S, C-G)/(C-*, C-G) to be carried over the advertised (C-S, C-G)/(C-*, C-G) to be carried over the advertised
S-PMSI). S-PMSI).
o Second, the PE advertising the next best route is to be If the resulting candidate set is empty, then the procedure is
considered. repeated without considering the P-tunnel status.
o Third, the UMH candidates that advertise a PMSI bound to a tunnel
that is "down" -- these will thus be used as a last resort to
ensure a graceful fallback to the basic MVPN UMH selection
procedures in the hypothetical case where a false negative would
occur when determining the status of all tunnels.
For a given downstream PE and a given VRF, the P-tunnel corresponding
to a given upstream PE for a given (C-S, C-G) state is the S-PMSI
tunnel advertised by that upstream PE for this (C-S, C-G) and
imported into that VRF, or if there isn't any such S-PMSI, the I-PMSI
tunnel advertised by that PE and imported into that VRF.
Note that this document assumes that if a site of a given MVPN that o The third option uses the installed UMH Route (i.e., the "best"
contains C-S is dual-homed to two PEs, then all the other sites of route towards the C-root) as the Selected UMH Route, and its
that MVPN would have two unicast VPN routes (VPN-IPv4 or VPN-IPv6) originating PE is the selected Upstream PE. With the optional
routes to C-S, each with its RD. procedure of considering P-tunnel status as in this document, the
Selected UMH Route is the best one among those whose originating
PE's P-tunnel is not "down". If that does not exist, the
installed UMH Route is selected regardless of the P-tunnel status.
3.1. Determining the status of a tunnel 3.1. Determining the status of a tunnel
Different factors can be considered to determine the "status" of a Different factors can be considered to determine the "status" of a
P-tunnel and are described in the following sub-sections. The P-tunnel and are described in the following sub-sections. The
optional procedures proposed in this section also allow that all optional procedures proposed in this section also allow that all
downstream PEs don't apply the same rules to define what the status downstream PEs don't apply the same rules to define what the status
of a P-tunnel is (please see Section 6), and some of them will of a P-tunnel is (please see Section 6), and some of them will
produce a result that may be different for different downstream PEs. produce a result that may be different for different downstream PEs.
Thus what is called the "status" of a P-tunnel in this section, is Thus what is called the "status" of a P-tunnel in this section, is
skipping to change at page 9, line 29 skipping to change at page 9, line 18
o MUST stop processing BFD control packets for this p2mp BFD o MUST stop processing BFD control packets for this p2mp BFD
session; session;
o SHOULD delete the p2mp BFD session associated with the P-tunnel; o SHOULD delete the p2mp BFD session associated with the P-tunnel;
o SHOULD NOT switch the traffic to the Standby Upstream PE. o SHOULD NOT switch the traffic to the Standby Upstream PE.
3.1.7. Per PE-CE link BFD Discriminator 3.1.7. Per PE-CE link BFD Discriminator
The following approach is defined for the fast failover in response The following approach is defined in response to the detection by the
to the detection of PE-CE link failures, in which UMH selection for a upstream PE of PE-CE link failure. Even though the provider tunnel
given C-multicast route takes into account the state of the BFD is still up, it is desired for the downstream PEs to switch to a
session associated with the state of the upstream PE-CE link. backup upstream PE. To achieve that, if the upstream PE detects that
According to section 6.8.17 [RFC5880], failure of a PE-CE link MAY be its PE-CE link fails, it SHOULD set the bfd.LocalDiag of the p2mp BFD
communicated to the downstream PE by setting the bfd.LocalDiag of the session to Concatenated Path Down and/or Reverse Concatenated Path
p2mp BFD session associated with this link to Concatenated Path Down Down (per section 6.8.17 [RFC5880]), unless it switches to a new PE-
and/or Reverse Concatenated Path Down. The mechanism to communicate CE link within the time of bfd.DesiredMinTxInterval for the p2mp BFD
the mapping between the PE-CE link and the associated BFD session is session (in that case the upstream PE will start tracking the status
outside the scope of this document. of the new PE-CE link). When a downstream PE receives that
bfd.LocalDiag code, it treats as if the tunnel itself failed and
3.1.7.1. Upstream PE Procedures tries to switch to a backup PE.
For each protected PE-CE link, the upstream PE initiates a multipoint
BFD session [RFC8562] as MultipointHead toward downstream PEs. A
downstream PE monitors the state of the p2mp session as
MultipointTail and MAY interpret the transition of the BFD session
into Down state as the indication of the associated PE-CE link being
down.
For SSM groups, the upstream PE advertises a (C-S, C-G) S-PMSI A-D
route or wildcard (S,*) S-PMSI A-D route for each received SSM (C-S,
C-G) C-multicast route for which protection is desired. For each ASM
(C-S, C-G) C-multicast route for which protection is desired, the
upstream PE advertises a (C-S, C-G) S-PMSI A-D route. For each ASM
(*, G) C-Multicast route for which protection is desired, the
upstream PE advertises a wildcard (*, G) S-PMSI A-D route. Note that
all S-PMSI A-D routes can signal the same P-tunnel, so there is no
need for a new P-tunnel for each S-PMSI A-D route. Multicast flows
for which protection is desired are controlled by configuration/
policy on the upstream PE. The protected link is the RPF PE-CE
interface towards the src/RP. The upstream PE advertises the BFD
Discriminator of the protected link in the S-PMSI A-D route. If the
route to the src/RP changes such that the RPF interface is changed to
be a new PE-CE interface, then the upstream PE will update the S-PMSI
A-D route with included BGP-BFD Attribute so that the previously
advertised value of the BFD Discriminator is associated with the new
RPF link.
3.1.7.2. Downstream PE Procedures
If an S-PMSI A-D route bound to a given C-multicast is signaled with
a multipoint BFD session, then the upstream PE is considered during
UMH selection for the C-multicast if and only if the corresponding
BFD session is not in state Down, i.e., bfd.SessionState != Down.
Whenever the state of the BFD session changes to Down the Provider
Tunnel will be considered down, and the downstream PE MAY switch to
the backup Provider Tunnel only if the backup Provider Tunnel deemed
available. The dedicated p2mp BFD session MAY monitor the state of
the backup Provider Tunnel. Note that the Provider Tunnel is
considered down only for the C-multicast states that match to an
S-PMSI A-D route which included BGP-BFD Attribute with the BFD
Discriminator of the p2mp BFD session which is down.
4. Standby C-multicast route 4. Standby C-multicast route
The procedures described below are limited to the case where the site The procedures described below are limited to the case where the site
that contains C-S is connected to two or more PEs though, to simplify that contains C-S is connected to two or more PEs though, to simplify
the description, the case of dual-homing is described. The the description, the case of dual-homing is described. The
procedures require all the PEs of that MVPN to follow the UMH procedures require all the PEs of that MVPN to follow the UMH
selection, as specified in [RFC6513], whether the PE selected based selection, as specified in [RFC6513], whether the PE selected based
on its IP address, hashing algorithm described in section 5.1.3 on its IP address, hashing algorithm described in section 5.1.3
[RFC6513], or Installed UMH Route. The procedures assume that if a [RFC6513], or Installed UMH Route. The procedures assume that if a
 End of changes. 17 change blocks. 
112 lines changed or deleted 62 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/