Re: [spring] Draft for Node protection of intermediate nodes in SR Paths

Robert Raszuk <robert@raszuk.net> Mon, 02 December 2019 10:14 UTC

Return-Path: <robert@raszuk.net>
X-Original-To: rtg-bfd@ietfa.amsl.com
Delivered-To: rtg-bfd@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57A32120041 for <rtg-bfd@ietfa.amsl.com>; Mon, 2 Dec 2019 02:14:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 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, URIBL_BLOCKED=0.001] autolearn=unavailable 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 BKczGHi0YcTA for <rtg-bfd@ietfa.amsl.com>; Mon, 2 Dec 2019 02:14:26 -0800 (PST)
Received: from mail-qk1-x72c.google.com (mail-qk1-x72c.google.com [IPv6:2607:f8b0:4864:20::72c]) (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 86A311200E7 for <rtg-bfd@ietf.org>; Mon, 2 Dec 2019 02:14:26 -0800 (PST)
Received: by mail-qk1-x72c.google.com with SMTP id v19so12313638qkv.3 for <rtg-bfd@ietf.org>; Mon, 02 Dec 2019 02:14:26 -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=SSRsHpRFqMmIBHoe20btvrzo8TdARKSi9YkuPYFtkUo=; b=YBEaMTi9l9Xj/radEyzrEcQsozHKeeHQZ3xrlW03k+IGoWmWzi+L8sbpzahAjkI1jW OhLC5NndX7V+PMXKCDTcR0UX1ZFvT/SfkJ9ZHaLnr8G4jDCJLtRrpibw0ZkYbt6NsLLc lnD9ck7ZS8U43z1C+JOIHWRnGutE8ilKizXAAncPiekcE4QWEZ/Bghd8NHB7du/ghEqy Ty+feBRpoYt9GxE1PB5yeu8BKrY+Y0mxLY2V0e+DdNbbfGk2Qplv93Lh2NkAcnVfiuvy QMt4EeVdUfULJgBRBBK3xpbZTL9Bae4QqJqgqlwxTccP5HeURCpteAWe/K/SaG2b8Mko TF/w==
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=SSRsHpRFqMmIBHoe20btvrzo8TdARKSi9YkuPYFtkUo=; b=ZoCzX6wuvyjJY0usbyHq29ABeS1Uje+eFUTWnCtU1MwCmvlSBBhuUaPrFPSwLqAFz5 epIEeM/Zv5oyvJ2zM/MbWV6+YmQLNXa6hk/v+t+ftfhmPwqrLqBZ/4CEznpog5UGy9HZ 5bYFy3xj9BHNwGddT7h5bWCe3UQBfanHlDuhqS7Avx/8EzVQT8fGkhNdroJ7wsptBGbw UPuPs6sFSuJ4jywKPzwV4L9B8Bm7gC9Od+GUZD61Tj+IGxjTrKkIlZrAzFaQhu7kPLbd qT9MYDc5z8Akvt97Hmq7QGc+FmnGgUOvZh2RYHRsy5lFM7O/c9yEDf+m7+smWut8PcCP yKEw==
X-Gm-Message-State: APjAAAUh89lcyI8hRhl1a9nheqbS9wN97oUYOX/oBP2P0lTGSQGZwL+N WyX81hNqgBAw9C/zKhCIv04huYV+MBTbBJQg1JvTzQ==
X-Google-Smtp-Source: APXvYqxMbmhjpWvo2C7R2EnxJ8EtTITvzDDpFD9xNzU8FJTrpX9+hX7XauAGR/iY0RhyDp15jWBuAbTmhC/NRU0kM8M=
X-Received: by 2002:a37:693:: with SMTP id 141mr16367595qkg.134.1575281665219; Mon, 02 Dec 2019 02:14:25 -0800 (PST)
MIME-Version: 1.0
References: <BYAPR05MB394365C9E4719913BEC0809CD5490@BYAPR05MB3943.namprd05.prod.outlook.com> <CAOj+MMFOueodpR-06AN47aND6_9WJAwPaXMTaP-0nzd0HCVzKA@mail.gmail.com> <AM0PR03MB382893DAFDE830D24EE7FAD49D480@AM0PR03MB3828.eurprd03.prod.outlook.com> <CAOj+MMFzrMBTbQbRXrnN0HTNm=uH+HF_LGggVZ3WUtAzGQSNgQ@mail.gmail.com> <VI1PR03MB383986D0D2E66226BFDEDF839D480@VI1PR03MB3839.eurprd03.prod.outlook.com> <AM0PR03MB3828FD21B1D69E3CB74F3AE49D480@AM0PR03MB3828.eurprd03.prod.outlook.com> <BYAPR05MB3943CE8749F824CDDA88F3C8D5430@BYAPR05MB3943.namprd05.prod.outlook.com> <AM0PR03MB3828F1161645C155DA569F099D430@AM0PR03MB3828.eurprd03.prod.outlook.com> <BYAPR05MB394390FE9BEAC8D0CA71DECED5430@BYAPR05MB3943.namprd05.prod.outlook.com> <DBBPR03MB5415486F24D2C9B6338611BEEE430@DBBPR03MB5415.eurprd03.prod.outlook.com> <CAOj+MME2EM52zF8j0N6+8kYpkPz2AN2JP0uMP4JYZcxOgXqGcw@mail.gmail.com> <DBBPR03MB5415CB7A89FBBF974FF284E7EE430@DBBPR03MB5415.eurprd03.prod.outlook.com>
In-Reply-To: <DBBPR03MB5415CB7A89FBBF974FF284E7EE430@DBBPR03MB5415.eurprd03.prod.outlook.com>
From: Robert Raszuk <robert@raszuk.net>
Date: Mon, 2 Dec 2019 11:14:15 +0100
Message-ID: <CAOj+MMEZR8V8wyUu92Rmm_26ojqnqnpM9wH67A04EbEOwHRxDw@mail.gmail.com>
Subject: Re: [spring] Draft for Node protection of intermediate nodes in SR Paths
To: Andrew Alston <Andrew.Alston@liquidtelecom.com>
Cc: Shraddha Hegde <shraddha=40juniper.net@dmarc.ietf.org>, Alexander Vainshtein <Alexander.Vainshtein@ecitele.com>, "spring@ietf.org" <spring@ietf.org>, "rtg-bfd@ietf.org" <rtg-bfd@ietf.org>, "rtgwg@ietf.org" <rtgwg@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000013b3950598b5d82d"
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-bfd/QZN4NXwW3V7Vt85n-B5yNWWgVBg>
X-BeenThere: rtg-bfd@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "RTG Area: Bidirectional Forwarding Detection DT" <rtg-bfd.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtg-bfd>, <mailto:rtg-bfd-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rtg-bfd/>
List-Post: <mailto:rtg-bfd@ietf.org>
List-Help: <mailto:rtg-bfd-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtg-bfd>, <mailto:rtg-bfd-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 02 Dec 2019 10:14:29 -0000

I encourage you to read those two documents:

https://tools.ietf.org/html/draft-akiya-bfd-seamless-sr-04

https://tools.ietf.org/html/draft-ali-spring-bfd-sr-policy-02

Cheers,
R.


On Mon, Dec 2, 2019 at 11:06 AM Andrew Alston <
Andrew.Alston@liquidtelecom.com> wrote:

> Robert – actually I disagree.
>
>
>
> Because to protect the paths you need the node protection on intermediate
> nodes due to lack of state – the headend has no way to actually protect an
> end to end path outside of S-BFD steered over the path to test end to end
> reachability and if you get an intermediate node-failure on the path you
> could run into a problem 😊
>
>
>
> As per draft-ietf-spring-segment-routing-policy-05 a path is valid when:
>
>
>
> It is empty
>
> Its weight is 0
>
> It’s headend is unable to perform path resolution for the first SID into
> one or more outgoing interface(s) and next-hop(s)
>
> The headend is unable to perform SID resolution for any non-first SID of
> type C through K into an MPLS label or an SRv6 SID
>
> The headend verification fails for any SID for which verification has been
> explicitly requested
>
>
>
> Effectively – as of right now – if you read that draft – there is no
> mechanism to verify path nodes if you are doing paths based on type A SID’s
> – the only way right now to do that – is using S-BFD – however this draft
> if my understanding is correct – would allow for node protection that would
> in effect protect the paths injected.
>
>
>
> Thanks
>
> Andrew
>
>
>
>
>
> *From:* Robert Raszuk <robert@raszuk.net>
> *Sent:* Monday, 2 December 2019 12:50
> *To:* Andrew Alston <Andrew.Alston@liquidtelecom.com>
> *Cc:* Shraddha Hegde <shraddha=40juniper.net@dmarc.ietf.org>rg>; Alexander
> Vainshtein <Alexander.Vainshtein@ecitele.com>om>; spring@ietf.org;
> rtg-bfd@ietf.org; rtgwg@ietf.org
> *Subject:* Re: [spring] Draft for Node protection of intermediate nodes
> in SR Paths
>
>
>
> On Mon, Dec 2, 2019 at 10:28 AM Andrew Alston <
> Andrew.Alston@liquidtelecom.com> wrote:
>
>
>
> Currently the biggest issue that I see with S-BFD based protection – which
> is something we use in production is as follows:
>
>
>
> Unless I’m mistaken – there is absolutely no way to tie S-BFD based
> protection with BGP injected SR-TE pathing
>
>
>
>
>
> Well I am not sure what you call " BGP injected SR-TE pathing" but if you
> are looking for validation of BGP paths that has been supported by some
> vendors for a loooong time. Hint: you allocate different next hop for your
> SR-TE endpoints and voila.
>
>
>
> Btw - not an ietf topic, but an implementation request / vendor's feature.
>
>
>
> Besides, since you are talking about headend what you are describing is
> path protection ... this draft talks about node protection which is a
> completely different thing.
>
>
>
> Cheers,
>
> r.
>
>