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

[Acee Lindem (acee)]

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 <bess-boun...@ietf.org> on behalf of John E Drake 
<jdr...@juniper.net>
Date: Friday, April 6, 2018 at 9:46 AM
To: Wen Lin <w...@juniper.net>, Sandy Breeze <sandy.bre...@eu.clara.net>, "Ali 
Sajassi (sajassi)" <saja...@cisco.com>, "UTTARO, JAMES" <ju1...@att.com>, 
"Rabadan, Jorge (Nokia - US)" <jorge.raba...@nokia.com>, Eric C Rosen 
<ero...@juniper.net>, "Satya Mohanty (satyamoh)" <satya...@cisco.com>
Cc: "bess@ietf.org" <bess@ietf.org>
Subject: Re: [bess] draft-mohanty-bess-evpn-bum-opt-00 - clarification on 
problem description

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 <sandy.bre...@eu.clara.net>; Ali Sajassi (sajassi) 
<saja...@cisco.com>; UTTARO, JAMES <ju1...@att.com>; John E Drake 
<jdr...@juniper.net>; Rabadan, Jorge (Nokia - US/Mountain View) 
<jorge.raba...@nokia.com>; Eric Rosen <ero...@juniper.net>; Satya Mohanty 
(satyamoh) <satya...@cisco.com>
Cc: bess@ietf.org
Subject: Re: [bess] draft-mohanty-bess-evpn-bum-opt-00 - clarification on 
problem description

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 <sandy.bre...@eu.clara.net<mailto:sandy.bre...@eu.clara.net>>
Date: Wednesday, April 4, 2018 at 6:07 AM
To: Wen Lin <w...@juniper.net<mailto:w...@juniper.net>>, "Ali Sajassi 
(sajassi)" <saja...@cisco.com<mailto:saja...@cisco.com>>, "UTTARO, JAMES" 
<ju1...@att.com<mailto:ju1...@att.com>>, John E Drake 
<jdr...@juniper.net<mailto:jdr...@juniper.net>>, "Rabadan, Jorge (Nokia - 
US/Mountain View)" <jorge.raba...@nokia.com<mailto:jorge.raba...@nokia.com>>, 
Eric Rosen <ero...@juniper.net<mailto:ero...@juniper.net>>, "Satya Mohanty 
(satyamoh)" <satya...@cisco.com<mailto:satya...@cisco.com>>
Cc: "bess@ietf.org<mailto:bess@ietf.org>" <bess@ietf.org<mailto:bess@ietf.org>>
Subject: Re: [bess] draft-mohanty-bess-evpn-bum-opt-00 - clarification on 
problem description

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" <w...@juniper.net<mailto:w...@juniper.net>> 
wrote:

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 <bess-boun...@ietf.org<mailto:bess-boun...@ietf.org>> on behalf of 
"Ali Sajassi (sajassi)" <saja...@cisco.com<mailto:saja...@cisco.com>>
Date: Monday, March 26, 2018 at 2:54 PM
To: "UTTARO, JAMES" <ju1...@att.com<mailto:ju1...@att.com>>, John E Drake 
<jdr...@juniper.net<mailto:jdr...@juniper.net>>, "Rabadan, Jorge (Nokia - 
US/Mountain View)" <jorge.raba...@nokia.com<mailto:jorge.raba...@nokia.com>>, 
Eric Rosen <ero...@juniper.net<mailto:ero...@juniper.net>>, Sandy Breeze 
<sandy.bre...@eu.clara.net<mailto:sandy.bre...@eu.clara.net>>, "Satya Mohanty 
(satyamoh)" <satya...@cisco.com<mailto:satya...@cisco.com>>
Cc: "Ali Sajassi (sajassi)" <saja...@cisco.com<mailto:saja...@cisco.com>>, 
"bess@ietf.org<mailto:bess@ietf.org>" <bess@ietf.org<mailto:bess@ietf.org>>
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 desc

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

[John E Drake]

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 <sandy.bre...@eu.clara.net>; Ali Sajassi (sajassi) 
<saja...@cisco.com>; UTTARO, JAMES <ju1...@att.com>; John E Drake 
<jdr...@juniper.net>; Rabadan, Jorge (Nokia - US/Mountain View) 
<jorge.raba...@nokia.com>; Eric Rosen <ero...@juniper.net>; Satya Mohanty 
(satyamoh) <satya...@cisco.com>
Cc: bess@ietf.org
Subject: Re: [bess] draft-mohanty-bess-evpn-bum-opt-00 - clarification on 
problem description

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 <sandy.bre...@eu.clara.net<mailto:sandy.bre...@eu.clara.net>>
Date: Wednesday, April 4, 2018 at 6:07 AM
To: Wen Lin <w...@juniper.net<mailto:w...@juniper.net>>, "Ali Sajassi 
(sajassi)" <saja...@cisco.com<mailto:saja...@cisco.com>>, "UTTARO, JAMES" 
<ju1...@att.com<mailto:ju1...@att.com>>, John E Drake 
<jdr...@juniper.net<mailto:jdr...@juniper.net>>, "Rabadan, Jorge (Nokia - 
US/Mountain View)" <jorge.raba...@nokia.com<mailto:jorge.raba...@nokia.com>>, 
Eric Rosen <ero...@juniper.net<mailto:ero...@juniper.net>>, "Satya Mohanty 
(satyamoh)" <satya...@cisco.com<mailto:satya...@cisco.com>>
Cc: "bess@ietf.org<mailto:bess@ietf.org>" <bess@ietf.org<mailto:bess@ietf.org>>
Subject: Re: [bess] draft-mohanty-bess-evpn-bum-opt-00 - clarification on 
problem description

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" <w...@juniper.net<mailto:w...@juniper.net>> 
wrote:

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 <bess-boun...@ietf.org<mailto:bess-boun...@ietf.org>> on behalf of 
"Ali Sajassi (sajassi)" <saja...@cisco.com<mailto:saja...@cisco.com>>
Date: Monday, March 26, 2018 at 2:54 PM
To: "UTTARO, JAMES" <ju1...@att.com<mailto:ju1...@att.com>>, John E Drake 
<jdr...@juniper.net<mailto:jdr...@juniper.net>>, "Rabadan, Jorge (Nokia - 
US/Mountain View)" <jorge.raba...@nokia.com<mailto:jorge.raba...@nokia.com>>, 
Eric Rosen <ero...@juniper.net<mailto:ero...@juniper.net>>, Sandy Breeze 
<sandy.bre...@eu.clara.net<mailto:sandy.bre...@eu.clara.net>>, "Satya Mohanty 
(satyamoh)" <satya...@cisco.com<mailto:satya...@cisco.com>>
Cc: "Ali Sajassi (sajassi)" <saja...@cisco.com<mailto:saja...@cisco.com>>, 
"bess@ietf.org<mailto:bess@ietf.org>" <bess@ietf.org<mailto:bess@ietf.org>>
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" <ju1...@att.com<mailto:ju1...@att.com>>
Date: Monday, March 26, 2018 at 10:46 AM
To: Cisco Employee <saja...@cisco.com<mailto:saja...@cisco.com>>, John E Drake 
<jdr...@junipe

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

[Wen Lin]

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 <sandy.bre...@eu.clara.net>
Date: Wednesday, April 4, 2018 at 6:07 AM
To: Wen Lin <w...@juniper.net>, "Ali Sajassi (sajassi)" <saja...@cisco.com>, 
"UTTARO, JAMES" <ju1...@att.com>, John E Drake <jdr...@juniper.net>, "Rabadan, 
Jorge (Nokia - US/Mountain View)" <jorge.raba...@nokia.com>, Eric Rosen 
<ero...@juniper.net>, "Satya Mohanty (satyamoh)" <satya...@cisco.com>
Cc: "bess@ietf.org" <bess@ietf.org>
Subject: Re: [bess] draft-mohanty-bess-evpn-bum-opt-00 - clarification on 
problem description

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" <w...@juniper.net<mailto:w...@juniper.net>> 
wrote:

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 <bess-boun...@ietf.org> on behalf of "Ali Sajassi (sajassi)" 
<saja...@cisco.com>
Date: Monday, March 26, 2018 at 2:54 PM
To: "UTTARO, JAMES" <ju1...@att.com>, John E Drake <jdr...@juniper.net>, 
"Rabadan, Jorge (Nokia - US/Mountain View)" <jorge.raba...@nokia.com>, Eric 
Rosen <ero...@juniper.net>, Sandy Breeze <sandy.bre...@eu.clara.net>, "Satya 
Mohanty (satyamoh)" <satya...@cisco.com>
Cc: "Ali Sajassi (sajassi)" <saja...@cisco.com>, "bess@ietf.org" <bess@ietf.org>
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" <ju1...@att.com>
Date: Monday, March 26, 2018 at 10:46 AM
To: Cisco Employee <saja...@cisco.com>, John E Drake <jdr...@juniper.net>, 
"Rabadan, Jorge (Nokia - US/Mountain View)" <jorge.raba...@nokia.com>, Eric 
Rosen <ero...@juniper.net>, Sandy Breeze <sandy.bre...@eu.clara.net>, "Satya 
Mohanty (satyamoh)" <satya...@cisco.com>
Cc: "bess@ietf.org" <bess@ietf.org>
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:saja...@cisco.com]
Sent: Monday, March 26, 2018 1:20 PM
To: UTTARO, JAMES <ju1...@att.com>; John E Drake <jdr...@juniper.net>; Rabadan, 
Jorge (Nokia - US/Mountain View) <jorge.raba...@nokia.com>; Eric Rosen 
<ero...@juniper.net>; Sandy Breeze <sandy.bre...@eu.clara.net>; Satya Mohanty 
(satyamoh) <satya...@cisco.com>
Cc: bess@ietf.org
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" <ju1...@att.com<mailto:ju1...@att.com>>
Date: Monday, March 26, 2018 at 10:03 AM
To: Cisco Emp

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

