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

Hey Gyan,

And to extend the picture if RT/RTC are not an option and neither is
inbound drop I would not mind extending ORF to cover std, extended**, large
& wide communities if there is a burning desire to push the burden of
filtering to RRs or peers.

** Extended Comm ORF was written 10 years back by Enke
(draft-chen-bgp-ext-community-orf) but since RTC came in it was shelved.

Best,
R.





On Sun, Oct 16, 2022 at 12:34 AM Gyan Mishra <[e-mail]> wrote:

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