Re: [Idr] WG Adoption call for draft-wang-idr-rd-orf-05.txt (2/4/2021 to 2/18/2021)

["UTTARO, JAMES" <[e-mail]>]

Gyan,

              Looking at your first bullet (a). It would be useful to describe the terms below in a manner that in not interpretative.  TBH we seem to be going around in circles as the language being used by the authors of the draft is imprecise. Below find a number of examples of how your language could be understood ( Not an exhaustive list )..

Offending PE – What does this mean? It seems that is the flooding routes which is a result of what?

  1.  Multiple CEs advertising routes simultaneously causing a wave of paths at the PE
  2.  Redistribution from VRF<->VRF.
  3.  Redistribution from GRT-> VRF.
  4.  Offending PE is actually an Option B ASBR or is dual purposed
  5.  Other ?


Weak PE – How do you characterize a weak PE and how do you define overwhelmed?

  1.  Cannot process a given number of routes in time period X leading to dropping of routes
  2.  Delayed processing that may result in an incomplete number of inputs to the BGP Best Path decision.
  3.  L3VPN customers experiencing an incorrect VPN specification for some time period Y ( Timeliness )
  4.  Control Plane Processing impact Forwarding ( This would be surprising )
  5.  Other services that may be instantiated on the “Weak PE” are impacted i.e VPLS
  6.  Other ?

Can a PE be both “offending” and “weak”? I would assume so. I see no mention of this in your text below. How does your approach deal with said PE?

Thanks,
              Jim Uttaro
a) the problem this draft is drafting to solve relating to BGP routes,
The problem we are trying to solve is a scenario where you have an offending PE that is flooding routes and a weak PE that is overwhelmed by a flood of routes.  This is not a normal situation and is an outage situation where the weak PE being overwhelmed by a flood of routes.  Do we all agree to the problem statement?


From: Idr <[e-mail]> On Behalf Of Gyan Mishra
Sent: Friday, February 12, 2021 10:16 PM
To: Aijun Wang <[e-mail]>
Cc: [e-mail]; Susan Hares <[e-mail]>; Robert Raszuk <[e-mail]>
Subject: Re: [Idr] WG Adoption call for draft-wang-idr-rd-orf-05.txt (2/4/2021 to 2/18/2021)


All

From Susan Hares summary of where we are at with the adoption call let’s start with the problem this draft is trying to solve and gaining consensus.  Once we gain consensus we can get back to RD-ORF solution.  See w

a) the problem this draft is drafting to solve relating to BGP routes,
The problem we are trying to solve is a scenario where you have an offending PE that is flooding routes and a weak PE that is overwhelmed by a flood of routes.  This is not a normal situation and is an outage situation where the weak PE being overwhelmed by a flood of routes.  Do we all agree to the problem statement?

Why and why not?

b) the need for additional mechanisms to solve the problem,
Do other methods exist that can solve the problem and if not do we need a new mechanism to solve this?
RTC, Peer maximum prefix, VPN maximum prefix
c) a clear description of the technology to solve the problem.

Do we all agree that in a normal situation we would never filter on RD as that would partition the VPN which is unwanted and what Robert mentioned.  As this is not a normal situation but a unique situation where a weak PE is overwhelmed by a flood of routes.  How best can this be solved?



On Fri, Feb 12, 2021 at 10:32 AM Aijun Wang <[e-mail]<mailto:[e-mail]>> wrote:
Hi, Robert:
Yes, the behavior of the device should be determined. There maybe several factors to be considered for this local behavior, we should describe it more clearly in this section later.
We have discussed the differences between RTC and RD-ORF a lot. As Haibo mentioned, they are not exclusive to each other, and can be used together in some situations. But they are different and can’t replace each other.
Aijun Wang
China Telecom


On Feb 12, 2021, at 23:04, Robert Raszuk <[e-mail]<mailto:[e-mail]>> wrote:

Sorry Aijun,

What you say is just handwaving. There is no room for it in any spec.

