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

Robert Raszuk <> Mon, 02 December 2019 18:29 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id EBACF120072 for <>; Mon, 2 Dec 2019 10:29:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.999
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: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id P9UP0l1_ZQN4 for <>; Mon, 2 Dec 2019 10:29:50 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::734]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 703F6120090 for <>; Mon, 2 Dec 2019 10:29:50 -0800 (PST)
Received: by with SMTP id b8so529431qkk.5 for <>; Mon, 02 Dec 2019 10:29:50 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=3qdhrFXHOKkIkMXjTq+U/qmylJwrMn+0tazxkokHSGc=; b=ZLlAy0FQXOPonr9+I5s3xlgsg919amgok4zstEmFo5A+L84sZfKBAZDei6H+ttfdVE NlN8sGZPlwmF0d+c/x+yXjmpm50VxP9y9c+w3Xb7ur63k8FtupUr+uN3FR8j8lpIFm/t OWenwdXg/4SJGdQmuIFiUDTeb5esrprvXPbrDdNrurP1eVE6u21wmkO08Xx8OtpJEX+/ BTt2CwW6fBsrA1QIl8FFBSEarYjsIx+Y0FHwmXXsqv5CtM0f8uFTeoKd4jDvYdtMyeI2 Rq7I6NLldwO+HkqbygGCbl3hhBH7XHp39zonHUX7v/Z0S5bBA3KsOzaP189dhR94VLn9 V7uQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=3qdhrFXHOKkIkMXjTq+U/qmylJwrMn+0tazxkokHSGc=; b=Mxx27zev0lLqhFPN/aVRJNeXUX+SJlXelHYB4v7nlUN4DGg+F/78PagwkjPbUQd6GU mrY2Vk2+tqGIVDS/LxhTI16Ds5MnGAIlwcEDGAyGVA2sVvMGBqoejlC1E6XriRgH1GJw mUsHChAf4BgA6x+MvPdD8bFDnl2yZAdrw2+VDGEz2cTxSi0yjR0ccrHF7Q8tfDq5lV8K nElucBdMW9cjOIdD6jTkIGOlbnaBsJnFcyoOkG22De/KwEo5GVDNPPuHier4Q9W4zOkM ISSbJqI5dvtIE+WzuxeN+F+nyYzNH1hYbfQkSsWACOJlGbvjHBucdSl3cN9yU/WZanGF mstg==
X-Gm-Message-State: APjAAAV9IoRAY+QEtRVtBHlgfMXbQPrEYTjpjmKDTiGG9bdLPJ/bhG6l Z7+wex4Lq99n784UcYzXcrkn1Arc/8m0KOY18zUug/N02ug=
X-Google-Smtp-Source: APXvYqw7jUueoYD/moueduY+70LmU9uwpMth84N7sizlsxORqj56RSwFS8c8T4wHmkeP/7syAmR/e4FWpK6swPbIRDw=
X-Received: by 2002:a37:693:: with SMTP id 141mr234371qkg.134.1575311389351; Mon, 02 Dec 2019 10:29:49 -0800 (PST)
MIME-Version: 1.0
References: <016501d59dd2$e5458850$afd098f0$> <> <> <>
In-Reply-To: <>
From: Robert Raszuk <>
Date: Mon, 02 Dec 2019 19:29:40 +0100
Message-ID: <>
To: Jeffrey Haas <>, "Van De Velde, Gunter (Nokia - BE/Antwerp)" <>
Cc: "" <>, Sue Hares <>
Content-Type: multipart/alternative; boundary="000000000000c5f3610598bcc391"
Archived-At: <>
Subject: Re: [Idr] WG LC draft-ietf-idr-flowspec-path-redirect-10.txt [11/17/2019 to 12/2/2019]
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Inter-Domain Routing <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 02 Dec 2019 18:29:52 -0000

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