Hi Yubao, Thanks for explaining!
RFC7432 never described a gateway functionality. RFC9014 does, that’s what I tried to say, but I see what you mean. However, if you have a gateway with a MAC-VRF instantiated and that gateway does not support the decapsulation of the flow label, the gateway will never add F=1 in its IMET route to either of the two domains. There is no propagation of IMET routes on a RFC9014 gateway, but origination on each domain. So I don’t see any issue here. Let me know if I understood your concern. Thanks. Jorge From: wang.yub...@zte.com.cn <wang.yub...@zte.com.cn> Date: Friday, April 28, 2023 at 4:09 AM To: Jorge Rabadan (Nokia) <jorge.raba...@nokia.com> Cc: draft-ietf-bess-rfc7432...@ietf.org <draft-ietf-bess-rfc7432...@ietf.org>, bess@ietf.org <bess@ietf.org> Subject: Re: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 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<https://datatracker.ietf.org/doc/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<https://datatracker.ietf.org/doc/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<https://datatracker.ietf.org/doc/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
