Re: [Idr] Adoption and IPR call for draft-wang-idr-vpn-prefix-orf-03.txt (8/16 to 8/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. If you select to let the source PEs advertise such value, it is possible that they change it along with their overflow VPN routes.

 

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.  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.

 

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.

 

 

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] <mailto:[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] <mailto:[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] <mailto:[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]] On Behalf Of Susan Hares
Sent: Tuesday, August 16, 2022 11:56 PM
To: [e-mail] <mailto:[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] <mailto:[e-mail]> 
https://www.ietf.org/mailman/listinfo/idr

_______________________________________________
Idr mailing list
[e-mail] <mailto:[e-mail]> 
https://www.ietf.org/mailman/listinfo/idr