Re: [spring] Spring protection - determining applicability

Robert Raszuk <robert@raszuk.net> Mon, 17 August 2020 22:15 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 CE2E43A12A6 for <spring@ietfa.amsl.com>; Mon, 17 Aug 2020 15:15:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.49
X-Spam-Level:
X-Spam-Status: No, score=-1.49 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, T_REMOTE_IMAGE=0.01, 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 eYzkXX9Zp7em for <spring@ietfa.amsl.com>; Mon, 17 Aug 2020 15:15:29 -0700 (PDT)
Received: from mail-ed1-x531.google.com (mail-ed1-x531.google.com [IPv6:2a00:1450:4864:20::531]) (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 575563A12AF for <spring@ietf.org>; Mon, 17 Aug 2020 15:15:28 -0700 (PDT)
Received: by mail-ed1-x531.google.com with SMTP id t15so13613077edq.13 for <spring@ietf.org>; Mon, 17 Aug 2020 15:15:28 -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=+8jNDseXFemisY9RXJhDWiBYUq0bEGjkyWjSuya3Sg4=; b=cQYk3yf1M74mnXS05snRVVQFrwtkw/GmLC8SmWAdWhjOPclX0Ao1F76EDITMBh2bN9 4E7XOoo7Lt45FtlC9S6PCIaUhYfzSQofp6x2n0/T1YTQE8xCY5XvIlDiPk5cCNfaAbpX vTQSGX/Dm1MvF816XMKEHgZKgS/kcdLKmE6wlZxNc/+pW4HN/T5Nx3sIquSEuSfs1pBm m9U4JgEIuCWkDAT1u0Z32/qmeSPfRjgwW7nKwcvPntwCray6fWY4E6ykNWZTw91UMBRN i58nrYRSzZGxiqUIwcqleVzQ5ZmLru8nC+ScdSd8RxSZxOqcZIz2MH63iRzLRYMlYHp/ mOgA==
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=+8jNDseXFemisY9RXJhDWiBYUq0bEGjkyWjSuya3Sg4=; b=idiq8norzK2eam/tc3ZnttIyh/KStm/oL1XfzMMJSnzW6cgyqRSxdokUSOHzhQjgae nW9JpHfQpi6av8AiqI/Ij3FFiDTOJUZK3+o7x98D/spZHDh+g/DOer5AY+TDNuEcoskw EvUqo5ZgMDkPqYlw4chYe5JH6QYmV+bXkJrTxojY1EcM2NXtKqaCGB45KvuSNr+k0Xj7 lQ1zAmBCMRRL8m7lSomciCMJHNAZDyS6QvPs1L3Y2BrMPJtZ0o6ATw18wWOPXSC350ri 3FJ42rvSaMpl7X2wfqT3EnSE1Ic0dpUWl4DmnhjDnY99fM+dPlWRdfBmhef7c286E4ni J3uw==
X-Gm-Message-State: AOAM532JPbH0FTifYS8EzeCE4LjLTrieB02zSRGBOffCJt+vmUTzvPzi qKBVXaSdwL7HALHZaiE4n6w+HzyKVx4NuvOdmsHiYQ==
X-Google-Smtp-Source: ABdhPJwL4h22iVp2QNcvJjs5nttiSl7WGNEqkb5nEDXy0wGjh8Ih8l0YuuNrtjME/BQwf9UUYeP41oTpFcVmYzqZa4M=
X-Received: by 2002:aa7:c70b:: with SMTP id i11mr16721115edq.272.1597702525998; Mon, 17 Aug 2020 15:15:25 -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> <CAOj+MME=kJ-JZcOKwiW4gPV6hM1zW7oC2w_S_DEZ4roP4CJ6hQ@mail.gmail.com> <19edd13c-8729-4534-b5da-c48a63a74aee@Spark> <e8dff31f-613e-4224-b784-77fd743f21cf@Spark> <CABNhwV3JFfdmxZKEaniBbgC6_O3_hoscoxQ5rjPXv_uahvTKEQ@mail.gmail.com> <7a88539d-9420-4abc-8dd6-2ba1401fcd0e@Spark> <CAOj+MMFRhbbGkf_2O2EHCfu8q2wP7nnwrxbUUjEC=8UOG0R=Cg@mail.gmail.com> <8940cdc0-9c51-46a4-8ddc-79df170c433f@Spark>
In-Reply-To: <8940cdc0-9c51-46a4-8ddc-79df170c433f@Spark>
From: Robert Raszuk <robert@raszuk.net>
Date: Tue, 18 Aug 2020 00:15:14 +0200
Message-ID: <CAOj+MMFP+JPGogL3n_FVFBMf6ROmNk=5RrByKn4SZT2HGnBOsA@mail.gmail.com>
To: Jeff Tantsura <jefftant.ietf@gmail.com>
Cc: Gyan Mishra <hayabusagsm@gmail.com>, Alexander Vainshtein <Alexander.Vainshtein@rbbn.com>, "EXT-Andrew.Alston@liquidtelecom.com" <Andrew.Alston@liquidtelecom.com>, "Joel M. Halpern" <jmh@joelhalpern.com>, "Ketan Talaulikar (ketant)" <ketant=40cisco.com@dmarc.ietf.org>, Shraddha Hegde <shraddha@juniper.net>, "spring@ietf.org" <spring@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000850c5a05ad1a1baf"
Archived-At: <https://mailarchive.ietf.org/arch/msg/spring/8bjCoeKHG7L5Uz6jNdvUB8x4eNc>
Subject: Re: [spring] Spring protection - determining applicability
X-BeenThere: spring@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" <spring.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/spring>, <mailto:spring-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/spring/>
List-Post: <mailto:spring@ietf.org>
List-Help: <mailto:spring-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/spring>, <mailto:spring-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 17 Aug 2020 22:15:35 -0000

Hi Jeff,

If one would allocate SIDs in a smart way they can include algorithmically
encoded information if packets are FRR eligible. No increase in IGP
flooding. No duplication of SID space. Just local behaviour.

For SRv6 - trivial. For SR-MPLS, also pretty simple provided one would be
keen on using MPLS forwarding paradigm for some time :)

