Subject: Re: [bess] draft-mohanty-bess-evpn-bum-opt-00 - clarification on problem description

From: Wen Lin <[email-masked]>
Date: Tue, 3 Apr 2018 18:01:43 +0000

The question is, in general,  whether we need to support more than one remote VTEP in this type of use case when VXLAN is used on the access side?   I think the answer is yes.

So the question about how to deal with “one remote VTEP verses more than one remote VTEP” is logically the same as “one CE verses more than one CE”.

Thanks,
Wen

From: BESS <[email-masked]> on behalf of "Ali Sajassi (sajassi)" <[email-masked]>
Date: Monday, March 26, 2018 at 2:54 PM
To: "UTTARO, JAMES" <[email-masked]>, John E Drake <[email-masked]>, "Rabadan, Jorge (Nokia - US/Mountain View)" <[email-masked]>, Eric Rosen <[email-masked]>, Sandy Breeze <[email-masked]>, "Satya Mohanty (satyamoh)" <[email-masked]>
Cc: "Ali Sajassi (sajassi)" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [bess] draft-mohanty-bess-evpn-bum-opt-00 - clarification on problem description

Hi Jim,

Draft-mohanty-bess-evpn-bum-opt is for a very specific use case and that use case is described in section 4.4 of draft-ietf-bess-dci-evpn-overlay. The solution for optimization for this use case could have been covered either in igmp-mld-proxy draft itself or it could be covered in a separate draft. I suggested it to be covered in a separate draft because I wasn’t keen in adding a new section to igmp-mld-proxy given that it is getting ready for WG LC. However, if people think it should be covered in igmp-mld-proxy draft then we can take that under consideration.

The interconnect of L2 to IRB/L3 core will be covered in the corresponding IRB mcast drafts.

Cheers,
Ali

From: "UTTARO, JAMES" <[email-masked]>
Date: Monday, March 26, 2018 at 10:46 AM
To: Cisco Employee <[email-masked]>, John E Drake <[email-masked]>, "Rabadan, Jorge (Nokia - US/Mountain View)" <[email-masked]>, Eric Rosen <[email-masked]>, Sandy Breeze <[email-masked]>, "Satya Mohanty (satyamoh)" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: RE: [bess] draft-mohanty-bess-evpn-bum-opt-00 - clarification on problem description

Ali,

                So, is this going to be a family of drafts dealing with inter-connection aspects across a set of use cases ? Would it be useful to right up a requirements draft like we did with EVPN??

Thanks,
                Jim Uttaro

From: Ali Sajassi (sajassi) [mailto:[email-masked]]
Sent: Monday, March 26, 2018 1:20 PM
To: UTTARO, JAMES <[email-masked]>; John E Drake <[email-masked]>; Rabadan, Jorge (Nokia - US/Mountain View) <[email-masked]>; Eric Rosen <[email-masked]>; Sandy Breeze <[email-masked]>; Satya Mohanty (satyamoh) <[email-masked]>
Cc: [email-masked]
Subject: Re: [bess] draft-mohanty-bess-evpn-bum-opt-00 - clarification on problem description

Hi Jim,

draft-mohanty-bess-evpn-bum-opt will focus on L2 only between EVPN overlay (VxLAN) access domain and EVPN MPLS core. Connectivity EVPN IRB core (or EVPN L3 core) will be covered in the other drafts that I mentioned below because they are  already doing it for other use cases.

Cheers,
Ali

From: "UTTARO, JAMES" <[email-masked]<mailto:[email-masked]>>
Date: Monday, March 26, 2018 at 10:03 AM
To: Cisco Employee <[email-masked]<mailto:[email-masked]>>, John E Drake <[email-masked]<mailto:[email-masked]>>, "Rabadan, Jorge (Nokia - US/Mountain View)" <[email-masked]<mailto:[email-masked]>>, Eric Rosen <[email-masked]<mailto:[email-masked]>>, Sandy Breeze <[email-masked]<mailto:[email-masked]>>, "Satya Mohanty (satyamoh)" <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: RE: [bess] draft-mohanty-bess-evpn-bum-opt-00 - clarification on problem description

