Hi Vinayak,
The Bump-in-the-wire with a VLAN-aware BD is just slightly implied in the
terminlogy section of RFC9136.
It is not mentioned in the main body of RFC9136.
So a few critical details are still absent, while there may be already
different implementations up to now,
I think these implementations will not be considered as RFC violation.
If we want to use VLAN-aware BD in Bump-in-the-wire use case,
Technically the following rules should be followed:
1) the Ethernet Tag ID of the IP prefix route must be encapsulated into the
VLAN-ID of the inner ethernet header in the data plane.
But it doesn't mean that the Ethernet Tag ID should be used in the IP
lookup,
but other EVPN route's Ethernet Tag ID will all be used to do MAC/Multicast
lookup.
So I think the Ethernet Tag ID can't be considered as consistency with the
rest of the EVPN service routes up to now.
2) The Ethernet Tag ID of the IP prefix route must be used to select the
corresponding RT-1 route which is advertised along with a L2 EVI label.
The MPLS label of the RT-1 route is a L2 EVI label,
and that's why the Ethernet Tag ID must be encapsulated into the inner
ethernet header.
3) The IP prefix route must be advertised along with a non-zero supplementary
(to the ESI) overlay index
If we don't do this, we don't know how to select the corresponding RT-1
route for that IP prefix route,
Because that the RT-1 per EVI routes of the Bump-in-the-wire use case are
totally advertised in the context of a VLAN-aware BD.
Actually, these RT-1 per EVI routes will be the same RT-1 per EVI routes
which are used by the MAC-forwarding of that VLAN-aware BD.
But whether the supplementary overlay index is the Ethernet Tag ID,
it is not explicitly described in RFC9136.
However, in RFC9136 section 3, the Ethernet Tag ID is excluded from the
construction of "Overlay Index".
Although in other EVPN service (e.g. EVPN MAC forwarding),
the Ethernet Tag ID is considered to be part of the "overlay index" for
MAC/Multicast forwarding.
4) The MAC address of the IRB interface of that VLAN-aware BD should be
encapsulated as the source MAC of the inner ethernet header in the data plane.
Other details are not explicitly described in RFC9136 (even that whether such
RT-5 route is advertised in the context of the VLAN-aware BD is not explicitly
described)
and can't be inferred from the scenario of VLAN-agnostic BDs either,
so I think different existing implementations may have different choices.
But the non-zero ethernet Tag ID can't be simply ignored,
it can be ignored in a few procedures, but not all procedures.
But in RFC9136's section 3, It seems that the ethernet Tag ID is not cosidered
as a part of overlay index,
That's why I am not sure how the recursive route resolution would be done,
I think different existing implementations may have different choices too. For
example:
Some implementations may consider that these RT-5 routes don't need to be
recursively resolved in the context of the IP-VRF,
because that in control plane these RT-5 routes are just imported into the BD,
not imported into the IP-VRF,
and from the BD, they can be directly installed into the IP-VRF just when the
control plane procedures are about to be finished.
So the recursive route resolution can be totally done in the context of the BD
technically.
Regards,
Yubao
原始邮件
发件人：Joshi,Vinayak
收件人：王玉保10045807;jorge.raba...@nokia.com;
抄送人：bess@ietf.org;jdr...@juniper.net;
日 期 ：2021年12月05日 16:44
主 题 ：RE: [bess] Query about Ethernet Tag Id for TYpe-5 routes (RFC 9136)
Hi Jorge & Yubao,
In the most common use cases an IP prefix route has to be unique with an VRF.
The VPN Label/L3VNI brings in this separation of IP prefixes even for
VLAN-aware bundling.
(With all L2 routes the Ethernet Tag has to be non-zero for VLAN-aware BD for
sure to distinguish BDs).
In case of VLAN aware BD implementations that do NOT need BD level distinction
of IP prefixes, would it be considered RFC violation if -
1) EVPN speaker sends out a zero Ethernet tag in its RT-5.
2) Ignores the non-zero Ethernet tag in the incoming RT-5 routes.
Regards,
Vinayak
From: wang.yub...@zte.com.cn [mailto:wang.yub...@zte.com.cn]
Sent: Saturday, December 4, 2021 9:56 AM
To: jorge.raba...@nokia.com
Cc: bess@ietf.org; Joshi, Vinayak <vinayak.jo...@hpe.com>; jdr...@juniper.net
Subject: Re: [bess] Query about Ethernet Tag Id for TYpe-5 routes (RFC 9136)
Hi Jorge and Vinayak,
I don't understand this use case of RFC9136 very well either,
because when a BD of VLAN-aware bundle EVI is used in Bump-in-the-wire use case,
I don't sure how the IP prefixes routes are recursively rosolved.
I hope to share my understandings to help to make this use case more clear.
When an IP Prefix route is advertised in the context of a VLAN-aware BD, and
the IP Prefix route would be using a non-zero Ethernet Tag ID,
The overlay index of the IP prefix route should be considered to be the <ESI,
Ethernet Tag ID> or just the ESI?
In section 3 of RFC9136, I see that only the ESI is considered to be the
overlay index.
Thanks,
Yubao
On Fri, 3 Dec 2021 17:03:48 +0000
"Rabadan, Jorge (Nokia - US/Mountain View)" <jorge.raba...@nokia.com> wrote:
> Hi again,
>
> John pointed to me that there are some cases where a non-zero Ethernet Tag ID
> on the IP Prefix route may be used in RFC9136.
>
> In the RFC9136 IP-VRF-to-IP-VRF use cases, the Ethernet Tag ID is always
> zero, since the IP Prefix route is advertised in the context of the IP-VRF.
> However it is true that RFC9136 also discusses some use-cases where the IP
> Prefix route is advertised in the context of a BD, in which case, if the BD
> belongs to a VLAN-aware bundle EVI, the IP Prefix routes would be using a
> non-zero Ethernet Tag ID.
>
> I overlooked that when I replied first.
> Thanks John.
>
> Jorge
>
> From: Rabadan, Jorge (Nokia - US/Mountain View) <jorge.raba...@nokia.com>
> Date: Thursday, December 2, 2021 at 6:00 PM
> To: Joshi, Vinayak <vinayak.jo...@hpe.com>, bess@ietf.org <bess@ietf.org>
> Subject: Re: Query about Ethernet Tag Id for TYpe-5 routes (RFC 9136)
> Hi Vinayak,
>
> RFC9136 does not have any use case for the use of a non-zero ethernet tag id.
> The IP Prefix route includes the ethernet tag id as part of the key for
> consistency with the rest of the EVPN service routes, for future use.
>
> Thanks.
> Jorge
>
> From: BESS <bess-boun...@ietf.org> on behalf of Joshi, Vinayak
> <vinayak.jo...@hpe.com>
> Date: Thursday, December 2, 2021 at 7:33 AM
> To: bess@ietf.org <bess@ietf.org>
> Subject: [bess] Query about Ethernet Tag Id for TYpe-5 routes (RFC 9136)
> Hi all,
>
> RFC 9136 says the following (Section 3.1)
>
>
> “ The RD, Ethernet Tag ID, IP prefix length, and IP prefix are part of
> the route key used by BGP to compare routes. The rest of the fields
> are not part of the route key.
>
> With VLAN Aware Bundling the Eth Tag ID acts as a distinguisher for the
> routes while importing into L2-VRF.
> But for L3 prefix routes what is the use case for setting the Ether Tag ID to
> any non-zero value?
>
> Thanks in advance,
> Vinayak_______________________________________________
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess
