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

[John E Drake <[e-mail]>]

Hi,

As I have indicated, I think the subject draft is fundamentally unsound and incompletely specified and I don’t support its adoption.

Yours Irrespectively,

John



Juniper Business Use Only
From: Idr <[e-mail]> On Behalf Of Aijun Wang
Sent: Tuesday, August 30, 2022 10:51 AM
To: John E Drake <jdrake=[e-mail]>
Cc: idr <[e-mail]>; Robert Raszuk <[e-mail]>; Sue Hares <[e-mail]>
Subject: Re: [Idr] Adoption and IPR call for draft-wang-idr-vpn-prefix-orf-03.txt (8/16 to 8/30)

[External Email. Be cautious of content]

Hi, John:

I think you can discuss Robert’s approach within BESS from the scratch.

I think you should know the VPN Prefixes ORF mechanism has been analyzed throughly within the IDR, the updated draft has incorporated many comments/suggestions that the IDR experts provides.
It is now the solid base to solve the problem and we have also analyzed other possible approaches, which have been also discussed within IDR intensely.

So, if you are also interested this topic, I think you can start the journey at the BESS. We are glad to hear your comments for VPN Prefixes ORF solution within IDR WG.

Aijun Wang
China Telecom

On Aug 30, 2022, at 22:13, John E Drake <jdrake=[e-mail]<mailto:jdrake=[e-mail]>> wrote:

Hi,

I think Robert’s approach is a much better solution to the problem and it obviates the need for the subject draft.  As an aside, why isn’t this topic being discussed in bess rather than idr?

Yours Irrespectively,

John



Juniper Business Use Only
From: Idr <[e-mail]<mailto:[e-mail]>> On Behalf Of Gyan Mishra
Sent: Tuesday, August 30, 2022 9:56 AM
To: Robert Raszuk <[e-mail]<mailto:[e-mail]>>
Cc: idr <[e-mail]<mailto:[e-mail]>>; Sue Hares <[e-mail]<mailto:[e-mail]>>
Subject: Re: [Idr] Adoption and IPR call for draft-wang-idr-vpn-prefix-orf-03.txt (8/16 to 8/30)

[External Email. Be cautious of content]


Hi Robert

We would like to hear your thoughts on ORF towards source PE.

I do agree that would help stop the problem at the source which we can add to the overall solution.

Kind Regards

Gyan
On Tue, Aug 30, 2022 at 4:49 AM Robert Raszuk <[e-mail]<mailto:[e-mail]>> wrote:

To close this discussion I do not agree at all with neither point #1 or #2 in your reply below.

And from RR I was not proposing RTC but ORF to src PE.

But since you are not willing to discuss any alternatives further emails are pointless.

Kind regards,
Robert


On Tue, Aug 30, 2022 at 5:01 AM Aijun Wang <[e-mail]<mailto:[e-mail]>> wrote:
Hi, Robert:

Regarding to your “final question”, my answers are the followings (I think you are mentioning again the RTC based approach):

1.     The overflowed VPN routes can only be identified/triggered via the receiving/overwhelmed PE.

2.     The per RT based maximum number of routes on RR can’t represent per VRF limit on the receivers.

Finally, thanks for your comments and suggestions during the adoption call of this draft, the updated draft has already incorporated some of your constructive suggestions, and we are glad to hear more such kind comments later. We have discussed intensely other possible approaches, there is no easier way to achieve such goal.

Best Regards

Aijun Wang
China Telecom

From: Robert Raszuk <[e-mail]<mailto:[e-mail]>>
Sent: Tuesday, August 30, 2022 12:24 AM
To: Igor Malyushkin <[e-mail]<mailto:[e-mail]>>
Cc: Aijun Wang <[e-mail]<mailto:[e-mail]>>; idr <[e-mail]<mailto:[e-mail]>>; Sue Hares <[e-mail]<mailto:[e-mail]>>
Subject: Re: [Idr] Adoption and IPR call for draft-wang-idr-vpn-prefix-orf-03.txt (8/16 to 8/30)


Hi Authors of this document,

I have final question to you on this proposal.

Would you be willing to rewrite the draft such that the required behaviour and protection can be run on Route Reflectors and not on receiving PEs ?

That way one hop ORF will easily reach the src PEs and the fire can be locally extinguished  where it starts.

Further if needed to automate things further, receiving PE could push you max number of routes it is both willing and expecting to accept on a per RT basis via simple extension to existing protocol.

Kind regards,
Robert.


_______________________________________________
Idr mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/idr<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/idr__;!!NEt6yMaO-gk!Ct5LCzVG_sHNF8rYTqJNTBU--Y-TWArmj-VqSYbm2GcU8EIyvuJ6knK_RvffFXjN3_x38MF-qbPdwH48b9Dd$>
--

[http://ss7.vzw.com/is/image/VerizonWireless/vz-logo-email]<https://urldefense.com/v3/__http:/www.verizon.com/__;!!NEt6yMaO-gk!Ct5LCzVG_sHNF8rYTqJNTBU--Y-TWArmj-VqSYbm2GcU8EIyvuJ6knK_RvffFXjN3_x38MF-qbPdwDh_fwGe$>

Gyan Mishra

Network Solutions Architect

Email [e-mail]<mailto:[e-mail]>

M 301 502-1347

_______________________________________________
Idr mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/idr