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:

Thanks for your comments!
If I get your points correctly, what your concerns are how to configure the per <RD,PE> quota in each PE? Actually, in practical deployment, this value will be same for each <RD,PE> tuple and can be set one default value. The reason that we provide such flexibility is that it can accommodate more deployments requirements. In very extreme situation, this value may be different per <RD,PE>, but even in such situation, the management planes for the VPN services can get such distinguished quota in advance and configure them on PE.

For the source PE information, we have proposed one “Source PE Extended Community” to accommodate the original source PE information. I think it can be used in your mentioned “core diversity pattern” VPN deployment scenarios.


Aijun Wang
China Telecom

> On Aug 20, 2022, at 20:27, Igor Malyushkin <[e-mail]> wrote:
> 
> 
> Some additions. In the offered model when a PE sends a notification based on its preconfigured limits, there is no option for AD, so this moment is not actual. But the problem is still actual. It's not clear to me why we need to preconfigure some quota per every possible source PE. Reading the draft and the analysis document didn't shed the light.
> I'm really sorry if this question was raised and was answered previously. If it is so a link to the conversation would be great :)
> 
> сб, 20 авг. 2022 г. в 12:54, Igor Malyushkin <[e-mail]>:
>> Hi all,
>> 
>> This draft requires configuring limits for every possible VRF on a PE with every possible pair of "source PE, RD" for these VRFs. For many deployments, such an approach leads to an operation burden. From my perspective, it is desirable to have some auto-discovery mechanism for these limits if the community is going to proceed with this draft.
>> 
>> Also, Section 5.1 states:
>>   In single-domain or Option C cross-domain scenario, NEXT_HOP attribute is unchanged during routing transmission, so it can be used as source address.
>> 
>> It is not actually true. There are some deployments using different next-hops for outbound VPN routes belonging to a single PE-VRF pair (e.g., core diversity pattern). Thus, there should be a more precise definition of a source PE that is absolutely decoupled from the NEXT_HOP attribute.