[Sandy Breeze]

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" <w...@juniper.net<mailto:w...@juniper.net>> 
wrote:

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 <bess-boun...@ietf.org> on behalf of "Ali Sajassi (sajassi)" 
<saja...@cisco.com>
Date: Monday, March 26, 2018 at 2:54 PM
To: "UTTARO, JAMES" <ju1...@att.com>, John E Drake <jdr...@juniper.net>, 
"Rabadan, Jorge (Nokia - US/Mountain View)" <jorge.raba...@nokia.com>, Eric 
Rosen <ero...@juniper.net>, Sandy Breeze <sandy.bre...@eu.clara.net>, "Satya 
Mohanty (satyamoh)" <satya...@cisco.com>
Cc: "Ali Sajassi (sajassi)" <saja...@cisco.com>, "bess@ietf.org" <bess@ietf.org>
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" <ju1...@att.com>
Date: Monday, March 26, 2018 at 10:46 AM
To: Cisco Employee <saja...@cisco.com>, John E Drake <jdr...@juniper.net>, 
"Rabadan, Jorge (Nokia - US/Mountain View)" <jorge.raba...@nokia.com>, Eric 
Rosen <ero...@juniper.net>, Sandy Breeze <sandy.bre...@eu.clara.net>, "Satya 
Mohanty (satyamoh)" <satya...@cisco.com>
Cc: "bess@ietf.org" <bess@ietf.org>
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:saja...@cisco.com]
Sent: Monday, March 26, 2018 1:20 PM
To: UTTARO, JAMES <ju1...@att.com>; John E Drake <jdr...@juniper.net>; Rabadan, 
Jorge (Nokia - US/Mountain View) <jorge.raba...@nokia.com>; Eric Rosen 
<ero...@juniper.net>; Sandy Breeze <sandy.bre...@eu.clara.net>; Satya Mohanty 
(satyamoh) <satya...@cisco.com>
Cc: bess@ietf.org
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" <ju1...@att.com<mailto:ju1...@att.com>>
Date: Monday, March 26, 2018 at 10:03 AM
To: Cisco Employee <saja...@cisco.com<mailto:saja...@cisco.com>>, John E Drake 
<jdr...@juniper.net<mailto:jdr...@juniper.net>>, "Rabadan, Jorge (Nokia - 
US/Mountain View)" <jorge.raba...@nokia.com<mailto:jorge.raba...@nokia.com>>, 
Eric Rosen <ero...@juniper.net<mailto:ero...@juniper.net>>, Sandy Breeze 
<sandy.bre...@eu.clara.net<mailto:sandy.bre...@eu.clara.net>>, "Satya Mohanty 
(satyamoh)" <satya...@cisco.com<mailto:satya...@cisco.com>>
Cc: "bess@ietf.org<mailto:bess@ietf.org>" <bess@ietf.org<mailto:bess@ietf.org>>
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:saja...@cisco.co

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

[Wen Lin]

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 <bess-boun...@ietf.org> on behalf of "Ali Sajassi (sajassi)" 
<saja...@cisco.com>
Date: Monday, March 26, 2018 at 2:54 PM
To: "UTTARO, JAMES" <ju1...@att.com>, John E Drake <jdr...@juniper.net>, 
"Rabadan, Jorge (Nokia - US/Mountain View)" <jorge.raba...@nokia.com>, Eric 
Rosen <ero...@juniper.net>, Sandy Breeze <sandy.bre...@eu.clara.net>, "Satya 
Mohanty (satyamoh)" <satya...@cisco.com>
Cc: "Ali Sajassi (sajassi)" <saja...@cisco.com>, "bess@ietf.org" <bess@ietf.org>
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" <ju1...@att.com>
Date: Monday, March 26, 2018 at 10:46 AM
To: Cisco Employee <saja...@cisco.com>, John E Drake <jdr...@juniper.net>, 
"Rabadan, Jorge (Nokia - US/Mountain View)" <jorge.raba...@nokia.com>, Eric 
Rosen <ero...@juniper.net>, Sandy Breeze <sandy.bre...@eu.clara.net>, "Satya 
Mohanty (satyamoh)" <satya...@cisco.com>
Cc: "bess@ietf.org" <bess@ietf.org>
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:saja...@cisco.com]
Sent: Monday, March 26, 2018 1:20 PM
To: UTTARO, JAMES <ju1...@att.com>; John E Drake <jdr...@juniper.net>; Rabadan, 
Jorge (Nokia - US/Mountain View) <jorge.raba...@nokia.com>; Eric Rosen 
<ero...@juniper.net>; Sandy Breeze <sandy.bre...@eu.clara.net>; Satya Mohanty 
(satyamoh) <satya...@cisco.com>
Cc: bess@ietf.org
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" <ju1...@att.com<mailto:ju1...@att.com>>
Date: Monday, March 26, 2018 at 10:03 AM
To: Cisco Employee <saja...@cisco.com<mailto:saja...@cisco.com>>, John E Drake 
<jdr...@juniper.net<mailto:jdr...@juniper.net>>, "Rabadan, Jorge (Nokia - 
US/Mountain View)" <jorge.raba...@nokia.com<mailto:jorge.raba...@nokia.com>>, 
Eric Rosen <ero...@juniper.net<mailto:ero...@juniper.net>>, Sandy Breeze 
<sandy.bre...@eu.clara.net<mailto:sandy.bre...@eu.clara.net>>, "Satya Mohanty 
(satyamoh)" <satya...@cisco.com<mailto:satya...@cisco.com>>
Cc: "bess@ietf.org<mailto:bess@ietf.org>" <bess@ietf.org<mailto:bess@ietf.org>>
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:saja...@cisco.com]
Sent: Monday, March 26, 2018 11:55 AM
To: UTTARO, JAMES <ju1...@att.com<mailto:ju1...@att.com>>; John E Drake 
<jdr...@juniper.net<mailto:jdr...@juniper.net>>; Rabadan, Jorge (Nokia - 
US/Mountain View) <jorge.raba...@nokia.com<mailto:jorge.raba...@nokia.com>>; 
Eric Rosen <ero...@juniper.net<mailto:ero...@juniper.net>>; Sandy Breeze 
<sandy.bre...@eu.clara.net<mailto:sandy.bre...@eu.clara.net>>; Satya Mohanty 
(satyamoh) <satya...@cisco.com<mailto:satya...@cisco.com>>
Cc: bess@ietf.org<mailto:bess@ietf.org

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

[UTTARO, JAMES]

Mankamana,

If not a requirements draft than a usage draft indicating what 
solutions are applicable for the different inter-connect solutions. I think 
this would be quite useful to architects/designers..

Thanks,
Jim Uttaro

From: Mankamana Mishra (mankamis) [mailto:manka...@cisco.com]
Sent: Tuesday, March 27, 2018 11:32 AM
To: UTTARO, JAMES <ju1...@att.com>; John E Drake <jdr...@juniper.net>; Rabadan, 
Jorge (Nokia - US/Mountain View) <jorge.raba...@nokia.com>; Eric Rosen 
<ero...@juniper.net>; Sandy Breeze <sandy.bre...@eu.clara.net>; Satya Mohanty 
(satyamoh) <satya...@cisco.com>
Cc: bess@ietf.org; Ali Sajassi (sajassi) <saja...@cisco.com>
Subject: Re: [bess] draft-mohanty-bess-evpn-bum-opt-00 - clarification on 
problem description

Hi Jim,
About your pointing of writing down requirement draft for multicast. I had 
discussion with Ali in this IETF (After we discussed). But looks like it might 
be too late for now to write requirement, as there are many multicast related 
solution draft already in BESS working group.  But still if majority thinks we 
need it. We can think about it.

Thanks
Mankamana

From: BESS <bess-boun...@ietf.org<mailto:bess-boun...@ietf.org>> on behalf of 
"UTTARO, JAMES" <ju1...@att.com<mailto:ju1...@att.com>>
Date: Monday, March 26, 2018 at 10:46 AM
To: "Ali Sajassi (sajassi)" <saja...@cisco.com<mailto:saja...@cisco.com>>, John 
E Drake <jdr...@juniper.net<mailto:jdr...@juniper.net>>, "Rabadan, Jorge (Nokia 
- US/Mountain View)" <jorge.raba...@nokia.com<mailto:jorge.raba...@nokia.com>>, 
Eric Rosen <ero...@juniper.net<mailto:ero...@juniper.net>>, Sandy Breeze 
<sandy.bre...@eu.clara.net<mailto:sandy.bre...@eu.clara.net>>, "Satya Mohanty 
(satyamoh)" <satya...@cisco.com<mailto:satya...@cisco.com>>
Cc: "bess@ietf.org<mailto:bess@ietf.org>" <bess@ietf.org<mailto:bess@ietf.org>>
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:saja...@cisco.com]
Sent: Monday, March 26, 2018 1:20 PM
To: UTTARO, JAMES <ju1...@att.com<mailto:ju1...@att.com>>; John E Drake 
<jdr...@juniper.net<mailto:jdr...@juniper.net>>; Rabadan, Jorge (Nokia - 
US/Mountain View) <jorge.raba...@nokia.com<mailto:jorge.raba...@nokia.com>>; 
Eric Rosen <ero...@juniper.net<mailto:ero...@juniper.net>>; Sandy Breeze 
<sandy.bre...@eu.clara.net<mailto:sandy.bre...@eu.clara.net>>; Satya Mohanty 
(satyamoh) <satya...@cisco.com<mailto:satya...@cisco.com>>
Cc: bess@ietf.org<mailto:bess@ietf.org>
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" <ju1...@att.com<mailto:ju1...@att.com>>
Date: Monday, March 26, 2018 at 10:03 AM
To: Cisco Employee <saja...@cisco.com<mailto:saja...@cisco.com>>, John E Drake 
<jdr...@juniper.net<mailto:jdr...@juniper.net>>, "Rabadan, Jorge (Nokia - 
US/Mountain View)" <jorge.raba...@nokia.com<mailto:jorge.raba...@nokia.com>>, 
Eric Rosen <ero...@juniper.net<mailto:ero...@juniper.net>>, Sandy Breeze 
<sandy.bre...@eu.clara.net<mailto:sandy.bre...@eu.clara.net>>, "Satya Mohanty 
(satyamoh)" <satya...@cisco.com<mailto:satya...@cisco.com>>
Cc: "bess@ietf.org<mailto:bess@ietf.org>" <bess@ietf.org<mailto:bess@ietf.org>>
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:saja...@cisco.com]
Sent: Monday, March 26, 2018 11:55 AM
To: UTTARO, JAMES <ju1...@att.com<mailto:ju1...@att.com>>; John E Drake 
<jdr...@juniper.net<mailto:jdr...@juniper.net>>; Rabadan, Jorge (Nokia - 
US/Mountain View) <jorge.raba...@nokia.com<mailto:jorge.raba...@nokia.com>>; 
Eric Rosen <ero...@juniper.net<mailto:ero...@juniper.net>>; Sandy Breeze 
<sandy.bre...@eu.clara.net<mailto:sandy.bre...@eu.clara.net>>; Satya Mohanty 
(s

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

[Mankamana Mishra (mankamis)]

Hi Jim,
About your pointing of writing down requirement draft for multicast. I had 
discussion with Ali in this IETF (After we discussed). But looks like it might 
be too late for now to write requirement, as there are many multicast related 
solution draft already in BESS working group.  But still if majority thinks we 
need it. We can think about it.

Thanks
Mankamana

From: BESS <bess-boun...@ietf.org> on behalf of "UTTARO, JAMES" <ju1...@att.com>
Date: Monday, March 26, 2018 at 10:46 AM
To: "Ali Sajassi (sajassi)" <saja...@cisco.com>, John E Drake 
<jdr...@juniper.net>, "Rabadan, Jorge (Nokia - US/Mountain View)" 
<jorge.raba...@nokia.com>, Eric Rosen <ero...@juniper.net>, Sandy Breeze 
<sandy.bre...@eu.clara.net>, "Satya Mohanty (satyamoh)" <satya...@cisco.com>
Cc: "bess@ietf.org" <bess@ietf.org>
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:saja...@cisco.com]
Sent: Monday, March 26, 2018 1:20 PM
To: UTTARO, JAMES <ju1...@att.com>; John E Drake <jdr...@juniper.net>; Rabadan, 
Jorge (Nokia - US/Mountain View) <jorge.raba...@nokia.com>; Eric Rosen 
<ero...@juniper.net>; Sandy Breeze <sandy.bre...@eu.clara.net>; Satya Mohanty 
(satyamoh) <satya...@cisco.com>
Cc: bess@ietf.org
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" <ju1...@att.com<mailto:ju1...@att.com>>
Date: Monday, March 26, 2018 at 10:03 AM
To: Cisco Employee <saja...@cisco.com<mailto:saja...@cisco.com>>, John E Drake 
<jdr...@juniper.net<mailto:jdr...@juniper.net>>, "Rabadan, Jorge (Nokia - 
US/Mountain View)" <jorge.raba...@nokia.com<mailto:jorge.raba...@nokia.com>>, 
Eric Rosen <ero...@juniper.net<mailto:ero...@juniper.net>>, Sandy Breeze 
<sandy.bre...@eu.clara.net<mailto:sandy.bre...@eu.clara.net>>, "Satya Mohanty 
(satyamoh)" <satya...@cisco.com<mailto:satya...@cisco.com>>
Cc: "bess@ietf.org<mailto:bess@ietf.org>" <bess@ietf.org<mailto:bess@ietf.org>>
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:saja...@cisco.com]
Sent: Monday, March 26, 2018 11:55 AM
To: UTTARO, JAMES <ju1...@att.com<mailto:ju1...@att.com>>; John E Drake 
<jdr...@juniper.net<mailto:jdr...@juniper.net>>; Rabadan, Jorge (Nokia - 
US/Mountain View) <jorge.raba...@nokia.com<mailto:jorge.raba...@nokia.com>>; 
Eric Rosen <ero...@juniper.net<mailto:ero...@juniper.net>>; Sandy Breeze 
<sandy.bre...@eu.clara.net<mailto:sandy.bre...@eu.clara.net>>; Satya Mohanty 
(satyamoh) <satya...@cisco.com<mailto:satya...@cisco.com>>
Cc: bess@ietf.org<mailto:bess@ietf.org>; Ali Sajassi (sajassi) 
<saja...@cisco.com<mailto:saja...@cisco.com>>
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=DwMGaQ=LFYZ-o9_HUMeMTSQicvjIg=3qhKphE8RnwJQ6u8MrAGeA=9SAgBpjkWp7kuXpNCFnHc0yYR4z5MDVrwDCLAD0vsGE=Ek3T8FismWFOPCcpsLXCVErB9uzwJ3Y1w9N_553cDtE=>
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=DwMGaQ=LFYZ-o9_HUMeMTSQicvjIg=3qhKphE8RnwJQ6u8MrAGeA=9SAgBpjkWp7kuXpNCFnHc0yYR4z5MDVrwDCLAD0vsGE=YtlZmFFol1NiX2LvH9SsVJuAZks-JdhzptPE0JZOdeU=>

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" <ju1...@att.com<mailto:ju1...@att.com>>
Date: Monday, March 26, 2018 at 6:25 AM
To: Cisco Employee <saja...@cisco.c

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

