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

[Gyan Mishra <[e-mail]>]

On Sat, Oct 15, 2022 at 5:59 PM Robert Raszuk <[e-mail]> wrote:

> 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.
>


    Gyan> I agree outside of management plane possibilities of using or
even tweaking RTC to provide the desired optimizations or standard
filtering techniques.  I still would like to see more information on the
problem statement details use cases where this special filtering needs a
new extended community and existing mechanisms won’t suffice.

>
> 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
>> <https://www.google.com/maps/search/Joseph-Dollinger-Bogen+14?entry=gmail&source=g>
>>       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
>>
> _______________________________________________
> Idr mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/idr
>
-- 

<http://www.verizon.com/>

*Gyan Mishra*

*Network Solutions A**rchitect *

*Email [e-mail] <[e-mail]>*



*M 301 502-1347*