Hi Jorge,
Thank you for your response.
I talk about EVPN VPLS per
https://datatracker.ietf.org/doc/html/draft-ietf-bess-rfc7432bis-07#name-evpn-layer-2-attributes-ext.
That section of rfc7432bis extends L2-Attr EC (which is defined in EVPN VPWS)
to EVPN VPLS.
And my case 2 taks about a gateway which only implements RFC7432, it doesn't
recognize L2-Attr EC (this is different from draft-sr-bess-evpn-vpws-gateway
) . What I want to know is whether there is a solution under the existing
RFC/drafts. I think there may be packet decapsulation error in case 2 following
current rfc7432bis.
If there is a solution using existing mechanisms and those mechanisms is an
option of a RFC, I think it will be better to mention that mechanism in the
corresponding section of rfc7432bis,because in such case it is required in
order to avoid traffic loss when rfc7432bis cowork with existing old devices.
And I think
https://datatracker.ietf.org/doc/html/draft-ietf-bess-evpn-virtual-hub-00 may
need to refer to rfc7432bis,and requires the implementation of L2-Attr EC is a
SHOULD or MUST, because otherwise a virtual hub (which doesn't recognized a
L2-Attr and can't decapsulate Flow label) cannot cowork with a rfc7432-enabled
virtual spoke (which signalled F bit in L2-Attr EC).
Thanks,
Yubao
原始邮件
发件人：JorgeRabadan(Nokia)
收件人：王玉保10045807;draft-ietf-bess-rfc7432...@ietf.org;
抄送人：bess@ietf.org;
日 期 ：2023年04月28日 01:51
主 题 ：Re: Discussion about F (Flow label) bit of draft-ietf-bess-rfc7432bis
section 7.11
Hi Yubao,
Since you are referring to the A-D per EVI route signaling the F bit, I assume
you talk about EVPN VPWS, however you mention MAC-VRF, so that’s confusing.
The case you are describing – propagation of the L2-attributes extended
community when readvertising the A-D per EVI or IMET route – is for sure out of
the scope of rfc7432bis.
Your case 1 sounds like an inter-domain model B case, which is covered by
draft-rabadan-bess-evpn-inter-domain-opt-b. In this case, the Border Router
just preserves the FAT label.
Your case 2 sounds like a service gateway model (RFC9014 for multi-point L2 and
draft-sr-bess-evpn-vpws-gateway for EVPN VPWS). In this case, the gateway may
change the F flag depending on its capabilities.
Please have a look and let us know if you have comments.
Thanks.
Jorge
From: wang.yub...@zte.com.cn <wang.yub...@zte.com.cn>
Date: Tuesday, April 25, 2023 at 8:33 AM
To: draft-ietf-bess-rfc7432...@ietf.org <draft-ietf-bess-rfc7432...@ietf.org>
Cc: bess@ietf.org <bess@ietf.org>
Subject: Discussion about F (Flow label) bit of draft-ietf-bess-rfc7432bis
section 7.11
CAUTION: This is an external email. Please be very careful when clicking links
or opening attachments. See the URL nok.it/ext for additional information.
Hi all,
The F bit is defined in EVPN L2-Attr extended community of
draft-ietf-bess-rfc7432bis-07.
When the RT-1 per EVI route including that L2-attr pass through a node which
does not recognize a L2-attr EC, there will be two cases:
Case1: that node change the MPLS label of that RT-1 per EVI to a label whose
label operation is a swap.
Case2: that node change the MPLS label of that RT-1 per EVI to a label whose
label operation is a pop, and that second label identifies a local MAC-VRF.
In either of these two cases, that node may propagate that L2-attr to other PEs
(i.e. PE3),
but in case 2 it will cause those PEs to send a flow label to it, while it
cannot decapsulate that flow label thus packet drop may happen.
Is there any solution to make those two cases distinguish from each other (from
the viewpoint of the target receiving PE PE3) ?
Thanks,
Yubao
_______________________________________________
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess
