< draft-ietf-bier-evpn-01.txt   draft-ietf-bier-evpn-02.txt >
BIER Z. Zhang BIER Z. Zhang
Internet-Draft A. Przygienda Internet-Draft A. Przygienda
Intended status: Standards Track Juniper Networks Intended status: Standards Track Juniper Networks
Expires: October 29, 2018 A. Sajassi Expires: May 7, 2020 A. Sajassi
Cisco Systems Cisco Systems
J. Rabadan J. Rabadan
Nokia Nokia
April 27, 2018 November 4, 2019
EVPN BUM Using BIER EVPN BUM Using BIER
draft-ietf-bier-evpn-01 draft-ietf-bier-evpn-02
Abstract Abstract
This document specifies protocols and procedures for forwarding This document specifies protocols and procedures for forwarding
broadcast, unknown unicast and multicast (BUM) traffic of Ethernet broadcast, unknown unicast and multicast (BUM) traffic of Ethernet
VPNs (EVPN) using Bit Index Explicit Replication (BIER). VPNs (EVPN) using Bit Index Explicit Replication (BIER).
Requirements Language Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
skipping to change at page 1, line 42 skipping to change at page 1, line 42
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 October 29, 2018. This Internet-Draft will expire on May 7, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2018 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
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 . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Terminologies . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Terminologies . . . . . . . . . . . . . . . . . . . . . . 3
2. Use of the PMSI Tunnel Attribute . . . . . . . . . . . . . . 4 2. Use of the PMSI Tunnel Attribute . . . . . . . . . . . . . . 4
2.1. Explicit Tracking . . . . . . . . . . . . . . . . . . . . 5 2.1. Auxiliary Information . . . . . . . . . . . . . . . . . . 5
2.1.1. Using IMET/SMET routes . . . . . . . . . . . . . . . 5 2.2. Explicit Tracking . . . . . . . . . . . . . . . . . . . . 6
2.1.2. Using S-PMSI/Leaf A-D Routes . . . . . . . . . . . . 6 2.2.1. Using IMET/SMET routes . . . . . . . . . . . . . . . 6
2.2. MPLS Label in PTA . . . . . . . . . . . . . . . . . . . . 7 2.2.2. Using S-PMSI/Leaf A-D Routes . . . . . . . . . . . . 6
3. Multihoming Split Horizon . . . . . . . . . . . . . . . . . . 7 2.3. MPLS Label in PTA . . . . . . . . . . . . . . . . . . . . 7
3. Multihoming Split Horizon . . . . . . . . . . . . . . . . . . 8
4. Data Plane . . . . . . . . . . . . . . . . . . . . . . . . . 8 4. Data Plane . . . . . . . . . . . . . . . . . . . . . . . . . 8
4.1. Encapsulation and Transmission . . . . . . . . . . . . . 8 4.1. Encapsulation and Transmission . . . . . . . . . . . . . 8
4.1.1. At a BFIR that is an Ingress PE . . . . . . . . . . . 8 4.1.1. At a BFIR that is an Ingress PE . . . . . . . . . . . 8
4.1.2. At a BFIR that is a P-tunnel Segmentation Point . . . 10 4.1.2. At a BFIR that is a P-tunnel Segmentation Point . . . 10
4.2. Disposition . . . . . . . . . . . . . . . . . . . . . . . 10 4.2. Disposition . . . . . . . . . . . . . . . . . . . . . . . 11
4.2.1. At a BFER that is an Egress PE . . . . . . . . . . . 10 4.2.1. At a BFER that is an Egress PE . . . . . . . . . . . 11
4.2.2. At a BFER that is a P-tunnel Segmentation Point . . . 11 4.2.2. At a BFER that is a P-tunnel Segmentation Point . . . 11
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
8.1. Normative References . . . . . . . . . . . . . . . . . . 11 8.1. Normative References . . . . . . . . . . . . . . . . . . 12
8.2. Informative References . . . . . . . . . . . . . . . . . 12 8.2. Informative References . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14
1. Introduction 1. Introduction
[RFC7432] and [RFC8365] specify the protocols and procedures for [RFC7432] and [RFC8365] specify the protocols and procedures for
Ethernet VPNs (EVPNs). For broadcast, unknown unicast and multicast Ethernet VPNs (EVPNs). For broadcast, unknown unicast and multicast
(BUM) traffic, provider/underlay tunnels (referred to as P-tunnels) (BUM) traffic, provider/underlay tunnels (referred to as P-tunnels)
are used to carry the BUM traffic. Several kinds of tunnel are used to carry the BUM traffic. Several kinds of tunnel
technologies can be used, as specified in [RFC7432]. technologies can be used, as specified in [RFC7432].
Bit Index Explicit Replication (BIER) ([RFC8279]) is an architecture Bit Index Explicit Replication (BIER) ([RFC8279]) is an architecture
skipping to change at page 3, line 12 skipping to change at page 3, line 12
domain", without requiring intermediate routers to maintain any per- domain", without requiring intermediate routers to maintain any per-
flow state or to engage in an explicit tree-building protocol. The flow state or to engage in an explicit tree-building protocol. The
purpose of this document is to specify the protocols and procedures purpose of this document is to specify the protocols and procedures
to transport EVPN BUM traffic using BIER. to transport EVPN BUM traffic using BIER.
The EVPN BUM procedures specified in [RFC7432] and extended in The EVPN BUM procedures specified in [RFC7432] and extended in
[I-D.ietf-bess-evpn-bum-procedure-updates], [I-D.ietf-bess-evpn-bum-procedure-updates],
[I-D.ietf-bess-evpn-igmp-mld-proxy], and [I-D.ietf-bess-evpn-igmp-mld-proxy], and
[I-D.zzhang-bess-mvpn-evpn-cmcast-enhancements] are much aligned with [I-D.zzhang-bess-mvpn-evpn-cmcast-enhancements] are much aligned with
MVPN procedures. As such, this document is also very much aligned MVPN procedures. As such, this document is also very much aligned
with [I-D.ietf-bier-mvpn]. For terseness, some background, terms and with [RFC8556]. For terseness, some background, terms and concepts
concepts are not repeated here. Additionally, some text is borrowed are not repeated here. Additionally, some text is borrowed verbatim
verbatim from [I-D.ietf-bier-mvpn]. from [RFC8556].
1.1. Terminologies 1.1. Terminologies
o BFR: Bit-Forwarding Router. o BFR: Bit-Forwarding Router.
o BFIR: Bit-Forwarding Ingress Router. o BFIR: Bit-Forwarding Ingress Router.
o BFER: Bit-Forwarding Egress Router. o BFER: Bit-Forwarding Egress Router.
o BFR-Prefix: An IP address that uniquely identifies a BFR and is o BFR-Prefix: An IP address that uniquely identifies a BFR and is
skipping to change at page 4, line 17 skipping to change at page 4, line 17
o PMSI Tunnel attribute (PTA). This BGP attribute carried is used o PMSI Tunnel attribute (PTA). This BGP attribute carried is used
to identify a particular P-tunnel. When C-flows of multiple VPNs to identify a particular P-tunnel. When C-flows of multiple VPNs
are carried in a single P-tunnel, this attribute also carries the are carried in a single P-tunnel, this attribute also carries the
information needed to multiplex and demultiplex the C-flows. information needed to multiplex and demultiplex the C-flows.
2. Use of the PMSI Tunnel Attribute 2. Use of the PMSI Tunnel Attribute
[RFC7432] specifies that Inclusive Multicast Ethernet Tag (IMET) [RFC7432] specifies that Inclusive Multicast Ethernet Tag (IMET)
routes carry a PMSI Tunnel Attribute (PTA) to identify the particular routes carry a PMSI Tunnel Attribute (PTA) to identify the particular
P-tunnel to which one or more BUM flows are being assigned, the same P-tunnel to which one or more BUM flows are being assigned, the same
as specified in [RFC6514] for MVPN. [I-D.ietf-bier-mvpn] specifies as specified in [RFC6514] for MVPN. [RFC8556] specifies the encoding
the encoding of PTA for use of BIER with MVPN. Much of that of PTA for use of BIER with MVPN. Much of that specification is
specification is reused for use of BIER with EVPN and much of the reused for use of BIER with EVPN and much of the text below is
text below is borrowed verbatim from [I-D.ietf-bier-mvpn]. borrowed verbatim from [RFC8556].
The PMSI Tunnel Attribute (PTA) contains the following fields: The PMSI Tunnel Attribute (PTA) contains the following fields:
o "Tunnel Type". The same codepoint 0x0B that IANA has assigned for o "Tunnel Type". The same codepoint 0x0B that IANA has assigned for
[I-D.ietf-bier-mvpn] for the new tunnel type "BIER" is used for [RFC8556] for the new tunnel type "BIER" is used for EVPN as well.
EVPN as well.
o "Tunnel Identifier". When the "tunnel type" field is "BIER", this o "Tunnel Identifier". When the "tunnel type" field is "BIER", this
field contains two subfields. The text below is exactly as in field contains two subfields. The text below is exactly as in
[I-D.ietf-bier-mvpn]. [RFC8556].
1 The first subfield is a single octet, containing the sub- 1 The first subfield is a single octet, containing the sub-
domain-id of the sub-domain to which the BFIR will assign the domain-id of the sub-domain to which the BFIR will assign the
packets that it transmits on the PMSI identified by the NLRI of packets that it transmits on the PMSI identified by the NLRI of
the IMET, S-PMSI A-D, or per-region I-PMSI A-D route that the IMET, S-PMSI A-D, or per-region I-PMSI A-D route that
contains this PTA. How that sub-domain is chosen is outside contains this PTA. How that sub-domain is chosen is outside
the scope of this document. the scope of this document.
2 The second subfield is a two-octet field containing the BFR-id, 2 The second subfield is a two-octet field containing the BFR-id,
in the sub-domain identified in the first subfield, of the in the sub-domain identified in the first subfield, of the
skipping to change at page 5, line 8 skipping to change at page 5, line 12
the address is IPv4 or IPv6 can be inferred from the total the address is IPv4 or IPv6 can be inferred from the total
length of the PMSI Tunnel attribute. length of the PMSI Tunnel attribute.
The BFR-prefix need not be the same IP address that is carried The BFR-prefix need not be the same IP address that is carried
in any other field of the x-PMSI A-D route, even if the BFIR is in any other field of the x-PMSI A-D route, even if the BFIR is
the originating router of the x-PMSI A-D route. the originating router of the x-PMSI A-D route.
o "MPLS label". For EVPN-MPLS [RFC7432], this field contains an o "MPLS label". For EVPN-MPLS [RFC7432], this field contains an
upstream-assigned MPLS label. It is assigned by the BFIR. upstream-assigned MPLS label. It is assigned by the BFIR.
Constraints on the way in which the originating router selects Constraints on the way in which the originating router selects
this label are discussed in Section 2.2. For EVPN-VXLAN/NVGRE this label are discussed in Section 2.3. For EVPN-VXLAN/NVGRE/
[RFC8365], this field is a 24-bit VNI/VSID of global significance. GENEVE [RFC8365], this field is a 24-bit VNI/VSID of global
significance.
o "Flags". When the tunnel type is BIER, two of the flags in the o "Flags". When the tunnel type is BIER, two of the flags in the
PTA Flags field are meaningful. Details about the use of these PTA Flags field are meaningful. Details about the use of these
flags can be found in Section 2.1. flags can be found in Section 2.2.
* "Leaf Info Required per Flow (LIR-pF)" * "Leaf Info Required per Flow (LIR-pF)"
[I-D.ietf-bess-mvpn-expl-track] [I-D.ietf-bess-mvpn-expl-track]
* "Leaf Info Required Bit (LIR)" * "Leaf Info Required Bit (LIR)"
o "Auxiliary Information". This is optional, present if the total
length of the PTA is larger then the sum of lengths of the fields
before this one. It is in the form of a series of TLVs.
Note that if a PTA specifying "BIER" is attached to an IMET, S-PMSI Note that if a PTA specifying "BIER" is attached to an IMET, S-PMSI
A-D, or per-region I-PMSI A-D route, the route MUST NOT be A-D, or per-region I-PMSI A-D route, the route MUST NOT be
distributed beyond the boundaries of a BIER domain. That is, any distributed beyond the boundaries of a BIER domain. That is, any
routers that receive the route must be in the same BIER domain as the routers that receive the route must be in the same BIER domain as the
originator of the route. If the originator is in more than one BIER originator of the route. If the originator is in more than one BIER
domain, the route must be distributed only within the BIER domain in domain, the route must be distributed only within the BIER domain in
which the BFR-Prefix in the PTA uniquely identifies the originator. which the BFR-Prefix in the PTA uniquely identifies the originator.
As with all MVPN routes, distribution of these routes is controlled As with all MVPN routes, distribution of these routes is controlled
by the provisioning of Route Targets. by the provisioning of Route Targets.
2.1. Explicit Tracking 2.1. Auxiliary Information
For the "Auxiliary Information", one TLV is defined in this document
- Tunnel Encapsulation TLV. The value part of the TLV is a Tunnel
TLV as defined in [I-D.ietf-idr-tunnel-encaps].
This MAY be used when VXLAN/NVGRE/GENEVE encapsulation with an IP
header (and UDP header in case of VXLAN/GENVE) is the BIER payload.
Normally that is not needed with BIER, except when BIER PHP [I-
D.ietf-bier-php] is used and the encapsulation (after BIER header is
popped) between the BIER Penultimate Hop and the egress PE does not
have a way to indicate the next header is VXLAN/NVGRE/GENEVE. In
that case the full VXLAN/NVGRE/GENEVE encapsulation with an IP header
MUST be used. The tunnel type (VXLAN/NVGRE/GENEVE), endpoint, and
some tunnel specific information MAY be specified in the Tunnel TLV
or MAY be provisioned on PEs. The tunnel endpoint MUST be an IP
multicast address and the receiving egress PE MUST be set up to
receive and process packets addressed to the address. The same
multicast address can be used for all BDs, as the the inner
VXLAN/NVGRE/GENEVE header will be used to identify BDs.
2.2. Explicit Tracking
When using BIER to transport an EVPN BUM data packet through a BIER When using BIER to transport an EVPN BUM data packet through a BIER
domain, an ingress PE functions as a BFIR (see [RFC8279]). The BFIR domain, an ingress PE functions as a BFIR (see [RFC8279]). The BFIR
must determine the set of BFERs to which the packet needs to be must determine the set of BFERs to which the packet needs to be
delivered. This can be done in either of two ways in the following delivered. This can be done in either of two ways in the following
two sections. two sections.
2.1.1. Using IMET/SMET routes 2.2.1. Using IMET/SMET routes
Both IMET and SMET (Selective Multicast Ethernet Tag Both IMET and SMET (Selective Multicast Ethernet Tag
[I-D.ietf-bess-evpn-igmp-mld-proxy]) routes provide explicit tracking [I-D.ietf-bess-evpn-igmp-mld-proxy]) routes provide explicit tracking
functionality. functionality.
For an inclusive PMSI, the set of BFERs to deliver traffic to For an inclusive PMSI, the set of BFERs to deliver traffic to
includes the originators of all IMET routes for a broadcast domain. includes the originators of all IMET routes for a broadcast domain.
For a selective PMSI, the set of BFERs to deliver traffic to includes For a selective PMSI, the set of BFERs to deliver traffic to includes
the originators of corresponding SMET routes. the originators of corresponding SMET routes.
The SMET routes do not carry a PTA. When an ingress PE sends traffic The SMET routes do not carry a PTA. When an ingress PE sends traffic
on a selective tunnel using BIER, it uses the upstream assigned label on a selective tunnel using BIER, it uses the upstream assigned label
that is advertised in its IMET route. that is advertised in its IMET route.
Only when selectively forwarding is for all flows without tunnel Only when selectively forwarding is for all flows without tunnel
segmentation, SMET routes are used without the need for S-PMSI A-D segmentation, SMET routes are used without the need for S-PMSI A-D
routes. Otherwise, the procedures in the following section apply. routes. Otherwise, the procedures in the following section apply.
2.1.2. Using S-PMSI/Leaf A-D Routes 2.2.2. Using S-PMSI/Leaf A-D Routes
There are two cases where S-PMSI/Leaf A-D routes are used as There are two cases where S-PMSI/Leaf A-D routes are used as
discussed in the following two sections. discussed in the following two sections.
2.1.2.1. Selective Forwarding Only for Some Flows 2.2.2.1. Selective Forwarding Only for Some Flows
With the SMET procedure, a PE advertises an SMET route for each With the SMET procedure, a PE advertises an SMET route for each
(C-S,C-G) or (C-*,C-G) state that it learns on its ACs, and each SMET (C-S,C-G) or (C-*,C-G) state that it learns on its ACs, and each SMET
route is tracked by every PE in the same broadcast domain. It may be route is tracked by every PE in the same broadcast domain. It may be
desired that SMET routes are not used to reduce the burden of desired that SMET routes are not used to reduce the burden of
explicit tracking. explicit tracking.
In this case, most multicast traffic will follow the I-PMSI In this case, most multicast traffic will follow the I-PMSI
(advertised via IMET route) and only some flows follow S-PMSIs. To (advertised via IMET route) and only some flows follow S-PMSIs. To
achieve that, S-PMSI/Leaf A-D routes can be used, as specified in achieve that, S-PMSI/Leaf A-D routes can be used, as specified in
[I-D.ietf-bess-evpn-bum-procedure-updates]. [I-D.ietf-bess-evpn-bum-procedure-updates].
The rules specified in Section 2.2.1 and Section 2.2.2 of The rules specified in Section 2.2.1 and Section 2.2.2 of [RFC8556]
[I-D.ietf-bier-mvpn] apply. apply.
2.1.2.2. Tunnel Segmentation 2.2.2.2. Tunnel Segmentation
Another case where S-PMSI/Leaf A-D routes are necessary is tunnel Another case where S-PMSI/Leaf A-D routes are necessary is tunnel
segmentation, which is also specified in segmentation, which is also specified in
[I-D.ietf-bess-evpn-bum-procedure-updates], and further clarified in [I-D.ietf-bess-evpn-bum-procedure-updates], and further clarified in
[I-D.zzhang-bess-mvpn-evpn-cmcast-enhancements] for segmentation with [I-D.zzhang-bess-mvpn-evpn-cmcast-enhancements] for segmentation with
SMET routes. This is only applicable to EVPN-MPLS. SMET routes. This is only applicable to EVPN-MPLS.
The rules specified in Section 2.2.1 of [I-D.ietf-bier-mvpn] apply. The rules specified in Section 2.2.1 of [RFC8556] apply.
Section 2.2.2 of [I-D.ietf-bier-mvpn] do not apply, because similar Section 2.2.2 of [RFC8556] do not apply, because similar to MVPN, the
to MVPN, the LIR-pF flag cannot be used with segmentation. LIR-pF flag cannot be used with segmentation.
2.1.2.3. Applicability of Additional MVPN Sepcifications 2.2.2.3. Applicability of Additional MVPN Sepcifications
As with the MVPN case, Section "3. Use of the PMSI Tunnel Attribute As with the MVPN case, Section "3. Use of the PMSI Tunnel Attribute
in Leaf A-D routes" of [I-D.ietf-bier-mvpn] apply. in Leaf A-D routes" of [RFC8556] apply.
Notice that, [I-D.ietf-bier-mvpn] refers to procedures specified in Notice that, [RFC8556] refers to procedures specified in [RFC6625]
[RFC6625] and [I-D.ietf-bess-mvpn-expl-track]. Those two documents and [I-D.ietf-bess-mvpn-expl-track]. Those two documents were
were specified for MVPN but are actually applicable to IP multicast specified for MVPN but are actually applicable to IP multicast
payload in EVPN as well. payload in EVPN as well.
2.2. MPLS Label in PTA 2.3. MPLS Label in PTA
Rules in section 2.1 of [I-D.ietf-bier-mvpn] apply, EXCEPT the Rules in section 2.1 of [RFC8556] apply, EXCEPT the following three
following three bullets (they do NOT apply to EVPN) in that section: bullets (they do NOT apply to EVPN) in that section:
o If the two routes do not have the same Address Family Identifier o If the two routes do not have the same Address Family Identifier
(AFI) value, then their respective PTAs MUST contain different (AFI) value, then their respective PTAs MUST contain different
MPLS label values. This ensures that when an egress PE receives a MPLS label values. This ensures that when an egress PE receives a
data packet with the given label, the egress PE can infer from the data packet with the given label, the egress PE can infer from the
label whether the payload is an IPv4 packet or an IPv6 packet. label whether the payload is an IPv4 packet or an IPv6 packet.
o If the BFIR is an ingress PE supporting MVPN extranet ([RFC7900]) o If the BFIR is an ingress PE supporting MVPN extranet ([RFC7900])
functionality, and if the two routes originate from different VRFs functionality, and if the two routes originate from different VRFs
on this ingress PE, then the respective PTAs of the two routes on this ingress PE, then the respective PTAs of the two routes
skipping to change at page 7, line 34 skipping to change at page 8, line 15
community but the other does not, then the respective PTAs of the community but the other does not, then the respective PTAs of the
two routes MUST contain different MPLS label values. two routes MUST contain different MPLS label values.
3. Multihoming Split Horizon 3. Multihoming Split Horizon
For EVPN-MPLS, [RFC7432] specifies the use of ESI labels to identify For EVPN-MPLS, [RFC7432] specifies the use of ESI labels to identify
the ES from which a BUM packet originates. A PE receiving that the ES from which a BUM packet originates. A PE receiving that
packet from the core side will not forward it to the same ES. The packet from the core side will not forward it to the same ES. The
procedure works for both Ingress Replication (IR) and RSVP-TE/mLDP procedure works for both Ingress Replication (IR) and RSVP-TE/mLDP
P2MP tunnels, using downstream- and upstream-assigned ESI labels P2MP tunnels, using downstream- and upstream-assigned ESI labels
respectively. For EVPN-VXLAN/NVGRE, [RFC8365] specifies local-bias respectively. For EVPN-VXLAN/NVGRE/GENEVE, [RFC8365] specifies
procedures, with which a PE receiving a BUM packet from the core side local-bias procedures, with which a PE receiving a BUM packet from
knows from encapsulation the ingress PE so it does not forward the the core side knows from encapsulation the ingress PE so it does not
packet to any multihoming ESes that the ingress PE is on, because the forward the packet to any multihoming ESes that the ingress PE is on,
ingress PE already forwarded the packet to those ESes, regardless of because the ingress PE already forwarded the packet to those ESes,
whether the ingress PE is a DF for those ESes. regardless of whether the ingress PE is a DF for those ESes.
With BIER, the local-bias procedure still applies for EVPN-VXLAN/ With BIER, the local-bias procedure still applies for EVPN-
NVGRE as the BFIR-id in the BIER header identifies the ingress PE. VXLAN/NVGRE/GENEVE as the BFIR-id in the BIER header identifies the
For EVPN-MPLS, ESI label procedures also still apply though two ingress PE. For EVPN-MPLS, ESI label procedures also still apply
upstream assigned labels will be used (one for identifying the though two upstream assigned labels will be used (one for identifying
broadcast domain and one for identifying the ES) - the same as in the the broadcast domain and one for identifying the ES) - the same as in
case of using a single P2MP tunnel for multiple broadcast domains. the case of using a single P2MP tunnel for multiple broadcast
The BFIR-id in the BIER header identifies the ingress PE that domains. The BFIR-id in the BIER header identifies the ingress PE
assigned those two labels. that assigned those two labels.
4. Data Plane 4. Data Plane
Similar to MVPN, the EVPN application plays the role of the Similar to MVPN, the EVPN application plays the role of the
"multicast flow overlay" as described in [RFC8279]. "multicast flow overlay" as described in [RFC8279].
4.1. Encapsulation and Transmission 4.1. Encapsulation and Transmission
A BFIR could be either an ingress PE or a P-tunnel segmentation A BFIR could be either an ingress PE or a P-tunnel segmentation
point. The procedures are slightly different as described below. point. The procedures are slightly different as described below.
skipping to change at page 9, line 33 skipping to change at page 10, line 11
The following text assumes that BIER is the determined tunnel type. The following text assumes that BIER is the determined tunnel type.
The ingress PE pushes an upstream assigned ESI label per [RFC7432] if The ingress PE pushes an upstream assigned ESI label per [RFC7432] if
the following conditions are all met: the following conditions are all met:
o The packet is received on a multihomed ES. o The packet is received on a multihomed ES.
o It's EVPN-MPLS. o It's EVPN-MPLS.
o ESI label procedure is used for split-horizon. o ESI label procedure is used for split-horizon.
The (upstream-assigned) MPLS label from the PTA of the route matched The MPLS label from the PTA of the route matched for transmission is
for transmission is then pushed onto the packet's label stack in case then pushed onto the packet's label stack for EVPN-MPLS. For EVPN-
of EVPN-MPLS. In case of EVPN-VXLAN/NVGRE, a VXLAN/NVGRE header is VXLAN/NVGRE/GENEVE, a VXLAN/NVGRE/GENEVE header is prepended to the
prepended to the packet with the VNI/VSID set to the value in the packet with the VNI/VSID set to the value in the PTA's label field,
PTA's label field and no IP/UDP header is used. and then an IP/UDP header is prepended if needed (e.g. for PHP
purpose).
Then the packet is encapsulated in a BIER header and forwarded, Then the packet is encapsulated in a BIER header and forwarded,
according to the procedures of [RFC8279] and [RFC8296]. See according to the procedures of [RFC8279] and [RFC8296]. See
especially Section 4, "Imposing and Processing the BIER especially Section 4, "Imposing and Processing the BIER
Encapsulation", of [RFC8296]. The "Proto" field in the BIER header Encapsulation", of [RFC8296]. The "Proto" field in the BIER header
is set to 2 in case of EVPN-MPLS or a value to be assigned in case of is set to 2 in case of EVPN-MPLS, or a value to be assigned in case
EVPN-VXLAN/NVGRE (Section 5). of EVPN-VXLAN/NVGRE/GENEVE (Section 5) when IP header is not used, or
4/6 if IP header is used for EVPN-VXLAN/NVGRE/GENEVE.
In order to create the proper BIER header for a given packet, the In order to create the proper BIER header for a given packet, the
BFIR must know all the BFERs that need to receive that packet. This BFIR must know all the BFERs that need to receive that packet. This
is determined from the set of leaf tracking routes. is determined from the set of leaf tracking routes.
4.1.2. At a BFIR that is a P-tunnel Segmentation Point 4.1.2. At a BFIR that is a P-tunnel Segmentation Point
In this case, the encapsulation for upstream segment of the p-tunnel In this case, the encapsulation for upstream segment of the p-tunnel
includes (among other things) a label that identifies the x-PMSI or includes (among other things) a label that identifies the x-PMSI or
IMET A-D route that is the match for reception on the upstream IMET A-D route that is the match for reception on the upstream
skipping to change at page 10, line 36 skipping to change at page 11, line 13
in the downtream region. in the downtream region.
If the downtream region uses BIER, the packet is forwarded as If the downtream region uses BIER, the packet is forwarded as
following: the upstream segmentation's encapsulation is removed and following: the upstream segmentation's encapsulation is removed and
the above mentioned label is swapped to the upstream-assigned label the above mentioned label is swapped to the upstream-assigned label
in the PTA of the route matched for transmission, and then a BIER in the PTA of the route matched for transmission, and then a BIER
header is imposed as in Section 4.1.1. header is imposed as in Section 4.1.1.
4.2. Disposition 4.2. Disposition
The same procedures in section 4.2 of [I-D.ietf-bier-mvpn] are The same procedures in section 4.2 of [RFC8556] are followed for
followed for EVPN-MPLS, except some EVPN specifics discussed in the EVPN-MPLS, except some EVPN specifics discussed in the following two
following two sub-sections in this document. sub-sections in this document.
For EVPN-VXLAN/NVGRE, the only difference is that the payload is For EVPN-VXLAN/NVGRE/GENEVE, the only difference is that the payload
VXLAN/NVGRE and the VNI/VSID field in the VXLAN/NVGRE header is used is VXLAN/NVGRE/GENEVE (with or without an IP header) and the VNI/VSID
to determine the corresponding mac VRF or broadcast domain. field in the VXLAN/NVGRE/GENEVE header is used to determine the
corresponding mac VRF or broadcast domain.
4.2.1. At a BFER that is an Egress PE 4.2.1. At a BFER that is an Egress PE
Once the corresponding mac VRF or broadcast domain is determined from Once the corresponding mac VRF or broadcast domain is determined from
the upstream assigned label or VNI/VSID, EVPN forwarding procedures the upstream assigned label or VNI/VSID, EVPN forwarding procedures
per [RFC7432] or [RFC8365] are followed. In case of EVPN-MPLS, if per [RFC7432] or [RFC8365] are followed. In case of EVPN-MPLS, if
there is an inner label in the label stack following the BIER header, there is an inner label in the label stack following the BIER header,
that inner label is considered as the upstream assigned ESI label for that inner label is considered as the upstream assigned ESI label for
split horizon purpose. split horizon purpose.
4.2.2. At a BFER that is a P-tunnel Segmentation Point 4.2.2. At a BFER that is a P-tunnel Segmentation Point
This is only applicable to EVPN-MPLS. The same procedures in This is only applicable to EVPN-MPLS. The same procedures in
Section 4.2.2 of [I-D.ietf-bier-mvpn] are followed, subject to Section 4.2.2 of [RFC8556] are followed, subject to multihoming
multihoming procedures specified in procedures specified in [I-D.ietf-bess-evpn-bum-procedure-updates].
[I-D.ietf-bess-evpn-bum-procedure-updates].
5. IANA Considerations 5. IANA Considerations
This document requests two assignments in "BIER Next Protocol This document requests two assignments in "BIER Next Protocol
Identifiers" registry, with the following two recommended values: Identifiers" registry, with the following two recommended values:
o 7: Payload is VXLAN encapsulated (no IP/UDP header) o 7: Payload is VXLAN encapsulated (no IP/UDP header)
o 8: Payload is NVGRE encapsulated (no IP header) o 8: Payload is NVGRE encapsulated (no IP header)
o 9: Payload is GENEVE encapsulated (no IP/UDP header)
6. Security Considerations 6. Security Considerations
To be updated. To be updated.
7. Acknowledgements 7. Acknowledgements
The authors thank Eric Rosen for his review and suggestions. The authors thank Eric Rosen for his review and suggestions.
Additionally, much of the text is borrowed verbatim from Additionally, much of the text is borrowed verbatim from [RFC8556].
[I-D.ietf-bier-mvpn].
8. References 8. References
8.1. Normative References 8.1. Normative References
[I-D.ietf-bess-evpn-bum-procedure-updates] [I-D.ietf-bess-evpn-bum-procedure-updates]
Zhang, Z., Lin, W., Rabadan, J., Patel, K., and A. Zhang, Z., Lin, W., Rabadan, J., Patel, K., and A.
Sajassi, "Updates on EVPN BUM Procedures", draft-ietf- Sajassi, "Updates on EVPN BUM Procedures", draft-ietf-
bess-evpn-bum-procedure-updates-03 (work in progress), bess-evpn-bum-procedure-updates-07 (work in progress),
April 2018. August 2019.
[I-D.ietf-bess-evpn-igmp-mld-proxy] [I-D.ietf-bess-evpn-igmp-mld-proxy]
Sajassi, A., Thoria, S., Patel, K., Yeung, D., Drake, J., Sajassi, A., Thoria, S., Patel, K., Drake, J., and W. Lin,
and W. Lin, "IGMP and MLD Proxy for EVPN", draft-ietf- "IGMP and MLD Proxy for EVPN", draft-ietf-bess-evpn-igmp-
bess-evpn-igmp-mld-proxy-01 (work in progress), March mld-proxy-04 (work in progress), September 2019.
2018.
[I-D.ietf-bess-evpn-optimized-ir]
Rabadan, J., Sathappan, S., Lin, W., Katiyar, M., and A.
Sajassi, "Optimized Ingress Replication solution for
EVPN", draft-ietf-bess-evpn-optimized-ir-06 (work in
progress), October 2018.
[I-D.ietf-bess-mvpn-expl-track] [I-D.ietf-bess-mvpn-expl-track]
Dolganow, A., Kotalwar, J., Rosen, E., and Z. Zhang, Dolganow, A., Kotalwar, J., Rosen, E., and Z. Zhang,
"Explicit Tracking with Wild Card Routes in Multicast "Explicit Tracking with Wild Card Routes in Multicast
VPN", draft-ietf-bess-mvpn-expl-track-09 (work in VPN", draft-ietf-bess-mvpn-expl-track-13 (work in
progress), April 2018. progress), November 2018.
[I-D.ietf-bier-mvpn] [I-D.ietf-idr-tunnel-encaps]
Rosen, E., Sivakumar, M., Aldrin, S., Dolganow, A., and T. Patel, K., Velde, G., and S. Ramachandra, "The BGP Tunnel
Przygienda, "Multicast VPN Using BIER", draft-ietf-bier- Encapsulation Attribute", draft-ietf-idr-tunnel-encaps-14
mvpn-11 (work in progress), March 2018. (work in progress), September 2019.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC6625] Rosen, E., Ed., Rekhter, Y., Ed., Hendrickx, W., and R. [RFC6625] Rosen, E., Ed., Rekhter, Y., Ed., Hendrickx, W., and R.
Qiu, "Wildcards in Multicast VPN Auto-Discovery Routes", Qiu, "Wildcards in Multicast VPN Auto-Discovery Routes",
RFC 6625, DOI 10.17487/RFC6625, May 2012, RFC 6625, DOI 10.17487/RFC6625, May 2012,
<https://www.rfc-editor.org/info/rfc6625>. <https://www.rfc-editor.org/info/rfc6625>.
skipping to change at page 12, line 37 skipping to change at page 13, line 22
Explicit Replication (BIER)", RFC 8279, Explicit Replication (BIER)", RFC 8279,
DOI 10.17487/RFC8279, November 2017, DOI 10.17487/RFC8279, November 2017,
<https://www.rfc-editor.org/info/rfc8279>. <https://www.rfc-editor.org/info/rfc8279>.
[RFC8296] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A., [RFC8296] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A.,
Tantsura, J., Aldrin, S., and I. Meilik, "Encapsulation Tantsura, J., Aldrin, S., and I. Meilik, "Encapsulation
for Bit Index Explicit Replication (BIER) in MPLS and Non- for Bit Index Explicit Replication (BIER) in MPLS and Non-
MPLS Networks", RFC 8296, DOI 10.17487/RFC8296, January MPLS Networks", RFC 8296, DOI 10.17487/RFC8296, January
2018, <https://www.rfc-editor.org/info/rfc8296>. 2018, <https://www.rfc-editor.org/info/rfc8296>.
[RFC8317] Sajassi, A., Ed., Salam, S., Drake, J., Uttaro, J.,
Boutros, S., and J. Rabadan, "Ethernet-Tree (E-Tree)
Support in Ethernet VPN (EVPN) and Provider Backbone
Bridging EVPN (PBB-EVPN)", RFC 8317, DOI 10.17487/RFC8317,
January 2018, <https://www.rfc-editor.org/info/rfc8317>.
[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>.
8.2. Informative References 8.2. Informative References
[I-D.boutros-bess-evpn-geneve]
Boutros, S., Sajassi, A., Drake, J., Rabadan, J., and S.
Aldrin, "EVPN control plane for Geneve", draft-boutros-
bess-evpn-geneve-04 (work in progress), March 2019.
[I-D.ietf-bier-php]
Zhang, Z., "BIER Penultimate Hop Popping", draft-ietf-
bier-php-03 (work in progress), October 2019.
[I-D.keyupate-bess-evpn-virtual-hub]
Patel, K., Sajassi, A., Drake, J., Zhang, Z., and W.
Henderickx, "Virtual Hub-and-Spoke in BGP EVPNs", draft-
keyupate-bess-evpn-virtual-hub-02 (work in progress),
September 2019.
[I-D.zzhang-bess-mvpn-evpn-cmcast-enhancements] [I-D.zzhang-bess-mvpn-evpn-cmcast-enhancements]
Zhang, Z., Kebler, R., Lin, W., and E. Rosen, "MVPN/EVPN Zhang, Z., Kebler, R., Lin, W., and E. Rosen, "MVPN/EVPN
C-Multicast Routes Enhancements", draft-zzhang-bess-mvpn- C-Multicast Routes Enhancements", draft-zzhang-bess-mvpn-
evpn-cmcast-enhancements-00 (work in progress), July 2016. evpn-cmcast-enhancements-01 (work in progress), March
2019.
[RFC8365] Sajassi, A., Ed., Drake, J., Ed., Bitar, N., Shekhar, R., [RFC8365] Sajassi, A., Ed., Drake, J., Ed., Bitar, N., Shekhar, R.,
Uttaro, J., and W. Henderickx, "A Network Virtualization Uttaro, J., and W. Henderickx, "A Network Virtualization
Overlay Solution Using Ethernet VPN (EVPN)", RFC 8365, Overlay Solution Using Ethernet VPN (EVPN)", RFC 8365,
DOI 10.17487/RFC8365, March 2018, DOI 10.17487/RFC8365, March 2018,
<https://www.rfc-editor.org/info/rfc8365>. <https://www.rfc-editor.org/info/rfc8365>.
Authors' Addresses Authors' Addresses
Zhaohui Zhang Zhaohui Zhang
 End of changes. 43 change blocks. 
93 lines changed or deleted 154 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/