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]>]

Robert,

On Wed, Oct 19, 2022 at 11:55:29PM +0200, Robert Raszuk wrote:
> 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.*

It's almost as if there was a reason I was emphasizing that I liked the use
case and had concerns about the distribution machinery.

Anyway.

I've started a separate thread on the distribution machinery since this one
has wandered into multiple levels of unreadability.  In particular, their
machinery is an attempt at using BGP session state from the OPEN messages to
build a targeted distribution mesh.  I think it's probably not the best way
to do this.

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

I certainly think this is a case to be addressed.

The BGP specifications are silent (as best I can remember) on whether VRF
CE-facing instances are permitted their own BGP Identifier.  Certainly many
implementations simply default to the PE's BGP Identifier.  But similarly,
it's a feature of some implementations to permit this to be configured
distinct from the PE's BGP Identifier.

For the distribution mechanism in the draft, it won't work in such
circumstances.  For something like RT-Constrain, it'd probably work as long
as the PE generated the necessary route as it already does for member VRF
Extended Communities.

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

I'm unable to parse your English here.  Please provide an explicit example.

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

This text seems to suggest you think that the NLRI key is becoming a
composite key with the node target for some reason.  I don't believe that's
the case, nor that this is different than any other outbound filtering
mechanisms we have specified.

-- Jeff