Re: [Idr] [internet-drafts@ietf.org: I-D Action: draft-haas-flowspec-capability-bits-02.txt]

"Jakob Heitz (jheitz)" <jheitz@cisco.com> Thu, 15 April 2021 03:37 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 087743A0930 for <idr@ietfa.amsl.com>; Wed, 14 Apr 2021 20:37:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.618
X-Spam-Level:
X-Spam-Status: No, score=-9.618 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_NONE=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=X2WQWBWO; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=WRNr4QvQ
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 gVZGC-_PU_Sy for <idr@ietfa.amsl.com>; Wed, 14 Apr 2021 20:37:27 -0700 (PDT)
Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 787F43A091F for <idr@ietf.org>; Wed, 14 Apr 2021 20:37:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5406; q=dns/txt; s=iport; t=1618457847; x=1619667447; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=S58yGQTwnhcm1luSp36mp9CIhJIUOAZqYtTNeN+QQ8w=; b=X2WQWBWOPznkjCMtJBKMWgcn3ymyPPiH6Qp9YQooEYETSRDzyX7FBtly cy0VnrCkLombgVFx8G8uwdRi0O1DJdCo29JEY5m3JrZNeYhdDLQwBxw9a h9ytcKWcmIJDx7/5CHb8DE4mmwaK04dbwMnGkFvmHIHaQL5ryvyvFHxbv U=;
IronPort-PHdr: A9a23:bf/VwBPY5xYADx49SVIl6nf1WUAX047cNxMJ6pchl7NFe7ii+JKnJkHE+PFxlzfhRYvB4LRDkeWF+6zjWGlV55GHvThCdZFXTBYKhI0QmBBoG8+KD0D3bZuIJyw3FchPThlpqne8N0UGAMjkbBvVuHLhpTIXEw/0YAxyIOm9E4XOjsOxgua1/ZCbYwhBiDenJ71oKxDjpgTKvc5Qioxnec4M
IronPort-HdrOrdr: A9a23:CpZv0qFyKgfPgBW8pLqFmZXXdLJzesId70hD6mlYcjYQWtCElsyogfQQ3QL1jjFUY307hdWcIsC7IE/03aVepa0cJ62rUgWjgmunK4l+8ZDvqgePJwTXzcQY76tpdsFFZ+HYJVJxgd/mpCyxFNg9yNeKmZrY+tv25V0Fd3AMV4hL6QBlBgGHVmh/QwdbDZQ0faDsmPZvjTymZHgRc4CHHXEDRefOvJnmk5jhbB4ACXccmUizpBmv76P3FAXd4wcGX1p0sPkf2EXmsyi83KWstPmn1gTRvlWy0716kMbso+Ezf/CkpdMSLlzX+2OVTaRnH4aPpTUk5NyogWxa7OXkhzcFE4BN52jKfmezyCGdmzXI9Do18XftxRu5rBLY0LbEbQk3AcZAmo5VGyGxgyFL0b0Ms9Mo40uju5VaFh/GlijmjuK4Ki1CrFa+onYpjIco/hpieLYec7NYoMg++05YAf47bVrHwb0nC+VnAYXg4u9XezqhHgnkl1RoqebcOkgbL1OjeAwvq8aV2z9ZkDRS1E0D3vESmX8G6dYUV4REz/6sCNUqqJh+CustKY5tDuYIRsW6TkbXRwjXDW6UKVP7UIkaJnP2rYLt6rld3pDpRLU4iL8J3LjRWlJRsmA/P2j0D9eV4ZFN+hfRBEKwQCrq0cMbw5RioLXzSP7KPES4ORUTuvrlh89aLtzQWv61Np4TKeTkN3HSFYFA2BC7VIJVLXUYTc0Jqtc2U1+DuavwW8rXn92eVMyWCKvmED4iVG+6KGAERiLPKMJJ6V3uWnKQummWZ1rdPmjEub5gGqnT+OYejKIXMJdXjwQTgVOlosWCKThItL0qbFJzSYmXy5+TlC2TxyLl/m9pMh1SAgJ++7P7SU5HogcMLgfzarYMu9KWfGhIx3uZLhpjT8fbeTQv42hfyOaSFdi91CoiA9WoPiaxlH0Ivk+HSJ8ah+me/8v/Y4g5CZwnQaR1Eg3OG3VO6F5XgVYGTDVBal7UFzvoh6ngsYcdA/vHccJgxC2xJ9RPlH7ZvUKAhM0mS3cBRQSyWcqPjQtGfUsOunRBt4skxJuJg3KGNHY2iuVQCiw8VE2nRJZ9SDmjSKoRsLbxYw10RXqNnlWh+mEOU1uv0V4TiGznJTCTYtfRDDNmyypl+5ev1k9ofWOAeE81TXZ2veRGZDj7k0c29/OXbayu1GbUUH8++6U2NTHIZiZ6GHIy+/m+yAOVlDGeFX8v25UpOajHAK4+dqzIs0ndW7GghOUIGeRZ841iM82ruugXUfiHcwvQNz/gDfg1sjbl60oNKW1xqHM+l+nv1wCg5G+k3GQnCf66GiUse5gLZ9Wd5XPjXfCGzdFwis80p/K5NiH0ZsSdwa/aKz5FJRW7mx/9c8g47ZRVt7k1rr19At3SVibJzmhO2FEmN9jv/XluNphT8fTEIMtibsYScyVW8h4gk8mONlIitkjzDvUldV8ggnfHN7qykvb1gKtqBlfEqBr7OFGZ/SEY5fvDUieZ3bMRCq47Iw1tGQABwWUn+PnHe5zbCQ2see0G4UGzNWWldqRBDKeCArcdo39Bkp61tv7SczC93g/evTF2eP0Tt2mmRN6/GwKKF6pD9cegNVGFn6ut54qygV7MOE+GQlVdgZcAc0oaKtlHgH0lioY81yCpUKz5ok4/iTJlkHhav0+o3pLj+XvRGEFNLBbQjZpXVyRCK3Tgt7WxzcGIkHDmpCVf0ZbNFE1MbshDFtgZQI/wNTpvI6ErzcmV1rtqhD9CbhcoB3M9jz643/oO58bK5Mnv
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0AeAABltHdg/5ldJa1aGQEBAQEBAQEBAQEBAQEBAQEBARIBAQEBAQEBAQEBAQFAgUEBAQEBAQELAYFSIy4Hd1o2MYgLA4U5iGsDmTyCUwNUCwEBAQ0BAR0LCgIEAQGBFgGDOQKBcwIlNwYOAgMBAQwBAQUBAQECAQYEcROFUA2GRAEBAQMBAQE4BgEBLAsBCwQCAQgOAwQBAQEdARAnCx0IAgQBDQUIgmqCVQMOIQEOoTYCih93gTSBAYIEAQEGhSQYghMDBoE5AYJ3ilwnHIFJQoETQ4JfPoJgAQGBYoNKgiuBTxpbagQUPwQMBANEKhNFChwbFBkCJ5AxIaoDCoMLnSaDTZEOjQ+DDhmGJR2JIIUankuEZQICAgIEBQIOAQEGgWokgVlwFTuCaVAXAg6OHzcYgyGFFIVFczgCBgoBAQMJfIlPLYIWAQE
X-IronPort-AV: E=Sophos;i="5.82,223,1613433600"; d="scan'208";a="875293834"
Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 15 Apr 2021 03:37:26 +0000
Received: from mail.cisco.com (xbe-rcd-003.cisco.com [173.37.102.18]) by rcdn-core-2.cisco.com (8.15.2/8.15.2) with ESMTPS id 13F3bQ8L022553 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=OK); Thu, 15 Apr 2021 03:37:26 GMT
Received: from xhs-rtp-001.cisco.com (64.101.210.228) by xbe-rcd-003.cisco.com (173.37.102.18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.2.792.3; Wed, 14 Apr 2021 22:37:26 -0500
Received: from xfe-rcd-005.cisco.com (173.37.227.253) by xhs-rtp-001.cisco.com (64.101.210.228) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Wed, 14 Apr 2021 23:37:25 -0400
Received: from NAM11-CO1-obe.outbound.protection.outlook.com (72.163.14.9) by xfe-rcd-005.cisco.com (173.37.227.253) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.3 via Frontend Transport; Wed, 14 Apr 2021 22:37:24 -0500
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=b+mi6eFs7eIxHuo7d3EFWWHMf1fACZkzRQPnYFb/wNUPoGQHjh6BUbKaX6gQ855xRTdhHr7I5GJc+4iYiFhM2fCvcj2MOh5pqOdWYRVwMfSPmeNDBd/9THa+sBMRIMDgX/q6rL7c/qOSvv0xRWW9Yr3qwLv+EZ6FR9jdiyQBwRsH5AfvnWWZ9E8v+8P/25nio6e0Ul5eumPQIJroqTZ4g7oJ+JJpgFxtC2Z/ZFPWflI/c19X9oM/QHmijSAiwgjwuOVc6707lgkD3WAyNkcec5Jfqaa5UDpndIqx1VK+a9Dt5qVXDz6B/msMFOjJ355wKpiq5g1LPTDvJ8KOsKkDNA==
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=hVqsok6uVdGFJwe1P89LrbibhK/CWzbVmLgEoS8pahI=; b=O4fS+1DwT/FYSXO80Px/oBfWShwNSpGhEHzyE56YaFQCrbDSx0+uynR9lIapGDoasJWDDV5T395E15LYSGE+8WkdppE4/+SeLTrYZYte4FKpKbkiTnHsm1TuNQ1pfG2x3OjqQGKnMskivfNnXcXY61WbCgw8cZllNGtdx7TNCihrsGS4OxqDLjpZiFsK+GyGIaGC8VfJyGYVGWQn/2BbVzkgA72NiQh8CCm0GtqnVupURz5hsHh3v+vHe8kgFq02qnl5GW1I6vyuyfJfklLMtKLRw3Yt0STgQPFisE/59Xpzyrudw3HlFRTPy5X9/obOCRPabzYz+aI8GsmkBOQsQQ==
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=hVqsok6uVdGFJwe1P89LrbibhK/CWzbVmLgEoS8pahI=; b=WRNr4QvQmE+HYOcABr1y8VgY+o2XdFOOeZrofi47qPBN883f5zC3o1uXHvcplw2BVVw84D2I8OJZksh7YfEgirag/xCM2zrvt0AHjbUcIRc+cEwMnTmgaOFkMn88X7PxiLxCZ5WQG9BWx+M1SvXZ12PhprcUWHtVWNxENSj6wus=
Received: from BL0PR11MB3202.namprd11.prod.outlook.com (2603:10b6:208:65::32) by MN2PR11MB4512.namprd11.prod.outlook.com (2603:10b6:208:18d::28) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4020.22; Thu, 15 Apr 2021 03:37:23 +0000
Received: from BL0PR11MB3202.namprd11.prod.outlook.com ([fe80::20d1:84e7:1636:dc8f]) by BL0PR11MB3202.namprd11.prod.outlook.com ([fe80::20d1:84e7:1636:dc8f%6]) with mapi id 15.20.4020.023; Thu, 15 Apr 2021 03:37:23 +0000
From: "Jakob Heitz (jheitz)" <jheitz@cisco.com>
To: Jeffrey Haas <jhaas@pfrc.org>, "Dongjie (Jimmy)" <jie.dong@huawei.com>
CC: "idr@ietf.org" <idr@ietf.org>
Thread-Topic: [Idr] [internet-drafts@ietf.org: I-D Action: draft-haas-flowspec-capability-bits-02.txt]
Thread-Index: AQHXLXls4c9PSdGr4USMoFAGvYibA6qxIN0AgAANFICAAvrpAIAAnNKAgAAvcsA=
Date: Thu, 15 Apr 2021 03:37:23 +0000
Message-ID: <BL0PR11MB3202A2A4CB44B853EC6BA0BEC04D9@BL0PR11MB3202.namprd11.prod.outlook.com>
References: <20210409201047.GA13742@pfrc.org> <4d862ff450b349e6bcdaf96bd4d09b99@huawei.com> <20210412175120.GA25856@pfrc.org> <8ab2391b8a8647d2a8319c71a140ccd5@huawei.com> <20210415004310.GA6652@pfrc.org>
In-Reply-To: <20210415004310.GA6652@pfrc.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: pfrc.org; dkim=none (message not signed) header.d=none;pfrc.org; dmarc=none action=none header.from=cisco.com;
x-originating-ip: [2601:647:5701:46e0:a9e3:e338:a265:f369]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 6ab0aa94-8cd6-4cb9-aa8e-08d8ffbfc834
x-ms-traffictypediagnostic: MN2PR11MB4512:
x-microsoft-antispam-prvs: <MN2PR11MB451277299D61C87F858FC080C04D9@MN2PR11MB4512.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: 93fhaPxRsTSzgD+zrQImZfoSV31YmtrZ4rtR9/ojs0kVJmR5IJpDEn88VpzMS42LMnYPJfxVL2OBvocVaxAk5WF7onD3c0jzZwTOKpkCyxu9bq8yGasv8CKwHtLtdymZ6o/tAegYYrhiHxx8y4phUZpHr6DsEh7zHycgW9EQs8PD6n5E2gmN5GxcvNuUkBnpCbTzaJ4OF5+zIw6WUNFFZucOTAqXJV773lU/6LUoaesX1RieZRETDkfiV/hYWWcQ/hALxCEonlrAO5F0VoN6o21vh/LoBJ+bFLUWYUJH5lSnxwdKkpHgfx0JuM3WHEicKgatFkUZsWtbUZF3776uDOyoZqu29rDAWjGJYWyO95qYGQvrWb8AklLIsBYH9G/saDD/0/YDQixdCvYEHW1IwRph7cf0jLT0KYpGz54B9PD649GHZEPMGBO4t7NUQWAuvwCylPGiF4BxdphWrUEIiiJ14U4bHwE1LWnBQZ/AfpC0Xn73+40KavbVJliPT8JYXp+k+SIgOAmvCamO4xf3HDV9+D9BoSi55ogJ3cM4o+66EZxiazcQ182cI7oVdMFNjgA91ycuJHrCwHPvWh0CI/EIB6tl6Jh5ZEg4pcj5vZicYYfpI73X+KQvy520ynaaG38km4iXnDWGDPD9V2OYFtbhDWixqnpM5D43bDlE1cPw8ACBejDNzytNUYeWtXba
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BL0PR11MB3202.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(39860400002)(366004)(136003)(376002)(346002)(396003)(38100700002)(8936002)(966005)(2906002)(122000001)(4326008)(66574015)(110136005)(86362001)(53546011)(8676002)(7696005)(478600001)(9686003)(5660300002)(55016002)(6506007)(83380400001)(66476007)(66556008)(66446008)(186003)(64756008)(76116006)(52536014)(66946007)(316002)(71200400001)(33656002); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata: 3wIzEiREQ8kEOO9cpSD9bq5WhpCyC+8DVVNnLuLZKShJQWVmPZ6cC/JFCxgn0/+sIQ0o5CPgLQtIPB1u2j0kpRmHm+BPQeDuhQjIKS8niiXXkpDwkCozgeGCZLmTgOvahp743rQcgsI7Q1EpIHv3tRn7jOqJph1CCk32ddk2hel66Q3+elscEX8RNBfDne3kyqIDm6BOmVQ7Y94YDH6PcTN8bwkZQt5hgMiKK4z3z9VStNQAEwDdn5G7/8Tlttume5rYtGT0RhzQOwz9F+IxVZ1Ngf5n09lbg96r5YiBNpTov49i9RafXjlPnHmqXmT+kBVhM6yjWGRCDyMg4Rk+xUmWsZIoWxPDy0AFPlVLu+kHePVCPd1lgvgDC8D+CdtjGm2/LCkox7eJd+KDHJLRm2OasV0n7dL62ZD+CVvuIHFduR/7Gqf6AxFRKaVtzuzzNeVSoYtfjjvDK33oprRgi/xLrUrA33FEm20XsgUsGoUvZonuR567MJjRSndPDb5ZkwG72S0KuNHuCbojkNOWpjPGWtmmeB/wBFfi/YE7rQMZhSY0PBfgax8Hs79mVfPT365e2oqbJFeIguti1WUjqdabO25YwoUCMgHnRKQcLE2ZX5gLl9pHMDTMIzwwsfrIa94QC/T44XCWtNbfFizoej48ZmlBAiI7HZjzAz20VnDsD5fTGFtUhj7A8c3yPqpYTqlYXXiv9sr8fgCwLXdCp6jG4POvtUnNCDsX150gMds19p0BFfLPgXNKj7N9Mtg3CenQtT+hkWYV/SNbJuH55tri6ELM4xiZVGgrsaGwwHwzIgkisuSyAMg0oyLPiFOsZ3gZRQ/5vj/bqi/GNKugaXV3Ma4KUQuE4lz1HxBBlEa4BSdmQTjEBCvm1SdBQr+TEvZ/4b/YDqfVWJMkI6z93wLTi9e2DFVAg+tJvcMV34+gXMGn7pPT+7jh8H3IwyFICYey9Dnwk6D+nNm6DY+OpctGBDWBww6C4xY2/XVDGI1vDCGXzV0ge/B6XJtE/WVNYY5CkKtQ6g4wO9gA4dMcx7ai8Z5LcvG2E9Hn9vLR1/b4kolDTj5YaBND4P2R12LGRWZRDb1hdaxhry9tcAniyhZOUxZVpHhFCj/D3SS3vjUv/rMYT5al133C2CcTZp7V9Ty/X3udNXC41fiX3Fg9S4dCWwU7BskjzwbqGbU+FtJP4Z5cg62L3ajzM1lyXvzq4zQ5uS8DQkdp8/2yESuDsIWWaAKARyWDneH70oaZet77Y28GHaWrEO3o0CptuTbuzFZI7PyPnLlxn2C0d+TutulXo0cMjufrfbuoy7/nnPNBerp8QsFE38WleOPZPAMIns7VDsbDuqypV+ZzY4PmQLIYJg/1z3boia9aFuFcyBIqbBkB/8L8oVNIryjtCKKE
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: BL0PR11MB3202.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 6ab0aa94-8cd6-4cb9-aa8e-08d8ffbfc834
X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Apr 2021 03:37:23.4716 (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: NVeldQd7/H8ZkLtBncKu+mpGYCJDzu2bUhXNnmvc1ydxXQkEPK//hSOjYWLaXjohfcecYQ60uijJ1KEkZyLXhg==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB4512
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.37.102.18, xbe-rcd-003.cisco.com
X-Outbound-Node: rcdn-core-2.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/dnAPgfD_eEdbb3cLVCYM9-kiAyM>
Subject: Re: [Idr] [internet-drafts@ietf.org: I-D Action: draft-haas-flowspec-capability-bits-02.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, 15 Apr 2021 03:37:32 -0000

I agree.
The capability is exchanged only with neighbors and thus is
not capable of informing the capabilities of all BGP speakers
in the network. A more capable network management method
is needed for that.

The BGP capability is only useful to avoid sending a flowspec
to a neighbor that it would consider as malformed.

Regards,
Jakob.

-----Original Message-----
From: Idr <idr-bounces@ietf.org> On Behalf Of Jeffrey Haas
Sent: Wednesday, April 14, 2021 5:43 PM
To: Dongjie (Jimmy) <jie.dong@huawei.com>
Cc: idr@ietf.org
Subject: Re: [Idr] [internet-drafts@ietf.org: I-D Action: draft-haas-flowspec-capability-bits-02.txt]

Jie,

On Wed, Apr 14, 2021 at 03:21:54PM +0000, Dongjie (Jimmy) wrote:
> > On Mon, Apr 12, 2021 at 05:04:32PM +0000, Dongjie (Jimmy) wrote:
> > > Hi Jeff, all,
> > >
> > > I've read the recent discussion and the updated version of this draft, here are
> > some thoughts and comments:
> > >
> > > I fully agree that incremental deployment of new flowspec components is
> > important, and it does not need to wait for Flowspec 2.0.
> > >
> > > Regarding a BGP flowspec component, there could be three different
> > capabilities:
> > >
> > > 1.	The capability of parsing and implementing the component as a filter
> > >
> > > 2.	The capability of parsing and propagating the component, but not for
> > local use
> > >
> > > 3.	The capability of propagating the component further even it is not parsed
> > >
> > > The first two capabilities are discussed in this thread and the updated draft,
> > and to me it makes sense to distinguish these two capabilities.
> > 
> > Operationally, how would you expect a BGP Speaker to differentiate these two
> > cases?
> 
> The assumption here is that not all the nodes are required to implement
> the filters (or some just don't want to), while they may be on the path of
> the flowspec rule propagation. If this is true, it may be useful for the
> operator to know the set of nodes with the first capability and the set of
> nodes with the second capability, although the capability of parsing and
> propagating is more relevant to this document. These two capabilities may
> be advertised using different mechanisms, as the first capability may be
> needed by nodes not directly peered. 

Understood.  My question is what should a BGP Speaker that has been told
that the adjacent BGP Speaker can parse a certain set of Flowspec components
but not use some of them do about it?  Is it strictly advisory?

If it's strictly advisory, I would advocate that we not worry about
publishing that part in BGP.  One motivation is that capability space is
still at somewhat of a premium without extended optional parameters.

A second motivation is there may be better mechanisms to publish the network
wide capabilities for using the filters.  I'll likely share a proposal in
the upcoming weeks.

> > The third case is unfortunately problematic right now.  Deployment
> > experience has shown implementations aren't willing to deal with fully
> > "opaque" NLRI.  We've had a number of outages resulting from parsing bugs
> > as it is.
> 
> I understand the problems with the "opaque" NLRI, while if the rule
> specified in the NLRI is not required (or not capable) to be implemented
> in data plane on a transit node, will it cause less harm to the network? 

My draft tries to make clear that any device that filters a rule, either
because it doesn't receive it because of lack of capability of an upstream
node, or lack of local ability, can have potential to result in
mis-forwarding.  Whether it does so or not will depend on the independence
of the rules.

If my use of "independence" is unclear, I'll share an example next round.

> > With flowspec v2, the primary obstacle toward opaque but still able to be
> > checked for NLRI high level syntactic correctness can be done.  We know this
> > is still problematic once you hit a node where the inner contents are validated
> > and found to be problematic, but at least in this case "treat as withdraw"
> > procedures are capable of being done.
> 
> Agree flowspec v2 can help with the syntax validation to some extent.
> While if the NLRI is considered malformed, the "treat as withdraw" error
> handling may not always work. 

I think lengths in structured BGP NLRI will likely give us a hybrid
situation.  

Consider an NLRI that has a known prefix length.
Consider that it has components that have individual sub-lengths that are
clear in the protocol.

It is possible that the length of the individual components summed together
are still a valid "length" from the top level (the prefix-length) from a
high level syntactic level, but individual components may be of invalid
length or syntax.  This is similar to the situation for path attributes.

In such a case, the NLRI is malformed, but may be of enough integrity to
properly handle as an ignore/discard.

The BGP-CAR proposal and perhaps some of the evpn NLRI error handling cases have
some similar overlap to this case.  (RFC 7606 tries to be too generic about
"typed NLRI" and I think got it somewhat wrong.)

-- Jeff

_______________________________________________
Idr mailing list
Idr@ietf.org
https://www.ietf.org/mailman/listinfo/idr