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 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] <mailto:[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] <mailto:[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] <mailto:[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.