< draft-ietf-bess-mvpn-fast-failover-12.txt   draft-ietf-bess-mvpn-fast-failover-13.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: May 1, 2021 Juniper Networks Expires: May 16, 2021 Juniper Networks
G. Mirsky, Ed. G. Mirsky, Ed.
ZTE Corp. ZTE Corp.
October 28, 2020 November 12, 2020
Multicast VPN Fast Upstream Failover Multicast VPN Fast Upstream Failover
draft-ietf-bess-mvpn-fast-failover-12 draft-ietf-bess-mvpn-fast-failover-13
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 consider the status of Provider-Tunnels (P-tunnels) when selecting to consider the status of Provider-Tunnels (P-tunnels) when selecting
the upstream PE for a VPN multicast flow. The fast failover is the upstream PE for a VPN multicast flow. The fast failover is
enabled by using RFC 8562 BFD for Multipoint Networks and the new BGP enabled by using RFC 8562 BFD for Multipoint Networks and the new BGP
Attribute - BFD Discriminator. Also, the document introduces a new Attribute - BFD Discriminator. Also, the document introduces a new
BGP Community, Standby PE, extending BGP MVPN routing so that a BGP Community, Standby PE, extending BGP Multicast VPN routing so
C-multicast route can be advertised toward a Standby Upstream PE. that a C-multicast route can be advertised toward a Standby Upstream
PE.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 May 1, 2021. This Internet-Draft will expire on May 16, 2021.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2020 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 20 skipping to change at page 2, line 21
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions used in this document . . . . . . . . . . . . . . 3 2. Conventions used in this document . . . . . . . . . . . . . . 3
2.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 2.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
2.3. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . 4 2.3. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . 4
3. UMH Selection Based on Tunnel Status . . . . . . . . . . . . 5 3. UMH Selection Based on Tunnel Status . . . . . . . . . . . . 5
3.1. Determining the Status of a Tunnel . . . . . . . . . . . 6 3.1. Determining the Status of a Tunnel . . . . . . . . . . . 6
3.1.1. mVPN Tunnel Root Tracking . . . . . . . . . . . . . . 6 3.1.1. MVPN Tunnel Root Tracking . . . . . . . . . . . . . . 7
3.1.2. PE-P Upstream Link Status . . . . . . . . . . . . . . 7 3.1.2. PE-P Upstream Link Status . . . . . . . . . . . . . . 7
3.1.3. P2MP RSVP-TE Tunnels . . . . . . . . . . . . . . . . 7 3.1.3. P2MP RSVP-TE Tunnels . . . . . . . . . . . . . . . . 7
3.1.4. Leaf-initiated P-tunnels . . . . . . . . . . . . . . 8 3.1.4. Leaf-initiated P-tunnels . . . . . . . . . . . . . . 8
3.1.5. (C-S, C-G) Counter Information . . . . . . . . . . . 8 3.1.5. (C-S, C-G) Counter Information . . . . . . . . . . . 8
3.1.6. BFD Discriminator Attribute . . . . . . . . . . . . . 8 3.1.6. BFD Discriminator Attribute . . . . . . . . . . . . . 8
3.1.7. Per PE-CE Link BFD Discriminator . . . . . . . . . . 12 3.1.7. Per PE-CE Link BFD Discriminator . . . . . . . . . . 12
4. Standby C-multicast Route . . . . . . . . . . . . . . . . . . 12 4. Standby C-multicast Route . . . . . . . . . . . . . . . . . . 12
4.1. Downstream PE Behavior . . . . . . . . . . . . . . . . . 13 4.1. Downstream PE Behavior . . . . . . . . . . . . . . . . . 13
4.2. Upstream PE Behavior . . . . . . . . . . . . . . . . . . 14 4.2. Upstream PE Behavior . . . . . . . . . . . . . . . . . . 14
4.3. Reachability Determination . . . . . . . . . . . . . . . 15 4.3. Reachability Determination . . . . . . . . . . . . . . . 15
4.4. Inter-AS . . . . . . . . . . . . . . . . . . . . . . . . 15 4.4. Inter-AS . . . . . . . . . . . . . . . . . . . . . . . . 15
4.4.1. Inter-AS Procedures for downstream PEs, ASBR Fast 4.4.1. Inter-AS Procedures for downstream PEs, ASBR Fast
Failover . . . . . . . . . . . . . . . . . . . . . . 16 Failover . . . . . . . . . . . . . . . . . . . . . . 16
4.4.2. Inter-AS Procedures for ASBRs . . . . . . . . . . . . 16 4.4.2. Inter-AS Procedures for ASBRs . . . . . . . . . . . . 16
5. Hot Root Standby . . . . . . . . . . . . . . . . . . . . . . 16 5. Hot Root Standby . . . . . . . . . . . . . . . . . . . . . . 17
6. Duplicate Packets . . . . . . . . . . . . . . . . . . . . . . 17 6. Duplicate Packets . . . . . . . . . . . . . . . . . . . . . . 17
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
7.1. Standby PE Community . . . . . . . . . . . . . . . . . . 18 7.1. Standby PE Community . . . . . . . . . . . . . . . . . . 18
7.2. BFD Discriminator . . . . . . . . . . . . . . . . . . . . 18 7.2. BFD Discriminator . . . . . . . . . . . . . . . . . . . . 18
7.3. BFD Discriminator Optional Sub-TLV Type . . . . . . . . . 19 7.3. BFD Discriminator Optional Sub-TLV Type . . . . . . . . . 19
8. Security Considerations . . . . . . . . . . . . . . . . . . . 19 8. Security Considerations . . . . . . . . . . . . . . . . . . . 20
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20
10. Contributor Addresses . . . . . . . . . . . . . . . . . . . . 20 10. Contributor Addresses . . . . . . . . . . . . . . . . . . . . 20
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 22 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 22
11.1. Normative References . . . . . . . . . . . . . . . . . . 22 11.1. Normative References . . . . . . . . . . . . . . . . . . 22
11.2. Informative References . . . . . . . . . . . . . . . . . 23 11.2. Informative References . . . . . . . . . . . . . . . . . 23
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23
1. Introduction 1. Introduction
It is assumed that the reader is familiar with the workings of It is assumed that the reader is familiar with the workings of
skipping to change at page 3, line 27 skipping to change at page 3, line 27
connected to a receiver site) to take into account the status of connected to a receiver site) to take into account the status of
P-tunnels to determine the Upstream Multicast Hop (UMH) for a given P-tunnels to determine the Upstream Multicast Hop (UMH) for a given
(C-S, C-G). One of the optional methods uses [RFC8562] and the new (C-S, C-G). One of the optional methods uses [RFC8562] and the new
BGP Attribute - BFD Discriminator. None of these methods provide a BGP Attribute - BFD Discriminator. None of these methods provide a
"fast failover" solution when used alone, but can be used together "fast failover" solution when used alone, but can be used together
with the mechanism described in Section 4 for a "fast failover" with the mechanism described in Section 4 for a "fast failover"
solution. solution.
Section 4 describes an optional BGP extension, a new Standby PE Section 4 describes an optional BGP extension, a new Standby PE
Community. that can speed up failover by not requiring any multicast Community. that can speed up failover by not requiring any multicast
VPN routing message exchange at recovery time. VPN (MVPN) routing message exchange at recovery time.
Section 5 describes a "hot leaf standby" mechanism that can be used Section 5 describes a "hot leaf standby" mechanism that can be used
to improve failover time in MVPN. The approach combines mechanisms to improve failover time in MVPN. The approach combines mechanisms
defined in Section 3 and Section 4 has similarities with the solution defined in Section 3 and Section 4 has similarities with the solution
described in [RFC7431] to improve failover times when PIM routing is described in [RFC7431] to improve failover times when PIM routing is
used in a network given some topology and metric constraints. used in a network given some topology and metric constraints.
The procedures described in this document are optional to enable an The procedures described in this document are optional to enable an
operator to provide protection for multicast services in BGP/MPLS IP operator to provide protection for multicast services in BGP/MPLS IP
VPNs. An operator would enable these mechanisms using a method VPNs. An operator would enable these mechanisms using a method
skipping to change at page 6, line 42 skipping to change at page 6, line 42
P-tunnel itself. That could be referred to as "P-tunnel reception P-tunnel itself. That could be referred to as "P-tunnel reception
status", but for simplicity, we will use the terminology of P-tunnel status", but for simplicity, we will use the terminology of P-tunnel
"status" for all of these methods. "status" for all of these methods.
Depending on the criteria used to determine the status of a P-tunnel, Depending on the criteria used to determine the status of a P-tunnel,
there may be an interaction with another resiliency mechanism used there may be an interaction with another resiliency mechanism used
for the P-tunnel itself, and the UMH update may happen immediately or for the P-tunnel itself, and the UMH update may happen immediately or
may need to be delayed. Each particular case is covered in each may need to be delayed. Each particular case is covered in each
separate sub-section below. separate sub-section below.
All methods described in this section may produce false-negative
state changes that can be the trigger for an unnecessary failover
negatively impacting the multicast service provided by the VPN. An
operator expected to consider the network environment and use
available controls of the mechanism used to determine the status of a
P-tunnel.
An implementation may support any combination of the methods An implementation may support any combination of the methods
described in this section and provide a network operator with control described in this section and provide a network operator with control
to choose which one to use in the particular deployment. to choose which one to use in the particular deployment.
3.1.1. mVPN Tunnel Root Tracking 3.1.1. MVPN Tunnel Root Tracking
A condition to consider that the status of a P-tunnel is Up is that A condition to consider that the status of a P-tunnel is Up is that
the root of the tunnel, as determined in the x-PMSI Tunnel attribute, the root of the tunnel, as determined in the x-PMSI Tunnel attribute,
is reachable through unicast routing tables. In this case, the is reachable through unicast routing tables. In this case, the
downstream PE can immediately update its UMH when the reachability downstream PE can immediately update its UMH when the reachability
condition changes. condition changes.
That is similar to BGP next-hop tracking for VPN routes, except that That is similar to BGP next-hop tracking for VPN routes, except that
the address considered is not the BGP next-hop address, but the root the address considered is not the BGP next-hop address, but the root
address in the x-PMSI Tunnel attribute. address in the x-PMSI Tunnel attribute.
skipping to change at page 12, line 30 skipping to change at page 12, line 30
Down (per Section 6.8.17 [RFC5880]), unless it switches to a new PE- Down (per Section 6.8.17 [RFC5880]), unless it switches to a new PE-
CE link within the time of bfd.DesiredMinTxInterval for the P2MP BFD CE link within the time of bfd.DesiredMinTxInterval for the P2MP BFD
session (in that case, the Upstream PE will start tracking the status session (in that case, the Upstream PE will start tracking the status
of the new PE-CE link). When a downstream PE receives that of the new PE-CE link). When a downstream PE receives that
bfd.LocalDiag code, it treats it as if the tunnel itself failed and bfd.LocalDiag code, it treats it as if the tunnel itself failed and
tries to switch to a backup PE. tries to switch to a backup PE.
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
the description, the case of dual-homing is described. The simplify the description, the case of dual-homing is described. Such
procedures require all the PEs of that MVPN to follow the same UMH a redundancy protection scheme, referred to as 1:N protection, is the
selection procedure, as specified in [RFC6513], whether the PE special case of M:N protection, where M working instances are sharing
selected based on its IP address, hashing algorithm described in protection of the N standby instances. In addition to a network
section 5.1.3 of [RFC6513], or Installed UMH Route. The procedures failure detection mechanism, the latter scheme requires using a
assume that if a site of a given MVPN that contains C-S is dual-homed mechanism to coordinate the failover among working instances. For
to two PEs, then all the other sites of that MVPN would have two that reason, M:N protection is outside the scope of this
unicast VPN routes (VPN-IPv4 or VPN-IPv6) to C-S, each with its RD. specification.
The procedures described in this section require all the PEs of that
MVPN to follow the same UMH selection procedure, as specified in
[RFC6513], whether the PE selected based on its IP address, hashing
algorithm described in section 5.1.3 of [RFC6513], or Installed UMH
Route. The procedures assume that if a site of a given MVPN that
contains C-S is dual-homed to two PEs, then all the other sites of
that MVPN would have two unicast VPN routes (VPN-IPv4 or VPN-IPv6) to
C-S, each with its RD.
As long as C-S is reachable via both PEs, a given downstream PE will As long as C-S is reachable via both PEs, a given downstream PE will
select one of the PEs connected to C-S as its Upstream PE for C-S. select one of the PEs connected to C-S as its Upstream PE for C-S.
We will refer to the other PE connected to C-S as the "Standby 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 Upstream PE". Note that if the connectivity to C-S through the
Primary Upstream PE becomes unavailable, then the PE will select the Primary Upstream PE becomes unavailable, then the PE will select the
Standby Upstream PE as its Upstream PE for C-S. When the Primary PE Standby Upstream PE as its Upstream PE for C-S. When the Primary PE
later becomes available, then the PE will select the Primary Upstream later becomes available, then the PE will select the Primary Upstream
PE again as its Upstream PE. Such behavior is referred to as PE again as its Upstream PE. Such behavior is referred to as
"revertive" behavior and MUST be supported. Non-revertive behavior "revertive" behavior and MUST be supported. Non-revertive behavior
 End of changes. 12 change blocks. 
20 lines changed or deleted 37 lines changed or added

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