Re: [spring] Spring protection - determining applicability

Huzhibo <huzhibo@huawei.com> Tue, 04 August 2020 13:32 UTC

Return-Path: <huzhibo@huawei.com>
X-Original-To: spring@ietfa.amsl.com
Delivered-To: spring@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D827A3A0B71 for <spring@ietfa.amsl.com>; Tue, 4 Aug 2020 06:32:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 oHRumwOpszDK for <spring@ietfa.amsl.com>; Tue, 4 Aug 2020 06:32:43 -0700 (PDT)
Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 676043A0B6B for <spring@ietf.org>; Tue, 4 Aug 2020 06:32:43 -0700 (PDT)
Received: from lhreml729-chm.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id 12F6A2D048052B120B20 for <spring@ietf.org>; Tue, 4 Aug 2020 14:32:40 +0100 (IST)
Received: from lhreml729-chm.china.huawei.com (10.201.108.80) by lhreml729-chm.china.huawei.com (10.201.108.80) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Tue, 4 Aug 2020 14:32:39 +0100
Received: from DGGEMM422-HUB.china.huawei.com (10.1.198.39) by lhreml729-chm.china.huawei.com (10.201.108.80) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA) id 15.1.1913.5 via Frontend Transport; Tue, 4 Aug 2020 14:32:39 +0100
Received: from DGGEMM509-MBX.china.huawei.com ([169.254.9.142]) by dggemm422-hub.china.huawei.com ([10.1.198.39]) with mapi id 14.03.0487.000; Tue, 4 Aug 2020 21:32:36 +0800
From: Huzhibo <huzhibo@huawei.com>
To: "Joel M. Halpern" <jmh@joelhalpern.com>, "spring@ietf.org" <spring@ietf.org>
Thread-Topic: [spring] Spring protection - determining applicability
Thread-Index: AQHWaSfMvaROiWEXVU+aZWRNMojsJakn8pLg
Date: Tue, 4 Aug 2020 13:32:36 +0000
Message-ID: <06CF729DA0D6854E8C1E5121AC3330DFAF728C2D@dggemm509-mbx.china.huawei.com>
References: <7e29a863-70e9-f0a8-638f-5151348be515@joelhalpern.com>
In-Reply-To: <7e29a863-70e9-f0a8-638f-5151348be515@joelhalpern.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.108.202.126]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/spring/sSl7fa8TsZ1lEsjCQZgtftXSJKk>
Subject: Re: [spring] Spring protection - determining applicability
X-BeenThere: spring@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" <spring.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/spring>, <mailto:spring-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/spring/>
List-Post: <mailto:spring@ietf.org>
List-Help: <mailto:spring-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/spring>, <mailto:spring-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 04 Aug 2020 13:32:45 -0000

Hi Joel and all:

    I think node protected is used when the SLA of a path cannot be quickly repaired. E2E detection cannot be deployed in some scenarios. As a result, the faulty path cannot be repaired at the headend. 
    To prevent SR policy from bypassing Service Sid, if the Per Sid forwarding state is not introduced on other nodes, the advertise Sid Not Bypass Flag is useless. Therefore, extending the Not Bypass Flag in the SRH Flag may be an effective method. The following document is trying to solve such problem.https://datatracker.ietf.org/doc/draft-li-rtgwg-enhanced-ti-lfa/?include_text=1

Thanks

Zhibo

-----Original Message-----
From: spring [mailto:spring-bounces@ietf.org] On Behalf Of Joel M. Halpern
Sent: Monday, August 3, 2020 7:51 AM
To: spring@ietf.org
Subject: [spring] Spring protection - determining applicability

(WG Chair hat Off, this is merely a note from a slightly confused WG
participant.)

I have been reading the various repair drafts, and the various networks programming and service programming draft, and I am trying to figure out one aspect of the combination.

How does a node that is doing some form of bypass (suppose, for simplicity, it is Node N2 deciding to bypass the next SID for a failed node N3) know that it is safe to do so?

If the path was just for TE, then it is "safe" if the new path meets the TE criteria.  or maybe it is safe if it is even close, as long as it is not used for too long.

But what if the node were a Firewall, included to meet legal requirements?
Or was some other necessary programmatic transform (wince we are deliberately vague about what nodes can do when asked suitably.)

Is there some "can be bypassed" indication in the routing advertisements that I missed?

Thank you,
Yours,
Joel

_______________________________________________
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring