draft-ietf-bess-evpn-irb-mcast-03.txt   draft-ietf-bess-evpn-irb-mcast-04.txt 
BESS W. Lin BESS W. Lin
Internet-Draft Z. Zhang Internet-Draft Z. Zhang
Intended status: Standards Track J. Drake Intended status: Standards Track J. Drake
Expires: February 17, 2020 E. Rosen, Ed. Expires: April 30, 2020 E. Rosen, Ed.
Juniper Networks, Inc. Juniper Networks, Inc.
J. Rabadan J. Rabadan
Nokia Nokia
A. Sajassi A. Sajassi
Cisco Systems Cisco Systems
August 16, 2019 October 28, 2019
EVPN Optimized Inter-Subnet Multicast (OISM) Forwarding EVPN Optimized Inter-Subnet Multicast (OISM) Forwarding
draft-ietf-bess-evpn-irb-mcast-03 draft-ietf-bess-evpn-irb-mcast-04
Abstract Abstract
Ethernet VPN (EVPN) provides a service that allows a single Local Ethernet VPN (EVPN) provides a service that allows a single Local
Area Network (LAN), comprising a single IP subnet, to be divided into Area Network (LAN), comprising a single IP subnet, to be divided into
multiple "segments". Each segment may be located at a different multiple "segments". Each segment may be located at a different
site, and the segments are interconnected by an IP or MPLS backbone. site, and the segments are interconnected by an IP or MPLS backbone.
Intra-subnet traffic (either unicast or multicast) always appears to Intra-subnet traffic (either unicast or multicast) always appears to
the endusers to be bridged, even when it is actually carried over the the endusers to be bridged, even when it is actually carried over the
IP or MPLS backbone. When a single "tenant" owns multiple such LANs, IP or MPLS backbone. When a single "tenant" owns multiple such LANs,
skipping to change at page 2, line 4 skipping to change at page 2, line 4
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 February 17, 2020. This Internet-Draft will expire on April 30, 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 49 skipping to change at page 2, line 49
2.4. Use of IRB Interfaces at an Egress PE . . . . . . . . . . 23 2.4. Use of IRB Interfaces at an Egress PE . . . . . . . . . . 23
2.5. Announcing Interest in (S,G) . . . . . . . . . . . . . . 23 2.5. Announcing Interest in (S,G) . . . . . . . . . . . . . . 23
2.6. Tunneling Frames from Ingress PE to Egress PEs . . . . . 24 2.6. Tunneling Frames from Ingress PE to Egress PEs . . . . . 24
2.7. Advanced Scenarios . . . . . . . . . . . . . . . . . . . 25 2.7. Advanced Scenarios . . . . . . . . . . . . . . . . . . . 25
3. EVPN-aware Multicast Solution Control Plane . . . . . . . . . 26 3. EVPN-aware Multicast Solution Control Plane . . . . . . . . . 26
3.1. Supplementary Broadcast Domain (SBD) and Route Targets . 26 3.1. Supplementary Broadcast Domain (SBD) and Route Targets . 26
3.2. Advertising the Tunnels Used for IP Multicast . . . . . . 27 3.2. Advertising the Tunnels Used for IP Multicast . . . . . . 27
3.2.1. Constructing Routes for the SBD . . . . . . . . . . . 28 3.2.1. Constructing Routes for the SBD . . . . . . . . . . . 28
3.2.2. Ingress Replication . . . . . . . . . . . . . . . . . 28 3.2.2. Ingress Replication . . . . . . . . . . . . . . . . . 28
3.2.3. Assisted Replication . . . . . . . . . . . . . . . . 29 3.2.3. Assisted Replication . . . . . . . . . . . . . . . . 29
3.2.3.1. Automatic SBD Matching . . . . . . . . . . . . . 30
3.2.4. BIER . . . . . . . . . . . . . . . . . . . . . . . . 30 3.2.4. BIER . . . . . . . . . . . . . . . . . . . . . . . . 30
3.2.5. Inclusive P2MP Tunnels . . . . . . . . . . . . . . . 31 3.2.5. Inclusive P2MP Tunnels . . . . . . . . . . . . . . . 31
3.2.5.1. Using the BUM Tunnels as IP Multicast Inclusive 3.2.5.1. Using the BUM Tunnels as IP Multicast Inclusive
Tunnels . . . . . . . . . . . . . . . . . . . . . 31 Tunnels . . . . . . . . . . . . . . . . . . . . . 31
3.2.5.2. Using Wildcard S-PMSI A-D Routes to Advertise 3.2.5.2. Using Wildcard S-PMSI A-D Routes to Advertise
Inclusive Tunnels Specific to IP Multicast . . . 32 Inclusive Tunnels Specific to IP Multicast . . . 33
3.2.6. Selective Tunnels . . . . . . . . . . . . . . . . . . 33 3.2.6. Selective Tunnels . . . . . . . . . . . . . . . . . . 33
3.3. Advertising SMET Routes . . . . . . . . . . . . . . . . . 34 3.3. Advertising SMET Routes . . . . . . . . . . . . . . . . . 34
4. Constructing Multicast Forwarding State . . . . . . . . . . . 36 4. Constructing Multicast Forwarding State . . . . . . . . . . . 37
4.1. Layer 2 Multicast State . . . . . . . . . . . . . . . . . 36 4.1. Layer 2 Multicast State . . . . . . . . . . . . . . . . . 37
4.1.1. Constructing the OIF List . . . . . . . . . . . . . . 37 4.1.1. Constructing the OIF List . . . . . . . . . . . . . . 38
4.1.2. Data Plane: Applying the OIF List to an (S,G) Frame . 38 4.1.2. Data Plane: Applying the OIF List to an (S,G) Frame . 38
4.1.2.1. Eligibility of an AC to Receive a Frame . . . . . 38 4.1.2.1. Eligibility of an AC to Receive a Frame . . . . . 39
4.1.2.2. Applying the OIF List . . . . . . . . . . . . . . 39 4.1.2.2. Applying the OIF List . . . . . . . . . . . . . . 39
4.2. Layer 3 Forwarding State . . . . . . . . . . . . . . . . 40 4.2. Layer 3 Forwarding State . . . . . . . . . . . . . . . . 40
5. Interworking with non-OISM EVPN-PEs . . . . . . . . . . . . . 41 5. Interworking with non-OISM EVPN-PEs . . . . . . . . . . . . . 41
5.1. IPMG Designated Forwarder . . . . . . . . . . . . . . . . 43 5.1. IPMG Designated Forwarder . . . . . . . . . . . . . . . . 44
5.2. Ingress Replication . . . . . . . . . . . . . . . . . . . 44 5.2. Ingress Replication . . . . . . . . . . . . . . . . . . . 44
5.2.1. Ingress PE is non-OISM . . . . . . . . . . . . . . . 45 5.2.1. Ingress PE is non-OISM . . . . . . . . . . . . . . . 46
5.2.2. Ingress PE is OISM . . . . . . . . . . . . . . . . . 47 5.2.2. Ingress PE is OISM . . . . . . . . . . . . . . . . . 47
5.3. P2MP Tunnels . . . . . . . . . . . . . . . . . . . . . . 48 5.3. P2MP Tunnels . . . . . . . . . . . . . . . . . . . . . . 48
6. Traffic to/from Outside the EVPN Tenant Domain . . . . . . . 48 6. Traffic to/from Outside the EVPN Tenant Domain . . . . . . . 48
6.1. Layer 3 Interworking via EVPN OISM PEs . . . . . . . . . 49 6.1. Layer 3 Interworking via EVPN OISM PEs . . . . . . . . . 49
6.1.1. General Principles . . . . . . . . . . . . . . . . . 49 6.1.1. General Principles . . . . . . . . . . . . . . . . . 49
6.1.2. Interworking with MVPN . . . . . . . . . . . . . . . 52 6.1.2. Interworking with MVPN . . . . . . . . . . . . . . . 52
6.1.2.1. MVPN Sources with EVPN Receivers . . . . . . . . 53 6.1.2.1. MVPN Sources with EVPN Receivers . . . . . . . . 54
6.1.2.1.1. Identifying MVPN Sources . . . . . . . . . . 53 6.1.2.1.1. Identifying MVPN Sources . . . . . . . . . . 54
6.1.2.1.2. Joining a Flow from an MVPN Source . . . . . 54 6.1.2.1.2. Joining a Flow from an MVPN Source . . . . . 54
6.1.2.2. EVPN Sources with MVPN Receivers . . . . . . . . 56 6.1.2.2. EVPN Sources with MVPN Receivers . . . . . . . . 56
6.1.2.2.1. General procedures . . . . . . . . . . . . . 56 6.1.2.2.1. General procedures . . . . . . . . . . . . . 56
6.1.2.2.2. Any-Source Multicast (ASM) Groups . . . . . . 58 6.1.2.2.2. Any-Source Multicast (ASM) Groups . . . . . . 58
6.1.2.2.3. Source on Multihomed Segment . . . . . . . . 58 6.1.2.2.3. Source on Multihomed Segment . . . . . . . . 58
6.1.2.3. Obtaining Optimal Routing of Traffic Between MVPN 6.1.2.3. Obtaining Optimal Routing of Traffic Between MVPN
and EVPN . . . . . . . . . . . . . . . . . . . . 59 and EVPN . . . . . . . . . . . . . . . . . . . . 59
6.1.2.4. Selecting the MEG SBD-DR . . . . . . . . . . . . 60 6.1.2.4. Selecting the MEG SBD-DR . . . . . . . . . . . . 60
6.1.3. Interworking with 'Global Table Multicast' . . . . . 60 6.1.3. Interworking with 'Global Table Multicast' . . . . . 60
6.1.4. Interworking with PIM . . . . . . . . . . . . . . . . 60 6.1.4. Interworking with PIM . . . . . . . . . . . . . . . . 61
6.1.4.1. Source Inside EVPN Domain . . . . . . . . . . . . 61 6.1.4.1. Source Inside EVPN Domain . . . . . . . . . . . . 61
6.1.4.2. Source Outside EVPN Domain . . . . . . . . . . . 62 6.1.4.2. Source Outside EVPN Domain . . . . . . . . . . . 63
6.2. Interworking with PIM via an External PIM Router . . . . 63 6.2. Interworking with PIM via an External PIM Router . . . . 63
7. Using an EVPN Tenant Domain as an Intermediate (Transit) 7. Using an EVPN Tenant Domain as an Intermediate (Transit)
Network for Multicast traffic . . . . . . . . . . . . . . . . 64 Network for Multicast traffic . . . . . . . . . . . . . . . . 64
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 67 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 67
9. Security Considerations . . . . . . . . . . . . . . . . . . . 67 9. Security Considerations . . . . . . . . . . . . . . . . . . . 67
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 67 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 67
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 67 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 67
11.1. Normative References . . . . . . . . . . . . . . . . . . 67 11.1. Normative References . . . . . . . . . . . . . . . . . . 68
11.2. Informative References . . . . . . . . . . . . . . . . . 69 11.2. Informative References . . . . . . . . . . . . . . . . . 69
Appendix A. Integrated Routing and Bridging . . . . . . . . . . 71 Appendix A. Integrated Routing and Bridging . . . . . . . . . . 71
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 76
1. Introduction 1. Introduction
1.1. Background 1.1. Background
Ethernet VPN (EVPN) [RFC7432] provides a Layer 2 VPN (L2VPN) Ethernet VPN (EVPN) [RFC7432] provides a Layer 2 VPN (L2VPN)
solution, which allows IP backbone provider to offer ethernet service solution, which allows IP backbone provider to offer ethernet service
skipping to change at page 19, line 36 skipping to change at page 19, line 36
o If the route is about the SBD, the route MUST carry the SBD-RT, o If the route is about the SBD, the route MUST carry the SBD-RT,
and MUST NOT carry any RT that is associated with any other BD. and MUST NOT carry any RT that is associated with any other BD.
o As detailed in subsequent sections, under certain circumstances a o As detailed in subsequent sections, under certain circumstances a
route that is about BD1 may carry both the RT of BD1 and also the route that is about BD1 may carry both the RT of BD1 and also the
SBD-RT. SBD-RT.
The IMET route for the SBD MUST carry an Multicast Flags Extended The IMET route for the SBD MUST carry an Multicast Flags Extended
Community, in which an "OISM SBD" flag is set. Community, in which an "OISM SBD" flag is set.
The IMET route for a BD other than the SBD SHOULD carry an EVI-RT EC
as defined in [IGMP-Proxy]. The EC is constructed from the SBD-RT,
to indicate the BD's corresponding SBD. This allows all PEs to check
that they have consistent SBD provisioning and allow an AR-replicator
to automatically determine a BD's corresponding SBD w/o any
provisioning, as explained in Section 3.2.3.1.
When receiving an IMET, SMET, S-PMSI or Leaf route, it is necessary When receiving an IMET, SMET, S-PMSI or Leaf route, it is necessary
for the receiving PE to determine the BD to which the route belongs. for the receiving PE to determine the BD to which the route belongs.
This is done by examining the RTs carried by the route, as well as This is done by examining the RTs carried by the route, as well as
the Tag ID field of the route's NLRI. There are several cases to the Tag ID field of the route's NLRI. There are several cases to
consider. Some of these cases are error cases that arise when the consider. Some of these cases are error cases that arise when the
route has not been properly constructed. route has not been properly constructed.
When one of the error cases is detected, the route MUST be regarded When one of the error cases is detected, the route MUST be regarded
as a malformed route, and the "treat-as-withdraw" procedure of as a malformed route, and the "treat-as-withdraw" procedure of
[RFC7606] MUST be applied. Note though that these error cases are [RFC7606] MUST be applied. Note though that these error cases are
skipping to change at page 29, line 23 skipping to change at page 29, line 25
3.2.3. Assisted Replication 3.2.3. Assisted Replication
When Assisted Replication is used to transport IP multicast frames of When Assisted Replication is used to transport IP multicast frames of
a given Tenant Domain, each EVPN-PE (including the AR-REPLICATOR) a given Tenant Domain, each EVPN-PE (including the AR-REPLICATOR)
attached to the Tenant Domain MUST originate an SBD-IMET route (see attached to the Tenant Domain MUST originate an SBD-IMET route (see
Section 3.2.1). Section 3.2.1).
An AR-REPLICATOR attached to a given Tenant Domain is considered to An AR-REPLICATOR attached to a given Tenant Domain is considered to
be an EVPN-PE of that Tenant Domain. It is attached to all the BDs be an EVPN-PE of that Tenant Domain. It is attached to all the BDs
in the Tenant Domain, but it has no IRB interfaces. in the Tenant Domain, but it does not necessarily have L3 routing
instances.
As with Ingress Replication, the SBD-IMET route carries a PTA where As with Ingress Replication, the SBD-IMET route carries a PTA where
the MPLS label field specifies the downstream-assigned MPLS label the MPLS label field specifies the downstream-assigned MPLS label
that identifies the SBD. However, the AR-REPLICATOR and AR-LEAF that identifies the SBD. However, the AR-REPLICATOR and AR-LEAF
EVPN-PEs will set the PTA's flags differently, as per [EVPN-AR]. EVPN-PEs will set the PTA's flags differently, as per [EVPN-AR].
In addition, each EVPN-PE originates an IMET route for each BD to In addition, each EVPN-PE originates an IMET route for each BD to
which it is attached. As in the case of Ingress Replication, these which it is attached. As in the case of Ingress Replication, these
routes carry the downstream-assigned MPLS labels that identify the routes carry the downstream-assigned MPLS labels that identify the
BDs and do not carry the SBD-RT. BDs and do not carry the SBD-RT.
When an ingress EVPN-PE, acting as AR-LEAF, needs to send an IP When an ingress EVPN-PE, acting as AR-LEAF, needs to send an IP
multicast frame from a particular source BD to an egress EVPN-PE, the multicast frame from a particular source BD to an egress EVPN-PE, the
ingress PE determines whether there is any AR-REPLICATOR that ingress PE determines whether there is any AR-REPLICATOR that
originated an IMET route for that BD. After the AR-REPLICATOR originated an IMET route for that BD. After the AR-REPLICATOR
selection (if there are more than one), the AR-LEAF uses the label selection (if there are more than one), the AR-LEAF uses the label
contained in the IMET route of the AR-REPLICATOR when transmitting contained in the IMET route of the AR-REPLICATOR when transmitting
packets to it. The AR-REPLICATOR receives the packet and, based on packets to it. The AR-REPLICATOR receives the packet and, based on
the procedures specified in [EVPN-AR], transmits the packets to the the procedures specified in [EVPN-AR] and in Section 3.2.2 of this
egress EVPN-PEs using the labels contained in the IMET routes document, transmits the packets to the egress EVPN-PEs using the
received from the egress PEs. labels contained in the received IMET routes for either the source BD
or the SBD.
If an ingress AR-LEAF for a given BD has not received any IMET route If an ingress AR-LEAF for a given BD has not received any IMET route
for that BD from an AR-REPLICATOR, the ingress AR-LEAF follows the for that BD from an AR-REPLICATOR, the ingress AR-LEAF follows the
procedures in Section 3.2.2. procedures in Section 3.2.2.
3.2.3.1. Automatic SBD Matching
Each PE needs to know a BD's corresponding SBD. Configuring that
information in each BD is one way but it requires repetitive
configuration and consistency check (to make sure that all the BDs of
the same tenant are configured with the same SBD). A better way is
to configure the SBD info in the L3 routing instance so that all
related BDs will derive the SBD information.
An AR-replicator also needs to know same information, though it does
not necessarily have an L3 routing instance. However from the EVI-RT
EC in a BD's IMET route, an AR-replicator can derive the
corresponding SBD of that BD w/o any configuration.
3.2.4. BIER 3.2.4. BIER
When BIER is used to transport multicast packets of a given Tenant When BIER is used to transport multicast packets of a given Tenant
Domain, and a given EVPN-PE attached to that Tenant Domain is a Domain, and a given EVPN-PE attached to that Tenant Domain is a
possible ingress EVPN-PE for traffic originating outside that Tenant possible ingress EVPN-PE for traffic originating outside that Tenant
Domain, the given EVPN-PE MUST originate an SBD-IMET route, (see Domain, the given EVPN-PE MUST originate an SBD-IMET route, (see
Section 3.2.1). Section 3.2.1).
In addition, IMET routes that are originated for other BDs in the In addition, IMET routes that are originated for other BDs in the
Tenant Domain MUST carry the SBD-RT. Tenant Domain MUST carry the SBD-RT.
skipping to change at page 61, line 25 skipping to change at page 61, line 33
layer 3 multicast routing is done via PIM rather than via BGP. layer 3 multicast routing is done via PIM rather than via BGP.
If external sources or receivers for a given group are attached to a If external sources or receivers for a given group are attached to a
PEG via a layer 3 interface, that interface should be treated as a PEG via a layer 3 interface, that interface should be treated as a
VRF interface attached to the Tenant Domain's L3VPN VRF. The layer 3 VRF interface attached to the Tenant Domain's L3VPN VRF. The layer 3
multicast routing instance for that Tenant Domain will either run PIM multicast routing instance for that Tenant Domain will either run PIM
on the VRF interface or will listen for IGMP/MLD messages on that on the VRF interface or will listen for IGMP/MLD messages on that
interface. If the external receiver is attached elsewhere on an IP interface. If the external receiver is attached elsewhere on an IP
network, the PE has to enable PIM on its interfaces to the backbone network, the PE has to enable PIM on its interfaces to the backbone
network. In both cases, the PE needs to perform PEG functionality, network. In both cases, the PE needs to perform PEG functionality,
and its IMET routes must carry the Muliticast Flags EC with the PEG and its IMET routes must carry the Multicast Flags EC with the PEG
flag set. flag set.
For each BD on which there is a multicast source or receiver, one of For each BD on which there is a multicast source or receiver, one of
the PEGs will becomes the PEG DR. DR selection can be done using the the PEGs will becomes the PEG DR. DR selection can be done using the
same procedures specified in Section 6.1.2.4, except with "PEG" same procedures specified in Section 6.1.2.4, except with "PEG"
substituted for "MEG". substituted for "MEG".
As long as there are no tenant multicast routers within the EVPN As long as there are no tenant multicast routers within the EVPN
Tenant Domain, the PEGs do not need to run PIM on their IRB Tenant Domain, the PEGs do not need to run PIM on their IRB
interfaces. interfaces.
skipping to change at page 67, line 37 skipping to change at page 67, line 43
BGP routes, in order to signal that particular nodes support the BGP routes, in order to signal that particular nodes support the
OISM, IPMG, MEG, and/or PEG functionalities that are defined in this OISM, IPMG, MEG, and/or PEG functionalities that are defined in this
document. Incorrect addition, removal, or modification of those document. Incorrect addition, removal, or modification of those
flags and/or ECs will cause the procedures defined herein to flags and/or ECs will cause the procedures defined herein to
malfunction, in which case loss or diversion of data traffic is malfunction, in which case loss or diversion of data traffic is
possible. possible.
10. Acknowledgements 10. Acknowledgements
The authors thank Vikram Nagarajan and Princy Elizabeth for their The authors thank Vikram Nagarajan and Princy Elizabeth for their
work on Section 6.2. The authors also benefited tremendously from work on Section 6.2 and Section 3.2.3.1. The authors also benefited
discussions with Aldrin Isaac on EVPN multicast optimizations. tremendously from discussions with Aldrin Isaac on EVPN multicast
optimizations.
11. References 11. References
11.1. Normative References 11.1. Normative References
[DF-Election-Framework] [DF-Election-Framework]
Rabadan, J., Mohanty, S., Sajassi, A., Drake, J., Nagaraj, Rabadan, J., Mohanty, S., Sajassi, A., Drake, J., Nagaraj,
K., and S. Sathappan, "Framework for EVPN Designated K., and S. Sathappan, "Framework for EVPN Designated
Forwarder Election Extensibility", internet-draft draft- Forwarder Election Extensibility", internet-draft draft-
ietf-bess-evpn-df-election-framework-07.txt, December ietf-bess-evpn-df-election-framework-07.txt, December
2018. 2018.
[EVPN-AR] Rabadan, J., Ed., "Optimized Ingress Replication solution [EVPN-AR] Rabadan, J., Ed., "Optimized Ingress Replication solution
 End of changes. 21 change blocks. 
24 lines changed or deleted 48 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/