Re: [Idr] draft-wang-idr-vpn-routes-control-analysis (was Re: rd-orf problem clarification at the local level)

[Robert Raszuk <[e-mail]>]

On Fri, Feb 26, 2021 at 4:49 PM Gyan Mishra <[e-mail]> wrote:

>
> Hi Robert
>
> In the first comment in the thread as a requirement to identify the
> Prefixes based on RD to be blocked in the case of not unique RD requires an
> AND of both RD+RT in the logic.  I am in complete agreement that is
> required.
>
> So I can see Jeffrey’s idea as a possible solution to modify RTC to
> include offending RD update to RTC spec.
>

Just to be clear ... Jeff did not suggest that. This suggestion I wrote.



> However, the RD ORF uses existing ORF machinery with add of new ORF type
> which to me seems a very minor change.  The nice thing about RD ORF is that
> it is controlled and requires manual intervention to unblock where RTC
> would be automatic and that could cause undesirable instability.
>

That can be manual even for RTC. Consider advertising an RD attribute as a
static route. It will be advertised till operator removes it.




> I am not sure if modifying RTC to include RD block logic would not cause
> added instability with RTC as RTC acts only on RT, as I this is a
> significant change to RTC membership logic.  Also any existing
> implementation of RTC would all be impacted by this change.  With RD ORF as
> this is a new type ORF, the ORF policy would have to be explicitly defined
> so this would only effect new deployments wanting to take advantage of RD
> ORF granularity of filtering.
>

The attribute wouild be optional transitive attribute. If you do not
recognize you do not use it.

Thx,
R.





>
> Gyan
>
> On Fri, Feb 26, 2021 at 5:47 AM Robert Raszuk <[e-mail]> wrote:
>
>> Gyan,
>>
>> What you said is pretty obvious I think to everyone here.
>>
>> But I think the point of bringing RTC into this picture was a bit
>> different.
>>
>> Just imagine RTC is running between PE and RR and signals interest in set
>> of RTs to the RR. Let's say those RTs are RT100, RT200, RT300, RT400, RT500
>>
>> Further imagine one VRF importing RT200 overflows on said PE with
>> incoming (pre-import routes of RD_FOO and RT100, RT200 and RT 300).
>>
>> So what if now PE via RTC will simply readvertise interest to get RT200
>> with new BGP attribute say called BLOCK_RD and lists in such attribute body
>> Route Distinguisher of RD_FOO ?
>>
>> The overall mission accomplished. No need for any new ORF type. It can be
>> even transitive if we apply a little hack and adjust the way RR will select
>> the best path for RTC (meaning include this attribute in advertisements
>> only if all peers sending RT200 attached it with such RD_FOO).
>>
>> To me this is very simply RTC extension and it seems solves this entire
>> "problem".
>>
>> And no - by proposing the above I am not changing my mind that it is
>> simply wrong network operation to even allow such problem to happen in the
>> first place.
>>
>> Best,
>> R.
>>
>>
>> On Fri, Feb 26, 2021 at 4:52 AM Gyan Mishra <[e-mail]>
>> wrote:
>>
>>>
>>> Hi Jeff
>>>
>>> Keep in mind that RTC is an optimization that does not apply to every
>>> scenario especially in cases where all PEs have all the same VPNs defined
>>> with explicit RT import.  The special cases were RTC does apply is for
>>> incongruent VRFs in cases of a sparse RT distribution graph where PEs don’t
>>> all import the same RTs.  By default all PE have RT filtering enabled by
>>> default meaning if their is not an explicit VRF definition to match and
>>> import the RT, the RT is dropped.  With RTC the distribution graph of what
>>> RTs are advertised RR-PE is now optimized with RT membership, and now  only
>>> RTs explicitly imported by the PEs are now advertised by the RR to PE for
>>> processing.  In the case of RD-ORF, it provides a layer of needed
>>> granularity as the RD PE originator of the flood is a subset of all the VPN
>>> prefixes represented by the RT permitted by RTC to be advertised to the
>>> PE.  The RD-ORF now dynamically blocks the offending PE prefixes that would
>>> otherwise have been advertised by RTC RR to PE and accepted by the PE for
>>> processing and added to the VRF RIB being overloaded.
>>>
>>>
>>> Kind Regards
>>>
>>> Gyan
>>>
>>> On Thu, Feb 25, 2021 at 6:21 PM Aijun Wang <[e-mail]>
>>> wrote:
>>>
>>>> Hi, Jeff:
>>>> Thanks for your suggestions!
>>>> I think combine RTC and RD-ORF information can accomplish the fine
>>>> control for the upstream propagation of unwanted VPN routes.
>>>> We will also try to find other ways to achieve the same effect.
>>>>
>>>> Aijun Wang
>>>> China Telecom
>>>>
>>>> > On Feb 25, 2021, at 22:01, Jeffrey Haas <[e-mail]> wrote:
>>>> >
>>>> > Aijun,
>>>> >
>>>> > On Thu, Feb 25, 2021 at 12:07:49PM +0800, Aijun Wang wrote:
>>>> >>> In the prior discussions, it was clear that remediation was trying
>>>> to be
>>>> >>> done on a per-RD basis.  The text in this draft seems to be a
>>>> larger scope
>>>> >>> than that; perhaps per VPN (and thus route-target?).  Is that your
>>>> >>> intention?
>>>> >> [WAJ] Yes. We are considering to add RT information to the current
>>>> RD-ORF
>>>> >> semantic, to identify/control the "excessive routes" in more
>>>> granular.
>>>> >
>>>> > Thanks for the clarification.  That expands the scope of the original
>>>> > discussion, but might be helpful for the solution.
>>>> >
>>>> >>> For a route reflector, it would require that all possible receivers
>>>> for a
>>>> >>> RD/RT have no interest in the routes, and that the source of the
>>>> routes is
>>>> >>> clearly directional.  BGP does not provide such a distribution
>>>> graph.
>>>> >>
>>>> >> [WAJ] " all its downstream BGP peers can't or don't want to process
>>>> it"
>>>> >> means RR receives the RD-ORF messages for the same set of VPN routes
>>>> from
>>>> >> all of its clients. This can be achieved by RR
>>>> >
>>>> > For my point, consider a trivial case:
>>>> >
>>>> > PE1 --- RR --- PE2
>>>> >
>>>> > PE2 is the source of the excess routes.
>>>> > PE1 is the impacted router.
>>>> > RR has only PE1 and PE2 as peers.
>>>> >
>>>> > By your current text, RR can only do something if PE1 and PE2 say
>>>> they're
>>>> > not interested.
>>>> >
>>>> > It can be observed here that if we have exactly one peer left, we
>>>> could
>>>> > signal to that one peer.
>>>> >
>>>> > I suspect your intent is to cover situations where you can
>>>> distinguish PE
>>>> > routers from solely internal route distributuion infrastructure, such
>>>> as
>>>> > route reflectors.  So, using a slighly more interesting topology:
>>>> >
>>>> > PE1 --- RR1 --- RR2 --- PE2
>>>> >
>>>> > PE2 is the source of the excess routes.
>>>> > PE1 is the impacted router.
>>>> > RR1 has only PE1 as a PE device.
>>>> >
>>>> > If PE1 signals to RR1 that it isn't interested in the offending
>>>> routes, RR1
>>>> > may propagate the filter.
>>>> >
>>>> > The issue here is that BGP does not specifically distinguish whether
>>>> an
>>>> > attached BGP Speaker is a PE or not.  The protocol doesn't help you
>>>> make
>>>> > this determination.
>>>> >
>>>> >>> In a network using RT-Constrain without a default RT-Constrain
>>>> route, such a
>>>> >>> graph potentially exists.
>>>> >> [WAJ] RT-Constrain can only express explicitly "what I want" and the
>>>> >> distributed graph. It can't express explicitly "what I don't want"
>>>> now, also
>>>> >> the distribution-block graph. Is that right?
>>>> >
>>>> > That is correct.  But consider the following example:
>>>> >
>>>> >        PE3
>>>> >         |
>>>> > PE1 --- RR1 --- RR2 --- PE2
>>>> >
>>>> > PE2 is the source of the excess routes for VPN RT-A.
>>>> > PE1 is the impacted router.
>>>> > RR1 has PE1 and PE3 as attached PE routers.
>>>> > All routers are configured to use RT-Constrain
>>>> > PE1 and PE2 source RT-Constrain routes for RT-A.  PE3 does not.
>>>> >
>>>> > If PE1 signals to RR1 that it isn't interested in the offending
>>>> routes, and
>>>> > that signal not only includes the offending RD, but also the matching
>>>> RTs,
>>>> > RR1 can determine that there are no further interested receivers for
>>>> that
>>>> > RD+RT and propagate that to RR2.
>>>> >
>>>> > RT-Constrain provides the ability to figure out what the interested
>>>> > receivers are for a VPN defined by a route-target.  This provides a
>>>> > restricted subset of the attached routers for propagation purposes.
>>>> >
>>>> > -- Jeff
>>>> >
>>>>
>>>> _______________________________________________
>>>> Idr mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/idr
>>>>
>>> --
>>>
>>> <http://www.verizon.com/>
>>>
>>> *Gyan Mishra*
>>>
>>> *Network Solutions A**rchitect *
>>>
>>>
>>>
>>> *M 301 502-134713101 Columbia Pike
>>> <https://www.google.com/maps/search/13101+Columbia+Pike?entry=gmail&source=g> *Silver
>>> Spring, MD
>>>
>>> _______________________________________________
>>> Idr mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/idr
>>>
>> --
>
> <http://www.verizon.com/>
>
> *Gyan Mishra*
>
> *Network Solutions A**rchitect *
>
>
>
> *M 301 502-134713101 Columbia Pike *Silver Spring, MD
>
>