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 PEs (which don't expect the
mass-withdraw feature for their single-homed ESes) from the ordinary route
resolution procedures.,
just because these PEs don't advertise RT-1 per ES route for single-homed ESes.
The receiving PEs can provide none of the mass-withdraw features for these
current PEs,
but the receiving PEs should still provide the ordinary route resolution
functions for them.
Please note that section 5 of RFC7432 is not saying that a RT-1 per ES route
should be advertised for a single-homed site,
it is just saying that whether a RT-1 per ES route is advertised for a
single-homed site or not,
the reserved ESI 0 can always be used to denote a single-homed site.
There is another factor to prevent the zero ESI RT-1 per ES to be used to do
mass-withdraw,
Because that in E-Tree scenarios, it is used to advertise the Leaf label, both
for single-homed Leafs and for multi-homed leafs.
In such case, a zero ESI RT-1 per ES route should be advertised even if all
single-homed ESes have failed already.
If there are any explicit describing of current PEs following RFC7432 should
advertise a RT-1 per ES/EVI route for a single-homed ES, I would appreciate it
if you could point it out.
Yubao
原始邮件
发件人：VasilenkoEduard
收件人：王玉保10045807;
抄送人：yuya...@yuyarin.net;bess@ietf.org;
日 期 ：2021年12月09日 20:35
主 题 ：RE: 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 RT-1 per ES route is advertised to the receiving PE or not,
It just does not make sense, because ESI=0 could mean many ESs (many different
physical ports) on this EVI of this PE. Not possible to guess which one has
failed.
I agree with you that you have pointed to the second place in the draft that
blocks “mass withdraw” for single-homed.
But this second restriction is easy to edit in 9.2.2. Route Resolution.
The concept of ESI=0 for single-homed would be difficult to change – it is in
many paces of the draft.
Hence, no problem, anyone who would like “mass withdraw” could use a
work-around to treat all ESIs as multi-homed.
Eduard
From: wang.yub...@zte.com.cn [mailto:wang.yub...@zte.com.cn]
Sent: Thursday, December 9, 2021 12:30 PM
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,
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 only the RT-2 route
itself (no matter whether there will be a zero ESI RT-1 or not) by the
receiving PE.
Whether such RT-1 per ES route is advertised to the receiving PE or not,
It will not influence the processing of the RT-2 route on the receiving PE.
So the route resolution for zero ESI RT-2 is actually not consistent with
non-zero ESI RT-2 as per RFC7432.
thus the advertisement for zero ESI is technically not necessary to be
consistent with non-zero either.
Yubao
原始邮件
发件人：VasilenkoEduard
收件人：王玉保10045807;
抄送人：yuya...@yuyarin.net;bess@ietf.org;
日 期 ：2021年12月09日 16:45
主 题 ：RE: 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 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;
日 期 ：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]
Sent: Thursday, December 9, 2021 4:37 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,
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> 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>;
> 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
> > https://www.ietf.org/mailman/listinfo/bess
> >
>
> _______________________________________________
> 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
