Re: [bess] Last Call: (Updates on EVPN BUM Procedures) to Proposed Standard

[Jeffrey (Zhaohui) Zhang]

Hi Satya,

Yes it applies to MVPN as well. I am actually in the process of writing a draft 
to formally extend the inter-region segmentation and per-region aggregation to 
MVPN, and to do intra-region segmentation for assisted replication purpose.

Jeffrey

From: Satya Mohanty (satyamoh) 
Sent: Tuesday, September 14, 2021 8:50 PM
To: Jeffrey (Zhaohui) Zhang ; last-c...@ietf.org; 
IETF-Announce 
Cc: ext-zzhang_i...@hotmail.com ; 
martin.vigour...@nokia.com; bess-cha...@ietf.org; 
draft-ietf-bess-evpn-bum-procedure-upda...@ietf.org; bess@ietf.org
Subject: Re: [bess] Last Call: 
 (Updates on EVPN BUM 
Procedures) to Proposed Standard

[External Email. Be cautious of content]

Hi Jeffrey,

Thanks for your reply.
It makes perfect sense.

Am I to assume that the same reasoning applies to Inter-as MVPN as well since 
EVPN BUM procedures is based significantly on MVPN procedures?

Best Regards,
--Satya

From: "Jeffrey (Zhaohui) Zhang" mailto:zzh...@juniper.net>>
Date: Tuesday, September 14, 2021 at 12:31 PM
To: "Satya Mohanty (satyamoh)" mailto:satya...@cisco.com>>, 
"last-c...@ietf.org" 
mailto:last-c...@ietf.org>>, IETF-Announce 
mailto:ietf-annou...@ietf.org>>
Cc: "ext-zzhang_i...@hotmail.com" 
mailto:zzhang_i...@hotmail.com>>, 
"martin.vigour...@nokia.com" 
mailto:martin.vigour...@nokia.com>>, 
"bess-cha...@ietf.org" 
mailto:bess-cha...@ietf.org>>, 
"draft-ietf-bess-evpn-bum-procedure-upda...@ietf.org"
 
mailto:draft-ietf-bess-evpn-bum-procedure-upda...@ietf.org>>,
 "bess@ietf.org" mailto:bess@ietf.org>>
Subject: RE: [bess] Last Call: 
 (Updates on EVPN BUM 
Procedures) to Proposed Standard

Hi Satya,

That is part of the optional procedure to provide backwards compatibility. An 
implementation would likely to have configuration controlling whether this 
procedure is used or not.

For the origination of per-region I-PMSI routes, whether it is for the purpose 
of backwards compatibility or just for the aggregation purpose, some 
provisioning is needed – at least to enable per-region aggregation (perhaps at 
per-VPN level). We are adding per-VPN signaling and procedures, so per-VRF 
configuration should be reasonable (at least on the source ASBRs).

In summary, that is indeed a local implementation issue.

Thanks!
Jeffrey

From: Satya Mohanty (satyamoh) mailto:satya...@cisco.com>>
Sent: Friday, September 10, 2021 2:10 PM
To: last-c...@ietf.org; IETF-Announce 
mailto:ietf-annou...@ietf.org>>
Cc: ext-zzhang_i...@hotmail.com 
mailto:zzhang_i...@hotmail.com>>; 
martin.vigour...@nokia.com; 
bess-cha...@ietf.org; 
draft-ietf-bess-evpn-bum-procedure-upda...@ietf.org;
 bess@ietf.org
Subject: Re: [bess] Last Call: 
 (Updates on EVPN BUM 
Procedures) to Proposed Standard

[External Email. Be cautious of content]


Hi authors,



One question on the draft Page #11, last paragraph;



   "  The ASBRs in an AS originate per-region I-PMSI A-D routes and

  advertise to their external peers to advertise tunnels used to

  carry traffic from the local AS to other ASes.  Depending on the

  types of tunnels being used, the L flag in the PTA may be set, in

  which case the downstream ASBRs and upgraded PEs will send Leaf

  A-D routes to pull traffic from their upstream ASBRs."



How do we originate these per-region I-PMSI?

Is it implied that there are EVI configuration at the ASBR?

