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 <wangaijun@tsinghua.org.cn>:

> 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:* idr-bounces@ietf.org <idr-bounces@ietf.org> *On Behalf Of *Igor
> Malyushkin
> *Sent:* Thursday, August 25, 2022 3:14 AM
> *To:* Robert Raszuk <robert@raszuk.net>
> *Cc:* Wanghaibo (Rainsword) <rainsword.wang=40huawei.com@dmarc.ietf.org>;
> Susan Hares <shares@ndzh.com>; idr@ietf.org
> *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 <robert@raszuk.net>:
>
> 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 <gmalyushkin@gmail.com>
> 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=
> 40huawei.com@dmarc.ietf.org>:
>
> 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:idr-bounces@ietf.org <idr-bounces@ietf.org>] *On
> Behalf Of *Susan Hares
> *Sent:* Tuesday, August 16, 2022 11:56 PM
> *To:* idr@ietf.org
> *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
> Idr@ietf.org
> https://www.ietf.org/mailman/listinfo/idr
>
> _______________________________________________
> Idr mailing list
> Idr@ietf.org
> https://www.ietf.org/mailman/listinfo/idr
>
>