Hint: think even/odd (1 bit in the SID) - well known in a domain - and used
correctly by your vendor.

Best,
R.

On Mon, Aug 17, 2020 at 11:54 PM Jeff Tantsura <jefftant.ietf@gmail.com>
wrote:

> Hi Robert,
>
> "possession of enough information in PLR” what do you call this, if not
> more state, given this information is not present there today?
>
> Cheers,
> Jeff
> On Aug 17, 2020, 2:25 PM -0700, Robert Raszuk <robert@raszuk.net>, wrote:
>
> Hi Jeff,
>
> This is not about more state in the network nor about including mirror
> service node in the backup path for some flows.
>
> The thread is about possession of enough information in PLR to either take
> the packet and shift it over backup path or just drop it.
>
> - - -
>
> Btw - path protection is completely orthogonal to the above.
>
> Cheers,
> Robert.
>
>
> On Mon, Aug 17, 2020 at 11:03 PM Jeff Tantsura <jefftant.ietf@gmail.com>
> wrote:
>
>> Gyan,
>>
>> TI-LFA computation is local to the PLR and is topology dependent, e.g
>> change in downstream topology could/would influence the choice of MP (PQ)
>> node.
>> While an implementation could take into consideration some additional
>> meta-data (e.g. locally provisioned SRLG, usually used to avoid protected
>> and protecting ports on the same line card), this is not a standardized
>> method.
>> If a service node must be included in a backup path, there’s a state
>> associated with it as well as distribution of the state involved.
>>
>> Back to my point, removing state and introducing services in the network
>> (at the very least at the computational logic and head-end level) are
>> mutually exclusive, trade-offs are inevitable (You can't eat your cake and
>> have it).
>> Keeping the state limited to:
>> - a logically centralized computational logic (aka PCE) - off path,
>> scales horizontally, could use additional business logic for the path
>> computation, example - CPU/memory consumption on a service node
>> - head-end - anchor to primary/backup paths
>> seems like a reasonable set of trade-offs.
>>
>> Cheers,
>> Jeff
>> On Aug 14, 2020, 7:44 PM -0700, Gyan Mishra <hayabusagsm@gmail.com>,
>> wrote:
>>
>>
>> Catching up on this thread as it is a interesting topic as FRR 1:N link
>> protection, node protection and path protection is critical to operators.
>>
>> There are multiple somewhat orthogonal topics brought up in the
>> discussion.
>>
>> Excluding SR SFC from “bypass” capable node such for appliances such as
>> firewalls and load balancer.  Makes sense.  I would not think SFC would be
>> in a PLR path to merger point but I could be mistaken.
>>
>> The goal of SR is eliminating state and so having TE like state is
>> undesirable.
>>
>> Intent based instantiation of bypass via SR-TE from network feedback at
>> PLR detection node of a failure and make before break pre computed backup
>> paths that can.
>>
>> It would make sense that SR-TE binding SID policy would be appropriate
>> for RSVP like FRR link node or path protection.
>>
>> My thoughts on this topic of SR protection is that don’t we already have
>> FRR protection natively without requiring SR-TE BSID or any additional
>> undesirable state maintenance with TI-LFA.
>>
>> Thanks
>>
>> Gyan
>>
>> On Fri, Aug 14, 2020 at 5:47 PM Jeff Tantsura <jefftant.ietf@gmail.com>
>> wrote:
>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> PCE computation in this case is trivial too(must traverse node B or node
>>> X) else FAIL.
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> Cheers,
>>>
>>> Jeff
>>>
>>>
>>>
>>>
>>>
>>>
>>> On Aug 14, 2020, 2:44 PM -0700, Jeff Tantsura <jefftant.ietf@gmail.com>,
>>> wrote:
>>>
>>>
>>>
>>>
>>>
>>>
>>> Robert,
>>>
>>>
>>>
>>>
>>>
>>> Agreed and apologies, hit send before finishing the email (it is Friday)
>>> ;-)
>>>
>>>
>>>
>>>
>>>
>>> Path protection in this case make more sense and is much less complex,
>>>
>>>
>>> if in the pathA (A->B->C) node B is a service node, it can’t be bypassed
>>> (node protected) if the link between A and B breaks
>>>
>>>
>>> however it could have a backup pathB (A->X->C) where X is the service
>>> node, potentially synchronizing its state with the node B.
>>>
>>>
>>>
>>>
>>>
>>> To my previous email - at expense of more state, we provide path and
>>> service protection, hence the similarity with RSVP-TE trade-offs.
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> Cheers,
>>>
>>> Jeff
>>>
>>>
>>>
>>>
>>>
>>>
>>> On Aug 14, 2020, 2:30 PM -0700, Robert Raszuk <robert@raszuk.net>,
>>> wrote:
>>>
>>>
>>>
>>>
>>> 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>, 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>; Joel M.
>>>> Halpern <jmh@joelhalpern.com>; Shraddha Hegde <shraddha@juniper.net>;
>>>> EXT-Andrew.Alston@liquidtelecom.com <Andrew.Alston@liquidtelecom.com>;
>>>> 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>; Joel M.
>>>> Halpern <jmh@joelhalpern.com>; Shraddha Hegde <shraddha@juniper.net>;
>>>> EXT-Andrew.Alston@liquidtelecom.com <Andrew.Alston@liquidtelecom.com>;
>>>> 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>; Joel M. Halpern <
>>>> jmh@joelhalpern.com>; Shraddha Hegde <shraddha@juniper.net>;
>>>> EXT-Andrew.Alston@liquidtelecom.com <Andrew.Alston@liquidtelecom.com>;
>>>> 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>; Joel M. Halpern <
>>>> jmh@joelhalpern.com>; Alexander Vainshtein <
>>>> Alexander.Vainshtein@rbbn.com>; Shraddha Hegde <shraddha@juniper.net>;
>>>> EXT-Andrew.Alston@liquidtelecom.com <Andrew.Alston@liquidtelecom.com>;
>>>> 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>; Shraddha
>>>> Hegde <shraddha=40juniper.net@dmarc.ietf.org>;
>>>> EXT-Andrew.Alston@liquidtelecom.com <Andrew.Alston@liquidtelecom.com>;
>>>> 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>; 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>>;
>>>> 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 <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/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/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
>>>> <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
>>>> <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
>>>> <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
>>>> <http://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
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>>
>>> spring mailing list
>>>
>>> spring@ietf.org
>>>
>>> https://www.ietf.org/mailman/listinfo/spring
>>>
>>> --
>>
>> <http://www.verizon.com/>
>>
>> *Gyan Mishra*
>>
>> *Network Solutions A**rchitect *
>>
>>
>>
>> *M 301 502-1347 13101 Columbia Pike *Silver Spring, MD
>>
>>