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 11:14 AM To: Vasilenko Eduard <vasilenko.edu...@huawei.com> Cc: yuya...@yuyarin.net; bess@ietf.org Subject: 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 whose ESI is also zero, It will be considered as RFC violation as per RFC7432 section 9.2.2. Yubao 原始邮件 发件人：VasilenkoEduard 收件人：王玉保10045807; 抄送人：yuya...@yuyarin.net;bess@ietf.org<mailto:yuya...@yuyarin.net;bess@ietf.org>; 日 期 ：2021年12月09日 15:21 主 题 ：RE: [bess] Contradiction for the RFC 7432 definition of the fast convergence (withdrawal) for single-homed CEs Hi Yubao, Thanks for the comment. I think more and have not understood too how "mass-withdraw" is possible with single-homed sites. Section 5 instructs us to use ESI=0 for single-homed sites. EVI could have many Ethernet Segments connected on 1 PE, all would be with ESI=0 for single-homed. Then I do not see what to signal to the remote to start "mass-withdraw". {EVI=X, ESI=0} would mean many physical Ethernet Segments in this case, no possibility to point to one particular Ethernet Segment (with broken port to CE). Hence, if one would like to have "mass-withdraw" Then all Ethernet Segments should be numbered (ESI>0). It is probably a little violation of RFC 7432 because ESI should be 0 for single-homed (section 5). But it would probably work because it would look like a situation with a redundant ESI connection permanently down. I am not 100% sure that would be any other negative consequences. Eduard From: wang.yub...@zte.com.cn<mailto:wang.yub...@zte.com.cn> [mailto:wang.yub...@zte.com.cn] Sent: Thursday, December 9, 2021 4:37 AM To: Vasilenko Eduard <vasilenko.edu...@huawei.com<mailto:vasilenko.edu...@huawei.com>> Cc: yuya...@yuyarin.net<mailto:yuya...@yuyarin.net>; bess@ietf.org<mailto:bess@ietf.org> Subject: Re: [bess] Contradiction for the RFC 7432 definition of the fast convergence (withdrawal) for single-homed CEs Hi Eduard, I don't think an Ethernet A-D per ES route with a zero ESI is better to use, Because each single-homed CE is an individual ES, that's why MAC mobility happens between two zero ESIs (for different single-homed ethernet segments) but not happens between the same ESI (local and remote). And I think such Ethernet A-D per ES route can't achieve the expected "mass-withdraw" behavior actually, Because it may not influence the installing of the RT-2 routes whose ESI are zero. If we want to use such Ethernet A-D per ES route to achieve mass-withdraw behavior, I think it will be difficult for us to decide when to trigger the mass-withdraw too. Please see section 9.2.2 of RFC7432: "9.2.2. Route Resolution If the Ethernet Segment Identifier field in a received MAC/IP Advertisement route is set to the reserved ESI value of 0 or MAX-ESI, then if the receiving PE decides to install forwarding state for the associated MAC address, it MUST be based on the MAC/IP Advertisement route alone." Regards, Yubao On Wed, 8 Dec 2021 09:28:27 +0000 Vasilenko Eduard <vasilenko.edu...@huawei.com<mailto:vasilenko.edu...@huawei.com>> wrote: > Hi Yuya, > Thanks. > Your explanation looks reasonable because section 8.2: > " If no other PE had advertised an Ethernet A-D route for the same segment, > then the PE that received the withdrawal simply invalidates the MAC entries > for that segment." > Does not say "MUST" or "SHOULD". > But the word "may" in this sentence was better to use. > OK. I understood. It is an optional feature that was not claimed optional > plainly. > Eduard > -----Original Message----- > From: BESS [mailto:bess-boun...@ietf.org] On Behalf Of Yuya KAWAKAMI > Sent: Wednesday, December 8, 2021 3:58 AM > To: Vasilenko Eduard > <vasilenko.eduard=40huawei....@dmarc.ietf.org<mailto:vasilenko.eduard=40huawei....@dmarc.ietf.org>>; > bess@ietf.org<mailto:bess@ietf.org> > Subject: Re: [bess] Contradiction for the RFC 7432 definition of the fast > convergence (withdrawal) for single-homed CEs > > Hi Eduard, > > As my understanding, these statements are not contradictory because mass > withdrawal is an optional functionality. > Section 8.3 says when PEs are operating All-Active redundancy mode, Ethernet > A-D per Ethernet Segment Route must be advertised for split horizon. > This would be reason why section 8.2.1 says "not needed" in case of > single-homed scenarios. > > I understand these sentences as: > - Implementations can use Ethernet A-D per ES routes to achieve mass > withdrawal for single-homed CE (optional) > - If Implementations want to achieve mass withdrawal, Ethernet A-D per ES > routes should be used > > The implementation I'm using does not support mass withdrawal for > single-homed CE. > > If there is any misunderstanding, I would appreciate it if you could point it > out. > > Thanks, > Yuya > > On 2021/12/08 4:24, Vasilenko Eduard wrote: > > Hi EVPN guru, > > > > It looks like RFC 7432 section 8.2.1 (Constructing Ethernet A-D per > > Ethernet Segment Route) has an error: > > "The Ethernet A-D route is not needed when the Segment Identifier is set to > > 0 (e.g., single-homed scenarios)." > > > > Because without "per ES route" it would not be possible to signal > > "mass withdrawal" If CE-PE connection would fail That plainly promised for > > single-homed CEs in section 8.2: > > " If no other PE had advertised an Ethernet A-D route for the same segment, > > then the PE that received the withdrawal simply invalidates the MAC entries > > for that segment." > > Or implied in section 17.3: > > "The Ethernet A-D per ES routes should be used by an implementation to > > optimize the withdrawal of MAC/IP Advertisement routes." > > > > Have I missed something? > > > > Eduard > > > > _______________________________________________ > > BESS mailing list > > BESS@ietf.org<mailto:BESS@ietf.org> > > https://www.ietf.org/mailman/listinfo/bess > > > > _______________________________________________ > BESS mailing list > BESS@ietf.org<mailto:BESS@ietf.org> > https://www.ietf.org/mailman/listinfo/bess > > >
_______________________________________________ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
