Re: [Idr] WG Adoption call for draft-wang-idr-rd-orf-05.txt (2/4/2021 to 2/18/2021)

"Jakob Heitz (jheitz)" <jheitz@cisco.com> Fri, 12 February 2021 02:56 UTC

Return-Path: <jheitz@cisco.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 15BEB3A10FD for <idr@ietfa.amsl.com>; Thu, 11 Feb 2021 18:56:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.6
X-Spam-Level:
X-Spam-Status: No, score=-9.6 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, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=AEHGJZ6y; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=JKJcqcW7
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 37M4DZb6Fu-c for <idr@ietfa.amsl.com>; Thu, 11 Feb 2021 18:56:27 -0800 (PST)
Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 837883A10FC for <idr@ietf.org>; Thu, 11 Feb 2021 18:56:27 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=53770; q=dns/txt; s=iport; t=1613098587; x=1614308187; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=AzRyuu8DmvLknQe+J6OS+4PA0pYIGZyr5lFsPVhklhg=; b=AEHGJZ6yFcKLArNH0W78BZX9sCV5hvM8g+gwkNvwaGGpJbTlu1pecR5M TEJVfIzJU+AcqM4Lk/K9XqxiigdtB3tpwWNajj5oll57DBwHUk+A4F5ZK 6L0GM1CoN/ZHmz9TAtQ6iBcHemQQ3WrEG7b9lBKm0gRDnigYlhU9eaSHy A=;
X-IPAS-Result: A0DrAQCR7SVgmIoNJK1iHAEBAQEBAQcBARIBAQQEAQGCD4EjMCMufVo2MYRBg0gDjhQDgQWOEYoGglMDVAsBAQENAQEjCgIEAQGESwIXgXACJTgTAgMBAQEDAgMBAQEBBQEBAQIBBgQUAQEBAQEBAQGGNg2GQwEBAQMBHQYKEwEBNwEECwIBBgIRBAEBHgMBBgMCAgIwFAkIAgQOBQgTglUBgX5XAw4gAQ6VI5BqAooldoEygwQBAQaFChiCEgMGgTiCdoQEAYZDJhuBQUGBEUOBWEk1PoEEgVkBAQIBgRZIKwmCYDSCK4IGWykBJ0MOAi8oEQwHBQNBCAcGCgQBNxIBBwELL494HgqDJ4c/jEqQNYEUCoJ6iTePX4MWoyyfZJF9D4RCAgICAgQFAg4BAQaBbCGBWXAVgyRQFwINhD2JYgwFCQkUgzqFFIVEAXM3AgYBCQEBAwl8ixcBAQ
IronPort-PHdr: 9a23:vHTSdx+DfvMmNP9uRHGN82YQeigqvan1NQcJ650hzqhDabmn44+7ZhKN+e5silDJQIyd7OhLzeHQ4OjsWm0FtJCGtn1KMJlBTAQMhshemQs8SNWEBkv2IL+PDWQ6Ec1OWUUj8yS9Nk5YS9rlZlvdomC7qzkIFVP0M1k9KuH8AIWHicOx2qi78IHSZAMdgj27bPtyIRy6oB+XuNMRhN5pK706zV3CpX4bdg==
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.81,172,1610409600"; d="scan'208,217";a="668831221"
Received: from alln-core-5.cisco.com ([173.36.13.138]) by alln-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 12 Feb 2021 02:56:26 +0000
Received: from XCH-ALN-001.cisco.com (xch-aln-001.cisco.com [173.36.7.11]) by alln-core-5.cisco.com (8.15.2/8.15.2) with ESMTPS id 11C2uQoc026622 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 12 Feb 2021 02:56:26 GMT
Received: from xfe-rcd-001.cisco.com (173.37.227.249) by XCH-ALN-001.cisco.com (173.36.7.11) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Thu, 11 Feb 2021 20:56:26 -0600
Received: from xhs-rtp-003.cisco.com (64.101.210.230) by xfe-rcd-001.cisco.com (173.37.227.249) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.2.792.3; Thu, 11 Feb 2021 20:56:25 -0600
Received: from NAM04-DM6-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-003.cisco.com (64.101.210.230) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Thu, 11 Feb 2021 21:56:25 -0500
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=i9R+Z2UuVPhzZ2kmP/PENF3nRtK8jSvvZ2JnGturxkdzcWRwCzWZxGa2mz02lx1JS8sTzAPzRXpCrpa+6ZZRv7K7M1y5JnihQEjSKfybiczPqe5bHQYQRz3++zQCJcQpoBIEnuhv753925SO8d66QwG2TCJW1A7tjL79lf77WzuHlaUEaQoWtDXkAoU3AlYhmdoy0h35ofnMXWONrlWGIuNKNk2Jeeal3xD6//DeRDGbhfQwOYd1TfYtWQ1cXYNRk1cYeaSQLlGBaDeAT91aJkekQQFbbbAxvI8uvKmWcHBVdl1XrfuNe5OatO1lzwwSZevQJukS6+aNWIC1lsuCiA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=AzRyuu8DmvLknQe+J6OS+4PA0pYIGZyr5lFsPVhklhg=; b=fXE5hJmnGHOnznBuhhc7/m/TpASyMbPjMTS7KLGZQkIheRArJe4cIZYEiY7IQhNZfVlDqUjhCH1NCAimckEZ9Phbauhepu9+1E4hcrvPpr0zmrvLqzaE+CPYQzZVZnl460UlXqF+eKnx/X9fj/I7+rS1q/gqna/q95DqZNDVl4lylLLcjyOktjx1z3QdR8Lw/TO0VXnOzkaXqfZtvCF6WJxb+wbtFuUOLil7+J/L85y131He9junPUYYILSGkeErSmmslDoXQYHPakqjY6bncixER1xPFpMRaxmJQjuedhYCtNthl1kALFS6pDJNpuo+nfSB8EdsHpYFHjSTSa3E1g==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=AzRyuu8DmvLknQe+J6OS+4PA0pYIGZyr5lFsPVhklhg=; b=JKJcqcW7LoJwfmHS9SrH4JRRl6wAdUECceK/UDOLfRK7oQbUACxNZpMsv6imEXQfHrZnGu+weTYeU4izs+heXiop8CK4TKheve372Pm9MBlwUow5lP8DVuEgU3ZiE+KOYhcPFgY2TZ166vXzQOmNacl136reFeQiisoukm4/GWc=
Received: from BYAPR11MB3207.namprd11.prod.outlook.com (2603:10b6:a03:7c::14) by BYAPR11MB3461.namprd11.prod.outlook.com (2603:10b6:a03:7b::23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3825.30; Fri, 12 Feb 2021 02:56:23 +0000
Received: from BYAPR11MB3207.namprd11.prod.outlook.com ([fe80::c951:3ae4:1aca:9daf]) by BYAPR11MB3207.namprd11.prod.outlook.com ([fe80::c951:3ae4:1aca:9daf%3]) with mapi id 15.20.3825.034; Fri, 12 Feb 2021 02:56:23 +0000
From: "Jakob Heitz (jheitz)" <jheitz@cisco.com>
To: Aijun Wang <wangaijun@tsinghua.org.cn>
CC: Robert Raszuk <robert@raszuk.net>, Susan Hares <shares@ndzh.com>, "idr@ietf.org" <idr@ietf.org>, "Acee Lindem (acee)" <acee@cisco.com>
Thread-Topic: [Idr] WG Adoption call for draft-wang-idr-rd-orf-05.txt (2/4/2021 to 2/18/2021)
Thread-Index: Adb7C8Tapzr6LUQXS7CFnBh8kC9NpgErJwcAAA2IX4AABtfh4AADGMsAABAsvAAABQFagAABoDAAAAYO6gAAAJ++AAABFeiAAAg1DPAAANgVgAAHWbiAAAAbuIAAAO5rgAAB0DSRAAFo3wAAAKBhkA==
Date: Fri, 12 Feb 2021 02:56:23 +0000
Message-ID: <BYAPR11MB3207FC61ECA7467CD19E5E82C08B9@BYAPR11MB3207.namprd11.prod.outlook.com>
References: <7433780F-B74A-49F0-85D5-C0767056C62C@cisco.com> <231878A8-2D2B-4F94-A667-97262C8EDA21@tsinghua.org.cn>
In-Reply-To: <231878A8-2D2B-4F94-A667-97262C8EDA21@tsinghua.org.cn>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: tsinghua.org.cn; dkim=none (message not signed) header.d=none;tsinghua.org.cn; dmarc=none action=none header.from=cisco.com;
x-originating-ip: [2601:647:5701:46e0:a466:79fe:7183:c553]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 4a86f5f6-efa3-4098-7acc-08d8cf01c849
x-ms-traffictypediagnostic: BYAPR11MB3461:
x-ms-exchange-transport-forked: True
x-microsoft-antispam-prvs: <BYAPR11MB3461BA5A6E24E61C3D3D93B2C08B9@BYAPR11MB3461.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:826;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: zjw3hKFnoKorlT4L5Xhy/GVWdzQhVLM+txbnuiClpok2NsaSLkDPZu+0stVkoxxpuYoRFyhxBf12G/Z0KITYjeAsnZK4qiIeGYSBeVPMCMeTf4dThzZs1FbIJzObgJui3KVo/5u0crF540Q6vHSmlzjiChVkSFNp7/Q3BJLYo8W9hkSJub+x59IaZxjIAtpxpWXocsqoyBBweiQnUJPQzK6txDuk3EO+3jI3n2xl45NO6xh5wB50hpq7VniO3eREXFXRPe6H4WV+ELOQTp8/ZqHy6y1G1X5ghphbpXXn95dOpoefaGSyrdJFq7FEL1DjwIb+wHH6ytQWHk0fTbVgrWyYkrfImSeXPJ/3Rea07amwBZXr6iNcfmB6P0IQ+slyXNXLim6gBQNbzkYf8eZwaMhdjhxqlN4VrosbJ+AiYEaMqhfSN0kT5oP3veooiQZUgp4C2b44gIg5Te7WFu6JEihz6kFszIVM+DsEjCyNxE3XHx6sX0ixxiv+l0czKOfzEUGKk9F8dC2tiMXMI+ZlTNC4psDT/AUmoNwFUfZ908N3G3MGpl+ZmlKZtf3Po+ve38grHuiVgsxqEfxZ4HvKxVc+vhJ5q0t8V8YgMTF76Qk=
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BYAPR11MB3207.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(396003)(366004)(39860400002)(376002)(136003)(346002)(86362001)(186003)(478600001)(7696005)(107886003)(6916009)(2906002)(8936002)(71200400001)(9686003)(8676002)(5660300002)(66556008)(66446008)(66476007)(66946007)(54906003)(64756008)(76116006)(966005)(166002)(53546011)(4326008)(6506007)(52536014)(83380400001)(55016002)(33656002)(316002)(66574015); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata: bAyigOmIdHbjvsF6vC6BTDZkLY+KVPBCPdmJeXKdLmBrE+qQRd/HRJJnCJ/Iuj8sSHs6tNlS5cIVDXf8g+yjBvkmnvd4ROWht9qhg5D86/6Q9zHu7VHJ2V7toRgmS3+/MFEqezEmZQVJKhaHCRcV+b86fM2h2h9RlHNfrJ3pd5XTx6eiBMZNiKY2RSLMm051JtZxhweHUbchcCOH48thYKbTOGEAyDUNHWIFjAYkf7qDtwUhHjBM7GU44XsnGyQb3ENmhztKiAsTgCqq7Srss5UdbdUr492LIN79xaT7RFWAlTN2g6CVuOKE50fzsOdBa5yv5evrbdF2Klk8P/kq2zbLWjbyEMlysQb+T/xtYnLPC5SmnHBqiVBpBx9sQRdLNfLaUorIlqBDOMxzqws5Ri1jkomTLSwhM+S7S6GihAz8fuD7NPid6GHE3q86V6RXAH2ogcRDgKvNR7fiSHnLnLme/RspO8kRr7yQkjACc8ho3KnVFxY9sAK0apptoDbglXjHJ0yFtKC2FinMemp4I+GAr9q7PKZ/FMl1oNfhVC4O8eKneehp8LOjj3GtMHvYG3j+NuFK/QoZFYTr1wxWnuDCyiZUuF5/K4LRVfXRYt76g+1jhfdNMGRijq44w6pef3Gl88Yiw4QPhYRNyQ0sTp1IK/XJcbyoairmab2FbBVrfNCjQnqggoJKIorfqfBZbH38W/Qofga/5T6fHcSj8edeX4Cu/3PDQy/Yl1YWkhoTPVI4wKEx8U5yx5u5wXsRXL49iRiQiE61qWehW/tJLdjmZzfyfSqK6+XMdSjkB5QpryfeQbNnjGLoLNnOhQuKvhZiy3N0BEbURb6sMYi1lvQiY72vKgMyAd7nBduZgmcQ9qTv+f6Z91yBupKBESE8cMiee0XJHKa6T7+rJGWeS3Ln/wEFfiIU8R0xcx5hG4DkI3PHnGEvKy0t4vlG77kaDHFFHu48Nz1Nc2qJ0M0ICGuAe4Vr8Azt0DB3VywuLG5snnqozLFbMw/jhYvNqz9H9DSDZXUqd0fBbEj240jfB5TC62TgFGgX5E0Y0RZ32eVW/+LSrcdxmOJAqoYM7F3DETmY1O2qYQLNDhw0Phcfwzx7DA2rdDiScB46fAvLwBuLUpC2OKjpfYUJvq5ZsEq+rSccrh1GuMfRV9rA/SUg1c/93PmQW8TC58nc5z1/I3tkQb7qg08lrxWIQ1MlrIugFJia3bz4/wY0nTe6mTcVDtn7dCagmS4TH0MMAjlmFD/hn8mx+UjrMsXP5u2zHwupElYCg07DqCNDwgiYkt+5lDF/71rmvx5Eg+7C49Mpxe/CqOfKfl7KoFBBomz+DUy8gQrg+lOIuOeld6snBryqBKyq7u64VXsHtDb9D+NC8Ge5TnlJC1Pvn8OOGCxiW6KP
Content-Type: multipart/alternative; boundary="_000_BYAPR11MB3207FC61ECA7467CD19E5E82C08B9BYAPR11MB3207namp_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: BYAPR11MB3207.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 4a86f5f6-efa3-4098-7acc-08d8cf01c849
X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Feb 2021 02:56:23.4441 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: uUaJJ8TfLuzPvMkGnvZfs5ID3oVsdAK5S503XdLoiY+3KUkR36reb2+vV+nhwFsABtGskcMLltWEWpkckuEz5g==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR11MB3461
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.36.7.11, xch-aln-001.cisco.com
X-Outbound-Node: alln-core-5.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/ijn-4O2tiqtX2qmlbz-su-2RSNc>
Subject: Re: [Idr] WG Adoption call for draft-wang-idr-rd-orf-05.txt (2/4/2021 to 2/18/2021)
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, 12 Feb 2021 02:56:31 -0000

The maximum-prefix configured on a BGP session is not designed to protect the router from too many routes.
When you add up all the maximum-prefix amounts for each session, the total is much higher than the router can tolerate.
There are other configuration knobs to protect the router from too many routes.
The purpose of maximum-prefix is to guard against route leaks and other configuration errors from customer networks.
It is not the only tool for that and it's not very good. But it does tell the customer in no uncertain terms that something went wrong. It's like a large hammer for a small screw. Or 杀鸡用牛刀.
Now, you said before that you don't want to tell the source, so there's little point.

Regards,
Jakob.

From: Aijun Wang <wangaijun@tsinghua.org.cn>
Sent: Thursday, February 11, 2021 6:03 PM
To: Jakob Heitz (jheitz) <jheitz@cisco.com>
Cc: Robert Raszuk <robert@raszuk.net>; Susan Hares <shares@ndzh.com>; idr@ietf.org; Acee Lindem (acee) <acee@cisco.com>
Subject: Re: [Idr] WG Adoption call for draft-wang-idr-rd-orf-05.txt (2/4/2021 to 2/18/2021)

Hi, Jakob:

I think we can evaluate this mechanism frim other viewpoints:
We will definitely deploy BGP maximum-prefixes feature between two BGP peer, and will break the session if the receiver can’t tolerate. Right?
The RD-ORF mechanism just wants to cope with such scenarios in more graceful/gradual way.

Aijun Wang
China Telecom


On Feb 12, 2021, at 09:23, Jakob Heitz (jheitz) <jheitz@cisco.com<mailto:jheitz@cisco.com>> wrote:
 "can" is not good enough. "can certainly" is not much better. "did" with backup is good.

Regards,
Jakob.



On Feb 11, 2021, at 4:31 PM, Aijun Wang <wangaijun@tsinghua.org.cn<mailto:wangaijun@tsinghua.org.cn>> wrote:
 Hi, Jakob:

This is the start point of ORF mechanism, not only for RD-ORF. I think we can refer the description in https://tools.ietf.org/html/rfc5291#section-1.
Locally discard is not enough. The excessive junk BGP Updates can certainly lead the high CPU usages of the affected PE, and let them react slowly to process the other normal BGP Updates, and then the communications of the other normal VPNs that on the shared BGP connection.

Aijun Wang
China Telecom


On Feb 12, 2021, at 08:16, Jakob Heitz (jheitz) <jheitz@cisco.com<mailto:jheitz@cisco.com>> wrote:

Ajun,

Well, if that's all it is, then you should just drop the routes at the weak PE.
You say that receiving and dropping is burdensome on the receiving router.
Frankly, I don't believe you.
Can you back that statement up and demonstrate how it has actually caused outages?

Regards,
Jakob.

From: Aijun Wang <wangaijun@tsinghua.org.cn<mailto:wangaijun@tsinghua.org.cn>>
Sent: Thursday, February 11, 2021 4:01 PM
To: Robert Raszuk <robert@raszuk.net<mailto:robert@raszuk.net>>
Cc: Jakob Heitz (jheitz) <jheitz@cisco.com<mailto:jheitz@cisco.com>>; Susan Hares <shares@ndzh.com<mailto:shares@ndzh.com>>; idr@ietf.org<mailto:idr@ietf.org>; Acee Lindem (acee) <acee@cisco.com<mailto:acee@cisco.com>>
Subject: Re: [Idr] WG Adoption call for draft-wang-idr-rd-orf-05.txt (2/4/2021 to 2/18/2021)

Hi, Robert and Jakob:
I think you all misunderstood the procedures of RD-ORF mechanism.
The RD-ORF message doesn’t need to find its way back to the source to control the excessive VPN routes, the intermediate nodes, for example, the RR, or the ASBR can accomplish this work instead.
That is to say, if one PE can’t receive more routes from the RR, it just send the RD-ORF message to the RR. If RR has the capability to process the upcoming BGP UPDATES, it will not send another RD-ORF message to the source.
Only the specified VPN communications between the weak PE and other health PEs will be influenced. The communications among the health PEs will be kept in good state.

Whether and when to send the RD-ORF message is determined independently by each involved nodes.

Let me also explain such behavior to you based your statements inline below.[WAJ]

Wish these explains can correct your understanding of RD-ORF mechanism.
Aijun Wang
China Telecom



On Feb 12, 2021, at 04:39, Robert Raszuk <robert@raszuk.net<mailto:robert@raszuk.net>> wrote:


> You are trying to have a VRF that is receiving routes to notify a VRF that is sending routes that it is sending too many routes.

Well if that was true maybe we could try to make it work. But they are not doing this.

See receiving VRF of RD:X can import routes from many other PEs/VRFs with zoo of RDs. So what they say is to be selective and say Oh this RD:FAT is sending way too many routes so we want to get rid of those routes. Moreover some PEs may be just weak and can trigger such dislike msg and some may be taking the routes with no problem.

[WAJ] If the weak PE trigger RD-ORF message to RR, but other health PEs under this RR can process it, then when RR receives such message, it just filter the RD-specified VPN BGP updates to the weak PE, other health  PEs can still receive the specified VPN BGP updates and then got the RD-specified VPN routes(VPN:FAT in your example)




What is being cooked here to me looks like a complete mess - that's all.

[WAJ] Wish the above explanations can help you reorganize the imaginal but unreal mess.



Cheers,
Robert






On Thu, Feb 11, 2021 at 9:19 PM Jakob Heitz (jheitz) <jheitz@cisco.com<mailto:jheitz@cisco.com>> wrote:
You are trying to have a VRF that is receiving routes to notify a VRF that is sending routes that it is sending too many routes.
The receiving VRF and the sending VRF are separated by several or many intermediate BGP speakers.
[WAJ] Yes, but controlling the VPN routes needn’t relay the RD-ORF messages back until to the source. There are many valves between them.


Bouncing ORFs back through these intermediate speakers is not a reliable way to achieve this notification.
[WAJ] Yes, we have avoided this approach.


This is because each intermediate speaker has multiple downstream speakers.
One speaker needs to receive the ORF from all of its downstream speakers before it can bounce the ORF upstream.
[WAJ] Each intermediate speaker can control the valves to each RD-ORF message initiator.
Whether and when send out its own RD-ORF message is determined by itself process capability, not related to the portion of downstream speakers emitted RD-ORF message. This is more flexible and deployable.


Thus, it's unlikely that the ORF will make it all the way to the source of the routes.
[WAJ] Yes, we have abandoned this approach.


You are asking for something like a reverse BGP.
That can't scale.
The way that we find out whether a far away speaker got our route correctly is with looking glasses.
Looking glasses aren't implemented by BGP, because BGP operators don't want to store that kind of information.
[WAJ] RD-ORF needs also not store that kind of information.



Regards,
Jakob.

From: Aijun Wang <wangaijun@tsinghua.org.cn<mailto:wangaijun@tsinghua.org.cn>>
Sent: Thursday, February 11, 2021 8:12 AM
To: Robert Raszuk <robert@raszuk.net<mailto:robert@raszuk.net>>
Cc: Jakob Heitz (jheitz) <jheitz@cisco.com<mailto:jheitz@cisco.com>>; Susan Hares <shares@ndzh.com<mailto:shares@ndzh.com>>; idr@ietf.org<mailto:idr@ietf.org>; Acee Lindem (acee) <acee@cisco.com<mailto:acee@cisco.com>>
Subject: Re: [Idr] WG Adoption call for draft-wang-idr-rd-orf-05.txt (2/4/2021 to 2/18/2021)

Hi, Robert:
Aijun Wang
China Telecom

On Feb 11, 2021, at 23:40, Robert Raszuk <robert@raszuk.net<mailto:robert@raszuk.net>> wrote:


Now if all of the above is not done or done with mistakes and you indeed experience to many routes to be handled by data plane you stop locally importing those routes to local VRFs by VRF shutdown. The good thing here is that this will be noticed by all attached customers as their dynamic routing will propagate withdraws.
[WAJ] The BGP session is shared by several VPNs and cannot be shutdown in such situations. Procedures that you expect would not happen.


Where did I say to shutdown BGP session ?

I said VRF shutdown ... nothing to do with BGP sessions shutdown.

[WAJ] Don’t you think VRF shutdown has the more broader influences? RD-ORF influences only the newly advertised VPN routes. VRF shutdown will influence the existing VPN routes and its existing forwarding traffic.

- - -

Let me provide the analogy here ...

You are presenting a solution on what to do when we fly low and start hitting the top of the trees.

WG tells you that flying low is bad practice and should not take place providing what to do to mitigate it well - in the analogy train your ground crew not to overload the plane.

You say - Oh well we have different idea instead - when we throw away during the flight some passengers we can keep flying (on the edge of safety).
[WAJ] Just deny the onboard of new passengers, not throwing the existing passengers.

That's here we are with this.

- - -

Quite honestly when we started to deploy 2547 back in nearly 2000s we were preparing much more user friendly solution (a flavor of CSC - not CSC as defined in the RFC) where SP network would only deal with next hops and never with customer routes ... yet customer would have the same type of service. Quite honestly we have had even OSPF reflector ready for it. Problem was that at that time SPs said oh we want to take millions of customer routes - no problem. We just buy bigger RRs and bigger routers. So you can guess what happened with such idea - got shelved as if deployed would result in revenue loss :).

[WAJ] RD-ORF mechanism can encourage the provider to deploy inter-as VPN solutions because it gives them the granular control over the VPN routes propagation between ASBRs or RRs, which can certainly broader the VPN service coverage and the revenue.

Best,
R.