[Satya Mohanty (satyamoh)]

Hi John,

We will take your feedback into account.

Thanks,
—Satya

From: "jdr...@juniper.net<mailto:jdr...@juniper.net>" 
<jdr...@juniper.net<mailto:jdr...@juniper.net>>
Date: Monday, March 26, 2018 at 6:00 AM
To: satyamoh <satya...@cisco.com<mailto:satya...@cisco.com>>, Sandy Breeze 
<sandy.bre...@eu.clara.net<mailto:sandy.bre...@eu.clara.net>>, "Rabadan, Jorge 
(Nokia - US/Mountain View)" 
<jorge.raba...@nokia.com<mailto:jorge.raba...@nokia.com>>, Eric Rosen 
<ero...@juniper.net<mailto:ero...@juniper.net>>, 
"bess@ietf.org<mailto:bess@ietf.org>" <bess@ietf.org<mailto:bess@ietf.org>>
Subject: RE: [bess] draft-mohanty-bess-evpn-bum-opt-00 - clarification on 
problem description

Satya,

Comment inline.

Yours Irrespectively,

John


[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=DwMGaQ=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI=-DXB84eU9m4cIlq2OOcCJCQQAwJXQQswyu3F0kG0VNo=rs8r_tXnIDIv9e5NNgiXOy5yYuE10r6x9al8H6FgK04=V42kiY3ngmDNxMKmk5GgHmy9LcMGdOXpcvbereFtUR8=>)
 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.
[Sandy] We discussed the use of extended community to signal NDF, this is 
indeed a viable alternative approach and one we’re not against.  We didn’t 
choose it over not sending IMET because we don’t have a good reason why not 
sending IMET at an NDF is actually a bad idea, for our use case.  That said, if 
the consensus of this list is to use an extended community then a flag in EVPN 
extended community sub-types registry is a possible fit
[Satya] Just to make clear, the Multicast Flags extended community is only sent 
with the IMET when IGMP proxy is supported. If the BD does not support 
IGMP/MLD, then this won’t work as Jorge pointed out earlier (BUM with IR only). 
Perhaps, if there  were available flag fields in the PMSI Tunnel attr, one 
could have used it. Also, creation of a new extended community for the purpose 
of this optimization looks to me to be adding extra complexity to the CP. So we 
did not prefer doing that. Setting the label to 0 would have worked, but the 
value 0 now has the semantics that Sandy points out below.

[JD]  I don’t think this is correct.  The IGMP Proxy draft defines the 
Multicast Flags extended community, which means that your draft would need to 
have a normative reference to that draft.  However, your draft would be free to 
define a new bit in the extended community and indicate that support for the 
that bit is not contingent upon support for the IGMP Proxy draft.


___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

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

[Ali Sajassi (sajassi)]

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" <ju1...@att.com>
Date: Monday, March 26, 2018 at 10:46 AM
To: Cisco Employee <saja...@cisco.com>, John E Drake <jdr...@juniper.net>, 
"Rabadan, Jorge (Nokia - US/Mountain View)" <jorge.raba...@nokia.com>, Eric 
Rosen <ero...@juniper.net>, Sandy Breeze <sandy.bre...@eu.clara.net>, "Satya 
Mohanty (satyamoh)" <satya...@cisco.com>
Cc: "bess@ietf.org" <bess@ietf.org>
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:saja...@cisco.com]
Sent: Monday, March 26, 2018 1:20 PM
To: UTTARO, JAMES <ju1...@att.com>; John E Drake <jdr...@juniper.net>; Rabadan, 
Jorge (Nokia - US/Mountain View) <jorge.raba...@nokia.com>; Eric Rosen 
<ero...@juniper.net>; Sandy Breeze <sandy.bre...@eu.clara.net>; Satya Mohanty 
(satyamoh) <satya...@cisco.com>
Cc: bess@ietf.org
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" <ju1...@att.com<mailto:ju1...@att.com>>
Date: Monday, March 26, 2018 at 10:03 AM
To: Cisco Employee <saja...@cisco.com<mailto:saja...@cisco.com>>, John E Drake 
<jdr...@juniper.net<mailto:jdr...@juniper.net>>, "Rabadan, Jorge (Nokia - 
US/Mountain View)" <jorge.raba...@nokia.com<mailto:jorge.raba...@nokia.com>>, 
Eric Rosen <ero...@juniper.net<mailto:ero...@juniper.net>>, Sandy Breeze 
<sandy.bre...@eu.clara.net<mailto:sandy.bre...@eu.clara.net>>, "Satya Mohanty 
(satyamoh)" <satya...@cisco.com<mailto:satya...@cisco.com>>
Cc: "bess@ietf.org<mailto:bess@ietf.org>" <bess@ietf.org<mailto:bess@ietf.org>>
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:saja...@cisco.com]
Sent: Monday, March 26, 2018 11:55 AM
To: UTTARO, JAMES <ju1...@att.com<mailto:ju1...@att.com>>; John E Drake 
<jdr...@juniper.net<mailto:jdr...@juniper.net>>; Rabadan, Jorge (Nokia - 
US/Mountain View) <jorge.raba...@nokia.com<mailto:jorge.raba...@nokia.com>>; 
Eric Rosen <ero...@juniper.net<mailto:ero...@juniper.net>>; Sandy Breeze 
<sandy.bre...@eu.clara.net<mailto:sandy.bre...@eu.clara.net>>; Satya Mohanty 
(satyamoh) <satya...@cisco.com<mailto:satya...@cisco.com>>
Cc: bess@ietf.org<mailto:bess@ietf.org>; Ali Sajassi (sajassi) 
<saja...@cisco.com<mailto:saja...@cisco.com>>
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=DwMGaQ=LFYZ-o9_HUMeMTSQicvjIg=3qhKphE8RnwJQ6u8MrAGeA=9SAgBpjkWp7kuXpNCFnHc0yYR4z5MDVrwDCLAD0vsGE=Ek3T8FismWFOPCcpsLXCVErB9uzwJ3Y1w9N_553cDtE=>
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=DwMGaQ=LFYZ-o9_HUMeMTSQicvjIg=3qhKphE8RnwJQ6u8MrAGeA=9SAgBpjkWp7kuXpNCFnHc0yYR4z5MDVrwDCLAD0vsGE=YtlZmFFol1NiX2LvH9SsVJuAZks-JdhzptPE0JZOdeU=>

I will update my draft to address Eric’s comment

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

[UTTARO, JAMES]

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:saja...@cisco.com]
Sent: Monday, March 26, 2018 1:20 PM
To: UTTARO, JAMES <ju1...@att.com>; John E Drake <jdr...@juniper.net>; Rabadan, 
Jorge (Nokia - US/Mountain View) <jorge.raba...@nokia.com>; Eric Rosen 
<ero...@juniper.net>; Sandy Breeze <sandy.bre...@eu.clara.net>; Satya Mohanty 
(satyamoh) <satya...@cisco.com>
Cc: bess@ietf.org
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" <ju1...@att.com<mailto:ju1...@att.com>>
Date: Monday, March 26, 2018 at 10:03 AM
To: Cisco Employee <saja...@cisco.com<mailto:saja...@cisco.com>>, John E Drake 
<jdr...@juniper.net<mailto:jdr...@juniper.net>>, "Rabadan, Jorge (Nokia - 
US/Mountain View)" <jorge.raba...@nokia.com<mailto:jorge.raba...@nokia.com>>, 
Eric Rosen <ero...@juniper.net<mailto:ero...@juniper.net>>, Sandy Breeze 
<sandy.bre...@eu.clara.net<mailto:sandy.bre...@eu.clara.net>>, "Satya Mohanty 
(satyamoh)" <satya...@cisco.com<mailto:satya...@cisco.com>>
Cc: "bess@ietf.org<mailto:bess@ietf.org>" <bess@ietf.org<mailto:bess@ietf.org>>
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:saja...@cisco.com]
Sent: Monday, March 26, 2018 11:55 AM
To: UTTARO, JAMES <ju1...@att.com<mailto:ju1...@att.com>>; John E Drake 
<jdr...@juniper.net<mailto:jdr...@juniper.net>>; Rabadan, Jorge (Nokia - 
US/Mountain View) <jorge.raba...@nokia.com<mailto:jorge.raba...@nokia.com>>; 
Eric Rosen <ero...@juniper.net<mailto:ero...@juniper.net>>; Sandy Breeze 
<sandy.bre...@eu.clara.net<mailto:sandy.bre...@eu.clara.net>>; Satya Mohanty 
(satyamoh) <satya...@cisco.com<mailto:satya...@cisco.com>>
Cc: bess@ietf.org<mailto:bess@ietf.org>; Ali Sajassi (sajassi) 
<saja...@cisco.com<mailto:saja...@cisco.com>>
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=DwMGaQ=LFYZ-o9_HUMeMTSQicvjIg=3qhKphE8RnwJQ6u8MrAGeA=9SAgBpjkWp7kuXpNCFnHc0yYR4z5MDVrwDCLAD0vsGE=Ek3T8FismWFOPCcpsLXCVErB9uzwJ3Y1w9N_553cDtE=>
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=DwMGaQ=LFYZ-o9_HUMeMTSQicvjIg=3qhKphE8RnwJQ6u8MrAGeA=9SAgBpjkWp7kuXpNCFnHc0yYR4z5MDVrwDCLAD0vsGE=YtlZmFFol1NiX2LvH9SsVJuAZks-JdhzptPE0JZOdeU=>

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" <ju1...@att.com<mailto:ju1...@att.com>>
Date: Monday, March 26, 2018 at 6:25 AM
To: Cisco Employee <saja...@cisco.com<mailto:saja...@cisco.com>>, John E Drake 
<jdr...@juniper.net<mailto:jdr...@juniper.net>>, "Rabadan, Jorge (Nokia - 
US/Mountain View)" <jorge.raba...@nokia.com<mailto:jorge.raba...@nokia.com>>, 
Eric Rosen <ero...@juniper.net<mailto:ero...@juniper.net>>, Sandy Breeze 
<sandy.bre...@eu.clara.net<mailto:sandy.bre...@eu.clara.net>>, "Satya Mohanty 
(satyamoh)" <satya...@cisco.com<mailto:satya...@cisco.com>>
Cc: "bess@ietf.org<mailto:bess@ietf.org>" <bess@ietf.org<mailto:bess@ietf.org>>
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:bess-boun...@ietf.org] On Behalf Of Ali Sajassi (sajassi)
Sent: Monday, March 26, 2018 12:54 AM
To: John E

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

