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

Robert Raszuk <robert@raszuk.net> Fri, 07 August 2020 11:50 UTC

Return-Path: <robert@raszuk.net>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A99E3A0928 for <idr@ietfa.amsl.com>; Fri, 7 Aug 2020 04:50:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.088
X-Spam-Level:
X-Spam-Status: No, score=-2.088 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=raszuk.net
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4mW0C8Ssdv4o for <idr@ietfa.amsl.com>; Fri, 7 Aug 2020 04:50:54 -0700 (PDT)
Received: from mail-ej1-x62a.google.com (mail-ej1-x62a.google.com [IPv6:2a00:1450:4864:20::62a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD6DF3A0913 for <idr@ietf.org>; Fri, 7 Aug 2020 04:50:53 -0700 (PDT)
Received: by mail-ej1-x62a.google.com with SMTP id m19so1758669ejd.8 for <idr@ietf.org>; Fri, 07 Aug 2020 04:50:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=raszuk.net; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=OQH0kAew4FxlKJ3lwB5zJHkn5cxI6O2djlC+RygitwE=; b=EliqNGECjsq5dMvDMmm5y+gmbCyizn8fvn3IqNvoeNksHvgxh5fsx63rfN0NlXj64g Mbl4F2NiE+CLrf4kastHm7B28+B1ZHnNjMFx+ghdkUSUWjP5RV5s3o8MF1LmjLnkUnxM Src0O21CO+ralBZEYovwf6/rGxETztBG/RA6ezI4LuwMwzeArgVwl1L9yNnKRxtypkaJ jlwq/k3yYoHmZPbgOdam3FXGFJn7YpmoVMJuRGVHO9vEQCgo5b17/v8N6vUmLq6xEW2d dQvdW0wMOpO2TlXzaGOPJRTjHxrfW5UEgRydS6PPUY1YIAKblzAFFe/xPPa+oAJDvBgb RYMQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=OQH0kAew4FxlKJ3lwB5zJHkn5cxI6O2djlC+RygitwE=; b=R7zMcAJBnmUCMEf5/y4K5UgA40ZSYfFae284HCEu9WCuEk/LDhoPsdDhih80Ngk4G1 AKLF2tMPWTuaMEEK2pwn0116C1Fh4QZlAsqFJvOlBjym/MV9adqxxUIGV/vdPuzuAueI DcGYwSG9rokFUQA79R3r05nzCaaloeHhftk5sHqJB6B3BOgrPmEGs02BQStLmf4pD8PM TgviHSVadKjwnv6GRtFOLCR/IDZ2Ravy02CDyUaWFxedZdYjlk/EOz9DSlcYbKpEfWU3 qTsgDmijsJ+ntIOGgUt9jwULJaM6IJ7Ylrjnv9pJYYWhGheGpZZvfWWEeh/TshPs7ozm GTxw==
X-Gm-Message-State: AOAM5321VaM+q7G6hEEa/rcxxCp36DrQOsIcn+pRVyJERuQhYlFLFtOT raJM+vdJCCdkkmnmV8X5+OlfH/E0UmZoTn7itVXBhcXu
X-Google-Smtp-Source: ABdhPJyvSLlFLgIEGNZKaqalkGfTvKZ5JIgx0BtWFBBJrUG0dTUaL73YZIK7Nk4SwllOFXwRAl1kvqudn4aqZUnFKMc=
X-Received: by 2002:a17:907:94ca:: with SMTP id dn10mr8876386ejc.110.1596801052248; Fri, 07 Aug 2020 04:50:52 -0700 (PDT)
MIME-Version: 1.0
References: <CABNhwV0upBRPwMmjV86ZOb1HObtugY5TQ5AdTt=tzv6mS=EzJg@mail.gmail.com> <2FFFEB16-DAAC-4E8A-AD24-7880A091F46E@tsinghua.org.cn> <CABNhwV0C9tmPre4KeRe+p5F2Wokjdb46M5UnC0LjRxwXue6ccw@mail.gmail.com> <CAOj+MME=-sC30LSEi9sdMZAwN-iWi-ATR7oT0n_4KeG5-o98ZQ@mail.gmail.com> <00ae01d66c58$de4da280$9ae8e780$@tsinghua.org.cn> <CAOj+MMH47cvi4YZCrgb_tDt6ttaL7M9_TS6fdFAX6GvFxs6LGA@mail.gmail.com> <003501d66c93$a0a3a5c0$e1eaf140$@tsinghua.org.cn> <CAOj+MMHSEB-H-yUrLnahmVAfibTpiEE46v4-zEwp-9emHd2aRw@mail.gmail.com> <004701d66c98$2ceb8670$86c29350$@tsinghua.org.cn>
In-Reply-To: <004701d66c98$2ceb8670$86c29350$@tsinghua.org.cn>
From: Robert Raszuk <robert@raszuk.net>
Date: Fri, 7 Aug 2020 13:50:43 +0200
Message-ID: <CAOj+MME3OpfgYqCFqOoXfNeMkUxhMZq8e0EEfzYOcy3M-9rGpQ@mail.gmail.com>
To: Aijun Wang <wangaijun@tsinghua.org.cn>
Cc: wangw36@chinatelecom.cn, Keyur Patel <keyur@arrcus.com>, idr <idr@ietf.org>, Gyan Mishra <hayabusagsm@gmail.com>
Content-Type: multipart/alternative; boundary="0000000000007f2a1d05ac4837ba"
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/dT826uPMpWw4yppM_2BcpdWiS2w>
Subject: Re: [Idr] [Responses for the comments during the IETF108] New Version Notification for draft-wang-idr-rd-orf-01.txt
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idr/>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 07 Aug 2020 11:50:58 -0000

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 <wangaijun@tsinghua.org.cn>
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:robert@raszuk.net]
> *Sent:* Friday, August 7, 2020 4:39 PM
> *To:* Aijun Wang <wangaijun@tsinghua.org.cn>
> *Cc:* wangw36@chinatelecom.cn; Keyur Patel <keyur@arrcus.com>om>; idr <
> idr@ietf.org>gt;; Gyan Mishra <hayabusagsm@gmail.com>
> *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 <wangaijun@tsinghua.org.cn>
> 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:robert@raszuk.net]
> *Sent:* Friday, August 7, 2020 3:45 PM
> *To:* Aijun Wang <wangaijun@tsinghua.org.cn>
> *Cc:* wangw36@chinatelecom.cn; Keyur Patel <keyur@arrcus.com>om>; idr <
> idr@ietf.org>gt;; Gyan Mishra <hayabusagsm@gmail.com>
> *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 <wangaijun@tsinghua.org.cn>
> 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:robert@raszuk.net]
> *Sent:* Friday, August 7, 2020 7:05 AM
> *To:* Aijun Wang <wangaijun@tsinghua.org.cn>cn>; wangw36@chinatelecom.cn
> *Cc:* Keyur Patel <keyur@arrcus.com>om>; idr <idr@ietf.org>rg>; Gyan Mishra <
> hayabusagsm@gmail.com>
> *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 <hayabusagsm@gmail.com> wrote:
>
>
>
>
>
> On Thu, Aug 6, 2020 at 7:29 AM Aijun Wang <wangaijun@tsinghua.org.cn>
> 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 <hayabusagsm@gmail.com> 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 <robert@raszuk.net> 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 <hayabusagsm@gmail.com> 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 <wangaijun@tsinghua.org.cn>
> wrote:
>
> Hi, Robert:
>
>
>
> Aijun Wang
>
> China Telecom
>
>
>
> On Aug 6, 2020, at 00:14, Robert Raszuk <robert@raszuk.net> 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
> Idr@ietf.org
> 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
>
>
>
>