Re: [spring] Spring protection - determining applicability

Robert Raszuk <robert@raszuk.net> Fri, 14 August 2020 21:30 UTC

Return-Path: <robert@raszuk.net>
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 9101C3A0AA2 for <spring@ietfa.amsl.com>; Fri, 14 Aug 2020 14:30:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.5
X-Spam-Level:
X-Spam-Status: No, score=-1.5 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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=raszuk.net
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 O2QWD4XhzR72 for <spring@ietfa.amsl.com>; Fri, 14 Aug 2020 14:30:52 -0700 (PDT)
Received: from mail-ed1-x52e.google.com (mail-ed1-x52e.google.com [IPv6:2a00:1450:4864:20::52e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 06C5F3A0AC7 for <spring@ietf.org>; Fri, 14 Aug 2020 14:30:51 -0700 (PDT)
Received: by mail-ed1-x52e.google.com with SMTP id i6so7847798edy.5 for <spring@ietf.org>; Fri, 14 Aug 2020 14:30:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=raszuk.net; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=TaMBH8C5n8YdZoJM2+rSsoQqD9XNQji1EBiUC/w/sAE=; b=Bmic+5MSWk/hS6ORWuKzJxePL7bltRrtFfwuF8j5zCoeb0Hhg7O8R+c1O9+gQa6pbx 57BDwjCRH+RWlaFuPFIo0IItL79GZG6n7qQoUFaNMROyd2CKYy0iNj5rs3ZsqlJkBvdm Zyc1rz/CEUvWSs48Jmlodk9Tmj16Z0T9WTS3waAmTgq7gdODDZ1vVXhTspS8BbtpuIT1 T531ddmh/+E+ZjzUp9qprVVfke+01dn3z3MDanMtXPOmuTzwqgCjb4REETTyh+3wrV/f LlYCTvttmrpGLUqzahco9mLKDcsRBIQoOKAP2RIkG1y59JgGqsFnO4vD7D+XSLjI5Z0R pc/w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=TaMBH8C5n8YdZoJM2+rSsoQqD9XNQji1EBiUC/w/sAE=; b=noSxN4vc+E61LKUOZ8PZVRPum15qK7pe9rYxH6dBPrhqM3Slq4fiBndmLwWuj54Vdx 7VaxdGQOUe7xE2EdudaeCX+qHnyMRa7rS25j7E2dIJDN0xBSbI4JMGYlfeDS8XfDFfpm LZemaUG82sa8Q6Dk6bqUtXo3v4ICknVvVgs7lfCSJ8vsMqrbWAxyxXmdrreb6iBtZja4 YXx6fOAPNzGRzFK0BFIcuWkXYPNDInamLRADhywHlMl0p3rRZPBFNa1FiteJPu8Sbzfl O3b/xJVIT/O1f3viBonh76CP4tDXU4tDPNG5YEuKMBAi4Z0SW0BRnVO6oN/twEYwfcwF v2aA==
X-Gm-Message-State: AOAM533I0j4q2tboEIcZJ80fmGsmAKxWpuJgFdLB7b2jAiXfg0+18G3R PnaDUAah74fiYX+gQ8SqzgBJjODGiM8RjKpGVwt9cQ==
X-Google-Smtp-Source: ABdhPJxd2x/SWG/4tH2PX7VLlVF99GXkgzFKgbRoQ4Bwzxw4XtVLV8yJd9qnPm3hkz5KwN9VNzbTixVFi2A8n0RL05Q=
X-Received: by 2002:aa7:cc85:: with SMTP id p5mr4260376edt.369.1597440649824; Fri, 14 Aug 2020 14:30:49 -0700 (PDT)
MIME-Version: 1.0
References: <7e29a863-70e9-f0a8-638f-5151348be515@joelhalpern.com> <F73A3CB31E8BE34FA1BBE3C8F0CB2AE297D63B99@dggeml510-mbs.china.huawei.com> <AM0PR03MB4499A048326D9A2E8DA5F46B9D4D0@AM0PR03MB4499.eurprd03.prod.outlook.com> <cce664f5-6f20-36ba-ccea-120266697528@joelhalpern.com> <CAOj+MMHZ5wGAPhAO+yLc+RY9OhRX=LuMQ27QQDJkAjK0YM0HMw@mail.gmail.com> <4229284b-9a73-612b-306d-2818f37dd5b3@joelhalpern.com> <VI1PR03MB50560EA5D95C76F7501608FBEE4D0@VI1PR03MB5056.eurprd03.prod.outlook.com> <CAOj+MMGUYkpT0xx+DAuaF-Gc9YSYrLQbNxHuenb2Xps_S=s_tQ@mail.gmail.com> <VI1PR03MB5056610F42282B6883CED19EEE4A0@VI1PR03MB5056.eurprd03.prod.outlook.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> <2c83ce86-4413-43bd-9d40-72ea3b9f4962@Spark>
In-Reply-To: <2c83ce86-4413-43bd-9d40-72ea3b9f4962@Spark>
From: Robert Raszuk <robert@raszuk.net>
Date: Fri, 14 Aug 2020 23:30:39 +0200
Message-ID: <CAOj+MME=kJ-JZcOKwiW4gPV6hM1zW7oC2w_S_DEZ4roP4CJ6hQ@mail.gmail.com>
To: Jeff Tantsura <jefftant.ietf@gmail.com>
Cc: "Ketan Talaulikar (ketant)" <ketant=40cisco.com@dmarc.ietf.org>, Alexander Vainshtein <Alexander.Vainshtein@rbbn.com>, "spring@ietf.org" <spring@ietf.org>, "Joel M. Halpern" <jmh@joelhalpern.com>, Shraddha Hegde <shraddha@juniper.net>, "EXT-Andrew.Alston@liquidtelecom.com" <Andrew.Alston@liquidtelecom.com>
Content-Type: multipart/alternative; boundary="0000000000007b9cc605acdd22ba"
Archived-At: <https://mailarchive.ietf.org/arch/msg/spring/yyDZwoyalrA4bKpHJ7YC2VvCudQ>
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: Fri, 14 Aug 2020 21:30:59 -0000

Jeff,

> This is very similar to RSVP-TE

I would rather differ on that statement.

See if you are using SR just for TE you are 100% right.

But if your SIDs embed additional local SR node processing functions this
suddenly becomes a completely different game. Let's keep this in mind in
this thread/topic.

Kind regards,
R.


On Fri, Aug 14, 2020 at 11:15 PM Jeff Tantsura <jefftant.ietf@gmail.com>
wrote:

> This is very similar to RSVP-TE, path vs link/node protection and usually
> dictated by the business logic, the triggers are obviously very different,
> head-end being notified of the failure on a path and switching to the
> backup path vs reaction to a local failure, so same considerations apply:
> -more state
> -pre-reserved resources
> while
> -predictable
> -meets SLA (as good as primary)
> vs
> -less state
> -local
> -best effort / can cause congestions
>
> Cheers,
> Jeff
> On Aug 14, 2020, 10:46 AM -0700, Ketan Talaulikar (ketant) <ketant=
> 40cisco.com@dmarc.ietf.org>gt;, wrote:
>
> 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>
> *Sent:* 14 August 2020 23:04
> *To:* Ketan Talaulikar (ketant) <ketant@cisco.com>
> *Cc:* Alexander Vainshtein <Alexander.Vainshtein@rbbn.com>om>; Joel M.
> Halpern <jmh@joelhalpern.com>om>; Shraddha Hegde <shraddha@juniper.net>et>;
> EXT-Andrew.Alston@liquidtelecom.com <Andrew.Alston@liquidtelecom.com>om>;
> 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> wrote:
>
> Hi Robert,
>
>
>
> Please check inline below.
>
>
>
> *From:* Robert Raszuk <robert@raszuk.net>
> *Sent:* 14 August 2020 21:13
> *To:* Ketan Talaulikar (ketant) <ketant@cisco.com>
> *Cc:* Alexander Vainshtein <Alexander.Vainshtein@rbbn.com>om>; Joel M.
> Halpern <jmh@joelhalpern.com>om>; Shraddha Hegde <shraddha@juniper.net>et>;
> EXT-Andrew.Alston@liquidtelecom.com <Andrew.Alston@liquidtelecom.com>om>;
> 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> 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>
> *Sent:* 14 August 2020 20:24
> *To:* Ketan Talaulikar (ketant) <ketant@cisco.com>om>; Joel M. Halpern <
> jmh@joelhalpern.com>gt;; Shraddha Hegde <shraddha@juniper.net>et>;
> EXT-Andrew.Alston@liquidtelecom.com <Andrew.Alston@liquidtelecom.com>om>;
> Robert Raszuk <robert@raszuk.net>
> *Cc:* 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://aka.ms/ghei36>
>
>
> ------------------------------
>
> *From:* Ketan Talaulikar (ketant) <ketant@cisco.com>
> *Sent:* Friday, August 14, 2020, 16:23
> *To:* Alexander Vainshtein; Joel M. Halpern; Shraddha Hegde;
> EXT-Andrew.Alston@liquidtelecom.com; Robert Raszuk
> *Cc:* 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>
> *Sent:* 14 August 2020 18:24
> *To:* Ketan Talaulikar (ketant) <ketant@cisco.com>om>; Joel M. Halpern <
> jmh@joelhalpern.com>gt;; Alexander Vainshtein <Alexander.Vainshtein@rbbn.com>om>;
> Shraddha Hegde <shraddha@juniper.net>et>; EXT-Andrew.Alston@liquidtelecom.com
> <Andrew.Alston@liquidtelecom.com>om>; Robert Raszuk <robert@raszuk.net>
> *Cc:* 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> on behalf of Ketan Talaulikar
> (ketant) <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; Robert Raszuk
> *Cc:* 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> On Behalf Of Joel M. Halpern
> Sent: 04 August 2020 20:25
> To: Alexander Vainshtein <Alexander.Vainshtein@rbbn.com>om>; Shraddha Hegde <
> shraddha=40juniper.net@dmarc.ietf.org>gt;;
> EXT-Andrew.Alston@liquidtelecom.com <Andrew.Alston@liquidtelecom.com>om>;
> Robert Raszuk <robert@raszuk.net>
> Cc: spring@ietf.org; Joel M. Halpern <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
> >
> > *From:* spring <spring-bounces@ietf.org> *On Behalf Of *Shraddha Hegde
> > *Sent:* Tuesday, August 4, 2020 9:41 AM
> > *To:* EXT-Andrew.Alston@liquidtelecom.com
> > <Andrew.Alston@liquidtelecom.com>om>; Robert Raszuk <robert@raszuk.net>
> > *Cc:* spring@ietf.org; Joel M. Halpern <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
> <spring-bounces@ietf.org%20%0b> > <mailto:spring-bounces@ietf.org
> <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
> <robert@raszuk.net>>>
> > *Cc:* spring@ietf.org <mailto:spring@ietf.org <spring@ietf.org>>g>>; Joel
> M. Halpern
> > <jmh@joelhalpern.com <mailto:jmh@joelhalpern.com <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
> <robert@raszuk.net>>>
> > *Sent:* Tuesday, 4 August 2020 01:27
> > *To:* Andrew Alston <Andrew.Alston@liquidtelecom.com
> <Andrew.Alston@liquidtelecom.com%20%0b> > <
> mailto:Andrew.Alston@liquidtelecom.com <Andrew.Alston@liquidtelecom.com>>>
> > *Cc:* Joel M. Halpern <jmh@joelhalpern.com
> <jmh@joelhalpern.com%20%0b> > <mailto:jmh@joelhalpern.com
> <jmh@joelhalpern.com>>>>>>; spring@ietf.org
> > <mailto:spring@ietf.org <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
> <Andrew.Alston@liquidtelecom.com%20%0b> > <
> mailto:Andrew.Alston@liquidtelecom.com <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
> <spring-bounces@ietf.org%0b> >     <mailto:spring-bounces@ietf.org
> <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
> <robert@raszuk.net>>>
> >     *Cc:* spring@ietf..org <mailto:spring@ietf.org <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
> <jmh@joelhalpern.com%0b> >     <mailto:jmh@joelhalpern.com%20%0b
> <jmh@joelhalpern.com%20%0b>>> <mailto:jmh@joelhalpern.com
> <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
> <Alexander.Vainshtein@ecitele.com>>
> >      > <mailto:Alexander.Vainshtein@ecitele.com
> <Alexander.Vainshtein@ecitele.com>>
> >      > >
> >      > > -----Original Message-----
> >      > > From: spring <spring-bounces@ietf.org
> <spring-bounces@ietf.org%0b> >     <mailto:spring-bounces@ietf.org%0b
> <spring-bounces@ietf.org%0b>>>
> >     <mailto:spring-bounces@ietf.org <spring-bounces@ietf.org>>> On
> Behalf Of Mach Chen
> >      > > Sent: Monday, August 3, 2020 6:30 AM
> >      > > To: Joel M. Halpern <jmh@joelhalpern.com
> <jmh@joelhalpern.com%0b> >     <mailto:jmh@joelhalpern.com%0b
> <jmh@joelhalpern.com%0b>>> <mailto:jmh@joelhalpern.com
> <jmh@joelhalpern.com>>>>>>;
> >     spring@ietf.org <mailto:spring@ietf.org <spring@ietf.org>> <
> mailto:spring@ietf.org <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 <spring-bounces@ietf.org>>
> >     <
> mailto:spring-bounces@ietf.org%0b%3e%20%3cmailto:spring-bounces@ietf.org%3e
> <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
> <spring@ietf.org>>
> >     <mailto:spring@ietf.org <spring@ietf.org>>
> >      > <mailto:spring@ietf.org <mailto:spring@ietf.org
> <spring@ietf.org%20%3cmailto:spring@ietf.org%0b> >     <
> mailto:spring@ietf.org%20%3cmailto:spring@ietf.org
> <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 <spring@ietf.org>>
> >     <mailto:spring@ietf.org <spring@ietf.org>>
> >      > <mailto:spring@ietf.org <mailto:spring@ietf.org
> <spring@ietf.org%20%3cmailto:spring@ietf.org%0b> >     <
> mailto:spring@ietf.org%20%3cmailto:spring@ietf.org
> <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/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 <spring@ietf.org>>
> >     <mailto:spring@ietf.org <spring@ietf.org>> <mailto:spring@ietf.org
> <spring@ietf.org%0b> >     <mailto:spring@ietf.org%0b <spring@ietf.org%0b>>>
> <mailto:spring@ietf.org <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 <spring@ietf.org>> <
> mailto:spring@ietf.org <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 <spring@ietf.org>> <
> mailto:spring@ietf.org <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 <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%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
>
> https://clicktime.symantec.com/3Q1xsKGyMzNJCKyVPByhqLq6H2?u=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspring
> _______________________________________________
> spring mailing list
> 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
> https://www.ietf.org/mailman/listinfo/spring
>
>