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

[Jeffrey Haas <[e-mail]>]

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