[Idr] Returning draft-ietf-idr-rfc5575bis to WG, new 2 week discussion period
John Scudder <jgs@juniper.net> Thu, 13 June 2019 17:42 UTC
Return-Path: <jgs@juniper.net>
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 F036E1201A3; Thu, 13 Jun 2019 10:42:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.71
X-Spam-Level:
X-Spam-Status: No, score=-2.71 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=juniper.net
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 bfpuOpVX0xnJ; Thu, 13 Jun 2019 10:42:49 -0700 (PDT)
Received: from mx0a-00273201.pphosted.com (mx0a-00273201.pphosted.com [208.84.65.16]) (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 2EFEB120164; Thu, 13 Jun 2019 10:42:49 -0700 (PDT)
Received: from pps.filterd (m0108156.ppops.net [127.0.0.1]) by mx0a-00273201.pphosted.com (8.16.0.27/8.16.0.27) with SMTP id x5DHcpBv008400; Thu, 13 Jun 2019 10:42:48 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=from : to : subject : date : message-id : content-type : content-id : content-transfer-encoding : mime-version; s=PPS1017; bh=eYBEy1eP+0YLdw9qYAwDp+Y4PQ/zXeDt64LsSKCuUas=; b=nRfN3FiMSwDcR85wkh15h5lYnDQQVbxtZ9DKRLaHBp2JNwMZdUICqn8tM9WcX9tHB+i2 vLUb5j0uuubxuL5FvNsJX4wrl0GxPOhk3CbnHj8F8UdB5oozmrOk6nU2iznsjXurtLjn Vcgq3feBLiZHBONT6+CGWWN/eQvhXaFhaBWwn6LhljUma5+J7okUgSVyEFz+1dlLHwXl wP1pO+riSn0J0kLGOrFZhQkFTqDnpeJbk0fmhlnpK3cNVnMv86qrXO7XjOcDa94nt5H7 fAHetDI37CBdiv7QC1LJVwzzu/cQfG1s4HZ0Mx55mtDec9vYrvFBhmrhvVlv8NmoWipW ww==
Received: from nam03-co1-obe.outbound.protection.outlook.com (mail-co1nam03lp2053.outbound.protection.outlook.com [104.47.40.53]) by mx0a-00273201.pphosted.com with ESMTP id 2t3t1k83qq-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Thu, 13 Jun 2019 10:42:48 -0700
Received: from DM6PR05MB4714.namprd05.prod.outlook.com (20.176.109.215) by DM6PR05MB5433.namprd05.prod.outlook.com (20.176.121.154) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2008.5; Thu, 13 Jun 2019 17:42:47 +0000
Received: from DM6PR05MB4714.namprd05.prod.outlook.com ([fe80::1549:ffd0:8373:4593]) by DM6PR05MB4714.namprd05.prod.outlook.com ([fe80::1549:ffd0:8373:4593%3]) with mapi id 15.20.2008.006; Thu, 13 Jun 2019 17:42:47 +0000
From: John Scudder <jgs@juniper.net>
To: "idr@ietf. org" <idr@ietf.org>, "draft-ietf-idr-rfc5575bis@ietf.org" <draft-ietf-idr-rfc5575bis@ietf.org>
Thread-Topic: Returning draft-ietf-idr-rfc5575bis to WG, new 2 week discussion period
Thread-Index: AQHVIg9pNG+/JhSk20+S9cOVhMWvGg==
Date: Thu, 13 Jun 2019 17:42:46 +0000
Message-ID: <A68BF050-9846-4E14-918D-297548E078A2@juniper.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [162.225.191.79]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 9347e2ba-68f1-4cac-7864-08d6f0268c2c
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(4618075)(2017052603328)(7193020); SRVR:DM6PR05MB5433;
x-ms-traffictypediagnostic: DM6PR05MB5433:
x-microsoft-antispam-prvs: <DM6PR05MB5433057E7122668223D79F79AAEF0@DM6PR05MB5433.namprd05.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 0067A8BA2A
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(376002)(39860400002)(136003)(396003)(346002)(366004)(189003)(199004)(6506007)(316002)(33656002)(102836004)(6486002)(6436002)(99286004)(2906002)(86362001)(66066001)(36756003)(73956011)(186003)(110136005)(71190400001)(71200400001)(2501003)(76116006)(68736007)(14444005)(66476007)(66556008)(66446008)(14454004)(64756008)(486006)(5660300002)(2616005)(476003)(26005)(478600001)(305945005)(8676002)(53936002)(256004)(66946007)(7736002)(25786009)(81156014)(6116002)(3846002)(8936002)(6512007)(81166006)(450100002); DIR:OUT; SFP:1102; SCL:1; SRVR:DM6PR05MB5433; H:DM6PR05MB4714.namprd05.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1;
received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: Ax7SI6SjjfJYW/UrYeEkVGK/M2CdOqf4MeXOEBY+g+tjiC5+LcMcJSf73twCbkZ7QXWYfLMoWWkiVQt82j9ITtyTXQuvt357EyRRMqjtsi0r8IHcguTIs4m/e9XTHA0ZTzh/DKFlxFTUbmVMIdCzGHZ1qzNTm/HYiDJ6nqaWvHWI8vksUtrrSeY0Rtxf03RM5rjTvcZcAR5ttizIJR4OeH/fRK560FldGsrtJL7oQNI5phmKH391exUMdGxF9OqUDWuPaGQQ2Ujb2bIsjjscA3AAnE4FD9J6M/Ep4eaOAgi5wunhgKVimUlvtdRZyiRtM1rDM2Q9uBt4s+iRQ/2is3pwpwE+eWNXNxRzxH+JE07T4f5AYMDwrorcd9oJpDqy2lmbF2BXVSW3ooSR8DevwHa5nWSqdHgmSDl2Aqy8XKU=
Content-Type: text/plain; charset="us-ascii"
Content-ID: <8189C4B0CB3A0A44B8F1348F695CD0C0@namprd05.prod.outlook.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-Network-Message-Id: 9347e2ba-68f1-4cac-7864-08d6f0268c2c
X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Jun 2019 17:42:46.9382 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: jgs@juniper.net
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR05MB5433
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-06-13_12:, , signatures=0
X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1906130129
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/VTuYf23Qzw5Z22EwBt8AFsj-H1g>
Subject: [Idr] Returning draft-ietf-idr-rfc5575bis to WG, new 2 week discussion period
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, 13 Jun 2019 17:42:51 -0000
Hi Authors and WG, I just had it brought to my attention that RFC 5575 and draft-ietf-idr-rfc5575bis both are underspecified with regard to the validation procedures. The problem is what to do if a flow-spec NLRI doesn't contain a destination prefix component. Section 4.2 makes it clear that destination prefix is optional, so it's valid for it not to be present. But the first set of validation steps in section 6 are written in terms of the destination prefix, without acknowledging it might not be there. This leaves a gap for an interoperability problem, where some implementations might choose to consider validation to have succeeded if the destination prefix component isn't present, and others might consider it to have failed. To fix this ambiguity I'd like to suggest the following change. The summary is we add a new rule (a), renumber the old (a) and (b), and add a note following. OLD: A Flow Specification NLRI must be validated such that it is considered feasible if and only if: a) The originator of the Flow Specification matches the originator of the best-match unicast route for the destination prefix embedded in the Flow Specification. b) There are no more specific unicast routes, when compared with the flow destination prefix, that has been received from a different neighboring AS than the best-match unicast route, which has been determined in step a). NEW: A Flow Specification NLRI must be validated such that it is considered feasible if and only if: a) A destination prefix component is embedded in the Flow Specification. b) The originator of the Flow Specification matches the originator of the best-match unicast route for the destination prefix embedded in the Flow Specification. c) There are no more specific unicast routes, when compared with the flow destination prefix, that has been received from a different neighboring AS than the best-match unicast route, which has been determined in step b). Rule a) MAY be relaxed by configuration, permitting Flow Specifications that include no destination prefix component. If such is the case, rules b) and c) are moot and MUST be disregarded. We need the MAY clause since 4.2 does say destination prefix is optional, and also because an operator might actually want to permit this under some circumstances, particularly if the route is internally sourced. I'll also point out that another way according to the proposed rule set to have a flow-spec that matches every packet is to actually put /0 in the destination prefix, then you don't need the optional configuration mentioned in the MAY clause (you do need to accept default for validation to succeed, but that's inherent in flow-spec's design). The draft has already passed WGLC and been sent to the IESG. But given that it's always easier to correct problems sooner rather than later, I've just pulled it back to the WG. I'm hoping we can have quick consensus on what to do -- - Adopt the fix I've suggested, - Adopt a different fix, - Determine that no fix is needed. We could also let the IESG resolve this but it doesn't seem like good WG hygiene. I'd like to keep the discussion tightly scoped to just the minimum necessary to clarify section 6. Let's have the traditional two week window for discussion, to end by June 28. Thanks, --John
- [Idr] Returning draft-ietf-idr-rfc5575bis to WG, … John Scudder
- Re: [Idr] Returning draft-ietf-idr-rfc5575bis to … Robert Raszuk
- Re: [Idr] Returning draft-ietf-idr-rfc5575bis to … Christoph Loibl
- Re: [Idr] Returning draft-ietf-idr-rfc5575bis to … Jeffrey Haas
- Re: [Idr] Returning draft-ietf-idr-rfc5575bis to … Jeffrey Haas
- Re: [Idr] Returning draft-ietf-idr-rfc5575bis to … Robert Raszuk
- Re: [Idr] Returning draft-ietf-idr-rfc5575bis to … Christoph Loibl
- Re: [Idr] Returning draft-ietf-idr-rfc5575bis to … Jeffrey Haas
- Re: [Idr] Returning draft-ietf-idr-rfc5575bis to … Robert Raszuk
- Re: [Idr] Returning draft-ietf-idr-rfc5575bis to … Jeffrey Haas
- Re: [Idr] Returning draft-ietf-idr-rfc5575bis to … Robert Raszuk
- Re: [Idr] Returning draft-ietf-idr-rfc5575bis to … Christoph Loibl
- Re: [Idr] Returning draft-ietf-idr-rfc5575bis to … John Scudder
- Re: [Idr] Returning draft-ietf-idr-rfc5575bis to … Susan Hares
- Re: [Idr] Returning draft-ietf-idr-rfc5575bis to … John Scudder
- Re: [Idr] Returning draft-ietf-idr-rfc5575bis to … John Scudder
- Re: [Idr] Returning draft-ietf-idr-rfc5575bis to … Susan Hares