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

Jie,

What you are really saying here is to create per peer delta RIB (delta as
any peer will be still receiving routes which do not carry
node-target-ext-comm)  then to advertise the sigma to peers: "global
routes" and per peer "policed/filtered routes".

Well that is exactly the model we built for commercial implementation of
Route Server in IOS in the past. So yes this can be done with more or less
effort depending on the given implementation.

But this is not so difficult if your policy is not dynamically signalled
and comes with scaling compromise. Here we are facing the situation
where eligibility for import to a given peer is based on the presence of
node target ext community.

It looks like a really heavy hammer to hit current route reflectors and
ASBR BGP speakers with. Especially that this is practically applicable only
to special NLRIs of any AFI/SAFI and not path attributes itself.

So Jie and other co-authors ... Could you describe here on the list or add
to the draft practical applications / use cases which this extension will
help to distribute ? So far the draft just says "how" ... but it is pretty
silent on "why".

Many thx,
Robert

On Fri, Sep 30, 2022 at 12:05 PM Dongjie (Jimmy) <jie.dong=
40huawei.com@dmarc.ietf.org> wrote:

> Hi Robert,
>
>
>
> Thanks for the information about some BGP implementations. My reading is
> that they can be considered as lightweight implementations of Adj-Rib-Out,
> while the concept of Adj-Rib-Out and related route advertisement procedure
> still comply to the BGP base specification.
>
>
>
> Best regards,
>
> Jie
>
>
>
> *From:* Robert Raszuk [mailto:robert@raszuk.net]
> *Sent:* Friday, September 30, 2022 4:53 PM
> *To:* Dongjie (Jimmy) <jie.dong@huawei.com>
> *Cc:* Susan Hares <shares@ndzh.com>; idr@ietf. org <idr@ietf.org>; 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,
>
>
>
> Many BGP implementations do not even have Adj-RIB-out and what is sent to
> a neighbor is just a bit in the neighbor list set post update generation.
>
>
>
> Moreover please be aware that for efficiency some implementations I am
> aware of for example for RTC perform filtering on ext comms. post update
> generation.
>
>
>
> So your story does not hold.
>
>
>
> Kind regards,
>
> R.
>
>
>
>
>
> On Fri, Sep 30, 2022, 10:06 Dongjie (Jimmy) <jie.dong=
> 40huawei.com@dmarc.ietf.org> wrote:
>
> Hi Robert,
>
>
>
> Thanks a lot for your review and comments, please find some replies inline:
>
>
>
> *From:* Idr [mailto:idr-bounces@ietf.org] *On Behalf Of *Robert Raszuk
> *Sent:* Wednesday, September 28, 2022 5:42 AM
> *To:* Susan Hares <shares@ndzh.com>
> *Cc:* idr@ietf.org; 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 Sue & Authors,
>
>
>
> I have re-read the draft and have two concerns and suggestion. Concerns
> IMO need to be addressed before we adopt the draft. Suggestions can be
> added later.
>
>
>
> *Major concern: *
>
>
>
> The document talks about procedure during dissemination of update
> message(s). It is however completely silent about withdraws. As we know BGP
> UPDATE which contains withdraws can be build using only subject NLRIs. That
> means that those may/will not be subject to discussed filtering.
>
>
>
> I am not 100% sure if all nodes will continue to operate fine if they will
> be receiving withdraws for NLRIs never previously received. Yet propagating
> withdraws will happen everywhere.
>
>
>
> To address this well it seems that capability negotiation would be the
> safest bet. But isn't this too much to ask ?
>
>
>
> [Jie] In BGP implementation, a BGP node advertises a withdraw to its
> neighbor only if the route has been installed in the Adj-Rib-Out. This
> document does not introduce any change to this.
>
>
>
> Thus the case you mentioned "BGP nodes receive withdraws for NLRIs which
> never previously received" would not happen if all nodes complies to BGP
> base specification.
>
>
>
> *Minor concern: *
>
>
>
> Which is more important RT or NT ? (RT when used with RTC of course).
>
>
>
> [Jie] Our suggestion is NT should be processed first, then the RT. But it
> is open for discussion.
>
>
>
> *Suggestion: *
>
>
>
> I would propose to make Target BGP Id to be a prefix not fixed 4 octet
> field. Wisely choosing BGP Ids can lead to very efficient distribution.
>
>
>
> [Jie] This is something the authors considered in the beginning, while
> changing the BGP ID to a prefix would require to introduce some longest
> match approach, which is not something we have with the extended
> communities so far.  This point could be further discussed, and for now the
> default approach can be with a 4-octet BGP ID.
>
>
>
> *Final word: *
>
>
>
> Of course this proposal goes against BGP p2mp principle, but at least it
> is not p2p, but have potential built in to make it
> p2(subset-of-multipoint)peers.
>
>
>
> [Jie] Agree with this statement.
>
>
>
> Best regards,
>
> Jie
>
>
>
> Thx a lot,
>
> Robert.
>
>
>
>
>
> On Tue, Sep 27, 2022 at 7:31 PM Susan Hares <shares@ndzh.com> wrote:
>
> This begins a 2 week WG adoption and IPR call for
> draft-dong-idr-node-target-ext-comm-05.txt.
>
> https://datatracker.ietf.org/doc/draft-dong-idr-node-target-ext-comm/
>
>
>
> The authors should respond to this email with an IPR statement.
>
>
>
> The WG should consider in their discussion:
>
> 1) Will this new  transitive extended community help
>
> in operational networks?
>
>
>
> 2) What conflicts does this new Extended Community have
>
> with other functions in general BGP route distribution or
>
> VPNs (EVPN, IPVPN)?
>
>
>
> 3) do you have any concern about the text in the draft?
>
>
>
> Cheerily, Sue
>
> _______________________________________________
> 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
>