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, I believe the upcoming updates will fill the gaps.


вт, 23 авг. 2022 г. в 03:15, Aijun Wang <[e-mail]>:

> Hi, Igor:
>
>
>
> The reason that we keep <RD, PE> quota in the standard is that there are
> possibility that the source VPN(different RD) on source PE may have
> different prefix advertisement limit, although it is not very common. We
> would like to add one section later (after the adoption?) for the
> “Deployment Considerations” to introduce some principles/guidelines for the
> quota value setting. But for standard definition itself, we should keep
> such granularity.
>
> For the value of “Source PE Extended Community”, I think your argument are
> valid. The BGP router id of the source PE is one better value to identify
> the source PE, than the Next-hop value within the BGP update message. We
> would like to update the related contents as the followings:
>
>      A new Extended Community: Source PE Extended Community is needed to preserve the source PE identification. Its value should be set by the RR (similar with the BGP ORIGINATOR_ID attributes) or the router that peers with the source PE (non-RR scenario), as the BGP Router ID of the corresponding BGP session. Once set and attached with the BGP update message, its value should not be changed along the advertisement path.
>
>
>
> Wish the above proposed update contents can address your concerns.
>
>
>
> Best Regards
>
>
>
> Aijun Wang
>
> China Telecom
>
>
>
>
>
>
>
> *From:* Igor Malyushkin <[e-mail]>
> *Sent:* Sunday, August 21, 2022 9:44 PM
> *To:* Aijun Wang <[e-mail]>
> *Cc:* Susan Hares <[e-mail]>; [e-mail]; Zhuangshunwan
> <zhuangshunwan=[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 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.
>
>