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
>