Re: [spring] Spring protection - determining applicability

Mach Chen <mach.chen@huawei.com> Mon, 03 August 2020 03:30 UTC

Return-Path: <mach.chen@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 1BBEF3A058F for <spring@ietfa.amsl.com>; Sun, 2 Aug 2020 20:30:24 -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 LoFzi-8eNkQw for <spring@ietfa.amsl.com>; Sun, 2 Aug 2020 20:30: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 9A2AB3A053E for <spring@ietf.org>; Sun, 2 Aug 2020 20:30:22 -0700 (PDT)
Received: from lhreml722-chm.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id 24ADEF6F1852ACBB7CBC for <spring@ietf.org>; Mon, 3 Aug 2020 04:30:20 +0100 (IST)
Received: from lhreml722-chm.china.huawei.com (10.201.108.73) by lhreml722-chm.china.huawei.com (10.201.108.73) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Mon, 3 Aug 2020 04:30:19 +0100
Received: from DGGEML423-HUB.china.huawei.com (10.1.199.40) by lhreml722-chm.china.huawei.com (10.201.108.73) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA) id 15.1.1913.5 via Frontend Transport; Mon, 3 Aug 2020 04:30:19 +0100
Received: from DGGEML510-MBS.china.huawei.com ([169.254.3.246]) by dggeml423-hub.china.huawei.com ([10.1.199.40]) with mapi id 14.03.0487.000; Mon, 3 Aug 2020 11:30:15 +0800
From: Mach Chen <mach.chen@huawei.com>
To: "Joel M. Halpern" <jmh@joelhalpern.com>, "spring@ietf.org" <spring@ietf.org>
Thread-Topic: [spring] Spring protection - determining applicability
Thread-Index: AQHWaSfMKyLC4PEJ3U24t3+Dp7H1BakluDxQ
Date: Mon, 3 Aug 2020 03:30:14 +0000
Message-ID: <F73A3CB31E8BE34FA1BBE3C8F0CB2AE297D63B99@dggeml510-mbs.china.huawei.com>
References: <7e29a863-70e9-f0a8-638f-5151348be515@joelhalpern.com>
In-Reply-To: <7e29a863-70e9-f0a8-638f-5151348be515@joelhalpern.com>
Accept-Language: en-US, zh-CN
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.108.243.140]
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/eRUuMtsjnCBfTwDLIwJeZcFwnjk>
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 03:30:24 -0000

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