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

Andrew Alston <Andrew.Alston@liquidtelecom.com> Mon, 02 December 2019 10:08 UTC

Return-Path: <andrew.alston@liquidtelecom.com>
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 5ABE91200B1 for <rtg-bfd@ietfa.amsl.com>; Mon, 2 Dec 2019 02:08:06 -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, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, PDS_BTC_ID=0.499, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
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 kCIRGBsaRUw3 for <rtg-bfd@ietfa.amsl.com>; Mon, 2 Dec 2019 02:08:03 -0800 (PST)
Received: from eu-smtp-delivery-182.mimecast.com (eu-smtp-delivery-182.mimecast.com [207.82.80.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1E73B120041 for <rtg-bfd@ietf.org>; Mon, 2 Dec 2019 02:08:02 -0800 (PST)
Received: from EUR04-DB3-obe.outbound.protection.outlook.com (mail-db3eur04lp2059.outbound.protection.outlook.com [104.47.12.59]) (Using TLS) by relay.mimecast.com with ESMTP id uk-mta-141-sxWXPyzwPbGRZotVIOOzug-1; Mon, 02 Dec 2019 10:06:25 +0000
Received: from DBBPR03MB5415.eurprd03.prod.outlook.com (20.179.47.79) by DBBPR03MB5223.eurprd03.prod.outlook.com (20.179.47.142) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2495.21; Mon, 2 Dec 2019 10:06:23 +0000
Received: from DBBPR03MB5415.eurprd03.prod.outlook.com ([fe80::707f:9207:45d4:82bc]) by DBBPR03MB5415.eurprd03.prod.outlook.com ([fe80::707f:9207:45d4:82bc%6]) with mapi id 15.20.2495.014; Mon, 2 Dec 2019 10:06:23 +0000
From: Andrew Alston <Andrew.Alston@liquidtelecom.com>
To: Robert Raszuk <robert@raszuk.net>
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>
Subject: RE: [spring] Draft for Node protection of intermediate nodes in SR Paths
Thread-Topic: [spring] Draft for Node protection of intermediate nodes in SR Paths
Thread-Index: AdWg5kSzPcmokSdUTd+ujmkEsxaFPQAMBq8AADGDFIAAA2XugAABUkKAAAdRE4ABsInvgAADpWmAAAEKboAAA6iU8AABbEuAAABBMsA=
Date: Mon, 2 Dec 2019 10:06:23 +0000
Message-ID: <DBBPR03MB5415CB7A89FBBF974FF284E7EE430@DBBPR03MB5415.eurprd03.prod.outlook.com>
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>
In-Reply-To: <CAOj+MME2EM52zF8j0N6+8kYpkPz2AN2JP0uMP4JYZcxOgXqGcw@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [197.155.81.57]
x-ms-publictraffictype: Email
x-ms-office365-filtering-ht: Tenant
x-ms-office365-filtering-correlation-id: 89757f9d-794e-4eac-4150-08d7770f4971
x-ms-traffictypediagnostic: DBBPR03MB5223:
x-microsoft-antispam-prvs: <DBBPR03MB522394ACAD35418605D06965EE430@DBBPR03MB5223.eurprd03.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:883;
x-forefront-prvs: 0239D46DB6
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(366004)(346002)(136003)(39860400002)(396003)(376002)(199004)(51444003)(189003)(54094003)(6246003)(8936002)(81156014)(81166006)(54896002)(6306002)(236005)(9686003)(8676002)(86362001)(66574012)(186003)(66066001)(606006)(11346002)(440504004)(446003)(256004)(76176011)(25786009)(517774005)(52536014)(30864003)(71190400001)(561944003)(71200400001)(478600001)(14454004)(966005)(4326008)(6916009)(5070765005)(26005)(102836004)(14444005)(6506007)(10916006)(45080400002)(33656002)(53546011)(74316002)(55016002)(64756008)(2906002)(6436002)(229853002)(54906003)(7696005)(7736002)(66946007)(66556008)(66446008)(66476007)(76116006)(5660300002)(316002)(6116002)(790700001)(3846002)(99286004)(579004)(559001); DIR:OUT; SFP:1102; SCL:1; SRVR:DBBPR03MB5223; H:DBBPR03MB5415.eurprd03.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: UnsXFmUic6XAMF1jS9DMQxXyMzGnsD9iRhisLKNMKNuRW0tshiU2+0HlVYdkn9xRSe18m539+kVGpb1JGmJxRiVxbfoVyFn8+BjMO1GojVgJz5+4jOTl0AF6/nJv95cAoI5DNM2tIQSlkCPqOvFo+UZnHPQen7f8HaiZ5fIQ++Ov6HuYAROe6ofyqZ/L1Mh2k/xbmnfNG3rHVz6lz5camr0UrahJ2jXQEt8pjgl+EnTcYoVQceO6x5KDWd2yqBUg6qK5H/LQ5ao54sHxYMEyj/los06PMN29IhLqVowyHrYlpJSbPhdeYZxVdxbyj73qFDOiGcP953qj+tkh/GAr0ZWZjeoe67PV1bAPxQSST/gq03uhHo9BothadBV7MfQ4IB3LsOr33xRKMbkax1APQf5j6pPNt/bblKm4TAy72binLxinDvJzt4IR55odIMuPes5G4dfPggxuu9VK2hgQH8mOrvtTnkENjvrX/dEBQkc=
x-ms-exchange-transport-forked: True
MIME-Version: 1.0
X-OriginatorOrg: liquidtelecom.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 89757f9d-794e-4eac-4150-08d7770f4971
X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Dec 2019 10:06:23.5678 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 68792612-0f0e-46cb-b16a-fcb82fd80cb1
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: cMW5Zjh0hbZ7EvgZMx2Esb8ty6NTf8loVTtaoUfv7GcmTm6vQK+//W5FEYbG1YW6f8ui6P5g/oSymt9V153/49aMVmsAWLqcIkLN2WzOXBQ=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DBBPR03MB5223
X-MC-Unique: sxWXPyzwPbGRZotVIOOzug-1
X-Mimecast-Spam-Score: 0
Content-Type: multipart/alternative; boundary="_000_DBBPR03MB5415CB7A89FBBF974FF284E7EE430DBBPR03MB5415eurp_"
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-bfd/gFdrij_UD0rqEO-jg6x3FVYPf-s>
X-Mailman-Approved-At: Mon, 02 Dec 2019 06:32:34 -0800
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:08:06 -0000

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<mailto: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.


Node validation as defined in the SR-TE drafts is limited to presence in the IGP
Since SR-TE path injection may be done through reflectors – using target communities – the point of communication into the network is not necessarily the head end of the tunnel and the point of injection may be entirely unaware of the implications of the path that’s being inserted.

By utilizing what is contained in this draft to build context tables at the head end of an inserted tunnel on an automated basis – this solves a problem that currently exists that S-BFD simply cannot solve without modification to the srte policy insertion drafts that would allow for automated building of S-BFD checks – which in and of itself could prove challenging considering the complexity of this.

That is not to say in any way that both s-bfd and potentially other mechanisms do not have use cases – but as an operator – this draft would certainly provide a better mechanism for constant path validation than anything we currently have (which is based on steered packets that leave the controller and return to the controller through the use of SR packets and binding sids).

Just my 2c

Thanks

Andrew


From: spring <spring-bounces@ietf.org<mailto:spring-bounces@ietf.org>> On Behalf Of Shraddha Hegde
Sent: Monday, 2 December 2019 10:24
To: Alexander Vainshtein <Alexander.Vainshtein@ecitele.com<mailto:Alexander.Vainshtein@ecitele.com>>
Cc: spring@ietf.org<mailto:spring@ietf.org>; rtg-bfd@ietf.org<mailto:rtg-bfd@ietf.org>; Robert Raszuk <robert@raszuk.net<mailto:robert@raszuk.net>>; rtgwg@ietf.org<mailto:rtgwg@ietf.org>
Subject: Re: [spring] Draft for Node protection of intermediate nodes in SR Paths

Sasha,

We are in agreement on separating the trigger from the protection mechanism.

> In any case I think that it woyld make sense to separate the protection scheme proposed in the draft from specific triggers for its activation >similar to how this has been done in MPLS Egress Protection Framework draft.

I’ll add text in the next revision for this.

Rgds
Shraddha


From: Alexander Vainshtein <Alexander.Vainshtein@ecitele.com<mailto:Alexander.Vainshtein@ecitele.com>>
Sent: Monday, December 2, 2019 12:24 PM
To: Shraddha Hegde <shraddha@juniper.net<mailto:shraddha@juniper.net>>
Cc: spring@ietf.org<mailto:spring@ietf.org>; rtgwg@ietf.org<mailto:rtgwg@ietf.org>; rtg-bfd@ietf.org<mailto:rtg-bfd@ietf.org>; Robert Raszuk <robert@raszuk.net<mailto:robert@raszuk.net>>
Subject: Re: [spring] Draft for Node protection of intermediate nodes in SR Paths

Shraddha,
Lots of thanks for athe tesponse.

I probably did not express myself clearly enough. I will try to fix thst now, and I apologise in advance for a long email.

I have not been speaking about end-yo-end protecyion, only about local protection against failure of an intermediate (a.k.a. pinned) node of an SR path and, specifically, triggers for such protection. This context has been actually defined by Robert in his original comment.

To the best of my understanding, Robert's concern was that failure of the link beteeen the pinned node of a SR path and its adjacency (the penultimate node of the Segment represented by the Node SID of the pinned node) is not a good enough indication of the pinned node failure.

I agree with this statement even if my understanding of a good indication differs from Robert's:
- I think that it is not sufficiently specific and therefore could result in flapping (local node protection activated and then released)
-Robert's concern, to the best of my understanding, was that it could miss some failures (e.g. the Fabric failure).

Therefore I have suggested two possibilities for more specific and more rrliabke detection of failure of the pinned node by its adjacency:

1. Run a multi-hop IP BFD session between the peniltimate node ans the pinned ones using prefixes acting as Node SIDs of this pair.  This wiuld ignore link failures but locally detect such node failurs as power-down or crash.

2.  Run S-BFD sessions to all other adjacencies of the pinned node using in each case a list of two SIDs: the protected Adj-SID to the pinned node followed by tge Node SID of the other adjacency, ans declare pinned node failure when all these sessions fail. This would again ignore failure of the link between the penultimate node and the pinned node but detect various real failures of the pinned node, e.g. failure of its Fabric.

In any case I think that it woyld make sense to separate the protection scheme proposed in the draft from specific triggers for its activation similar to how this has been done in MPLS Egress Protection Framework draft.

My 2c.






Get Outlook for Android<https://urldefense.com/v3/__https:/aka.ms/ghei36__;!8WoA6RjC81c!QAhYaA0qhoUZ3yxQWl05Ap12CMR-J-RTL_O_d_wKElC5ktZrPekfTDhLH6GPZiIH$>

________________________________
From: Shraddha Hegde <shraddha@juniper.net<mailto:shraddha@juniper.net>>
Sent: Monday, December 2, 2019, 06:10
To: Alexander Vainshtein; Robert Raszuk
Cc: spring@ietf.org<mailto:spring@ietf.org>; rtgwg@ietf.org<mailto:rtgwg@ietf.org>; rtg-bfd@ietf.org<mailto:rtg-bfd@ietf.org>
Subject: RE: [spring] Draft for Node protection of intermediate nodes in SR Paths

Robert/Sasha,


S-BFD based mechanism is  head-end triggered protection. It is not a local protection.
S-BFD mechanism is orthogonal to the mechanism described in this draft and an operator can
choose what kind of protection makes more sense to his/her network.

In many cases, node-protecting backup path will be different from link-protecting/SRLG protecting backup path.
If you really want to use link-protecting backup path when link fails and node protecting backup path when node fails,
You will have to download both link protecting and node-protecting backup paths in FIB and detect which
failure really happened and have the ability in hardware to use appropriate backup path. None of these
is in the scope of this document.

Rgds
Shraddha


From: Alexander Vainshtein <Alexander.Vainshtein@ecitele.com<mailto:Alexander.Vainshtein@ecitele.com>>
Sent: Saturday, November 23, 2019 8:15 PM
To: Robert Raszuk <robert@raszuk.net<mailto:robert@raszuk.net>>; Shraddha Hegde <shraddha@juniper.net<mailto:shraddha@juniper.net>>
Cc: spring@ietf.org<mailto:spring@ietf.org>; rtgwg@ietf.org<mailto:rtgwg@ietf.org>; rtg-bfd@ietf.org<mailto:rtg-bfd@ietf.org>
Subject: Re: [spring] Draft for Node protection of intermediate nodes in SR Paths

Robert,
On the second thought, for the purpose of this draft (i.e. in the scope of SR) it is possible to implement your suggestion by running S-BFD sessions between R7 (as the initiator) and each other adjacency of R8  (acting as Reflectors) of a SR policy with list of two SIDs:
- protected adjacency between R7 and R8
- Node SID of the specific "other" adjacency  of R8.

If all these sessions fail, R7 can reliably consider R8 as failed.

I am not sure this would be much better than multi-hop IP BFD, and it looks much more complicated to me.


What do you think?




Get Outlook for Android<https://urldefense.com/v3/__https:/clicktime.symantec.com/3MR8y7CviGLkS3kzg1UybRv6H2?u=https*3A*2F*2Furldefense.com*2Fv3*2F__https*3A*2Faka.ms*2Fghei36__*3B*218WoA6RjC81c*21Xo-D7e5MfUeTOyV17KUflgSI002KCmsw_EjxLc9pxA6sJ1EbrioDE0VmgnYBhAbc*24__;JSUlJSUlJSUlJSUl!8WoA6RjC81c!QAhYaA0qhoUZ3yxQWl05Ap12CMR-J-RTL_O_d_wKElC5ktZrPekfTDhLH1YVygZC$>

________________________________
From: Alexander Vainshtein <Alexander.Vainshtein@ecitele.com<mailto:Alexander.Vainshtein@ecitele.com>>
Sent: Saturday, November 23, 2019, 13:15
To: Robert Raszuk; Shraddha Hegde
Cc: spring@ietf.org<mailto:spring@ietf.org>; rtgwg@ietf.org<mailto:rtgwg@ietf.org>; rtg-bfd@ietf.org<mailto:rtg-bfd@ietf.org>
Subject: Re: [spring] Draft for Node protection of intermediate nodes in SR Paths

Robert,
Lots of thanks for a prompt response.

I respectfully disagree with your statement that BFD implementation  is usually offloaded to the HW of the ingress line card.  I do not think this can wor for MH BFD sessions because the ingress and egress line cards are not known in advance and change with the routing changes
A good  multi-hop BFD implementation should be ready to overcome this.. There are many ways to achieve that. A naive implementation that runs in SW of the control card is also possible of course. And they would sensd and receive packets

My 2c.
Get Outlook for Android<https://urldefense.com/v3/__https:/clicktime.symantec.com/3MR8y7CviGLkS3kzg1UybRv6H2?u=https*3A*2F*2Furldefense.com*2Fv3*2F__https*3A*2Faka.ms*2Fghei36__*3B*218WoA6RjC81c*21Xo-D7e5MfUeTOyV17KUflgSI002KCmsw_EjxLc9pxA6sJ1EbrioDE0VmgnYBhAbc*24__;JSUlJSUlJSUlJSUl!8WoA6RjC81c!QAhYaA0qhoUZ3yxQWl05Ap12CMR-J-RTL_O_d_wKElC5ktZrPekfTDhLH1YVygZC$>

________________________________
From: Robert Raszuk <robert@raszuk.net<mailto:robert@raszuk.net>>
Sent: Saturday, November 23, 2019, 12:37
To: Alexander Vainshtein; Shraddha Hegde
Cc: spring@ietf.org<mailto:spring@ietf.org>; rtgwg@ietf.org<mailto:rtgwg@ietf.org>; rtg-bfd@ietf.org<mailto:rtg-bfd@ietf.org>
Subject: Re: [spring] Draft for Node protection of intermediate nodes in SR Paths

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.

Thx,
Robert.


On Sat, Nov 23, 2019 at 10:00 AM Alexander Vainshtein <Alexander.Vainshtein@ecitele.com<mailto:Alexander.Vainshtein@ecitele.com>> 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<https://urldefense.com/v3/__https:/clicktime.symantec.com/3NbK72q2ca668aVyMaT7Esn6H2?u=https*3A*2F*2Furldefense.com*2Fv3*2F__https*3A*2Fclicktime.symantec.com*2F3CfVQPtBYBAPbHUSngEVNQD6H2*3Fu*3Dhttps*2A3A*2A2F*2A2Faka.ms*2A2Fghei36__*3BJSUlJQ*218WoA6RjC81c*21Xo-D7e5MfUeTOyV17KUflgSI002KCmsw_EjxLc9pxA6sJ1EbrioDE0Vmgujy50EN*24__;JSUlJSUlJSUlJSUlJSUlJSUl!8WoA6RjC81c!QAhYaA0qhoUZ3yxQWl05Ap12CMR-J-RTL_O_d_wKElC5ktZrPekfTDhLH7q73pAh$>

________________________________
From: spring <spring-bounces@ietf.org<mailto:spring-bounces@ietf.org>> on behalf of Robert Raszuk <robert@raszuk.net<mailto:robert@raszuk.net>>
Sent: Friday, November 22, 2019, 11:22
To: Shraddha Hegde
Cc: spring@ietf.org<mailto:spring@ietf.org>; rtgwg@ietf.org<mailto:rtgwg@ietf.org>
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=40juniper.net@dmarc.ietf..org<mailto:40juniper.net@dmarc.ietf.org>> 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.
https://tools.ietf.org/html/draft-hegde-spring-node-protection-for-sr-te-paths-05<https://urldefense.com/v3/__https:/clicktime.symantec.com/3HvrzHXwAou2JruETj6jcyF6H2?u=https*3A*2F*2Furldefense.com*2Fv3*2F__https*3A*2Fclicktime.symantec.com*2F375SW6TBGPi2mN7V9YeVWGg6H2*3Fu*3Dhttps*2A3A*2A2F*2A2Ftools.ietf.org*2A2Fhtml*2A2Fdraft-hegde-spring-node-protection-for-sr-te-paths-05__*3BJSUlJSU*218WoA6RjC81c*21Xo-D7e5MfUeTOyV17KUflgSI002KCmsw_EjxLc9pxA6sJ1EbrioDE0Vmgg0xmj_C*24__;JSUlJSUlJSUlJSUlJSUlJSUlJQ!8WoA6RjC81c!QAhYaA0qhoUZ3yxQWl05Ap12CMR-J-RTL_O_d_wKElC5ktZrPekfTDhLH9RfbOqT$>

Review and comments solicited.

Rgds
Shraddha

_______________________________________________
rtgwg mailing list
rtgwg@ietf.org<mailto:rtgwg@ietf.org>
https://www.ietf.org/mailman/listinfo/rtgwg<https://urldefense.com/v3/__https:/clicktime.symantec.com/37ZvNSMSAddpxDGDQPm7oVA6H2?u=https*3A*2F*2Furldefense.com*2Fv3*2F__https*3A*2Fclicktime.symantec.com*2F35M9j5zHTaSYRwVh5RP6xcB6H2*3Fu*3Dhttps*2A3A*2A2F*2A2Fwww.ietf.org*2A2Fmailman*2A2Flistinfo*2A2Frtgwg__*3BJSUlJSUl*218WoA6RjC81c*21Xo-D7e5MfUeTOyV17KUflgSI002KCmsw_EjxLc9pxA6sJ1EbrioDE0VmgvV9Y4sM*24__;JSUlJSUlJSUlJSUlJSUlJSUlJSU!8WoA6RjC81c!QAhYaA0qhoUZ3yxQWl05Ap12CMR-J-RTL_O_d_wKElC5ktZrPekfTDhLH_pG5Prx$>



___________________________________________________________________________

This e-mail message is intended for the recipient only and contains information which is
CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have received this
transmission in error, please inform us by e-mail, phone or fax, and then delete the original
and all copies thereof.
___________________________________________________________________________


___________________________________________________________________________

This e-mail message is intended for the recipient only and contains information which is
CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have received this
transmission in error, please inform us by e-mail, phone or fax, and then delete the original
and all copies thereof.
___________________________________________________________________________