[Ali Sajassi (sajassi)]

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" <ju1...@att.com>
Date: Monday, March 26, 2018 at 10:03 AM
To: Cisco Employee <saja...@cisco.com>, John E Drake <jdr...@juniper.net>, 
"Rabadan, Jorge (Nokia - US/Mountain View)" <jorge.raba...@nokia.com>, Eric 
Rosen <ero...@juniper.net>, Sandy Breeze <sandy.bre...@eu.clara.net>, "Satya 
Mohanty (satyamoh)" <satya...@cisco.com>
Cc: "bess@ietf.org" <bess@ietf.org>
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:saja...@cisco.com]
Sent: Monday, March 26, 2018 11:55 AM
To: UTTARO, JAMES <ju1...@att.com>; John E Drake <jdr...@juniper.net>; Rabadan, 
Jorge (Nokia - US/Mountain View) <jorge.raba...@nokia.com>; Eric Rosen 
<ero...@juniper.net>; Sandy Breeze <sandy.bre...@eu.clara.net>; Satya Mohanty 
(satyamoh) <satya...@cisco.com>
Cc: bess@ietf.org; Ali Sajassi (sajassi) <saja...@cisco.com>
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=DwMGaQ=LFYZ-o9_HUMeMTSQicvjIg=3qhKphE8RnwJQ6u8MrAGeA=9SAgBpjkWp7kuXpNCFnHc0yYR4z5MDVrwDCLAD0vsGE=Ek3T8FismWFOPCcpsLXCVErB9uzwJ3Y1w9N_553cDtE=>
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=DwMGaQ=LFYZ-o9_HUMeMTSQicvjIg=3qhKphE8RnwJQ6u8MrAGeA=9SAgBpjkWp7kuXpNCFnHc0yYR4z5MDVrwDCLAD0vsGE=YtlZmFFol1NiX2LvH9SsVJuAZks-JdhzptPE0JZOdeU=>

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" <ju1...@att.com<mailto:ju1...@att.com>>
Date: Monday, March 26, 2018 at 6:25 AM
To: Cisco Employee <saja...@cisco.com<mailto:saja...@cisco.com>>, John E Drake 
<jdr...@juniper.net<mailto:jdr...@juniper.net>>, "Rabadan, Jorge (Nokia - 
US/Mountain View)" <jorge.raba...@nokia.com<mailto:jorge.raba...@nokia.com>>, 
Eric Rosen <ero...@juniper.net<mailto:ero...@juniper.net>>, Sandy Breeze 
<sandy.bre...@eu.clara.net<mailto:sandy.bre...@eu.clara.net>>, "Satya Mohanty 
(satyamoh)" <satya...@cisco.com<mailto:satya...@cisco.com>>
Cc: "bess@ietf.org<mailto:bess@ietf.org>" <bess@ietf.org<mailto:bess@ietf.org>>
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:bess-boun...@ietf.org] On Behalf Of Ali Sajassi (sajassi)
Sent: Monday, March 26, 2018 12:54 AM
To: John E Drake <jdr...@juniper.net<mailto:jdr...@juniper.net>>; Rabadan, 
Jorge (Nokia - US/Mountain View) 
<jorge.raba...@nokia.com<mailto:jorge.raba...@nokia.com>>; Eric Rosen 
<ero...@juniper.net<mailto:ero...@juniper.net>>; Sandy Breeze 
<sandy.bre...@eu.clara.net<mailto:sandy.bre...@eu.clara.net>>; Satya Mohanty 
(satyamoh) <satya...@cisco.com<mailto:satya...@cisco.com>>
Cc: Ali Sajassi (sajassi) <saja...@cisco.com<mailto:saja...@cisco.com>>; 
bess@ietf.org<mailto:bess@ietf.org>
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:
 *   Enable DF election on per mcast flow – this gives the best 
load-balancing for DF election among multicast flows and avoids FAT VLAN issue
 *   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,

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

[UTTARO, JAMES]

Ali,

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

Thanks,
Jim Uttaro


From: Ali Sajassi (sajassi) [mailto:saja...@cisco.com]
Sent: Monday, March 26, 2018 11:55 AM
To: UTTARO, JAMES <ju1...@att.com>; John E Drake <jdr...@juniper.net>; Rabadan, 
Jorge (Nokia - US/Mountain View) <jorge.raba...@nokia.com>; Eric Rosen 
<ero...@juniper.net>; Sandy Breeze <sandy.bre...@eu.clara.net>; Satya Mohanty 
(satyamoh) <satya...@cisco.com>
Cc: bess@ietf.org; Ali Sajassi (sajassi) <saja...@cisco.com>
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=DwMGaQ=LFYZ-o9_HUMeMTSQicvjIg=3qhKphE8RnwJQ6u8MrAGeA=9SAgBpjkWp7kuXpNCFnHc0yYR4z5MDVrwDCLAD0vsGE=Ek3T8FismWFOPCcpsLXCVErB9uzwJ3Y1w9N_553cDtE=>
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=DwMGaQ=LFYZ-o9_HUMeMTSQicvjIg=3qhKphE8RnwJQ6u8MrAGeA=9SAgBpjkWp7kuXpNCFnHc0yYR4z5MDVrwDCLAD0vsGE=YtlZmFFol1NiX2LvH9SsVJuAZks-JdhzptPE0JZOdeU=>

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" <ju1...@att.com<mailto:ju1...@att.com>>
Date: Monday, March 26, 2018 at 6:25 AM
To: Cisco Employee <saja...@cisco.com<mailto:saja...@cisco.com>>, John E Drake 
<jdr...@juniper.net<mailto:jdr...@juniper.net>>, "Rabadan, Jorge (Nokia - 
US/Mountain View)" <jorge.raba...@nokia.com<mailto:jorge.raba...@nokia.com>>, 
Eric Rosen <ero...@juniper.net<mailto:ero...@juniper.net>>, Sandy Breeze 
<sandy.bre...@eu.clara.net<mailto:sandy.bre...@eu.clara.net>>, "Satya Mohanty 
(satyamoh)" <satya...@cisco.com<mailto:satya...@cisco.com>>
Cc: "bess@ietf.org<mailto:bess@ietf.org>" <bess@ietf.org<mailto:bess@ietf.org>>
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:bess-boun...@ietf.org] On Behalf Of Ali Sajassi (sajassi)
Sent: Monday, March 26, 2018 12:54 AM
To: John E Drake <jdr...@juniper.net<mailto:jdr...@juniper.net>>; Rabadan, 
Jorge (Nokia - US/Mountain View) 
<jorge.raba...@nokia.com<mailto:jorge.raba...@nokia.com>>; Eric Rosen 
<ero...@juniper.net<mailto:ero...@juniper.net>>; Sandy Breeze 
<sandy.bre...@eu.clara.net<mailto:sandy.bre...@eu.clara.net>>; Satya Mohanty 
(satyamoh) <satya...@cisco.com<mailto:satya...@cisco.com>>
Cc: Ali Sajassi (sajassi) <saja...@cisco.com<mailto:saja...@cisco.com>>; 
bess@ietf.org<mailto:bess@ietf.org>
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 <jdr...@juniper.net<mailto:jdr...@juniper.net>>
Date: Sunday, March 25, 2018 at 9:57 AM
To: Cisco Employee <saja...@cisco.com<mailto:saja...@cisco.com>>
Cc: "Rabadan, Jorge (Nokia - US/Mountain View)" 
<jorge.raba...@nokia.com<mailto:jorge.raba...@nokia.com>>, Eric Rosen 
<ero...@juniper.net<mailto:ero...@juniper.net>>, Sandy Breeze 
<sandy.bre...@eu.clara.net<mailto:sandy.bre...@eu.clara.net>>, 
"bess@ietf.org<mailto:bess@ietf.org>" <bess@ietf.org<mailto:bess@ietf.org>>
Subject: Re: [bess] draft-mohanty-bess-evpn-bum-opt-00 - clarification on 
problem description

Ali,

I don'

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

[Ali Sajassi (sajassi)]

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://tools.ietf.org/html/draft-sajassi-bess-evpn-mvpn-seamless-interop-00

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" <ju1...@att.com>
Date: Monday, March 26, 2018 at 6:25 AM
To: Cisco Employee <saja...@cisco.com>, John E Drake <jdr...@juniper.net>, 
"Rabadan, Jorge (Nokia - US/Mountain View)" <jorge.raba...@nokia.com>, Eric 
Rosen <ero...@juniper.net>, Sandy Breeze <sandy.bre...@eu.clara.net>, "Satya 
Mohanty (satyamoh)" <satya...@cisco.com>
Cc: "bess@ietf.org" <bess@ietf.org>
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:bess-boun...@ietf.org] On Behalf Of Ali Sajassi (sajassi)
Sent: Monday, March 26, 2018 12:54 AM
To: John E Drake <jdr...@juniper.net>; Rabadan, Jorge (Nokia - US/Mountain 
View) <jorge.raba...@nokia.com>; Eric Rosen <ero...@juniper.net>; Sandy Breeze 
<sandy.bre...@eu.clara.net>; Satya Mohanty (satyamoh) <satya...@cisco.com>
Cc: Ali Sajassi (sajassi) <saja...@cisco.com>; bess@ietf.org
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:
 *   Enable DF election on per mcast flow – this gives the best 
load-balancing for DF election among multicast flows and avoids FAT VLAN issue
 *   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 <jdr...@juniper.net<mailto:jdr...@juniper.net>>