Or this is a local decision and is not to be discussed in the standard.



In L23VPN, usually ASBRs do not have VRFs configured. Therefore asking this 
question.



Thanks,

--Satya



On 8/24/21, 7:38 AM, "BESS on behalf of The IESG" mailto:bess-boun...@ietf.org%20on%20behalf%20of%20iesg-secret...@ietf.org>>
 wrote:





The IESG has received a request from the BGP Enabled ServiceS WG (bess) to

consider the following document: - 'Updates on EVPN BUM Procedures'

   as Proposed Standard



The IESG plans to make a decision in the next few weeks, and solicits final

comments on this action. Please send substantive comments to the

last-c...@ietf.org mailing lists by 2021-09-07. 
Exceptionally, comments may

be sent to i...@ietf.org instead. In either case, 
please retain the beginning

of the Subject line to allow automated sorting.



Abstract





   This document specifies procedure updates for broadcast, unknown

   unicast, and multicast (BUM) traffic in Ethernet VPNs (EVPN),

   including selective multicast, and provider tunnel segmentation.

   This document updates RFC 7432.











The file can be 

Re: [bess] WG adoption poll and IPR poll for draft-mohanty-bess-ebgp-dmz-03 [1].

[Neeraj Malhotra]

Hi,

Support adoption.

Thanks,
Neeraj

On Tue, Sep 7, 2021 at 5:42 AM Bocci, Matthew (Nokia - GB) <
matthew.bo...@nokia.com> wrote:

> Hello,
>
>
>
> This email begins a two-week WG adoption poll for
> draft-mohanty-bess-ebgp-dmz-03 [1].
>
>
>
> Please review the draft and post any comments to the BESS working group
> list.
>
>
>
> We are also polling for knowledge of any undisclosed IPR that applies to
> this document, to ensure that IPR has been disclosed in compliance with
> IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details).
>
>
>
> If you are listed as an author or a contributor of this document, please
> respond to this email and indicate whether or not you are aware of any
> relevant undisclosed IPR, copying the BESS mailing list. The document will
> not  progress without answers from all of the authors and contributors.
>
>
>
> Currently, there are no IPR disclosures against this document.
>
>
>
> If you are not listed as an author or a contributor, then please
> explicitly respond only if you are aware of any IPR that has not yet been
> disclosed in conformance with IETF rules.
>
>
>
> This poll for adoption closes on September 21st 2021.
>
>
>
> Regards,
>
> Matthew and Stephane
>
>
>
>
>
> [1] https://datatracker.ietf.org/doc/draft-mohanty-bess-ebgp-dmz-03/
>
>
>
>
> ___
> BESS mailing list
> BESS@ietf.org
> https://www.ietf.org/mailman/listinfo/bess
>
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] Query to authors of draft-ietf-bess-evpn-fast-df-recovery and rfc

[Dikshit, Saumya]

Hi Jorge and Members of Bess WG,

Please let us know your views on 
https://datatracker.ietf.org/doc/draft-saumvinayak-bess-all-df-bum/.
We have described the use-case this draft intends to solve, leveraging the 
existing TLVs.
Please include this as wg draft.

Thanks
Saumya.

From: Dikshit, Saumya
Sent: Friday, September 3, 2021 5:53 PM
To: Joshi, Vinayak ; Rabadan, Jorge (Nokia - US/Mountain 
View) ; 
draft-ietf-bess-evpn-fast-df-recov...@ietf.org; 
draft-ietf-bess-evpn-df-election-framew...@ietf.org
Cc: bess@ietf.org
Subject: RE: Query to authors of draft-ietf-bess-evpn-fast-df-recovery and rfc

Hi Jorge and others in Bess WG,

We have come out with a new draft to which proposes a DF-election-mode where in 
all the PEs intend to play the DF-role.
Please go through the document and provide your comments: 
https://datatracker.ietf.org/doc/draft-saumvinayak-bess-all-df-bum/

Thanks
Saumya.


