Re: [Idr] John Scudder's No Objection on draft-ietf-idr-bgp-flowspec-oid-13: (with COMMENT)

"Juan Alcaide (jalcaide)" <jalcaide@cisco.com> Sat, 15 May 2021 18:34 UTC

Return-Path: <jalcaide@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 9533C3A17A4; Sat, 15 May 2021 11:34:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.595
X-Spam-Level:
X-Spam-Status: No, score=-9.595 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_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, 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=KGlukRGp; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=WztpjBVi
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 Ac0qgDx9sU-m; Sat, 15 May 2021 11:34:39 -0700 (PDT)
Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E1BF63A1798; Sat, 15 May 2021 11:34:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=31608; q=dns/txt; s=iport; t=1621103679; x=1622313279; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=rPk/JXwuDZnX0Sg05nxelKvPTJ6ToNXQM6K6DW1O+4A=; b=KGlukRGp/WJjVAofCqaCujmusaM7WhByQ31PsL4AXn49947Wplnwme31 deP08sJM2A+nRdJbYpKbAFH+UiriErSPOmmcot54e1tqcU9ZwNPFEHfxg 0K1ncFM8oz66A+ofT79/eTTpnh4dZFzUgUsDabvlBlt+eYK0Ge4Ft7Gd9 I=;
X-IPAS-Result: A0CFAAD7EqBg/5ldJa1aGQEBAQEBAQEBAQEBAQEBAQEBARIBAQEBAQEBAQEBAQFAgVeBUyMuB3daNjEDCIQ8g0gDhTmIdQOBDYkxjymBQoERA1QLAQEBDQEBNQoCBAEBhE8CF4FdAiU4EwIEAQEBAQMCAwEBAQEFAQEFAQEBAgEGBHEThVANhkQBAQEDARoJBA0MAQE3AQQHBAIBCA4DBAEBAQICERUCAgIfERUICAIEDgUIgmqCVQMOIQEDC51TAoofen8zgQGCBgEBBgQEgUhBgzMNC4ITAwaBECoBgnqEDoZaJxyBSUSBFUOBX0o2PoIfQgICAYEWEgEMBgEJGhUoglg2gi2BWQIBDloGAQEsLQkEFA4QCQgICBQbKAYWDAEFExgSAgYaAwEUBQICBwYMDQYBBwMRkQkTgncBQpUUkF46WwqDFooCjXwEhVoRg1qLE4YihF+LT5dMiXCDIo9gDoRsAgICAgQFAg4BAQaBayNpWBEHcBU7gmlQFwIOjh8HBRYVgzmFFIVJcwI2AgYBCQEBAwl8iU4BJgeBBwEyXgEB
IronPort-PHdr: A9a23:kxJuiRP/rf1HVTZSxaAl6nflWUAX0o4cdiYX95wmk79UNKKu48eqM E/e4KBri1nEFcXe5ulfguXb+6bnRSQb4JmHvXxDFf4EVxIMhcgM2QB1BsmDBB75MfjrdyEgW sJPSAwt83SyK0MAHsH4ahXbqWGz6jhHHBL5OEJ1K+35F5SUgd6w0rW5+obYZENDgz/uCY4=
IronPort-HdrOrdr: A9a23:xZTN2qwaxPyeVo8RHjTgKrPx+eskLtp133Aq2lEZdPULSK2lfp GV8sjziyWatN9IYgBepTiBUJPwJk80hqQFn7X5Wo3SHTUO2VHYYr2KiLGD/9SOIVyEygcw79 YET0E6MqyNMbEYt7e73ODbKadb/DDvysnB7o2yowYPPGNXguNbnnpE422gYytLrXx9dOIE/e 2nl7N6TlSbCBAqR/X+IkNAc/nIptXNmp6jSwUBHQQb5A6Hii7twKLmEjCDty1uEA9n8PMHyy zoggb57qKsv7WQ0RnHzVLe6JxQhZ/I1sZDPsqRkcIYQw+cyDpAJb4RHoFqjgpF591H22xa1u UkZC1QZvib3kmhOl1dZyGdgzUIngxesEMKgmXo8EcL6faJNA7STfAx376wtnDimhYdVBYW6t MX44vRjeslMTrQ2Cv6/NTGTBdsiw69pmcji/caizhFXZIZc6I5l/1SwKp5KuZLIMvB0vFrLA CuNrCU2B9cSyLUU5kYhBgl/DWIZAVEIv6reDl3hiWl6UkfoJki9Tps+CU2pAZ2yHsSceg329 j5
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.82,303,1613433600"; d="scan'208";a="700804480"
Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 15 May 2021 18:34:37 +0000
Received: from mail.cisco.com (xbe-aln-006.cisco.com [173.36.7.21]) by rcdn-core-2.cisco.com (8.15.2/8.15.2) with ESMTPS id 14FIYbKK012880 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=OK); Sat, 15 May 2021 18:34:37 GMT
Received: from xhs-rtp-001.cisco.com (64.101.210.228) by xbe-aln-006.cisco.com (173.36.7.21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.2.792.3; Sat, 15 May 2021 13:34:36 -0500
Received: from xfe-rcd-003.cisco.com (173.37.227.251) by xhs-rtp-001.cisco.com (64.101.210.228) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Sat, 15 May 2021 14:34:35 -0400
Received: from NAM12-DM6-obe.outbound.protection.outlook.com (72.163.14.9) by xfe-rcd-003.cisco.com (173.37.227.251) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.3 via Frontend Transport; Sat, 15 May 2021 13:34:35 -0500
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=NRVgna4Io0juFkb70A41wkt4iRNjU3ew7Xwi5fgO9OuYLdLURBC0g3Pz2H7nIk5f8v8wJ3F0eqoWr79JD9ybQPxM0Dg42WoOs3HrUFmrsg914F07SpNIZf0LxvS7Bbq33hzIkbLiVigsBntc8fHsBkejOwjqnV8c2JYHJETaZJOMZ8KYEjTkSuhyU7l8flue+cq7RVwC4Ryw605l0z/K/cClwaNQ9vPUE2pprwm06p73Wz1nz0OdwtTjmpn4sV4PMFRXpMy7H0LSPixVN2kzGM2VAFfJAvIMk3xuoBO+c5fftRxgQm4NlKX68DfdBM/60h5ARVsmRdo19yqxi10o9Q==
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=rPk/JXwuDZnX0Sg05nxelKvPTJ6ToNXQM6K6DW1O+4A=; b=Joi5+nMWv09PBPCAilNtQbsNkKl/zEl5AA1ok6PyeqT7lf1VcHZdx9XXh5mUf8/eJzXQ06e82RHai+H/zw6FkYf+nWTB5I4NaJNmQ/Nh0suZHLD7qjlE8OXNyV8vQ1bCZpYCEbEEYGSiTc5F25Soy3Vu+5ftLd1nCrFUej6sfG9UqYso76JS6lD1BUE4Q0WkT8kDAIgO63AnYqwdj+XmWyCQlqFXHatVac3FGXUIsO6FuTikZMs8SSbW56fLJDXzz03uRX+XKfU/DobaGYJS0m/q/HxraJ3Cx7zF2I8AKhn7c+mGzKf0KEU85o68Moq41MROXoM7FWu4ma5fGKhGOg==
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=rPk/JXwuDZnX0Sg05nxelKvPTJ6ToNXQM6K6DW1O+4A=; b=WztpjBViY3Kuyg+AZqFiDcpfnClRx+na46X0ws07yTSFKFN5qCQVmwMUfg+UHKMEhvhp9mvand6yhCRT+mdiQybnpwLArrQ7BPdBRM4PFfphMzsfHGKQ1lMOVlMk0T4kUungK3KZN8FqieLISM4AC08APEM+uB6oHpwdJGfFGEI=
Received: from DM6PR11MB3194.namprd11.prod.outlook.com (2603:10b6:5:5c::25) by DM5PR11MB1483.namprd11.prod.outlook.com (2603:10b6:4:e::9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4129.28; Sat, 15 May 2021 18:34:33 +0000
Received: from DM6PR11MB3194.namprd11.prod.outlook.com ([fe80::e4e0:cf18:7be1:8019]) by DM6PR11MB3194.namprd11.prod.outlook.com ([fe80::e4e0:cf18:7be1:8019%7]) with mapi id 15.20.4129.031; Sat, 15 May 2021 18:34:33 +0000
From: "Juan Alcaide (jalcaide)" <jalcaide@cisco.com>
To: John Scudder <jgs@juniper.net>
CC: The IESG <iesg@ietf.org>, "draft-ietf-idr-bgp-flowspec-oid@ietf.org" <draft-ietf-idr-bgp-flowspec-oid@ietf.org>, "idr-chairs@ietf.org" <idr-chairs@ietf.org>, "idr@ietf.org" <idr@ietf.org>, Hares Susan <shares@ndzh.com>, "aretana.ietf@gmail.com" <aretana.ietf@gmail.com>, Lars Eggert <lars@eggert.org>, "David Smith (djsmith)" <djsmith@cisco.com>, Magnus Nyström <magnusn@gmail.com>
Thread-Topic: John Scudder's No Objection on draft-ietf-idr-bgp-flowspec-oid-13: (with COMMENT)
Thread-Index: AQHXQ3tJiP7jAt0U4UqyoDg/3TXRCKriDsNQgAFTtwCAAYgw0A==
Date: Sat, 15 May 2021 18:34:33 +0000
Message-ID: <DM6PR11MB3194BA315E52D59325830C00CD2F9@DM6PR11MB3194.namprd11.prod.outlook.com>
References: <162041746726.16037.6421894058933171338@ietfa.amsl.com> <DM6PR11MB3194EAEC2799AD9213E2B527CD519@DM6PR11MB3194.namprd11.prod.outlook.com> <3A5161A8-6187-4CB9-A796-7381EC598388@juniper.net>
In-Reply-To: <3A5161A8-6187-4CB9-A796-7381EC598388@juniper.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: juniper.net; dkim=none (message not signed) header.d=none;juniper.net; dmarc=none action=none header.from=cisco.com;
x-originating-ip: [83.38.90.229]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 69311a38-99d7-4e3f-117c-08d917d015fa
x-ms-traffictypediagnostic: DM5PR11MB1483:
x-ms-exchange-transport-forked: True
x-microsoft-antispam-prvs: <DM5PR11MB1483EE45E2ECA587CC053C08CD2F9@DM5PR11MB1483.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: JAKYlr9gm95jhT/jEFexeK4CWXcKzBiL/oGJRW1VU2JZZqSmNq6g5ZxivD8W31z/01VIvn1bdlWYw6O4IoWMsGQs68am8T3f2skDYLLoXxhBU5QJwZlFfF5fN6C6mnD+BDd/lEC/FN1FPv1Yn9dmJnrX9cD0d5nzkIsegEXXcWvBLeclnIgWyS1O7z1+90sx/4h9t1UxVHGBNbj0FB/NP1l95yiOHBtm4SC6q1ORzBAkVv3ty299yZp0QW9naiSDk0ID+kwtiGTf8FxZ+1QHSNQ8fTEyQHEOAuBS+x7O+wrjrfv8fSnmqeUjtFb/GIvWEgn85+rh4kkA8RJ7Z5yrEwkXBSFqIW2P0/ets1oHCGH1cGvo8Ide3rOj0+tJDnjkILEn9Juc7FLloJjRRy7N17EQv4oxN9navpWQPf2u3DRD1dYNbWQSbyz8cxqBN/gcyQG3zjYx6+MW7rCL3vvXtVz9a3RtXq1pbDfljhf4EjQzmEYtQGGKmIMnfJ69aHNMK/YnIIxMNYJL9zLF21X9DiRRMrrMBUFsYcSIIpuyxL6GR32HozwnrvG/L1elLCZoMdogkl6E5KUps/8XmwiO+QEqxzH3A+DsbgkjCSxXrED7ZxuJ5YobfCvaaDtZeC+qQ+tDVU4Dga0Lx9qta1IyZHi2WRBE4MLhvXT72YxrnQEm5QpfEzPOgKOqUIw2ecb5ai2AHwSZIrXJR6eD925RlVG3C+b3v/RW7HBtiw2mCCM3KEjaXyTiX5aPXxGSnYm6
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM6PR11MB3194.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(136003)(396003)(376002)(39860400002)(346002)(366004)(66946007)(4326008)(6916009)(71200400001)(122000001)(76116006)(30864003)(26005)(33656002)(478600001)(316002)(966005)(55016002)(66446008)(66556008)(64756008)(66574015)(38100700002)(54906003)(9686003)(8936002)(83380400001)(186003)(52536014)(2906002)(5660300002)(6506007)(18074004)(53546011)(8676002)(7696005)(66476007)(86362001)(579004); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata: w/w4kJrbhOrO6b3o8XdsfhjjaLp5VGJPqBTEZD3fMaZdS6EdRTOTkD4WXc2+rQuMSp+lAchttaydAabnlU/0NeDn2oFgl7qWwLTsNpZaGAw8QsiOUSNhwrcQ8uevhVoiaxKLHvC0yiyg0XiwvtzQz5nbxzpSpGFOrIn190+QaaZs99lLIomMvl29AwnelnNA7J1380i1bORSBkAl9x+zCQNZnYUoaY8u8Yi5O2sJiU2RO0UPBtn8/plYcxYHKUPfwR2TDlVXSfocyMwXyombMCOn1ZErlCw4+DI1sxzln8ououXI0+2Lhe7G1HAEPEx5jnHtvr9QhhcqhpBicvGc1ytwFIVMph5gEp5vwrf3TumS2PVNntgxGcASbLH6fGhH0QsoOoxvZLvfJeSxbR4KFOAFdNLMdOJAG+N6crrA72v8dknE0WNMpe3po1Wu5YtVlqoFwK2oEooANElxPtcaZaGb2jTiVHjWO7LNQ+Ov1sPVuaLZ8FtcPS0iPsF38zGYyJ/LbYQVTtE9xbv/O+tiU8Zac83oW00BXcSGTawfeMF2QYrnR/RQLa1ir3yDFVQs4WU3IfVuP25pAH8NcJuHoqbCzPfeUIf+rTx7kvtBl/bkl3EK1hdyAgdczwQ5rEMBgvryFQsRPDK3zAc8ZSCaNNAucK2jY7uPsX/R9kGpeH0M2u6liXm1+VgWOUdo5fp8AUnran4GzWR76qd3H/oaSEAu6tK1p1i9UesYfJfevYCAL5nObKBlPeTGl3ZU9fOSgoMDMyMgjrM7gwqh7fAdpGvCNLsID7wDUvghx11Ufi57vGALZGOShOSYP/FXmQigiHZ3VR3IWGwsC+pj3/2oX43pL+Ln+jkolX4AJ06SvFDcgDp1LX7oDje/OoYtL8zDFC9dQXq9BKoclrAYSbwopkTOxYwTXULjnVxBio/wt5iltsaBEyzddmVDO6setZYS1jVE1NpZN93xF+hO2L/YFo/xFALgeQUkkauzcFirsoWpbtNDSMxrbhpRiuZH/+Ledsxw4Jh9VNlUCrRYxuaYYyMbgYM4tt3wSDO4EyUZtZAK2I6RtAKZnm4pmnSS3SQc47uG68coUxDzscwtGSQ0qT2AiTWV9dd3G8LsTXxx98RT6y9Rp/OL3lQvlFfK50B71Mozyvfayks63nsgBoTzBApKwc/Dx4D7kNdIXgP/dgDZx+FJ+XSxmYFIonSBo+4UoE/GAo3NT60CZUyatUVB9I98TAevU2gHXbClRSER6e0GAsY3ASUDZ+5Q1bkqhsrQfKyhfKsNgIhX2vZitFey/ZgMocVOkDs1oZ0Hh8oCr24=
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: DM6PR11MB3194.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 69311a38-99d7-4e3f-117c-08d917d015fa
X-MS-Exchange-CrossTenant-originalarrivaltime: 15 May 2021 18:34:33.7573 (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: c44SDpob3xE98bELxxZwHVqaguLGpkoZ/LPBbacMGX/bqWv4iwJdE4VWOgN6heBFMighVSw1DfdzDonp/sktHw==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR11MB1483
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.36.7.21, xbe-aln-006.cisco.com
X-Outbound-Node: rcdn-core-2.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/1wQpluoKd-i3Y_TS0xS8sLMsspg>
X-Mailman-Approved-At: Sat, 15 May 2021 11:58:40 -0700
Subject: Re: [Idr] John Scudder's No Objection on draft-ietf-idr-bgp-flowspec-oid-13: (with COMMENT)
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: Sat, 15 May 2021 18:34:56 -0000

Thanks John

I'll incorporate your comments.

In particular:



I'll add a Terminology section. We are kind of redefining eBGP and iBGP for the purposes of this draft. It's not the same way it's used on other RFCs, but it 
certainly makes it more clear.

Great for pointing out to use 'local domain' instead of 'local autonomous system' (or just autonomous system). We shouldn't be using both things to refer to the same concept
I'll replace autonomous system all around. I'll still keep AS because it only refers to examples.


I'll add ', except as detailed below.' in the Security Section. I thought the idea of the security section was to summarize all security considerations (*even* if they were discussed previously), and then any extra ones.
Even if it was a slight RFC8955  oversight, it shouldn't be here since we are overwriting that RFC8955 section ;-)


This paragraph you mention 'last AS*es*' as a nit. But I think there is more to it [major]

     Comparing only the last ASes added is sufficient for eBGP learned
      Flow Specification NLRIs.  Requiring a full AS_PATH match would
      limit origination of inter-domain Flow Specifications to the
      origin AS of the best-match unicast route for the destination
      prefix embedded in the Flow Specification only.  As such, a full
      AS_PATH validity check may prevent transit ASes from originating
      inter-domain Flow Specifications, which is not desirable.

Do we really want to match only the last-AS, or as many ASes as we want?  The paragraph above in the explanation would seem to favor as many AS_PATHS as we can. Transit ASes
could still originate FS rules.

Ex:

Validate         Unicast: 100 101 102 103, FS: 100 101
Do not validate  Unicast: 100 101 102 103, FS: 100 102

-J


-----Original Message-----
From: John Scudder <jgs@juniper.net> 
Sent: Friday, May 14, 2021 9:10 PM
To: Juan Alcaide (jalcaide) <jalcaide@cisco.com>
Cc: The IESG <iesg@ietf.org>; draft-ietf-idr-bgp-flowspec-oid@ietf.org; idr-chairs@ietf.org; idr@ietf.org; Hares Susan <shares@ndzh.com>; aretana.ietf@gmail.com; Lars Eggert <lars@eggert.org>; David Smith (djsmith) <djsmith@cisco.com>; Magnus Nyström <magnusn@gmail.com>
Subject: Re: John Scudder's No Objection on draft-ietf-idr-bgp-flowspec-oid-13: (with COMMENT)

Hi Juan,

Thanks for your reply.

> On May 13, 2021, at 7:07 PM, Juan Alcaide (jalcaide) <jalcaide@cisco.com> wrote:
> 
> Hi John,
> 
> Thanks a lot for your detailed comments. Sorry, also I missed them before publishing -14. Some of the changes on -14 already address your concerns.

Great, thanks.

> I'll incorporate your comments. But some of them I'd like to discuss are:
> 
> #4
> 
> Your suggestion
> 
>      For clarity, the AS in the left-most position of the AS_PATH means
>      the AS that was most recently added to the AS_PATH.
> 
> I used AS_SEQUENCE on purpose. You are not receiving the route from the same confederation. And it would not apply to AS_SET.
> But rfc4271 uses directly AS_PATH. So it's fine to use AS_PATH even if it's not that specific?

It would be a protocol violation to receive an EBGP route with an AS_SET in the leftmost position, since the neighbor is required to add its own AS to an AS_SEQUENCE before sending you the update. However, it’s a good point regarding confederations. If we are being excruciatingly correct we have to account for at least two annoying details:

- In a confederation, the leftmost element could be an AS_CONFED_SEQUENCE
- An AS_PATH can, and occasionally does, contain more than a single AS_SEQUENCE

The second observation was what led to my earlier suggestion. Now that you’ve made your observation, I think maybe a simpler rewrite would cover both:

     For clarity, the AS in the left-most position of the AS_PATH means
     the AS that was last added to an AS_SEQUENCE.

(Changed “the AS_SEQUENCE” to “an AS_SEQUENCE”. You could also say “the left-most AS_SEQUENCE” but then it just moves the problem.) 

I’m not sure how helpful this is to an implementor standing alone, since it relies on the idea of recency which also isn’t defined, but it’s correct and I think there’s a wealth of other information that would help the implementor get it right. I don’t think lack of perfection here will, realistically, hurt implementability. IRL, as far as I know “leftmost” is well-understood by BGP implementors.

> #6
> 
> You didn't like:
> 
>      Using the new rule to validate a Flow Specification route received
>      from an External Border Gateway Protocol (eBGP) peer belonging to
>      the same local domain (in the case of a confederation) is out of
>      the scope of this document.  Note that although it's possible, its
>      utility is dubious.  Although it is conceivable that a router in
>      the same local domain (both iBGP and eBGP within the same local
>      domain) could send a rogue update, only eBGP (outside the local
>      domain) risk is considered within this document (in the same
>      spirit of the mentioned beforehand AS_PATH validation in
>      [RFC4271]).
> 
> 
> What about this rewrite:
> 
> "
> Using that same original AS_PATH validation rule for a route learned 
> from a confed-ebgp peer (i.e. a peer in another sub-AS within the same 
> local domain) is outside of the scope of this document. Note that 
> although it's possible, its utility is dubious, since that confed-ebgp 
> peer may be considered trusted.  Although it is conceivable that a router in the same local domain (both iBGP and eBGP within the same local domain) could send a rogue update, only eBGP (outside the local domain) risk is considered within this document. Note also that [RFC5065] does not mandate to enforce this AS_PATH validation rule for a route learned from a confed-ebgp peer.
> "
> 
> This paragraph was built as a part of trying to include and mix 
> toguether several review comments. But honestly I don't think it adds that much value. So I wouldn't mind to remove it.

That would be a simple fix! I wouldn’t object, although I don’t insist.

> I keep using 'local domain' just to specify that I am refering to either 1) a standalone AS  or 2 ) to a confederation of ASes. If you have a better way, I'll be happy to use it.

In looking back over the spec I do see you’ve supplied a definition of “local domain” in §4.1:

      In this context, a local domain includes the local AS or the local
      confederation [RFC5065]. 

That actually helps a lot, my bad for not noticing it the first time, sorry. But I think it should be made more obvious to the reader. How about adding a “terminology” or “definitions” section up front (some people place the RFC 2119 language in such a section as well, but I don’t have an opinion about that), and putting a few definitions there:

- "Local Domain” (so capitalized): defined as quoted above. Then whenever referring to local domain, use the capitalized form to make it clear you’re using your defined term.
- “EBGP” (or “eBGP” if you prefer): “BGP peering to a router not within the Local Domain” (or something like that) to make it clear that whenever you mention EBGP you mean real EBGP?
- “IBGP”: means both classic IBGP and any form of BGP peering with a router within the same confederation. 

With those definitions, I think I would be almost happy with the original paragraph. Here’s a suggested minor rewrite:

“Using the new rule to validate a Flow Specification route received from a peer belonging to the same Local Domain is out of the scope of this document. Note that although it’s possible, its utility is dubious. Although it is conceivable that a router in the same Local Domain could send a rogue update, only EBGP risk is considered within this document (in the same spirit as the aforementioned AS_PATH validation in [RFC4271]).”

If you decide you like this approach, I think you can also replace “local autonomous system” with “Local Domain” in §2.

Oh by the way, while I was writing this reply, I noticed this nit in §4.2:

      Comparing only the last ASes added is sufficient for eBGP learned

Shouldn’t that be “last AS added”, singular?
 
> #10.
> 
> Section 7 was rewritten in draft -14  using some of the points you also raised. Does it look Ok now?

Yes it does. Below I’ve included some editorial nits, but the content seems fine.

> Trying to make it clear the enforcement paragraph for both you, Lars, and Magnus, I would rewrite it like this, if nobody objects.
> 
> "
> If configuration (or other means beyond the scope of this document) 
> indicates that the peer is not a route server, that optional rule 
> SHOULD be enforced. If the indication is that the peer is not a route server or there is no conclusive indication, that optional rule SHOULD NOT be enforced.
> "

I think that option is fine. (I am also OK with what’s in -14.)

   This document updates the route feasibility validation procedures for
   Flow Specifications learned from iBGP peers and through route
   servers.  This change is in line with the procedures described in
   [RFC8955] and, thus, the security characteristics equivalent to the

Delete “the”, so “thus, security characteristics”.

   existing security properties of BGP unicast routing are maintained.

   The security considerations discussed in [RFC8955] apply to this
   specification as well.

   This document makes the original AS_PATH validation rule ([RFC4271]
   section 6.3) again optional (section 4.2) for Flow Specification
   Address Family (the rule is no longer mandatory as it was specified

Suggest “as had been specified”.

   by [RFC8955]).  If that original rule is not enforced for Flow
   Specification it may introduce some new security risks.  A peer (or a
   client of a route server peer) in AS X could advertise a rogue Flow
   Specification route whose first AS in AS_PATH was Y (assume Y is the
   first AS in the AS_PATH of the best-match unicast route).  This risk
   is impossible to prevent if the Flow Specification route is received
   from a route server peer.  If that peer is known for a fact not to be
   a route server, that optional rule SHOULD be enforced for Flow
   Specification routes.  Note that identifying those peers that are
   route servers may suppose an operational challenge.  If the condition

“Suppose” -> “pose”

   of the peer is unknown, the rule SHOULD not be enforced.

   A route server itself may be in a good position to enforce the
   AS_PATH validation rule described in the previous paragraph.  If a
   route server knowns it's not peering with any other route server, it
   can enforce the AS_PATH validation rule across all its peers.  If, in
   addition to that, the route server is trusted, the security threat
   described above disappears.

   BGP updates learned from iBGP peers are considered trusted, so the
   Traffic Flow Specifications contained in BGP updates are also
   considered trusted.  Therefore, it is not required to validate that
   the originator of an intra-domain Traffic Flow Specification matches
   the originator of the best-match unicast route for the destination
   prefix embedded in that Flow Specification.  Note that this
   trustworthy consideration is not absolute and the new possibility

“Trustworthy” -> “trustworthiness”

   than an iBGP speaker could send a rogue Flow Specification is
   introduced.

   The changes in Section 4.1 don't affect the validation procedures for
   eBGP-learned routes.

> #OTHER
> 
> Nobody complained, so not sure if I'm over thinking it. But this 
> doesn't seem 100% correct
> 
> "
>   This document updates the route feasibility validation procedures for
>   Flow Specifications learned from iBGP peers and through route
>   servers.  This change is in line with the procedures described in
>   [RFC8955] and, thus, the security characteristics equivalent to the
>   existing security properties of BGP unicast routing are maintained.
> "
> 
> Aren't we introducing a bit more of a risk than unicast routing, because of the AS_PATH validation rule? (as stated in " If that original rule is not enforced for Flow
>   Specification it may introduce some new security risks")

I guess you’re right. You could probably make the paragraph even more correct by adding “, except as detailed below” to the end of the sentence? I do think you cover that topic pretty well in the third paragraph, and in particular this:

                 If that peer is known for a fact not to be
   a route server, that optional rule SHOULD be enforced for Flow
   Specification routes. 

> When rfc8955 says "   As long as Flow Specifications are restricted to match the corresponding unicast routing paths for the relevant prefixes
>   (Section 6)," it's not making reference to AS_PATH validation rule. Shouldn't it?

Well RFC 8955 is already published :-) but since that text refers to Section 6, and since §6 says

   BGP implementations MUST also enforce that the AS_PATH attribute of a
   route received via the External Border Gateway Protocol (eBGP)
   contains the neighboring AS in the left-most position of the AS_PATH
   attribute.  While this rule is optional in the BGP specification, it
   becomes necessary to enforce it here for security reasons.

