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

Hi Jie,

To your example clearly if you insert both RT2 and RT1 either will cause
the import to PE global table. In addition RT2 will also result in import
to a VRF.

However if you are to distribute information which is not targetted to a
VRF you do not need to insert this extended community (here RT2) to an
UPDATE message. Then RT1 alone will result in exactly what you need. I
honestly do not see a problem here.

Filtering on a fixed Router_IDs is not flexible enough IMHO even
considering targetted information distribution.

Kind regards,
R.

On Mon, Oct 17, 2022 at 5:45 PM Dongjie (Jimmy) <jie.dong=
[e-mail]> wrote:

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