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> Thu, 06 August 2020 09:49 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 430993A10A6 for <idr@ietfa.amsl.com>; Thu, 6 Aug 2020 02:49:28 -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 SsMVe6Pxw-P0 for <idr@ietfa.amsl.com>; Thu, 6 Aug 2020 02:49:26 -0700 (PDT)
Received: from mail-ed1-x531.google.com (mail-ed1-x531.google.com [IPv6:2a00:1450:4864:20::531]) (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 EAFBE3A1002 for <idr@ietf.org>; Thu, 6 Aug 2020 02:49:25 -0700 (PDT)
Received: by mail-ed1-x531.google.com with SMTP id q4so31466642edv.13 for <idr@ietf.org>; Thu, 06 Aug 2020 02:49:25 -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=nN/EhWcRqsvqb3f8r5Ozh/1aTIFeMyt8vOzNDb2+XHo=; b=aIIePXZ63UFc+ZQyaS3RHzQAfeu5cwoM+8cYXkZkEeol1tajhr4RjkLujI0flYSIu6 28LcoyiX/OcunMnl7Ds++fT30gAsBkSEghs3nYd6FPAqgIF2GF3CHGzCO5oSikd/qVaD fKr4l8tXww78NMA7+TQgmEVr0x4yhi1aUcLeEzR3qNxnh6ADXuFKjY1NIzvhBVz6Ff+N 85PTwBhW3AZkMcAfHyYSdf10D+J9zXiPdgnwdRROb1BtTFWFPQL4VgBnQhZfHqNbPW7/ I4qUvEDhhweZygxUZOiMRwpBdy/WXJaslOM6/VBnWfQj8a8OWVlkqA8CMZwYIdLD5vu6 lPFg==
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=nN/EhWcRqsvqb3f8r5Ozh/1aTIFeMyt8vOzNDb2+XHo=; b=AB30yW8b7eP32OaAuUGHcBgCp4R/QChZk58w9GT1a9NWWQTsjQaC0XDm+hTYJzvFHV wIORKs9Hfttgyl/OTOfpR4qeHlbUhffggeaFXrsaIdq+zLLnTRMgZ8aWj47873bfKoAs SDZMj9vdu+s4OPbMd+08berJyr98Jr18QuH2A2NDfAPtorAwszQIkUWewmYtaJUEBbo0 xFioZ3sGtZ+vRNrUsuAKI6mikQhCEK4iH8ZefRfNGs2lXGd5Wwy2qClO5SezsW8dlN+J q3WgUOZ9bTgNqH1EtsMvmMzzvmVY99pq7FXm668GGkCtioUyr9P1Yp4CbQ06NS0BOTZy E49g==
X-Gm-Message-State: AOAM533+B4IQ73JI1+huuxz3oSHWs3VJ5xKXMNrd6VNODcveCCIil23U R7tbnAntJTgxxY+emcPdQwUWHyqULrIFgboYvqVILg==
X-Google-Smtp-Source: ABdhPJzA+oTFD3oBOTiWC+rTtZFPDIzsZQ079HYlZC66glwmSSkIOmLzfOPB59CmW2AnuC1thyM1JGirysAriX0BApU=
X-Received: by 2002:a05:6402:2042:: with SMTP id bc2mr3302386edb.109.1596707364289; Thu, 06 Aug 2020 02:49:24 -0700 (PDT)
MIME-Version: 1.0
References: <CAOj+MMHzritvnTE=wbojZJz52Ww38CPz32oY=cDEM9zcPUPgfQ@mail.gmail.com> <D2259017-50C8-4481-AC3B-BA7FB7D4DA60@tsinghua.org.cn> <CABNhwV3KTV_s59TirpBfH463HhuSQCw8_xf7o+W+NdHgc1HftQ@mail.gmail.com>
In-Reply-To: <CABNhwV3KTV_s59TirpBfH463HhuSQCw8_xf7o+W+NdHgc1HftQ@mail.gmail.com>
From: Robert Raszuk <robert@raszuk.net>
Date: Thu, 6 Aug 2020 11:49:13 +0200
Message-ID: <CAOj+MMFFN5RPYh8=0yE2NNt=Ke2vWVi7sHwLGMPZJzB+uQtTYw@mail.gmail.com>
To: Gyan Mishra <hayabusagsm@gmail.com>
Cc: Aijun Wang <wangaijun@tsinghua.org.cn>, Keyur Patel <keyur@arrcus.com>, idr <idr@ietf.org>, wangw36@chinatelecom.cn
Content-Type: multipart/alternative; boundary="00000000000042542505ac326763"
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/oX72VlOBdJwgzux0rRe_qatLYdk>
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 09:49:28 -0000

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.

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.
>
> 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 *Silver Spring, MD
>
>