Re: [Idr] One Admin Domain
"UTTARO, JAMES" <ju1738@att.com> Thu, 08 April 2021 11:14 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 236E93A1252; Thu, 8 Apr 2021 04:14:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.817
X-Spam-Level:
X-Spam-Status: No, score=-1.817 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 (1024-bit key) header.d=att.onmicrosoft.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 o4JpL922V_g3; Thu, 8 Apr 2021 04:14:00 -0700 (PDT)
Received: from mx0a-00191d01.pphosted.com (mx0a-00191d01.pphosted.com [67.231.149.140]) (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 064B13A1251; Thu, 8 Apr 2021 04:13:59 -0700 (PDT)
Received: from pps.filterd (m0049295.ppops.net [127.0.0.1]) by m0049295.ppops.net-00191d01. (8.16.0.43/8.16.0.43) with SMTP id 138BDw7X020778; Thu, 8 Apr 2021 07:13:59 -0400
Received: from alpi155.enaf.aldc.att.com (sbcsmtp7.sbc.com [144.160.229.24]) by m0049295.ppops.net-00191d01. with ESMTP id 37sfa9fxfr-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 08 Apr 2021 07:13:57 -0400
Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id 138BDkgl012062; Thu, 8 Apr 2021 07:13:46 -0400
Received: from zlp27129.vci.att.com (zlp27129.vci.att.com [135.66.87.42]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id 138BDeen012015 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 8 Apr 2021 07:13:40 -0400
Received: from zlp27129.vci.att.com (zlp27129.vci.att.com [127.0.0.1]) by zlp27129.vci.att.com (Service) with ESMTP id 40681401657F; Thu, 8 Apr 2021 11:13:40 +0000 (GMT)
Received: from MISOUT7MSGEX2DC.ITServices.sbc.com (unknown [135.66.184.194]) by zlp27129.vci.att.com (Service) with ESMTP id F26E94014CA0; Thu, 8 Apr 2021 11:13:39 +0000 (GMT)
Received: from MISOUT7MSGED1AA.ITServices.sbc.com (135.66.184.195) by MISOUT7MSGEX2DC.ITServices.sbc.com (135.66.184.194) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2176.2; Thu, 8 Apr 2021 07:13:39 -0400
Received: from MISOUT7MSGETA01.tmg.ad.att.com (144.160.12.221) by MISOUT7MSGED1AA.ITServices.sbc.com (135.66.184.195) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2242.4 via Frontend Transport; Thu, 8 Apr 2021 07:13:39 -0400
Received: from NAM10-BN7-obe.outbound.protection.outlook.com (104.47.70.103) by edgeso1.exch.att.com (144.160.12.221) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2242.4; Thu, 8 Apr 2021 07:13:38 -0400
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=lVqW4uDBtJhULC6jlmVN41Y2nNXISNXvmZu59KNLktKLclEVyZ2c34ikbcy/0uT4MviHmejASOuhcKL/r3e43U/2APRyTcmGxOzHv3BXSg+cKwupzHOWNimrkZ8BcVtJE6T2L7ntjk88fz37/yeO0YA2efQI4INvgYLMc4GWW/A9qhy5tI76cSef4sfT70zxPbWHtPuf4H1bNxXMDubD3jT7uimFDWzBG5HaNky2lC2QZX9OFOi+jilNhqicMUT0FEQIRChNcBaSJw9dZqrJ5N38l2uTtJ1fMrXMysNnbwQy3B2wU0h5T0KYTCdIxhWUkwzXz8Ww19aBICtFLlWphg==
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=R+hiDEPKxxbeM5h0iYlwPHEiXnMJAlx/5WloqJq3Lnw=; b=cCTsKtlEgiAhlfufp3AzTH0Txf9rfLhlMpG3DRvjg9myNeK76zce/0qPpVqy0YyKoFtXsOkB5RNV7nkidu0O1bXBUnGOMLIOJSiIf9EbT5NxuuOXv2oNxoC2wRvEvffpwbVCx0ZVQF8aD001lrqVgsbO+YqtUqKYoEnicSCV4wEuHRTTH+WV7cWRIhoEYM3WeZPWPrLailnhL/EA+F813zGzeSDE7rOehMY/4DjZvKK0nnwhR4FqFCCEKCCjmftps2JaGcDZCKPgY4mQZIaiC6NRX+BbkFibw/CmpZfQxGeiozjJ1gh66xqcYDPd4Z9IU7ZVpAMXIczIOAvKikaaRw==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=att.com; dmarc=pass action=none header.from=att.com; dkim=pass header.d=att.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=att.onmicrosoft.com; s=selector2-att-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=R+hiDEPKxxbeM5h0iYlwPHEiXnMJAlx/5WloqJq3Lnw=; b=w+g703Frby1qijQj6gOmqT/ey57BFVPFU4bivCEAFuogsJCzGCOXTvNJQGiSF0BdV89P7StXl2uhA2HnyYXUoUkRJxVG2PffQK9eqRPT/Rn5to3y8Wxol1rx2+GcWAY/Gbs603ku3N2jtxnMo8Jhstm4OcE5Vw/gX24ZaeJkFJs=
Received: from MW4PR02MB7394.namprd02.prod.outlook.com (2603:10b6:303:7d::7) by MW2PR02MB3834.namprd02.prod.outlook.com (2603:10b6:907:3::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3999.27; Thu, 8 Apr 2021 11:13:37 +0000
Received: from MW4PR02MB7394.namprd02.prod.outlook.com ([fe80::3cae:f9b8:8000:78cb]) by MW4PR02MB7394.namprd02.prod.outlook.com ([fe80::3cae:f9b8:8000:78cb%5]) with mapi id 15.20.4020.018; Thu, 8 Apr 2021 11:13:37 +0000
From: "UTTARO, JAMES" <ju1738@att.com>
To: Robert Raszuk <robert@raszuk.net>, "Jakob Heitz (jheitz)" <jheitz=40cisco.com@dmarc.ietf.org>
CC: "idr@ietf. org" <idr@ietf.org>
Thread-Topic: [Idr] One Admin Domain
Thread-Index: Adcr9hZmlKm2YwrFRIW5ehKVUp4yTwAVB4OAAAbpKNA=
Date: Thu, 08 Apr 2021 11:13:37 +0000
Message-ID: <MW4PR02MB739455B379DB7E397CB69740C6749@MW4PR02MB7394.namprd02.prod.outlook.com>
References: <BYAPR11MB32078DF8E3EE49F3248742C7C0759@BYAPR11MB3207.namprd11.prod.outlook.com> <CAOj+MMGHHLmmVxMdnQrCZDXpqCBdehNF=w88jgOW+hzL1HSz+Q@mail.gmail.com>
In-Reply-To: <CAOj+MMGHHLmmVxMdnQrCZDXpqCBdehNF=w88jgOW+hzL1HSz+Q@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
authentication-results: raszuk.net; dkim=none (message not signed) header.d=none;raszuk.net; dmarc=none action=none header.from=att.com;
x-originating-ip: [72.229.64.230]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 1b5e73bf-d4a9-4f1b-c25b-08d8fa7f5b7e
x-ms-traffictypediagnostic: MW2PR02MB3834:
x-microsoft-antispam-prvs: <MW2PR02MB3834344A28B8C3CBF661860DC6749@MW2PR02MB3834.namprd02.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:7219;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: svcGPyarokuKgv9y4WU7Xc3dEv9aIrfIrmc2apN5fnhQsWB0+EKsxeqItmXDKsY1l0mwLjw6Au1Dmu1nT/t7d46q9kqq72zLMpDAZhFA/bnUuNmoFknhMGBwplZslim+W7HMOglxHIFsFRgfnjNt3Q7c7mBBpHSzMpHyi9o13XZy9GUyrb6CcGuKsPq8RUXGGqvakpmcmH49ibhJ6soZBwWqQJ86Alk8YZsHZ0rOK0Ck6uwpWB+1A0lgHZf/g5JEI7g7JJAfSx3P9fCOYsRKEBiJsxbUibyTMnSCx+D9ei1JSCIxQPhwaVyJtU/yF1VSqZxeqoC8xoADtycvNq0hZyCaWG9QgmJZK6bLQAj0Z09WRg2XrjaDbPSyC9Neir4vqQl253EH+aDowR0xviBGpjZ8Uuv5CBpzRljSt/WUm0ekz51oUlPIchCkThRRolJM1PpsaldCXvaMi6t3zgDMZUhH2NbODEFytRVswFSfVgSibbF5W70zNUV5WQPvh7hFTqM+iK76jbRKE5QW/1D9T8XpskfqnQvQAtbULEDQHn097mv2rz7d3KBMEhjb7hsslcCn9c10pVr+CIEyoBHznXgN5fr49vRoMO40ad1ooOxUUwUZs9pbpySjkSJvVWPAWt8nmKiB22UrfYGJxjkXfEeKByHmEahiGH/i0/MQ5qMn3n2NWpJq8gDKuFhk7NNdC9bHLwNI+ebK87ybNn52mt/7PgYL2gx93MkLA8XKMSg=
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MW4PR02MB7394.namprd02.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(376002)(366004)(396003)(39860400002)(136003)(346002)(5660300002)(8676002)(33656002)(71200400001)(6506007)(2906002)(66574015)(83380400001)(4326008)(64756008)(66616009)(66476007)(76116006)(316002)(66556008)(110136005)(86362001)(26005)(66946007)(52536014)(966005)(38100700001)(166002)(9686003)(55016002)(99936003)(8936002)(82202003)(186003)(66446008)(478600001)(53546011)(7696005); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata: A5VZn1WZSqUQypaHUbz8FIaSnBy0H5BkiDnqH+E3gxMh/1VnHWi1gE6cr9cwMN8GFwxOXup3VV6byeJaY7yaiMOlIyM/UcP0Y30FejpkVQzik4iCdpUitkqqsBLjJooJlRN+Os3mdxbVqwEAhekDi5AfbpG85kzDiIo5pBdBrF2jE7zejcnWPwB5h3nC1BDW52ZW6jyLSI0X24H1JdI5qs9mnua+EqjWA4Uc3t/uwU8XvT0uB5CqVBBzFnR1hOKuKelbZfLjZIj95eu8h9/+uZAYO/3+Iso+aKgdh9NnkEmS1UyhlR6x+OPH8ZmkzVRYMBFwk2Ydt6PtbkQSztncnAJild+xdXVKWzivRJNvu0vrQ310qicy+QCqM0xLgSMH0GJQZH4M3OX1f1IoLQjIXlg/VETLxpp8+xx6DVylF9LDZ5RewaP+gEarKz89zejMBI3cJ6H8So8Bf0CI1iQGxrnvD7NdxqGZQs/dCzWFluWqDtx5ROMLSEjToB33GHjlEsT4q7EBgAvD0WIbVW/YpNIC/yqklm4V82HH2oMgBVmBoKKXejAkxz0TfOGp/jMyHACG1QYAi7Yild0WIrhZRHUUefTo9y+ndHtmf5/GNeQ1+2J2sntzqY6OQWZc+5Tz2iQ+V6brHzO+pWaYUdL0a6ufx3n6bXoVgYeARLz2GY3VuI69FR0t9iJZye9oeGlK5S299eesGmYIL3DBZjzcGXxvY2u21zyBsj5ZD/MnCD+YKxhL/Oe9rIxewJPghWK4qiUCn+Ug65Rty4mZk8hYFq4UgwkiVXmwoj8CEpPW/e8OjB4lXPdcXCTSb/5ZVxFd09jtKCYUgEGYuH/1StUYO5QJc+3mLhSw/xSsUlHsoBjrrGn3zek8K9epEkHeH0hxz6h34PjtEDt58pgGxtq5GPtTsfdgmTHfPp5nomWjYGGqZUFIUCFogZRHdLSHJnW4amDQfj7dVVZ645IZimznylb5s4FVdOi4QsV/W0lFWh1+GidtON/68ivVbvhHuDBdrdMIMhmPtNpICiCNEkzAXfMjkTiUDBhasT/UNIfB/21GeRUWNpD5SRrmp02HXWrfvKKPUURhS4fIYMFCcQcrjrqCc5Touve+eO6HE97VHiFJyH/MLCUW+qaJf6COYzsKx18ypUMPxEQ7ejrPTxczgLKXhHGodcTQl68eCmxIEF+kuCBPpgpTShUwnc5oumII/H2hK/KhUOuBdvxwuOZ60KiYARQ7OgQRLTcvu4lMmXL4kwrCyl3ATHDMB1MmYuPgPjGOWSXn06QrKvPSsUy4EmxmnPyK5R5ZuUZxnfEXyGI4w9TwPa4eC4mZw7MGySAN
x-ms-exchange-transport-forked: True
Content-Type: multipart/mixed; boundary="_004_MW4PR02MB739455B379DB7E397CB69740C6749MW4PR02MB7394namp_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: MW4PR02MB7394.namprd02.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 1b5e73bf-d4a9-4f1b-c25b-08d8fa7f5b7e
X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Apr 2021 11:13:37.3400 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: e741d71c-c6b6-47b0-803c-0f3b32b07556
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: J6Y+snpAOIUXMNA0mA/6Lu7wVFkV6T6rWtfH44YfYHJFI6LNCuxLibi98c+fpcwe
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MW2PR02MB3834
X-OriginatorOrg: att.com
X-TM-SNTS-SMTP: 0A84DE6C6469784728BBAB4CDF7E32869884F5168D7E4CF6F21CC1DCCF94C6982
X-Proofpoint-GUID: QlWuQdHkr1020uKiXyjWs7t2l2Euwc6T
X-Proofpoint-ORIG-GUID: QlWuQdHkr1020uKiXyjWs7t2l2Euwc6T
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.391, 18.0.761 definitions=2021-04-08_02:2021-04-08, 2021-04-08 signatures=0
X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 phishscore=0 impostorscore=0 clxscore=1015 priorityscore=1501 lowpriorityscore=0 malwarescore=0 bulkscore=0 mlxscore=0 suspectscore=0 mlxlogscore=999 spamscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2104060000 definitions=main-2104080077
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/jmBwcm3RYdC8TVVU3C0cab2YYUU>
Subject: Re: [Idr] One Admin Domain
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, 08 Apr 2021 11:14:06 -0000
The two instantiations of this draft vary in approach. The first “draft-pmohapat-ide-oad-ebgp-00.txt” introduces the notion of an OAD-EBGP peer and revises procedures specific to path attributes i.e LP, AIGP etc.. Introducing a new paradigm “OAD” changes the scope of an administrative domain and corresponding eBGP peering specifications in term of path attributes. The second introduces an attr-set stack to correlate with path attributes set at different points throughout a topology CE<->CE. This is an incremental approach that does not modify the underlying specifications. At the time my goal was to insulate the customer and simplify operations to provide a seamless solution across AS boundaries. The thinking on the first draft was more revolutionary, the second was to solve a specific need. That being said in today’s world BGP is used across so many fields of use that an incremental solution to solve a specific need is insufficient. Network construction i.e LU and it’s derivatives, network configuration i.e flowspec, kompella, network telemetry i.e BGP LS etc… all require consistent behavior across an OAD. IMO the attached draft is a good place to start the discussion. Thanks, Jim Uttaro From: Robert Raszuk <robert@raszuk.net> Sent: Thursday, April 08, 2021 3:39 AM To: Jakob Heitz (jheitz) <jheitz=40cisco.com@dmarc.ietf.org> Cc: UTTARO, JAMES <ju1738@att.com>; idr@ietf. org <idr@ietf.org> Subject: Re: [Idr] One Admin Domain > That draft looks fine. Was it ever submitted? I can't find it in a search. https://tools.ietf.org/html/draft-uttaro-idr-oad-01<https://urldefense.com/v3/__https:/tools.ietf.org/html/draft-uttaro-idr-oad-01__;!!BhdT!zfO4c4vsPgfDrkW_tTrxxo8w5CHckexSKjc5de6FWSuMw6Fda_uqsgNK99zIrWs$> r. On Wed, Apr 7, 2021 at 11:55 PM Jakob Heitz (jheitz) <jheitz=40cisco.com@dmarc.ietf.org<mailto:40cisco.com@dmarc.ietf.org>> wrote: Jim, That draft looks fine. Was it ever submitted? I can't find it in a search. I would add a mechanism to reduce the AS_PATH length. When sending out of the OAD, replace the sequence of ASNs in the OAD by a single configured master ASN. If a route is received by a speaker in any AS in the OAD from a speaker not in the OAD, then the master ASN in the AS_PATH counts as a loop. Regards, Jakob. -----Original Message----- From: Idr <idr-bounces@ietf.org<mailto:idr-bounces@ietf.org>> On Behalf Of UTTARO, JAMES Sent: Wednesday, April 7, 2021 6:43 AM To: Jeffrey Haas <jhaas@pfrc.org<mailto:jhaas@pfrc.org>>; Robert Raszuk <robert@raszuk.net<mailto:robert@raszuk.net>> Cc: idr@ietf. org <idr@ietf.org<mailto:idr@ietf.org>>; Susan Hares <shares@ndzh.com<mailto:shares@ndzh.com>> Subject: Re: [Idr] WG adoption for draft-haas-flowspec-capability-bits - 3/30 to 4/13 " I don't believe we're likely to come up with a simple answer to BGP capability domains soon. That said, operators in a single administrative domain at least can figure this out themselves because they're the ones configuring it" This discussion illustrates that a single administrative domain spanning multiple ASes should be addressed. Pradosh, John Scudder and I began identifying how an OAD ( One Administrative Domain ) should behave in terms of an eBGP and OAD-eBGP learned paths. ( See Attached ). As an example if we offering RFC 1998 feature to a customer whose VPN spans multiple AS domains requires that the operator preserve or reset ( default ) the LP. The customer may want to scope LP to a given AS or have it apply across an OAD. As operators we have figured out how to create a somewhat seamless reachability/forwarding domain upon which services can be overlaid. That being said it maybe time to re-look at the scope of an AS vis-a-vis Admin domain including capabilities on a router, AS and OAD level.. Thanks, Jim Uttaro -----Original Message----- From: Idr <idr-bounces@ietf.org<mailto:idr-bounces@ietf.org>> On Behalf Of Jeffrey Haas Sent: Wednesday, April 07, 2021 9:25 AM To: Robert Raszuk <robert@raszuk.net<mailto:robert@raszuk.net>> Cc: idr@ietf. org <idr@ietf.org<mailto:idr@ietf.org>>; Susan Hares <shares@ndzh.com<mailto:shares@ndzh.com>> Subject: Re: [Idr] WG adoption for draft-haas-flowspec-capability-bits - 3/30 to 4/13 Robert, I think you're mixing some of the points together. On Wed, Apr 07, 2021 at 12:29:21PM +0200, Robert Raszuk wrote: > I have a question on how practical this proposal is. > > Fundamental problem with today's BGP capabilities is that the information > is only known to the peer. > > So if I inject flowspec rule from behind the RR the RR will suppress some > updates but: > > * sender will have no clue about it > * any other flow spec BGP speaker which supports request filtering down the > BGP path will never get the chance to receive and apply the filter. This is explicitly acknowledged in section 5. It's also indistinguishable from policy. > Both are IMHO bad. The latter is in fact directly against flowspec spirit > to apply filtering as close to the src even if hops on the way are not > capable of doing so. > > So I am yet to be convinced this proposal is useful. > > Today as a general rule if a router does not support an extension received > via flowspec it just does not apply it but still can happily propagate the > update down the road. Not a single BGP flowspec implementation implemented the "opaque" property in RFC 5575. Not one. And it was the strong motivation to remove that text in RFC 8955. This may change in flowspec v2 where we likely will make the NLRI proper type-length-value rather than implied length as it is currently done. How well the argument to filter unsupported components stands once we're to something like flowspec v2 will be the longer question. For such scenarios, once we're no longer concerned about propagation characteristics of the NLRI, it's quite reasoanble for a route reflector to carry NLRI with filtering components it doesn't understand - but edge devices may not want it. But in that scenario, perhaps it's simply better for edge devices to accept it and simply not install it. > I think what we have here on the table is an illustration about the growing > need for domain wide (or set of domains under the same admin) capability > distribution such that all BGP speakers could advertise their > capabilities to interested parties. A bit broader than flowspec, but could > be useful here. At the day job, we talk about the "flooding domain" of new features that are gated on their capabilities. BGP doesn't provide an explicit concept for this, but it's become a protocol intrinsic behavior. Unless you configure a capability between two devices, it does't gain the ability to use the feature. A contiguous set of devices using those capabilities becomes that domain. That domain may, or may not, have strong overlap with one or more ASes under the control of one or more parties. For many BGP features, knowing what those domain boundaries are isn't much of a problem. Flowspec implementations with disjoint capabilities is a place where it could be problematic. (Again, see section 5.) --- I don't believe we're likely to come up with a simple answer to BGP capability domains soon. That said, operators in a single administrative domain at least can figure this out themselves because they're the ones configuring it. Right now, we are unable to safely deploy new flowspec features. Even when you have disjoint flooding domains, if your flowspec rules are independent, you can gain benefit. So, short term for flowspec v1, I think there's benefit for this feature. -- Jeff _______________________________________________ Idr mailing list Idr@ietf.org<mailto:Idr@ietf.org> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/idr__;!!BhdT!zKnvUXaBTauH415pLQgguhjbJ69dkTpI04OgwY3aoSSiPV4IGBB2u-MqG68$<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/idr__;!!BhdT!zKnvUXaBTauH415pLQgguhjbJ69dkTpI04OgwY3aoSSiPV4IGBB2u-MqG68$> _______________________________________________ Idr mailing list Idr@ietf.org<mailto:Idr@ietf.org> https://www.ietf.org/mailman/listinfo/idr<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/idr__;!!BhdT!zfO4c4vsPgfDrkW_tTrxxo8w5CHckexSKjc5de6FWSuMw6Fda_uqsgNKqM9XzPc$>
- [Idr] One Admin Domain Jakob Heitz (jheitz)
- Re: [Idr] One Admin Domain Robert Raszuk
- Re: [Idr] One Admin Domain UTTARO, JAMES