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

Andrew Alston <> Mon, 02 December 2019 10:28 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 78DB2120073 for <>; Mon, 2 Dec 2019 02:28:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id j2IoK6mPWQ6P for <>; Mon, 2 Dec 2019 02:27:59 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id B33C61200D7 for <>; Mon, 2 Dec 2019 02:27:58 -0800 (PST)
Received: from ( []) (Using TLS) by with ESMTP id uk-mta-128-PmDPvwdnPYOCRlQPcfNIzw-1; Mon, 02 Dec 2019 10:27:53 +0000
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2495.22; Mon, 2 Dec 2019 10:27:51 +0000
Received: from ([fe80::707f:9207:45d4:82bc]) by ([fe80::707f:9207:45d4:82bc%6]) with mapi id 15.20.2495.014; Mon, 2 Dec 2019 10:27:51 +0000
From: Andrew Alston <>
To: Robert Raszuk <>
CC: Shraddha Hegde <>, Alexander Vainshtein <>, "" <>, "" <>, "" <>
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
Date: Mon, 2 Dec 2019 10:27:51 +0000
Message-ID: <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
x-ms-publictraffictype: Email
x-ms-office365-filtering-ht: Tenant
x-ms-office365-filtering-correlation-id: 20c39d3c-b294-4d11-228c-08d777124920
x-ms-traffictypediagnostic: DBBPR03MB5397:
x-microsoft-antispam-prvs: <>
x-ms-oob-tlc-oobclassifiers: OLM:4303;
x-forefront-prvs: 0239D46DB6
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(346002)(376002)(136003)(396003)(39860400002)(366004)(189003)(199004)(54906003)(55016002)(6436002)(3846002)(6116002)(52536014)(790700001)(66946007)(8676002)(33656002)(81166006)(5660300002)(81156014)(66066001)(99286004)(606006)(446003)(76116006)(316002)(8936002)(11346002)(14454004)(102836004)(54896002)(6306002)(6246003)(9686003)(6916009)(86362001)(7736002)(26005)(64756008)(66556008)(236005)(478600001)(66476007)(2906002)(229853002)(10916006)(71200400001)(71190400001)(186003)(74316002)(25786009)(66446008)(256004)(76176011)(14444005)(4326008)(53546011)(966005)(6506007)(7696005); DIR:OUT; SFP:1102; SCL:1; SRVR:DBBPR03MB5397;; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: 4tnMbO6TO523KLMStjQN14r/aXVmZ66mP+SH+Nu8/3gJfY+bAI+OsT2TZOjIdc5PKutPsckxHJ6jnh1mV5iDU6Lv6Lpzs33Z/AEKvw0+dGYtPwwSkEA6opClGsj7pstH7mJtb1J9mEibtunIbilENDG3sfhexBR6zGKDCtZ8XXzlIoU7d9U+WJtkz5YJOH6d499JVkTPa8mcwUc9ud11kg1ujsnjS0sT+deoybqThtHVaUlmvlkSly6yMQOQgTBNNU9ui08GTHoYxgelV2p0OapL33cuoA/XNdlIBo05FF+nJhRhbpc1txp1DDNVCjjYCxO0FXZQRtDxB7OVyuHRTnZa8pgY8WAmQL8FRSiadxUW7ItyfUJe3pcPaXJcjnCcnRbTbgEhjkcffThwyyvI2w1OH1oKmzUyuA0wXW+MSf2JBPjAPMDf50AQlcce/zenXn152sIjaL7zIUoe5sbhXhAOrqKxoBS360ag4yPdwOM=
x-ms-exchange-transport-forked: True
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 20c39d3c-b294-4d11-228c-08d777124920
X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Dec 2019 10:27:51.5174 (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: tCA3zOpafj26CTltkyIpddX1xm3TIwYxBZlHdhii2Mk+ZhpsrjQbf3BMPpRDv7w2EYY1lihG1fa609Y26IY2dnBVJBMyig+7DSajn/bxqAs=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DBBPR03MB5397
X-MC-Unique: PmDPvwdnPYOCRlQPcfNIzw-1
X-Mimecast-Spam-Score: 0
Content-Type: multipart/alternative; boundary="_000_DBBPR03MB5415A3FC8FC2FE7D996457C7EE430DBBPR03MB5415eurp_"
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: Mon, 02 Dec 2019 10:28:02 -0000


Some how I had missed these drafts – I will go through in further detail and then potentially comment more.  My bad for missing them and appreciate the pointers.



From: Robert Raszuk <>
Sent: Monday, 2 December 2019 13:14
To: Andrew Alston <>
Cc: Shraddha Hegde <>rg>; Alexander Vainshtein <>om>;;;
Subject: Re: [spring] Draft for Node protection of intermediate nodes in SR Paths

I encourage you to read those two documents:<><>


On Mon, Dec 2, 2019 at 11:06 AM Andrew Alston <<>> 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.


From: Robert Raszuk <<>>
Sent: Monday, 2 December 2019 12:50
To: Andrew Alston <<>>
Cc: Shraddha Hegde <<>>; Alexander Vainshtein <<>>;<>;<>;<>
Subject: Re: [spring] Draft for Node protection of intermediate nodes in SR Paths

On Mon, Dec 2, 2019 at 10:28 AM Andrew Alston <<>> 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.