Re: [Idr] WG LC draft-ietf-idr-flowspec-path-redirect-10.txt [11/17/2019 to 12/2/2019]
"Van De Velde, Gunter (Nokia - BE/Antwerp)" <gunter.van_de_velde@nokia.com> Fri, 29 November 2019 03:51 UTC
Return-Path: <gunter.van_de_velde@nokia.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 24B6C120125 for <idr@ietfa.amsl.com>; Thu, 28 Nov 2019 19:51:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nokia.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 1FMNynUc-IaN for <idr@ietfa.amsl.com>; Thu, 28 Nov 2019 19:51:38 -0800 (PST)
Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-eopbgr130114.outbound.protection.outlook.com [40.107.13.114]) (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 51DB91200D7 for <idr@ietf.org>; Thu, 28 Nov 2019 19:51:38 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Q6hx7R/k9NP2UoiFAiartJ17sppCLnEBiYyr2W1y7ec1nVB62av7gqYbSPEYCkG71HYW9FvQ45P2OMm2T6gVMLMgMazobfJkkNc1e8JMkVV9FlaP6GXRQKGzIpm8gGCUsyW0i1emoZZgpiw1WpgwyHpslSwiOVMUa3AGTGIB6efmj1eDBl/QRh15k1YOfzozdHvpgt0u5905FUCex3r0pMpRZZ+jy1xe+OK900c7w3Sol6D1L9sAWfWDpn0dOA1QaMQYVvDm4c1Hkf2glEtv/x5QDk3FdfVmYCHP4hZyO0R9SSz615VHU45iGSnGxR2a6Z4LhhHqdDB5rFEz7FH3HQ==
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=/1v+E4SSkyp38NAnhAEgE0kkBqadX2iugmU2tVY19kU=; b=A1oNMxGuMiU/R2hEkuxaRRoFUOZXJr+yn01XzTqLWme7Ube9mHYzPwuGy3JJx8ffcCpFb3XM4UGn6UsmyYTUzVrgq6AT7vYn27TvU7/xtVkpcVxM5nJ3vRQEv3W4EAXYRAcbjGSrJoGyB/M3CNCH/JSxZjIpx/lz8eFG6/KoYu2XLQSNZND9DmaceTxIZR8NEozrSKQkraxhM2k3kCHllOtNZu4PhFh1CFiEYIDcC2c4QfiuytTXMzZpIbqE3lZlqNrOREZ2zGXOzc+jUJX8+DevUosC0csiJIEoMaNt0RMLBE9UusgwcFxr4C95hL4Rh98cIBebxWEhSSQ9GEE/hQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=nokia.com; dmarc=pass action=none header.from=nokia.com; dkim=pass header.d=nokia.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=/1v+E4SSkyp38NAnhAEgE0kkBqadX2iugmU2tVY19kU=; b=i560US7Roft/h7TXkbCbjECNomlpBMbuEwInBz9SlWK931rkjCO5LmTr57geb3NPFW+CNYllcPqqilOGpvYzJssebky0OjaiNZAHZpfTImPoeZReg3VNMnBhQpL+yK+xkepgoDmZMVaL5Odp1zW+hqlna3ss8iy6IuMUXBvdAbg=
Received: from AM6PR07MB4823.eurprd07.prod.outlook.com (20.177.191.14) by AM6PR07MB5815.eurprd07.prod.outlook.com (20.178.95.86) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2516.4; Fri, 29 Nov 2019 03:51:35 +0000
Received: from AM6PR07MB4823.eurprd07.prod.outlook.com ([fe80::b1d3:14fc:83c7:d765]) by AM6PR07MB4823.eurprd07.prod.outlook.com ([fe80::b1d3:14fc:83c7:d765%3]) with mapi id 15.20.2516.003; Fri, 29 Nov 2019 03:51:35 +0000
From: "Van De Velde, Gunter (Nokia - BE/Antwerp)" <gunter.van_de_velde@nokia.com>
To: Jeffrey Haas <jhaas@pfrc.org>, Sue Hares <shares@ndzh.com>
CC: "idr@ietf.org" <idr@ietf.org>
Thread-Topic: [Idr] WG LC draft-ietf-idr-flowspec-path-redirect-10.txt [11/17/2019 to 12/2/2019]
Thread-Index: AdWd0gRnmm6Aw4Y9ShOHyzWN65U36QIHKy+AABzOGSA=
Date: Fri, 29 Nov 2019 03:51:35 +0000
Message-ID: <AM6PR07MB482356A327D714512EBAF2DBE0460@AM6PR07MB4823.eurprd07.prod.outlook.com>
References: <016501d59dd2$e5458850$afd098f0$@ndzh.com> <D0AA5E62-4AE5-43A5-BA23-E66D98AF657B@pfrc.org>
In-Reply-To: <D0AA5E62-4AE5-43A5-BA23-E66D98AF657B@pfrc.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=gunter.van_de_velde@nokia.com;
x-originating-ip: [119.76.35.36]
x-ms-publictraffictype: Email
x-ms-office365-filtering-ht: Tenant
x-ms-office365-filtering-correlation-id: 01c3234c-9b90-41d4-dd27-08d7747f6e23
x-ms-traffictypediagnostic: AM6PR07MB5815:
x-microsoft-antispam-prvs: <AM6PR07MB581546C6DEB2B95E74F0548FE0460@AM6PR07MB5815.eurprd07.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 0236114672
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(396003)(346002)(39860400002)(366004)(136003)(376002)(189003)(199004)(13464003)(51914003)(86362001)(6116002)(3846002)(66446008)(30864003)(64756008)(316002)(66066001)(99286004)(110136005)(33656002)(52536014)(66556008)(66476007)(5660300002)(76116006)(8676002)(186003)(76176011)(81156014)(7736002)(2906002)(25786009)(66946007)(446003)(26005)(11346002)(7696005)(478600001)(74316002)(305945005)(102836004)(966005)(14454004)(6436002)(256004)(55016002)(8936002)(9686003)(6306002)(4326008)(6506007)(6246003)(14444005)(5024004)(229853002)(81166006)(53546011)(71200400001)(71190400001); DIR:OUT; SFP:1102; SCL:1; SRVR:AM6PR07MB5815; H:AM6PR07MB4823.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1;
received-spf: None (protection.outlook.com: nokia.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: tn4Q/lBj8fwDyxcu+7yfhfjNb/Hh3+qAVx/+vzEg8tFH6pJwVUkxVZSIAp/0KE05/8qB3KcGoewZXvd6F8cwWEBc0/hGHwuQMijBEoQqL6iIGzV761H47F6E5CDxFwL0rAv/p9OnuarIKPDETJrp+naPSWRqkFFKkeyYSaKVwxxllnwiAEjrWFI1+NYUmS9FonGX9zw92lmvyGz1mRJ+h6TSACcxUM4Oe86NCEhnL9bdDG6kowEffyshBUp94muJPZJpF4eTPEycFOtOdXFakTaM+GR1mI9SoaIvfqzZrsyg5lkH/Hma06dkw5lHP1AaMRN6Xed6i/I1UQ+Fa5j6LKnWp4IPXJjDmtWda0IqNCexIn2qQhHAhd/X1mEu/y6kvxOUZEDjhL5TIxePELkWjZZqwM92Pughjudy6nCMvY6WYGoE/IF0NZ3sClr3DQPQ
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_AM6PR07MB482356A327D714512EBAF2DBE0460AM6PR07MB4823eurp_"
MIME-Version: 1.0
X-OriginatorOrg: nokia.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 01c3234c-9b90-41d4-dd27-08d7747f6e23
X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Nov 2019 03:51:35.3157 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: x82z+C3dQQ8Dqh6k7j4ahxC37PZgaUXwwNMYMCyF6nS/rB4PpVxWElpVCI4lT3FO9PVyKpViFucIBoWiIDzW4dldOhCCPQfBZ0httbpHmo0=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM6PR07MB5815
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/q1jWPmA34prDPiZmpYTEOTX9QAs>
Subject: Re: [Idr] WG LC draft-ietf-idr-flowspec-path-redirect-10.txt [11/17/2019 to 12/2/2019]
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: Fri, 29 Nov 2019 03:51:42 -0000
Hi Jeff, Thanks for the feedback and suggestions. See inline: GV> -----Original Message----- From: Idr <idr-bounces@ietf.org> On Behalf Of Jeffrey Haas Sent: Thursday, November 28, 2019 20:21 To: Sue Hares <shares@ndzh.com> Cc: idr@ietf.org Subject: Re: [Idr] WG LC draft-ietf-idr-flowspec-path-redirect-10.txt [11/17/2019 to 12/2/2019] Sue, > On Nov 18, 2019, at 12:41 AM, Susan Hares <shares@ndzh.com<mailto:shares@ndzh.com>> wrote: > > This begins a 2 week WG Last call on draft-idr-flowspec-path-redirect-10.txt from [11/17/2019 to 12/2/2019]. > > You can obtain the draft at: > > https://datatracker.ietf.org/doc/draft-ietf-idr-flowspec-path-redirect/ > > Consider in your review whether this draft: > > 1) Is compatible with draft-ietf-rfc5575bis-17.txt? Yes. (Close enough.) The current version of the draft is implementable. > 2) Whether the draft is useful for deployments of flow specification It can be useful. > 3) Is this technology ready for deployment? > 4) Is the write-up of this technology in draft-ietf-idr-flowspec-path-redirect clearly written and ready for publication? Ready with minor issues, IMO: Procedure-wise, there needs to be a bit more text covering cases about interactions with other traffic actions. This was a known headache for similar drafts such as redirect-to-ip. In particular, interaction with redirect-to-ip and redirect-to-vrf is needed. GV> Section "6. Validation Procedures" gives input on this. We discussed this with you long ago and hence this text was added. " While it MUST NOT happen, and is seen as invalid combination, it is possible from a semantics perspective to have multiple clashing redirect actions defined within a single flowspec rule. For best and consistant compatibility with legacy implementations, the redirect functionality as documented by rfc5575bis MUST NOT be broken, and hence when a clash occurs, then rfc5575bis based redirect MUST take priority. " This means that redirect-to-VRF will take absolute priority to not break rfc5575bis behavior. Having also redirect-to-ip will result in an invalid The text "A single flowspec rule MUST NOT have more as one indirection-id per S-ID. On a flowspec client the indirection-id with lowest S-ID MUST be imposed first for any given flowspec entry." There's no procedure for what happens in error handling when you do have more than one of the same S-ID. The text about the case for S-ID of 0 is also a bit ambiguous. It feels like it's reading "there is no sequence", but what do you do when you then have ones that do? GV> What about the following rewrite: Original: The 'S-ID' field identifies a 4 bit Sequence ID field. This field is used to provide a flowspec client an indication how and where to sequence the received indirection-ids. The Sequence ID value 0 indicates that Sequence ID field is NOT set and SHOULD be ignored. A single flowspec rule MUST NOT have more as one indirection-id per S-ID. On a flowspec client the indirection-id with lowest S-ID MUST be imposed first for any given flowspec entry. New: The 'S-ID' field identifies a 4 bit Sequence ID field. This field is used to provide a flowspec client an indication how and where to sequence the received indirection-ids. The Sequence ID value 0 indicates that Sequence ID field is NOT set and **all other sequence ID's** SHOULD be ignored. A single flowspec rule MUST NOT have more as one indirection-id per S-ID. On a flowspec client the indirection-id with lowest S-ID MUST be imposed first for any given flowspec entry. GV> In section *6. Validation procedure" there is text to handle the error condition when the flowspec rule results in an invalid redirection, that prescribe what needs to happen when the "redirect to indirection-id" does not result in a valid redirection: " While it MUST NOT happen, and is seen as invalid combination, it is possible from a semantics perspective to have multiple clashing redirect actions defined within a single flowspec rule. For best and consistant compatibility with legacy implementations, the redirect functionality as documented by rfc5575bis MUST NOT be broken, and hence when a clash occurs, then rfc5575bis based redirect MUST take priority. Additionally, if the "Redirect to indirection-id" does not result in a valid redirection, then the flowspec rule MUST be processed as if the "Redirect to indirection-id" community was not attached to the flowspec route. " GV> Is there more to add to this? (We could add a line to detail that "redirect-to-ip" is incompatible with "redirect to indirection-id" and result in invalid redirection rule, however to me that is already implied with enough detail in the text above) A few IANA issues: I see the type registry is currently registered with IANA (code point 0x09). However, the sub-type registry is not established for some reason? The ID-Type field likely needs its own IANA registry. Values 1-5 are defined in this draft. GV> Correct. There is a reason for this. When we asked IANA the code-points they informed me that once the document get to RFC the sub-type registry will be established by IANA. The flags field (one octet) currently has 3 bits reserved. In the past, we've not done a registry for such cases (c.f. graceful restart) until we need to start carving out those reserved bits for future extensions. I leave it to the chairs' opinion whether we want this a priori or not. G/ > > Thank you for considering this draft. > > Cheerily, Susan Hares > > _______________________________________________ > Idr mailing list > Idr@ietf.org<mailto:Idr@ietf.org> > https://www.ietf.org/mailman/listinfo/idr _______________________________________________ Idr mailing list Idr@ietf.org<mailto:Idr@ietf.org> https://www.ietf.org/mailman/listinfo/idr
- [Idr] WG LC draft-ietf-idr-flowspec-path-redirect… Susan Hares
- Re: [Idr] WG LC draft-ietf-idr-flowspec-path-redi… Zhuangshunwan
- Re: [Idr] WG LC draft-ietf-idr-flowspec-path-redi… Wanghaibo (Rainsword)
- Re: [Idr] WG LC draft-ietf-idr-flowspec-path-redi… Van De Velde, Gunter (Nokia - BE/Antwerp)
- Re: [Idr] WG LC draft-ietf-idr-flowspec-path-redi… Rabadan, Jorge (Nokia - US/Mountain View)
- Re: [Idr] WG LC draft-ietf-idr-flowspec-path-redi… Lizhenbin
- Re: [Idr] WG LC draft-ietf-idr-flowspec-path-redi… Jeffrey Haas
- Re: [Idr] WG LC draft-ietf-idr-flowspec-path-redi… Aissaoui, Mustapha (Nokia - CA/Ottawa)
- Re: [Idr] WG LC draft-ietf-idr-flowspec-path-redi… Bidgoli, Hooman (Nokia - CA/Ottawa)
- Re: [Idr] WG LC draft-ietf-idr-flowspec-path-redi… Henderickx, Wim (Nokia - BE/Antwerp)
- Re: [Idr] WG LC draft-ietf-idr-flowspec-path-redi… Van De Velde, Gunter (Nokia - BE/Antwerp)
- Re: [Idr] WG LC draft-ietf-idr-flowspec-path-redi… Robert Raszuk
- Re: [Idr] WG LC draft-ietf-idr-flowspec-path-redi… Gunter Van De Velde
- Re: [Idr] WG LC draft-ietf-idr-flowspec-path-redi… Robert Raszuk
- Re: [Idr] WG LC draft-ietf-idr-flowspec-path-redi… Keyur Patel
- Re: [Idr] WG LC draft-ietf-idr-flowspec-path-redi… Chengli (Cheng Li)
- Re: [Idr] WG LC draft-ietf-idr-flowspec-path-redi… Dongjie (Jimmy)
- Re: [Idr] WG LC draft-ietf-idr-flowspec-path-redi… Jeffrey Haas
- Re: [Idr] WG LC draft-ietf-idr-flowspec-path-redi… Jeffrey Haas
- Re: [Idr] WG LC draft-ietf-idr-flowspec-path-redi… Robert Raszuk
- Re: [Idr] WG LC draft-ietf-idr-flowspec-path-redi… Van De Velde, Gunter (Nokia - BE/Antwerp)
- Re: [Idr] WG LC draft-ietf-idr-flowspec-path-redi… Van De Velde, Gunter (Nokia - BE/Antwerp)
- Re: [Idr] WG LC draft-ietf-idr-flowspec-path-redi… Robert Raszuk
- Re: [Idr] WG LC draft-ietf-idr-flowspec-path-redi… Jeffrey Haas