Ali,

                So is the plan to incorporate Sandy’s work in these docs??

Thanks,
                Jim Uttaro

From: Ali Sajassi (sajassi) [mailto:[email-masked]]
Sent: Monday, March 26, 2018 11:55 AM
To: UTTARO, JAMES <[email-masked]<mailto:[email-masked]>>; John E Drake <[email-masked]<mailto:[email-masked]>>; Rabadan, Jorge (Nokia - US/Mountain View) <[email-masked]<mailto:[email-masked]>>; Eric Rosen <[email-masked]<mailto:[email-masked]>>; Sandy Breeze <[email-masked]<mailto:[email-masked]>>; Satya Mohanty (satyamoh) <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; Ali Sajassi (sajassi) <[email-masked]<mailto:[email-masked]>>
Subject: Re: [bess] draft-mohanty-bess-evpn-bum-opt-00 - clarification on problem description

Hi Jim,

Wrt multicast for L2 EVPN<-> L3 EVPN, that should be covered in corresponding EVPN multicast drafts:

https://tools.ietf.org/html/draft-ietf-bess-evpn-irb-mcast-00<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dietf-2Dbess-2Devpn-2Dirb-2Dmcast-2D00&d=DwMGaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=3qhKphE8RnwJQ6u8MrAGeA&m=9SAgBpjkWp7kuXpNCFnHc0yYR4z5MDVrwDCLAD0vsGE&s=Ek3T8FismWFOPCcpsLXCVErB9uzwJ3Y1w9N_553cDtE&e=>
https://tools.ietf.org/html/draft-sajassi-bess-evpn-mvpn-seamless-interop-00<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dsajassi-2Dbess-2Devpn-2Dmvpn-2Dseamless-2Dinterop-2D00&d=DwMGaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=3qhKphE8RnwJQ6u8MrAGeA&m=9SAgBpjkWp7kuXpNCFnHc0yYR4z5MDVrwDCLAD0vsGE&s=YtlZmFFol1NiX2LvH9SsVJuAZks-JdhzptPE0JZOdeU&e=>

I will update my draft to address Eric’s comments as well as capture the L2 EVPN <-> L3 EVPN explicitly in a few weeks.

Cheers,
Ali

From: "UTTARO, JAMES" <[email-masked]<mailto:[email-masked]>>
Date: Monday, March 26, 2018 at 6:25 AM
To: Cisco Employee <[email-masked]<mailto:[email-masked]>>, John E Drake <[email-masked]<mailto:[email-masked]>>, "Rabadan, Jorge (Nokia - US/Mountain View)" <[email-masked]<mailto:[email-masked]>>, Eric Rosen <[email-masked]<mailto:[email-masked]>>, Sandy Breeze <[email-masked]<mailto:[email-masked]>>, "Satya Mohanty (satyamoh)" <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: RE: [bess] draft-mohanty-bess-evpn-bum-opt-00 - clarification on problem description

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-masked]] On Behalf Of Ali Sajassi (sajassi)
Sent: Monday, March 26, 2018 12:54 AM
To: John E Drake <[email-masked]<mailto:[email-masked]>>; Rabadan, Jorge (Nokia - US/Mountain View) <[email-masked]<mailto:[email-masked]>>; Eric Rosen <[email-masked]<mailto:[email-masked]>>; Sandy Breeze <[email-masked]<mailto:[email-masked]>>; Satya Mohanty (satyamoh) <[email-masked]<mailto:[email-masked]>>
Cc: Ali Sajassi (sajassi) <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
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-masked]<mailto:[email-masked]>>
Date: Sunday, March 25, 2018 at 9:57 AM
To: Cisco Employee <[email-masked]<mailto:[email-masked]>>
Cc: "Rabadan, Jorge (Nokia - US/Mountain View)" <[email-masked]<mailto:[email-masked]>>, Eric Rosen <[email-masked]<mailto:[email-masked]>>, Sandy Breeze <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
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-masked]<mailto:[email-masked]>> 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-masked]<mailto:[email-masked]>> on behalf of "Rabadan, Jorge (Nokia - US/Mountain View)" <[email-masked]<mailto:[email-masked]>>
Date: Saturday, March 24, 2018 at 3:58 AM
To: Eric C Rosen <[email-masked]<mailto:[email-masked]>>, Sandy Breeze <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
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-masked]<mailto:[email-masked]>>
Date: Friday, March 23, 2018 at 5:00 PM
To: "Rabadan, Jorge (Nokia - US/Mountain View)" <[email-masked]<mailto:[email-masked]>>, Sandy Breeze <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
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-masked]<mailto:[email-masked]>
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=

