Hi Yubao, My previous email was not about L3 gateways either. RFC9014 defines L2 EVPN gateways for ELAN services.
rfc7432bis defines that the signaling of flow label, CW or MTU for EVPN ELAN services is done in the IMET route, not the A-D per EVI route. This is irrespective of the flow label only being used for known unicast traffic. Thanks. Jorge From: wang.yub...@zte.com.cn <wang.yub...@zte.com.cn> Date: Wednesday, May 3, 2023 at 6:28 PM 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, The gateway in my previous mail is not a L3 gateway. We can take a virtual hub node of https://datatracker.ietf.org/doc/html/draft-ietf-bess-evpn-virtual-hub-00 for an example, as I had mentioned in the previous mail. Such L2 gateway is a bit like the gateway of draft-sr-bess-evpn-vpws-gateway<https://datatracker.ietf.org/doc/draft-sr-bess-evpn-vpws-gateway/>. But here is EVPN VPLS scenario. The route propagation is not about IMET routes, which may not carry the F bit because BUM cannot use a flow label. An example for the propagation is the route relay which is done by a virtual hub node for a virtual spoke node's Ethernet A-D per EVI routes. When such route-relay is done by a PE which has no knowledge of L2 Attr EC for a virtual spoke which has an implementation of rfc7432bis , there may be some issues that should be concerned. Such gateway is not defined in rfc7432bis, but I think a rfc7432bis node may need to cowork with such gateway. Thanks, Yubao 原始邮件 发件人：JorgeRabadan(Nokia) 收件人：王玉保10045807; 抄送人：draft-ietf-bess-rfc7432...@ietf.org;bess@ietf.org; 日 期 ：2023年04月28日 22:02 主 题 ：Re: Re:Discussion about F (Flow label) bit of draft-ietf-bess-rfc7432bis section 7.11 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
