Re: [Idr] https://tools.ietf.org/html/draft-wang-idr-rd-orf-00

Jeff Tantsura <jefftant.ietf@gmail.com> Fri, 17 July 2020 00:20 UTC

Return-Path: <jefftant.ietf@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 BB68F3A0E4F for <idr@ietfa.amsl.com>; Thu, 16 Jul 2020 17:20:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.096
X-Spam-Level:
X-Spam-Status: No, score=-2.096 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, MIME_QP_LONG_LINE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, 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 ShznnMmvQlsZ for <idr@ietfa.amsl.com>; Thu, 16 Jul 2020 17:20:32 -0700 (PDT)
Received: from mail-pl1-x62d.google.com (mail-pl1-x62d.google.com [IPv6:2607:f8b0:4864:20::62d]) (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 63BAA3A0E4C for <idr@ietf.org>; Thu, 16 Jul 2020 17:20:32 -0700 (PDT)
Received: by mail-pl1-x62d.google.com with SMTP id o1so4656078plk.1 for <idr@ietf.org>; Thu, 16 Jul 2020 17:20:32 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=content-transfer-encoding:from:mime-version:subject:date:message-id :references:cc:in-reply-to:to; bh=CwdjaCBJgDnk+VDYi+mg3pmrnyDE83nJvovnq1Fhogc=; b=iULMqTxF56MvWFyGCzt4wP+BeyQXIA3CAv2VczUkbXuEsZ7o+pTZ8tu/Ga9wcR+vhd FuVB2ULTBHGaoc2XW80uIQSHEwhp6t1UugzArbMzU5S/x4Lmz26aaOXvNZOfdOlvYV3O UFaniZiu7JaLIXmWDYF1/sD4nUZ4nJZadgliqahas0SjiG0OQW01/zbPP/OwrM3VOCoz 5ByYl3oJve4+ZvzDdv0ZIZbrPW4rAKbiEYEx5OzqqdCwRklAs4mOfeOFavaMnicYvrFZ dW4OTy6W7u331xjaTwCKRrczAyYrNxKpr2Nog6jgFD3WfUIwNEOVN1e9jILL7joFSo0T x2pA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:content-transfer-encoding:from:mime-version :subject:date:message-id:references:cc:in-reply-to:to; bh=CwdjaCBJgDnk+VDYi+mg3pmrnyDE83nJvovnq1Fhogc=; b=ou9LamlzVqTx0dA9Ma7lWnT10tTpjKPDbmCGF4giu9NDgAWIOhjMlWme90IdwuHNyt GVCDXtvH51T3mSQGT6Qat4QtrtWfgmm+CGRTUEPAkELdcr3KHCkHneUiy41sNLxX5l9V 16rZGMqbfPd3XzBNAi32D5mNwlcAzPuamfmLlBEYdssjkQ2H9EcY7qG2owQD97ONihGm eS3JQF89TbJS5ntPoNiHmHmqU/bRnPo+jHYyggxHRQiIfCze8L/ta410aYlULg9eGmQp klx5Nhke2K8x5rQk2zmjypytemAJ8TS78I1iVCkMrLEjXJ77Eh+VQy7gU5tib2n6ADq7 wuzQ==
X-Gm-Message-State: AOAM5305bZeCOat77rMo36HNSbJJGZ2oDcwtM4A9fVod2Xe2Oy6w92p+ Z0G8vFUfb7WoBUzxNKg0hww=
X-Google-Smtp-Source: ABdhPJxdK/i4CPalUBfEyFT10atVkiCMutjBzegaT9tLUr98WYrrMNVPyeSGWDh2+iCwKU2MfjTEFA==
X-Received: by 2002:a17:90a:e60b:: with SMTP id j11mr7509889pjy.189.1594945231790; Thu, 16 Jul 2020 17:20:31 -0700 (PDT)
Received: from [192.168.1.6] (c-73-63-232-212.hsd1.ca.comcast.net. [73.63.232.212]) by smtp.gmail.com with ESMTPSA id 9sm5773138pfx.131.2020.07.16.17.20.30 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 16 Jul 2020 17:20:30 -0700 (PDT)
Content-Type: multipart/alternative; boundary=Apple-Mail-A66D74A0-CD47-4893-BAD7-1CAA8F01F2B3
Content-Transfer-Encoding: 7bit
From: Jeff Tantsura <jefftant.ietf@gmail.com>
Mime-Version: 1.0 (1.0)
Date: Thu, 16 Jul 2020 17:20:29 -0700
Message-Id: <3DF89604-E435-49F2-AC27-8211231200B0@gmail.com>
References: <BYAPR11MB3207B46C0198DD2836778EF0C07F0@BYAPR11MB3207.namprd11.prod.outlook.com>
Cc: Robert Raszuk <robert@raszuk.net>, Aijun Wang <wangaj3@chinatelecom.cn>, "idr@ietf. org" <idr@ietf.org>
In-Reply-To: <BYAPR11MB3207B46C0198DD2836778EF0C07F0@BYAPR11MB3207.namprd11.prod.outlook.com>
To: "Jakob Heitz (jheitz)" <jheitz=40cisco.com@dmarc.ietf.org>
X-Mailer: iPhone Mail (17F80)
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/Xwga06cTXih9YttKwBU9is012-s>
Subject: Re: [Idr] https://tools.ietf.org/html/draft-wang-idr-rd-orf-00
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, 17 Jul 2020 00:20:35 -0000

+1

Regards,
Jeff

> On Jul 16, 2020, at 15:58, Jakob Heitz (jheitz) <jheitz=40cisco.com@dmarc.ietf.org> wrote:
> 
> 
> Can't we already do an RD ORF anyway?
> Using an address-prefix ORF in the VPN address family with prefix length 64.
>  
> Regards,
> Jakob.
>  
> From: Robert Raszuk <robert@raszuk.net> 
> Sent: Thursday, July 16, 2020 2:58 PM
> To: Jakob Heitz (jheitz) <jheitz@cisco.com>
> Cc: Aijun Wang <wangaj3@chinatelecom.cn>; idr@ietf. org <idr@ietf.org>
> Subject: Re: [Idr] https://tools.ietf.org/html/draft-wang-idr-rd-orf-00
>  
>  
> > but only one of them is sending too many routes.  
>  
> Well PEs do not produce routes all by themselves :) 
>  
> They receive it from CEs. /* Likewise ASBRs option B receive it from other ASBRs. */
>  
> So one's network should be able to handle an agreed number of routes as defined in VPN service. For anything above that in order to protect PE control and data planes prefix limit is the tool to apply towards your local peers which could result with src session down till NOC diagnoses the issue. 
>  
> Thx,
> R.
>  
>  
>  
>  
> On Thu, Jul 16, 2020 at 11:22 PM Jakob Heitz (jheitz) <jheitz@cisco.com> wrote:
> I can see how you might want to do max-prefix filtering by RD.
> Suppose there are many PEs in an AS that all have VRFs for the same VPN,
> but only one of them is sending too many routes.
> In that case, you can't filter just that one VRF by RT.
> You need RD.
> Sure, you will end up with partial routes and a bit of a mess, as Robert points out, but that's the nature of max-prefix anyway. It is a safety valve that prevents a big disaster by causing a smaller disaster.
>  
> One thing I do see a problem with is that the RR or ASBR propagates
> a received ORF back to the source of the routes.
> That RR or ASBR may have other clients that still want the routes.
> ORFs are not designed to be propagated.
>  
> Regards,
> Jakob.
>  
> From: Idr <idr-bounces@ietf.org> On Behalf Of Robert Raszuk
> Sent: Thursday, July 16, 2020 12:21 PM
> To: Aijun Wang <wangaj3@chinatelecom.cn>
> Cc: idr@ietf. org <idr@ietf.org>
> Subject: Re: [Idr] https://tools.ietf.org/html/draft-wang-idr-rd-orf-00
>  
> Aijun,
>  
> I do understand that you want to push in RD-ORD pre import RDs. Perhaps selecting first those which advertise the most VPN routes. 
>  
> But this is so severely broken idea that I am not sure how to even describe it. Just imagine the mess of now partially broken VPN users which asked for full mesh and got now partially working and partially broken mesh. 
>  
> This would be also terrible to troubleshoot (even assuming that you would refrain from RD-ORF propagation). 
>  
> Bottom line - to control number of VPN routes - for years operators have deployed prefix limit on ingress to the SP network (PE-CE edge). Once prefix is accepted into a network it better be installed when VPN topology requires it. 
>  
> Filtering per RD is a really BAD IDEA. 
>  
> Thx,
> R.
>  
> On Thu, Jul 16, 2020 at 10:58 AM Aijun Wang <wangaj3@chinatelecom.cn> wrote:
> Hi, Robert:
>  
> When the RD is designed as per VRF per PE, the mechanism of RD based ORF can also apply-------The received router needs only extract and reflect the most influenced RDs back to upstream router(ASBR/RR),  and then to notify the source of these VPN routes to control the prefixes advertisement.
> Actually, the above design will make the RD-ORF more accurate than the RT based control.
>  
>  
> Best Regards
>  
> Aijun Wang
> China Telecom
>  
>  
>  
> From: robert@raszuk.net [mailto:robert@raszuk..net] 
> Sent: Thursday, July 16, 2020 3:06 PM
> To: Aijun Wang <wangaijun@tsinghua.org.cn>
> Cc: wangw36@chinatelecom.cn; Aijun Wang <wangaj3@chinatelecom.cn>; idr@ietf. org <idr@ietf.org>
> Subject: Re: [Idr] https://tools.ietf.org/html/draft-wang-idr-rd-orf-00
>  
> > It can also be used to identify the VPN customer.  
>  
> Sorry but no. 
>  
> Best practice for number of reasons is to make RD unique per VRF and not per VPN. We should not standardize something which is a pretty bad idea to start with. 
>  
> Kind regards,
> Robert
>  
>  
>  
>  
>  
> On Thu, Jul 16, 2020 at 4:40 AM Aijun Wang <wangaijun@tsinghua.org.cn> wrote:
> Hi, Robert:
>  
> Thanks for your reviews and comments.
> As you said, RD is to make the VPN prefix unique within the VPN’s domain. It can also be used to identify the VPN customer.
> The usage of RT, just as you said, is to control what routes are distributed where, that is to say, to control the customer’s VPN topology. RT can’t be used to identify one VPN customer.
>  
> The scenarios/problems described in this draft(https://tools.ietf.org/html/draft-wang-idr-rd-orf-00) are not for the VPN topology control, but for the VPN prefix limit management, which is signed along with the agreement with the VPN customer.
> This is the reason that we select the RD-based ORF control mechanism.
>  
> More detail reply are inline below. Wish to get more your comments/suggestions on them.
>  
> Thanks in advance.
>  
> Best Regards
>  
> Aijun Wang
> China Telecom
>  
> From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of Robert Raszuk
> Sent: Thursday, July 16, 2020 2:26 AM
> To: wangw36@chinatelecom.cn; Aijun Wang <wangaj3@chinatelecom.cn>
> Cc: idr@ietf. org <idr@ietf.org>
> Subject: [Idr] https://tools.ietf.org/html/draft-wang-idr-rd-orf-00
>  
> Dear Aijun & Wei,
>  
> I have read your draft as per subject. 
>  
> I think there is a serious misunderstanding on what RD's role is in RFC4364. 
>  
> RDs MUST never be used to signal anything which would in any way influence what routes are distributed where. Their sole role is to make the VPN prefix unique across given VPN's domain. 
> 【WAJ】RD can be used to identify one VPN customer
>  
> It is RTs which are used to import routes to VRFs on PEs. What you are trying to do is exactly why we have defined some time back RTC (RFC4684). Applications from section 5.1 and 5.2 can be happily addressed with use of RTC. 
> 【WAJ】RT is used to control VPN topology, same as the mechanism of RTC(4684). But the application described in section 5.1 and 5.2 of this draft is not for VPN topology control, but for VPN route-limit management, which is based on customer/RD.
>  
> Informationally let me also point out that RFC7543 has defined extensions to ORF to signal RTs for reducing size VPN RIBs in specific Hub & Spoke topologies. 
> 【WAJ】RFC7543 is to pull the prefix that cover one specific host address, to get the more optimal route information from the Hub, not the same scenarios as described in the current draft.
>  
> Last your proposal calls for treating ORF as a transitive message without any loop protection. That is not a good idea. 
> 【WAJ】ORF messages are exchanged within only the directed BGP sessions. Such Messages will be regenerated when it is needed to send to another BGP peer.  Would you like to describe more for the loop scenarios?
>  
> I recommend to protect your PEs from being overwhelmed by VPN routes by prefix limit instead. 
> 【WAJ】Prefix Limit mechanism can be used for Option –A, but not for Option B/C, as that described in the draft.
>  
> Kind regards,
> R.
>  
> PS. Did we have any discussion in IDR or BESS on this proposal ?
>  
> _______________________________________________
> Idr mailing list
> Idr@ietf.org
> https://www.ietf.org/mailman/listinfo/idr