IETF Logo Mail Archive

[spring] Spring protection - determining applicability

"Joel M. Halpern" <jmh@joelhalpern.com> Sun, 02 August 2020 23:50 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 35DA33A0DD2 for <spring@ietfa.amsl.com>; Sun, 2 Aug 2020 16:50:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.2
X-Spam-Level:
X-Spam-Status: No, score=-0.2 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 fiG0myA2NHMo for <spring@ietfa.amsl.com>; Sun, 2 Aug 2020 16:50:41 -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 449C03A0DD1 for <spring@ietf.org>; Sun, 2 Aug 2020 16:50:41 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 4BKd7P0HWxz6G8tX for <spring@ietf.org>; Sun, 2 Aug 2020 16:50:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1596412241; bh=eFDJ5unKbgAX06l13/EqmpklRd46aWJ3XzwrwBrQPhw=; h=To:From:Subject:Date:From; b=phDhCc19EhVNmBZODmSsulx3SLNQqNqkrfpaSvOmy20OlKxuMYaZWetw1iOdT1eDH O21E9h+191N89V8DRcVgngvn6k4UipF20Bn17vg2tWRfY9XWkpQ36n3AcJkdzlGBhA pFhZU+uGMDSU1k7FgSbnEMtCtsaGB6Y9cyd3akKs=
X-Quarantine-ID: <GVyJq16YgrKu>
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 4BKd7N4Ldxz6G7Lk for <spring@ietf.org>; Sun, 2 Aug 2020 16:50:40 -0700 (PDT)
To: "spring@ietf.org" <spring@ietf.org>
From: "Joel M. Halpern" <jmh@joelhalpern.com>
Message-ID: <7e29a863-70e9-f0a8-638f-5151348be515@joelhalpern.com>
Date: Sun, 02 Aug 2020 19:50:38 -0400
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/spring/0Tt4NXNFmkxkqWrq6pwgeQt7I7Q>
Subject: [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: Sun, 02 Aug 2020 23:50:42 -0000

(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

v2.23.0 | Report a Bug | By Email