Date: Sunday, March 25, 2018 at 9:57 AM
To: Cisco Employee <saja...@cisco.com<mailto:saja...@cisco.com>>
Cc: "Rabadan, Jorge (Nokia - US/Mountain View)" 
<jorge.raba...@nokia.com<mailto:jorge.raba...@nokia.com>>, Eric Rosen 
<ero...@juniper.net<mailto:ero...@juniper.net>>, Sandy Breeze 
<sandy.bre...@eu.clara.net<mailto:sandy.bre...@eu.clara.net>>, 
"bess@ietf.org<mailto:bess@ietf.org>" <bess@ietf.org<mailto:bess@ietf.org>>
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) 
<saja...@cisco.com<mailto:saja...@cisco.com>> 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 <bess-boun...@ietf.org<mailto:bess-boun...@ietf.org>> on behalf of 
"Rabadan, Jorge (Nokia - US/Mountain View)" 
<jorge.raba...@nokia.com<mailto:jorge.raba...@nokia.com>>
Date: Saturday, March 24, 2018 at 3:58 AM
To: Eric C Rosen <ero...@juniper.net<mailto:ero...@juniper.net>>, Sandy Breeze 
<sandy.bre...@eu.clara.net<mailto:sandy.bre...@eu.clara.net>>, 
"bess@ietf.org<mailto:bess@

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

[UTTARO, JAMES]

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:bess-boun...@ietf.org] On Behalf Of Ali Sajassi (sajassi)
Sent: Monday, March 26, 2018 12:54 AM
To: John E Drake <jdr...@juniper.net>; Rabadan, Jorge (Nokia - US/Mountain 
View) <jorge.raba...@nokia.com>; Eric Rosen <ero...@juniper.net>; Sandy Breeze 
<sandy.bre...@eu.clara.net>; Satya Mohanty (satyamoh) <satya...@cisco.com>
Cc: Ali Sajassi (sajassi) <saja...@cisco.com>; bess@ietf.org
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 <jdr...@juniper.net<mailto:jdr...@juniper.net>>
Date: Sunday, March 25, 2018 at 9:57 AM
To: Cisco Employee <saja...@cisco.com<mailto:saja...@cisco.com>>
Cc: "Rabadan, Jorge (Nokia - US/Mountain View)" 
<jorge.raba...@nokia.com<mailto:jorge.raba...@nokia.com>>, Eric Rosen 
<ero...@juniper.net<mailto:ero...@juniper.net>>, Sandy Breeze 
<sandy.bre...@eu.clara.net<mailto:sandy.bre...@eu.clara.net>>, 
"bess@ietf.org<mailto:bess@ietf.org>" <bess@ietf.org<mailto:bess@ietf.org>>
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) 
<saja...@cisco.com<mailto:saja...@cisco.com>> 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 <bess-boun...@ietf.org<mailto:bess-boun...@ietf.org>> on behalf of 
"Rabadan, Jorge (Nokia - US/Mountain View)" 
<jorge.raba...@nokia.com<mailto:jorge.raba...@nokia.com>>
Date: Saturday, March 24, 2018 at 3:58 AM
To: Eric C Rosen <ero...@juniper.net<mailto:ero...@juniper.net>>, Sandy Breeze 
<sandy.bre...@eu.clara.net<mailto:sandy.bre...@eu.clara.net>>, 
"bess@ietf.org<mailto:bess@ietf.org>" <bess@ietf.org<mailto:bess@ietf.org>>
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 t

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

[John E Drake]

Satya,

Comment inline.

Yours Irrespectively,

John


[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)
 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.
[Sandy] We discussed the use of extended community to signal NDF, this is 
indeed a viable alternative approach and one we’re not against.  We didn’t 
choose it over not sending IMET because we don’t have a good reason why not 
sending IMET at an NDF is actually a bad idea, for our use case.  That said, if 
the consensus of this list is to use an extended community then a flag in EVPN 
extended community sub-types registry is a possible fit
[Satya] Just to make clear, the Multicast Flags extended community is only sent 
with the IMET when IGMP proxy is supported. If the BD does not support 
IGMP/MLD, then this won’t work as Jorge pointed out earlier (BUM with IR only). 
Perhaps, if there  were available flag fields in the PMSI Tunnel attr, one 
could have used it. Also, creation of a new extended community for the purpose 
of this optimization looks to me to be adding extra complexity to the CP. So we 
did not prefer doing that. Setting the label to 0 would have worked, but the 
value 0 now has the semantics that Sandy points out below.

[JD]  I don’t think this is correct.  The IGMP Proxy draft defines the 
Multicast Flags extended community, which means that your draft would need to 
have a normative reference to that draft.  However, your draft would be free to 
define a new bit in the extended community and indicate that support for the 
that bit is not contingent upon support for the IGMP Proxy draft.


___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

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

[Ali Sajassi (sajassi)]

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:
 *   Enable DF election on per mcast flow – this gives the best 
load-balancing for DF election among multicast flows and avoids FAT VLAN issue
 *   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 <jdr...@juniper.net>
Date: Sunday, March 25, 2018 at 9:57 AM
To: Cisco Employee <saja...@cisco.com>
Cc: "Rabadan, Jorge (Nokia - US/Mountain View)" <jorge.raba...@nokia.com>, Eric 
Rosen <ero...@juniper.net>, Sandy Breeze <sandy.bre...@eu.clara.net>, 
"bess@ietf.org" <bess@ietf.org>
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) 
<saja...@cisco.com<mailto:saja...@cisco.com>> 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 <bess-boun...@ietf.org<mailto:bess-boun...@ietf.org>> on behalf of 
"Rabadan, Jorge (Nokia - US/Mountain View)" 
<jorge.raba...@nokia.com<mailto:jorge.raba...@nokia.com>>
Date: Saturday, March 24, 2018 at 3:58 AM
To: Eric C Rosen <ero...@juniper.net<mailto:ero...@juniper.net>>, Sandy Breeze 
<sandy.bre...@eu.clara.net<mailto:sandy.bre...@eu.clara.net>>, 
"bess@ietf.org<mailto:bess@ietf.org>" <bess@ietf.org<mailto:bess@ietf.org>>
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 <ero...@juniper.net<mailto:ero...@juniper.net>>
Date: Friday, March 23, 2018 at 5:00 PM
To: "Rabadan, Jorge (Nokia - US/Mountain View)" 
<jorge.raba...@nokia.com<mailto:jorge.raba...@nokia.com>>, Sandy Breeze 
<sandy.bre...@eu.clara.net<mailto:sandy.bre...@eu.clara.net>>, 
"bess@ietf.org<mailto:bess@ietf.org>" <bess@ietf.org<mailto:bess@ietf.org>>
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

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

[John E Drake]

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) 
<saja...@cisco.com<mailto:saja...@cisco.com>> 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 <bess-boun...@ietf.org<mailto:bess-boun...@ietf.org>> on behalf of 
"Rabadan, Jorge (Nokia - US/Mountain View)" 
<jorge.raba...@nokia.com<mailto:jorge.raba...@nokia.com>>
Date: Saturday, March 24, 2018 at 3:58 AM
To: Eric C Rosen <ero...@juniper.net<mailto:ero...@juniper.net>>, Sandy Breeze 
<sandy.bre...@eu.clara.net<mailto:sandy.bre...@eu.clara.net>>, 
"bess@ietf.org<mailto:bess@ietf.org>" <bess@ietf.org<mailto:bess@ietf.org>>
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 <ero...@juniper.net<mailto:ero...@juniper.net>>
Date: Friday, March 23, 2018 at 5:00 PM
To: "Rabadan, Jorge (Nokia - US/Mountain View)" 
<jorge.raba...@nokia.com<mailto:jorge.raba...@nokia.com>>, Sandy Breeze 
<sandy.bre...@eu.clara.net<mailto:sandy.bre...@eu.clara.net>>, 
"bess@ietf.org<mailto:bess@ietf.org>" <bess@ietf.org<mailto:bess@ietf.org>>
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 furthe

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

[Ali Sajassi (sajassi)]

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 <bess-boun...@ietf.org> on behalf of "Rabadan, Jorge (Nokia - 
US/Mountain View)" <jorge.raba...@nokia.com>
Date: Saturday, March 24, 2018 at 3:58 AM
To: Eric C Rosen <ero...@juniper.net>, Sandy Breeze 
<sandy.bre...@eu.clara.net>, "bess@ietf.org" <bess@ietf.org>
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 <ero...@juniper.net>
Date: Friday, March 23, 2018 at 5:00 PM
To: "Rabadan, Jorge (Nokia - US/Mountain View)" <jorge.raba...@nokia.com>, 
Sandy Breeze <sandy.bre...@eu.clara.net>, "bess@ietf.org" <bess@ietf.org>
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=DwMGaQ=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI=-DXB84eU9m4cIlq2OOcCJCQQAwJXQQswyu3F

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

[Ali Sajassi (sajassi)]

Hi John,

Your suggestion (of defining a flag mcast flag EC) requires that in addition to 
gateways upgrade, all other PEs to be upgraded. I think option-A in my earlier 
email is the best option for Sandy’s use case and it provide that with the 
existing WG drafts without inventing/developing a new scheme.

Cheers,
Ali

From: BESS <bess-boun...@ietf.org> on behalf of John E Drake 
<jdr...@juniper.net>
Date: Thursday, March 22, 2018 at 8:50 AM
To: "Rabadan, Jorge (Nokia - US/Mountain View)" <jorge.raba...@nokia.com>, Eric 
Rosen <ero...@juniper.net>, Sandy Breeze <sandy.bre...@eu.clara.net>, 
"bess@ietf.org" <bess@ietf.org>
Subject: Re: [bess] draft-mohanty-bess-evpn-bum-opt-00 - clarification on 
problem description

Hi,

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) 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.

As an aside, I think Ali’s suggestion of using local configuration to set the 
ESI to zero in the HRW is fine.

