Saumya I have raised this with the authors but I believe several are out at the moment. Please give them time to consider your comments and respond.
Thanks Matthew From: Dikshit, Saumya <[email protected]> Date: Thursday, 13 August 2026 at 08:46 To: Dikshit, Saumya <[email protected]>; [email protected] <[email protected]>; [email protected] <[email protected]>; [email protected] <[email protected]>; Jorge Rabadan (Nokia) <[email protected]>; Wen Lin <[email protected]>; [email protected] <[email protected]> Cc: BESS <[email protected]> Subject: Re: draft-ietf-bess-evpn-first-hop-security-01: optional scoping for DSR distribution when a BD spans fabrics 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. Hello @[email protected]<mailto:[email protected]> , Authors of draft-ietf-bess-evpn-first-hop-security-01 It will be great to hear from anyone who is seeing this email chain. Thanks, Saumya. From: Dikshit, Saumya <[email protected]> Date: Saturday, 8 August 2026 at 9:24 AM To: Dikshit, Saumya <[email protected]>; [email protected] <[email protected]>; [email protected] <[email protected]>; [email protected] <[email protected]>; [email protected] <[email protected]>; Wen Lin <[email protected]>; [email protected] <[email protected]> Cc: BESS <[email protected]> Subject: Re: draft-ietf-bess-evpn-first-hop-security-01: optional scoping for DSR distribution when a BD spans fabrics Hello Authors, @[email protected]<mailto:[email protected]> Waiting for the response Saumya. From: Dikshit, Saumya <[email protected]> Date: Thursday, 6 August 2026 at 12:55 AM To: Dikshit, Saumya <[email protected]>; [email protected] <[email protected]>; [email protected] <[email protected]>; [email protected] <[email protected]>; [email protected] <[email protected]>; Wen Lin <[email protected]>; [email protected] <[email protected]> Cc: BESS <[email protected]> Subject: Re: draft-ietf-bess-evpn-first-hop-security-01: optional scoping for DSR distribution when a BD spans fabrics Hello Authors, Hoping to get a response !!! Thanks, in advance, Saumya. ________________________________ From: Dikshit, Saumya <[email protected]> Sent: Tuesday, August 4, 2026 3:20:19 pm To: Dikshit, Saumya <[email protected]>; [email protected] <[email protected]>; [email protected] <[email protected]>; [email protected] <[email protected]>; [email protected] <[email protected]>; Wen Lin <[email protected]>; [email protected] <[email protected]> Cc: BESS <[email protected]> Subject: Re: draft-ietf-bess-evpn-first-hop-security-01: optional scoping for DSR distribution when a BD spans fabrics Hello Authors of draft-ietf-bess-evpn-first-hop-security , BESS-WG members, It will be great to hear back from anyone who can do so. Thanks, Saumya. From: Dikshit, Saumya <[email protected]> Date: Saturday, 1 August 2026 at 3:56 PM To: Dikshit, Saumya <[email protected]>; [email protected] <[email protected]>; [email protected] <[email protected]>; [email protected] <[email protected]>; [email protected] <[email protected]>; Wen Lin <[email protected]> Cc: BESS <[email protected]> Subject: [bess] Re: draft-ietf-bess-evpn-first-hop-security-01: optional scoping for DSR distribution when a BD spans fabrics Hello Authors, WG, bess members, Hoping, someone can respond back to my below email Thanks, Saumya. ________________________________ From: Dikshit, Saumya <[email protected]> Sent: Thursday, July 30, 2026 12:06:21 am To: [email protected] <[email protected]>; [email protected] <[email protected]>; [email protected] <[email protected]>; [email protected] <[email protected]>; Wen Lin <[email protected]> Cc: BESS <[email protected]> Subject: [bess] draft-ietf-bess-evpn-first-hop-security-01: optional scoping for DSR distribution when a BD spans fabrics Hello authors of draft-ietf-bess-evpn-first-hop-security-01, I would like to raise one deployment case that I do not think the current DSR distribution model covers, along with a small optional extension. Section 4.3 (Bridged Service) describes the create path as the anchor sending the binding: "to all PEs in that BD, including multihoming PEs in the same redundancy group." and Section 4.4 (IRB Service) repeats the same sentence, so this is the behavior for both service types Section 8 (BGP EVPN DSR) already requires that "The BGP advertisement for the DSR MUST also carry the Route Target (RT) associated with the BD." So, distribution is scoped to the Broadcast Domain, and for a BD that lives inside one fabric that is exactly right. The case I am interested in is where the BD itself spans fabrics. In a stretched or hub-and-spoke campus/branch design, one BD can reach PEs in geographically separate fabrics that are connected only to reach shared central services. The RT scopes to the BD, but it does not sub-scope within it so, every PE in the BD imports and retains the binding, * including PEs in fabrics where the client will never egress * where no DAI/NDI/Source Guard decision will ever be taken for it. For these PEs, the state is pure overhead, and in some multi-tenant or regulated environments the presence and binding information of a client is something the operator would rather not expose to a fabric outside that client's operational domain. This is the same concern we documented for the RT-2-carried binding case in draft-saumthimma-evpn-ip-binding-sync. We have written up an optional companion extension: https://datatracker.ietf.org/doc/draft-dikshit-bess-evpn-fhs-scoped-sync/<https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-dikshit-bess-evpn-fhs-scoped-sync/__;!!NpxR!hqZDNHjg_NfkfTBh7nvGyxbVCnnV7_GY4ine9WB00RCGzs10laAawSTwv9NAeHJ_04MpDtbFzv72Vg38n_6s5FJfBacOVrW1PA$>. : It defines a "DSR Sync-Scope Extended Community" carrying a 16-bit, operator-assigned Sync-Scope ID. An anchor PE configured with a scope for a BD attaches it to the DSRs it originates; PEs provisioned with that ID import as today, and PEs outside the scope do not. Two properties we deliberately preserved: * Absence of the extended community means unscoped, BD-wide and that is exactly the behavior specified in your document today. Operators who do not configure a scope see no change * A PE that does not implement the extension behaves as it does now, so the extension degrades to current behavior rather than breaking mixed deployments, hence backward compatible. Is this a case the WG considers in scope for the first hop-security document itself, or is a separate companion draft the right home for it ? If you think the scoping belongs inside the base document, I would be glad to contribute the text there and drop our draft. If a companion is preferred, I would like to align terminology with yours. Also happy to be told this deployment model is out of scope for the WG, this is not needed Thanks, Saumya Dikshit
_______________________________________________ BESS mailing list -- [email protected] To unsubscribe send an email to [email protected]