it seems to me as though it has, indeed, made reference to the AS_PATH validation rule. No?

Regards,

—John


> 
> -J
> 
> 
> 
> 
> 
> -----Original Message-----
> From: John Scudder via Datatracker <noreply@ietf.org>
> Sent: Friday, May 7, 2021 9:58 PM
> To: The IESG <iesg@ietf.org>
> Cc: draft-ietf-idr-bgp-flowspec-oid@ietf.org; idr-chairs@ietf.org; 
> idr@ietf.org; Susan Hares <shares@ndzh.com>; aretana.ietf@gmail.com; 
> shares@ndzh.com
> Subject: John Scudder's No Objection on 
> draft-ietf-idr-bgp-flowspec-oid-13: (with COMMENT)
> 
> John Scudder has entered the following ballot position for
> draft-ietf-idr-bgp-flowspec-oid-13: No Objection
> 
> When responding, please keep the subject line intact and reply to all 
> email addresses included in the To and CC lines. (Feel free to cut 
> this introductory paragraph, however.)
> 
> 
> Please refer to 
> https://urldefense.com/v3/__https://www.ietf.org/iesg/statement/discus
> s-criteria.html__;!!NEt6yMaO-gk!QLCeaGKX3jpp4rLrE_k8iSduOkCXEr6Pdyj6AX
> wU8zsm-hg6xFZnm-1skqoj2w$ for more information about DISCUSS and 
> COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-iet
> f-idr-bgp-flowspec-oid/__;!!NEt6yMaO-gk!QLCeaGKX3jpp4rLrE_k8iSduOkCXEr
> 6Pdyj6AXwU8zsm-hg6xFZnm-1uegg6yg$
> 
> 
> 
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> Thanks for this document, I'm glad to see it finally close to publication. I have a few comments I hope will help improve it, below.
> 
> 1. Section 2
> 
>   [RFC8955] defines a BGP NLRI [RFC4271] that can be used to 
> distribute
> 
> RFC 4271 is the right citation for “BGP” but for “BGP NLRI” other than IPv4 unicast you want RFC 4760.
> 
>   the Flow Specification.  The aim is making sure that only speakers 
> on
> 
> making -> to make
> 
>   originated in any location within the same autonomous system than 
> the
> 
> than -> as
> 
>   Flow Specification received from an iBGP peer, it could be possible
>   to disseminate such Flow Specification NLRIs directly from the
> 
> “It could be possible”? Or “it would be necessary”?
> 
>   validated when received by RR and R1.  Sometimes the Flow
>   Specification needs to be originated on AS1.  ASBR1 could originate
> 
> on -> within
> 
> 2. Section 4.1
> 
>          1.  This condition SHOULD be enabled by default (it may be
>              disabled by explicit configuration as described on the
>              next list item (b.2.1))..  an empty AS_PATH.
> 
> Looks as though “an empty AS_PATH” is a cut-n-paste error that should be deleted?
> 
>          3.  As an extension to this rule, a given non-empty AS_PATHs
> 
> AS_PATHs -> AS_PATH (agreement in number)
> 
>              AS_CONFED_SET segments), MAY be validated by policy.  A
> 
> I think “permitted” would be clearer than “validated”.
> 
>      Also, policy may be useful to validate a specific set of non-empty
>      AS_PATHs (b.2.3).  For example, it could validate a Flow
>      Specification whose AS_PATH contains only an AS_SEQUENCE with ASes
>      that are all known to belong to the same administrative domain.
> 
> Same point, I suggest “permit”.
> 
> 3. Section 4.2
> 
>   This rule prevents the exchange of BGP Flow Specification NLRIs at
>   Internet exchanges with BGP route servers [RFC7947].
> 
> Since it may not be common knowledge that route servers don’t insert their own AS number, I suggest a change something like this, for clarity:
> 
>   This rule prevents the exchange of BGP Flow Specification NLRIs at
>   Internet exchanges with BGP route servers, which by design don’t insert
>   their own AS number into the AS_PATH  ([RFC7947] Section 2.2.2.1).
> 
> 4. Section 4.2
> 
>      For clarity, the AS in the left-most position of the AS_PATH means
>      the AS that was last added to the AS_SEQUENCE.
> 
> I suggest changing “last” to “most recently”. This is just personal preference, though. I also suggest changing “AS_SEQUENCE” somehow, probably to “AS_PATH”.
> The reason for this is there could be more than one AS_SEQUENCE in the AS_PATH so the definite article isn’t quite correct. There is however only one AS_PATH, and you can make the change without loss of generality or correctness. So, the full suggested rewrite is:
> 
>      For clarity, the AS in the left-most position of the AS_PATH means
>      the AS that was most recently added to the AS_PATH.
> 
> 5. Section 4.2
> 
>      Specifications.  This is a security BGP threat, but out of the
> 
> “Security BGP threat” -> “security threat” (or “BGP security threat” 
> if you
> prefer)
> 
> 6. Section 4.2
> 
>      Using the new rule to validate a Flow Specification route received
>      from an External Border Gateway Protocol (eBGP) peer belonging to
>      the same local domain (in the case of a confederation) is out of
>      the scope of this document.  Note that although it's possible, its
>      utility is dubious.  Although it is conceivable that an router in
>      the same local domain (both iBGP and eBGP within the same local
>      domain) could send a rogue update, only eBGP (outside the local
>      domain) risk is considered within this document (in the same
>      spirit of the mentioned beforehand AS_PATH validation in
>      [RFC4271]).
> 
> I’m having a hard time understanding this paragraph. This is at least partly due to the use of “local domain“, which isn’t a well-defined term of art. You could try something like “under the same administration“? But, even if I make that change in my head as I read the paragraph, I still don’t get your point.
> :-(
> 
> Is the whole paragraph strictly about confederations, and what you’re talking about is a BGP session between a router in one member-AS and a router in another member-AS of the confederation? If that’s it, I can probably propose some new text.
> 
> Also, “an router” -> “a router”.
> 
> Also, you should cite RFC 5065 when you mention confederations.
> 
> 7. Section 5
> 
>   its best-match unicast route) are learned from the same peer accross
> 
> accross-> across
> 
> 8. Section 5
> 
>      Consider the validation procedure preceding this document.  The
> 
> I think what you mean here is “consider the validation procedure 
> defined in RFC 8955“. If that’s correct, I suggest saying it that way. 
> (If that’s not correct, what did you mean?)
> 
> 9. Section 7
> 
>   thus maintain security characteristics equivalent to the existing
> 
> Maintain -> maintains
> 
> 10. Section 7
> 
>   The original AS_PATH validation rule ([RFC4271] section 6.3) becomes
>   hereby optional (section 4.2).
> 
> I don’t think you’re actually updating RFC 4271, are you? The way you’ve written this makes it sound as though you are. You’re relaxing the rule in RFC 8955, but as you point out in section 4.2, RFC 4271 makes AS_PATH neighbor AS insertion enforcement optional to begin with:
> 
>   If the UPDATE message is received from an external peer, the local
>   system MAY check whether the leftmost (with respect to the position
>   of octets in the protocol message) AS in the AS_PATH attribute is
>   equal to the autonomous system number of the peer that sent the
>   message.  If the check determines this is not the case, the Error
>   Subcode MUST be set to Malformed AS_PATH.
> 
> Maybe you could rewrite something like this: “As per section 4.2, it is becomes optional to enforce that the AS_PATH attribute of a route received via the External Border Gateway Protocol (eBGP) contains the neighboring AS in the leftmost position of the AS_PATH attribute. Then we continue:
> 
>             If that original rule is actually not
>   enforced it may introduce some security risks.  A peer (or a client
>   of a route server peer) in AS X could advertise a rogue Flow
>   Specification route whose first AS in AS_PATH was Y (assume Y is the
>   first AS in the AS_PATH of the best-match unicast route).  This risk
>   is impossible to prevent if the Flow Specification route is received
>   from a route server peer.
> 
> I think you’ve missed out on the opportunity to point out that the 
> risk can also be mitigated if the route server itself enforces the 
> optional rule of RFC
> 4271 section 6.3.. I think it’s fair to say that at an exchange point, the administrator of the route server enjoys more trust then the administrators of other routers at the exchange point.
> 
>               If that peer is known for a fact not to be
>   a route server, that optional rule SHOULD be enforced for Flow
>   Specification routes.
> 
> It may be necessary to say a little more about how you would get this 
> knowledge about the peer not being a route server. Possibly a rewrite 
> could be something
> like: "Unless configuration (or other means beyond the scope of this document) indicates that the peer is a route server, that optional rule SHOULD be enforced for Flow Specification routes from EBGP peers."
> 
> 11. Section 7
> 
>   absolute and the new possibility than an iBGP speaker could send a
> 
> Than -> that
> 
> 
>