Re: [spring] Spring protection - determining applicability

"Joel M. Halpern" <jmh@joelhalpern.com> Mon, 03 August 2020 16:43 UTC

Return-Path: <jmh@joelhalpern.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 D29413A0EBC for <spring@ietfa.amsl.com>; Mon, 3 Aug 2020 09:43:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 3.053
X-Spam-Level: ***
X-Spam-Status: No, score=3.053 tagged_above=-999 required=5 tests=[BITCOIN_SPAM_02=2.497, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, MISSING_HEADERS=1.207, NICE_REPLY_A=-0.949, PDS_BTC_ID=0.498, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.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 oqonFrU0DjQh for <spring@ietfa.amsl.com>; Mon, 3 Aug 2020 09:43:20 -0700 (PDT)
Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (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 8011D3A0E4A for <spring@ietf.org>; Mon, 3 Aug 2020 09:43:20 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 4BL3br2KmHz6G9nh for <spring@ietf.org>; Mon, 3 Aug 2020 09:43:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1596473000; bh=1Gi4SX8qRJ9CEbOINs8uGSG0XrZL72On3JL2ZeZQVg4=; h=Subject:Cc:References:From:Date:In-Reply-To:From; b=fdVAbz4/RZ3u7RaCh7lvFpo4kWZyKJYAjspLum4J+uEaecEc+S4aVWd1fSFa8Rhm2 qTfhK5IUfdwAyX7OvuY9HIh/bHKnBQUFrOrmos/wb8Ma9eyoMSNdmW3KG2JdK96C8Y nc+rcHHPVFszib9bTMpoBiUareL17o7vO88D13XM=
X-Quarantine-ID: <SFyH78KFoucr>
X-Virus-Scanned: Debian amavisd-new at a2.tigertech.net
Received: from [192.168.128.43] (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 4BL3bq62gfz6G9kX for <spring@ietf.org>; Mon, 3 Aug 2020 09:43:19 -0700 (PDT)
Cc: "spring@ietf.org" <spring@ietf.org>
References: <7e29a863-70e9-f0a8-638f-5151348be515@joelhalpern.com> <F73A3CB31E8BE34FA1BBE3C8F0CB2AE297D63B99@dggeml510-mbs.china.huawei.com> <AM0PR03MB4499A048326D9A2E8DA5F46B9D4D0@AM0PR03MB4499.eurprd03.prod.outlook.com>
From: "Joel M. Halpern" <jmh@joelhalpern.com>
Message-ID: <0f1c2ea9-1096-5806-3962-1cee8d525ae6@joelhalpern.com>
Date: Mon, 3 Aug 2020 12:43:17 -0400
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0
MIME-Version: 1.0
In-Reply-To: <AM0PR03MB4499A048326D9A2E8DA5F46B9D4D0@AM0PR03MB4499.eurprd03.prod.outlook.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/spring/gEgQUSPo_b9zz0fZbUvAO00jCIM>
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 16:43:22 -0000

What I am hearing is that we all know there is an issue here, but the 
documents do not connect the dots?

Yours,
Joel

On 8/3/2020 2:36 AM, Alexander Vainshtein wrote:
> 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.:
> 
> oIGP Prefix Node SIDs IGP Adj-SIDs (identified as such in the 
> corresponding IGP advertisements) represent topological instructions
> 
> oService 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.
> ------------------------------------------------------------------------
> 
> _______________________________________________
> spring mailing list
> spring@ietf.org
> https://www.ietf.org/mailman/listinfo/spring
>