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> Tue, 03 December 2019 10:09 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 698FB12004A for <idr@ietfa.amsl.com>; Tue, 3 Dec 2019 02:09:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level:
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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 oZe9r0-dffAi for <idr@ietfa.amsl.com>; Tue, 3 Dec 2019 02:09:23 -0800 (PST)
Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-eopbgr130112.outbound.protection.outlook.com [40.107.13.112]) (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 0DC33120013 for <idr@ietf.org>; Tue, 3 Dec 2019 02:09:22 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=FJ06IMTvKkEmCSmXln3zCUy4zK6dAW47C8xg8Pg74LObmNDzUcbJ2kVeXDXSfVjdJs1/KNnjgtPFZ8RRRU6ProWCxnvxmjl34zQsD37BRlmibK/f/VWLpA7UtK36MACCwskEX5NWJqKf6iLfxQZKcDEQeTp71r1B/dMZAmu1iIs+ec0q0MflXY+9Qgqe+zsU0x/pG6UX63ybWmc+IMAtChJsfMBsPbeR6rr7Y70Tlgw25kaEkTOtJYnlikSx3xhD5Q3GzYXsUHMYcQc/1i+45acDN/t0ylyUYgZnc8Fsi+b5TA0RVSGOUEGv5tdMkcPbQ9rvdpP1tdhhZOk3tQArPg==
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=+qFHHd4psmdaaCx7RmJA5qgxOPgS/oB7to/cZMbbKW0=; b=XfVUcqSf4MVhooG5Z9DHlxqPTq2ub9ITrKXZKdbyus60oI6oGKa7QNiMpPGgw5v3G4zYcnvV8shrnubbBuAEq+8v0y+rAwGwLKVE6rTPdNUFvv3K/y24lJhytrZjIizbtIl4NLFjNPgYITOrzcU9y7661VKASs/DxK3Kk5Ghc2BOjyUS46/JE02Vi184VcVUZ4YHLtN+28y1VoPb7ln1RJD3FPQy8Zy6a2q0WZlfP+U/Nw8rZwXFJEJFZCd8EEsRQUE9vRKBku7l9QrqyT4AAZgs+QMakYgJPZ9Bq5ewRgEuoZlcKTZgHljd/nEskPG6qU3d5qK4uaSPuvjxK+tCtw==
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=+qFHHd4psmdaaCx7RmJA5qgxOPgS/oB7to/cZMbbKW0=; b=uTebI6KbEWgDkTF/hbplVJ2kPq0tG3zyx3ljfB77htUaQN43sW7fXLtIIUAoZ//ueTDXbd0egmTY9fAU180ME9r9Y0lVSrOViYIL6rrzmOhcW+nj9GvCxP5XpNFemgW0Tv/oRz6sgsIFu6LZ4uZb3/0HZnZzAQv0l7oixpNNTzQ=
Received: from AM6PR07MB4823.eurprd07.prod.outlook.com (20.177.191.14) by AM6PR07MB4536.eurprd07.prod.outlook.com (20.177.37.159) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2516.9; Tue, 3 Dec 2019 10:09:19 +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; Tue, 3 Dec 2019 10:09:19 +0000
From: "Van De Velde, Gunter (Nokia - BE/Antwerp)" <gunter.van_de_velde@nokia.com>
To: Jeffrey Haas <jhaas@pfrc.org>
CC: Sue Hares <shares@ndzh.com>, "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+AABzOGSAAtOzfgAAiWpBw
Date: Tue, 03 Dec 2019 10:09:19 +0000
Message-ID: <AM6PR07MB4823A2E541541E24526A362DE0420@AM6PR07MB4823.eurprd07.prod.outlook.com>
References: <016501d59dd2$e5458850$afd098f0$@ndzh.com> <D0AA5E62-4AE5-43A5-BA23-E66D98AF657B@pfrc.org> <AM6PR07MB482356A327D714512EBAF2DBE0460@AM6PR07MB4823.eurprd07.prod.outlook.com> <20191202172621.GG18175@pfrc.org>
In-Reply-To: <20191202172621.GG18175@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: [131.228.32.163]
x-ms-publictraffictype: Email
x-ms-office365-filtering-ht: Tenant
x-ms-office365-filtering-correlation-id: 0ce8d77a-781b-422f-7a69-08d777d8dceb
x-ms-traffictypediagnostic: AM6PR07MB4536:
x-microsoft-antispam-prvs: <AM6PR07MB4536D9D7592B2BD0AE408BB8E0420@AM6PR07MB4536.eurprd07.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:4125;
x-forefront-prvs: 02408926C4
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(136003)(346002)(396003)(39860400002)(366004)(376002)(189003)(199004)(13464003)(99286004)(33656002)(26005)(256004)(66476007)(66556008)(64756008)(6916009)(66446008)(5024004)(76116006)(11346002)(305945005)(14454004)(52536014)(9686003)(478600001)(71190400001)(86362001)(71200400001)(25786009)(66946007)(76176011)(54906003)(229853002)(4326008)(316002)(5660300002)(446003)(6436002)(2906002)(186003)(7696005)(8676002)(6246003)(8936002)(81166006)(102836004)(3846002)(7736002)(55016002)(6116002)(53546011)(81156014)(74316002)(6506007); DIR:OUT; SFP:1102; SCL:1; SRVR:AM6PR07MB4536; 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: aCL6lwx9l3FY/fcJKL7JKWmQ5Zr9FaMMefN648Kom9VXdHJXMETxCPDqBNNc0OUcBXXA4ss/zUzdKFPuV2K4OifWqi4mnJLVlLOxF6t2uU42pbrZol8rbW3ztz9Sm27DjHCP8PVx/F+dYNs0RMoR0KS5H5CljXE3ovZW1g49EsMkx/oN0BT51qF8PxY0lGfA+9mUmmFahf0k3MAQYE3SdOfjhfZaqBOZw7Kzs6wKqzvt+FyjnTXtRk8BryOrqjrgPKzkaW7lP+NODqgmZEVWIYcNo1EGDv7Gp6umOjVo6ODfE07UyNzXUFNTxXbGVR9wtv8SwN4yKSU4hHo7QhA0/wQ+omkY8ky1Axy5A5/ydIZdq5dq2w7OFeDsZXnTHQ141D05ANv6dnOldzTkn39XvXeSgbT0o+PPvH9Z/Oaz1jbgmL6rBqcLRWq7FDiwsbO6
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: nokia.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 0ce8d77a-781b-422f-7a69-08d777d8dceb
X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Dec 2019 10:09:19.8506 (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: wGMX2/vzWIHthOQCFgREsGVOZO1Bno4i5OyjcZfQ7xBgCxY9mizjdUAjVpqm/GE8Akla3U3Sn+2iIJ5sV2PUSxeNZGQI2eJqDq2KpUSMNYo=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM6PR07MB4536
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/ThJH2iH0uZORaqtXleV7kRhked8>
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: Tue, 03 Dec 2019 10:09:25 -0000

Inline: GV2>

-----Original Message-----
From: Jeffrey Haas <jhaas@pfrc.org> 
Sent: Monday, December 2, 2019 18:26
To: Van De Velde, Gunter (Nokia - BE/Antwerp) <gunter.van_de_velde@nokia.com>
Cc: Sue Hares <shares@ndzh.com>; idr@ietf.org
Subject: Re: [Idr] WG LC draft-ietf-idr-flowspec-path-redirect-10.txt [11/17/2019 to 12/2/2019]

Gunter,

On Fri, Nov 29, 2019 at 03:51:35AM +0000, Van De Velde, Gunter (Nokia - BE/Antwerp) wrote:
> > 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

Redirect-ip isn't even mentioned in the draft.

Part of the reason to raise this is whether intentional interactions could happen.  As an example, redirect-ip is specced to be permitted in the context of a VRF redirection.

I suspect in the majority of the cases that path-redirect is intended involving segment routing that following a segment path from a VRF context doesn't make much sense.  However, some of the cases are left as much more abstract and perhaps they could?

My point is that a bit more normative text on the various cases would be needed for interoperable code.

***
GV2> The original concept was to have an abstract steering correlation towards a 32bit tunnel-ID (This is an action, opaque to VRF, or any other associated contexts). If indeed a matter of context is added to the redirection id (for example the 32 bits represent a Segment path) then that few more normative text could be added on the cases.
***

> > 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.

Aside comment: Any possibility this could be renamed Seq-Id or something similar to avoid name confusion to SID?

The text above is clearer, but I'm not sure it really helps your case.  Here is what I believe the intent to be in pseudo-code:

if Seq-ID == 0 is present:
  apply actions, if possible.
  exit
foreach s in Seq-Id 1..15:
  if s is present:
     if action for s is possible:
        apply it.
        exit
     else:
        continue

Basically, try each sequence in turn.  If you can do something with it, you're done.  If you can't (the indirection can't be applied for numerous reasons), try next.  S-ID zero is intended to be a "hard stop".

***
GV2> Thanks. let me think on how to integrate this best
***

The 'C' bit also looks like it only changes the stream behavior and doesn't impact whether the rule is terminating or not.

***
GV2> correct
***

What's still not covered, since these are extended communities, is cases like there are two of a given S-ID present.  Perhaps it was added via blind policy?  What do you do?  

***
GV2> ok, my personal understanding is that rule is invalid, and then the flowspec rule MUST be
processed as if the "Redirect to indirection-id" community was not attached to the flowspec route.
***

> "
>    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 
> GV> "redirect-to-ip" is incompatible with "redirect to indirection-id" 
> GV> and result in invalid redirection rule, however to me that is 
> GV> already implied with enough detail in the text above)

redirect-to-ip is not core to 5575bis, so clarity as to precedence would be helpful, I think.

***
GV2> ack, will add that line
***

> > 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.

Understood.  They sometimes like to operate this way.  

-- Jeff

G/