---

From: Sandy Breeze <[email-masked]>
Date: Wed, 4 Apr 2018 10:07:01 +0000

Hi Wen,

Yes, we absolutely need to support more than one remote VTEP in the access side.  As for how to deal with one or more than one remote VTEP, I don’t agree it’s quite the same as one CE vs more than one CE.  For a single VNI in a BD, we should treat this as a single virtual ES in a BD, regardless of how many remote VTEPs there are participating in it.  This is treated differently to multiple CE on a BD, because multiple CE might imply multiple ES’s.

Cheers
Sandy

On 03/04/2018, 19:01, "Wen Lin" <[email-masked]<mailto:[email-masked]>> wrote:

Thanks,
Wen

Hi Jim,

Cheers,
Ali

Ali,

Thanks,
                Jim Uttaro

Hi Jim,

Cheers,
Ali

Ali,

Thanks,
                Jim Uttaro

Hi Jim,

Cheers,
Ali

All,

Thanks,
                Jim Uttaro

Cheers,
Ali

Ali,

Sent from my iPhone

Hi Jorge,

The best solution for your use case is (option-A):
a.       Enable DF election on per mcast flow – 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

Cheers,
Ali

My 2 cents.
Jorge

---

From: Wen Lin <[email-masked]>
Date: Fri, 6 Apr 2018 13:26:28 +0000

Hi Sandy,

Yes, you can have all remote VTEPs share the same virtual ES.  The other alternative is that each remote VTEP is assigned with its own virtual ES, so that we can achieve load balance and quick mass withdrawal when a remote VTEP is no longer reachable.

Thanks,
Wen

From: Sandy Breeze <[email-masked]>
Date: Wednesday, April 4, 2018 at 6:07 AM
To: Wen Lin <[email-masked]>, "Ali Sajassi (sajassi)" <[email-masked]>, "UTTARO, JAMES" <[email-masked]>, John E Drake <[email-masked]>, "Rabadan, Jorge (Nokia - US/Mountain View)" <[email-masked]>, Eric Rosen <[email-masked]>, "Satya Mohanty (satyamoh)" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [bess] draft-mohanty-bess-evpn-bum-opt-00 - clarification on problem description

Hi Wen,

Cheers
Sandy

Thanks,
Wen

Hi Jim,

Cheers,
Ali

Ali,

Thanks,
                Jim Uttaro

Hi Jim,

Cheers,
Ali

Ali,

Thanks,
                Jim Uttaro

Hi Jim,

Cheers,
Ali

All,

Thanks,
                Jim Uttaro

Cheers,
Ali

Ali,

Sent from my iPhone

Hi Jorge,

Cheers,
Ali

My 2 cents.
Jorge

---

From: John E Drake <[email-masked]>
Date: Fri, 6 Apr 2018 13:45:42 +0000

Hi,

We use the virtual ES concept to get additional granularity within a DC.  I.e., there is one ES for the entire DC and multiple virtual ESes, e.g., one per rack, that are anchored to it.  This allows us to perform mass-withdraw for individual rack(s) or mass-withdraw for the entire DC.

Yours Irrespectively,

John

