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

[Robert Raszuk <[e-mail]>]

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.*

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.

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.

Many thx,
R.

On Wed, Oct 19, 2022 at 11:41 PM Jeffrey Haas <[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
>