Re: [spring] Spring protection - determining applicability

"Chengli (Cheng Li)" <c.l@huawei.com> Mon, 03 August 2020 09:14 UTC

Return-Path: <c.l@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 BAE0C3A0CFA for <spring@ietfa.amsl.com>; Mon, 3 Aug 2020 02:14:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.001
X-Spam-Level:
X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[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 KkG1-N9Meld0 for <spring@ietfa.amsl.com>; Mon, 3 Aug 2020 02:14:22 -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 5532C3A0CF9 for <spring@ietf.org>; Mon, 3 Aug 2020 02:14:22 -0700 (PDT)
Received: from lhreml704-chm.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id 248B1FB22F7D75A63275 for <spring@ietf.org>; Mon, 3 Aug 2020 10:14:18 +0100 (IST)
Received: from lhreml704-chm.china.huawei.com (10.201.108.53) by lhreml704-chm.china.huawei.com (10.201.108.53) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1913.5; Mon, 3 Aug 2020 10:14:17 +0100
Received: from DGGEML424-HUB.china.huawei.com (10.1.199.41) by lhreml704-chm.china.huawei.com (10.201.108.53) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P256) id 15.1.1913.5 via Frontend Transport; Mon, 3 Aug 2020 10:14:17 +0100
Received: from DGGEML529-MBX.china.huawei.com ([169.254.6.133]) by dggeml424-hub.china.huawei.com ([10.1.199.41]) with mapi id 14.03.0487.000; Mon, 3 Aug 2020 17:14:08 +0800
From: "Chengli (Cheng Li)" <c.l@huawei.com>
To: Mach Chen <mach.chen@huawei.com>, "Joel M. Halpern" <jmh@joelhalpern.com>, "spring@ietf.org" <spring@ietf.org>
Thread-Topic: [spring] Spring protection - determining applicability
Thread-Index: AQHWaSfMxHlh+yzcCkewTBiyswjXMaklNGAAgACNQuA=
Date: Mon, 3 Aug 2020 09:14:07 +0000
Message-ID: <C7C2E1C43D652C4E9E49FE7517C236CB02B43EDD@dggeml529-mbx.china.huawei.com>
References: <7e29a863-70e9-f0a8-638f-5151348be515@joelhalpern.com> <F73A3CB31E8BE34FA1BBE3C8F0CB2AE297D63B99@dggeml510-mbs.china.huawei.com>
In-Reply-To: <F73A3CB31E8BE34FA1BBE3C8F0CB2AE297D63B99@dggeml510-mbs.china.huawei.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.108.243.130]
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/A3ybSZmORCpsBvcZH8-pM2vVLZo>
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: Mon, 03 Aug 2020 09:14:24 -0000

Hi Joel and Mach,

Yes, we should consider to bypass or not bypass the node in different cases.

Like Joel said, we can not skip the firewall, while it can be fine to skip a TE node, if the repair path meets the TE SLA requirements.

Regarding these two cases, AFAIK, two documents describes the related mechanisms
* Bypass:  https://tools.ietf.org/html/draft-chen-bess-srv6-service-bypass-sid-00
* No bypass: https://datatracker.ietf.org/doc/draft-li-rtgwg-enhanced-ti-lfa/

Hope it help the discussion, and comments are welcome! 

Respect,
Cheng



-----Original Message-----
From: spring [mailto:spring-bounces@ietf.org] On Behalf Of Mach Chen
Sent: Monday, August 3, 2020 11:30 AM
To: Joel M. Halpern <jmh@joelhalpern.com>om>; spring@ietf.org
Subject: Re: [spring] Spring protection - determining applicability

Hi Joel,

I think this is a good point that may not be discussed in the past. And I also don't think there is a "can be bypassed" indication in the routing advertisement for now.

IMHO, the information advertised by routing is neutral, such information (can or cannot be bypassed) is more path specific, thus normally the controller should be responsible for deciding whether/which SID can be bypassed. 

Best regards,
Mach

> -----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

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