From: Wen Lin
Sent: Friday, April 6, 2018 9:26 AM
To: Sandy Breeze <[email-masked]>; Ali Sajassi (sajassi) <[email-masked]>; UTTARO, JAMES <[email-masked]>; John E Drake <[email-masked]>; Rabadan, Jorge (Nokia - US/Mountain View) <[email-masked]>; Eric Rosen <[email-masked]>; Satya Mohanty (satyamoh) <[email-masked]>
Cc: [email-masked]
Subject: Re: [bess] draft-mohanty-bess-evpn-bum-opt-00 - clarification on problem description

Hi Sandy,

Thanks,
Wen

From: Sandy Breeze <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, April 4, 2018 at 6:07 AM
To: Wen Lin <[email-masked]<mailto:[email-masked]>>, "Ali Sajassi (sajassi)" <[email-masked]<mailto:[email-masked]>>, "UTTARO, JAMES" <[email-masked]<mailto:[email-masked]>>, John E Drake <[email-masked]<mailto:[email-masked]>>, "Rabadan, Jorge (Nokia - US/Mountain View)" <[email-masked]<mailto:[email-masked]>>, Eric Rosen <[email-masked]<mailto:[email-masked]>>, "Satya Mohanty (satyamoh)" <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [bess] draft-mohanty-bess-evpn-bum-opt-00 - clarification on problem description

Hi Wen,

Cheers
Sandy

Thanks,
Wen

From: BESS <[email-masked]<mailto:[email-masked]>> on behalf of "Ali Sajassi (sajassi)" <[email-masked]<mailto:[email-masked]>>
Date: Monday, March 26, 2018 at 2:54 PM
To: "UTTARO, JAMES" <[email-masked]<mailto:[email-masked]>>, John E Drake <[email-masked]<mailto:[email-masked]>>, "Rabadan, Jorge (Nokia - US/Mountain View)" <[email-masked]<mailto:[email-masked]>>, Eric Rosen <[email-masked]<mailto:[email-masked]>>, Sandy Breeze <[email-masked]<mailto:[email-masked]>>, "Satya Mohanty (satyamoh)" <[email-masked]<mailto:[email-masked]>>
Cc: "Ali Sajassi (sajassi)" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [bess] draft-mohanty-bess-evpn-bum-opt-00 - clarification on problem description

Hi Jim,

Cheers,
Ali

Ali,

Thanks,
                Jim Uttaro

Cc: [email-masked]<mailto:[email-masked]>

Hi Jim,

Cheers,
Ali

Ali,

Thanks,
                Jim Uttaro

Hi Jim,

Cheers,
Ali

All,

Thanks,
                Jim Uttaro

Cheers,
Ali

Ali,

Sent from my iPhone

Hi Jorge,

Cheers,
Ali

My 2 cents.
Jorge

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Fri, 6 Apr 2018 14:50:38 +0000

Hi John,

So I must surmise that all the MAC routes are associated with the more granular virtual ESs? If so, what is the purpose of the aggregate DC ES?

Thanks,
Acee

From: BESS <[email-masked]> on behalf of John E Drake <[email-masked]>
Date: Friday, April 6, 2018 at 9:46 AM
To: Wen Lin <[email-masked]>, Sandy Breeze <[email-masked]>, "Ali Sajassi (sajassi)" <[email-masked]>, "UTTARO, JAMES" <[email-masked]>, "Rabadan, Jorge (Nokia - US)" <[email-masked]>, Eric C Rosen <[email-masked]>, "Satya Mohanty (satyamoh)" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [bess] draft-mohanty-bess-evpn-bum-opt-00 - clarification on problem description

Hi,

Yours Irrespectively,

John

From: Wen Lin

Hi Sandy,

Thanks,
Wen

Hi Wen,

Cheers
Sandy

Thanks,
Wen

Hi Jim,

Cheers,
Ali

Ali,

Thanks,
                Jim Uttaro

Hi Jim,

Cheers,
Ali

Ali,

Thanks,
                Jim Uttaro

Hi Jim,

Cheers,
Ali

All,

Thanks,
                Jim Uttaro

