All,
Should we expand this conversation to a L2 EVPN<-> L3 EVPN
space? IOW do we want to tackle this once and for all..
Thanks,
Jim Uttaro
From: BESS [mailto:[email protected]] On Behalf Of Ali Sajassi (sajassi)
Sent: Monday, March 26, 2018 12:54 AM
To: John E Drake <[email protected]>; Rabadan, Jorge (Nokia - US/Mountain
View) <[email protected]>; Eric Rosen <[email protected]>; Sandy Breeze
<[email protected]>; Satya Mohanty (satyamoh) <[email protected]>
Cc: Ali Sajassi (sajassi) <[email protected]>; [email protected]
Subject: Re: [bess] draft-mohanty-bess-evpn-bum-opt-00 - clarification on
problem description
I had some further discussions with the authors of the draft and we have
reached the following conclusions:
1) The solution that they will capture in their draft will be based on
option-A which is:
a. Enable DF election on per mcast flow – this gives the best
load-balancing for DF election among multicast flows and avoids FAT VLAN issue
b. Enable IGMP proxy and SMET route – avoid unnecessary
replication/transmission of mcast flows over core
2) They will re-spin their draft as informational and capture their use
case along with the requirements and the solution
3) We will need to update the text in per-mcast-flow-df-election draft,
igmp-mld-proxy draft, and pim-proxy draft to capture vES in addition to ES and
in future drafts, we should make sure that both ES and vES are captured
Cheers,
Ali
From: John E Drake <[email protected]<mailto:[email protected]>>
Date: Sunday, March 25, 2018 at 9:57 AM
To: Cisco Employee <[email protected]<mailto:[email protected]>>
Cc: "Rabadan, Jorge (Nokia - US/Mountain View)"
<[email protected]<mailto:[email protected]>>, Eric Rosen
<[email protected]<mailto:[email protected]>>, Sandy Breeze
<[email protected]<mailto:[email protected]>>,
"[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>>
Subject: Re: [bess] draft-mohanty-bess-evpn-bum-opt-00 - clarification on
problem description
Ali,
I don't mean to quibble but your option A also requires all PEs to be upgraded.
However, it's both a more mainstream upgrade and a better solution than the
Sandy/Satya proposal.
Also, as we discussed last week, the SMET processing already includes what
Sandy/Satya proposal wants to do. I.e., when a PE is no longer the DF on any
of the ESes to which it is attached it withdraws its SMET routes.
Sent from my iPhone
On Mar 24, 2018, at 1:30 PM, Ali Sajassi (sajassi)
<[email protected]<mailto:[email protected]>> wrote:
Hi Jorge,
As I pointed out in my previous email, the use of flag is not a viable option
because it requires update to every single PE for it to be effective. Before
getting too much into a new solution with many restrictions, we should evaluate
the current mechanisms and if they fall short, then discuss new mechanism. In
one of my emails (which got sent out of order because the connection on the
plane is very slow), I talked about option-A:
The best solution for your use case is (option-A):
1. Enable DF election on per mcast flow – gives the best load-balancing for
DF election among multicast flows and avoids FAT VLAN issue
2. Enable IGMP proxy and SMET route – avoid unnecessary
replication/transmission of mcast flows over core
Cheers,
Ali
From: BESS <[email protected]<mailto:[email protected]>> on behalf of
"Rabadan, Jorge (Nokia - US/Mountain View)"
<[email protected]<mailto:[email protected]>>
Date: Saturday, March 24, 2018 at 3:58 AM
To: Eric C Rosen <[email protected]<mailto:[email protected]>>, Sandy Breeze
<[email protected]<mailto:[email protected]>>,
"[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>>
Subject: Re: [bess] draft-mohanty-bess-evpn-bum-opt-00 - clarification on
problem description
Eric, as discussed and you point out, one can easily interpret that IMET is not
mandatory in some cases where multi-destination traffic is not needed. In any
case, whether this document is Informational or Standards Track is probably not
that important.
If this had to be done, out of the options you list, I think omitting the PTA
would not be backwards compatible since the use of PTA is a MUST in RFC7432, so
RRs wouldn’t like it. Maybe label zero could cause issues too. So maybe a flag
is the least disruptive one if the document has to modify something.
I still think it may be better to proceed with the IMET withdraw procedure and
clarify that it is only valid for:
a) BUM traffic in IR cases
b) BDs with no igmp/mld/pim proxy
c) BDs with no OISM or IRBs
d) BDs with I-ES associated to overlay tunnels and no other ACs
And any other restrictions/caveats we may need to add.
My 2 cents.
Jorge
From: Eric C Rosen <[email protected]<mailto:[email protected]>>
Date: Friday, March 23, 2018 at 5:00 PM
To: "Rabadan, Jorge (Nokia - US/Mountain View)"
<[email protected]<mailto:[email protected]>>, Sandy Breeze
<[email protected]<mailto:[email protected]>>,
"[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>>
Subject: Re: [bess] draft-mohanty-bess-evpn-bum-opt-00 - clarification on
problem description
[Jorge] my interpretation of RFC7432 is that IMET routes are mandatory to
enable the handling of multi-destination traffic in a BD. But in a non-DF PE
for a given ES and with no other ACs in the BD, assuming Ingress Replication,
there is no such multi-destination traffic (Tx or Rx). So one could interpret
that RFC7432 is ok with withdrawing the IMET route in that case.
If we consider the case of all-active multi-homing, then there may well be Tx
multi-destination traffic in the scenario under discussion, as multicast
traffic from a given ES could arrive at any PE attached to the ES, whether or
not that PE is the DF.
The relevant section from RFC 7432 is:
11. Handling of Multi-destination Traffic
Procedures are required for a given PE to send broadcast or multicast
traffic received from a CE encapsulated in a given Ethernet tag
(VLAN) in an EVPN instance to all the other PEs that span that
Ethernet tag (VLAN) in that EVPN instance. In certain scenarios, as
described in Section 12 ("Processing of Unknown Unicast Packets"), a
given PE may also need to flood unknown unicast traffic to other PEs.
The PEs in a particular EVPN instance may use ingress replication,
P2MP LSPs, or MP2MP LSPs to send unknown unicast, broadcast, or
multicast traffic to other PEs.
Each PE MUST advertise an "Inclusive Multicast Ethernet Tag route" to
enable the above. The following subsection provides the procedures
to construct the Inclusive Multicast Ethernet Tag route. Subsequent
subsections describe its usage in further detail.
Interestingly, this says that the IMET route is mandatory to enable "the
above", where "the above" is "send broadcast or multicast traffic received from
a CE". Note it says "send", not "receive".
If P2MP tunnels are used for the BUM traffic, the IMET route is certainly
required to support all-active multi-homing. If IR is used, or if
single-active multi-homing is used, one could argue that RFC 7432 didn't really
need to require the IMET route. However, it does.
[John] Wouldn’t it be better to have this draft define a bit in the Multicast
Flags extended community
(https://tools.ietf.org/html/draft-ietf-bess-evpn-igmp-mld-proxy-01<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dietf-2Dbess-2Devpn-2Digmp-2Dmld-2Dproxy-2D01&d=DwMGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=-DXB84eU9m4cIlq2OOcCJCQQAwJXQQswyu3F0kG0VNo&m=rs8r_tXnIDIv9e5NNgiXOy5yYuE10r6x9al8H6FgK04&s=V42kiY3ngmDNxMKmk5GgHmy9LcMGdOXpcvbereFtUR8&e=>)
indicating that that the originating PE is neither DF nor backup DF for this
broadcast domain on any ES to which it is attached? This allows us to always
advertise the IMET route and makes the situation explicit. I think the
consensus is that this situation is rare so the number of IMET route updates
shouldn’t be excessive and we could also say that this bit is only set by EVPN
DC GWs.
If it's worth doing at all, this would be a better method. Alternatives would
be omitting the PMSI Tunnel attribute, or setting the MPLS label in the PMSI
Tunnel attribute to 0.
[Sandy] We’d considered alternative methods other than withdraw, such as
extended community or something specific in PMSI Tunnel Attribute.
Withdraw/don’t advertise RT3 approach was chosen for the following reasons;
· Requires no change to protocol
Since the proposal changes the conditions under which an IMET route is
originated, it is certainly changing the protocol. (It's obvious that the
finite state machine is changed.) Perhaps what is meant is that the protocol
change is backwards compatible with systems that implement only RFC7432. But
it does not appear to be backwards compatible with systems that have IRB, and
the draft has no analysis of the impact on all the various extensions and
proposed extensions to RFC7432.
· Is computationally easier on all participating PE’s, to deal with a
simple withdraw than to look for something in an update. For instance, on
transition from BDF to NDF for example
These are of course not the only considerations.
_______________________________________________
BESS mailing list
[email protected]<mailto:[email protected]>
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_bess&d=DwICAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=CRB2tJiQePk0cT-h5LGhEWH-s_xXXup3HzvBSMRj5VE&m=OdMuRFQV6omnCDf3TmywTtn1VPIRaTJK4ryi6yVwveE&s=QAWt42753vZzfOQ0mJP32Xk-D7_QwwEloKLv2jirKNg&e=
_______________________________________________
BESS mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/bess
