Just to finish this thread in the WG list, we had a sidebar discussion. It appears that ERL label distributed in extended EAD/EVI can be a MAC-VRF label (depending on local implementation) and hence when a redirected packet is received, MH peer would do lookup on MAC DA. If it is known UNICAST it would forward it out to the ESI.
If BUM, it will get broadcasted to all local ACs associated with the MAC VRF which will result in duplicates. Hence the reason to “not support redirection for BUM”. However, if we choose to provide explicit additional forwarding semantics which says that packet received with ERL is a redirected packet from MH peer and hence must be sent to respective local ESI without DMAC lookup then BUM packets can also be redirected from a DF MH-peer to NDF MH-peer, when DF MH-peer’s local ESI is down. Thanks, Himanshu From: Shah, Himanshu <hshah=40ciena....@dmarc.ietf.org> Date: Monday, November 4, 2024 at 8:52 PM To: Luc André Burdet <laburdet.i...@gmail.com>, Boutros, Sami <sboutros=40ciena....@dmarc.ietf.org>, BESS <bess@ietf.org> Subject: [**EXTERNAL**] [bess] Re: Few questions about https://www.ietf.org/archive/id/draft-burdet-bess-evpn-fast-reroute-08.txt Actually, not advertising ERL for conflicted ESI+EVI+VLAN is probably not a good idea since it will lose benefit for known unicasts.. ☹ Let me sync up with you, if you are attending the IETF or will sync up with Jorge or Patrice.. Thanks, Himanshu From: Shah, Himanshu <hs...@ciena.com> Date: Monday, November 4, 2024 at 8:02 PM To: Luc André Burdet <laburdet.i...@gmail.com>, Boutros, Sami <sboutros=40ciena....@dmarc.ietf.org>, BESS <bess@ietf.org> Subject: Re: Few questions about https://www.ietf.org/archive/id/draft-burdet-bess-evpn-fast-reroute-08.txt [ietf.org]<https://urldefense.com/v3/__https:/www.ietf.org/archive/id/draft-burdet-bess-evpn-fast-reroute-08.txt__;!!OSsGDw!NG4308PM0stpHgb2szHtEkRK6KmbUtAY9n0S8WaJKhL3mmocB06CME9g2X-_reSE-6V8fkUqWi7Wc89vy8ZSOhdef50$> In line.. Thanks, Himanshu From: Luc André Burdet <laburdet.i...@gmail.com> Date: Monday, November 4, 2024 at 6:16 PM To: Shah, Himanshu <hs...@ciena.com>, Boutros, Sami <sboutros=40ciena....@dmarc.ietf.org>, BESS <bess@ietf.org> Subject: [**EXTERNAL**] Re: Few questions about https://www.ietf.org/archive/id/draft-burdet-bess-evpn-fast-reroute-08.txt [ietf.org]<https://urldefense.com/v3/__https:/www.ietf.org/archive/id/draft-burdet-bess-evpn-fast-reroute-08.txt__;!!OSsGDw!NG4308PM0stpHgb2szHtEkRK6KmbUtAY9n0S8WaJKhL3mmocB06CME9g2X-_reSE-6V8fkUqWi7Wc89vy8ZSOhdef50$> Hi Himanshu, If BUM is brought into scope, redirecting from Failed-NDF to DF would cause issues: DF will have duplicates. Only Failed-DF to NDF can be supported in a straightforward manner. Himanshu> Not sure why failed-NDF would consider redirection, the packet was not eligible for to be forwarded to ES (failed ES or not). However, BUM is (usually) ingress-replicated to both peering PEs. Consider ingress-replicated traffic to a pair of peering PEs with multiple ACs. If the AC/s (ESIs) are not DF-Elected symmetrically (such as may occur with HRW DF Election) then redirected traffic would flood at the peer side also -> potentially egressing an NDF AC2 which was DF at the redirecting node and already sent the BUM packet to attached AC. Himanshu> If there is a case whereby on a given ESI+EVI, for some VLANs node A is DF and for the same ESI+EVI, other VLANs he is NDF, then ERL should not be advertised nor used, IMO. This will avoid need for granular ERL. The point is to be able to take advantage of ERL as much as possible. Supporting this would require more complex behaviours (like finer-granularity redirect labels, specific to each AC or other considerations) for little benefit: traffic loss is usually most-relevant for known unicast flows. Regards, Luc André Luc André Burdet | Cisco | laburdet.i...@gmail.com | Tel: +1 613 254 4814 From: Shah, Himanshu <hs...@ciena.com> Date: Monday, November 4, 2024 at 11:36 To: Luc André Burdet <laburdet.i...@gmail.com>, Boutros, Sami <sboutros=40ciena....@dmarc.ietf.org>, BESS <bess@ietf.org> Subject: Re: Few questions about https://www.ietf.org/archive/id/draft-burdet-bess-evpn-fast-reroute-08.txt [ietf.org]<https://urldefense.com/v3/__https:/www.ietf.org/archive/id/draft-burdet-bess-evpn-fast-reroute-08.txt__;!!OSsGDw!IzrR5Tl48NFvIi8TyuKyej5yy4zhntWYkmYRuvZ_YGGRdL8Nrhz74JQUY2njaPj-Reo31HNiTeTyxPfOcBw$> Hmm that is interesting.. I would have thought BUM would be in scope. If a node is DF elected and receives BUM and if his ES is down why can he not redirect to NDF? NDF, by virtue of getting traffic on ERL could then bypass the DF election status and forward it to that local ESI.. Thanks, Himanshu From: Luc André Burdet <laburdet.i...@gmail.com> Date: Monday, November 4, 2024 at 3:23 PM To: Boutros, Sami <sboutros=40ciena....@dmarc.ietf.org>, BESS <bess@ietf.org> Subject: [**EXTERNAL**] [bess] Re: Few questions about https://www.ietf.org/archive/id/draft-burdet-bess-evpn-fast-reroute-08.txt [ietf.org]<https://urldefense.com/v3/__https:/www.ietf.org/archive/id/draft-burdet-bess-evpn-fast-reroute-08.txt__;!!OSsGDw!IzrR5Tl48NFvIi8TyuKyej5yy4zhntWYkmYRuvZ_YGGRdL8Nrhz74JQUY2njaPj-Reo31HNiTeTyxPfOcBw$> Hi Sami, Yes, BUM is out of scope – Sasha already raised this question and it looks like I forgot to add the clarifying statement. I will in next rev. * IMHO and FWIW an explicit statement that “BUM is not in-scope of the draft, it is not redirected” would help the readers. It would also help to clarify that bypassing DF Election behavior is not relevant for All-Active and Single Flow-Active redundancy modes. You are correct on the DF-bypass redundancy modes; However for the draft itself I am not typing specific behaviours to load-balancing modes: Backup-DF blocking is bypassed if/when applicable. Regards, Luc André Luc André Burdet | Cisco | laburdet.i...@gmail.com | Tel: +1 613 254 4814 From: Boutros, Sami <sboutros=40ciena....@dmarc.ietf.org> Date: Thursday, October 24, 2024 at 11:21 To: BESS <bess@ietf.org> Subject: [bess] Few questions about https://www.ietf.org/archive/id/draft-burdet-bess-evpn-fast-reroute-08.txt [ietf.org]<https://urldefense.com/v3/__https:/www.ietf.org/archive/id/draft-burdet-bess-evpn-fast-reroute-08.txt__;!!OSsGDw!O8kCFeJxk_vSiAVDJ3R7FC_JZhfwG_s2NJkVkMPiIg-crNmp9hai86eo9_4Pa17nl3pmaF4v1f6ObYH-WAA$> Hi, It is not clear in the draft, if you are redirecting BUM traffic or not? I assume you are not redirecting BUM traffic. In what redundancy mode will you need to override the DF election? Is it only for single active and port active? Thanks, Sami
_______________________________________________ BESS mailing list -- bess@ietf.org To unsubscribe send an email to bess-le...@ietf.org
