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,

Please see some clarifications inline:

From: Robert Raszuk [mailto:[e-mail]]
Sent: Thursday, October 20, 2022 5:55 AM
To: Jeffrey Haas <[e-mail]>
Cc: Gert Doering <[e-mail]>; [e-mail]; Susan Hares <[e-mail]>; Dongjie (Jimmy) <[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)

Hi Jeff,

Thank you for some of your comments.

Let me just observe one fundamental point. You said:

> Processing of community membership by importing nodes

a) This draft (at least the way I read the juice of it) use case focuses on using the community on the sender not receiver. It is BGP OPEN BGP Identifier which they intend to use as a input for sending some UPDATES to only one (or a few peers) from RRs or ASBRs. If this draft would be just adding a community like this I think there would be zero objections.

[Jie] The goal of this draft is to introduce a new type of extended community (NT), which is used by a receiving node to check whether itself is the target node.  As describe in the draft, route distribution optimization based on NT is optional, and by default NT is not checked in route reflection. It is good to know that you agree such a new type of extended community is needed.

b) As observed today BGP Identifier is both global and per VRF. They are clear that targeted data in some cases must be imported to a VRFs. So I do see a collision of at least two BGP Identifiers.

[Jie] The case you described above is not what we intended to cover with the current draft.

To your point of withdrawal, I see that the extended community is linked with MP_REACH. If MP_UNREACH is in the same UPDATE the nodes which should get the MP_UNREACH may not even get the withdrawal. As you know the key for withdrawal is self contained in the MP_UNREACH .. here we are adding another layer of filtering on the sender. If you  are always ok to split the non congruent (node target ext comm wise) MP_REACH with MP_UNREACH I am fine. But this needs to be observed IMO up front when we are talking about nodes not even getting the UPDATES.

[Jie] You are correct that the withdrawal in BGP update is self-contained. The NT extended community only applies to the information in MP_REACH. And as Jeff mentioned, BGP route update is stateful on a per-route basis. If a BGP node needs to send withdrawal to its peer, it will be sent regardless of whether the withdrawal was received in an Update containing MP_REACH or not. In summary I don’t see this as a problem.

Best regards,
Jie

Many thx,
R.

On Wed, Oct 19, 2022 at 11:41 PM Jeffrey Haas <[e-mail]<mailto:[e-mail]>> wrote:
On Sat, Oct 15, 2022 at 01:00:22AM +0200, Robert Raszuk wrote:
> /* adding GROW WG as what is being discussed is much more operational topic
> then protocol extension */

And subtracting grow because you're bifurcating a long set of threads
unnecessarily.  Feel free to prod their list directly with the mailarchive
top of thread.

> > Minimally, the proposal
> > covers an extended community that can be used by policy to say:
> >
> >   Is my BGP Identifier present in this list of extended communities?
> >   If so, I'm interested in it.
>
>
> I would like to comment on this point. Looks very innocent on the surface.
>
> *Point #1: *
>
> At the target deployment (as per current version of the draft) this means
> p2p distribution of information with inherently p2mp protocol. I do not
> think this is efficient. This is trying to use BGP as a policy/config push
> mechanism only because we do not have a good one yet in IETF.

As I noted, the community as a marker is a fine and simple thing.  I have
concerns about the text for what it's intended to do on the distribution
machinery that I'll be taking up separately.

Today, we already can use communities of any flavor to accomplish such goals
using standard policy tooling.  The authors point this out directly in their
draft:

:    Another possible approach is to configure, on each router, a
:    community and the corresponding policies to match the community to
:    determine whether to accept the received routes or not.  Such
:    mechanism relies on manual configuration thus is considered error-
:    prone.  It is preferable by some operators that an automatic approach
:    can be provided, which would make the operation much easier.

RFC 1997 community space is a bit thin on space to do this.  Large BGP
Communities have plenty of space to do exactly this without any IETF
coordination required.

Extended communities have two nice properties for this sort of thing:
1. They already have structure.
2. RT-Constrain works on them.

When we look at the various types of communities used for "targeting"
purposes, the semantic of single-party or multi-party largely depends on the
thing we're targeting.  L3VPN route targets are often targeting VRFs on
multiple PEs, but for scenarios like hub and spoke may target a single
device.  Jeffrey Zhang provided a reference for a targeted VRF in MVPN
procedures. EVPN has its ES-Import.

Similar to how a L3VPN route can have multiple route-targets, routes
containing multiple node-targets mean "distribute to a set of routers".

If the set of routers becomes large enough, we likely want a community that
covers such a form of group membership.

> *Point #2: *
>
> I do have some sympathy (as noted already earlier) that if my extended
> community carries a prefix of BGP_ROUTE_IDs this could have potentially
> some useful applications**. But not a list of 1:1 mapped BGP_IDs. That list
> can get really long and neither processing it at each node now attaching it
> to each UPDATE is efficient.

There are BGP Flowspec scenarios where such a behavior would be desirable.
(Target this filter to these specific routers.)

Aside from the usual consideration of "too many communities", which we
already see on existing VPN technologies, I have no concerns about
processing time.  Processing of community membership by importing nodes is
usually O(lg(N)) time on even trivially optimized implementations.  If your
implementation is doing O(N), consider having a cranky conversation with
your developers.

> *Point #3: *
>
> As it has been noted already by Gert you can accomplish what you need today
> already with just adding a community and applying filtering on it. Of
> course modulo filtering on IBGP has its own risks, but those I assume are
> well understood.

Yeah, and as I'm noting, I'm fine with a distinguished community format that
is well understood by implementations.  The fact that Jie and company simply
haven't allocated from FCFS and simply told IDR "we're doing this" is mostly
community service by letting the IETF participate in refining a more
general mechanism.

> *Point #4: *
>
> As previously discussed, the draft should discuss handling withdrawals in
> all previously described scenarios. Not only in terms of implementation's
> ability to do so, but actual protocol correctness (case where UPDATE
> carries both MP_REACH and MP_UNREACH and node-target-ext-comm applies to
> the former not the latter. Splitting those into different UPDATE messages
> may not always be easy.

I'm frankly puzzled by this bit in your initial response and followups.  The
filtering procedures recommended are effectively no different than those
utilized by RT-Constrain.

BGP is expected to be stateful.  If a speaker sends the route to some peer,
it's expected to be able to send a withdraw for it.  The contents of the
Path Attributes previously advertised are not relevant for the withdraw
procedures.

Implementations are expected to handle processing withdraws for routes they
may not have in their Adj-Ribs-In.  This is no different than receiving a
withdraw for a route that hasn't been installed in the rib-in due to policy.

> *Point #5: *
>
> We are starting to get to the point of ingress inline signalling atomic
> filtering rules. Nothing wrong with this. But if so I would rather see this
> generalized. With that, Wide-Communities provide such ability. Why define
> more in encoding which by design is limited in size ? What if next would be
> a request to only accept UPDATE by a node which has a client belonging to a
> fixed IPv6 prefix ?

The specified semantic is "target this node".  While you could encode this
in a wide community, the semantic would be an atom that contains one or more
ipv4 addresses but interpreted vs. the node's BGP Identifier.  So, you can
encode it that way, but it isn't helpful.

Additionally, if your desire is to leverage RT-Constrain, that's additional
work.

> Likewise why not enable sender to advertise routes to only a subset of
> upstream or peer ASNs ?

Great wide communities use case. :-)

-- Jeff