Re: [bess] Alvaro Retana's Discuss on draft-ietf-bess-evpn-igmp-mld-proxy-14: (with DISCUSS and COMMENT)

Thanks, changed version on the way . From: Alvaro Retana Date: Thursday, December 9, 2021 at 12:58 PM To: Mankamana Mishra (mankamis) , The IESG Cc: draft-ietf-bess-evpn-igmp-mld-pr...@ietf.org , slitkows.i...@gmail.com , bess-cha...@ietf.org , bess@ietf.org Subject: Re: Alvaro Retana's

Re: [bess] Contradiction for the RFC 7432 definition of the fast convergence (withdrawal) for single-homed CEs

Hi Eduard, I am not saying that the mass-withdraw for single-homed ES don't have any benifits. What I have noticed is that when we extend a mass-withdraw feature for single-homed ES, the route resolution for zero ESI RT-2 can not be simply updated, if those updates would exclude current

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

Hi Matthew, Thanks for your comments. We will republish this draft as draft-ietf-bess-ebgp-dmz-00 shortly. Best Regards, --Satya From: BESS on behalf of Bocci, Matthew (Nokia - GB) Date: Thursday, December 9, 2021 at 5:36 AM To: Ajay Kini Cc: Akshay Gattani , bess@ietf.org , Lukas

Re: [bess] Alvaro Retana's Discuss on draft-ietf-bess-evpn-igmp-mld-proxy-14: (with DISCUSS and COMMENT)

Hi! Yes, please use terminology consistent with the existing RFCs. Thanks! Alvaro. On December 8, 2021 at 6:14:34 PM, Mankamana Mishra (mankamis) ( manka...@cisco.com) wrote: Hi Alvaro, while i wait for PIM working group to provide and submit the next revision this Friday. I have question

Re: [bess] Robert Wilton's No Objection on draft-ietf-bess-evpn-igmp-mld-proxy-14: (with COMMENT)

Hi Mankamana, Thank for the updates, given that these are only comments, so I'm happy to leave it you (and the AD) to decide how to address them. One comment inline ... From: Mankamana Mishra (mankamis) Sent: 08 December 2021 23:51 To: Rob Wilton (rwilton) ; The IESG Cc:

[bess] WGLC draft-ietf-bier-evpn

Please read the latest rev and respond. We cleared WGLC, then had a review in BESS with some feedback. The latest rev is now available: https://datatracker.ietf.org/doc/draft-ietf-bier-evpn/ I've included BESS in this LC as well to ensure their issues are met in this latest rev. We still need a

Re: [bess] Murray Kucherawy's Discuss on draft-ietf-bess-evpn-igmp-mld-proxy-14: (with DISCUSS and COMMENT)

On Wed, Nov 17, 2021 at 12:03 PM Mankamana Mishra (mankamis) < manka...@cisco.com> wrote: > (0) I suggest making each of the actions you want to take (there are four) > into > > their own subsections of this section. > Any thoughts on this point? (1) "EVPN Extended Community sub-types registry"

Re: [bess] A query regarding applicability of EVPN fast failover mechanisms to Port-Active multi-homing draft

Luc, Lots of thanks for a prompt response. I have missed the fact that, once DF calculation has been done, loss of the remote ES results in immediate re-calculation without any need for the DF election timer. My mistake. Regards, Sasha Office: +972-39266302 Cell: +972-549266302 Email:

Re: [bess] A query regarding applicability of EVPN fast failover mechanisms to Port-Active multi-homing draft

Hi Sasha, The DF-Election timer is only run on an interface recovery, not on failure, e.g. on PE1 PE-CE link recovery. In step 4.b.ii, there is no timer involved. Port-active is no different than other DF-election mechanisms: RT4 ES withdrawal by PE1 will trigger DF takeover at PE2. I am

[bess] A query regarding applicability of EVPN fast failover mechanisms to Port-Active multi-homing draft

