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,

Well even without RTC you have an issue if path changes on A and B keeps
the inbound filter set to 100:100.

Note that on any properties change to make it effective you need to clear
session out. In the old days that was hard reset so no issues. These days
this is soft reset.

So what you are essentially saying is that with RT filtering (or really
filtering of any sort on non immutable path attribute which removes a
parameter) you can not use the implicit withdrawal concept in iBGP.  Is
this the right conclusion ?

You always must withdraw the old path then advertise the new one.

Enhanced Route Refresh could help but honestly I don't think I have ever
tested how it works with RTC or even RT inbound filtering.

Thx,
R.

On Fri, Oct 21, 2022 at 10:57 PM Jeffrey Haas <[e-mail]> wrote:

>
>
> On Oct 21, 2022, at 4:32 PM, Robert Raszuk <[e-mail]> wrote:
>
> Hi,
>
> > A has a properties change for the route
>
> That is why I said in the same RD case (not recommended anyway) the change
> must be symmetric to all VRFs sourcing such route.
>
>
> In the example below, the prefix does not change.  This is a single route
> example.
>
> -- Jeff
>
>
> Kind regards,
> Robert.
>
>
> On Fri, Oct 21, 2022 at 10:13 PM Jeffrey Haas <[e-mail]> wrote:
>
>>
>>
>> On Oct 21, 2022, at 12:27 PM, Robert Raszuk <[e-mail]> wrote:
>>
>>
>>
>>> Perhaps Robert will share whose implementation is intentionally broken
>>> in this fashion to help shortcut that process.
>>
>>
>> I do not consider implementation to be broken the moment IDR decides to
>> use BGP as point to point configuration protocol and forces it to filter
>> BGP UPDATES from arbitrary AFI/SAFI when propagating towards IBGP peers.
>>
>> For current SAFIs with unique RDs and RT based filtering nothing is
>> broken.
>>
>>
>> A peers with B with RT-C and L3VPN.
>> B advertises to A an RT-C route that attracts route-target:100:100
>>
>> A theoretically filters L3VPN routes at the update-send portion of the
>> process by dropping updates containing no matching RT-C extended
>> communities of interest.
>>
>> A advertises L3VPN route RD:prefix to B with route-target:100:100 and
>> route-target:200:200.  This matches received RT-C for route-target:100:100
>> from B and is thus transmitted.
>>
>> A has a properties change for the route and needs to advertise L3VPN
>> route RD:prefix to B with only route-target:200:200.
>> There is no matching received RT-C route from B with this route-target.
>>
>> If the route is filtered, B now has stale state.
>>
>> If A doesn't generate a withdraw for this route, B now has stale state.
>>
>> Q.E.D.
>>
>> -- Jeff
>>
>>
>