From: Joshi, Vinayak
Sent: Monday, August 23, 2021 5:22 PM
To: Dikshit, Saumya mailto:saumya.diks...@hpe.com>>; 
Rabadan, Jorge (Nokia - US/Mountain View) 
mailto:jorge.raba...@nokia.com>>; 
draft-ietf-bess-evpn-fast-df-recov...@ietf.org;
 
draft-ietf-bess-evpn-df-election-framew...@ietf.org
Cc: bess@ietf.org
Subject: RE: Query to authors of draft-ietf-bess-evpn-fast-df-recovery and rfc

+1 for standard compliance on the control plane to indicate [All Active + All 
DF].
However, I think local bias is still needed to prevent some scenarios

E.g.:
1)  Host1 sends out ARP request for the Firewall.
2)  It reaches VTEP-1 over VxLAN from Vtep_Host1. Two options at Vtep_1

a)  Proprietary Option:  VTEP 2 does not forward it over the VxLAN DCI 
tunnel to Vtep2. I.e. VTEP 1 has to match the ARP for Firewall.

b)   Vtep_1 sends it over VTEP 2 on VxLAN DCI. VTEP 2's local bias 
procedure prevents it from getting into Firewall_2.  This makes it easier to 
implement on Vtep_2. This is because Vtep_1 need not selectively block BUM over 
the VxLAN tunnel (ARP from Host1 to resolve Host2's IP has to be forwarded by 
Vtep_1 to Vtep_2).

Regards,
Vinayak



From: BESS [mailto:bess-boun...@ietf.org] On Behalf Of Dikshit, Saumya
Sent: Thursday, August 19, 2021 11:39 PM
To: Rabadan, Jorge (Nokia - US/Mountain View) 
mailto:jorge.raba...@nokia.com>>; 
draft-ietf-bess-evpn-fast-df-recov...@ietf.org;
 
draft-ietf-bess-evpn-df-election-framew...@ietf.org
Cc: bess@ietf.org
Subject: Re: [bess] Query to authors of draft-ietf-bess-evpn-fast-df-recovery 
and rfc


 If you still want to control the unicast and BUM flows to one FW or the 
 other depending on the leaf, you can still do it but that's implementation 
 specific since it relies on the route selection in vtep_host1 and 
 vtep_host2.
+1 on the implementation part. It's good to have few proprietary solutions in 
place.
On another note, the best way forward could be the standards-support/enabler 
for EVPN control-plane;
like an option to allow more than one PEs (in active-active) to process the BUM 
(arp request) traffic.

Thanks
Saumya.

From: Rabadan, Jorge (Nokia - US/Mountain View) [mailto:jorge.raba...@nokia.com]
Sent: Thursday, August 19, 2021 9:40 PM
To: Dikshit, Saumya mailto:saumya.diks...@hpe.com>>; 
draft-ietf-bess-evpn-fast-df-recov...@ietf.org;
 
draft-ietf-bess-evpn-df-election-framew...@ietf.org
Cc: bess@ietf.org
Subject: Re: Query to authors of draft-ietf-bess-evpn-fast-df-recovery and rfc

I think you are saying that the FW can fail but it's interface to the leaf is 
oper-up. I don't think the network can do anything to prevent traffic to that 
interface then.

And of course, in your new diagram local bias does not play. As I said, local 
bias works in the previous diagram.
Those new leaf nodes will do aliasing to the remote all-active ES.

If you still want to control the unicast and BUM flows to one FW or the other 
depending on the leaf, you can still do it but that's implementation specific 
since it relies on the route selection in vtep_host1 and vtep_host2.

Thx
Jorge


From: Dikshit, Saumya mailto:saumya.diks...@hpe.com>>
Date: Thursday, August 19, 2021 at 8:49 AM
To: Rabadan, Jorge (Nokia - US/Mountain View) 
mailto:jorge.raba...@nokia.com>>, 
draft-ietf-bess-evpn-fast-df-recov...@ietf.org
 
mailto:draft-ietf-bess-evpn-fast-df-recov...@ietf.org>>,
 
draft-ietf-bess-evpn-df-election-framew...@ietf.org
 
mailto:draft-ietf-bess-evpn-df-election-framew...@ietf.org>>
Cc: bess@ietf.org mailto:bess@ietf.org>>