Re: [Idr] Choice of Large vs. Extended Community for Route Leaks Solution

"Sriram, Kotikalapudi (Fed)" <kotikalapudi.sriram@nist.gov> Wed, 31 March 2021 17:16 UTC

Return-Path: <kotikalapudi.sriram@nist.gov>
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 9D1F63A2EEB; Wed, 31 Mar 2021 10:16:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.102
X-Spam-Level:
X-Spam-Status: No, score=-2.102 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FROM_GOV_DKIM_AU=-0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H2=-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=nist.gov
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 6995BdFOP5lx; Wed, 31 Mar 2021 10:16:50 -0700 (PDT)
Received: from GCC02-BL0-obe.outbound.protection.outlook.com (mail-bl2gcc02on2131.outbound.protection.outlook.com [40.107.89.131]) (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 643513A2EEC; Wed, 31 Mar 2021 10:16:50 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Iw2fuyqj+ckI5gAsBihkmSWP5E3yEnsR6X67jl3ZnY5IQxawaH/GcMSHfGNqtePClA4Oz1mQyt6hVnGLR8GOT8uJDnYFntq73+HTy9xO/fmILSVGQYjlZs357FRQSmzgffa1bYKo2j72bDRP60+dLrq4RjTY8pVgNJw9TP3D0kfMGz88BJqFV3PIy9MylZiUe+8baO4xTJM7zoH8rP75RwvAwbHHLCQeK32V/OP+7hdo+g0TVnT1k8JyQ2LloqmcUzQTJQ0N30drSLDEFuQHyNimaenoTrMh4VOVXNMEn6XfsZ9zqS65QuYH9eybzFFOBisxCePBjbe/cNFKmSsXsg==
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=lW/YBzEWl8eUuCyHZMkrTkMPbjhyjKLndBnNnAGEFww=; b=fIYPn4AdXKVghrB9YrfqY5MQHqQFGBRX7sB9pGJ7WDn6lutT69UaH2DAt5T2mReQcYbhFyE9u4L7s+7BI26XBmOc/zpQGZOiobNhXivxyO2Yx4pE/LKGsVU3k5Y8ye2v2taOH1984UjAb5dOcht1j1Eky24Ub0o2WW/3tJfyuLodjHvQ6W/3zAuGDM7HyUCJiww8tGW87medplBZTZgGSDBOKxAZ+c7KjzLpugb774Wrdk7/Zp+3b7FOg3mMTOluX2Vr/6y4zQ2eIHcOSGXB0v7fTS9bE18QZvupE6g29Iq//H8NnL4Fk45iJWcea++5cOGSyHH+VlnMU5iLAr/yEQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=nist.gov; dmarc=pass action=none header.from=nist.gov; dkim=pass header.d=nist.gov; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nist.gov; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=lW/YBzEWl8eUuCyHZMkrTkMPbjhyjKLndBnNnAGEFww=; b=JNbgMkQbK1VgmKIsfm5/ivYGiCJDLCy9dYa9+iD05/7aTb/5Z0PxmTzdcKhBnpguzm1pAIlc4O0VHlKX2ecMNeQErB3evW2wweXFneG/w+9RmvltZqBjGpGxFeI9htfC2zS3PqqVULmH0ObMykxB1YrHabY1qWU+/DU8q18mOO0=
Received: from SA1PR09MB8142.namprd09.prod.outlook.com (2603:10b6:806:171::8) by SA0PR09MB7243.namprd09.prod.outlook.com (2603:10b6:806:a9::24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3999.26; Wed, 31 Mar 2021 17:16:47 +0000
Received: from SA1PR09MB8142.namprd09.prod.outlook.com ([fe80::54a1:82da:6cd9:a9b3]) by SA1PR09MB8142.namprd09.prod.outlook.com ([fe80::54a1:82da:6cd9:a9b3%7]) with mapi id 15.20.3977.033; Wed, 31 Mar 2021 17:16:47 +0000
From: "Sriram, Kotikalapudi (Fed)" <kotikalapudi.sriram@nist.gov>
To: Jeffrey Haas <jhaas@pfrc.org>
CC: Susan Hares <shares@ndzh.com>, "idr@ietf.org" <idr@ietf.org>, "grow@ietf.org" <grow@ietf.org>, "draft-heitz-idr-wklc@ietf.org" <draft-heitz-idr-wklc@ietf.org>
Thread-Topic: [Idr] Choice of Large vs. Extended Community for Route Leaks Solution
Thread-Index: AQHXJjlK5mSz8dfqZEmidVsO6NqPaKqeRUIAgAABhvw=
Date: Wed, 31 Mar 2021 17:16:47 +0000
Message-ID: <SA1PR09MB8142C40CC942F7CF7BD05EDF847C9@SA1PR09MB8142.namprd09.prod.outlook.com>
References: <SA1PR09MB814269138AEE1567CEED703B847C9@SA1PR09MB8142.namprd09.prod.outlook.com>, <20210331161358.GI24667@pfrc.org>
In-Reply-To: <20210331161358.GI24667@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=nist.gov;
x-originating-ip: [129.6.223.204]
x-ms-publictraffictype: Email
x-ms-office365-filtering-ht: Tenant
x-ms-office365-filtering-correlation-id: 3d02bdf6-71a6-406d-874a-08d8f468c404
x-ms-traffictypediagnostic: SA0PR09MB7243:
x-microsoft-antispam-prvs: <SA0PR09MB7243CE4502472EDE1E72A946847C9@SA0PR09MB7243.namprd09.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: 3wjIjg7AB69ZP0Junt2+ugOKFL5tHDvToDl22YK94uJ7+cwjalXcsQZRlAlyLdjs7Z0cx5/SjUODEUEcd+wg2dkqatEsszgKGg2Owjg7wSmwPBxzB2sFNrUrvdWrVjZYxPBq37Y/5mw9VZpYugZBbmRyMOoqTVeU6nW4ZM6DKgElo0e9NeMUTRK7KE9sDri1XXAkjrJtFUxwP0Q3Q3DX7Blh/B8d5eYJixfB+C9YeFZoRT0vstPNTIgfXttKSHofj3+vD3FMJ8Na3m0J1ctYxi83fYpcy73qmDOr9QTul0i1yQFB/rtgDLHT2gnC+VVrdM3034S3aVTrobYXukXmJqR9PP2QWq7JyMB2G8/CCCPPnwBHJgaRM/GzPDjiHwXPHcnd+VJJDuGTNOdlVfDhVFbKYoT51fcntheyunYaZcBxLNZ+oIoIbXdR7ydHtkXczE9Xf0WhUucA2xwl1Ir12xmpI9hsnji/akM8Zw4+X6eHxbgZ8iRlcxL87awMVNNtOECIfEhy/YJRcCIvh4Q+hKUwfdY2Zh0nnREncczUTwgZ2HUUUIKLnnP9Kymswi+8sKfAi6gJ3edKleHgzqhr5o6Uj8QObzQLDY/ndFcOft/IZvs0QTl82GfRuinmOzoYi9febf8I3sHEX8AEcBR3DUyBSOefbMxS43Bq1yqmcu8u+lkDjOK3rRrHU00RjKaxH3qBFQ5Y0ChfHiZHpRwlc5gC/Hc8FFJGUye3jryOdkY=
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:SA1PR09MB8142.namprd09.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(86362001)(9686003)(66946007)(66476007)(26005)(66446008)(64756008)(66556008)(76116006)(91956017)(8676002)(55016002)(8936002)(2906002)(4326008)(52536014)(186003)(54906003)(6916009)(498600001)(6506007)(53546011)(38100700001)(5660300002)(7696005)(33656002)(83380400001)(966005)(71200400001); DIR:OUT; SFP:1102;
x-ms-exchange-antispam-messagedata: =?iso-8859-1?Q?Lm1bL1EonaucJRA2Use3t1ZZlBgBQlfXq1cGJ6ju+8KKznZP5CFSmAEq+j?= =?iso-8859-1?Q?MIcAtAZsUvQBXsXTPKu7oPR5PnhDtoOhD9ildvPSMijwr89SQOk2TOdT5z?= =?iso-8859-1?Q?6+dYZTDNyl8TxWAiZP0tEpXVWjJO/wlTxHUtnj0Q0+Q5yHwZ1ctWGLgvAi?= =?iso-8859-1?Q?SRnjC8JXHmY3XV8q6e3aX05L97jmfjEs803lcXh5Wmvl3BN+Wg+u5CT2v5?= =?iso-8859-1?Q?Ek57uHIiEl72GjhV2+LG4NPtrH2I08fFx9xQHdFNfodNw0ayMxSRoICGXF?= =?iso-8859-1?Q?iGD5l+niKp9e0Vvn322ewW4f02XeQDW1n5lQ16cgDjcRDno8+2zFegoHPR?= =?iso-8859-1?Q?ZmldC5ictrz2unXw9czbNz0O24V5NQuKMrRbU+9+lOUIAWIgx696BuYZPv?= =?iso-8859-1?Q?1myw3eFd/jb774A2W+53Ow9Iiq+mTD0+hsUznuldB6AvJGFZx8ucjWUcVN?= =?iso-8859-1?Q?BlUtMKL+44LmmAKyy4rmv6V3EGSdIvXbMJI6j95LAYUD8Vjk3suYowCj6m?= =?iso-8859-1?Q?jbmZc0X7ALqIqiq6ogpYdJPhjLUQx/DZGQVFVq1DmYknw4uBDvaiJDMoot?= =?iso-8859-1?Q?jBYfc5rte4bmo+TAmPeSr2LRSyAa2MrrXfqX2ewJFKEgdhxeEf678qshQb?= =?iso-8859-1?Q?K8BSMKbzxOk8dl27l9V5497n77WwN4MZF86EE5xI7rVUfiURDynrm2xhtw?= =?iso-8859-1?Q?5x/2aX+9MuBA+qlgKW02PNKLRjj+xC/coMi0xXBOykT4xq01dfibDaeG2u?= =?iso-8859-1?Q?UZhhzv48qoOeQKrOdj1X6LinmAS4AiQaRN+qo/MDeXYxmjVGEJxmdYkChB?= =?iso-8859-1?Q?OVVALd5oPmq/OwMtgfv4ltvqY6e5Wn+QvNIL2b6q9VdQrNx/u0irDk6Xhj?= =?iso-8859-1?Q?IC+3Q+jUebP2W7zwTbkYqUpunaTPfsOUXJRvLwaSoyGNti1N9c1XQF74Pk?= =?iso-8859-1?Q?bGYp7sDL31JGh0l3TWCfOvwfWPefYub8Vwwz/PxI36StJ5LSGiDnvRcw1v?= =?iso-8859-1?Q?3nhrq1bUi1R0Cd2FG5+pU8kzw9rfyWV5tNtEMZG+e6nLP8jF58hp+aMMC7?= =?iso-8859-1?Q?Ir2Dm715h//xdaZ91WgEhcW1sNqJ18ogfS1d6F02nN3qXh9Dsm0Hwi9Lo8?= =?iso-8859-1?Q?8eRJaWoCE+4M92cvhw23ZFk4vTSyZCKD84stzD39c5sv/Sn6t81Q4/KryM?= =?iso-8859-1?Q?yNeo0rDFDOk140r5Vg3/l11vAlHu/1v9+rWwaS34mEtSJX1LpO/cUstP0Y?= =?iso-8859-1?Q?e6Cge+dVOhRdSKef7QEA9ApMiS+9cvaNjD/PHKzgysffaTDs1v5zMueFAu?= =?iso-8859-1?Q?oW0or/5VLW6yUqG7Y7ddHl4E4ZlJ/2D+zli3wCpbotN/plY=3D?=
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: nist.gov
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: SA1PR09MB8142.namprd09.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 3d02bdf6-71a6-406d-874a-08d8f468c404
X-MS-Exchange-CrossTenant-originalarrivaltime: 31 Mar 2021 17:16:47.3381 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA0PR09MB7243
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/aV_G7aodIYYPsf-aS87YhQBMyV0>
Subject: Re: [Idr] Choice of Large vs. Extended Community for Route Leaks Solution
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, 31 Mar 2021 17:16:56 -0000

Jeff,

Thank you for the response. My comments inline.

>You can thus just get a FCFS extended community from a
>transitive space TODAY and
>it'd probably do most of what you want.  One of the beneficial properties
>that extended communities have is the transitivity is at least understood
>and well deployed.

I was hoping for a confirmation of that nature. So, that is good to hear.

>That said, there's still no guarantee that some operator may choose to just delete them all at an ASBR.

Yep. It is not a perfect world. But are you suggesting that no community-based approach (EC or LC or ?) is worth pursuing? 

>...the headache you're going through is trying to avoid the work of creating a new attribute. 

There is already a separate draft in IDR that has passed WGLC, and it uses a new transitive BGP Path Attribute 'Only to Customer (OTC)':
https://tools.ietf.org/html/draft-ietf-idr-bgp-open-policy-15
We view that as a longer-term solution, while the EC/LC-based approach is meant to be deployed quickly.  

>A discussion I'd suggest is that we've had a need for a "BGP routing
>security" attribute where we can put these various proposals:
>- It's not a victim of existing community practices.
>- Policy might still interact with it, but the baseline maintenance
  expectations can be set for it.
>- It can be extensible so new components can be added incrementally.

In the above, are you suggesting BGP Path Attribute or a new type of Community that comes with transitivity guarantees?

Sriram
________________________________________
From: Jeffrey Haas <jhaas@pfrc.org>
Sent: Wednesday, March 31, 2021 12:13 PM
To: Sriram, Kotikalapudi (Fed)
Cc: Susan Hares; idr@ietf.org; grow@ietf.org; draft-heitz-idr-wklc@ietf.org
Subject: Re: [Idr] Choice of Large vs. Extended Community for Route Leaks Solution

Sriram,

(Clearly I'm not Sue...)

Extending the observation I've just made to Gyan, the headache you're going
through is trying to avoid the work of creating a new attribute.  A result
of this is a lot of work trying to proscriptively change how people operate
their networks for more general features.

Extended communities have functionally behaved as more of a protocol control
mechanism in their general history.  They already have behaviors that permit
them to be selectively transitive or non-transitive across ASes.
Operationally, they MAY be stripped by policy, but sanitization practices
for them are significantly less codified than RFC 1997 communities.  You can
thus just get a FCFS extended community from a transitive space TODAY and
it'd probably do most of what you want.  One of the beneficial properties
that extended communities have is the transitivity is at least understood
and well deployed.

That said, there's still no guarantee that some operator may choose to just
delete them all at an ASBR.

A discussion I'd suggest is that we've had a need for a "BGP routing
security" attribute where we can put these various proposals:
- It's not a victim of existing community practices.
- Policy might still interact with it, but the baseline maintenance
  expectations can be set for it.
- It can be extensible so new components can be added incrementally.

While I understand a motivation for putting this in communities is "faster
deployment", take the other example from the life of large communities: when
there's sufficient interest, the feature will show up pretty fast.

-- Jeff (the best time to plant a tree is ten years ago. the second best
time is now...)