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

[Gyan Mishra <[e-mail]>]

Slide deck looks good to present.  All set.

Thanks

Gyan

On Wed, Mar 3, 2021 at 1:54 AM Aijun Wang <[e-mail]> wrote:

> Hi, Gyan:
>
>
>
> I have finished the draft of presentation material, which is slightly
> different from the uploaded draft.
>
> Please review it whether it is enough for the presentation. I will update
> the draft accordingly in these days if we have consensus on the
> presentation material.
>
>
>
> We have also discussed also the solution yesterday offline with experts
> from Huawei.  Will update the solution draft after the WG consensus on the
> problem analysis draft.
>
>
>
> 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/>
>
> *Gyan Mishra*
>
> *Network Solutions Architect *
>
>
>
> *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 Architect *
>
>
>
> *M 301 502-134713101 Columbia Pike *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