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,

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