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/. :
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]