Hi, A have a question regarding usage of EVPN fast failover mechanisms in combination with the port-active multi-homing mode as defined in the corresponding draft. Please configure the following scenario: 1. There are 3

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

Thanks Ajay There is consensus to adopt this draft as a BESS WG draft. Authors: Please republish the draft as draft-ietf-bess-ebgp-dmz-00. Best regards Matthew From: Ajay Kini Date: Thursday, 9 December 2021 at 13:21 To: Bocci, Matthew (Nokia - GB) Cc: Akshay Gattani , Lukas Krattiger

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

Ashkay, Thank you for your response. Strictly, I need a response from each individual author, otherwise I will have to ask the WG if they are happy to proceed. Ajay, please can you confirm whether or not you are aware of any undisclosed IPR? Thanks Matthew From: Akshay Gattani Date:

Re: [bess] Contradiction for the RFC 7432 definition of the fast convergence (withdrawal) for single-homed CEs

Eduard, Lots of thanks for a prompt response. I doubt "mass withdrawal" in the single-homed scenarios has real added value. However, even if it has, IMHO advertisement and withdrawal of per-ES EVPN Type 1 routes with zero ESI vale in their NLRI in any case will not help you to enjoy these

Re: [bess] Contradiction for the RFC 7432 definition of the fast convergence (withdrawal) for single-homed CEs

Hi Yubao, I just haven't noted that in RFC7432 a RT-1 per ES/EVI (with ESI=0) route should be advertised for each single-homed ES. Well, it is my reading of 5. Ethernet Segment: - ESI 0 denotes a single-homed site. Whether such

Re: [bess] Contradiction for the RFC 7432 definition of the fast convergence (withdrawal) for single-homed CEs

Hi Alexander, For sure, multi-homed scenario is the primary beneficiary from "mass-withdraw". Could I argue a little bit that it is valuable for "single-homed" too? 1. If MAC learning is in the data plane, then probably not much additional value from faster signaling. But it is: remote PE would

[bess] Queries on draft-ietf-bess-evpn-pref-df

Hi, I have a few questions with regard to draft-ietf-bess-evpn-pref-df: 1. The first statement in Section 4.4 of the draft says that "a capability to NOT preempt the existing DF for a given Ethernet Tag is required and

Re: [bess] Contradiction for the RFC 7432 definition of the fast convergence (withdrawal) for single-homed CEs

Eduard hi! I do not see any contradiction in your scenario. Mass withdrawal provides for (relatively) fast restoration of traffic that originally has been sent to a multi-homed customer site via one of the links comprising a multi-homed Ethernet Segment when this link fails. >From my POV

Re: [bess] Contradiction for the RFC 7432 definition of the fast convergence (withdrawal) for single-homed CEs

Hi Eduard, I just haven't noted that in RFC7432 a RT-1 per ES/EVI (with ESI=0) route should be advertised for each single-homed ES. RFC7432 just says that all RT-2 routes of a single-homed ES should be advertised with ESI=0, and then it MUST be installed into the dataplane based on

Re: [bess] Contradiction for the RFC 7432 definition of the fast convergence (withdrawal) for single-homed CEs

Hi Yubao For sure should be consistency: If ESI=0 in RT-1 then all subsequent RT-2 should have ESI=0 too. Just it is a discovery for me that "mass-withdraw" is not possible for single-homed ES. Eduard From: wang.yub...@zte.com.cn [mailto:wang.yub...@zte.com.cn] Sent: Thursday, December 9, 2021

Re: [bess] Contradiction for the RFC 7432 definition of the fast convergence (withdrawal) for single-homed CEs

Hi Eduard, It is just a configuration-decision whether to configure a single-homed ES with a non-zero ESI, thus it is not RFC violation from the viewpoint of the implementation. But if the RT-2 routes whose ESI is zero will not be installed unless there is an Ethernet A-D per ES route