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