Re: [Idr] [Responses for the comments during the IETF108] New Version Notification for draft-wang-idr-rd-orf-01.txt
Gyan Mishra <hayabusagsm@gmail.com> Thu, 06 August 2020 22:50 UTC
Return-Path: <hayabusagsm@gmail.com>
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 C21403A0AD7
for <idr@ietfa.amsl.com>; Thu, 6 Aug 2020 15:50:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.087
X-Spam-Level:
X-Spam-Status: No, score=-2.087 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, FREEMAIL_FROM=0.001,
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=gmail.com
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 5Zq00DIXubNX for <idr@ietfa.amsl.com>;
Thu, 6 Aug 2020 15:50:03 -0700 (PDT)
Received: from mail-ua1-x934.google.com (mail-ua1-x934.google.com
[IPv6:2607:f8b0:4864:20::934])
(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 108A23A0ADD
for <idr@ietf.org>; Thu, 6 Aug 2020 15:50:03 -0700 (PDT)
Received: by mail-ua1-x934.google.com with SMTP id p27so10922549uaa.12
for <idr@ietf.org>; Thu, 06 Aug 2020 15:50:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
h=mime-version:references:in-reply-to:from:date:message-id:subject:to
:cc; bh=vCLCOsWCXsxrNfmSuMJoWYLWCjA48H5Hbk0vdhG5xhQ=;
b=C+tsmLP2KH8G/PIB0fgWOfiwTMCQogP3MRRQ9Nh9IuPPjNof+42w+9kSUVR8wwh0bl
dUs+mFCWl0RA5O0V7SRUuPiHgNrxvwuA15CL5dhOaI5ekPXq7TMwsIrSvPlt4FTjWavi
KMnpEBCBKW8lXPAwYJ3HHC8cYxhRrLSxTJnDebQ/3Z7m0p3iYbHwojkNloecSho+Ku16
V7M6EmURu/x66BseooFfkCQWbqSHUkWdcY++vXzHhE/5JUxG7kTy/ZuGkrumAt7aXjN8
blZcDNsafUeGtECQcA/HO2kORIxxnhB6M8D6Gu5EuYLpMRSjJaShXh4RUWdDgEfAsOSC
em5Q==
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=vCLCOsWCXsxrNfmSuMJoWYLWCjA48H5Hbk0vdhG5xhQ=;
b=GcGifYHysCmdktmb+v3dt7cr8NbNCAezrnorBZlt9X1LBIVV2MmZAXkTVaHOOZ3+iY
NTvp8al6uryuFDeiSI8Jgao3LDTCacev6DUqjl8qvi7Hw7fwLW/PpA2PyFT33iMaZhP6
T3SBLO8H2N5gQVPZBIectGjqhC31dAfQBx3b79Xsv3652RzRH3CeMUPpE9m0+E2p2aGn
UNLlcKF9eUeZVMvPEmpD8++4wpNYs5kbYV4dbZuz6GTfEmHD4+j4puKCnI40oGjKY7Cl
5IsC99gnnryLfzx8tS4IfobUsLyQGCbpFhQRXA6Zs1xXRKvaGH+fFGKfAioF+aAl9Hs9
UYkA==
X-Gm-Message-State: AOAM5323plRmz2SyQVh/9C8dsdtQBr+8z7K5CNErq8YT+k+P1L28EqCt
si82YIZaBy1N8JvxSio8EBUpSdTcZSj2CmaXxmMzZ0qPet8=
X-Google-Smtp-Source: ABdhPJyBnl6OG/dKBG03Blrb58dTfl0bcOXAIlqa0CjTJuPScKf5WD/aJtMhXV+at1mAyrISPndmteOV+FPhcOPaZ9E=
X-Received: by 2002:ab0:5eaa:: with SMTP id y42mr8300136uag.118.1596754202066;
Thu, 06 Aug 2020 15:50:02 -0700 (PDT)
MIME-Version: 1.0
References: <CABNhwV0upBRPwMmjV86ZOb1HObtugY5TQ5AdTt=tzv6mS=EzJg@mail.gmail.com>
<2FFFEB16-DAAC-4E8A-AD24-7880A091F46E@tsinghua.org.cn>
In-Reply-To: <2FFFEB16-DAAC-4E8A-AD24-7880A091F46E@tsinghua.org.cn>
From: Gyan Mishra <hayabusagsm@gmail.com>
Date: Thu, 6 Aug 2020 18:49:51 -0400
Message-ID: <CABNhwV0C9tmPre4KeRe+p5F2Wokjdb46M5UnC0LjRxwXue6ccw@mail.gmail.com>
To: Aijun Wang <wangaijun@tsinghua.org.cn>
Cc: Keyur Patel <keyur@arrcus.com>, Robert Raszuk <robert@raszuk.net>,
idr <idr@ietf.org>, wangw36@chinatelecom.cn
Content-Type: multipart/alternative; boundary="0000000000000202cd05ac3d4f54"
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/3zJTraPMMFcQuH8TJUJ8uD4PePg>
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: Thu, 06 Aug 2020 22:50:06 -0000
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 A**rchitect * >>> >>> >>> >>> *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 A**rchitect * > > > > *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 A**rchitect * *M 301 502-134713101 Columbia Pike *Silver Spring, MD
- [Idr] New Version Notification for draft-wang-idr… wangw36@chinatelecom.cn
- Re: [Idr] [Responses for the comments during the … Aijun Wang
- Re: [Idr] [Responses for the comments during the … Robert Raszuk
- Re: [Idr] [Responses for the comments during the … Aijun Wang
- Re: [Idr] [Responses for the comments during the … Rajiv Asati (rajiva)
- Re: [Idr] [Responses for the comments during the … Aijun Wang
- Re: [Idr] [Responses for the comments during the … Robert Raszuk
- Re: [Idr] [Responses for the comments during the … Robert Raszuk
- Re: [Idr] [Responses for the comments during the … Aijun Wang
- Re: [Idr] [Responses for the comments during the … Robert Raszuk
- Re: [Idr] [Responses for the comments during the … Aijun Wang
- Re: [Idr] [Responses for the comments during the … Aijun Wang
- Re: [Idr] [Responses for the comments during the … Gyan Mishra
- Re: [Idr] [Responses for the comments during the … Robert Raszuk
- Re: [Idr] [Responses for the comments during the … Gyan Mishra
- Re: [Idr] [Responses for the comments during the … Aijun Wang
- Re: [Idr] [Responses for the comments during the … UTTARO, JAMES
- Re: [Idr] [Responses for the comments during the … Gyan Mishra
- Re: [Idr] [Responses for the comments during the … Robert Raszuk
- Re: [Idr] [Responses for the comments during the … Aijun Wang
- Re: [Idr] [Responses for the comments during the … Aijun Wang
- Re: [Idr] [Responses for the comments during the … Robert Raszuk
- Re: [Idr] [Responses for the comments during the … Aijun Wang
- Re: [Idr] [Responses for the comments during the … Robert Raszuk
- Re: [Idr] [Responses for the comments during the … Aijun Wang
- Re: [Idr] [Responses for the comments during the … Robert Raszuk
- Re: [Idr] [Responses for the comments during the … John E Drake
- Re: [Idr] [Responses for the comments during the … Gyan Mishra
- Re: [Idr] [Responses for the comments during the … UTTARO, JAMES
- Re: [Idr] [Responses for the comments during the … Gyan Mishra
- Re: [Idr] [Responses for the comments during the … Aijun Wang
- Re: [Idr] [Responses for the comments during the … Robert Raszuk
- Re: [Idr] [Responses for the comments during the … Aijun Wang
- Re: [Idr] [Responses for the comments during the … Gert Doering
- Re: [Idr] [Responses for the comments during the … Aijun Wang
- Re: [Idr] [Responses for the comments during the … Gert Doering
- Re: [Idr] [Responses for the comments during the … Gyan Mishra
- Re: [Idr] [Responses for the comments during the … Aijun Wang
- Re: [Idr] [Responses for the comments during the … Gyan Mishra
- Re: [Idr] [Responses for the comments during the … Aijun Wang
- Re: [Idr] [Responses for the comments during the … Robert Raszuk
- Re: [Idr] [Responses for the comments during the … Gyan Mishra
- Re: [Idr] [Responses for the comments during the … Aijun Wang
- Re: [Idr] [Responses for the comments during the … Gyan Mishra