Re: [Idr] draft-dong-idr-node-target-ext-comm-05.txt - WG Adoption and IPR call (9/27 to 10/11/2022)

[Robert Raszuk <[e-mail]>]

Jeff,

> Imagine a 1000s devices in 9-11-13 stages multi-planar leaf-spine block
> with eBGP (next-hop rewrite) between them

So because you bended BGP to be used in such topologies you now want to
load it with features specific to accommodate such topologies ? And where
is the rest of the world in this picture ? Where is the Internet in this
picture ?

> (requires some planning of how router-ids are allocated)

Why are Router_IDs now an optimal filtering parameter ?

If you have such topology running BGP as IGP just allocate RT and use RT
based filtering (perhaps even with RTC) instead of reinventing the wheel.
If you are already using RT and for any reason prefer not to touch it,
allocate a std, extended, large or wide community and use it for filtering.

Cheers,
Robert



On Sat, Oct 15, 2022 at 11:47 PM Jeff Tantsura <[e-mail]>
wrote:

> Hey Gert (long time ;-)),
>
> We are much beyond the time when an AS was bunch of ASBRs with RR and iBGP
> in between only.
> /* fictional
> Imagine a 1000s devices in 9-11-13 stages multi-planar leaf-spine block
> with eBGP (next-hop rewrite) between them, policies are horizontally
> consistent (based on a position of a device in the block). When everything
> is up and running, stage interconnection is highly consistent (equidistant
> end-points)and works just great with consistent distribution of
> reachability (p2mp).
> Single or even double failures are easily mitigated by wide ECMP (with
> fast rehash, easily below 100ms).
> When an optical span fails however, it is a very different story, so you
> need to update either all relevant receivers (could be just a subset of
> routes, could be some additional meta-data(metrics/BW/etc) or sender(s) (or
> a controller that injects said subset m). In many cases, being able to
> target a specific set of BGP speakers is the only solution (temp
> mitigation).
>
> As you rightfully said - all of this can be done with 0 changes to the
> protocol (through management plane), however has a number of its own issues
> (trade-offs).
>
> I agree that 1:1 mapping doesn’t really scale, we could think a a more
> efficient distribution through wildcarding (requires some planning of how
> router-ids are allocated). Would be somewhat similar to “passive BGP” in
> some implementations - accept all peers that come from 10/8.
>
> I have a mixed feeling about this, BGP person in me is saying (throw this
> over the board to management), operating this stuff at scale one is seeing
> some opportunities  ;-)
> Hence my support.
>
> Cheers,
> Jeff
>
> > On Oct 14, 2022, at 09:10, Gert Doering <[e-mail]> wrote:
> >
> > Hi,
> >
> >> On Thu, Oct 13, 2022 at 08:30:45AM -0700, Jeff Tantsura wrote:
> >> Looking at my toolset (sometimes i need to move GWs of capacity from
> one region to another) - this would be a very useful addition.
> >
> > If you need a mechanism to actually control routing propagation, this
> > can all be built today with route-policies and communities, without
> > protocol changes.  Exactly the way an AS needs.
> >
> > If you want this to propagate something else, I am yet to be convinced
> > BGP is what we should burden with it.
> >
> > Gert Doering
> >        -- NetMaster
> > --
> > have you enabled IPv6 on something today...?
> >
> > SpaceNet AG                      Vorstand: Sebastian v. Bomhard, Michael
> Emmer
> > Joseph-Dollinger-Bogen 14        Aufsichtsratsvors.: A. Grundner-Culemann
> > D-80807 Muenchen                 HRB: 136055 (AG Muenchen)
> > Tel: [phone]         USt-IdNr.: DE813185279
>
> _______________________________________________
> Idr mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/idr
>