Re: [Idr] WG LC draft-ietf-idr-flowspec-path-redirect-10.txt [11/17/2019 to 12/2/2019]

Robert Raszuk <robert@raszuk.net> Tue, 03 December 2019 14:21 UTC

Return-Path: <robert@raszuk.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 6AE1712006E for <idr@ietfa.amsl.com>; Tue, 3 Dec 2019 06:21:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=raszuk.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 DePTTHfrlKo1 for <idr@ietfa.amsl.com>; Tue, 3 Dec 2019 06:21:08 -0800 (PST)
Received: from mail-qt1-x832.google.com (mail-qt1-x832.google.com [IPv6:2607:f8b0:4864:20::832]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C2BC212006B for <idr@ietf.org>; Tue, 3 Dec 2019 06:21:07 -0800 (PST)
Received: by mail-qt1-x832.google.com with SMTP id w47so3910431qtk.4 for <idr@ietf.org>; Tue, 03 Dec 2019 06:21:07 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=raszuk.net; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=JDZcRX5KjdyasuPmvVgzOkv/Y8K/wCohNFU24+HUZcg=; b=ZDi8sFl9uN+xE+vpOog1pzfIP4u9GmH1Q4u8QjG+DJbagJeHbSkgoNWeuctwKr8oMp GFS3tF8s4puYWw9LaHbPnsJZu4hLskd2nqWMshfe1F61jPrhqE7SjMZ71zL+PQGIXy3v m0Wk9RXq0c1VcBcdKiQG6af6JcodqMAPbpUhuHx5XBQZTRsBM1foVC1R6OpXQem3QyAm HVGqNTz167tG4y1EQ8zkfGhbJY16m+vA4gixNoOKw7I68TxcxbQ46vsqU/RC0l0WRz2H 9iRWuscfP6lrfs9KpzTOIMvdjF6CrxTZ/dV5EPRt/YCGWZ9xETRrANLO1NpZD9wZba9W 1F0w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=JDZcRX5KjdyasuPmvVgzOkv/Y8K/wCohNFU24+HUZcg=; b=hwEP1To8ellWXR2c0RalZ8v6U6GyQdTYMBpzZuj8fHgCuSVhEcFgLNKr+gRA4lC7mM w6UFUmaIplrSatmBrGlNrm8q196XH3sXa6PT6kFdTHd+0qoOIDlnnOBaeNt1cyYjD1V5 Ibsw9ail3frHe0gTtbIhWQXEUOrV8GWVdJcxX3jNS9zcoJ60/cn/F5Sbfk35TLJgW4j0 MEKWnAa5CWs+NbSpjv2Zy6KxuNlhA2fPwHKqGJKJ4jxny+pXYpeAtwqr7pSV5W3JvrP1 UOpGw1kDM4O+ZX/K/j1H6+AjW4pKLM5qGWvqs5b27jEOTLwKdMf2MDn9nISrehdjyYqX QWMA==
X-Gm-Message-State: APjAAAWsHPEWE+tKqQPXJqYnKgktSsUEVdN9HNJET8jX369S3fmByuqN gEd0RAsMgT/5pJgwLZGpAcB938NG7YqwHAc2Z/5ECA==
X-Google-Smtp-Source: APXvYqwmJyWGdzXFKurzFCl3+iUwv1ELSw5pxnXAB515++j0VNRupE6GQuuNMWY+QOAuTbkNSqU9Ngu21+Rj5zSFDTI=
X-Received: by 2002:ac8:5197:: with SMTP id c23mr5274492qtn.343.1575382866505; Tue, 03 Dec 2019 06:21:06 -0800 (PST)
MIME-Version: 1.0
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> <AM6PR07MB48230122B93261D695F5FDB3E0420@AM6PR07MB4823.eurprd07.prod.outlook.com>
In-Reply-To: <AM6PR07MB48230122B93261D695F5FDB3E0420@AM6PR07MB4823.eurprd07.prod.outlook.com>
From: Robert Raszuk <robert@raszuk.net>
Date: Tue, 3 Dec 2019 15:20:53 +0100
Message-ID: <CAOj+MMGpiDtW-HRahyFWLHag0MoqHLeEMFsNsEMtc3E=DyAwRQ@mail.gmail.com>
To: "Van De Velde, Gunter (Nokia - BE/Antwerp)" <gunter.van_de_velde@nokia.com>
Cc: Jeffrey Haas <jhaas@pfrc.org>, "idr@ietf.org" <idr@ietf.org>, Sue Hares <shares@ndzh.com>
Content-Type: multipart/alternative; boundary="00000000000024c9cd0598cd68be"
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/0lzaGZZu3UucmyBD7M8-ta7lQt0>
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 14:21:14 -0000

Hey Gunter,

> That means we keep current proposed Type 0 and Type 5
> (and rename Type 5 to something more sensible in that case).

Yes and that would be a great fix.

To sort of cover more explicitly then via type 0 types 2,3 & 4 you may
define new type to carry the "color". The same color as carried in BGP SR
Policy document if you want to be SR friendly :).

Then we should be fine.

Cheers,
R.,

On Tue, Dec 3, 2019 at 11:20 AM Van De Velde, Gunter (Nokia - BE/Antwerp) <
gunter.van_de_velde@nokia.com> wrote:

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