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 Thu, Oct 20, 2022 at 12:50:20AM +0200, Robert Raszuk wrote:
> > 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.
> >
> 
> The use case why this was introduced was to enable VRF to VRF eBGP session
> via firewalls (other types of chaining). Without running into BGP session
> BGP_ID checks (not that many implementations actually check it :).

Cute. :-)

Enough implementations check the session collisions that such a feature is
appropriate.

If you have any passion toward such a thing, I'd suggest review of the BGP
YANG module to see how you think it should be managed in the IETF model...
or not at all as a vendor-specific item.

> > > 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.
> >
> 
> 
> Deepest apologies. Maybe indeed my example was unclear. Let me try much
> cleaner one:
> 
> net_X has two paths P1 and P2. P1 had NT 1.1.1.1 and was best. Was sent as
> such to 1.1.1.1
> 
> Now for whatever reason P2 got selected as best but it's NT is 2.2.2.2
> 
> When we build UPDATE we just include net-X + P2. Business as usual.
> 
> Well don't you think node 1.1.1.1 will remain stuck with net_X forever ?

I don't.

In RFC 4271 abstracts:
P1 is selected as the active path in LocRib
P1 then is placed in 1.1.1.1's Adj-Rib-Out, but not 2.2.2.2's Adj-Rib-Out.
Advertisement happens based on that state.
P2 is then selected in LocRib
P1 is removed from 1.1.1.1's Adj-Rib-Out because it's not eligible.
P2 is installed in 2.2.2.2's Adj-Rib-Out.

Specifically from RFC 4271, §9.1.3:
:   All routes in the Loc-RIB are processed into Adj-RIBs-Out according
:   to configured policy.  This policy MAY exclude a route in the Loc-RIB
:   from being installed in a particular Adj-RIB-Out.

This just happens to be another flavor of policy, much like RT-Constrain.

If it makes you feel happier, you already know this case for proxy route
advertisement suppression that many implementations do at ASBRs when there
would be an AS-Loop, or from route reflectors when advertisement would
result in a cluster loop.

-- Jeff