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

[Igor Malyushkin <[e-mail]>]

Hi Aijun,

Thanks for the clarification.

Please see the inline below

вс, 21 авг. 2022 г. в 13:14, 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?
>
[IM] Correct.


> 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.
>
[IM] In general, I understand the idea coming with this flexibility. But it
is unclear what are the goals behind it. The idea of the offered solution
is to stop receiving VPN routes when a destination VRF is offended, which
is a sub-task of preventing the offending of a whole PE. Is it important
whether the VRF`s limit was depleted by a single source PE or by a group of
them? The impact on the control plane is the same.

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.
>
 [IM] This way I'd expect to configure some value under a VRF of a source
PE. Say, "I-can-normally-send-no-more-than" and propagate it *somehow* to
others letting them construct a list of <S-PE, RD, limit> dynamically. But
it is just an idea :)

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.
>
[IM] Thank you for noticing. But I disagree with linking to the NEXT_HOP
attribute in the sense of identification of a PE in any possible way. A
value from the NEXT_HOP attribute is a pure transport entity. For example,

         A new Extended Community: Source PE Extended Community is needed to

      preserve the NEXT_HOP attribute before being rewritten by ASBRs.

I think the community doesn't need to preserve the NEXT_HOP unless you are
going to somehow use this next-hop for traffic forwarding, this community
is needed to contain a router ID of a source PE and is pure control plane
entity. Thus, I believe Section 5.1 should be rewritten.


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