Cheers,
Ali

Ali,

Sent from my iPhone

Hi Jorge,

Cheers,
Ali

My 2 cents.
Jorge

---

From: John E Drake <[email-masked]>
Date: Fri, 6 Apr 2018 17:48:42 +0000

Acee,

If a DC gateway loses connectivity to the entire DC it withdraws its ES for the entire DC.  If it loses connectivity to a rack it withdraws the virtual ES for that rack.

Yours Irrespectively,

John

From: Acee Lindem (acee) <[email-masked]>
Sent: Friday, April 6, 2018 10:51 AM
To: John E Drake <[email-masked]>; Wen Lin <[email-masked]>; Sandy Breeze <[email-masked]>; Ali Sajassi (sajassi) <[email-masked]>; UTTARO, JAMES <[email-masked]>; Rabadan, Jorge (Nokia - US/Mountain View) <[email-masked]>; Eric Rosen <[email-masked]>; Satya Mohanty (satyamoh) <[email-masked]>
Cc: [email-masked]
Subject: Re: [bess] draft-mohanty-bess-evpn-bum-opt-00 - clarification on problem description

Hi John,

Thanks,
Acee

From: BESS <[email-masked]<mailto:[email-masked]>> on behalf of John E Drake <[email-masked]<mailto:[email-masked]>>
Date: Friday, April 6, 2018 at 9:46 AM
To: Wen Lin <[email-masked]<mailto:[email-masked]>>, Sandy Breeze <[email-masked]<mailto:[email-masked]>>, "Ali Sajassi (sajassi)" <[email-masked]<mailto:[email-masked]>>, "UTTARO, JAMES" <[email-masked]<mailto:[email-masked]>>, "Rabadan, Jorge (Nokia - US)" <[email-masked]<mailto:[email-masked]>>, Eric C Rosen <[email-masked]<mailto:[email-masked]>>, "Satya Mohanty (satyamoh)" <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [bess] draft-mohanty-bess-evpn-bum-opt-00 - clarification on problem description

Hi,

Yours Irrespectively,

John

From: Wen Lin
Sent: Friday, April 6, 2018 9:26 AM
To: Sandy Breeze <[email-masked]<mailto:[email-masked]>>; Ali Sajassi (sajassi) <[email-masked]<mailto:[email-masked]>>; UTTARO, JAMES <[email-masked]<mailto:[email-masked]>>; John E Drake <[email-masked]<mailto:[email-masked]>>; Rabadan, Jorge (Nokia - US/Mountain View) <[email-masked]<mailto:[email-masked]>>; Eric Rosen <[email-masked]<mailto:[email-masked]>>; Satya Mohanty (satyamoh) <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [bess] draft-mohanty-bess-evpn-bum-opt-00 - clarification on problem description

Hi Sandy,

Thanks,
Wen

Hi Wen,

Cheers
Sandy

Thanks,
Wen

Hi Jim,

Cheers,
Ali

Ali,

Thanks,
                Jim Uttaro

Hi Jim,

Cheers,
Ali

Ali,

Thanks,
                Jim Uttaro

Hi Jim,

Cheers,
Ali

All,

Thanks,
                Jim Uttaro

Cheers,
Ali

Ali,

Sent from my iPhone

Hi Jorge,

Cheers,
Ali

My 2 cents.
Jorge

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Fri, 6 Apr 2018 19:26:53 +0000

Hi John,

I can see how this would be useful. After sending the Email, I also see there is a virtual ES draft that I have not read.

Thanks,
Acee

From: John E Drake <[email-masked]>
Date: Friday, April 6, 2018 at 1:48 PM
To: Acee Lindem <[email-masked]>, Wen Lin <[email-masked]>, Sandy Breeze <[email-masked]>, "Ali Sajassi (sajassi)" <[email-masked]>, "UTTARO, JAMES" <[email-masked]>, "Rabadan, Jorge (Nokia - US)" <[email-masked]>, Eric C Rosen <[email-masked]>, "Satya Mohanty (satyamoh)" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: RE: [bess] draft-mohanty-bess-evpn-bum-opt-00 - clarification on problem description

