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

Jeff,

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

That is one way it can be implemented.

RTC has been implemented as filter post update generation in some operating
systems. In such cases your example does not apply.

>From sender POV it has been sent to all. Filtering at replication mimics
filtering at the receiver. Works for RT may break for NT.

And as mentioned the crux here is in the MP_REACH structure. If we force
NLRIs to be uniquely different RD per path it all works smoothly. If you
try to make it work with NLRIs which can have different paths and still
filter at replication I am afraid it will not work.

Many thx,
R.

Ps. This is just for the archives. If someone complains down the road at
least we can point them to the list that it has been brought up.


On Thu, Oct 20, 2022 at 10:42 PM Jeffrey Haas <[e-mail]> wrote:

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