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

[Gyan Mishra <[e-mail]>]

Hi James

Replies in-line

On Mon, Feb 15, 2021 at 7:35 AM UTTARO, JAMES <[e-mail]> wrote:

> *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 ?*
>
>
>
> *Gyan> a-d are possible.  Any trigger as the ones you mentioned that could
> cause  flooding of routes.   Single or Multiple VRFs being flooded
> simultaneously hitting VPN maximum prefix. Inter-AS B where “retain RT all”
> is specified where all RTs are imported.  *
>
> *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 ?*
>
>
              Gyan> A-D are possible.  Definitely multiple services is a
big one such as VPLS / EVPN Mac route flood. The control plane issues can
impact the data plane forwarding on the weak PE.

>
> *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?*
>
> *Gyan> It’s possible.  The  RD-ORF process is locally significant so the
> offending and weak PE could be the same device.  We can add some verbiage
> to the draft to account for this situation.*
>
> *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]>
> 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]> 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]>
> 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]> 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: 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
> <https://www.google.com/maps/search/13101+Columbia+Pike?entry=gmail&source=g>
> *Silver Spring, MD
>
>
>
-- 

<http://www.verizon.com/>

*Gyan Mishra*

*Network Solutions A**rchitect *



*M 301 502-134713101 Columbia Pike *Silver Spring, MD