However, given the you are using local configuration to do this, why isn’t 
preference-based DF election 
(https://tools.ietf.org/html/draft-ietf-bess-evpn-pref-df-00) a better 
solution?  I.e., we should have specific DF election type for a specific set of 
situations rather than trying to parameterize the HRW DF election to handle a 
multiplicity of situations.

Yours Irrespectively,

John

From: BESS <bess-boun...@ietf.org> On Behalf Of Rabadan, Jorge (Nokia - 
US/Mountain View)
Sent: Thursday, March 22, 2018 10:58 AM
To: Eric Rosen <ero...@juniper.net>; Sandy Breeze <sandy.bre...@eu.clara.net>; 
bess@ietf.org
Subject: Re: [bess] draft-mohanty-bess-evpn-bum-opt-00 - clarification on 
problem description

Eric,

The way the draft is described makes me think there are no IRB interfaces and 
this is limited to Ingress Replication. But should be clarified.

Also 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.

Assuming the above, my reasoning is that advertising/withdrawing an IMET route 
does not change any procedures or modifies any routes.

Other than that, I fully agree with you this is a corner case scenario. And if 
this goes one, it must explain clearly what the use-case is.

Thank you.
Jorge

From: Eric C Rosen <ero...@juniper.net<mailto:ero...@juniper.net>>
Date: Thursday, March 22, 2018 at 1:57 PM
To: "Rabadan, Jorge (Nokia - US/Mountain View)" 
<jorge.raba...@nokia.com<mailto:jorge.raba...@nokia.com>>, Sandy Breeze 
<sandy.bre...@eu.clara.net<mailto:sandy.bre...@eu.clara.net>>, 
"bess@ietf.org<mailto:bess@ietf.org>" <bess@ietf.org<mailto:bess@ietf.org>>
Subject: Re: [bess] draft-mohanty-bess-evpn-bum-opt-00 - clarification on 
problem description

On 3/21/2018 12:36 PM, Rabadan, Jorge (Nokia - US/Mountain View) wrote:
This scenario definitively helps understand the use-case better. Still a bit 
specific but I think you should add this scenario to the draft, and again, make 
it Informational since there is no control plane change for this.

If I understand correctly, the draft does make a control plane change, since it 
describes situations in which IMET routes should not be originated.  This 
contradicts RFC 7432, and so would have to be considered a update to that, and 
hence a standards track document.

Since I wasn't at the BESS meeting (but did watch the video), it's possible I 
missed some of the discussion, but from my reading of the draft, I have the 
following concerns.

I'm not sure the draft properly describes the situations in which one may omit 
the IMET route.  It describes the situation in which a PE doesn't need to 
propagate, on any of its ACs, BUM traffic that it receives from the backbone.  
However, if the PE has IRB interfaces, doesn't it need to receive some of the 
BUM traffic in order to process that traffic itself?  For example, if a PE is 
configured to be  a PIM router attached to two Broadcast Domains, BD1 and BD2, 
won't it need to receive PIM Hellos from BD1, even if it doesn't actually 
propagate those out the local AC attaching it to BD1?

At the meeting a DF election scheme was proposed in which, for a given <ES,BD>

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

[Ali Sajassi (sajassi)]

Eric, Jorge,

At the time I wrote RFC 7432, I had an implicit assumption that IMET routes 
advertisement is based on EVI/BD configuration only and thus it is not 
dependent on failure scenario, single-homing scenario, etc. If there was not a 
better option to solve Sandy’s use case, then I would have been OK with IMET 
advertisement suppression but I think there is (refer to my previous email). 
So, let’s evaluate all our options here.

Cheers,
Ali

From: BESS <bess-boun...@ietf.org> on behalf of "Rabadan, Jorge (Nokia - 
US/Mountain View)" <jorge.raba...@nokia.com>
Date: Thursday, March 22, 2018 at 7:58 AM
To: Eric C Rosen <ero...@juniper.net>, Sandy Breeze 
<sandy.bre...@eu.clara.net>, "bess@ietf.org" <bess@ietf.org>
Subject: Re: [bess] draft-mohanty-bess-evpn-bum-opt-00 - clarification on 
problem description

Eric,

The way the draft is described makes me think there are no IRB interfaces and 
this is limited to Ingress Replication. But should be clarified.

Also 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.

Assuming the above, my reasoning is that advertising/withdrawing an IMET route 
does not change any procedures or modifies any routes.

Other than that, I fully agree with you this is a corner case scenario. And if 
this goes one, it must explain clearly what the use-case is.

Thank you.
Jorge

From: Eric C Rosen <ero...@juniper.net>
Date: Thursday, March 22, 2018 at 1:57 PM
To: "Rabadan, Jorge (Nokia - US/Mountain View)" <jorge.raba...@nokia.com>, 
Sandy Breeze <sandy.bre...@eu.clara.net>, "bess@ietf.org" <bess@ietf.org>
Subject: Re: [bess] draft-mohanty-bess-evpn-bum-opt-00 - clarification on 
problem description

On 3/21/2018 12:36 PM, Rabadan, Jorge (Nokia - US/Mountain View) wrote:


This scenario definitively helps understand the use-case better. Still a bit 
specific but I think you should add this scenario to the draft, and again, make 
it Informational since there is no control plane change for this.

If I understand correctly, the draft does make a control plane change, since it 
describes situations in which IMET routes should not be originated.  This 
contradicts RFC 7432, and so would have to be considered a update to that, and 
hence a standards track document.

Since I wasn't at the BESS meeting (but did watch the video), it's possible I 
missed some of the discussion, but from my reading of the draft, I have the 
following concerns.

I'm not sure the draft properly describes the situations in which one may omit 
the IMET route.  It describes the situation in which a PE doesn't need to 
propagate, on any of its ACs, BUM traffic that it receives from the backbone.  
However, if the PE has IRB interfaces, doesn't it need to receive some of the 
BUM traffic in order to process that traffic itself?  For example, if a PE is 
configured to be  a PIM router attached to two Broadcast Domains, BD1 and BD2, 
won't it need to receive PIM Hellos from BD1, even if it doesn't actually 
propagate those out the local AC attaching it to BD1?

At the meeting a DF election scheme was proposed in which, for a given <ES,BD> 
pair, there could be a different DF for each(S,G)  multicast flow.  I don't 
think the draft takes this into account.  I wonder how many other scenarios 
there are which the draft fails to consider.

Many EVPN drafts have been written on the presumption that IMET routes will 
always be originated.  Some of the drafts add flags or communities to the IMET 
routes to advertise capabilities of one sort or another.  Every one of those 
drafts would need to be checked to see if it still works when some nodes do not 
originate IMET routes.

As future EVPN drafts are written, the authors (and reviewers) will now have to 
remember that they cannot presume that all the PEs attached to a given BD are 
originating IMET routes for that BD.   This creates more complexity, more 
corner cases, and ultimately, more specification bugs.

Still, one might consider adopting this complication if it were a big win.  But 
it only seems to apply to one specific (and not very common) scenario, and from 
the discussion at the microphone it wasn't clear to me that the co-authors are 
even on the same page about just what that scenario is (recall the discussion 
about whether the diagram in the draft does or does not depict the intended use 
case).










___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

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

[Satya Mohanty (satyamoh)]

Some additional comments inline [Satya]

From: BESS <bess-boun...@ietf.org<mailto:bess-boun...@ietf.org>> on behalf of 
Sandy Breeze <sandy.bre...@eu.clara.net<mailto:sandy.bre...@eu.clara.net>>
Date: Saturday, March 24, 2018 at 11:39 AM
To: "Rabadan, Jorge (Nokia - US/Mountain View)" 
<jorge.raba...@nokia.com<mailto:jorge.raba...@nokia.com>>, Eric C Rosen 
<ero...@juniper.net<mailto:ero...@juniper.net>>, 
"bess@ietf.org<mailto:bess@ietf.org>" <bess@ietf.org<mailto:bess@ietf.org>>
Subject: Re: [bess] draft-mohanty-bess-evpn-bum-opt-00 - clarification on 
problem description

John, Eric, Jorge,

[Sandy] Comments inline


On 24/03/2018, 10:57, "Rabadan, Jorge (Nokia - US/Mountain View)" 
<jorge.raba...@nokia.com<mailto:jorge.raba...@nokia.com>> wrote:

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.
[Sandy] I agree, and detailed reasoning on those points in line below

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
[Sandy] We’re happy to call out those restrictions under a definition of what 
we mean in connecting EVPN domains at DCI for L2 only scenarios
[Satya] Yes, This is applicable for the restricted cases as stated above.


And any other restrictions/caveats we may need to add.

My 2 cents.
Jorge

On 23/03/2018, 17:00, "Eric C Rosen" 
<ero...@juniper.net<mailto:ero...@juniper.net>> wrote:

[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.

[Sandy] In the specific scenario with all-active multi-homing, EVPN GW / DCI 
routers connect an EVPN VXLAN fabric and an EVPN MPLS core.  Therefore, for all 
NDF PE’s (read EVPN GW’s) there will be no IMET sent to neither RR’s in the 
EVPN MPLS core, nor to ToR in the EVPN VXLAN fabric – so neither side of the 
EVPN GW would attract BUM.



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".

[Sandy] This is a very good point Eric.  Its my understanding the reasons for 
‘sending’ IMET is because you want to signal eligibility to receive BUM 
traffic.  ‘send’ vs ‘receive’ wording aside, I agree with the RFC7432 in that 
as per my first comment above, those PE’s would not attract BUM from the EVPN 
VXLAN fabric side, because they also wouldn’t be sending the IMET to ToR, if 
they’re NDF…



If P2MP tunnels are used for the BUM traffic, the IMET route is certainly 
required to support all-active multi-homing.
[Sandy] I concur

If IR is used, or if single-active multi-homing is used, one could argue

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

[Sandy Breeze]

John, Eric, Jorge,

[Sandy] Comments inline


On 24/03/2018, 10:57, "Rabadan, Jorge (Nokia - US/Mountain View)" 
> wrote:

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.
[Sandy] I agree, and detailed reasoning on those points in line below

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
[Sandy] We’re happy to call out those restrictions under a definition of what 
we mean in connecting EVPN domains at DCI for L2 only scenarios


And any other restrictions/caveats we may need to add.

My 2 cents.
Jorge

On 23/03/2018, 17:00, "Eric C Rosen" 
> wrote:

[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.

[Sandy] In the specific scenario with all-active multi-homing, EVPN GW / DCI 
routers connect an EVPN VXLAN fabric and an EVPN MPLS core.  Therefore, for all 
NDF PE’s (read EVPN GW’s) there will be no IMET sent to neither RR’s in the 
EVPN MPLS core, nor to ToR in the EVPN VXLAN fabric – so neither side of the 
EVPN GW would attract BUM.



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".

[Sandy] This is a very good point Eric.  Its my understanding the reasons for 
‘sending’ IMET is because you want to signal eligibility to receive BUM 
traffic.  ‘send’ vs ‘receive’ wording aside, I agree with the RFC7432 in that 
as per my first comment above, those PE’s would not attract BUM from the EVPN 
VXLAN fabric side, because they also wouldn’t be sending the IMET to ToR, if 
they’re NDF…



If P2MP tunnels are used for the BUM traffic, the IMET route is certainly 
required to support all-active multi-homing.
[Sandy] I concur

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.
[Sandy] I do not concur, as per my previous point, and noting that 7432 wording 
asserts that sending IMET enables a PE to forward BUM received from CE… but in 
this scenario it will never receive BUM from the EVPN VXLAN fabric side, 
because we wont send IMET to ToR



[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)
 indicating that 

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

[Rabadan, Jorge (Nokia - US/Mountain View)]

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 <ero...@juniper.net>
Date: Friday, March 23, 2018 at 5:00 PM
To: "Rabadan, Jorge (Nokia - US/Mountain View)" <jorge.raba...@nokia.com>, 
Sandy Breeze <sandy.bre...@eu.clara.net>, "bess@ietf.org" <bess@ietf.org>
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=DwMGaQ=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI=-DXB84eU9m4cIlq2OOcCJCQQAwJXQQswyu3F0kG0VNo=rs8r_tXnIDIv9e5NNgiXOy5yYuE10r6x9al8H6FgK04=V42kiY3ngmDNxMKmk5GgHmy9LcMGdOXpcvbereFtUR8=>)
 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 compati

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

[Eric C Rosen]

[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 
) 
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
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

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

[John E Drake]

Hi,

Comments inline

Yours Irrespectively,

John

From: Sandy Breeze <sandy.bre...@eu.clara.net>
Sent: Thursday, March 22, 2018 1:42 PM
To: John E Drake <jdr...@juniper.net>; Rabadan, Jorge (Nokia - US/Mountain 
View) <jorge.raba...@nokia.com>; Eric Rosen <ero...@juniper.net>; bess@ietf.org
Subject: Re: [bess] draft-mohanty-bess-evpn-bum-opt-00 - clarification on 
problem description

Hi John,

On 22/03/2018, 15:50, "John E Drake" 
<jdr...@juniper.net<mailto:jdr...@juniper.net>> wrote:

Hi,

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=DwMGaQ=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI=CRB2tJiQePk0cT-h5LGhEWH-s_xXXup3HzvBSMRj5VE=1qUG2zcOnBYVgqYAruIyYwYTWI_ccvWmgqpVaj6nw_g=VPDaymo2gpPzYJstfpbXMMhH21sHQWFlZM5dWELsiPY=>)
 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.

