Re: [Idr] New Version Notification for draft-wang-idr-rd-orf-03.txt

"UTTARO, JAMES" <ju1738@att.com> Mon, 24 August 2020 21:48 UTC

Return-Path: <ju1738@att.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 95C763A0CEA for <idr@ietfa.amsl.com>; Mon, 24 Aug 2020 14:48:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.104
X-Spam-Level:
X-Spam-Status: No, score=0.104 tagged_above=-999 required=5 tests=[HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
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 RqWhde_9OPvq for <idr@ietfa.amsl.com>; Mon, 24 Aug 2020 14:48:54 -0700 (PDT)
Received: from mx0a-00191d01.pphosted.com (mx0b-00191d01.pphosted.com [67.231.157.136]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3061F3A0CE6 for <idr@ietf.org>; Mon, 24 Aug 2020 14:48:54 -0700 (PDT)
Received: from pps.filterd (m0049462.ppops.net [127.0.0.1]) by m0049462.ppops.net-00191d01. (8.16.0.42/8.16.0.42) with SMTP id 07OLgLNV013323; Mon, 24 Aug 2020 17:48:47 -0400
Received: from alpi154.enaf.aldc.att.com (sbcsmtp6.sbc.com [144.160.229.23]) by m0049462.ppops.net-00191d01. with ESMTP id 334njh0cw3-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 24 Aug 2020 17:48:46 -0400
Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id 07OLhjPb024176; Mon, 24 Aug 2020 17:43:45 -0400
Received: from zlp30484.vci.att.com (zlp30484.vci.att.com [135.47.91.179]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id 07OLhfqf024087 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 24 Aug 2020 17:43:42 -0400
Received: from zlp30484.vci.att.com (zlp30484.vci.att.com [127.0.0.1]) by zlp30484.vci.att.com (Service) with ESMTP id ABA144009E60; Mon, 24 Aug 2020 21:43:41 +0000 (GMT)
Received: from GAALPA1MSGEX1BD.ITServices.sbc.com (unknown [135.50.89.105]) by zlp30484.vci.att.com (Service) with ESMTPS id 91C044009E63; Mon, 24 Aug 2020 21:43:41 +0000 (GMT)
Received: from GAALPA1MSGEX1BE.ITServices.sbc.com (135.50.89.106) by GAALPA1MSGEX1BD.ITServices.sbc.com (135.50.89.105) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2044.4; Mon, 24 Aug 2020 17:43:38 -0400
Received: from GAALPA1MSGEX1BE.ITServices.sbc.com ([135.50.89.106]) by GAALPA1MSGEX1BE.ITServices.sbc.com ([135.50.89.106]) with mapi id 15.01.2044.004; Mon, 24 Aug 2020 17:43:38 -0400
From: "UTTARO, JAMES" <ju1738@att.com>
To: "Fomin, Sergey (Nokia - US/Mountain View)" <sergey.fomin@nokia.com>, "wangw36@chinatelecom.cn" <wangw36@chinatelecom.cn>
CC: idr <idr@ietf.org>
Thread-Topic: [Idr] New Version Notification for draft-wang-idr-rd-orf-03.txt
Thread-Index: AQHWecA7JvHW2O3WUkmBF60ycZnFoKlH+a2A///RgcA=
Date: Mon, 24 Aug 2020 21:43:38 +0000
Message-ID: <9ae4a998586744aaa2705307b1fce7c9@att.com>
References: <159823342044.23031.16551144892707874928@ietfa.amsl.com> <202008240951001271894@chinatelecom.cn> <BYAPR08MB54935CC14FAD4B91D3331ED185560@BYAPR08MB5493.namprd08.prod.outlook.com>
In-Reply-To: <BYAPR08MB54935CC14FAD4B91D3331ED185560@BYAPR08MB5493.namprd08.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [130.10.128.217]
x-tm-snts-smtp: 87F59C487E6B5F5F7F53083A812C93BAD0A43F82630AC2D4057B11C70C2F615E2
Content-Type: multipart/alternative; boundary="_000_9ae4a998586744aaa2705307b1fce7c9attcom_"
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.235, 18.0.687 definitions=2020-08-24_12:2020-08-24, 2020-08-24 signatures=0
X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 phishscore=0 mlxlogscore=999 lowpriorityscore=0 mlxscore=0 adultscore=0 impostorscore=0 suspectscore=0 priorityscore=1501 spamscore=0 clxscore=1011 malwarescore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2006250000 definitions=main-2008240170
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/otuzwOzi9IiJLDRimocDttHGIu0>
Subject: Re: [Idr] New Version Notification for draft-wang-idr-rd-orf-03.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: Mon, 24 Aug 2020 21:48:57 -0000

Comments In-Line.

Thanks,
              Jim Uttaro

From: Idr <idr-bounces@ietf.org> On Behalf Of Fomin, Sergey (Nokia - US/Mountain View)
Sent: Monday, August 24, 2020 4:28 PM
To: wangw36@chinatelecom.cn
Cc: idr <idr@ietf.org>
Subject: Re: [Idr] New Version Notification for draft-wang-idr-rd-orf-03.txt

Hi Wei Wang,

From your description of existing solutions:

>   4) Configure the Maximum Prefix for each VRF on edge nodes
>
>   When a VRF overflows, PE will break down the BGP session with RR
>   according to the Maximum Prefix mechanism.  However, there may have
>   several VRFs on PE rely on the PE-RR session, this mechanism will
>   influence other VRFs.
This is not correct. A good implementation of _per-vrf prefix-limit_ does not mandate MP-BGP session teardown, it allows to use soft actions instead, such as discard routes + log.
[Jim U>] Yup.. That is the way my implementations work.. The goal is to ensure maximum correctness of a given VPN. Tearing down the PE-RR session is killing a fly with a sledge hammer..

Additionally, if you insist that a local-only discard mechanism is not good enough (why?) and you want to prevent route advertisement(s) from an RR/remote PE for a specific VRF, it is hard to see real-world benefits of the proposed solution vs, for example, extra logic on top of RTC (i.e. if you implement a feature "withdraw an RTC route after FIB/memory utilization reaches 95%"). Yes, RD-ORF might be a bit more granular in such case, but does it bring any benefit? VRF with 50% reachability or VRF with 0% reachability from a given PE are both examples of unintended network state (and the earlier could be worse) that requires intervention.

--
Sergey

From: Idr <idr-bounces@ietf.org<mailto:idr-bounces@ietf.org>> On Behalf Of wangw36@chinatelecom.cn<mailto:wangw36@chinatelecom.cn>
Sent: Sunday, August 23, 2020 6:51 PM
To: idr <idr@ietf.org<mailto:idr@ietf.org>>
Subject: Re: [Idr] New Version Notification for draft-wang-idr-rd-orf-03.txt

Hi IDR experts,

Based on the previous discussion, we update our draft as follows:

  *   the description of the limitations of existing solutions is added
  *   clarifying that the operation process of RD-ORF on each device is independent
  *   modifying the withdraw mechanism of RD-ORF
    Any comments are welcome.

Best Regards.


________________________________
Wei Wang
China Telecom

wangw36@chinatelecom.cn<mailto:wangw36@chinatelecom.cn>

From: internet-drafts<mailto:internet-drafts@ietf.org>
Date: 2020-08-24 09:43
To: Haibo Wang<mailto:rainsword.wang@huawei.com>; Gyan S. Mishra<mailto:gyan.s.mishra@verizon.com>; Wei Wang<mailto:wangw36@chinatelecom.cn>; Aijun Wang<mailto:wangaj3@chinatelecom.cn>; Shunwan Zhuang<mailto:zhuangshunwan@huawei.com>; Jie Dong<mailto:jie.dong@huawei.com>; Gyan Mishra<mailto:gyan.s.mishra@verizon.com>
Subject: New Version Notification for draft-wang-idr-rd-orf-03.txt

A new version of I-D, draft-wang-idr-rd-orf-03.txt
has been successfully submitted by Wei Wang and posted to the
IETF repository.

Name: draft-wang-idr-rd-orf
Revision: 03
Title: Route Distinguisher Outbound Route Filter (RD-ORF) for BGP-4
Document date: 2020-08-24
Group: Individual Submission
Pages: 14
URL:            https://www.ietf.org/internet-drafts/draft-wang-idr-rd-orf-03.txt<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_internet-2Ddrafts_draft-2Dwang-2Didr-2Drd-2Dorf-2D03.txt&d=DwMGaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=s7ZzB4JbPv3nYuoSx5Gy8Q&m=T-GmdIk3xStsk13lycUmUrbLRODstoJm4CN-V2JjExU&s=14kL4f6cO3I39QTIY9-i3boaLA2giY4KiD3j2Tu9fi0&e=>
Status:         https://datatracker.ietf.org/doc/draft-wang-idr-rd-orf/<https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dwang-2Didr-2Drd-2Dorf_&d=DwMGaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=s7ZzB4JbPv3nYuoSx5Gy8Q&m=T-GmdIk3xStsk13lycUmUrbLRODstoJm4CN-V2JjExU&s=Aw-Mc7bSxvLnYtxEpzTjMz5qVGpXvLZRkDb0Ze8kZ0I&e=>
Htmlized:       https://tools.ietf.org/html/draft-wang-idr-rd-orf-03<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dwang-2Didr-2Drd-2Dorf-2D03&d=DwMGaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=s7ZzB4JbPv3nYuoSx5Gy8Q&m=T-GmdIk3xStsk13lycUmUrbLRODstoJm4CN-V2JjExU&s=PIKT-TH9C9zny7t-hQj9xqSwHgV_XG4VXGx5sMbWTJg&e=>
Htmlized:       https://datatracker.ietf.org/doc/html/draft-wang-idr-rd-orf<https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_html_draft-2Dwang-2Didr-2Drd-2Dorf&d=DwMGaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=s7ZzB4JbPv3nYuoSx5Gy8Q&m=T-GmdIk3xStsk13lycUmUrbLRODstoJm4CN-V2JjExU&s=Tre2skoFxacQ9M124fvYpANTrlrA5iYvyGv_RdEOntc&e=>
Diff:           https://www.ietf.org/rfcdiff?url2=draft-wang-idr-rd-orf-03<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_rfcdiff-3Furl2-3Ddraft-2Dwang-2Didr-2Drd-2Dorf-2D03&d=DwMGaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=s7ZzB4JbPv3nYuoSx5Gy8Q&m=T-GmdIk3xStsk13lycUmUrbLRODstoJm4CN-V2JjExU&s=CcQDMR1B4HvydxNGlDcsW01YUNWiuGyrtr_o1w2wWnE&e=>

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 information directly (e.g.
   routers in single-domain connect via Route Reflector, or routers in
   Option B/Option AB/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