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

> 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] <mailto:[e-mail]>> wrote:
> 
> 
>> On Oct 21, 2022, at 12:27 PM, Robert Raszuk <[e-mail] <mailto:[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
>