Acee,

Yours Irrespectively,

John

Hi John,

Thanks,
Acee

Hi,

Yours Irrespectively,

John

From: Wen Lin

Hi Sandy,

Thanks,
Wen

Hi Wen,

Cheers
Sandy

Thanks,
Wen

Hi Jim,

Cheers,
Ali

Ali,

Thanks,
                Jim Uttaro

Hi Jim,

Cheers,
Ali

Ali,

Thanks,
                Jim Uttaro

Hi Jim,

Cheers,
Ali

All,

Thanks,
                Jim Uttaro

Cheers,
Ali

Ali,

Sent from my iPhone

Hi Jorge,

Cheers,
Ali

My 2 cents.
Jorge

---

From: John E Drake <[email-masked]>
Date: Fri, 6 Apr 2018 19:40:18 +0000

Acee,

The virtual ES draft was originally designed for access networks but as I mentioned, it turns out to be quite useful for DCI as well.

Yours Irrespectively,

John

From: Acee Lindem (acee) <[email-masked]>
Sent: Friday, April 6, 2018 3:27 PM
To: John E Drake <[email-masked]>; Wen Lin <[email-masked]>; Sandy Breeze <[email-masked]>; Ali Sajassi (sajassi) <[email-masked]>; UTTARO, JAMES <[email-masked]>; Rabadan, Jorge (Nokia - US/Mountain View) <[email-masked]>; Eric Rosen <[email-masked]>; Satya Mohanty (satyamoh) <[email-masked]>
Cc: [email-masked]
Subject: Re: [bess] draft-mohanty-bess-evpn-bum-opt-00 - clarification on problem description

Hi John,

Thanks,
Acee

To: Acee Lindem <[email-masked]<mailto:[email-masked]>>, Wen Lin <[email-masked]<mailto:[email-masked]>>, Sandy Breeze <[email-masked]<mailto:[email-masked]>>, "Ali Sajassi (sajassi)" <[email-masked]<mailto:[email-masked]>>, "UTTARO, JAMES" <[email-masked]<mailto:[email-masked]>>, "Rabadan, Jorge (Nokia - US)" <[email-masked]<mailto:[email-masked]>>, Eric C Rosen <[email-masked]<mailto:[email-masked]>>, "Satya Mohanty (satyamoh)" <[email-masked]<mailto:[email-masked]>>

Acee,

Yours Irrespectively,

John

From: Acee Lindem (acee) <[email-masked]<mailto:[email-masked]>>
Sent: Friday, April 6, 2018 10:51 AM
To: John E Drake <[email-masked]<mailto:[email-masked]>>; Wen Lin <[email-masked]<mailto:[email-masked]>>; Sandy Breeze <[email-masked]<mailto:[email-masked]>>; Ali Sajassi (sajassi) <[email-masked]<mailto:[email-masked]>>; UTTARO, JAMES <[email-masked]<mailto:[email-masked]>>; Rabadan, Jorge (Nokia - US/Mountain View) <[email-masked]<mailto:[email-masked]>>; Eric Rosen <[email-masked]<mailto:[email-masked]>>; Satya Mohanty (satyamoh) <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [bess] draft-mohanty-bess-evpn-bum-opt-00 - clarification on problem description

Hi John,

Thanks,
Acee

Hi,

Yours Irrespectively,

John

From: Wen Lin

Hi Sandy,

Thanks,
Wen

Hi Wen,

Cheers
Sandy

Thanks,
Wen

Hi Jim,

Cheers,
Ali

Ali,

Thanks,
                Jim Uttaro

Hi Jim,

Cheers,
Ali

Ali,

Thanks,
                Jim Uttaro

Hi Jim,

Cheers,
Ali

All,

Thanks,
                Jim Uttaro

Cheers,
Ali

Ali,

Sent from my iPhone

Hi Jorge,

Cheers,
Ali

My 2 cents.
Jorge