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

Hi Jie,

Thank you for uncovering corner of one potential use case. We need more
real use cases.

In the draft I do not see anywhere statement that node target extended
community must be automatically more important then route target extended
community.

Since such text is missing I presume it will be subject to operator's local
policy configuration.

And if so there is nothing - neither on sender nor on the receiver - to
prevent one from using RT value X (RT1 in yr example) as an absolute
drop/accept filtering criteria.

- - -

As far as your IANA allocation I do recommend calling things much more
clearly. Currently you asked and IANA allocated sub-type name "Node Target
Extended Community" - it is good for the draft, but in the registry it
should be "BGP Router ID" or "BGP Identifier" which makes it very clear
what is being encoded.

Many thx,
R.

On Tue, Oct 18, 2022 at 5:53 AM Dongjie (Jimmy) <jie.dong=
40huawei.com@dmarc.ietf.org> wrote:

> Hi Robert,
>
>
>
> Please note that the use case is to distribute the information to a VRF on
> specific set of nodes, which are a subset of nodes which are provisioned
> with that VPN.
>
>
>
> A route with both RT-A and RT1 will be imported into the VRFs of all PE
> nodes of that VPN. Clearly this is not the expected result.
>
>
>
> I agree that for non-VPN cases using RT-A only would be OK, while it is
> not a generic solution to cover the VPN related cases.
>
>
>
> Best regards,
>
> Jie
>
>
>
> *From:* Robert Raszuk [mailto:robert@raszuk.net]
> *Sent:* Tuesday, October 18, 2022 12:04 AM
> *To:* Dongjie (Jimmy) <jie.dong@huawei.com>
> *Cc:* Jeff Tantsura <jefftant.ietf@gmail.com>; idr@ietf.org; Susan Hares <
> shares@ndzh.com>; Van De Velde, Gunter \(Nokia - BE/Antwerp\) <
> gunter.van_de_velde@nokia.com>
> *Subject:* Re: [Idr] draft-dong-idr-node-target-ext-comm-05.txt - WG
> Adoption and IPR call (9/27 to 10/11/2022)
>
>
>
> 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=
> 40huawei.com@dmarc.ietf.org> 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 <robert@raszuk.net>
> *Sent:* Sunday, October 16, 2022 6:00 AM
> *To:* Jeff Tantsura <jefftant.ietf@gmail.com>
> *Cc:* Gert Doering <gert@space.net>; Dongjie (Jimmy) <jie.dong@huawei.com>;
> idr@ietf.org; Susan Hares <shares@ndzh.com>; Van De Velde, Gunter \(Nokia
> - BE/Antwerp\) <gunter.van_de_velde@nokia.com>
> *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 <jefftant.ietf@gmail.com>
> 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 <gert@space.net> 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: +49 (0)89/32356-444         USt-IdNr.: DE813185279
>
> _______________________________________________
> Idr mailing list
> Idr@ietf.org
> https://www.ietf.org/mailman/listinfo/idr
>
> _______________________________________________
> Idr mailing list
> Idr@ietf.org
> https://www.ietf.org/mailman/listinfo/idr
>
> _______________________________________________
> Idr mailing list
> Idr@ietf.org
> https://www.ietf.org/mailman/listinfo/idr
>