Hi Jorge,
Lots of thanks for your explanation.
The IMET route will not be propagated so the F bit inside it will not be
propagated even if the L2 attr is not recognised by the L2 gateway.
But the flow label cannot be used for BUM packets, is this a design object to
avoid some other issues or just a result of the technical-restraints caused by
ESI label mechanisms?
If it is just a result of the technical-restraints caused by ESI label
mechanisms, whether an ELI label can be used or not?
If an ELI label can be used (may be an ELI flag can be added), I think it will
be helpful to improve the following use case:
PE1(F=1)-------------PE2(F=1)----------------(F=0)PE3
Above network has no original flow label configurations, but when it starts to
be configured with flow label commands, the configuration will be done one PE
by one PE (as shown in above figure), during the configuration the traffic
(e.g. from PE3 to PE2) will be dropped according current rfc7432bis.
But if an ELI label can be used, the flow label can be optional even if a F bit
is advertised.
I also don't understand the following description very well:
"When the L2-Attr Extended Community is received from a remote PE, flow label F
flag MUST be checked against local flow label enablement. If there is a
mismatch, the local PE MUST NOT add the remote PE as the EVPN destination for
any of the corresponding service instances. "
Literally I think it is saying that the remote PE MUST NOT be added as both BUM
destination and known-unicast destination. But I am not sure that it is
necessary. Because although the F bit is contained in IMET route but flow label
is not applied to BUM destination. So whether such remote PE can be added as
BUM destinations or not according to rfc7432bis?
"When sending EVPN-encapsulated packets over a P2MP LSP (either RSVP-TE or
mLDP), flow label SHOULD NOT be used. This is independant of any F-bit
signalling in the L2-Attr Extended Community which would still apply to
unicast."
Given that the flow label is not applied to BUM pakcets, and the known-unicast
packets will not use a P2MP LSP, what is the point this paragraph want to tell
us?
Literally it sounds like that when sending BUM packets over P2MP LSP, the
known-unicast packet (regardless of what tunnel it is using) cannot use a flow
label even if the F-bit is signalled.
Is it the point that it want to say?
Could you make the above more clear?
Thanks,
Yubao
原始邮件
发件人：JorgeRabadan(Nokia)
收件人：王玉保10045807;
抄送人：draft-ietf-bess-rfc7432...@ietf.org;bess@ietf.org;
日 期 ：2023年05月04日 11:26
主 题 ：Re: Re:Discussion about F (Flow label) bit of draft-ietf-bess-rfc7432bis
section 7.11
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. 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
) . 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
