Re: [Idr] https://tools.ietf.org/html/draft-wang-idr-rd-orf-00

[Robert Raszuk <[e-mail]>]

That is true indeed.

Good point !

R.



On Fri, Jul 17, 2020 at 12:58 AM Jakob Heitz (jheitz) <[e-mail]>
wrote:

> Can't we already do an RD ORF anyway?
>
> Using an address-prefix ORF in the VPN address family with prefix length
> 64.
>
>
>
> Regards,
>
> Jakob.
>
>
>
> *From:* Robert Raszuk <[e-mail]>
> *Sent:* Thursday, July 16, 2020 2:58 PM
> *To:* Jakob Heitz (jheitz) <[e-mail]>
> *Cc:* Aijun Wang <[e-mail]>; idr@ietf. org <[e-mail]>
> *Subject:* Re: [Idr] https://tools.ietf.org/html/draft-wang-idr-rd-orf-00
>
>
>
>
>
> > but only one of them is sending too many routes.
>
>
>
> Well PEs do not produce routes all by themselves :)
>
>
>
> They receive it from CEs. /* Likewise ASBRs option B receive it from
> other ASBRs. */
>
>
>
> So one's network should be able to handle an agreed number of routes as
> defined in VPN service. For anything above that in order to protect PE
> control and data planes prefix limit is the tool to apply towards your
> local peers which could result with src session down till NOC diagnoses the
> issue.
>
>
>
> Thx,
>
> R.
>
>
>
>
>
>
>
>
>
> On Thu, Jul 16, 2020 at 11:22 PM Jakob Heitz (jheitz) <[e-mail]>
> wrote:
>
> I can see how you might want to do max-prefix filtering by RD.
>
> Suppose there are many PEs in an AS that all have VRFs for the same VPN,
>
> but only one of them is sending too many routes.
>
> In that case, you can't filter just that one VRF by RT.
>
> You need RD.
>
> Sure, you will end up with partial routes and a bit of a mess, as Robert
> points out, but that's the nature of max-prefix anyway. It is a safety
> valve that prevents a big disaster by causing a smaller disaster.
>
>
>
> One thing I do see a problem with is that the RR or ASBR propagates
>
> a received ORF back to the source of the routes.
>
> That RR or ASBR may have other clients that still want the routes.
>
> ORFs are not designed to be propagated.
>
>
>
> Regards,
>
> Jakob.
>
>
>
> *From:* Idr <[e-mail]> *On Behalf Of *Robert Raszuk
> *Sent:* Thursday, July 16, 2020 12:21 PM
> *To:* Aijun Wang <[e-mail]>
> *Cc:* idr@ietf. org <[e-mail]>
> *Subject:* Re: [Idr] https://tools.ietf.org/html/draft-wang-idr-rd-orf-00
>
>
>
> Aijun,
>
>
>
> I do understand that you want to push in RD-ORD pre import RDs. Perhaps
> selecting first those which advertise the most VPN routes.
>
>
>
> But this is so severely broken idea that I am not sure how to even
> describe it. Just imagine the mess of now partially broken VPN users which
> asked for full mesh and got now partially working and partially broken
> mesh.
>
>
>
> This would be also terrible to troubleshoot (even assuming that you would
> refrain from RD-ORF propagation).
>
>
>
> Bottom line - to control number of VPN routes - for years operators have
> deployed prefix limit on ingress to the SP network (PE-CE edge). Once
> prefix is accepted into a network it better be installed when VPN topology
> requires it.
>
>
>
> Filtering per RD is a really BAD IDEA.
>
>
>
> Thx,
> R.
>
>
>
> On Thu, Jul 16, 2020 at 10:58 AM Aijun Wang <[e-mail]>
> wrote:
>
> Hi, Robert:
>
>
>
> When the RD is designed as per VRF per PE, the mechanism of RD based ORF
> can also apply-------The received router needs only extract and reflect the
> most influenced RDs back to upstream router(ASBR/RR),  and then to notify
> the source of these VPN routes to control the prefixes advertisement.
>
> Actually, the above design will make the RD-ORF more accurate than the RT
> based control.
>
>
>
>
>
> Best Regards
>
>
>
> Aijun Wang
>
> China Telecom
>
>
>
>
>
>
>
> *From:* [e-mail] [mailto:robert@raszuk..net <[e-mail]>]
> *Sent:* Thursday, July 16, 2020 3:06 PM
> *To:* Aijun Wang <[e-mail]>
> *Cc:* [e-mail]; Aijun Wang <[e-mail]>;
> idr@ietf. org <[e-mail]>
> *Subject:* Re: [Idr] https://tools.ietf.org/html/draft-wang-idr-rd-orf-00
>
>
>
> > It can also be used to identify the VPN customer.
>
>
>
> Sorry but no.
>
>
>
> Best practice for number of reasons is to make RD unique per VRF and not
> per VPN. We should not standardize something which is a pretty bad idea to
> start with.
>
>
>
> Kind regards,
>
> Robert
>
>
>
>
>
>
>
>
>
>
>
> On Thu, Jul 16, 2020 at 4:40 AM Aijun Wang <[e-mail]>
> wrote:
>
> Hi, Robert:
>
>
>
> Thanks for your reviews and comments.
>
> As you said, RD is to make the VPN prefix unique within the VPN’s domain.
> It can also be used to identify the VPN customer.
>
> The usage of RT, just as you said, is to control what routes are
> distributed where, that is to say, to control the customer’s VPN
> topology. RT can’t be used to identify one VPN customer.
>
>
>
> The scenarios/problems described in this draft(
> https://tools.ietf.org/html/draft-wang-idr-rd-orf-00) are not for the VPN
> topology control, but for the VPN prefix limit management, which is signed
> along with the agreement with the VPN customer.
>
> This is the reason that we select the RD-based ORF control mechanism.
>
>
>
> More detail reply are inline below. Wish to get more your
> comments/suggestions on them.
>
>
>
> Thanks in advance.
>
>
>
> Best Regards
>
>
>
> Aijun Wang
>
> China Telecom
>
>
>
> *From:* [e-mail] [mailto:[e-mail]] *On Behalf Of *Robert
> Raszuk
> *Sent:* Thursday, July 16, 2020 2:26 AM
> *To:* [e-mail]; Aijun Wang <[e-mail]>
> *Cc:* idr@ietf. org <[e-mail]>
> *Subject:* [Idr] https://tools.ietf.org/html/draft-wang-idr-rd-orf-00
>
>
>
> Dear Aijun & Wei,
>
>
>
> I have read your draft as per subject.
>
>
>
> I think there is a serious misunderstanding on what RD's role is
> in RFC4364.
>
>
>
> RDs MUST never be used to signal anything which would in any way influence
> what routes are distributed where. Their sole role is to make the VPN
> prefix unique across given VPN's domain.
>
> 【WAJ】RD can be used to identify one VPN customer
>
>
>
> It is RTs which are used to import routes to VRFs on PEs. What you are
> trying to do is exactly why we have defined some time back RTC (RFC4684).
> Applications from section 5.1 and 5.2 can be happily addressed with use of
> RTC.
>
> 【WAJ】RT is used to control VPN topology, same as the mechanism of
> RTC(4684). But the application described in section 5.1 and 5.2 of this
> draft is not for VPN topology control, but for VPN route-limit management,
> which is based on customer/RD.
>
>
>
> Informationally let me also point out that RFC7543 has defined extensions
> to ORF to signal RTs for reducing size VPN RIBs in specific Hub & Spoke
> topologies.
>
> 【WAJ】RFC7543 is to pull the prefix that cover one specific host address,
> to get the more optimal route information from the Hub, not the same
> scenarios as described in the current draft.
>
>
>
> Last your proposal calls for treating ORF as a transitive message without
> any loop protection. That is not a good idea.
>
> 【WAJ】ORF messages are exchanged within only the directed BGP sessions.
> Such Messages will be regenerated when it is needed to send to another BGP
> peer.  Would you like to describe more for the loop scenarios?
>
>
>
> I recommend to protect your PEs from being overwhelmed by VPN routes by
> prefix limit instead.
>
> 【WAJ】Prefix Limit mechanism can be used for Option –A, but not for Option
> B/C, as that described in the draft.
>
>
>
> Kind regards,
>
> R.
>
>
>
> PS. Did we have any discussion in IDR or BESS on this proposal ?
>
>
>
>