Re: [Idr] draft-dong-idr-node-target-ext-comm route distribution procedures

[Jeffrey Haas <[e-mail]>]

Jie,

On Thu, Oct 20, 2022 at 09:41:50AM +0000, Dongjie (Jimmy) wrote:
> That said, this document tries to introduce an optional procedure to
> improve the route distribution efficiency based on NT. It could be
> considered as a starting point for further discussion. The authors
> realized that this optional procedure may or may not work in different
> network scenarios (e.g. the deployment of hierarchical RRs), thus whether
> it can be enabled needs depends on the operators policy and understanding
> to their network. This policy also needs to apply to the EBGP peer case
> (Sorry the current version is not very clear on this).
> 
> Your suggestion about using RT-constrain for this distribution control is
> interesting and deserve some further discussion. And in the controller
> based route distribution case, BGP-LS may also be an option to build the
> distribution graph on RRs. Actually this makes me wonder whether it would
> be better if we split the optional distribution optimization from the NT
> extended community definition in this draft. What do you think?

Not speaking as one of the IDR Chairs, I think it's likely that the Extended
Community for signaling purposes will get easier traction if your
distribution and filtering procedures aren't a core part of the proposal.
It's clear what is intended as the target for this Extended Community.

Some form of optimized filtering behavior, however, is strongly desired when
using such a community - or sets of them attached to a BGP route.
Otherwise, as others have said, we're taking a point-to-multipoint
distribution mechanism and putting a lot of excessive noise in the protocol.

Choosing my favored use case for such a community, targeting BGP Flowspec
routes to a subset of nodes, there's still clear benefit even without such a
filtering method.  In Flowspec scenarios, it's typical for there to be a
dedicated route reflector plane that is responsible for distribution of
flowspec routes to interested ASBR devices.  Currently, if a filter is
desired to be installed on a subset of devices, it's necessary to have
targeted BGP sessions to those devices.  With a node target community, the
reflector can simply distribute the routes to the targeted subset.

I did realize one bit of my thinking in my original response is not fully
correct:

> > Of course, there's one large hold-up with regard to such a methodology:
> > RT-Constrain is not per-AFI/SAFI for its flooding graph.  In general, this
> > hasn't been a problem for features deployed for RT-Constrain since the
> > communities in question tend to be associated with specific AFI/SAFIs.
> > However, there's no guarantee that a given AFI/SAFI node-targeted route has
> > an appropriately congruent AFI/SAFI flooding topology along the
> > RT-Constrain graph.
> > 
> > Solving the RT-Constrain AFI/SAFI congruency issue may be helpful here, and
> > perhaps has overlapping use with other possible BESS use cases.

The congruency isn't fully important for interior BGP scenarios.
RT-Constrain would indeed build graph arcs that might not be eligible for
all AFI/SAFI to be distributed over.  However, since the mechanism simply
says "you're allowed to", routes will still properly distribute over
sessions that have the necessary AFI/SAFI negotiated.

RFC 4684's inter-as scenario permits pruning of paths.  The challenge of
AFI/SAFI congruency vs. the pruning is present only in that scenario.

-- Jeff