Hi Ali,
I want to come back to this thread because of what Sasha pointed out in
https://mailarchive.ietf.org/arch/msg/bess/FmYtsY6xA1GBRStZ2dZH5YhunyQ/.
This email was about the following text:
Note that the above allows the Ethernet A-D per EVI route to be
advertised with one of the following granularities:
* One Ethernet A-D route per <ESI, Ethernet Tag ID> tuple per
MAC-VRF. This is applicable when the PE uses MPLS-based
disposition with VID translation or may be applicable when the PE
uses MAC-based disposition with VID translation.
* One Ethernet A-D route for each <ESI> per MAC-VRF (where the
Ethernet Tag ID is set to 0). This is applicable when the PE uses
MAC-based disposition or MPLS-based disposition without VID
translation.
Our earlier conversation concluded that the VID would not be used to identify
the BT. But apparently, an implementation could advertise the same label for
different Tag IDs and rely on <VID, label> to identify the BT in the case of no
VID translation.
Therefore, another bullet point could be added to the above.
Thanks.
Jeffrey
Juniper Business Use Only
From: Ali Sajassi (sajassi) <[email protected]>
Sent: Monday, June 2, 2025 6:31 PM
To: Jeffrey (Zhaohui) Zhang <[email protected]>; [email protected]
Subject: Re: label scheme in EVPN A-D per EVI routes
[External Email. Be cautious of content]
Hi Jeffrey,
Please see my comments below
From: Jeffrey (Zhaohui) Zhang
<[email protected]<mailto:[email protected]>>
Date: Wednesday, May 28, 2025 at 1:45 PM
To: [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>>
Subject: [bess] label scheme in EVPN A-D per EVI routes
Hi,
This is another question coming out of the shepherd review of RFC7432bis.
In the following text, what does "disposition" mean exactly? Just "forwarding"?
Ali> It means forwarding in the disposition direction – i.e., from core to
access
Note that the above allows the Ethernet A-D per EVI route to be
advertised with one of the following granularities:
* One Ethernet A-D route per <ESI, Ethernet Tag ID> tuple per
MAC-VRF. This is applicable when the PE uses MPLS-based
disposition with VID translation or may be applicable when the PE
uses MAC-based disposition with VID translation.
Is it that the label alone will identify the outgoing AC w/o a MAC lookup, and
it can also identify bridge table in which a MAC lookup is done?
Ali> That’s correct.
Zzh> The key here is that non-zero Tag is used, and labels are different based
on the tag value so that in the MAC lookup case the label can lead to the BT.
Zzh> I suppose this is only for vlan-aware bundle.
Ali>> Exactly! In case of MAC lookup, this applies to VLAN-aware bundle or
vlan-based service interfaces where label identifies specific BT of a MAC-VRF
(I am adding some text to say that).
* One Ethernet A-D route for each <ESI> per MAC-VRF (where the
Ethernet Tag ID is set to 0). This is applicable when the PE uses
MAC-based disposition or MPLS-based disposition without VID
translation.
Is it that the VID in the packet plus the label will determine the outgoing AC
or the bridge table in which a MAC lookup is done?
Ali> In case of MAC-based disposition (i.e., using MAC lookup), the received
MPLS label identifies the bridge table, and the MAC lookup is performed there.
In case of MPLS-based disposition, the received MPLS label identifies, egress
port; however, no VID translation can be done for that port. I will change “or”
or “or,” in the above sentence.
Zzh> Initially I was wondering if this was also applicable to the vlan-aware
bundle case, hence the question – would the incoming VID also be used to
determine the BT in the mac-based forwarding.
Ali>> That’s correct. The applicability is for vlan-bundle or port-based
service interfaces (I am adding some text to say that). Since Ethernet Tag ID
is set to zero in this case, vlan look up is not performed to identify BT.
Zzh> Now I suppose it is really just for the vlan-bundle case and the label
alone determines the BT. If that’s the case, then the whole text here is only
adding confusion, because the route is always one per <ESI, Ethernet Tag ID>
tuple per MAC-VRF – in the vlan-bundle case the Tag ID is 0.
Ali>> Yes, but when you set the Tag ID to zero, then the granularity is at the
<ESI> level and that’s what the text says.
Cheers,
Ali
Zzh> Is my understanding correct?
Zzh> Thanks.
Zzh> Jeffrey
Thanks.
Jeffrey
Juniper Business Use Only
_______________________________________________
BESS mailing list -- [email protected]<mailto:[email protected]>
To unsubscribe send an email to [email protected]<mailto:[email protected]>
_______________________________________________
BESS mailing list -- [email protected]
To unsubscribe send an email to [email protected]