[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
-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


[JD]  I think what Eric and I are saying is that this is a bad idea.  As an 
example, it breaks IGMP Proxy because we no longer no whether all of the PEs 
attached to a given ES support it which effectively disables IGMP Proxy on that 
ES.  It would also break OISM because, again, we would no longer know the 
capabilities of the PEs attached to that ES.


[Sandy] You mention only applicable to EVPN DC GWs.  In my world this is a 
converged EVPN PE router.  How would you declare an EVPN DC GW and treat it 
differently from an EVPN PE?


[JD]  The normal case is that a PE is attached to a multiplicity of ESEs


As an aside, I think Ali’s suggestion of using local configuration to set the 
ESI to zero in the HRW is fine.

However, given the you are using local configuration to do this, why isn’t 
preference-based DF election 
(https://tools.ietf.org/html/draft-ietf-bess-evpn-pref-df-00<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dietf-2Dbess-2Devpn-2Dpref-2Ddf-2D00=DwMGaQ=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI=CRB2tJiQePk0cT-h5LGhEWH-s_xXXup3HzvBSMRj5VE=1qUG2zcOnBYVgqYAruIyYwYTWI_ccvWmgqpVaj6nw_g=26lcqkrOqqDHo5faivKsv2-uJQ_3Qbe17Zmkolbiht8=>)
 a better solution?  I.e., we should have specific DF election type for a 
specific set of situations rather than trying to parameterize the HRW DF 
election to handle a multiplicity of situations.
[Sandy] I don’t think in my specific case, I’m reliant on setting ESI to zero 
to since I am only 1 ES per BD.


[JD]  I don’t think this is consistent w/ the DCI interconnect draft and I 
don’t see any reason for doing this.  I.e., there is supposed to be any 
interconnect ESI for the DC as a whole..

In the more general case however, as Satya mentions in an earlier thread, this 
may be desirable to set ESI to 0 for optimal NDF position where all BD’s share 
the same ES and there are many ES’s.


[JD]  I have heard this assertion from both you and Satya.  Do you have any 
evidence to support it?


[Sandy] As with any existing DF type I know of, preference DF is fine as a 
selection mechanism, but it doesn’t stop NDF’s attracting traffic unnecessarily 
which is what I’m trying to achieve here.


[JD]  That is why I am suggesting the bit in the Multicast Flags extended 
community.


Regards
Sandy



Yours Irrespectively,

John

From: BESS <bess-boun...@ietf.org<mailto:bess-boun...@ietf.org>> On Behalf Of 
Rabadan, Jorge (Nokia - US/Mountain View)
Sent: Thursday, March 22, 2018 10:58 AM
To: Eric Rosen <ero...@juniper.net<mailto:ero...@juniper.net>>; Sandy Breeze 
<sandy.bre...@eu.clara.net<mailto:sandy.bre...@eu.clara.net>>; 
bess@ietf.org<mailto:bess@ietf.org>
Subject: Re: [bess] draft-mohanty-bess-evpn-bum-opt-00 - clarification on 
problem description

Eric,

The way the draft is described makes me think there are no IRB interfaces and 
this is limited to Ingress Replication. But should be clarified.

Also my interpretation of RFC7432 is that IMET routes are mandatory to enable 
the handling of multi-destination traffic in a 

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

[Sandy Breeze]

Hi John,

On 22/03/2018, 15:50, "John E Drake" 
<jdr...@juniper.net<mailto:jdr...@juniper.net>> wrote:

Hi,

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) 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.

[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
  *   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

[Sandy] You mention only applicable to EVPN DC GWs.  In my world this is a 
converged EVPN PE router.  How would you declare an EVPN DC GW and treat it 
differently from an EVPN PE?

As an aside, I think Ali’s suggestion of using local configuration to set the 
ESI to zero in the HRW is fine.

However, given the you are using local configuration to do this, why isn’t 
preference-based DF election 
(https://tools.ietf.org/html/draft-ietf-bess-evpn-pref-df-00) a better 
solution?  I.e., we should have specific DF election type for a specific set of 
situations rather than trying to parameterize the HRW DF election to handle a 
multiplicity of situations.
[Sandy] I don’t think in my specific case, I’m reliant on setting ESI to zero 
to since I am only 1 ES per BD. In the more general case however, as Satya 
mentions in an earlier thread, this may be desirable to set ESI to 0 for 
optimal NDF position where all BD’s share the same ES and there are many ES’s.

[Sandy] As with any existing DF type I know of, preference DF is fine as a 
selection mechanism, but it doesn’t stop NDF’s attracting traffic unnecessarily 
which is what I’m trying to achieve here.

Regards
Sandy



Yours Irrespectively,

John

From: BESS <bess-boun...@ietf.org> On Behalf Of Rabadan, Jorge (Nokia - 
US/Mountain View)
Sent: Thursday, March 22, 2018 10:58 AM
To: Eric Rosen <ero...@juniper.net>; Sandy Breeze <sandy.bre...@eu.clara.net>; 
bess@ietf.org
Subject: Re: [bess] draft-mohanty-bess-evpn-bum-opt-00 - clarification on 
problem description

Eric,

The way the draft is described makes me think there are no IRB interfaces and 
this is limited to Ingress Replication. But should be clarified.

Also 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.

Assuming the above, my reasoning is that advertising/withdrawing an IMET route 
does not change any procedures or modifies any routes.

Other than that, I fully agree with you this is a corner case scenario. And if 
this goes one, it must explain clearly what the use-case is.

Thank you.
Jorge

From: Eric C Rosen <ero...@juniper.net<mailto:ero...@juniper.net>>
Date: Thursday, March 22, 2018 at 1:57 PM
To: "Rabadan, Jorge (Nokia - US/Mountain View)" 
<jorge.raba...@nokia.com<mailto:jorge.raba...@nokia.com>>, Sandy Breeze 
<sandy.bre...@eu.clara.net<mailto:sandy.bre...@eu.clara.net>>, 
"bess@ietf.org<mailto:bess@ietf.org>" <bess@ietf.org<mailto:bess@ietf.org>>
Subject: Re: [bess] draft-mohanty-bess-evpn-bum-opt-00 - clarification on 
problem description

On 3/21/2018 12:36 PM, Rabadan, Jorge (Nokia - US/Mountain View) wrote:
This scenario definitively helps understand the use-case better. Still a bit 
specific but I think you should add this scenario to the draft, and again, make 
it Informational since there is no control plane change for this.

If I understand correctly, the draft does make a control plane change, since it 
describes situations in which IMET routes should not be originated.  This 
contradicts RFC 7432, and so would have to be considered a update to that, and 
hence a standards track document.

Since I wasn't at the BESS meeting (but did watch the video), it's possible I 
missed some of the discussion, but from my reading of the draft, I have the 
following concerns.

I'm not sure the draft properly describes the situations in which one may omit 
the IMET route.  It describes the situation in which a PE doesn't need to 
propagate, on any of its ACs, BUM tr

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

[Sandy Breeze]

Eric, Jorge,

[Sandy] Comments inline;

On 22/03/2018, 14:58, "Rabadan, Jorge (Nokia - US/Mountain View)" 
<jorge.raba...@nokia.com<mailto:jorge.raba...@nokia.com>> wrote:

Eric,

The way the draft is described makes me think there are no IRB interfaces and 
this is limited to Ingress Replication. But should be clarified.

Also 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.

Assuming the above, my reasoning is that advertising/withdrawing an IMET route 
does not change any procedures or modifies any routes.

[Sandy] Yes, your interpretation is correct

Other than that, I fully agree with you this is a corner case scenario. And if 
this goes one, it must explain clearly what the use-case is.

Thank you.
Jorge

From: Eric C Rosen <ero...@juniper.net>
Date: Thursday, March 22, 2018 at 1:57 PM
To: "Rabadan, Jorge (Nokia - US/Mountain View)" <jorge.raba...@nokia.com>, 
Sandy Breeze <sandy.bre...@eu.clara.net>, "bess@ietf.org" <bess@ietf.org>
Subject: Re: [bess] draft-mohanty-bess-evpn-bum-opt-00 - clarification on 
problem description

On 3/21/2018 12:36 PM, Rabadan, Jorge (Nokia - US/Mountain View) wrote:


This scenario definitively helps understand the use-case better. Still a bit 
specific but I think you should add this scenario to the draft, and again, make 
it Informational since there is no control plane change for this.

If I understand correctly, the draft does make a control plane change, since it 
describes situations in which IMET routes should not be originated.  This 
contradicts RFC 7432, and so would have to be considered a update to that, and 
hence a standards track document.

Since I wasn't at the BESS meeting (but did watch the video), it's possible I 
missed some of the discussion, but from my reading of the draft, I have the 
following concerns.

I'm not sure the draft properly describes the situations in which one may omit 
the IMET route.  It describes the situation in which a PE doesn't need to 
propagate, on any of its ACs, BUM traffic that it receives from the backbone.  
However, if the PE has IRB interfaces, doesn't it need to receive some of the 
BUM traffic in order to process that traffic itself?  For example, if a PE is 
configured to be  a PIM router attached to two Broadcast Domains, BD1 and BD2, 
won't it need to receive PIM Hellos from BD1, even if it doesn't actually 
propagate those out the local AC attaching it to BD1?

[Sandy] - It was not the intention to include IRB and the use case is limited 
to Ingress Replication only.  We will call this out in -01


At the meeting a DF election scheme was proposed in which, for a given <ES,BD> 
pair, there could be a different DF for each(S,G)  multicast flow.  I don't 
think the draft takes this into account.  I wonder how many other scenarios 
there are which the draft fails to consider.

[Sandy] The -00 draft doesn’t mention it, but the authors have discussed 
consequences on each DF type, not just (S,G) and (*,G), and the consensus is 
this has no impact.  Evidence of that will appear in -01.


Many EVPN drafts have been written on the presumption that IMET routes will 
always be originated.  Some of the drafts add flags or communities to the IMET 
routes to advertise capabilities of one sort or another.  Every one of those 
drafts would need to be checked to see if it still works when some nodes do not 
originate IMET routes.

[Sandy] The following drafts were read and considered to be non-impacting

  *   Df-framework
  *   Fast-df-recovery
  *   Per-mcast-flow
  *   Igmp-mld-proxy
  *   Irb-mcast – Though we assume no irb in our scenario


As future EVPN drafts are written, the authors (and reviewers) will now have to 
remember that they cannot presume that all the PEs attached to a given BD are 
originating IMET routes for that BD.   This creates more complexity, more 
corner cases, and ultimately, more specification bugs.

[Sandy] Isn’t that the same situation with increments to all standards?


Still, one might consider adopting this complication if it were a big win.  But 
it only seems to apply to one specific (and not very common) scenario, and from 
the discussion at the microphone it wasn't clear to me that the co-authors are 
even on the same page about just what that scenario is (recall the discussion 
about whether the diagram in the draft does or does not depict the intended use 
case).

[Sandy] In the -00 draft and during bess session, we positioned the use case 
from a very general perspective.  This caused confusion, and the specific 
problem statement has been explained in this thread and made clear in -01.
Use cas

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

[Rabadan, Jorge (Nokia - US/Mountain View)]

Eric,

The way the draft is described makes me think there are no IRB interfaces and 
this is limited to Ingress Replication. But should be clarified.

Also 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.

Assuming the above, my reasoning is that advertising/withdrawing an IMET route 
does not change any procedures or modifies any routes.

Other than that, I fully agree with you this is a corner case scenario. And if 
this goes one, it must explain clearly what the use-case is.

Thank you.
Jorge

From: Eric C Rosen <ero...@juniper.net>
Date: Thursday, March 22, 2018 at 1:57 PM
To: "Rabadan, Jorge (Nokia - US/Mountain View)" <jorge.raba...@nokia.com>, 
Sandy Breeze <sandy.bre...@eu.clara.net>, "bess@ietf.org" <bess@ietf.org>
Subject: Re: [bess] draft-mohanty-bess-evpn-bum-opt-00 - clarification on 
problem description

On 3/21/2018 12:36 PM, Rabadan, Jorge (Nokia - US/Mountain View) wrote:

This scenario definitively helps understand the use-case better. Still a bit 
specific but I think you should add this scenario to the draft, and again, make 
it Informational since there is no control plane change for this.

If I understand correctly, the draft does make a control plane change, since it 
describes situations in which IMET routes should not be originated.  This 
contradicts RFC 7432, and so would have to be considered a update to that, and 
hence a standards track document.

Since I wasn't at the BESS meeting (but did watch the video), it's possible I 
missed some of the discussion, but from my reading of the draft, I have the 
following concerns.

I'm not sure the draft properly describes the situations in which one may omit 
the IMET route.  It describes the situation in which a PE doesn't need to 
propagate, on any of its ACs, BUM traffic that it receives from the backbone.  
However, if the PE has IRB interfaces, doesn't it need to receive some of the 
BUM traffic in order to process that traffic itself?  For example, if a PE is 
configured to be  a PIM router attached to two Broadcast Domains, BD1 and BD2, 
won't it need to receive PIM Hellos from BD1, even if it doesn't actually 
propagate those out the local AC attaching it to BD1?

At the meeting a DF election scheme was proposed in which, for a given <ES,BD> 
pair, there could be a different DF for each(S,G)  multicast flow.  I don't 
think the draft takes this into account.  I wonder how many other scenarios 
there are which the draft fails to consider.

Many EVPN drafts have been written on the presumption that IMET routes will 
always be originated.  Some of the drafts add flags or communities to the IMET 
routes to advertise capabilities of one sort or another.  Every one of those 
drafts would need to be checked to see if it still works when some nodes do not 
originate IMET routes.

As future EVPN drafts are written, the authors (and reviewers) will now have to 
remember that they cannot presume that all the PEs attached to a given BD are 
originating IMET routes for that BD.   This creates more complexity, more 
corner cases, and ultimately, more specification bugs.

Still, one might consider adopting this complication if it were a big win.  But 
it only seems to apply to one specific (and not very common) scenario, and from 
the discussion at the microphone it wasn't clear to me that the co-authors are 
even on the same page about just what that scenario is (recall the discussion 
about whether the diagram in the draft does or does not depict the intended use 
case).









___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

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

[Eric C Rosen]

On 3/21/2018 12:36 PM, Rabadan, Jorge (Nokia - US/Mountain View) wrote:


This scenario definitively helps understand the use-case better. Still 
a bit specific but I think you should add this scenario to the draft, 
and again, make it Informational since there is no control plane 
change for this.




If I understand correctly, the draft does make a control plane change, 
since it describes situations in which IMET routes should not be 
originated.  This contradicts RFC 7432, and so would have to be 
considered a update to that, and hence a standards track document.


Since I wasn't at the BESS meeting (but did watch the video), it's 
possible I missed some of the discussion, but from my reading of the 
draft, I have the following concerns.


I'm not sure the draft properly describes the situations in which one 
may omit the IMET route.  It describes the situation in which a PE 
doesn't need to propagate, on any of its ACs, BUM traffic that it 
receives from the backbone.  However, if the PE has IRB interfaces, 
doesn't it need to receive some of the BUM traffic in order to process 
that traffic itself?  For example, if a PE is configured to be  a PIM 
router attached to two Broadcast Domains, BD1 and BD2, won't it need to 
receive PIM Hellos from BD1, even if it doesn't actually propagate those 
out the local AC attaching it to BD1?


At the meeting a DF election scheme was proposed in which, for a given 
 pair, there could be a different DF for each(S,G)  multicast 
flow.  I don't think the draft takes this into account.  I wonder how 
many other scenarios there are which the draft fails to consider.


Many EVPN drafts have been written on the presumption that IMET routes 
will always be originated.  Some of the drafts add flags or communities 
to the IMET routes to advertise capabilities of one sort or another.  
Every one of those drafts would need to be checked to see if it still 
works when some nodes do not originate IMET routes.


As future EVPN drafts are written, the authors (and reviewers) will now 
have to remember that they cannot presume that all the PEs attached to a 
given BD are originating IMET routes for that BD. This creates more 
complexity, more corner cases, and ultimately, more specification bugs.


Still, one might consider adopting this complication if it were a big 
win.  But it only seems to apply to one specific (and not very common) 
scenario, and from the discussion at the microphone it wasn't clear to 
me that the co-authors are even on the same page about just what that 
scenario is (recall the discussion about whether the diagram in the 
draft does or does not depict the intended use case).









___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

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

[Satya Mohanty (satyamoh)]

Hi John,

That is right. I get your point.

I replied in the preceding mail the reasons for having this option.
If we all decide this is not particularly useful, we don’t have to take that 
into account.

Thanks,
—Satya


From: "jdr...@juniper.net<mailto:jdr...@juniper.net>" 
<jdr...@juniper.net<mailto:jdr...@juniper.net>>
Date: Thursday, March 22, 2018 at 2:17 AM
To: satyamoh <satya...@cisco.com<mailto:satya...@cisco.com>>
Cc: "Ali Sajassi (sajassi)" <saja...@cisco.com<mailto:saja...@cisco.com>>, 
Sandy Breeze <sandy.bre...@eu.clara.net<mailto:sandy.bre...@eu.clara.net>>, 
"bess@ietf.org<mailto:bess@ietf.org>" <bess@ietf.org<mailto:bess@ietf.org>>
Subject: Re: [bess] draft-mohanty-bess-evpn-bum-opt-00 - clarification on 
problem description

Satya,

If we do this, it requires that we define two different DF election types, one 
that uses ESI and one that doesn't.  Given that we have other DF election types 
that will give us the same behavior I don't agree w/ this.

John

Sent from my iPhone

On Mar 21, 2018, at 10:16 PM, Satya Mohanty (satyamoh) 
<satya...@cisco.com<mailto:satya...@cisco.com>> wrote:

We will take the feedback and revise the next version with the EVPN GW case as 
the primary use case.
Also, we will make it informational.

I need to make a mention again of what I spoke at the mic because I think it 
may not have been clear to everyone.
In the DF election framework draft, the weight is now a function of  the 
tuple(vlan, Esid, PE’s IP).
If we set the Esid to 0, then as long as each ES has the exact same set if 
vlans, the carving of vlans by the algorithm is the same.

Thanks,
—Satya

From: BESS <bess-boun...@ietf.org<mailto:bess-boun...@ietf.org>> on behalf of 
"Ali Sajassi (sajassi)" <saja...@cisco.com<mailto:saja...@cisco.com>>
Date: Wednesday, March 21, 2018 at 6:27 PM
To: Sandy Breeze <sandy.bre...@eu.clara.net<mailto:sandy.bre...@eu.clara.net>>, 
"bess@ietf.org<mailto:bess@ietf.org>" <bess@ietf.org<mailto:bess@ietf.org>>
Subject: Re: [bess] draft-mohanty-bess-evpn-bum-opt-00 - clarification on 
problem description

Hi Sandy,

The key point in here is that the proposal is intended for EVPN GWs (and not 
PEs). By talking about PEs and NVEs at BESS yesterday, lot of people got 
confused. Although for EVPN GWs, this proposal makes better sense, for EVPN 
PEs, it doesn’t much because:

  1.  Vast majority (if not all) of TORs/PEs multi-homing are dual-homing which 
gives us zero benefit
  2.  Even for multi-homing with >2 PEs in the redundancy group, the chances of 
a PE not becoming a DF across all ES's in a BD is extremely low. We need to 
keep in mind that number of ES's are much larger than number of PEs !! And HRW 
algorithm in our df-framework draft takes into account the ES-id in its hash 
algorithm which means for the same BD, different PEs can become DF for 
different ES's !!
3) As soon as there is a stub node (e.g., a single-home CE) connected to any 
PE, then all bets are off and that PE needs to send IMET route and receive 
mcast traffic
4) As soon as there is a link/ES failure, then we will end-up with (3) above 
for dual-homing scenario and the PE with active link needs to send IMET route 
and receive mcast traffic
5) For mcast flow (*,G) or (S,G), the solution described in igmp-proxy draft  
is the most optimal

So, I would suggest to do the following:

  1.  In the problem statement of the draft, capture the below use case clearly.
  2.  Change the name of the draft to “bum optimization for EVPN gateways”
  3.  Capture briefly why the proposal is not intended for EVPN PEs/NVEs 
because of the above reasons.

Cheers,
Ali

From: BESS <bess-boun...@ietf.org<mailto:bess-boun...@ietf.org>> on behalf of 
Sandy Breeze <sandy.bre...@eu.clara.net<mailto:sandy.bre...@eu.clara.net>>
Date: Wednesday, March 21, 2018 at 8:58 AM
To: "bess@ietf.org<mailto:bess@ietf.org>" <bess@ietf.org<mailto:bess@ietf.org>>
Subject: [bess] draft-mohanty-bess-evpn-bum-opt-00 - clarification on problem 
description

After some discussion, we acknowledge the problem description needs further 
clarification for this not to become too specific a use case.  Consider the 
following example of our existing live deployments;




The main points to articulate here are;

  *   PE[1..4] are at the boundary of an EVPN/MPLS domain (core side) and an 
EVPN/VXLAN domain (datacentre fabric side)
  *   They are responsible for L2VNI VTEP from ToR and MPLS L2VPN in core.
  *   From their point of view, 1 BD = 1 L2VNI (=1 ES).
  *   For any given DF type (modulo/HRW/etc) they distribute DF’s per-ES 
between them.
  *   Therefore, all nDF PE’s attract BUM for ES’s they’re not allowed to 
forward on and hence the waste of bandwidth in the EVPN core and cycles.

In our case, the solution