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

Hello Jeff,

Thinking more about your exemple I am concluding that any filtering
performed on path attributes which could change without prior route
withdrawal from the src is simply not compliant with base BGP
specifications.

*RFC4271 was very clear to say: *

An UPDATE message might advertise only routes that are to be withdrawn from
service, in which case the message will not include path attributes or
Network Layer Reachability Information.

*RFC4760 is also clear: *

An UPDATE message that contains the MP_UNREACH_NLRI is not required  to
carry any other path attributes.

That means that implementations which send implicit withdrawals do not
break any BGP specifications.

*Quote from RFC4271:*

   If the UPDATE message contains a feasible route, the Adj-RIB-In will
   be updated with this route as follows: if the NLRI of the new route
   is identical to the one the route currently has stored in the Adj-
   RIB-In, then the new route SHALL replace the older route in the Adj-
   RIB-In, thus implicitly withdrawing the older route from service.

- - -

UPDATES which contain MP_UNREACH_NLRI should not be subject to any RT
filtering. I do recall some discussions on this in the past but don't
recall what conclusion was reached.

But let's note that when both MP_UNREACH_NLRI and MP_REACH_NLRI contain the
same NLRI only the latter is processed. MP_UNREACH_NLRI could be just a
protocol "hack" to bypass filters in such cases.

Bottom line I think we have enough issues just with SAFI 128 alone and RT
filtering.

Adding to this new extended community to add more filtering into iBGP  is
clearly not going to help to simplify the situation.

Thx,
R.


On Sat, Oct 22, 2022 at 12:37 AM Robert Raszuk <[e-mail]> wrote:

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