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

[Robert Raszuk <[e-mail]>]

Aijun,


> Your proposal just let RTC act as the behavior of RD-ORF.
> I think no one will agree with you.
>

I think you did not understand it. But that's ok.

And if you think that it is better to make any routing protocol decision
(in regards to route distribution) by collecting information from more then
one protocol source then indeed no point to discuss this  any further.

Kind regards,
R.



> I think what Jeff’s proposal is to utilize the information from RTC to let
> the RR decide when to send out the RD-ORF message on behalf of its peers,
> not to change the behavior of RTC.
>
> Aijun Wang
> China Telecom
>
> > On Feb 26, 2021, at 18:48, 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 ?
>
> [WAJ] The action on RR then will be advertised VPN routes that with RT200,
> but the RD part is not 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).
>
> [WAJ] Normally RTC message will be flooded within the network immediately
> . Your proposal here just let it wait responses from all its peers. If so,
> why using BGP UPDATE message?
>
> >
> > 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
>
>