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:21 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 AB21D1201E5 for <idr@ietfa.amsl.com>; Tue, 3 Dec 2019 02:21:02 -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 kpu09_wZENTT for <idr@ietfa.amsl.com>; Tue, 3 Dec 2019 02:21:00 -0800 (PST)
Received: from EUR04-DB3-obe.outbound.protection.outlook.com (mail-eopbgr60095.outbound.protection.outlook.com [40.107.6.95]) (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 99064120013 for <idr@ietf.org>; Tue, 3 Dec 2019 02:20:59 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=QXMomnKBSigEJGQfjVWvDa9IEldd/GPYSQcciLotxpk7P261Rh/vJGzE+oIhOLJ+5PlY057wgMRi5lrg5oCdoxE7qGiKnH4fS2N2h3c/ZbTjq0+a+Vh2dvnqiE5f+tRhNEVhoxop3IWjwdi5/ZuXmvTZNxu6gwvckKGUhHH1KSo0cTuJ45+42AKj69HjQOc7GF2S1dXFVOZsUJ/nVmxtyki3bqnjrkIyQfZcqLJndCt6Z7N6FbGZ+THPk5Mbu+ThtpZo4nuJ/IBjZMR+gEi1gRcEqe/A1dANZ/B4kRTLABMZCWJZGa7ml+RmpJKcawgyJNIF1DJ0lYyavMwueyokQw==
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=3L5DH7Ou8RRyk3vCNYofw0eJnDgNbRRXQvHgKzCpB+Y=; b=m0IBbcULblgOrsV/S7Hay3iCbHC4TuOiYUnKkvgdpMxuA2xY/uzLLakw6FzrnIAu2XNpw9gRjCYoFC6YZyODdZ6jEwGElxNM+AznfMZfnKvzr9noY8Ar7EULW87UUiORiGBOPax4dYLVjkPsMjWj8wC2wh/Io6t5HADOfawxNuJCm3d5y29oCEwZqxceEe7LXoVpiIs+9aNwPup39Vh4ptJnX4sm2ZOx2No22e12cqTwUxf+ah4nlS1lRwX2BddU72e1DyDw1/kRBZJAHhsmI2hGBHT2aNSbLT+PpHPxXUoEqfSxtWEanjREQmE7LkowQyQJH8GNitD+4xYhjMhtYg==
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=3L5DH7Ou8RRyk3vCNYofw0eJnDgNbRRXQvHgKzCpB+Y=; b=IKACrEraQHMz/jRY4zTh+ZQSMyQgUbgnWMxFbWUvoaa+XOU2urDalnCIK1tJ6FPTmFyUlbSUXDP8Nq3ezlDV4iKRfzyy2kBwPN2ZwrEybocx4TmKc8qabbh0n4Gv/M9LNiOtWbsLuPln3UXj8vgTvxHoBs6AyuWwCVwWhooVbvk=
Received: from AM6PR07MB4823.eurprd07.prod.outlook.com (20.177.191.14) by AM6PR07MB5909.eurprd07.prod.outlook.com (20.178.88.212) 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:20:56 +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:20:56 +0000
From: "Van De Velde, Gunter (Nokia - BE/Antwerp)" <gunter.van_de_velde@nokia.com>
To: Robert Raszuk <robert@raszuk.net>, Jeffrey Haas <jhaas@pfrc.org>
CC: "idr@ietf.org" <idr@ietf.org>, Sue Hares <shares@ndzh.com>
Thread-Topic: [Idr] WG LC draft-ietf-idr-flowspec-path-redirect-10.txt [11/17/2019 to 12/2/2019]
Thread-Index: AdWd0gRnmm6Aw4Y9ShOHyzWN65U36QIHKy+AABzOGSAAtOzfgAACNhgAACDUAwA=
Date: Tue, 3 Dec 2019 10:20:56 +0000
Message-ID: <AM6PR07MB48230122B93261D695F5FDB3E0420@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> <CAOj+MMHbHVARhpDasx6e=Q8f3Q8HNG8JQ4Wn7mwAyaDPA6wvRQ@mail.gmail.com>
In-Reply-To: <CAOj+MMHbHVARhpDasx6e=Q8f3Q8HNG8JQ4Wn7mwAyaDPA6wvRQ@mail.gmail.com>
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: 0388461d-127e-4818-2469-08d777da7c58
x-ms-traffictypediagnostic: AM6PR07MB5909:
x-microsoft-antispam-prvs: <AM6PR07MB59099CE5964E37BDD8ACAC28E0420@AM6PR07MB5909.eurprd07.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 02408926C4
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(346002)(366004)(39860400002)(396003)(136003)(376002)(189003)(199004)(64756008)(66446008)(66574012)(66476007)(66556008)(14454004)(33656002)(5660300002)(66946007)(25786009)(52536014)(186003)(53546011)(76116006)(54896002)(6436002)(6306002)(102836004)(7696005)(6246003)(74316002)(86362001)(11346002)(76176011)(7736002)(99286004)(478600001)(6506007)(26005)(9686003)(55016002)(4326008)(446003)(3846002)(6116002)(790700001)(256004)(8676002)(316002)(81156014)(8936002)(81166006)(54906003)(2906002)(110136005)(71190400001)(71200400001)(229853002); DIR:OUT; SFP:1102; SCL:1; SRVR:AM6PR07MB5909; 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: DB9nZJOp3P2Y9UwpAdDlELQi2OmkBZTHfJqiVWv7kpHFQvX20YM81aPwtBLCrcIS9lP9AnYW02JCdFs15KNks2+5MRRD68SLNh2VDYNN21SvJU8QjPEuWz3ktmv3rxuaAxwPnen/uB6TTHydwz1p5gb4NlviKZ6XI3+jBfJQzkm12I1Y5vTiLi2tQBUk/5Ry/IwSyKPJYEXFi5ueyAhSSgVaIn4gOPWFEZkDA8xDpyEieFS3zX28jbILCBU18iW4WPisik0wcHBIp6z7RaYJClxivJG83P8a0DHZEFF2vf8oDYw0I8dPvaCA9+VZI+wfjddOwMhbopVZdE9WNrCpy5QMcYpfOcWjBgl2KXZcE+FVL/1smgkaqnPBiM+fCmP51nqps99OP+Jok51DNT6/L3UzsNMrZy1FnNiBMHCR2bK7vqK844bOGw2GxFNN6KaZ
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_AM6PR07MB48230122B93261D695F5FDB3E0420AM6PR07MB4823eurp_"
MIME-Version: 1.0
X-OriginatorOrg: nokia.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 0388461d-127e-4818-2469-08d777da7c58
X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Dec 2019 10:20:56.6443 (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: JAUTc1ElHkttaRWyuRdxY5Y4YV6evEt3Cldi2yhEFzvsZDJdhVxnvuadTCiufgs8rFWUsfbnU8CESizRsSRDzGqawMtMguN8stpVPBpsBgc=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM6PR07MB5909
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/gzo6wfTo1gc3Sv_i8GGZAMAgaTs>
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:21:02 -0000

BGP SR policy is different in such a way that it can not steer based upon a flowspec tupple match. It uses a payload prefix and NH to select a particular path policy.

The original path-redirect had no additional assumptions associated and it referenced a 32bit number (Type 0 Seq-ID).
This 32bit number was used as opaque value to lookup forwarding information. If enabled, this is what I have in running code.


***
   ID-Type: 1 octet value.  This draft defines following Context Types:

      0 - Localised ID (The flowspec client uses the received 32-bit
      indirection-id to lookup forwarding information within the
      localised indirection-id table.  The allocation and programming of
      the localised indirection-id table is outside scope of the
      document)

      1 - Node ID with SID/index in MPLS-based Segment Routing (This
      means the 32-bit indirection-id is mapped to an MPLS label using
      the index as a global offset in the SID/label space)

      2 - Node ID with SID/label in MPLS-based Segment Routing (This
      means the 32-bit indirection-id is mapped to an MPLS label using
      the 32-bit indirection-id as global label)

      3 - Binding Segment ID with SID/index in MPLS-based Segment
      Routing (This means the 32-bit indirection-id is mapped to an MPLS
      binding label using the indirection-id as index for global offset
      in the SID/label space) [I-D.draft-ietf-spring-segment-routing]
      [6]

      4 - Binding Segment ID with SID/label in MPLS-based Segment
      Routing (This means 32-bit indirection-id is mapped to an MPLS
      binding label using the 32-bit indirection-id as global label) [I-
      D.draft-ietf-spring-segment-routing] [6]

      5 - Tunnel ID (Tunnel ID is within a single administrative domain
      a 32-bit globally unique tunnel identifier.  The allocation and
      programming of the Tunnel ID within the localised indirection-id
      table is outside scope of the document)

   Generalized indirection_id: 32-bit identifier used as indirection_id

***

I do have sympathy for your suggestion to simplify assuming if the general WG feels that there is too much overlap between the BGP SR Policy propagation and the current indirection Type 1, 2, 3, 4? We could drop those Type’s from the current draft and simplify interop complexity? That means we keep current proposed Type 0 and Type 5 (and rename Type 5 to something more sensible in that case).

G/

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


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?

IMO using flow spec extension to specify a binding SID which in turn will be replaced by explicit path is a huge mistake this draft is proposing. Sure text can take everything but the operational complexity to troubleshoot such network will be a nightmare. And if you would just specify a single SID why not to specify the IP address and be done ? Router will reach such IP via proper path.

Please observe that you are now trying to mimic BGP SR Policy propagation which also includes mapping via color and policy to be used.

What happens when router will receive both in a conflicting manner ?

Btw what practical application is this draft trying to accomplish other then pretty badly redo subset of BGP SR Policy work ?

Thx,
R/