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

[Robert Raszuk <[e-mail]>]

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