BIER Flow Overlay with Anycast Egress Protection
draft-zzhang-bier-egress-protection-overlay-01
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Authors | Zhaohui (Jeffrey) Zhang , IJsbrand Wijnands , Zheng Zhang , Mankamana Prasad Mishra , Huaimo Chen | ||
| Last updated | 2024-02-06 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-zzhang-bier-egress-protection-overlay-01
BIER Working Group Z. Zhang
Internet-Draft Juniper Networks
Intended status: Standards Track I. Wijnands
Expires: 9 August 2024 Arrcus
Z. Zhang
ZTE
M. Mishra
Cisco Systems
H. Chen
Futurewei
6 February 2024
BIER Flow Overlay with Anycast Egress Protection
draft-zzhang-bier-egress-protection-overlay-01
Abstract
This document discusses considerations and specifies procedures for
multicast flow overlay when BIER Anycast is used for egress
protection in the context of MVPN and EVPN. Future revisions will
cover other flow overlay protocols like PIM/MLD/mLDP.
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 https://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 9 August 2024.
Copyright Notice
Copyright (c) 2024 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 (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Zhang, et al. Expires 9 August 2024 [Page 1]
Internet-Draft BIER-egress-protection February 2024
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 Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. PE/CE Procedures for MVPN Multi-homing . . . . . . . . . 2
1.2. EVPN Multi-homing . . . . . . . . . . . . . . . . . . . . 3
1.3. MVPN/EVPN Tunnel Segmentation . . . . . . . . . . . . . . 4
1.4. Relationship with Warm Root Standby . . . . . . . . . . . 5
2. Specification . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Security Considerations . . . . . . . . . . . . . . . . . . . 6
4. References . . . . . . . . . . . . . . . . . . . . . . . . . 6
4.1. Normative References . . . . . . . . . . . . . . . . . . 6
4.2. Informative References . . . . . . . . . . . . . . . . . 7
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7
1. Introduction
For services like L3VPN, service nodes (e.g., VPN CEs) may be multi-
homed to several Provider Edge nodes (PEs) so that if one PE fails
traffic can be quickly delivered by another PE. This applies even to
in-flight traffic before the ingress PE detects failure and switch
over to use another egress PE.
Anycast addresses may be used for the multi-homing PEs so that
traffic can be naturally routed/re-routed to any of the available PEs
[RFC8679]. When BIER is used in the provider network for multicast,
[I-D.zzhang-bier-anycast] specifies BIER with anycast as the building
block of egress protection for multicast.
This document discusses considerations and specifies procedures for
multicast flow overlay when BIER anycast is used for egress
protection, in the context of MVPN [RFC6513] [RFC6514] and EVPN
[RFC7432]. Future revisions may cover other flow overlay protocols
like PIM/MLD/mLDP.
1.1. PE/CE Procedures for MVPN Multi-homing
In the following diagram for MVPN [RFC6513] [RFC6514] service:
Zhang, et al. Expires 9 August 2024 [Page 2]
Internet-Draft BIER-egress-protection February 2024
+-----+
PE1 |BFER1|_________+---+
PE0 +-----+ /|CE1|
+----+ +-----+_______/ +---+
|BFIR| PE2 |BFER2|_________+---+
+----+ +-----+ /|CE2|
+-----+_______/ +---+
PE3 |BFER3|_________+---+
+-----+ |CE3|
+---+
CE1 and CE2 are multi-homed to PE1/PE2 (BFER1/BFER2)and PE2/PE3
(BFER2/BFER3) respectively. CE3 is single-homed to PE3 (BFER3).
Each multi-homing group (PE1/PE2, and PE2/PE3) shares an anycast
address that is advertised as BFR-prefix.
Depending on the underlay routing metric, a multicast packet towards
CE1 may arrive either on PE1 or PE2 but not both (a much higner
routing metric to one of them will lead to consistent primary/
secondary behavior) and if it arrives on PE2 it won't be delivered to
CE2. Similarly, a packet towards CE2 may arrive either on PE2 or PE3
but not both, but if it arrives on PE2 it won't be delivered to CE1,
and if it arrives on PE3 it won't be delivered to CE3.
For PE1/PE2 to deliver the received multicast traffic to CE1, they
both need to receive PIM [RFC7761] join or mLDP [RFC6388] label
mapping if the PE-CE protocol is mLDP from the CE. With the MoFRR
[RFC7431] feature for PIM and mLDP, a multi-homed CE can send PIM
join or mLDP label mapping to both PEs in the multi-homing group,
though additional steps are needed:
* The CE accepts traffic from any PEs in the multi-homing group
because only one of the PEs will deliver the traffic. Compared to
regular MoFRR scenario, all upstream nodes to which join or label
mapping is sent will receive and deliver traffic so the downstream
accepts traffic from only one of the upstream nodes.
* The PE's flow overlay signaling protocol for BIER needs to use
appropriate BFR-prefix when signal the flow interest to the BFIRs.
In the above example, PE2 needs to use the anycast BFR-prefix for
the PE1/PE2 for flows requested by CE1, use the anycast BFR-prefix
for the PE2/PE3 for flows requested by CE2, and use the PE3 BFR-
prefix for flows requested by CE3.
1.2. EVPN Multi-homing
The MVPN approach described above does not apply to EVPN, which does
not use anycast.
Zhang, et al. Expires 9 August 2024 [Page 3]
Internet-Draft BIER-egress-protection February 2024
A more detailed desription may be included in a future revision to
explain why different approaches are taken for MVPN and EVPN.
However, when tunnel segmentation is used, the anycast based approach
does apply to EVPN as well, as described in the following section.
1.3. MVPN/EVPN Tunnel Segmentation
A large BIER sub-domain may have many BFERs - more than the length of
BitString. While multiple copies could be sent, where each copy is
for a different set of the BFERs so that the same bit in different
copies corresponds to different BFERs, smaller BIER sub-domains can
be used along with MVPN tunnel segmentation [RFC7524]. In the latter
case, only one copy needs to be sent, and BIER decapsulation and re-
encapsulation happen at the border of sub-domains.
The tunnel segmentation procedures also apply to EVPN and are
specified in [I-D.ietf-bess-evpn-bum-procedure-updates].
Common to both MVPN and EVPN, ingress PEs advertise I/S-PMSI routes
(the EVPN IMET route is considered as an I-PMSI route as described in
[I-D.ietf-bess-evpn-bum-procedure-updates]), which carry a PMSI
Tunnel Attribute (PTA) that specifies the type and instance of the
tunnel that instantiate the PMSI. When a border router (ASBR, ABR,
or the generalized Reginal Border Router term introduced in
[I-D.ietf-bess-evpn-bum-procedure-updates]) re-advertises the route
to the next region, the type and instance in the PTA are also changed
to identify the tunnel used in the next region.
The border router is referred to as Semgentation Point. It receives/
re-advertises MVPN/EVPN I/S-PMSI, receives and advertises Leaf A-D
routes, and set up appropriate forwarding state. For example, in
case of BIER, it is a BFER for the upstream region (sub-domain) and
BFIR for the downtream region (sub-domain). It switches traffic
based on the service label that comes after the BIER header after
decapsulating incoming BIER header, and encapsulate a new BIER header
for the downtream region (sub-domain).
For redundancy purposes, multiple segemntation points can be used
between a pair upstream and downtream regions, and they can share an
anycast address. In this document, they are referred to as anycast
segmentation points.
While EVPN PEs don't use anycast multi-homing, the anycast procedures
on the segmentation points described here do apply to EVPN tunnel
segmentation as well.
Zhang, et al. Expires 9 August 2024 [Page 4]
Internet-Draft BIER-egress-protection February 2024
When an anycast segmentation point re-advertises a PMSI route to the
downstream region, it uses the anycast address in the Inter-Area P2MP
Segmented Next-Hop Extended Community in case of MVPN inter-area
segemntation, or in the BGP Next Hop in case of MVPN inter-AS
segmentation or EVPN inter-region segmetnation. As a result, when a
downstream egress PE or segmentation point sends Leaf A-D route in
response, all segmentation points with the same anycast address will
receive the Leaf A-D routes in the downtream region (just like all
multi-homing MVPN PEs will receive MoFRR joins from their multi-homed
CEs) and send their own Leaf A-D routes in the upstream region, also
using the anycast address. Only one will receive traffic, and any
one will send received traffic to the downstream region (sub-domain).
While this document is about BIER, the above procedure works when the
upstream and downstream region uses either BIER or Ingress
Replication (IR), including the case where one uses BIER and the
other uses IR.
If the downstream region uses another tunnel type, e.g. mLDP, then a
downstream PE or segmentation point can join all the tunnels
announced by the anycast segmentation points and accept traffic on
all of them, so that the anycast segmentation points can easiy
protect each other in the upstream BIER/IR region.
1.4. Relationship with Warm Root Standby
With Warm Root Standby procedures in [RFC9026], an egress PE chooses
a pair of primary/backup ingress PEs and sends C-multicast routes
with corresponding primary/backup indications. Only the primary
ingress PE will send traffic, and the egress PE only accepts traffic
from its chosen primary ingress PE. The protection is about the
ingress PE.
With MVPN with BIER Anycast, the protection is about the egress PE or
segmentation point. One of all the anycast egress PE or segmentation
points will receive the traffic and all will send to their multi-
homed downstream (either the CE, or a PE or segmentation point that
is the downstream of "this" segmentation point), who will accept
traffic from all the anycast upstream.
2. Specification
Detailed normative procedures will be added in future revisions.
Zhang, et al. Expires 9 August 2024 [Page 5]
Internet-Draft BIER-egress-protection February 2024
3. Security Considerations
This document does not introduce any new security concerns besides
what has been discussed in [RFC8279], [RFC6513], [RFC8556],
[I-D.ietf-bier-tether] and [I-D.zzhang-bier-anycast].
4. References
4.1. Normative References
[I-D.ietf-bess-evpn-bum-procedure-updates]
Zhang, Z. J., Lin, W., Rabadan, J., Patel, K., and A.
Sajassi, "Updates on EVPN BUM Procedures", Work in
Progress, Internet-Draft, draft-ietf-bess-evpn-bum-
procedure-updates-14, 18 November 2021,
<https://datatracker.ietf.org/doc/html/draft-ietf-bess-
evpn-bum-procedure-updates-14>.
[I-D.ietf-bier-tether]
Zhang, Z. J., Warnke, N., Wijnands, I., and D. O. Awduche,
"Tethering A BIER Router To A BIER incapable Router", Work
in Progress, Internet-Draft, draft-ietf-bier-tether-04, 5
July 2023, <https://datatracker.ietf.org/doc/html/draft-
ietf-bier-tether-04>.
[I-D.zzhang-bier-anycast]
Zhang, Z. J., Wijnands, I., Zhang, Z., Mishra, M. P., and
H. Chen, "BIER with Anycast", Work in Progress, Internet-
Draft, draft-zzhang-bier-anycast-02, 11 March 2023,
<https://datatracker.ietf.org/doc/html/draft-zzhang-bier-
anycast-02>.
[RFC6513] Rosen, E., Ed. and R. Aggarwal, Ed., "Multicast in MPLS/
BGP IP VPNs", RFC 6513, DOI 10.17487/RFC6513, February
2012, <https://www.rfc-editor.org/info/rfc6513>.
[RFC6514] Aggarwal, R., Rosen, E., Morin, T., and Y. Rekhter, "BGP
Encodings and Procedures for Multicast in MPLS/BGP IP
VPNs", RFC 6514, DOI 10.17487/RFC6514, February 2012,
<https://www.rfc-editor.org/info/rfc6514>.
[RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A.,
Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based
Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February
2015, <https://www.rfc-editor.org/info/rfc7432>.
Zhang, et al. Expires 9 August 2024 [Page 6]
Internet-Draft BIER-egress-protection February 2024
[RFC7524] Rekhter, Y., Rosen, E., Aggarwal, R., Morin, T.,
Grosclaude, I., Leymann, N., and S. Saad, "Inter-Area
Point-to-Multipoint (P2MP) Segmented Label Switched Paths
(LSPs)", RFC 7524, DOI 10.17487/RFC7524, May 2015,
<https://www.rfc-editor.org/info/rfc7524>.
[RFC8279] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A.,
Przygienda, T., and S. Aldrin, "Multicast Using Bit Index
Explicit Replication (BIER)", RFC 8279,
DOI 10.17487/RFC8279, November 2017,
<https://www.rfc-editor.org/info/rfc8279>.
[RFC8556] Rosen, E., Ed., Sivakumar, M., Przygienda, T., Aldrin, S.,
and A. Dolganow, "Multicast VPN Using Bit Index Explicit
Replication (BIER)", RFC 8556, DOI 10.17487/RFC8556, April
2019, <https://www.rfc-editor.org/info/rfc8556>.
4.2. Informative References
[RFC6388] Wijnands, IJ., Ed., Minei, I., Ed., Kompella, K., and B.
Thomas, "Label Distribution Protocol Extensions for Point-
to-Multipoint and Multipoint-to-Multipoint Label Switched
Paths", RFC 6388, DOI 10.17487/RFC6388, November 2011,
<https://www.rfc-editor.org/info/rfc6388>.
[RFC7431] Karan, A., Filsfils, C., Wijnands, IJ., Ed., and B.
Decraene, "Multicast-Only Fast Reroute", RFC 7431,
DOI 10.17487/RFC7431, August 2015,
<https://www.rfc-editor.org/info/rfc7431>.
[RFC7761] Fenner, B., Handley, M., Holbrook, H., Kouvelas, I.,
Parekh, R., Zhang, Z., and L. Zheng, "Protocol Independent
Multicast - Sparse Mode (PIM-SM): Protocol Specification
(Revised)", STD 83, RFC 7761, DOI 10.17487/RFC7761, March
2016, <https://www.rfc-editor.org/info/rfc7761>.
[RFC8679] Shen, Y., Jeganathan, M., Decraene, B., Gredler, H.,
Michel, C., and H. Chen, "MPLS Egress Protection
Framework", RFC 8679, DOI 10.17487/RFC8679, December 2019,
<https://www.rfc-editor.org/info/rfc8679>.
[RFC9026] Morin, T., Ed., Kebler, R., Ed., and G. Mirsky, Ed.,
"Multicast VPN Fast Upstream Failover", RFC 9026,
DOI 10.17487/RFC9026, April 2021,
<https://www.rfc-editor.org/info/rfc9026>.
Authors' Addresses
Zhang, et al. Expires 9 August 2024 [Page 7]
Internet-Draft BIER-egress-protection February 2024
Zhaohui (Jeffrey) Zhang
Juniper Networks
Email: zzhang@juniper.net
IJsbrand Wijnands
Arrcus
Email: ice@braindump.be
Zheng Zhang
ZTE
Email: zhang.zhen@zte.com.cn
Mankamana Mishra
Cisco Systems
Email: mankamis@cisco.com
Huaimo Chen
Futurewei
Email: Huaimo.chen@futurewei.com
Zhang, et al. Expires 9 August 2024 [Page 8]