Re: [Idr] [Responses for the comments during the IETF108] New Version Notification for draft-wang-idr-rd-orf-01.txt

[Robert Raszuk <[e-mail]>]

ORF messages are p2p. They are not transitive.

There is no such thing like smuggling messages around even if they are
re-originated on RRs.

Thx,
R.

On Fri, Aug 7, 2020 at 10:53 AM Aijun Wang <[e-mail]>
wrote:

> Hi, Robert:
>
>
>
> The updated encoding of RD-ORF message includes the originator of routes
> (source PE).
>
> Once the “source PE” receives such message, it can log this event, or
> notify the customer further via traditional “BGP Prefix Limit” mechanism.
>
> If necessary, we can add such consideration later in the draft.
>
>
>
> Best Regards
>
>
>
> Aijun Wang
>
> China Telecom
>
>
>
> *From:* Robert Raszuk [mailto:[e-mail]]
> *Sent:* Friday, August 7, 2020 4:39 PM
> *To:* Aijun Wang <[e-mail]>
> *Cc:* [e-mail]; Keyur Patel <[e-mail]>om>; idr <
> [e-mail]>gt;; Gyan Mishra <[e-mail]>
> *Subject:* Re: [Idr] [Responses for the comments during the IETF108] New
> Version Notification for draft-wang-idr-rd-orf-01.txt
>
>
>
> Hi Aijun,
>
>
>
> The reason for RTC is to propagate information which routes are needed -
> between PE & RR or between domains. The goal is to even further scale the
> VPN route distribution.
>
>
>
> RTC is not defined to signal which routes should be dropped due to low
> resources. Very fundamental difference.
>
>
>
> Prefix ORF in general is very rarely used. Reason being that it is
> normally only applicable for eBGP sessions and no peer wants to honor
> someone else's filters. For IBGP prefix ORF IMO should be forbidden by the
> spec.
>
>
>
> Knob on RRs can be very simple: drop or stop propagating to any PE VPNv4
> or v6 routes if number of routes with given RD exceeds say 1 million or X.
>
>
>
> And such 1 million or 1K or xyz can be based on expected number of VPN
> routes from any L3VPN customer in his VPN. I do hope when customers sign
> the agreement you ask that question.
>
>
>
> > Back pressure to the source can eliminate the root of overflowed VPN
> routes.
>
>
>
> The problem is that you are not defining back pressure to the source. You
> are defining back pressure to your own devices. If you were to define a
> message which would tell the originator of the routes (customer CE) to stop
> or which would bring down the session to the CE which is polluting the VPN
> space I would perhaps carefully review it and maybe even support it.
>
>
>
> But you are proposing a tool which just breaks VPNs without signalling it
> to customers. That is not acceptable - very sorry.
>
>
>
> Many thx,
> R.
>
>
>
> On Fri, Aug 7, 2020 at 10:20 AM Aijun Wang <[e-mail]>
> wrote:
>
> Hi, Robert:
>
> According to your logic, what the reason for the ORF、RTC mechanism exist?
> The extra info that they filter can all be locally dropped.
>
> Regarding the knob on RR, how RR know which routes it should drop by
> itself?
>
>
>
> Back pressure to the source can eliminate the root of overflowed VPN
> routes.
>
>
>
>
>
> Best Regards
>
>
>
> Aijun Wang
>
> China Telecom
>
>
>
> *From:* Robert Raszuk [mailto:[e-mail]]
> *Sent:* Friday, August 7, 2020 3:45 PM
> *To:* Aijun Wang <[e-mail]>
> *Cc:* [e-mail]; Keyur Patel <[e-mail]>om>; idr <
> [e-mail]>gt;; Gyan Mishra <[e-mail]>
> *Subject:* Re: [Idr] [Responses for the comments during the IETF108] New
> Version Notification for draft-wang-idr-rd-orf-01.txt
>
>
>
>
>
>  > Using RD-ORF can control the VPN routes limits within each VRF.
>
>
>
> If you really want to create such inconsistency within any VPN you can ask
> your vendor for a knob to locally drop on inbound received routes with
> specific RD. That also can be fully automated by setting the auto trigger
> threshold on a per VRF.
>
>
>
> The inbound drop is a very low cost operation so will be of no CPU issue.
>
>
>
> You will then be able to use such *local* knob as an additional safety
> fuse.
>
>
>
> There is however no need to propagate this anywhere nor to pass it from RR
> to upstream PEs. Such knob can exist on RRs as well if you even further
> want to completely break your user's happiness.
>
>
>
> I see no need and I stay by original position that this proposed protocol
> extension is a bad one and I do not support it to proceed any further nor
> to be adopted as an IDR WG document.
>
>
>
> Kind regards,
>
> Robert
>
>
>
>
>
> On Fri, Aug 7, 2020 at 3:20 AM Aijun Wang <[e-mail]>
> wrote:
>
> Hi, Robert and Gyan:
>
>
>
> The problem is similar as that for “BGP Maximum-Prefix” and should be
> control plane related issue.
>
> No matter what’s the capabilities of the router, there is always the roof
> for its performance.
>
> And in large network deployment, there still exist the possibility that
> one or some PEs are misconfigured/attacked etc.
>
> We should not only control the PE behavior at network edge(for example,
> using BGP Maximum-Prefix feature), but also need to consider the risk
> within the network.
>
>
>
> RTC is one kind of method to control the routes propagation within the
> network, but it is not enough.
>
> RTC can filter the VRF routes it doesn’t want to, but it can’t suppress
> the VPN routes it wants.  Using RD-ORF can control the VPN routes limits
> within each VRF.
>
>
>
>
>
> Best Regards
>
>
>
> Aijun Wang
>
> China Telecom
>
>
>
> *From:* Robert Raszuk [mailto:[e-mail]]
> *Sent:* Friday, August 7, 2020 7:05 AM
> *To:* Aijun Wang <[e-mail]>cn>; [e-mail]
> *Cc:* Keyur Patel <[e-mail]>om>; idr <[e-mail]>rg>; Gyan Mishra <
> [e-mail]>
> *Subject:* Re: [Idr] [Responses for the comments during the IETF108] New
> Version Notification for draft-wang-idr-rd-orf-01.txt
>
>
>
> Folks,
>
>
>
> I think we need to step back and first understand what is the problem.
>
>
>
> Statements "overload of the PE" .. "overwhelmed PE" etc ... are really not
> helpful. Neither are sufficient to justify this work based on the statement
> "we need more then one solution" etc ....
>
>
>
> What exactly is being considered a problem here ?
>
>
>
> 1. Running out of RAM in control plane ?
>
> 2. Running out of CPU in control plane ?
>
> 3. Not being able to import VPNv4 routes to a VRFs due to not enough
> control plane memory ?
>
> 4. Not being able to import VPNv4 routes to a VRFs due to not enough data
> plane memory ?
>
>
>
> And please do not say "all of the above" as it will also not much
> productive.
>
>
>
> While stating the above please indicate which vendors have been tested and
> do not meet feature wise sufficient protection.
>
>
>
> Many thx,
>
> R.
>
>
>
>
>
>
>
> On Fri, Aug 7, 2020 at 12:50 AM Gyan Mishra <[e-mail]> wrote:
>
>
>
>
>
> On Thu, Aug 6, 2020 at 7:29 AM Aijun Wang <[e-mail]>
> wrote:
>
> Hi, Gyan and Robert:
>
>
>
> Maximum Prefix Limit is one method to control the routes between PE and
> CE, but we should not depend only on it.
>
>
>
>    You can use maximum prefix along with an inbound filter prefix list or
> as path or community match for whatever style routing control desired.
>
>
>
> From a PE standpoint you have not explained why using the per VRF prefix
> limit to limit the size of the per VRF rib.  Please explain why that does
> not solve the problem.
>
>
>
> RD-ORF can limit the influence scope of misbehavior PE as small as
> possible.
>
>
>
>     I don’t think you want to use RD-ORF as that would drop all routes
> from a PE and RTC does the job well only advertising RTs imported on the
> PE.  I think it would be rare if ever that anyone would ever filter on RD.
>
>
>
> RT-ORF can suppress the routes from unwanted VRFs, but can’t suppress the
> overflow routes in VRF that it is interested.
>
>
>
>
>
>
>
> More details responses are inline below.
>
> Aijun Wang
>
> China Telecom
>
>
>
> On Aug 6, 2020, at 18:02, Gyan Mishra <[e-mail]> wrote:
>
> 
>
>
>
> Hi Robert
>
>
>
> I am in agreement as you stated that most service providers from my
> experience use the per VRF prefix limit to protect resources.  Problem
> solved as you said 20+ years ago.
>
>
>
> That is a general rule of thumb for any service providers to perform due
> diligence on their PE memory resource carving per VRF and set it
> appropriately based on platform and total number of VRFs to account for.
>
>
>
> Problem solved on the SP end.
>
>
>
> On the customer end, they can also use the maximum prefix peer command as
> well to prevent flood of routes in case of unwanted advertisements from
> unintentional VRF leaking by providers.
>
>
>
> Kind Regards
>
>
>
> Gyan
>
>
>
>
>
> On Thu, Aug 6, 2020 at 5:49 AM Robert Raszuk <[e-mail]> wrote:
>
> Hi Gyan,
>
>
>
> Thank you for your comments - all very valid observations.
>
>
>
> Just to perhaps clarify one thing ... Problem authors are attempting to
> address - the way I understand it - is that given resource may be suffering
> from actually legitimate VPN routes hence to use RTC indeed a lot of
> additional RTs would have to be applied.
>
>
>
> But I do not understand why authors fail to recognize that solution for
> their problem has been invented and implemented over 20 years ago already.
> The solution is to control on a per *ingress* VRF basis number of VPN
> routes customer is authorized to inject into his VPN with eBGP PE-CE prefix
> limit.
>
>
>
> [WAJ] we have mentioned prefix limit solutions in the draft and analysis
> its applicability scope.
>
>
>
> Most SPs offering L3VPNs use prefix limit successfully to protect their
> shared resources for vast majority of customers and deployments. For VPN
> customers with unpredictable amount of routing CSC model should be used
> instead.
>
>
>
> By all means filtering and dropping accepted into SP network VPN route
> should not take place.
>
>
>
> Thx,
> R.
>
>
>
>
>
>
>
>
>
>
>
> On Thu, Aug 6, 2020 at 11:41 AM Gyan Mishra <[e-mail]> wrote:
>
> Hi Aijun
>
>
>
> I agree with Robert that you cannot filter by RD or you would drop all the
> routes and filtering must be done by RT.  Also the issue with RT ORF filter
> is as Robert mentioned that you may have the same prefix with two different
> RTs which is common unique by RD and so the ORF would drop the prefixes.
>
>
>
> [WAJ] Such situation can only happen at the extraVPN scenarios which
> should be designed carefully——one must keep the prefixes in these VRFs
> not overlap. But if the prefixes in these VRFs are not overlap, why do we
> need to separate them in different VRFs?
>
> In conclusion, this is just corner case and should be avoided in design.
>
>
>
>
>
>
>
> I am not sure I understand what problem you are trying to solve that is
> not already solved by RTC membership so that only RTs imported by the PE
> are what is advertised by the RR.  That is most effective way of cutting
> down the RT flooding that occurs in the RR to PE advertisement.  RT
> filtering is enabled by Default on all PEs and only if the RT is imported
> on the PE are the RTs accepted into the vpn rib. That works pretty well in
> cutting down RT advertisements by the RR.
>
>
>
> As Robert mentioned each VRF has a maximum prefix which is defined on the
> PE RIBs per VRF and in general on most current or even hardware within the
> last 10 years is a minimum 1M prefixes per VRF is pretty standard with most
> vendors and platforms.  The vpn rib limit is much much higher on the higher
> end platforms.
>
>
>
> You draft talks about inter-as issues solved with RT-ORF.  So when PE-PE
> inter-as option B by default all RTs are dropped due to default RT
> filtering and only RTs that are accepted are those RTS that are explicitly
> being imported on the PE ASBR.  There is an option for retain route-target
> all that disabled the default RT filtering so that all VPN routes can be
> accepted on the inter-as option B link.  However a RT filter can still be
> applied to the retian-route-target all so that only pertinent RTs are
> accepted inter domain.  That seems to work pretty well.
>
>
>
> As far as inter-as option C, the PE-PE ASBRs do not maintain the VPN RIB.
> BGP LU is enabled on the inter-as link for end to end LSP by importing the
> loopback between ASs for the end to end LSPto be built.   The RRs between
> the SPs have eBGP VPN IPv4 VPN IPV6 peer with next hop unchanged so the
> data plane gets built between the PEs.  The RR by default does not have RT
> filtering enabled by default as does the PE, so is able to reflect all the
> vpn routes learned to all PEs within each AS.  In the inter-as scenario as
> well RTC works very well with the RT membership to cut down on RR to PE vpn
> route advertisements.
>
>
>
> Kind Regards
>
>
>
> Gyan
>
>
>
> On Wed, Aug 5, 2020 at 12:49 PM Aijun Wang <[e-mail]>
> wrote:
>
> Hi, Robert:
>
>
>
> Aijun Wang
>
> China Telecom
>
>
>
> On Aug 6, 2020, at 00:14, Robert Raszuk <[e-mail]> wrote:
>
> 
>
>
>
> [WAJ] The VPN routes imported in these VRFs can’t use the same RD, or
> else, the VPN prefixes in different VRFs will collision on RR.
>
>
>
> Nothing will "collide" on RRs.
>
>
>
> NLRI = RD+Prefix  not just the RD.
>
>
>
> [WAJ] The prefix part can be overlap in different VRF. If the RD is same,
> RD+Prefix will also be overlap.
>
> We must make sure different VRF use different RD to make the VPN prefixes
> unique within the domain.
>
>
>
> So you may have completely different prefixes sourced by the same VRF
> going to completely different VRFs on same or different PEs.
>
>
>
>
>
> [WAJ] This situation is for extraVPN communication, and should be designed
> carefully to avoid the address collision..
>
> If the address space in different VRF need to be considered in such
> manner, putting them in one VRF may be more straightforward.
>
>
>
> Kind regards,
> R.
>
>
>
>
>
>
>
>
>
>
>
>
>
> _______________________________________________
> Idr mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/idr
>
> --
>
> <http://www.verizon.com/>
>
> *Gyan Mishra*
>
> *Network Solutions Architect *
>
>
>
> *M 301 502-134713101 Columbia Pike
> <https://www.google.com/maps/search/13101+Columbia+Pike%C2%A0+Silver+Spring,+MD?entry=gmail&source=g>*Silver
> Spring, MD
> <https://www.google.com/maps/search/13101+Columbia+Pike%C2%A0+Silver+Spring,+MD?entry=gmail&source=g>
>
>
>
> --
>
> <http://www.verizon.com/>
>
> *Gyan Mishra*
>
> *Network Solutions Architect *
>
>
>
> *M 301 502-134713101 Columbia Pike
> <https://www.google.com/maps/search/13101+Columbia+Pike+Silver+Spring,+MD?entry=gmail&source=g> *Silver
> Spring, MD
> <https://www.google.com/maps/search/13101+Columbia+Pike+Silver+Spring,+MD?entry=gmail&source=g>
>
>
>
> --
>
> <http://www.verizon.com/>
>
> *Gyan Mishra*
>
> *Network Solutions Architect *
>
>
>
> *M 301 502-134713101 Columbia Pike *Silver Spring, MD
>
>
>
>