Hi Jeffrey, Please see my comments below
From: Jeffrey (Zhaohui) Zhang <zzhang=40juniper....@dmarc.ietf.org<mailto:zzhang=40juniper....@dmarc.ietf.org>> Date: Wednesday, May 28, 2025 at 1:45 PM To: bess@ietf.org<mailto:bess@ietf.org> <bess@ietf.org<mailto:bess@ietf.org>> 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 -- bess@ietf.org<mailto:bess@ietf.org> To unsubscribe send an email to bess-le...@ietf.org<mailto:bess-le...@ietf.org>
_______________________________________________ BESS mailing list -- bess@ietf.org To unsubscribe send an email to bess-le...@ietf.org
