Re: [spring] Spring protection - determining applicability

Alexander Vainshtein <Alexander.Vainshtein@rbbn.com> Tue, 18 August 2020 15:44 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 7730F3A0DC6 for <spring@ietfa.amsl.com>; Tue, 18 Aug 2020 08:44:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.487
X-Spam-Level:
X-Spam-Status: No, score=-1.487 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, HTTP_ESCAPED_HOST=0.1, PDS_BTC_ID=0.498, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=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 xH_AqXy3XdVL for <spring@ietfa.amsl.com>; Tue, 18 Aug 2020 08:44:37 -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 284613A0DC3 for <spring@ietf.org>; Tue, 18 Aug 2020 08:44:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rbbn.com; s=mimecast20180816; t=1597765475; 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=tNxAdr/AbqQc9E7DZ3sMKgn9Q6ASpkYXJyhmxp6u+YE=; b=Ze4AdvbGVXvU7ZrSCZjQ/Gb97+iI2mSFFeZGPgMBsY+x/ZlGgLRp4DbivfRkLOkKdfNVfA CYYA0973Cqk9zj/wZtS8Gt2uXubuorH1e+Rp8z0OtF17Q/m+WqPqpdrGgPFn9KwfPASju9 xCPdC6odpWkuczYvsjtQD/cXun+SV80=
Received: from AZWPVEXEdge02.ecitele.com (13.81.42.245 [13.81.42.245]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-38-LnjXguOdNLi993Ggq0ns-g-1; Tue, 18 Aug 2020 11:44:29 -0400
X-MC-Unique: LnjXguOdNLi993Ggq0ns-g-1
Received: from EUR01-DB5-obe.outbound.protection.outlook.com (104.47.2.50) 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; Tue, 18 Aug 2020 18:44:27 +0300
Received: from AM0PR03MB4499.eurprd03.prod.outlook.com (2603:10a6:208:c4::33) by AM0PR0302MB3236.eurprd03.prod.outlook.com (2603:10a6:208:8::24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3305.24; Tue, 18 Aug 2020 15:44:25 +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.3283.027; Tue, 18 Aug 2020 15:44:25 +0000
From: Alexander Vainshtein <Alexander.Vainshtein@rbbn.com>
To: Martin Horneffer <maho@lab.dtag.de>
CC: Robert Raszuk <robert@raszuk.net>, "EXT-Andrew.Alston@liquidtelecom.com" <Andrew.Alston@liquidtelecom.com>, Shraddha Hegde <shraddha@juniper.net>, "Ketan Talaulikar (ketant)" <ketant=40cisco.com@dmarc.ietf.org>, "Joel M. Halpern" <jmh@joelhalpern.com>, "spring@ietf.org" <spring@ietf.org>
Thread-Topic: [spring] Spring protection - determining applicability
Thread-Index: AQHWaSfCODf9rN3izE+yW9JumUctqqklun0AgAAq2JCAAMsLAIAABZ+AgAABgICAADUrgIAAC1aAgAAdJoCAAGzfgIAAD7UQgAB6ewCAD4ZhAIAAC+KLgAALZwCAABX95oAADfeAgAAC7gCAAAmbgIAAFWyAgAADZQCABhhmgIAACWPQ
Date: Tue, 18 Aug 2020 15:44:25 +0000
Message-ID: <AM0PR03MB449963FAF42D748F7FD7F2E09D5C0@AM0PR03MB4499.eurprd03.prod.outlook.com>
References: <7e29a863-70e9-f0a8-638f-5151348be515@joelhalpern.com> <CY4PR05MB35769327315CBA84E8912D84D54A0@CY4PR05MB3576.namprd05.prod.outlook.com> <AM0PR03MB449907B6175A572E73B6D0389D4A0@AM0PR03MB4499.eurprd03.prod.outlook.com> <af38a341-9839-9435-54b7-09f49e667787@joelhalpern.com> <MW3PR11MB45706B42711F76BB5DD2110EC1400@MW3PR11MB4570.namprd11.prod.outlook.com> <AM0PR03MB449975114CFA78448BFE54A29D400@AM0PR03MB4499.eurprd03.prod.outlook.com> <MW3PR11MB4570615B3050B500C456C99EC1400@MW3PR11MB4570.namprd11.prod.outlook.com> <AM0PR03MB4499C8691A7D5690D052EEB59D400@AM0PR03MB4499.eurprd03.prod.outlook.com> <MW3PR11MB4570C29F44A9234A5B0729D0C1400@MW3PR11MB4570.namprd11.prod.outlook.com> <CAOj+MMFvP1PBgBogG+r1i_Vj3onYUBTeYbAdniRUqGS9TcQJ5w@mail.gmail.com> <MW3PR11MB457066589CAE97721BB97D84C1400@MW3PR11MB4570.namprd11.prod.outlook.com> <CAOj+MMHtkRvV-yRV21+pzAqtyz_QsLEVrvQrOa-wFW1-OyVpng@mail.gmail.com> <MW3PR11MB4570250AC1693BD65241A638C1400@MW3PR11MB4570.namprd11.prod.outlook.com> <4692aa7f-babe-71c3-970f-b448f4bb8343@lab.dtag.de>
In-Reply-To: <4692aa7f-babe-71c3-970f-b448f4bb8343@lab.dtag.de>
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: 41660d20-3239-43d7-2c76-08d8438d9598
x-ms-traffictypediagnostic: AM0PR0302MB3236:
x-microsoft-antispam-prvs: <AM0PR0302MB3236C1E246ED861F3844E1889D5C0@AM0PR0302MB3236.eurprd03.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:8882;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: aLXkQd857dfl8basuWknNSlwBHzFoz2uxkTu33btKd+jbgOaO4uZtd+kBA6+ucNBpBnR9pAfqalYs3P8w5fg9KRvXus8+MhVPbZDgBoqcOYZxs8JEVgTmA05W4SCBmOZEBGqB70uvSvbrq8lzsZdyUjBBoGC+K0sJIySlrfTCZ0BW02bAOZBy6D0E2pV0Pk3tZJChhpdOsAlh2b1hHotuu7Cq0LqxEwIAIcp70bxKX6jqnRCf7Rv2X1Px/o+zKaRfUYEQTpP7kGIiTmAAXTwVapNZe2gW0329CAhddWjo1YduA7JbOKSluWqcYuuq41vHhClxwkvHgOxyeuduFrB5s0jGZko9iINESNxum+hEjMQ6hwBF9fB1DyOrHJXjex5TvDK/7bzJGAwog84vifMGw==
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; SFS:(136003)(366004)(39860400002)(376002)(396003)(346002)(76116006)(66946007)(54906003)(478600001)(33656002)(86362001)(55016002)(316002)(4326008)(52536014)(83380400001)(166002)(9686003)(53546011)(6506007)(66446008)(64756008)(66556008)(66476007)(6916009)(7696005)(30864003)(186003)(2906002)(5660300002)(45080400002)(26005)(8676002)(71200400001)(8936002)(966005)(579004)(559001); DIR:OUT; SFP:1102;
x-ms-exchange-antispam-messagedata: 1r8Ah697cVqqWsmReRg6iGhALduSxSkrgPq42GQKgqb5nUJa7F32u5E1bU+DeFmC+hv740Gzhhvjt7yNhggUuP2rGWSkvvxVkvmDw0fMASQjy3qP2HI3wgh8Ew2WvwxAsPYesY2JcfRO5wiIpBupgBr3o82l5hZOEm+ujkV2QpBI8DqXCHsdxxA3Ud3Ij7hU0ga9yBQuB8OyD4qp8q0YyN+NkniMdKjWbj8aocl0+ym8AxCge8BM4YtXDSvKwbFAPICy+y4yHZ2vDM0GFupNK3jXc3AP5ULXDmxCzJrcqfT5dD1NmFJWbNBnmT6xUk+wmtojEaG8YB82p1ZcZ2ccSHq5HPXuhB+wFxeAt0VwE0BHL5K0EEpam3fhDXujRUw2s4Gj8cTCy7kdkgtedZrFlV6tCRJpdij9RdngEOK+b3TF9wP1fVgtVlsanNWRvpw7D2vVOXHxLNL1WRBbAiRRy5XHqDVgNxvJUQCyV7dF8wM4boMC4dS6C0+HNJ4d6GTzSi4h4t426m53k/plUZS3hIhGukmpPXX7JaU1cNywf+e4AJ6auj4T1MJiCkVueL1BL/aiShtz81Bo5fO4ix0nXXIYcCEET26nmcc0HAC/EY4kOn8U/RQxJeZb7nx181Av05Wp2fz1PAJ3rhHkUvJfTw==
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: 41660d20-3239-43d7-2c76-08d8438d9598
X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Aug 2020 15:44:25.0773 (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: hwKpYVJCKfLD7W8d/dNH5iAtcpm79zy4y3nnHO8/N9W6F3FLJa91zqwiZ22a11DQL2QwrDWnEuWaGxkKYqSdzw==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR0302MB3236
Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA81A106 smtp.mailfrom=alexander.vainshtein@rbbn.com
X-Mimecast-Spam-Score: 0.004
X-Mimecast-Originator: rbbn.com
Content-Type: multipart/alternative; boundary="_000_AM0PR03MB449963FAF42D748F7FD7F2E09D5C0AM0PR03MB4499eurp_"
Archived-At: <https://mailarchive.ietf.org/arch/msg/spring/C_kaPoyinPUMt9EpeYZ-cAv89Xc>
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: Tue, 18 Aug 2020 15:44:44 -0000

Martin,
Lots of thanks for an important input to this discussion.

I fully agree with you that ability to turn off the node protection scheme for a specific PLR neighbor (i.e., on a specific PLR port) by suitable local configuration in the PLR is definitely required. Such an ability would probably address most (if not all) scenarios associated with the so-called “service nodes” that cannot be bypassed.

I also think that service nodes that cannot be bypassed typically would advertise themselves as “stub nodes” in IGP in order to prevent inadvertent application of their service function to transit traffic (which could otherwise pass thru the service node due to some topology change). Therefore a local policy that would exclude IGP neighbors advertising  themselves as stub nodes in IGP from the node protection scheme could be also useful.

Last but not least, ability of the node to advertise a specific Prefix SID it originates as “not eligible for bypass protection” (e.g., using a new flag in the Prefix Node TLV for IS-IS or OSPF) should be considered.

My 2c,
Sasha

Office: +972-39266302
Cell:      +972-549266302
Email:   Alexander.Vainshtein@ecitele.com

From: spring <spring-bounces@ietf.org> On Behalf Of Martin Horneffer
Sent: Tuesday, August 18, 2020 5:51 PM
To: spring@ietf.org
Cc: Alexander Vainshtein <Alexander.Vainshtein@rbbn.com>; Robert Raszuk <robert@raszuk.net>; EXT-Andrew.Alston@liquidtelecom.com <Andrew.Alston@liquidtelecom.com>; Shraddha Hegde <shraddha@juniper.net>; Ketan Talaulikar (ketant) <ketant=40cisco.com@dmarc.ietf.org>; Joel M. Halpern <jmh@joelhalpern.com>
Subject: Re: [spring] Spring protection - determining applicability

A few thoughts from my (operator's) PoV:

 - The disussion is a very good and important one. It probably should be discussed and documented well in order to justify the proposed protections mechanisms.

 - Not all operators seem to have the same requirements.
    (A somewhat similar discussion might be the one for disjoint paths. Those are often equired by voice signalling applications. In some cases the voice service demands that traffic is blackholed rather than on forwarded on the wrong path. In other cases disjoint paths are just required for the "good case". Traffic MAY be forwarded on the wrong path, as long as the network just makes sure the traffic on the other path is never affected by the same failure.)

 - Personally I would hate to see yet another IGP extension for this purpose.

 - I would rather prefer a good discussion of what can be achieved by using easy to make switches:
    - The protection behaviour could be switched on or off per node.
       - An operator with strict "some traffic may never touch certain parts of the network" requirements might switch off the behaviour, while others might switch it on.
    - A node could allow a switch even individually for every port or neighbor.
       - If a node knows that one of it's neighbours is a service node rather than a plain topological one, it could switch off protection. This is how I would prefer to solve the problem with serrvice nodes.

Should this be discussed in the protection document, or in a separate one?

Best regards, Martin

Am 14.08.20 um 19:45 schrieb Ketan Talaulikar (ketant):
Hi Robert,

We do not have a signalling mechanism in IGPs today to indicate a “bypass-able” indication for Prefix SIDs. If there was a desire for it, an IGP extension would be required (there is none in progress AFAIK). Note that this results in doubling the prefix SID scale (global labels) in the network. So I would not go about this trivially.

I think it helps to get more inputs and perspectives from operators on their views for doing a bypass via local protection for segments in an SR Policy. There may be those that prefer end-to-end path protection using a fallback path that is say disjoint with the primary but provides an appropriate SLA/intent?

Thanks,
Ketan

From: Robert Raszuk <robert@raszuk.net><mailto:robert@raszuk.net>
Sent: 14 August 2020 23:04
To: Ketan Talaulikar (ketant) <ketant@cisco.com><mailto:ketant@cisco.com>
Cc: Alexander Vainshtein <Alexander.Vainshtein@rbbn.com><mailto:Alexander.Vainshtein@rbbn.com>; Joel M. Halpern <jmh@joelhalpern.com><mailto:jmh@joelhalpern.com>; Shraddha Hegde <shraddha@juniper.net><mailto:shraddha@juniper.net>; EXT-Andrew.Alston@liquidtelecom.com<mailto:EXT-Andrew.Alston@liquidtelecom.com> <Andrew.Alston@liquidtelecom.com><mailto:Andrew.Alston@liquidtelecom.com>; spring@ietf.org<mailto:spring@ietf.org>
Subject: Re: [spring] Spring protection - determining applicability

Ketan,

Looks like we are pretty much in sync here.

But let me just observe that I purposely did not mention about SR policies as we are not able to signal the intent with the packets itself.

So all we have there is SIDs. BSIDs or prefix SIDs need to be flooded with information if policies build with using them are bypass eligible or not.

I was actually under the impression that this is already there and I am just not aware, but looking deeper indeed I do not see this marking neither in ISIS nor OSPF for prefix SIDs.

Is there some work in progress to add it to those protocols or have we just documented need for a short LSR draft  ?

Thx,
R.


On Fri, Aug 14, 2020 at 6:17 PM Ketan Talaulikar (ketant) <ketant@cisco.com<mailto:ketant@cisco.com>> wrote:
Hi Robert,

Please check inline below.

From: Robert Raszuk <robert@raszuk.net<mailto:robert@raszuk.net>>
Sent: 14 August 2020 21:13
To: Ketan Talaulikar (ketant) <ketant@cisco.com<mailto:ketant@cisco.com>>
Cc: Alexander Vainshtein <Alexander.Vainshtein@rbbn.com<mailto:Alexander.Vainshtein@rbbn.com>>; Joel M. Halpern <jmh@joelhalpern.com<mailto:jmh@joelhalpern.com>>; Shraddha Hegde <shraddha@juniper.net<mailto:shraddha@juniper.net>>; EXT-Andrew.Alston@liquidtelecom.com<mailto:EXT-Andrew.Alston@liquidtelecom.com> <Andrew.Alston@liquidtelecom.com<mailto:Andrew.Alston@liquidtelecom.com>>; spring@ietf.org<mailto:spring@ietf.org>
Subject: Re: [spring] Spring protection - determining applicability

Hi Ketan,

While I completely agree with your note the consequences of it are pretty sevre.
[KT] I understand. We need to be mindful of implications of protection schemes for the SLAs/intent of SR Policies.

Unless we signal which prefix SID is protection eligible and which is not how would other nodes know if they can protect it or not ?
[KT] Correct. To be more accurate, we need to consider this more in the context of SLA or “intent” of SR Policies and which segments may be “bypass-able” for local protection for some of those SR Policies. We also have path-protection mechanisms.

It seems that today's safe thing is not to apply any node protection on SR flows at the PLRs then.

And link protection MUST assure that packets will arrive at the neighbor node via some other link regardless of further path towards destination.
[KT] Yes. We have a mechanism to indicate which adj-SIDs have protection (that mechanism only provides link protection to get to the neighbor node) so the SR Policy computation is able to indicate whether that specific link is “bypass-able” or not by its choice of protected or unprotected adj-SIDs respectively.

Thanks,
Ketan

Is it correct ?

Thx
R

On Fri, Aug 14, 2020 at 5:32 PM Ketan Talaulikar (ketant) <ketant@cisco.com<mailto:ketant@cisco.com>> wrote:
Hi Sasha,

The service node advertises its own Prefix SID. The service function that this service node implements does not require any context (i.e. all packets arriving at the node are subjected to that service). Therefore the service node does not need to receive a packet with it’s own Prefix SID.

Thus, we cannot assume that when PHP is used, then the SID is only associated with a topological instruction.

Hope that clarifies?

Thanks,
Ketan

From: Alexander Vainshtein <Alexander.Vainshtein@rbbn.com<mailto:Alexander.Vainshtein@rbbn.com>>
Sent: 14 August 2020 20:24
To: Ketan Talaulikar (ketant) <ketant@cisco.com<mailto:ketant@cisco.com>>; Joel M. Halpern <jmh@joelhalpern.com<mailto:jmh@joelhalpern.com>>; Shraddha Hegde <shraddha@juniper.net<mailto:shraddha@juniper.net>>; EXT-Andrew.Alston@liquidtelecom.com<mailto:EXT-Andrew.Alston@liquidtelecom.com> <Andrew.Alston@liquidtelecom.com<mailto:Andrew.Alston@liquidtelecom.com>>; Robert Raszuk <robert@raszuk.net<mailto:robert@raszuk.net>>
Cc: spring@ietf.org<mailto:spring@ietf.org>
Subject: Re: [spring] Spring protection - determining applicability

Ketan, and all,
I have stated that, IMHO and FWIW, both Adj-SIDs and Prefix SIDs that are advertised with PHP can  ONLY represent topological instructions in SR-MPLS - because the advertising node will not receive them and therefore can hardly be expected to associate any service function with them.

This is complementary to what you have said.

Hope this clarifies my position.
What, if anything, did I miss?

Regards,
Sasha

Get Outlook for Android<https://clicktime.symantec.com/33Gi7zptDyRpRkx4RcDpbUC6H2?u=https%3A%2F%2Faka.ms%2Fghei36>

________________________________
From: Ketan Talaulikar (ketant) <ketant@cisco.com<mailto:ketant@cisco.com>>
Sent: Friday, August 14, 2020, 16:23
To: Alexander Vainshtein; Joel M. Halpern; Shraddha Hegde; EXT-Andrew.Alston@liquidtelecom.com<mailto:EXT-Andrew.Alston@liquidtelecom.com>; Robert Raszuk
Cc: spring@ietf.org<mailto:spring@ietf.org>
Subject: RE: [spring] Spring protection - determining applicability

________________________________
NOTICE: This email was received from an EXTERNAL sender
________________________________

Hi Sasha,

If the service does not need any additional context (e.g. a firewall that just applies locally configured default rules on it), then I don’t see why PHP could not be done for a Prefix SID associated with a service node.

Also, I didn’t follow the point that you were trying to make about Adj-SIDs.

Thanks,
Ketan

From: Alexander Vainshtein <Alexander.Vainshtein@rbbn.com<mailto:Alexander.Vainshtein@rbbn.com>>
Sent: 14 August 2020 18:24
To: Ketan Talaulikar (ketant) <ketant@cisco.com<mailto:ketant@cisco.com>>; Joel M. Halpern <jmh@joelhalpern.com<mailto:jmh@joelhalpern.com>>; Alexander Vainshtein <Alexander.Vainshtein@rbbn.com<mailto:Alexander.Vainshtein@rbbn.com>>; Shraddha Hegde <shraddha@juniper.net<mailto:shraddha@juniper.net>>; EXT-Andrew.Alston@liquidtelecom.com<mailto:EXT-Andrew.Alston@liquidtelecom.com> <Andrew.Alston@liquidtelecom.com<mailto:Andrew.Alston@liquidtelecom.com>>; Robert Raszuk <robert@raszuk.net<mailto:robert@raszuk.net>>
Cc: spring@ietf.org<mailto:spring@ietf.org>
Subject: Re: [spring] Spring protection - determining applicability

Hi all,
Regarding the statement "Prefix SID could be just a topological instruction or may also be used to steer the flow to a node which is applying a service function to it":


I think that in SR-MPLS a Node SID that is advertised with PHP aciton can be safely considered as "just a topological instruction" by the PLR because the originating node will not receive it.
The same applies to Adj-SDIs.

My 2c.

Get Outlook for Android<https://clicktime.symantec.com/375c5YYBeEbaEZwUcHpCY1m6H2?u=https%3A%2F%2Faka.ms%2Fghei36>

________________________________
From: spring <spring-bounces@ietf.org<mailto:spring-bounces@ietf.org>> on behalf of Ketan Talaulikar (ketant) <ketant=40cisco.com@dmarc.ietf.org<mailto:ketant=40cisco.com@dmarc.ietf.org>>
Sent: Friday, August 14, 2020, 15:00
To: Joel M. Halpern; Alexander Vainshtein; Shraddha Hegde; EXT-Andrew.Alston@liquidtelecom.com<mailto:EXT-Andrew.Alston@liquidtelecom.com>; Robert Raszuk
Cc: spring@ietf.org<mailto:spring@ietf.org>
Subject: Re: [spring] Spring protection - determining applicability

Hi All,

I would like to share a different perspective on this.

First, thanks to Joel for bringing up the discussion. Clearly we need a well-defined applicability statement for determining applicability of protection for segment used in an SR Policy. Some of this is captured in [1].

This is about local repair at a PLR. By it's very nature, the PLR does not have a notion of how "strict or not" is the SLA that is being provided by the SR Policy. Awareness of that notion exists at the SR Policy headend and/or computation-node.

We have protected and un-protected variants of adjacency SIDs to enable the computation to pick or the other based on the "strictness" of the SLA requirement for picking that link. We do not have such a notion for Prefix SIDs. One can say that we could introduce signalling (e.g. a B flag) to indicate whether a Prefix SID can be bypassed or not. This provides the opportunity for the computation to use one or the other flavor depending on the nature of the SLA for the SR Policy.

I have a problem and a concern in the assumption that PLRs can assume that the currently defined variant of Prefix SIDs in RFC8402 (and IGP specs) are "bypass-able".

As Joel and others have brought out, the Prefix SID could be just a topological instruction or may also be used to steer the flow to a node which is applying a service function to it. In order to support a mix of SR Policies of different SLAs (strict and not-strict), we need to enable the choice of SIDs that indicates to the PLR whether they are "bypass-able" or not.

For the cases, where the SR Policy has a specific SLA, it is required for nodes to drop the packets meant for the "active segment" than to bypass it. When this mechanism is used along side SRTE path monitoring mechanisms, it enables the headend to detect the failure and fallback to an alternate path using the path protection approach. This is something that is described and in use in deployments today [1]..

Thanks,
Ketan

[1] https://clicktime.symantec.com/3Y3fWuNFYCjMJUiiAiWwUms6H2?u=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-ietf-spring-segment-routing-policy-08%23section-9
[2] https://clicktime.symantec.com/36fCMrgmEewC4a4AJRrmn7H6H2?u=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-ietf-spring-segment-routing-policy-08%23section-9.3

-----Original Message-----
From: spring <spring-bounces@ietf.org<mailto:spring-bounces@ietf.org>> On Behalf Of Joel M. Halpern
Sent: 04 August 2020 20:25
To: Alexander Vainshtein <Alexander.Vainshtein@rbbn.com<mailto:Alexander.Vainshtein@rbbn.com>>; Shraddha Hegde <shraddha=40juniper.net@dmarc.ietf.org<mailto:shraddha=40juniper.net@dmarc.ietf.org>>; EXT-Andrew.Alston@liquidtelecom.com<mailto:EXT-Andrew.Alston@liquidtelecom.com> <Andrew.Alston@liquidtelecom.com<mailto:Andrew.Alston@liquidtelecom.com>>; Robert Raszuk <robert@raszuk.net<mailto:robert@raszuk.net>>
Cc: spring@ietf.org<mailto:spring@ietf.org>; Joel M. Halpern <jmh@joelhalpern.com<mailto:jmh@joelhalpern.com>>
Subject: Re: [spring] Spring protection - determining applicability

There are, as far as I can tell, a number of ways to address this family of related questions.
What struck me, and prompted the starting question, was that none of them were spelled out.  I see lots of interesting ideas / proposals.
Some of them are compatible with others.   Some are not.
It would be good if we could reach agreement on how we thought it should be handled.

Thank you,
Joel

On 8/4/2020 3:54 AM, Alexander Vainshtein wrote:
> Hi all,
>
> I am still not sure that the problem of bypass going thru undesirable
> links/nodes exists in the case of topological SIDs.
>
> AFAIK, Facility Protection in RSVP-TE FRR (RFC 4090
> <https://clicktime.symantec.com/3Q92knE9XJujrf8Bk7oJvs6H2?u=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Frfc4090>) has been successfully deployed
> for many years before SR-MPLS has been introduced. What’s more,
> signaling of bypass tunnels he PLR usually did not include any of the
> constraints used for computing of any specific LSP that the bypass LSP
> would protect – because in the Facility Protection mode the same
> bypass LSP would be used to protect multiple LSPs passing thru the
> failed link/node.
>
>  From my POV the only difference between this behavior and that
> introduced by the “bypassing” drafts in SR is that, in the case of
> RSVP-TE, the operator would explicitly indicate, as part of LSP
> signaling, whether it would or would not use FRR; LSPs that would not
> use FRR would then drop traffic rather than delivering it the wrong way.
>
> Such an option indeed does not exist in SR-TE today, but would be easy
> to provide if so desired IMHO.
>
> Did I miss something substantial?
>
> Regards, and lots of thanks in advance,
>
> Sasha
>
> Office: +972-39266302
>
> Cell:      +972-549266302
>
> Email:   Alexander.Vainshtein@ecitele.com<mailto:Alexander.Vainshtein@ecitele.com>
>
> *From:* spring <spring-bounces@ietf.org<mailto:spring-bounces@ietf.org>> *On Behalf Of *Shraddha Hegde
> *Sent:* Tuesday, August 4, 2020 9:41 AM
> *To:* EXT-Andrew.Alston@liquidtelecom.com<mailto:EXT-Andrew.Alston@liquidtelecom.com>
> <Andrew.Alston@liquidtelecom.com<mailto:Andrew.Alston@liquidtelecom.com>>; Robert Raszuk <robert@raszuk.net<mailto:robert@raszuk.net>>
> *Cc:* spring@ietf.org<mailto:spring@ietf.org>; Joel M. Halpern <jmh@joelhalpern.com<mailto:jmh@joelhalpern.com>>
> *Subject:* Re: [spring] Spring protection - determining applicability
>
> All,
>
> This is a very interesting discussion and thanks to Joel for starting
> this discussion. IMO, when there are strict requirements of avoiding
> certain nodes/links it can be realized  either by defining a flex-algo
> avoiding those
>
> Nodes and links or by using a stack of unprotected adj-sids that avoid
> restricted nodes and links. When a stack of adj-sids is used to
> realize the path, the head-end based (sBFD) protection mechanisms can be applied.
>
> If Node-sids/prefix-sid/anycast-sids are used to build the stack, the
> failure events may cause traffic to go through restricted nodes and
> links. This would happen regardless of whether any kind of protection
> is in use or not.
>
> Rgds
>
> Shraddha
>
> Juniper Business Use Only
>
> *From:* spring <spring-bounces@ietf.org
<mailto:spring-bounces@ietf.org%20%0b>> <mailto:spring-bounces@ietf.org>> *On Behalf Of *Andrew Alston
> *Sent:* Tuesday, August 4, 2020 5:41 AM
> *To:* Robert Raszuk <robert@raszuk.net<mailto:robert@raszuk.net> <mailto:robert@raszuk.net>>
> *Cc:* spring@ietf.org<mailto:spring@ietf.org> <mailto:spring@ietf.org>; Joel M. Halpern
> <jmh@joelhalpern.com<mailto:jmh@joelhalpern.com> <mailto:jmh@joelhalpern.com>>
> *Subject:* Re: [spring] Spring protection - determining applicability
>
> *[External Email. Be cautious of content]*
>
> Robert this is actually far more difficult when – it can be an entire
> (long) series of nodes that need to be avoided.
>
> It could potentially be made to work but I’d worry that to do this –
> you’d have to stack 10 – 20 – 30 negative labels – and that wouldn’t
> be viable.
>
> It’s easier to use algorithms and adjacency sids and other such things
> to calculate paths – the biggest trick is about the stack depth.  When
> you have this need for node avoidance – the need for 10+ label depth
> is critical – unless you wanna be applying one hell of a lot of
> binding labels along the way which is a nightmare.
>
> But to answer your question, is this a common use case – it’s a use
> case that most of the people I discuss this with certain have – I cant
> comment on a global scale, or for anyone else, but every indication I
> have is that yes – its something people need, and want
>
> Andrew
>
> *From:* Robert Raszuk <robert@raszuk.net<mailto:robert@raszuk.net> <mailto:robert@raszuk.net>>
> *Sent:* Tuesday, 4 August 2020 01:27
> *To:* Andrew Alston <Andrew.Alston@liquidtelecom.com
<mailto:Andrew.Alston@liquidtelecom.com%20%0b>> <mailto:Andrew.Alston@liquidtelecom.com>>
> *Cc:* Joel M. Halpern <jmh@joelhalpern.com
<mailto:jmh@joelhalpern.com%20%0b>> <mailto:jmh@joelhalpern.com>>; spring@ietf.org<mailto:spring@ietf.org>
> <mailto:spring@ietf.org>
> *Subject:* Re: [spring] Spring protection - determining applicability
>
> Is this a common use case ie.  "but rather – which nodes / network
> segments it can never touch or flow through."
>
> If so perhaps its time to define notion of *negative-SID* ie. list in
> the packet resources which given packet MUST not ever traverse.
>
> Put in the packet set of nodes or links which the packet should never
> traverse.
>
> That goes in line of recent wave of negative routing implementations
> (RIFT) or discussions (LSR)
>
> Best,
> R.
>
> On Mon, Aug 3, 2020 at 11:46 PM Andrew Alston
> <Andrew.Alston@liquidtelecom.com
<mailto:Andrew.Alston@liquidtelecom.com%20%0b>> <mailto:Andrew.Alston@liquidtelecom.com>> wrote:
>
>     So –
>
>     One of the use cases, in fact, some very major use cases in any
>     spring technology for us revolve around the following
>
>     a.The explicit avoidance of certain nodes
>
>     b.The explicit avoidance of certain sections of the network
>
>     Anything that could result in that explicit avoidance being violated
>     – would create, shall we say significant problems.
>
>     Much of the use case is not a case of which nodes the packets flow
>     through – but rather – which nodes / network segments it can never
>     touch or flow through.  Effectively, to be used as a technology to
>     avoid certain things for specific reasons.
>
>     This is also one of the reasons for needing such deep label stacks –
>     this kind of detailed path programming tends to deepen the stack
>     because you sometimes have to be pretty explicit.
>
>     It is absolutely critical to us that this functionality is there –
>     and that we can avoid situations which could cause traffic to
>     accidently hit things explicitly avoided.
>
>     I wish I could be more specific than this, but it is what it is.
>
>     Thanks
>
>     Andrew
>
>     *From:* spring <spring-bounces@ietf.org
<mailto:spring-bounces@ietf.org%0b>>     <mailto:spring-bounces@ietf.org>> *On Behalf Of *Joel M. Halpern
>     *Sent:* Monday, 3 August 2020 21:36
>     *To:* Robert Raszuk <robert@raszuk.net<mailto:robert@raszuk.net> <mailto:robert@raszuk.net>>
>     *Cc:* spring@ietf..org<mailto:spring@ietf..org> <mailto:spring@ietf.org>
>     *Subject:* Re: [spring] Spring protection - determining
> applicability
>
>     (Since the thread has gotten long enough, reiterating that this is as a
>     participant, not a WG chair.)
>
>     Yes, we are talking IP networks. And yes, I have seen IP networks that
>     choose to drop packets. For all sorts of reasons.
>     I think there are likely other reasons why one may not want a random
>     path rather than a chosen TE path. I think it is important we be clear
>     about what constraints may be / are violated when we tell people they
>     have this tool (protective rerouting) that is intended to preserve QoS.
>
>     Let's be clear. I am not arguing that this is not a good idea. It is a
>     good idea. And useful. I am trying to figure otu what combination of
>     additional mechanisms and clear descriptions will lead to everyone
>     getting the behavior they expect (which may not be the behavior they
>     desire, but sometimes is the best we can do.)
>
>     Yours,
>     Joel
>
>     On 8/3/2020 2:30 PM, Robert Raszuk wrote:
>      > Joel,
>      >
>      > Are we still talking about IP networks here ? Or perhaps some hard
>      > slicing with real resource reservations or detnets ?
>      >
>      > Because if we are talking about IP networking I have two
>     observations:
>      >
>      > A) If you need to traverse via a specific node (ie. firewall) you
>     better
>      > apply IP encapsulation to that node.. I don't think IP
>     encapsulation can
>      > be hijacked today such that destination address of the packet is
>     ignored.
>      >
>      > B) Have you seen any IP network where upon topology change (link
>     or node
>      > failure) you suddenly start dropping flows in spite of SPT offering
>      > perhaps few ms longer path with 10 ms more jitter ?
>      >
>      > Or are some SR marketing slides promise to turn IP networks in
>      > something new ? Worse ... do they mention path quality guarantees,
>      > resource reservations ? I hope not.
>      >
>      > Thx,
>      > R.
>      >
>      >
>      >
>      >
>      >
>      >
>      >
>      >
>      >
>      > On Mon, Aug 3, 2020 at 8:10 PM Joel M. Halpern <jmh@joelhalpern.com
<mailto:jmh@joelhalpern.com%0b>>     <mailto:jmh@joelhalpern.com%20%0b>> <mailto:jmh@joelhalpern.com>> wrote:
>      >
>      > Well less serious for TE SIDs, I am not sure the problem is
>     restricted
>      > to just service SIDs.
>      >
>      > Suppose that the PCE has specified the path to meet some complex te
>      > objective.  The bypass node has no way of knowing what those
>      > constraints
>      > were.  And for some kinds of traffic, it is better to drop the packet
>      > than to deliver it outside the envelop.  I suspect that the right
>      > answer
>      > to this is "too bad".  If so, as with the distinction regarding
>     service
>      > nodes, we should say so, shouldn't we?
>      >
>      > 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://clicktime.symantec.com/3CCcy9mY6cMfbk7QfjhiA3R6H2?u=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-bess-srv6-services-04
<https://clicktime.symantec.com/3CCcy9mY6cMfbk7QfjhiA3R6H2?u=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-bess-srv6-services-04%0b>>     <https://clicktime.symantec.com/3GC5af2z3JzphZDkPncHAQi6H2?u=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-bess-srv6-services-04__%3B%21%21NEt6yMaO-gk%21S0Yusx9FYNE8E_R1oiQAtQxgm0x0wxqguoZHgwp6vpRHOGt8AkTRDuiDo4T-L0nl%24>>
>      >
>      > > 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://clicktime.symantec.com/345NLCB6TydxuuqUjtcDRZy6H2?u=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Frfc8402
<https://clicktime.symantec.com/345NLCB6TydxuuqUjtcDRZy6H2?u=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Frfc8402%0b>>     <https://clicktime.symantec.com/37PzUKAD82cjSvmVcGvpkhF6H2?u=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Ftools.ietf.org%2Fhtml%2Frfc8402__%3B%21%21NEt6yMaO-gk%21S0Yusx9FYNE8E_R1oiQAtQxgm0x0wxqguoZHgwp6vpRHOGt8AkTRDuiDo0I4Ybtm%24>>
>     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://clicktime.symantec.com/3JbSWGx5DAfNPsZdhpExxx96H2?u=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-hegde-spring-node-protection-for-sr-te-paths-07%23section-3.4
<https://clicktime.symantec.com/3JbSWGx5DAfNPsZdhpExxx96H2?u=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-hegde-spring-node-protection-for-sr-te-paths-07%23section-3.4%0b>>     <https://clicktime.symantec.com/3CrUgARW8somAbw6TisjgJ16H2?u=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-hegde-spring-node-protection-for-sr-te-paths-07%2Asection-3.4__%3BIw%21%21NEt6yMaO-gk%21S0Yusx9FYNE8E_R1oiQAtQxgm0x0wxqguoZHgwp6vpRHOGt8AkTRDuiDo9wO-Ssn%24>>
>      >
>      > > 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://clicktime.symantec.com/3JfvtBAmaQPN1jA3pM6TdCE6H2?u=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Frfc8679
<https://clicktime.symantec.com/3JfvtBAmaQPN1jA3pM6TdCE6H2?u=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Frfc8679%0b>>     <https://clicktime.symantec.com/36dMAjuYTQovo8jHwmm3eJw6H2?u=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Frfc8679__%3B%21%21NEt6yMaO-gk%21S0Yusx9FYNE8E_R1oiQAtQxgm0x0wxqguoZHgwp6vpRHOGt8AkTRDuiDo8MGipXc%24>>]
>     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<mailto:Alexander.Vainshtein@ecitele.com>
>     <mailto:Alexander.Vainshtein@ecitele.com>
>      > <mailto:Alexander.Vainshtein@ecitele.com>
>      > >
>      > > -----Original Message-----
>      > > From: spring <spring-bounces@ietf.org
<mailto:spring-bounces@ietf.org%0b>>     <mailto:spring-bounces@ietf.org%0b>>
>     <mailto:spring-bounces@ietf.org>> On Behalf Of Mach Chen
>      > > Sent: Monday, August 3, 2020 6:30 AM
>      > > To: Joel M. Halpern <jmh@joelhalpern.com
<mailto:jmh@joelhalpern.com%0b>>     <mailto:jmh@joelhalpern.com%0b>> <mailto:jmh@joelhalpern.com>>;
>     spring@ietf.org<mailto:spring@ietf.org> <mailto:spring@ietf.org> <mailto: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<mailto:spring-bounces@ietf.org>
>      > <mailto:spring-bounces@ietf.org>
>     <mailto:spring-bounces@ietf.org%0b%3e%20%3cmailto:spring-bounces@ietf.org%3e>]
>     On Behalf Of Joel M.
>      > >
>      > >  > Halpern
>      > >
>      > >  > Sent: Monday, August 3, 2020 7:51 AM
>      > >
>      > >  > To: spring@ietf.org<mailto:spring@ietf.org> <mailto:spring@ietf.org>
>     <mailto:spring@ietf.org>
>      > <mailto:spring@ietf.org <mailto:spring@ietf.org
<mailto:spring@ietf.org%20%3cmailto:spring@ietf.org%0b>>     <mailto:spring@ietf.org%20%3cmailto: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> <mailto:spring@ietf.org>
>     <mailto:spring@ietf.org>
>      > <mailto:spring@ietf.org <mailto:spring@ietf.org
<mailto:spring@ietf.org%20%3cmailto:spring@ietf.org%0b>>     <mailto:spring@ietf.org%20%3cmailto:spring@ietf.org>>>
>      > >
>      > >  >
>      > >
>      >
>     https://clicktime.symantec.com/367qhU4KiUkzW9uGC4eAvP46H2?u=https%3A%2<https://clicktime.symantec.com/367qhU4KiUkzW9uGC4eAvP46H2?u=https%3A%252>
>     <https://clicktime.symantec.com/3Q7vX2qWSUdWVc892XuXy2H6H2?u=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Fclicktime.symantec.com%2F367qhU4KiUkzW9uGC4eAvP46H2%3Fu%3Dhttps%2A3A%2A2__%3BJSU%21%21NEt6yMaO-gk%21S0Yusx9FYNE8E_R1oiQAtQxgm0x0wxqguoZHgwp6vpRHOGt8AkTRDuiDo6HwPLil%24>
>      > >
>      >
>     <https://clicktime.symantec.com/367qhU4KiUkzW9uGC4eAvP46H2?u=https%3A%252
<https://clicktime.symantec.com/367qhU4KiUkzW9uGC4eAvP46H2?u=https%3A%252%0b>>     <https://clicktime.symantec.com/3A5B8H2Fm1rPnaZ3Supjwr6H2?u=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Fclicktime.symantec.com%2F367qhU4KiUkzW9uGC4eAvP46H2%3Fu%3Dhttps%2A3A%2A252__%3BJSU%21%21NEt6yMaO-gk%21S0Yusx9FYNE8E_R1oiQAtQxgm0x0wxqguoZHgwp6vpRHOGt8AkTRDuiDozoQiAHk%24>>
>      > >
>      > >  > F%2Fwww.ietf.org<https://clicktime.symantec.com/32yCkPKRruRj1ZfCvKgL2Gq6H2?u=http%3A%2F%2F2Fwww.ietf.org>
>     <https://clicktime.symantec.com/39NznmYBtRuHARhGJ5W5dGB6H2?u=https%3A%2F%2Furldefense.com%2Fv3%2F__http%3A%2F2Fwww.ietf.org__%3B%21%21NEt6yMaO-gk%21S0Yusx9FYNE8E_R1oiQAtQxgm0x0wxqguoZHgwp6vpRHOGt8AkTRDuiDo-pPCjvR%24>
>      > <https://clicktime.symantec.com/3GWT9fyjaFi3FcvHDvoodvS6H2?u=http%3A%2F%2F2Fwww.ietf.org
<https://clicktime.symantec.com/3GWT9fyjaFi3FcvHDvoodvS6H2?u=http%3A%2F%2F2Fwww.ietf.org%0b>>     <https://clicktime.symantec.com/39NznmYBtRuHARhGJ5W5dGB6H2?u=https%3A%2F%2Furldefense.com%2Fv3%2F__http%3A%2F2Fwww.ietf.org__%3B%21%21NEt6yMaO-gk%21S0Yusx9FYNE8E_R1oiQAtQxgm0x0wxqguoZHgwp6vpRHOGt8AkTRDuiDo-pPCjvR%24>>%2Fmailman%2Flistinfo%2Fspring
>      > >
>      > > _______________________________________________
>      > >
>      > > spring mailing list
>      > >
>      > > spring@ietf.org<mailto:spring@ietf.org> <mailto:spring@ietf.org>
>     <mailto:spring@ietf.org> <mailto:spring@ietf.org
<mailto:spring@ietf.org%0b>>     <mailto:spring@ietf.org%0b>> <mailto:spring@ietf.org>>
>      > >
>      > >
>      >
>     https://clicktime.symantec.com/367qhU4KiUkzW9uGC4eAvP46H2?u=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspring
>     <https://clicktime.symantec.com/3BhyEtx4Q7n74BhiRnfMJtT6H2?u=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Fclicktime.symantec.com%2F367qhU4KiUkzW9uGC4eAvP46H2%3Fu%3Dhttps%2A3A%2A2F%2A2Fwww.ietf.org%2A2Fmailman%2A2Flistinfo%2A2Fspring__%3BJSUlJSUl%21%21NEt6yMaO-gk%21S0Yusx9FYNE8E_R1oiQAtQxgm0x0wxqguoZHgwp6vpRHOGt8AkTRDuiDo-hR3gAD%24>
>      > >
>      > >
>      > >
>      > >
>      >
>     ------------------------------------------------------------------------
>      > > 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<mailto:spring@ietf.org> <mailto:spring@ietf.org> <mailto:spring@ietf.org>
>      > > https://clicktime.symantec.com/3Q1xsKGyMzNJCKyVPByhqLq6H2?u=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspring
>     <https://clicktime.symantec.com/3NrDnSTReXh671G79BVGEq16H2?u=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspring__%3B%21%21NEt6yMaO-gk%21S0Yusx9FYNE8E_R1oiQAtQxgm0x0wxqguoZHgwp6vpRHOGt8AkTRDuiDo5KlPnbj%24>
>      > >
>      >
>      > _______________________________________________
>      > spring mailing list
>      > spring@ietf.org<mailto:spring@ietf.org> <mailto:spring@ietf.org> <mailto:spring@ietf.org>
>      > https://clicktime.symantec.com/3Q1xsKGyMzNJCKyVPByhqLq6H2?u=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspring
>     <https://clicktime.symantec.com/3NrDnSTReXh671G79BVGEq16H2?u=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspring__%3B%21%21NEt6yMaO-gk%21S0Yusx9FYNE8E_R1oiQAtQxgm0x0wxqguoZHgwp6vpRHOGt8AkTRDuiDo5KlPnbj%24>
>      >
>
>     _______________________________________________
>     spring mailing list
>     spring@ietf.org<mailto:spring@ietf.org> <mailto:spring@ietf.org>
>     https://clicktime.symantec.com/3Q1xsKGyMzNJCKyVPByhqLq6H2?u=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspring
>
> <https://clicktime.symantec.com/3NrDnSTReXh671G79BVGEq16H2?u=https%3A%
<https://clicktime.symantec.com/3NrDnSTReXh671G79BVGEq16H2?u=https%3A%25%0b>> 2F%2Furldefense.com%2Fv3%2F__https%3A%2Fwww.ietf.org<https://clicktime.symantec.com/32yCkPKRruRj1ZfCvKgL2Gq6H2?u=http%3A%2F%2F2Fwww.ietf.org>%2Fmailman%2Flisti
> nfo%2Fspring__%3B%21%21NEt6yMaO-gk%21S0Yusx9FYNE8E_R1oiQAtQxgm0x0wxqgu
> oZHgwp6vpRHOGt8AkTRDuiDo5KlPnbj%24>
>
>
>
> ----------------------------------------------------------------------
> --
> 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<mailto:spring@ietf.org>
https://clicktime.symantec.com/3Q1xsKGyMzNJCKyVPByhqLq6H2?u=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspring
_______________________________________________
spring mailing list
spring@ietf.org<mailto:spring@ietf.org>
https://clicktime.symantec.com/3Q1xsKGyMzNJCKyVPByhqLq6H2?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<mailto:spring@ietf.org>

https://www.ietf.org/mailman/listinfo/spring<https://clicktime.symantec.com/35PXkKKT6EzLUVfDT443Qoy6H2?u=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspring>