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

[Susan Hares <[e-mail]>]

Aijun: 

 

As a chair, I did not hear consensus on the problem statement in the meeting yesterday or on the mail list.   One issue with the shorter meeting times is the lack of time to discuss these issues.  If you wish to have a longer meeting discussion, we can scheduling an interim to discuss your problem statement.

 

As the shepherd handling your adoption calls for a solution, I would like to have a consensus call on your problem statement. 

 

Please let me know if you wish to schedule an interim prior to a consensus call on your problem statement.  

 

Cheerily, Sue 

 

From: Idr [mailto:[e-mail]] On Behalf Of Aijun Wang
Sent: Tuesday, March 9, 2021 9:34 PM
To: 'Aijun Wang'; 'Robert Raszuk'; 'Jakob Heitz (jheitz)'; 'UTTARO, JAMES'; [e-mail]
Cc: [e-mail]; [e-mail]
Subject: Re: [Idr] draft-wang-idr-vpn-routes-control-analysis (was Re: rd-orf problem clarification at the local level)

 

Hi, all:

 

As introduced and explained by Gyan in yesterday’s IDR meeting, we have analyzed the potential VPN routes control scenarios, solution requirements and proposed solution within the document https://datatracker.ietf.org/meeting/110/materials/slides-110-idr-sessa-analysis-of-vpn-routes-control-in-shared-bgp-session-00.pdf

 

Here we want to know can we consensus on the scenarios and solution requirements analysis now?

If so, we can begin the discussion of proposed solution. If not, we would like to receive your feedbacks/comments on the mail list then.

 

After offline discussions within the co-authors of draft https://datatracker.ietf.org/doc/draft-wang-idr-rd-orf/ for the potential solutions to the mentioned scenarios, we found the original RD-ORF semantic is enough to meet the solution requirements, no need to add additional RT information. 

Only the behaviors of the received PE, RR/ASBR and the propagation procedure of RD-ORF message should be updated/clarified, which are also mentioned in yesterday’s presentation.

The usage of sequence field in current RD-ORF semantic will also be updated in next version, as discussed with Jeffrey in previous mail.

 

Best Regards

 

Aijun Wang

China Telecom

 

From: [e-mail] <[e-mail]> On Behalf Of Aijun Wang
Sent: Saturday, February 27, 2021 8:41 AM
To: Robert Raszuk <[e-mail]>
Cc: [e-mail]; [e-mail]
Subject: Re: [Idr] draft-wang-idr-vpn-routes-control-analysis (was Re: rd-orf problem clarification at the local level)

 

Hi, Robert:

If you use non-transitive attributes, every in-path router must decide and add/delete it based on its justification. 

If so, why bother RTC and why use the BGP-Update message? ORF/Route-refresh message is the right mechanism to utilize.

Aijun Wang

China Telecom

 

On Feb 27, 2021, at 08:18, Robert Raszuk <[e-mail]> wrote:



 

I am not proposing anything new nor change to RTC dynamics or current fundamental operation model of RTC. 

 

RTC NLRIs would be flooded just like today however it is just like with some attributes or non transitive at domain border communities that routers drop them before propagating over ebgp here we would not propagate by default this new attribute. Actually it should be non transitive - I am self correcting myself here. 

 

Here the definition of handling this attribute would be not to propagate within it such RDs to other ibgp or ebgp peers unless all requesters indicating interest with given RT also signalled such filtering request for those RDs. Obviously there should be no need to also propagate such attribute with an empty list of RDs. 

 

Sure as pointed by Jakob when new peer comes up and he sends interest in those RT(s) without RD such routes must be sent to him or requested upstream. All easily doable if and only if there is real need for it. 

 

Thx

R.

 

On Sat, Feb 27, 2021 at 12:51 AM Aijun Wang <[e-mail]> wrote:

Hi, Robert:

 

We should keep mind that the message “What I want(expressed by RTC)” can be flooded automatically throughout the network, but “What’s I don’t want(expressed by RD-ORF)” should not be flooded out unconditionally.

Try to use RTC to express “What I don’t want” within the network(not just in one device) will change the RTC mechanism dramatically, not just the unrecognized transitive attributes.

 

On the contrary, ORF based solutions can cover the situations what RTC aimed. Don’t you think so?

Aijun Wang

China Telecom

 

On Feb 27, 2021, at 00:28, Robert Raszuk <[e-mail]> wrote:



 

 

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/> Image removed by sender.

Gyan Mishra

Network Solutions Architect 

M 301 502-1347
13101 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/> Image removed by sender.

Gyan Mishra

Network Solutions Architect 

M 301 502-1347
13101 Columbia Pike 
Silver Spring, MD

 

_______________________________________________
Idr mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/idr