Re: [spring] Spring protection - determining applicability

Alexander Vainshtein <Alexander.Vainshtein@rbbn.com> Mon, 03 August 2020 06:36 UTC

Return-Path: <alexander.vainshtein@rbbn.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 92C993A0768 for <spring@ietfa.amsl.com>; Sun, 2 Aug 2020 23:36:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.312
X-Spam-Level:
X-Spam-Status: No, score=0.312 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, PDS_BTC_ID=0.498, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=rbbn.com
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 oN4Jrger-Qi1 for <spring@ietfa.amsl.com>; Sun, 2 Aug 2020 23:36:39 -0700 (PDT)
Received: from us-smtp-delivery-181.mimecast.com (us-smtp-delivery-181.mimecast.com [63.128.21.181]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B1C243A064A for <spring@ietf.org>; Sun, 2 Aug 2020 23:36:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rbbn.com; s=mimecast20180816; t=1596436598; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=aeM5/VjCifB6C24kBxjp328kEbjOeaCeWnYfLk+D/A0=; b=qhAlAGlt5fuiDMirJytXiE5q39/BgwQVW77paKEZ/jWworT1GzxvppRFyt0bjR3YNIfsWs CU8JvzhJCkvOoaVyjGT1P7kMCyhgzkfb5Usvkl5WGWIixe1ORs9yb59UilFldT7cZCifo3 DtgWHcFznUKuV9a3H2rfmzRdZn9b+7w=
Received: from AZWPVEXEdge02.ecitele.com (13.81.42.245 [13.81.42.245]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-306-4n8Pjjb-OMO1vffwwiWXGQ-3; Mon, 03 Aug 2020 02:36:36 -0400
X-MC-Unique: 4n8Pjjb-OMO1vffwwiWXGQ-3
Received: from EUR01-HE1-obe.outbound.protection.outlook.com (104.47.0.52) by AZWPVEXEdge02.ecitele.com (10.0.2.5) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.595.3; Mon, 3 Aug 2020 09:36:35 +0300
Received: from AM0PR03MB4499.eurprd03.prod.outlook.com (2603:10a6:208:c4::33) by AM0PR03MB5602.eurprd03.prod.outlook.com (2603:10a6:208:171::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3239.20; Mon, 3 Aug 2020 06:36:33 +0000
Received: from AM0PR03MB4499.eurprd03.prod.outlook.com ([fe80::8920:3fbc:c06a:49a1]) by AM0PR03MB4499.eurprd03.prod.outlook.com ([fe80::8920:3fbc:c06a:49a1%6]) with mapi id 15.20.3239.021; Mon, 3 Aug 2020 06:36:33 +0000
From: Alexander Vainshtein <Alexander.Vainshtein@rbbn.com>
To: Mach Chen <mach.chen@huawei.com>, "Joel M. Halpern" <jmh@joelhalpern.com>
CC: "spring@ietf.org" <spring@ietf.org>
Thread-Topic: [spring] Spring protection - determining applicability
Thread-Index: AQHWaSfCODf9rN3izE+yW9JumUctqqklun0AgAAq2JA=
Date: Mon, 3 Aug 2020 06:36:33 +0000
Message-ID: <AM0PR03MB4499A048326D9A2E8DA5F46B9D4D0@AM0PR03MB4499.eurprd03.prod.outlook.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: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [79.183.63.9]
x-ms-publictraffictype: Email
x-ms-office365-filtering-ht: Tenant
x-ms-office365-filtering-correlation-id: 766261f1-556f-49a7-b262-08d837779084
x-ms-traffictypediagnostic: AM0PR03MB5602:
x-microsoft-antispam-prvs: <AM0PR03MB56023AFD8B65E1BB5ABDFE589D4D0@AM0PR03MB5602.eurprd03.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:9508;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: W39iklkAgnOnS+bjDBvvGE7OA4U5PQ8eRkT3EG6Q6m943i6+rsUBFlQk2xa+3qfc8aZuErfDwIK7kzYHKPQcAbUjtOcWuwCu2R27hDKcuhUAZCDUWiAlmEUx35T9qjHjbgOXLx8R/h95g0Ptx1GfdLK/qC01ygjCj7F4XXwiHWT3NZw5nxcQh7P0qjftwI3W3lhe6Y3BGSxy4PloaHiHXleRzoO8O9nzvgA3Nct1mMqYklkN5UgkD0yMiUIVrR/5mN/qUs/57Hz9rB2f4hPfrt0rVos6wMYA2USraJWzC4bXZN2Yo3ZPCCyoQuxCtU4ZX0Kh2HAT3Hwo1FCVd4/f863RMcyOMtA2RgUsUXUx77X7i0JOXMnI2rgm/PbkHfiZyR8g/cbDkkE2ymh3mmwteg==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM0PR03MB4499.eurprd03.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(136003)(376002)(346002)(39860400002)(396003)(366004)(7696005)(6506007)(53546011)(8676002)(83380400001)(64756008)(66476007)(66446008)(66556008)(66946007)(33656002)(76116006)(71200400001)(186003)(26005)(166002)(966005)(52536014)(478600001)(316002)(5660300002)(55016002)(86362001)(110136005)(8936002)(4326008)(9686003)(2906002); DIR:OUT; SFP:1102;
x-ms-exchange-antispam-messagedata: VUxyq6qhe6loZzHFF+fW8DHuGaF12fyR/35+oDnJV40QXbH9PSdI3tPnzqxUNIqLU3O92gTKo+W3xdScSiAFAk892DZ2PYN0Ow083uyc5wCahNhf1s9hJXVCjznFJJ4ZUfQthuuqTw2Dg8wkiGFjd2dYi5QF8W25aaEjnXDh9CuRQbQZfnZwmjl+uAv6flQBzqh43BQMBPedIZgyKolKEgj5PV6ZRfCtz6LPcOsGBaV/8QtaFpz+4sGD6a8O7Et58dOiwnTWpykpzZZzv8TOp9K2H2X6RxWmW4R5nHdFoJ6lgBmXYv18cCdz5Y88hg8jESiljYxFlwxSe/Adpzy12AAA+AQ4BaP0YQb8i6gfk+ZPSeNHHhgNjJKjgj1WoNub0nHSk86diOwMo8b62yDMOZ0b0sOqoX9YBJifo1U6imHNfl+YyOAGYh0bDwTkgjPBpThe2AAfEAki80TyOmp2OFCLoDAHr7MzMRnEL1LWv12GCcUTizse91B9RJvlURZmNF+8khzHGPa5wUuluGEaAaLzTVnE76t0R22n3pep5BUW0dUntDQs+FrB2j2VbfN9hztnLkVicbOOrzsQL6eB0c0FdSBPrjAr/gegn39EnlFLTKh4RL8i0N5uEUCRgEI6z7A6KhSDgvA5sElZCdiFMQ==
x-ms-exchange-transport-forked: True
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: AM0PR03MB4499.eurprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 766261f1-556f-49a7-b262-08d837779084
X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Aug 2020 06:36:33.7566 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 2c514a61-08de-4519-b4c0-921fef62c42a
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: L7YzuarP2fzUddBF/BOWL7NXudszgPl9t0q/WIU9jtURI2v2QeQZofbOGp+ewkOWLM6L5PjUoeClyDhyfdvpzQ==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR03MB5602
X-Mimecast-Spam-Score: 0
X-Mimecast-Originator: rbbn.com
Content-Type: multipart/alternative; boundary="_000_AM0PR03MB4499A048326D9A2E8DA5F46B9D4D0AM0PR03MB4499eurp_"
Archived-At: <https://mailarchive.ietf.org/arch/msg/spring/HCf6NoyLvKcvVrmVXN0J3WVKn20>
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 06:36:42 -0000

Mach, Joel and all,



I think that in most cases:

1.       There is clear differentiation between "topological" and "service" instructions in SID advertisements. E.g.:

o   IGP Prefix Node SIDs IGP Adj-SIDs (identified as such in the corresponding IGP advertisements) represent topological instructions

o   Service SIDs for SRv6 (see SRv6 BGP-Based Overlay Services<https://datatracker.ietf.org/doc/html/draft-ietf-bess-srv6-services-04> draft) unsurprisingly represent "service" instructions

2.       Segments that represent topological instructions can be bypassed, while segments that represent service instructions require alternative protection mechanisms.



This view seems to be aligned with RFC 8402<https://tools.ietf.org/html/rfc8402> that says in Section 1:



   In the context of an IGP-based distributed control plane, two

   topological segments are defined: the IGP-Adjacency segment and the

   IGP-Prefix segment.



   In the context of a BGP-based distributed control plane, two

   topological segments are defined: the BGP peering segment and the

   BGP-Prefix segment.



In the case of SR-MPLS this differentiation is assumed in Section 3.4 of the Node Protection for SR-TE Path<https://datatracker.ietf.org/doc/html/draft-hegde-spring-node-protection-for-sr-te-paths-07#section-3.4> draft that says:



   The node protection mechanism described in the previous sections

   depends on the assumption that the label immediately below the top

   label in the label stack is understood in the IGP domain.  When the

   provider edge routers exchange service labels via BGP or some other

   non-IGP mechanism the bottom label is not understood in the IGP

   domain.



   The egress node protection mechanisms described in the draft

   [RFC8679<https://datatracker.ietf.org/doc/html/rfc8679>] is applicable to this use case and no additional changes

   will be required for SR based networks



The scenarios in which  differentiation between "topological" and "service" instructions is broken are indeed problematic. E.g., consider the use case in which a Node SID in the ERO of a SR-TE path identifies a node that acts as a firewall for all packets it receives, i.e., provides the firewall service without any dedicated service SID identifying it. One could say that the Node SID of such a node would combine topological and service instructions thus breaking the differentiation between the two.



I am not sure if usage of such "combined" SIDs could be prevented or at least discouraged.

If not, providing an ability to identify such SIDs in the advertisement mechanisms would be useful IMHO.



My 2c,

Sasha



Office: +972-39266302

Cell:      +972-549266302

Email:   Alexander.Vainshtein@ecitele.com



-----Original Message-----
From: spring <spring-bounces@ietf.org> On Behalf Of Mach Chen
Sent: Monday, August 3, 2020 6: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<mailto: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<mailto:spring@ietf.org>

> https://clicktime.symantec.com/367qhU4KiUkzW9uGC4eAvP46H2?u=https%3A%2<https://clicktime.symantec.com/367qhU4KiUkzW9uGC4eAvP46H2?u=https%3A%252>

> F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspring



_______________________________________________

spring mailing list

spring@ietf.org<mailto:spring@ietf.org>

https://clicktime.symantec.com/367qhU4KiUkzW9uGC4eAvP46H2?u=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspring


-----------------------------------------------------------------------------------------------------------------------
Notice: This e-mail together with any attachments may contain information of Ribbon Communications Inc. that
is confidential and/or proprietary for the sole use of the intended recipient.  Any review, disclosure, reliance or
distribution by others or forwarding without express permission is strictly prohibited.  If you are not the intended
recipient, please notify the sender immediately and then delete all copies, including any attachments.
-----------------------------------------------------------------------------------------------------------------------