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> Wed, 05 August 2020 06:55 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 3ED413A0EA7 for <idr@ietfa.amsl.com>; Tue, 4 Aug 2020 23:55:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 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, 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 uYRaNbAQy3nO for <idr@ietfa.amsl.com>; Tue, 4 Aug 2020 23:55:04 -0700 (PDT)
Received: from mail-ej1-x630.google.com (mail-ej1-x630.google.com [IPv6:2a00:1450:4864:20::630]) (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 2E4D03A0EB3 for <idr@ietf.org>; Tue, 4 Aug 2020 23:55:03 -0700 (PDT)
Received: by mail-ej1-x630.google.com with SMTP id m22so2091280eje.10 for <idr@ietf.org>; Tue, 04 Aug 2020 23:55:03 -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=dQjlPRhli242OW8mqjAMND+kqZ3dWDG6AEgyF790gQY=; b=R2z2gDsvdXjg65mDuB4j6VQ7HTOvcWv7jKI9/40d+dlaYrdjjETZcpuQluV/I8lBHr ZXvZtdvVzdpyU+6trm3ZkD4xsy7Ga2XH9Fm4k2Ql8DeWImXKTPyabzyndiCnndUzCwin mvnU5yrKs6XPsD3MDLTkE6EtS2y8rFAeNh8xtx8Qjw36yIXXy5n8klCDTDh9jBQH1+0X 1Uv/X+DsxE19VZsMP2OKgzU81+KpsISmxBez6r/xsrj7mdxKjoXo0O1Jc+AWKjOzi+33 7JNkRo2ALA13Up7G+0TihUnftNc417Y4X1OJpjxbgoheEVLEtv3o2NVxdwty9/XWtMbn 0oZw==
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=dQjlPRhli242OW8mqjAMND+kqZ3dWDG6AEgyF790gQY=; b=gM3gT2zIEbCw8KevMQhnDHMBXA1M/Hej1uDVpmvnY0LsiJzEYU5jQKLCYaZFiUgYiS 6p39j6GHBRzztonjxZFebDYHfJHi+ecfjN6f5Pi+8OXwfdLi1BtQVM05knLh3Jec4EZO KAKhDgJ9q9EtFysczvNLIOTzfg6d/NbwCxhZmgCCuIpqNx4r1Vz3lhJ2hSK0ank+v9QC 9imfZhOMlvFN60slcFu2yASDhG4h4cLwkTZ6V20JPcDq2QnD/vwhT0c2GXAVIdF2DRoo iOUGZdGzLIeoXoTtmEj/lCVKrrT6KAarQ/yO2upbvdHCMDm1CeMRGaReCliTFYrW95N3 YUnA==
X-Gm-Message-State: AOAM533q3KJ4qGl3hjnYWFIBgUR5zycKeN0h/5sJeflJ3F/7WVLgKC3w ZghGIybpzy6stMHnrWbKJ+v5XC3xJ9xfS1o3k5FcxQ==
X-Google-Smtp-Source: ABdhPJwLLtz/OEakWZBwXu5rLlXqkYpg2ygReptoPULvznTU0rcmQ5TtbXQUWNSCJr3h7FbHRxNL22L2klfE0oyhEvw=
X-Received: by 2002:a17:907:94ca:: with SMTP id dn10mr1828634ejc.110.1596610502360; Tue, 04 Aug 2020 23:55:02 -0700 (PDT)
MIME-Version: 1.0
References: <059401d66ad0$f96c3b50$ec44b1f0$@tsinghua.org.cn>
In-Reply-To: <059401d66ad0$f96c3b50$ec44b1f0$@tsinghua.org.cn>
From: Robert Raszuk <robert@raszuk.net>
Date: Wed, 5 Aug 2020 08:54:54 +0200
Message-ID: <CAOj+MMHgwXNcGduKHXoQNsn_UJS9Kpz_kDcpXH_kAhpotDKWng@mail.gmail.com>
To: Aijun Wang <wangaijun@tsinghua.org.cn>
Cc: Keyur Patel <keyur@arrcus.com>, idr <idr@ietf.org>, wangw36@chinatelecom.cn
Content-Type: multipart/alternative; boundary="000000000000d69bd505ac1bd984"
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/Z5KNQFRlRP1Js44baDz4YLcUH5Q>
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: Wed, 05 Aug 2020 06:55:09 -0000

Hello Aijun,

【Robert】: there was a number of technical problems sent to the list. None
of these were addressed. This is not the right way to filter VPN

【A-WAJ】:Would you like to point out which technical problem isn’t addressed
yet?  We have also compared the existing solutions and their limitations in
the draft and at the presentation.


As you know VPNs use different scheme of RD allocations. Most common would
be to import RDs with local rewrite. So I know you realize that and your
intention is to signal such RD to RRs or other PEs from the pre imported
routes. So far so good.


Now realize that on a given PE there is few VRFs which need to import given
RD. Import is based on RTs. Therefor not all target VRFs may import same
subset of routes originally carrying given RD. One VRF can import 5 routes,
the other 10 and yet one more 10000. Let's assume for now that that last
VRF "overflows" and decided to trigger RD-ORF.


That means that PE signals this to RR and RR stops sending all such routes
to given PE. That effectively means that even those first two VRFs which
are fine as they just import subset of routes suffer unreachability as
those routes are simply no longer arriving at the PE.


For me this is showstopper - and pretty fatal one to use RD for filtering.
We do import based on RTs and filtering should also be done based on the
RTs.


- - -


My other serious concern is that end customer will in no one be notified
about such RD-ORF filtering ... - that is frankly not acceptable to me or
to any L3VPN or L2VPN customer. As comparison when you use prefix limit on
the PE-CE customer's session goes down hence customer is alerted about the
problem.


See worst "solutions" are those which may cause silent failures. We should
avoid those at all cost.


- - -


Last this is measure to protect SP resources (PEs). Let me observe that
this topic came up in early 2000 and it was commonly agreed that the best
we can offer is protect the network from any customer injecting more then
in the customer <--> SP SLAs.


Beyond that SP's infra must keep good monitoring of PE resources instead of
waiting for disaster to happen and building parachutes.


Kind regards,

R.

















On Wed, Aug 5, 2020 at 4:34 AM Aijun Wang <wangaijun@tsinghua.org.cn> wrote:

> Hi, Keyur, Praveen and Robert:
>
>
>
> Thanks for your comments on this draft during the IETF 108 meeting.
>
> Below are responses for your questions, please review them to see whether
> they resolve your concerns:
>
>
>
> 【Q-Praveen】: When PE1 injects a prefix, will it impact other routers
> which are not overflowing the source?
>
> 【A-WAJ】:No. RR can control when to send the RD-ORF message to the
> upstream/source router.
>
> For example, if only one PE overflow, RR can add the RD-ORF as its
> Adj-RIB-Out filter to this PE, and don’t send this message to the source
> PE, or other RR.
>
> Theoretically, RR need only send such RD-ORF upstream when it can’t
> process the BGP Updates, or it is overflow.
>
>
>
> 【Keyur】:The prefix filter level filtering has more expense than a higher
> level filters.
>
> 【A-WAJ】:RD based filter is also higher level filter.  RT based filter
> can’t solve the problems that described in this draft.
>
>
>
> 【Robert】: there was a number of technical problems sent to the list. None
> of these were addressed. This is not the right way to filter VPN
>
> 【A-WAJ】:Would you like to point out which technical problem isn’t
> addressed yet?  We have also compared the existing solutions and their
> limitations in the draft and at the presentation.
>
>
>
>
>
> Best Regards
>
>
>
> Aijun Wang
>
> China Telecom
>
>
>
> *From:* idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] *On Behalf Of *
> wangw36@chinatelecom.cn
> *Sent:* Tuesday, July 28, 2020 4:47 PM
> *To:* idr <idr@ietf.org>
> *Subject:* [Idr] New Version Notification for draft-wang-idr-rd-orf-01.txt
>
>
>
> Hi,IDR experts:
>
>
>
>     Based on the previous discussion with Robert and Jakob, we update our
> draft as follows:
>
> ·       The differences between RD-ORF, RTC and Address Prefix ORF are
> briefly described;
>
> ·       The encoding of RD-ORF type-specific part is changed and the
> source address sub TLV field is added;
>
> ·       The application in single-domain scenario is added;
>
> ·       Four new types of sub-TLV are defined to carry the source address
> in different scenarios.
>
>     Any comments are welcome.
>
>
>
> Best Regards.
> ------------------------------
>
>  王巍  Wang Wei
>
> +86-010-5090-2397
> +86-177-7809-6050
> wangw36@chinatelecom.cn
> ------------------------------------------------------------------------
> CTNET2025研究所
> 中国电信股份有限公司北京研究院
> China Telecom Corporation Limited Beijing Research Institute
> 北京市昌平区北七家镇未来科技城南区中国电信北京信息科技创新园
> 邮编:102209
>
>
>
> *From:* internet-drafts <internet-drafts@ietf.org>
>
> *Date:* 2020-07-28 16:17
>
> *To:* Jie Dong <jie.dong@huawei.com>om>; Aijun Wang <wangaj3@chinatelecom.cn>cn>;
> Shunwan Zhuang <zhuangshunwan@huawei.com>om>; Wei Wang
> <wangw36@chinatelecom.cn>cn>; Haibo Wang <rainsword.wang@huawei.com>
>
> *Subject:* New Version Notification for draft-wang-idr-rd-orf-01.txt
>
>
>
> A new version of I-D, draft-wang-idr-rd-orf-01.txt
>
> has been successfully submitted by Wei Wang and posted to the
>
> IETF repository.
>
>
>
> Name: draft-wang-idr-rd-orf
>
> Revision: 01
>
> Title: Route Distinguisher Outbound Route Filter (RD-ORF) for BGP-4
>
> Document date: 2020-07-28
>
> Group: Individual Submission
>
> Pages: 14
>
> URL:
> https://www.ietf.org/internet-drafts/draft-wang-idr-rd-orf-01.txt
>
> Status:         https://datatracker.ietf.org/doc/draft-wang-idr-rd-orf/
>
> Htmlized:       https://tools.ietf.org/html/draft-wang-idr-rd-orf-01
>
> Htmlized:
> https://datatracker.ietf.org/doc/html/draft-wang-idr-rd-orf
>
> Diff:           https://www.ietf.org/rfcdiff?url2=draft-wang-idr-rd-orf-01
>
>
>
> Abstract:
>
>    This draft defines a new Outbound Route Filter (ORF) type, called the
>
>    Route Distinguisher ORF (RD-ORF).  RD-ORF is applicable when the
>
>    routers do not exchange VPN routing infomation directly (e.g. routers
>
>    in single-domain connect via Route Reflector, or routers in Option B/
>
>    Option C cross-domain scenario)..
>
>
>
>
>
>
>
>
>
>
> Please note that it may take a couple of minutes from the time of
> submission
>
> until the htmlized version and diff are available at tools.ietf.org.
>
>
>
> The IETF Secretariat
>
>
>
>
>
>
>
>