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