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

Andrew Alston <Andrew.Alston@liquidtelecom.com> Mon, 02 December 2019 10:28 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 78DB2120073 for <rtg-bfd@ietfa.amsl.com>; Mon, 2 Dec 2019 02:28:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j2IoK6mPWQ6P for <rtg-bfd@ietfa.amsl.com>; Mon, 2 Dec 2019 02:27:59 -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 B33C61200D7 for <rtg-bfd@ietf.org>; Mon, 2 Dec 2019 02:27:58 -0800 (PST)
Received: from EUR04-HE1-obe.outbound.protection.outlook.com (mail-he1eur04lp2051.outbound.protection.outlook.com [104.47.13.51]) (Using TLS) by relay.mimecast.com with ESMTP id uk-mta-128-PmDPvwdnPYOCRlQPcfNIzw-1; Mon, 02 Dec 2019 10:27:53 +0000
Received: from DBBPR03MB5415.eurprd03.prod.outlook.com (20.179.47.79) by DBBPR03MB5397.eurprd03.prod.outlook.com (20.179.47.203) 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 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:27:51 +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+ujmkEsxaFPQAMBq8AADGDFIAAA2XugAABUkKAAAdRE4ABsInvgAADpWmAAAEKboAAA6iU8AABbEuAAABBMsAAAJvxgAAALybA
Date: Mon, 2 Dec 2019 10:27:51 +0000
Message-ID: <DBBPR03MB5415A3FC8FC2FE7D996457C7EE430@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> <DBBPR03MB5415CB7A89FBBF974FF284E7EE430@DBBPR03MB5415.eurprd03.prod.outlook.com> <CAOj+MMEZR8V8wyUu92Rmm_26ojqnqnpM9wH67A04EbEOwHRxDw@mail.gmail.com>
In-Reply-To: <CAOj+MMEZR8V8wyUu92Rmm_26ojqnqnpM9wH67A04EbEOwHRxDw@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: 20c39d3c-b294-4d11-228c-08d777124920
x-ms-traffictypediagnostic: DBBPR03MB5397:
x-microsoft-antispam-prvs: <DBBPR03MB5397FB2267F84E4C7532FFFDEE430@DBBPR03MB5397.eurprd03.prod.outlook.com>
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; H:DBBPR03MB5415.eurprd03.prod.outlook.com; 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-OriginatorOrg: liquidtelecom.com
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: <https://mailarchive.ietf.org/arch/msg/rtg-bfd/mpVeqjStGTQlNgpYYqo2ZHC2eVc>
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:28:02 -0000

Thanks,

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.

Thanks

Andrew

From: Robert Raszuk <robert@raszuk.net>
Sent: Monday, 2 December 2019 13:14
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


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-akiya-bfd-seamless-sr-04>

https://tools.ietf.org/html/draft-ali-spring-bfd-sr-policy-02<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<mailto: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<mailto:robert@raszuk.net>>
Sent: Monday, 2 December 2019 12:50
To: Andrew Alston <Andrew.Alston@liquidtelecom.com<mailto:Andrew.Alston@liquidtelecom.com>>
Cc: Shraddha Hegde <shraddha=40juniper.net@dmarc.ietf.org<mailto:40juniper.net@dmarc.ietf.org>>; Alexander Vainshtein <Alexander.Vainshtein@ecitele.com<mailto:Alexander.Vainshtein@ecitele.com>>; spring@ietf.org<mailto:spring@ietf.org>; rtg-bfd@ietf.org<mailto:rtg-bfd@ietf.org>; rtgwg@ietf.org<mailto: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.