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

[Robert Raszuk <[e-mail]>]

First when BGP max prefix used session should get terminated with a peer.

Then Max prefix is to be used on eBGP sessions only.

Using it on IBGP is dangerous. Not a recommended configuration.

Thx,
R.


On Tue, Aug 23, 2022 at 1:39 PM 王巍 <[e-mail]> wrote:

> Hi Robert,
>
> The offending VPN routes are dropped because they pass the predefined
> quota threshold, it’s the similar behavior for “BGP maximum prefixes”
> mechanism.
> Before dropping, the device can also send the alarm signal to operator.
>
> Dropping them can assure the offending VPN routes does not affect the
> receiving and parsing of routes belong to other VPNs.
> The updated VPN Prefixes ORF mechanism filter the routes not solely based
> on RD or prefix.
>
> Best Regards,
> Wei
> ------------------ Original ------------------
> *From:* "Robert Raszuk" <[e-mail]>;
> *Date:* Tue, Aug 23, 2022 04:46 PM
> *To:* "Aijun Wang"<[e-mail]>;
> *Cc:* "Susan Hares"<[e-mail]>;"idr@ietf. org"<[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)
>
> Aijun,
>
> > Wish it can help for you to flip the page.
>
> I recall this thread, but it did not "flip the page".
>
> See dropping VPN routes when CE points default to a PE (very common case)
> will just result in less specific forwarding (potential loops as IBGP
> becomes inconsistent now) or at best silent drops at the PEs. Authors
> somehow forgot that it is a really bad idea and very unsafe to drop valid
> routes on IBGP.
>
> Note that non intersecting RT based drop is safe. But not per prefix or
> per RD drops !
>
> Besides if we are talking at scale to do what you are describing requires
> lots of real time per path per vrf stats. That's a CPU burden which is
> completely unnecessary.
>
> > And, the deny-focusing mechanism (VPN Prefixes ORF) acts differently
> from the allow-focus mechanism (RTC).
>
> You missed my point.
>
> While RTC today indeed expresses the list of required RTs nothing stops
> you to define RTC-like AF based propagation with deny semantics.
>
> Thx,
> Robert.
>
>
> On Tue, Aug 23, 2022 at 3:56 AM Aijun Wang <[e-mail]>
> wrote:
>
>> Hi, Robert:
>>
>>
>>
>> For your concerned points regarding to the ordering of path, I recommend
>> that you review again our discussion with Jeffrey Haas on various scenarios
>> at https://mailarchive.ietf.org/arch/msg/idr/uoQO8vqSA82UCrfXppFjwNbMg1A/.
>> Wish it can help for you to flip the page.
>>
>>
>>
>> And, the deny-focusing mechanism (VPN Prefixes ORF) acts differently from
>> the allow-focus mechanism (RTC). The former should be decided based on each
>> hop itself, and should not be propagated further unconditionally, as that
>> done in RTC mechanism. We don’t want to repeat the discussed points again.
>>
>>
>>
>> Best Regards
>>
>>
>>
>> Aijun Wang
>>
>> China Telecom
>>
>>
>>
>> *From:* Robert Raszuk <[e-mail]>
>> *Sent:* Sunday, August 21, 2022 8:00 PM
>> *To:* Aijun Wang <[e-mail]>
>> *Cc:* Susan Hares <[e-mail]>; idr@ietf. org <[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)
>>
>>
>>
>> Aijun,
>>
>>
>>
>> Actually I did read the -03 version of the draft and changes made
>> actually make it even less attractive.
>>
>>
>>
>> Let's first establish what is the format of the ORF message you are
>> proposing to advertise and when those optional TLVs are added ?
>>
>>
>>
>> Quote 1 - PE2 triggers the VPN  Prefix ORF message *(RD1, RT1, comes
>> from PE3)*.
>>
>>
>>
>> Quote 2 - VPN Prefix ORF entry *(RD31, RT1, RT2, comes from PE3)*
>>
>>
>>
>> Your email suggest that *"and global allocation(in this case, the source
>> PE will be attached)"*
>>
>>
>>
>> There is no clear and exhaustive definition when each defined TLV (Source
>> PE or RT) needs to be added by the node generating this new ORF message.
>>
>>
>>
>> It is fascinating that you have now added a list of RTs to the spec. We
>> argued from the beginning that a list of RTs offers a good solution for
>> such filtering and RTC RFC4684 can be used instead.
>>
>>
>>
>> More inline ...
>>
>>
>>
>> #1 - RD allocation can be per VRF or Global in a given VPN. This scheme
>> works only in the case of per VRF allocation.
>>
>> [WAJ]The proposed mechanism works both in per VRF allocation and global
>> allocation(in this case, the source PE will be attached)
>>
>>
>>
>>
>>
>> How do you handle multipaths ? How do you handle anycast ? How do you
>> determine the src PE ?
>>
>>
>>
>> Please observe that during import there is no ordering of paths. So when
>> you are just about to reach the vrf prefix limit and 95% of imported routes
>> come from PE1 suddenly the vrf prefix limit is exceeded when just a few
>> paths arrive from PE2. Are you now going to suppress those few routes as
>> they were unlucky and happened to exceed the prefix limit ?
>>
>>
>>
>>
>>
>> #3 - Use of prefix ORF can be applied where prefix is just /64 RD without
>> any new draft. The draft says:
>>
>>
>>
>>
>>
>> *Using Address Prefix ORF to filter VPN routes need to pre-
>>  configuration, but it is impossible to know which prefix may cause
>>  overflow in advance.*
>>
>>
>>
>>     .. which clearly is not correct as irrespective on the encoding you
>> need to know what RD to push.
>>
>>     Here in this context of RFC5292 PREFIX == RD == /64 PREFIX
>>
>>
>> [WAJ] This point has been discussed throughly in the first round
>> discussions. The key answer is that you cannot know in advance which RD
>> will cause the overflow VPN routes. And one more point again, current VPN
>> ORF prefixes doesn’t depend only the automatic extracted RD information.
>>
>>
>>
>> No one is saying you need to know this in advance. Sure questionable
>> source PE and RTC like list of RTs will not fit RFC5292.
>>
>>
>>
>> While we are at this, asking anyone to configure a list of <src RDs+src
>> PEs> limits on each PE is beyond even commenting on.
>>
>>
>>
>> #4 - Change of ORF list results in advertisement of ALL routes of a a
>> given AFI/SAFI to the peer.
>>
>>         That is the same irrespective if IMMEDIATE or DEFER flags are
>> set. That puts burden on the peer especially in
>>
>>         VPN cases when the number of routes may be high.
>>
>>
>> [WAJ] What you described is the current ORF mechanism. There are some
>> spaces to optimize it.
>>
>>
>>
>>
>>
>> Yes this is how ORF works.
>>
>>
>>
>> And I don't think there is any consensus to break it.
>>
>>
>>
>> Actually looking at your -03 version I have a suggestion.
>>
>>
>>
>> Forget about hacking ORF. Just use new SAFI and push those policies in
>> the new address family. Just like we did with RTC. And please do not try to
>> fix RTC :) Leave it alone and transfer your policy to new AFI/SAFI
>> advertisements.
>>
>>
>>
>> It will also be automatically transitive so you should have much better
>> coverage with that.
>>
>>
>>
>> Alternatively you may find some traction to add this into Flowspec v2
>> work.
>>
>>
>>
>> Kind regards,
>>
>> Robert
>>
>>
>>
>