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 >> >>
- [spring] Spring protection - determining applicab… Joel M. Halpern
- Re: [spring] Spring protection - determining appl… Mach Chen
- Re: [spring] Spring protection - determining appl… Alexander Vainshtein
- Re: [spring] Spring protection - determining appl… Chengli (Cheng Li)
- Re: [spring] Spring protection - determining appl… Joel M. Halpern
- Re: [spring] Spring protection - determining appl… Joel M. Halpern
- Re: [spring] Spring protection - determining appl… Joel M. Halpern
- Re: [spring] Spring protection - determining appl… Robert Raszuk
- Re: [spring] Spring protection - determining appl… Andrew Alston
- Re: [spring] Spring protection - determining appl… UTTARO, JAMES
- Re: [spring] Spring protection - determining appl… Robert Raszuk
- Re: [spring] Spring protection - determining appl… Greg Mirsky
- Re: [spring] Spring protection - determining appl… Andrew Alston
- Re: [spring] Spring protection - determining appl… Andrew Alston
- Re: [spring] Spring protection - determining appl… Greg Mirsky
- Re: [spring] Spring protection - determining appl… Andrew Alston
- Re: [spring] Spring protection - determining appl… li_zhenqiang@hotmail.com
- Re: [spring] Spring protection - determining appl… Shraddha Hegde
- Re: [spring] Spring protection - determining appl… Dongjie (Jimmy)
- Re: [spring] Spring protection - determining appl… Alexander Vainshtein
- Re: [spring] Spring protection - determining appl… Huzhibo
- Re: [spring] Spring protection - determining appl… Joel M. Halpern
- Re: [spring] Spring protection - determining appl… Ketan Talaulikar (ketant)
- Re: [spring] Spring protection - determining appl… Alexander Vainshtein
- Re: [spring] Spring protection - determining appl… Ketan Talaulikar (ketant)
- Re: [spring] Spring protection - determining appl… Alexander Vainshtein
- Re: [spring] Spring protection - determining appl… Joel M. Halpern
- Re: [spring] Spring protection - determining appl… Ketan Talaulikar (ketant)
- Re: [spring] Spring protection - determining appl… Robert Raszuk
- Re: [spring] Spring protection - determining appl… Ketan Talaulikar (ketant)
- Re: [spring] Spring protection - determining appl… Robert Raszuk
- Re: [spring] Spring protection - determining appl… Ketan Talaulikar (ketant)
- Re: [spring] Spring protection - determining appl… Jeff Tantsura
- Re: [spring] Spring protection - determining appl… Robert Raszuk
- Re: [spring] Spring protection - determining appl… Jeff Tantsura
- Re: [spring] Spring protection - determining appl… Jeff Tantsura
- Re: [spring] Spring protection - determining appl… Gyan Mishra
- Re: [spring] Spring protection - determining appl… Jeff Tantsura
- Re: [spring] Spring protection - determining appl… Robert Raszuk
- Re: [spring] Spring protection - determining appl… Jeff Tantsura
- Re: [spring] Spring protection - determining appl… Robert Raszuk
- Re: [spring] Spring protection - determining appl… Jeff Tantsura
- Re: [spring] Spring protection - determining appl… Martin Horneffer
- Re: [spring] Spring protection - determining appl… Alexander Vainshtein
- Re: [spring] Spring protection - determining appl… Robert Raszuk
- Re: [spring] Spring protection - determining appl… Shraddha Hegde
- Re: [spring] Spring protection - determining appl… Chengli (Cheng Li)
- Re: [spring] Spring protection - determining appl… Chengli (Cheng Li)
- Re: [spring] Spring protection - determining appl… Alexander Vainshtein
- Re: [spring] Spring protection - determining appl… Chengli (Cheng Li)