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

["Dongjie (Jimmy)" <[e-mail]>]

Hi Robert,

As described in the introduction section of this draft, RT and the RTC mechanism applies to the filtering of routes to all nodes with specific VRFs. One cannot use RTs for both node filtering and VRF filtering, because the matching rule for RTs is “match-any”.

Here is a simple example: Assume you want to use RT-A to specify the target node (say node A), and RT-2 is used to specify the target VRF, then BGP routes carrying both RT-A and RT-2 will be imported by all PE nodes (not just node A) which has RT2 as the import RT of their VRFs, clearly this does not meet the requirement on targeted node distribution.

That’s why this document proposes a new extended community type:  to distinguish its semantics and operation logic with the current RT. Whether we need to use wide community or large community depends on how much information needs to be carried.

Best regards,
Jie

From: Robert Raszuk <[e-mail]>
Sent: Sunday, October 16, 2022 6:00 AM
To: Jeff Tantsura <[e-mail]>
Cc: Gert Doering <[e-mail]>; Dongjie (Jimmy) <[e-mail]>; [e-mail]; Susan Hares <[e-mail]>; Van De Velde, Gunter \(Nokia - BE/Antwerp\) <[e-mail]>
Subject: Re: [Idr] draft-dong-idr-node-target-ext-comm-05.txt - WG Adoption and IPR call (9/27 to 10/11/2022)

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]<mailto:[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]<mailto:[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]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/idr