When code is written PE must deterministically behave so the RR or any other network element.

Statements "decisions of PE2 to judge" are not acceptable in protocol design.

Just imagine that each PE does what it feels like in a distributed network .... Same for BGP same for IGP etc ....

And all of this is not needed if on ingress between PE1 and HQ1 you apply max prefix of 2 or even 100. It is also not needed if you enable  RTC to send RT:TO_HUB from PE2 to RR.

But I understand - no matter what we say or how much we spend time to explain why this idea is a bad idea you are still going to push this fwd. Oh well ...   If I were you I would spend this time to redefine L3VPN such that customer routes are never needed to be sent to SP core routers.

Thx,
R.


On Fri, Feb 12, 2021 at 3:47 PM Aijun Wang <[e-mail]<mailto:[e-mail]>> wrote:
Hi, Robert:

https://datatracker.ietf.org/doc/html/draft-wang-idr-rd-orf-05#section-5.1.1<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-wang-idr-rd-orf-05*section-5.1.1__;Iw!!BhdT!wFDvJUfijC2hIGiH79yASFcLdf_N2ZgRzGAyZFBQ9qPt6NEnHHW4evpmkDA$> has described such situations, which will require the additional local decisions of PE2 to judge whether to send the RD-ORF message out.
In your example, if only the HUB VRF exceed but the resources of PE2 is not exhausted, then the PE2 will not send the RD-ORF message. It may just discard the excessive 100000/32 routes.
If the resources of PE2 is nearly exhausted, it must send the RD-ORF message out. Or else not only the Spoke VRF, but also other VPNs on this device can’t be used.

Regarding to RR, it is the same principle: if RR can cope with such flooding, it need not send out RD-ORF to PE1. If RR can’t cope with, it must send out the RD-ORF message, or else not only the VPN that import RD X1 routes can’t work, but also other VPNs that don’t import RD x1 routes.

RD-ORF mechanism just keep the influences as small as possible.

Wish the above explanation can refresh your review of this draft.

We are also hopeful to invite you join us to make RD-ORF mechanism more robust and meet the critical challenges.
Aijun Wang
China Telecom


On Feb 12, 2021, at 19:30, Robert Raszuk <[e-mail]<mailto:[e-mail]>> wrote:

Aijun & Gyan,

Let me try one more (hopefully last time) to explain to both of you - and for that matter to anyone how supported this adoption.

Let's consider very typical Hub and Spoke scenario as illustrated below:

<image.png>


HQ1 is advertising two routes:

- one default with RDX1 with RT TO_SPOKE
- one or more specifics with RDX1 to the other HUBs

Now imagine HQ1 bought a new BGP "Optimizer" and suddenly is starting to advertise 100000 /32 routes just to the other HUB with RT: TO_HUB.

<image.png>



So PE2 detects this as VRF with RDX2 on it got overwhelmed during import with RT TO_HUB and starts pushing RDX1 (original RD) to RR to stop getting those routes.

Well all great except now you are throwing baby with the water as all spokes attached to PE2 which just import default route to HUB HQ1 also can no longer reach their hub site as their default route will be removed. Therefor they will have nothing to import with RT:TO_SPOKE

Further if RR "independently" decided ... oh let's push this ORF to PE1 then all of the spokes attached to perhaps even much more powerful PE3 can also no longer reach their headquarters.

- - -

Summary:

The above clearly illustrates why the proposed solution to use RD for filtering is in fact harmful.

See when you design new protocol extensions the difficulty is to not break any existing protocols and deployments.

Hope this puts this long thread to rest now.


Thx,
Robert

--

[Image removed by sender.]<https://urldefense.com/v3/__http:/www.verizon.com/__;!!BhdT!wFDvJUfijC2hIGiH79yASFcLdf_N2ZgRzGAyZFBQ9qPt6NEnHHW4U1-UgK8$>

Gyan Mishra

Network Solutions Architect

M 301 502-1347
13101 Columbia Pike
Silver Spring, MD