Hi,
As the shepherd for this document, I have the following questions/comments
after my pre-WGLC review.
This document defines an enhancement to the Designated Forwarder (DF)
election process in Ethernet Virtual Private Network (EVPN)
environments. While traditional DF election operates at a per
Virtual Local Area Network (VLAN) or per group of VLANs (in case of
VLAN bundle or VLAN-aware bundle service) level, such granularity may
not be sufficient for applications requiring optimized or isolated
multicast forwarding.
...
[RFC7432] defines the procedures for Designated Forwarder (DF)
election in Ethernet Virtual Private Network (EVPN) networks at the
granularity of the Ethernet Segment Identifier (ESI) and the EVPN
Instance (EVI), which typically maps to a single Virtual Local Area
Network (VLAN) or a group of VLANs in the case of VLAN-bundle or
VLAN-aware bundle services. This per-VLAN granularity, however, is
not always sufficient to meet the operational and performance needs
of certain multicast applications.
The above two paragraphs (from the abstract and introduction) talk about
DF per group of VLANs in the case of vlan(-aware) bundle, and then it
talks about "per-VLAN granularity". That is confusing.
I looked into RFC8584, which talked about AC-influenced DF election that
does achieve per-VLAN granularity for vlan-aware bundle. I think we
should add text about the per-vlan granularity in the case of vlan-aware
bundle, and change "This per-VLAN granularity, however, ..." to
"Even the per-VLAN granularity, however, ...".
[RFC8584] defines an extended community, which would be used for PEs
in redundancy group to reach a consensus as to which DF election
procedure is desired. A PE can notify other participating PEs in
redundancy group about its willingness to support Per multicast flow
base DF election capability by signaling a DF election extended
community along with Ethernet-Segment Route (Type-4). The current
proposal extends the existing extended community defined in
[RFC8584]. This draft defines new a DF type. [RFC8584] defines a DF
Election Extended Community that is used by Provider Edge (PE)
devices in a redundancy group to reach consensus on the DF election
procedure to be used for a given Ethernet Segment (ES). A PE
indicates its supported DF election capability by attaching this
extended community to its Ethernet Segment Route (Route Type 4)
advertisement. This document extends the DF Election Extended
Community defined in [RFC8584] by introducing a new DF Alg to signal
support for per-multicast flow-based DF election. A PE that supports
the procedures specified in this document MUST signal the
corresponding DF Alg in its Route Type 4 advertisement. This enables
all participating PEs in the redundancy group to discover and agree
upon the enhanced DF election behavior in a backward-compatible and
interoperable manner.
There are quite some repetitive text in the above paragraph.
This document is an extension of [RFC8584], so this draft does not
repeat the description of HRW algorithm itself. This document is an
extension of [RFC8584] and leverages the Highest Random Weight (HRW)
algorithm for Designated Forwarder (DF) election. Therefore, this
draft does not repeat the general description of the HRW algorithm
itself. Section 3.2 of [RFC8584] defines the use of the HRW
algorithm for DF election in Ethernet Virtual Private Network (EVPN)
environments. This document enhances that mechanism by introducing
additional input parameters from the multicast flow, allowing DF
election to be performed at the granularity of (𝑆, 𝐺, 𝑉, Es ) where:
The repetitive text in the above paragraph could be cleaned up a bit.
* Weight (S,G,V, ESI, Address(i)) = (1103515245.
((1103515245.Address(i) + 12345) XOR D(S,G,V,ESI))+12345) (mod
2^31)
What does the '.' in the above function mean? What if Address(i) is IPv6?
I noticed that in RFC8584, there is only one '.'.
5.3. Default DF election procedure
The per-multicast flow Designated Forwarder (DF) election procedure
defined in this document is applicable only after multicast
membership activity is detected, i.e., when hosts behind the
Attachment Circuit (AC) of a given Ethernet Segment (ES) begin
sending Internet Group Management Protocol (IGMP) or Multicast
Listener Discovery (MLD) membership reports. Membership information
is synchronized across the participating Provider Edge (PE) devices
in the redundancy group using the procedures defined in [RFC9251].
Once synchronized, each PE MAY apply the per-flow DF election
procedure to create and maintain DF state on a per multicast flow
basis (i.e., per (S,G) or (∗,G) flow). The "Type 1" Highest Random
Weight (HRW) DF election procedure specified in [RFC8584] MUST be
used to perform the default DF election for the Ethernet Segment.
This election SHOULD be performed at the port level, independent of
multicast membership state, and SHOULD occur prior to any IGMP or MLD
membership activity.
"default DF election" is confusing, since we have "Alg 0" for "Default
DF Election". Perhaps call it "base DF election"?
Why should it be port level? For vlan-aware bundles, RFC8584 already
supports per-vlan "base DF election".
As multicast membership requests are subsequently learned and
synchronized, the default port level DF state MUST be overridden by
the per-flow DF election mechanism introduced in this document.
"the default DF state MUST be overriden" is misleading. The "base DF state"
does not change (for broadcast, unknow unicast, link local multicast, and
multicast that we have learned join state for), but the specific flows
for which the membership have been learned will now have their per-flow DF
state.
Thanks.
Jeffrey
Juniper Business Use Only
_______________________________________________
BESS mailing list -- [email protected]
To unsubscribe send an email to [email protected]
