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

Robert Raszuk <> Sat, 23 November 2019 10:37 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E7312120898 for <>; Sat, 23 Nov 2019 02:37:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.4
X-Spam-Status: No, score=-1.4 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, HTTPS_HTTP_MISMATCH=0.1, PDS_BTC_ID=0.499, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id wqaW1oJJpVXb for <>; Sat, 23 Nov 2019 02:37:42 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::82b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 82C68120288 for <>; Sat, 23 Nov 2019 02:37:42 -0800 (PST)
Received: by with SMTP id y10so11044326qto.3 for <>; Sat, 23 Nov 2019 02:37:42 -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=EgDivIgqG5Ehdm1dX+VVzZdMA4UF8AUdfjPUFKxzUOk=; b=UmhWtW88rer9ceNEpfLz7y4HJe+/V3TnA/u9sklPtZjWMWN3z4e8Sszd/zNj3q5fU1 O5fJ8ePsAZKvTEmz3m717hweFww3UUdVRAfA/NbAK5R0tbrleIzvkKoIBQvyx9pf2dg0 gXENAly+gYFiJVQJLIxWBD1yk8UybbjXNgWV3+TZGUyIBI28uKYUr/bMRH0Denqs/1RM vpI9EODGqIQVo5/e6mTWV8i9Rq/VEfZP6diwGpHr73m0Z/C+8D6rYurS1BNEnC9Qzu+n iSGejyTQhIRuCjz58btj+6DF5mHYFf5Ryzyirwolmv57rCT6+n/VisF0QZIOm6tEFsCH zMVQ==
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=EgDivIgqG5Ehdm1dX+VVzZdMA4UF8AUdfjPUFKxzUOk=; b=cy8dET3W+p5Fq/LWyXMRfqk59ZiILLWKfOEwKeHRl4xjlZ7besvgbj6Host16DdT0i 0IVyeMpR2tdPFIp6Ol6uCsJFlzkBCR0NmCb0UflJO1nf1lPkFlCZ6CvQP8w/lNjtTwo6 pUd5Hxaf/QmkDgNIg8C2P5E8ZvDmAxGI0BuxXGr4fv+JQmgwrE2Z1VlskMCPAIJCFmqN Zif+PWDSPWL+Fdi0lD6aAoQF5oNRzm9ATeGyZ7EuyDDkfnSRGGymkR3Fn83Pxlzi5rep YdMfhidrAnk3MyEon8c/Zw2SsWNSWgBj9pl0u1s7ocSOapAoKzYdKs+uYkzBDlPXKLUF BUMA==
X-Gm-Message-State: APjAAAWL0jQHSjohX9AHHm1hxjVEA1ju3vD5q0SicppmQ1mZEjTGYrH8 CVipR/5voXUd2uL0HjpYCIYaKmk6gJDAfzVB9bhHxw==
X-Google-Smtp-Source: APXvYqwjVXZtKNmhcHtSqMuwmy6mNpOJ8aX2OjaAyoL7zWmSGQ5KD4UD2m0U9Trt8SfTX6t4u4krogjMHOOXWs+qApA=
X-Received: by 2002:aed:36a1:: with SMTP id f30mr4911144qtb.154.1574505461278; Sat, 23 Nov 2019 02:37:41 -0800 (PST)
MIME-Version: 1.0
References: <> <> <>
In-Reply-To: <>
From: Robert Raszuk <>
Date: Sat, 23 Nov 2019 11:37:33 +0100
Message-ID: <>
Subject: Re: [spring] Draft for Node protection of intermediate nodes in SR Paths
To: Alexander Vainshtein <>, Shraddha Hegde <>
Cc: "" <>, "" <>,
Content-Type: multipart/alternative; boundary="000000000000b795db0598011ece"
Archived-At: <>
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "RTG Area: Bidirectional Forwarding Detection DT" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 23 Nov 2019 10:37:45 -0000

Hi Sasha,

On the surface your suggestion may look cool - but if you zoom in - I do
not think it will work in practice.

See - one of the biggest value of BFD is its offload to line card's
hardware. And in most cases it is ingress line card to the box. So if you
instruct such hardware to respond to SID address loopback you still did not
gain much in terms of detection router's fabric failures, remote LC failure
or control plane issues which could soon result in box failure. The
catalogue of router failures is of course much more colorful.

If you ask BFD to be responded by RP/RE it no longer has the BFD advantage.

IMHO the best way to detect node failure is actually to send the probes
*across* the node under test to its peers.

The way I would think of establishing such m-hop sessions would be fully
automated with one knob per IGP adj. ex: "bfd detect-node-failure [max N]"
where local BFD subsystem would create N sessions to IGP peers of the node
we are to protect. LSDB has those peers so no new protocol extension is
needed, perhaps even no new IETF draft is required :). N would be the limit
of such sessions in case the node under protection has say 10s of peers.
Default could be perhaps even 1.


On Sat, Nov 23, 2019 at 10:00 AM Alexander Vainshtein <> wrote:

> Shraddha, Robert and all,
> Regarding Robert's question:
> I wonder if multi-hop IP BFD session with addresses used as /32 (or /128)
> prefixes serving as Nose SIDs of R8 and R7 respectively could be used as
> such a trigger by R7? Such a session would not respond to link failures,
> and I find it problematic to imagine a scenario when it would be kept UP in
> the case of a real node failure.
> Of course such a session would have to be slow enough not to react to link
> failures. But it still couks be much faster than IGP conversion IMHO.
> My 2c,
> Sasha
> Such
> Get Outlook for Android <>
> ------------------------------
> *From:* spring <> on behalf of Robert Raszuk <
> *Sent:* Friday, November 22, 2019, 11:22
> *To:* Shraddha Hegde
> *Cc:*;
> *Subject:* Re: [spring] Draft for Node protection of intermediate nodes
> in SR Paths
> Hi Shraddha,
> I have one question to the document.
> As you know the critical element for the effective protection of any
> scheme is the failure detection. On that your draft seems to have just one
> little paragraph:
>    Note that R7 activates the node-protecting backup path when it
>    detects that the link to R8 has failed.  R7 does not know that node
>    R8 has actually failed.  However, the node-protecting backup path is
>    computed assuming that the failure of the link to R8 implies that R8
>    has failed.
> Well IMO this is not enough. Specifically there can be a lot of types of
> node failure when link is still up. Moreover there can be even running BFD
> across the link just fine when say fabric failure occurs at R8.
> While this is not solely issue with this draft, it is our common IETF
> failure to provide correct means of detecting end to end path or fragments
> of path failures (I am specifically not calling them segment here :).
> For example I propose that to effectively detect R8 failure as node
> failure which is the topic of your proposal a mechanism is clearly defined
> and includes bi-dir data plane probes send between R7-R9, R3-R7, R4-R7,
> R4-R9, R3-R9
> Many thx,
> Robert.
> On Fri, Nov 22, 2019 at 4:38 AM Shraddha Hegde <shraddha=
> <>> wrote:
>> WG,
>> This is the draft I pointed out that talks about solutions for providing
>> node-protection.
>> It covers Anycast case as well as keeping forwarding plane longer.
>> **
>> <>
>> Review and comments solicited.
>> Rgds
>> Shraddha
>> _______________________________________________
>> rtgwg mailing list
>> <>