Re: [Idr] Adoption and IPR call for draft-wang-idr-vpn-prefix-orf-03.txt (8/16 to 8/30)

[Robert Raszuk <[e-mail]>]

Hello Ajiun,

> not to repeat the biases that can’t bear the close analysis.

I can bear correct analysis just fine. However you are right that I can not
bear nonsense.

However what is more worrying here is that you can not bear facts.

As an example when I explained that RTC can be used for filtering very
effectively subject
only to proper network configuration - all what was pointed back was three
completely
incorrect assertions.

REF: https://mailarchive.ietf.org/arch/msg/idr/ArgFtmvKUrGfcl1X9KRuSC5DH9s/

And it is never a good idea to reinvent the wheel. Or worse reinvent the
square and claim this is a wheel.

You are doing this in both LSR and IDR WGs consistently. It is not helpful.

Rgs,
RR.



On Fri, Aug 26, 2022 at 11:34 PM Aijun Wang <[e-mail]>
wrote:

> Hi, Acee:
>
> Where do you find that the draft add new semantics to the RD?
> Would like to hear your facts before make the conclusions.
> Curious also for your followers.
> We are glad to know your arguments or suggestions, not to repeat the
> biases that can’t bear the close analysis.
>
> Aijun Wang
> China Telecom
>
> On Aug 27, 2022, at 00:35, Acee Lindem (acee) <[e-mail]> wrote:
>
> 
>
> All,
>
>
>
> I agree with Robert on abandoning the proposal – this draft adds new
> semantics to the RD and unneeded complexity for a problem that is already
> solved.
>
>
>
> Thanks,
>
> Acee
>
>
>
> *From: *Idr <[e-mail]> on behalf of Robert Raszuk <
> [e-mail]>
> *Date: *Friday, August 26, 2022 at 8:25 AM
> *To: *Aijun Wang <[e-mail]>
> *Cc: *IDR List <[e-mail]>, Susan Hares <[e-mail]>
> *Subject: *Re: [Idr] Adoption and IPR call for
> draft-wang-idr-vpn-prefix-orf-03.txt (8/16 to 8/30)
>
>
>
> Aijun,
>
>
>
> Indeed this is going in circles ... So let me repeat one more time
> for those who came recently to this discussion.
>
>
>
> When you are offering a LxVPN service (or even ISP Internet Transit) you
> sign with your customer Service Agreement when he declares the number of
> routes he will be sending to you.
>
>
>
> It is clear that you better use platforms which can accommodate that
> service level agreement to construct the connectivity.
>
>
>
> And the way you control/policing this is by PE-CE ingress prefix limit.
>
>
>
> For Inter-AS again you are not to blindly accept everything, but you
> tightly control what is being injected into your network.
>
>
>
> If you think what is in place today to control what is accepted to the
> network is not sufficient I think everyone will welcome new suggestions.
>
>
>
> But you can not take everyone who comes in then just drop them in the
> middle of the flight ...
>
>
>
> This proposal should be abandoned.
>
>
>
> Kind regards,
>
> Robert
>
>
>
>
>
> On Fri, Aug 26, 2022 at 1:55 PM Aijun Wang <[e-mail]>
> wrote:
>
> Hi, Igor:
>
>
>
> What you quoted has stated the VRF Limit mechanism is not enough to
> alleviate the receiving router from parsing the overflowed BGP updates.
>
> We need to push back theses overflowed routes via the VPN Prefixes ORFF
> mechanism, which needs the quota to judge which VPN routes breaks its
> threshold.
>
> Wish the above explanation can help you get the key motivation of this
> draft.
>
> Aijun Wang
>
> China Telecom
>
>
>
> On Aug 26, 2022, at 19:05, Igor Malyushkin <[e-mail]> wrote:
>
> Hi Wei,
>
> Thanks for your comments.
>
>
>
> It seems we are going around the same point again and again. I understand
> what quota gives us, but I don't think that it is necessary (or mandatory)
> and that it should be a core feature of your solution.
> Neither draft-wang-idr-vpn-routes-control-analysis
> nor draft-wang-idr-vpn-prefix-orf gives us a good motivation for that
> (please point me to it if I'm wrong).
>
> Let me quote draft-wang-idr-vpn-prefix-orf:
>
> 5) Configure the Maximum Prefix for each VRF on edge nodes
>
>  When a VRF overflows, it stops the import of routes and log the extra
>
>    VPN routes into its RIB.  However, PEs still need to parse the BGP
>
>    updates.  These processes will cost CPU cycles and further burden the
>
>    overflowing PE.
>
> It does not matter for what reason a VRF`s prefix limit has been
> overflowed (at least I don't see any discussion in the documents about it).
> All we need in this case is to stop receiving routes into this VRF
> whatever the source of them. Maybe it is possible to describe two options
> in your draft? One is based on the VRF prefix limit solely and another is
> for its slicing by source PEs (as you see it). The first is mandatory.
>
>
>
>
>
> пт, 26 авг. 2022 г. в 04:27, Wei Wang <[e-mail]>:
>
> Hi Igor,
>
>     We think the quota value should be set based on the resouce limit of
> the receiver device and the number of route sources(PEs) within the same
> VPN. The aim of the quota is to ensure the resouce is shared/used properly
> among the sources.
>
>     The quota value usually be set much higher than PE-CE limit. It will
> certainly have enough margin to accomodate the possible future expansion
> and need no shrink when one or some the PEs are taken out of the VPN.
>
>
>
> Best Regards,
>
> Wei
>
> ------------------ Original ------------------
>
> *From:* "Igor Malyushkin" <[e-mail]>;
>
> *Date:* Thu, Aug 25, 2022 05:30 PM
>
> *To:* "Aijun Wang"<[e-mail]>;
>
> *Cc:* "Robert Raszuk"<[e-mail]>;"Wanghaibo
> (Rainsword)"<rainsword.wang=[e-mail]>;"Susan Hares"<
> [e-mail]>;"idr@ietf. org"<[e-mail]>;
>
> *Subject:* Re: [Idr] Adoption and IPR call for
> draft-wang-idr-vpn-prefix-orf-03.txt (8/16 to 8/30)
>
>
>
> Hi Aijun,
>
> Thanks for the comments, please see the inline below.
>
>
>
> чт, 25 авг. 2022 г. в 08:30, Aijun Wang <[e-mail]>:
>
> Hi, Igor:
>
>
>
> The setting of quota value is the matter of management issue, and should
> be decoupled from the control plane.
>
> [IM] From my point of you in your specification, this is the only option.
>
> If you select to let the source PEs advertise such value, it is possible
> that they change it along with their overflow VPN routes.
>
> [IM] Well, if the limit between a source and destination PEs should be
> linked as you are suggesting, increasing some value for one VRF cannot be
> made without of review other VRFs among a common VPN. No matter if the
> limit is set manually on a destination PE or dynamically synced from a
> source. A network design should be consistent.
>
> And from the POV of the receiver PE, before you setting the prefix limit
> under each VRF, you should have the well estimated quota/value from each PE
> or each VRF.
>
> [IM] That is where we do not agree with each other. From my perspective,
> if we are talking about local PE protection then setting a limit under a
> VRF is a matter of the number of all VRFs under the PE and some memory
> limits of the PE. And the VRF limit, in this case, does not be the same as
> the sum of all incoming routes, it can be slightly bigger. If we see
> warnings (say, we've just exceeded 80%) we are considering increasing this
> value (if the memory limit allows it) or updating the hardware. Your
> suggestion requires reviewing the limits for all VRFs every time we add or
> remove a VRF-PE pair (not to mention configuring of these limits). And at
> the end of the day, you actually reach the same local memory limit. I want
> to remember that the solution you are suggesting actually does not depend
> on how we set the prefix limit for the VRF. When it is reached we just
> signal to stop sending.
>
> As stated before, in most of the situation, the per <PE> or per <RD, PE>
> quota will be the same value, the operator will not let the design of its
> network too complex to operate, but the standard should provide the finer
> control capabilities.
>
>  [IM] I believe the standard should provide finer control for a reason.
> Let's imagine that without these quotas the solution will not work, but it
> will.
>
>  This is same as the usage of RD within the network. There is no scenario
> that the operator to allocate different RDs for one VPN on the same PE.
> What we often do is that we allocate different RDs for the same VPN on
> different PEs. Then RD is the right value to distinguish the VPNs on one PE.
>
>  [IM] All I wanted is to point to the authors that from the parent
> standards POV an RD is not a unique ID for a VRF (under a single PE). Some
> scenarios may emerge in the future.
>
>
>
>
>
> Best Regards
>
>
>
> Aijun Wang
>
> China Telecom
>
>
>
> *From:* [e-mail] <[e-mail]> *On Behalf Of *Igor
> Malyushkin
> *Sent:* Thursday, August 25, 2022 3:14 AM
> *To:* Robert Raszuk <[e-mail]>
> *Cc:* Wanghaibo (Rainsword) <rainsword.wang=[e-mail]>;
> Susan Hares <[e-mail]>; [e-mail]
> *Subject:* Re: [Idr] Adoption and IPR call for
> draft-wang-idr-vpn-prefix-orf-03.txt (8/16 to 8/30)
>
>
>
> For sure it is design-depended. If every VRF has its own RT it will work.
> But I think if we have a mechanism that allows us to attach several RTs to
> a route we are in a trouble. Guys are just typing to cover this case.
>
>
>
> If we talk in general about a whole solution I also think that the way
> with the new AFI/SAFI is much better. I also don't understand the benefits
> behind quotas per VRF-PE pair, but if it is really worth the time I expect
> to see the propagation of these quotas from source PEs instead of a manual
> configuration. I think it can be easily introduced into a solution with the
> new AFI/SAFI.
>
>
>
> ср, 24 авг. 2022 г. в 21:05, Robert Raszuk <[e-mail]>:
>
> Igor,
>
>
>
> RT can uniquely distinguish src vrf. It is simply a matter of
> proper configuration. No ned protocol extension is required.
>
>
>
> Thx,
>
> R.
>
>
>
> On Wed, Aug 24, 2022 at 9:03 PM Igor Malyushkin <[e-mail]>
> wrote:
>
> Hi Haibo,
>
>
>
> 2) It is unpractical to set the quota value for <RT>, or <RT, PE> under
> VRF, because RT can't uniquely distinguish one VRF on one PE.
>
> What if a VRF has several RDs for its routes? RFC4364 and RFC4659 don't
> restrict this behavior and even more, it explicitly describes it. So, RD
> also can't uniquely distinguish one VRF. Looks like we need a different
> marker for all routes belonging to the same source VRF. Say, VPN ID
> community or something like that.
>
>
>
>
>
> ср, 24 авг. 2022 г. в 18:26, Wanghaibo (Rainsword) <rainsword.wang=
> [e-mail]>:
>
> Hi Sue and WG,
>
>
>
> I support this adoption.
>
> This draft proposes the mechanism to control the overflow of VPN routes
> within one VRF from influencing other VPNs on the same device
> automatically.
>
>
>
> The updated contents have accommodated the suggestions and addressed the
> comments raised within the WG discussions. Some additional concerns can be
> addressed after the adoption.
>
>
>
> I am not aware of any undisclosed IPR to this draft.
>
>
>
> To make the actual progress of this draft, we should avoid to discuss the
> solved points back and forth. For example, RTC mechanism is not suitable
> for the scenarios that described in this adoption draft, because:
>
> 1) RTC has no any automatic detection mechanism to determine which RT
> should be withdrawn now.
>
> 2) It is unpractical to set the quota value for <RT>, or <RT, PE> under
> VRF, because RT can't uniquely distinguish one VRF on one PE.
>
> 3) It is dangerous to propagate the RT based filter rule unconditionally
> in the intra-domain or inter-domain wide, as that done in current RTC
> mechanism.
>
>
>
> The conclusion, RTC is not the right direction to accomplish the goal.
>
>
>
> Regards,
>
> Haibo
>
>
>
> *From:* Idr [mailto:[e-mail] <[e-mail]>] *On
> Behalf Of *Susan Hares
> *Sent:* Tuesday, August 16, 2022 11:56 PM
> *To:* [e-mail]
> *Subject:* [Idr] Adoption and IPR call for
> draft-wang-idr-vpn-prefix-orf-03.txt (8/16 to 8/30)
>
>
>
> This begins a 2 week WG Adoption call for
> draft-wang-idr-vpn-prefix-orf-03.txt
>
> https://datatracker.ietf.org/doc/draft-wang-idr-vpn-prefix-orf/
>
>
>
> The authors believe that they have addressed the concerns raised in
>
> the previous 2 WG adoption calls.
>
>
>
> The WG should consider if:
>
>
>
> 1) The revised text answers the previous concerns regarding
>
> the scope of this draft?
>
>
>
> 2) Does the revised text provide a useful function for
>
> networks?
>
>
>
> 3) Are there any additional concerns regarding the new text?
>
>
>
> Each of the authors should send an IPR statement for
>
> this version of the draft.
>
>
>
> The adoption call was moved to 8/29 to 8/30 to allow questions
>
> to be asked at the IDR interim meeting on 8/29/2022 (10am – 12pm EDT).
>
>
>
> Cheers, Sue Hares
>
> _______________________________________________
> Idr mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/idr
>
> _______________________________________________
> Idr mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/idr
>
> _______________________________________________
> Idr mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/idr
>
>