Re: [spring] Spring protection - determining applicability

Greg Mirsky <gregimirsky@gmail.com> Tue, 04 August 2020 00:18 UTC

Return-Path: <gregimirsky@gmail.com>
X-Original-To: spring@ietfa.amsl.com
Delivered-To: spring@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 958BF3A118D for <spring@ietfa.amsl.com>; Mon, 3 Aug 2020 17:18:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.301
X-Spam-Level:
X-Spam-Status: No, score=0.301 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, PDS_BTC_ID=0.498, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ehYqE9cuUJ0u for <spring@ietfa.amsl.com>; Mon, 3 Aug 2020 17:18:40 -0700 (PDT)
Received: from mail-lj1-x22b.google.com (mail-lj1-x22b.google.com [IPv6:2a00:1450:4864:20::22b]) (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 DC33D3A118B for <spring@ietf.org>; Mon, 3 Aug 2020 17:18:39 -0700 (PDT)
Received: by mail-lj1-x22b.google.com with SMTP id x9so41647218ljc.5 for <spring@ietf.org>; Mon, 03 Aug 2020 17:18:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=9noS4MOGsARFGY4wNTKQntbZCa1TscH1f9mWvWpUrro=; b=OxlBy0VmnZxbxNFb2ZC5uZNc8UlkKVMJtaXhHyTjrS/PjL6SVv1shihswAYL57vMR9 N6vM5bvo2RG/22UvO9C39x+aHMV+lYK8omDq2iS+P+039RMEALDJiPfrbyw4540ukATW 2Bxj/i8/5JAOnpZ+l1oYZAvpqqUS/fs1XgeRyfd2trG5mZ37VmoQbBIzEpd0eoGVo3AS iap2N8vatYa8PElcnCN3PptlklIIGy6sCGZJTDmAuL3XzPJjcXkbnQ0uSgLKqTWEFTrk eXI9T5ed8bX4uExaLWS80CEsDvgT2QLuGe2re0+WgkhgOK2AcgRe1JmORq8kxhS/nTZy Ji/A==
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=9noS4MOGsARFGY4wNTKQntbZCa1TscH1f9mWvWpUrro=; b=bbIeXDC4kjlED+TBZcx6RQyF/lqjZ19PeltRJA54LTcLj9yydkxrw75CAFXiAaQMj3 EtcQTr9fFUmUVB2r4l4ctuEsRulmDlHwLz+CgSCfLz+8HHGHjjfUK8daB5/5Lty/YB41 gpnc0agBrgF/1OM3RkKLXQpEXNYEWInLBu/tz1mXnuzn5B7nBPKogDRBJ/Ik15gIvDxx GO/9J2oUY1lojRGca2tV1Z9q3ifgdA7j0DocML7/W76s0tS53KHFDo203K0oXglCigMX Psi1VnDrfcB15WgK9wTlOO/rkT4oZevaiHe682gdKGeyDiabgu3GTzQKfdaBDDNi7E8y BHaA==
X-Gm-Message-State: AOAM5332YPeViZTdF2Nz+yR1xtu1+ykrRc9qDFjvil34eDlqDw3TVpz9 vse/AosN/3E2DqFBYQlxTp0duCBEW0aFJtug0kY=
X-Google-Smtp-Source: ABdhPJzlN+fL5rjGdD08tjcl3WbTIb09acLSzS5L4ZXRybZBwkq90IUWe0F7AvpJU3HU8E9122oTUduWe/DV3n7vDlY=
X-Received: by 2002:a2e:87c4:: with SMTP id v4mr8775187ljj.8.1596500317837; Mon, 03 Aug 2020 17:18:37 -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> <CA+RyBmWNLDq0Vrczvs454DNnRyQ0EMiQX1Tixp1bD_BkEA4p=A@mail.gmail.com> <VI1PR03MB5056B7BBAFE9BE2BD1BECDA2EE4A0@VI1PR03MB5056.eurprd03.prod.outlook.com>
In-Reply-To: <VI1PR03MB5056B7BBAFE9BE2BD1BECDA2EE4A0@VI1PR03MB5056.eurprd03.prod.outlook.com>
From: Greg Mirsky <gregimirsky@gmail.com>
Date: Mon, 3 Aug 2020 17:18:26 -0700
Message-ID: <CA+RyBmX1ipXV1etgTeMS4T+Pc4TKum5WtUbm2Ke1fSuJSZw2CQ@mail.gmail.com>
To: Andrew Alston <Andrew.Alston@liquidtelecom.com>
Cc: "Joel M. Halpern" <jmh@joelhalpern.com>, Robert Raszuk <robert@raszuk.net>, "spring@ietf.org" <spring@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000541eed05ac023253"
Archived-At: <https://mailarchive.ietf.org/arch/msg/spring/UpI0TdEKSSqQI7cDRxWf8H_hFZw>
Subject: Re: [spring] Spring protection - determining applicability
X-BeenThere: spring@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" <spring.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/spring>, <mailto:spring-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/spring/>
List-Post: <mailto:spring@ietf.org>
List-Help: <mailto:spring-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/spring>, <mailto:spring-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 04 Aug 2020 00:18:44 -0000

Hi Andrew,
thank you for your expedient response. I understand why operators are using
S-BFD to monitor the continuity of p2p SR-MPLS tunnel. But I'd note that
S-BFD does not support monitoring of multicast trees, ones that now can be
realized using the Replication SID defined in
draft-voyer-spring-sr-replication-segment
<https://tools.ietf.org/html/draft-voyer-spring-sr-replication-segment-02>.
But that can be achieved using RFC 8563
<https://tools.ietf.org/html/rfc8563>. Multicast and Composite polling
methods might not provide the required defect detection by the head of the
multicast tree. There's a faster option mentioned in RFC 8563, Unsolicited
notification. Applicability of the Unsolicited mode to SR-MPLS is described
in draft-mirsky-spring-bfd
<https://datatracker.ietf.org/doc/draft-mirsky-spring-bfd/?include_text=1>.

Regards,
Greg

On Mon, Aug 3, 2020 at 5:05 PM Andrew Alston <
Andrew.Alston@liquidtelecom.com> wrote:

> Greg we effectively get this using sbfd and fall back paths at the moment
> – far from ideal – but it does work.
>
>
>
> There are also other methods of detecting end to end reachability to do
> blackhole detection etc – particularly in the face of the fact that I’ve
> yet to see a functional implication of the sid verification flag.
>
>
>
> Could things be improved this regard? 100% but for now – the deep seated
> and critical need for the requirement overrides the drawbacks of the
> protection mechanisms we are forced to use at this point
>
>
>
> Andrew
>
>
>
>
>
> *From:* Greg Mirsky <gregimirsky@gmail.com>
> *Sent:* Tuesday, 4 August 2020 01:40
> *To:* Andrew Alston <Andrew.Alston@liquidtelecom.com>
> *Cc:* Joel M. Halpern <jmh@joelhalpern.com>om>; Robert Raszuk <
> robert@raszuk.net>gt;; spring@ietf.org
> *Subject:* Re: [spring] Spring protection - determining applicability
>
>
>
> Hi Andrew,
>
> would such requirements support using e2e protection?
>
>
>
> Regards,
>
> Greg
>
>
>
> On Mon, Aug 3, 2020 at 2:46 PM Andrew Alston <
> 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> *On Behalf Of *Joel M. Halpern
> *Sent:* Monday, 3 August 2020 21:36
> *To:* Robert Raszuk <robert@raszuk.net>
> *Cc:* 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%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://datatracker.ietf.org/doc/html/draft-ietf-bess-srv6-services-04>
> >
> > > 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://tools.ietf.org/html/rfc8402> 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://datatracker.ietf.org/doc/html/draft-hegde-spring-node-protection-for-sr-te-paths-07#section-3.4
> >
> >
> > > 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://datatracker.ietf.org/doc/html/rfc8679>] 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>>
> > >
> > > -----Original Message-----
> > > From: spring <spring-bounces@ietf.org
> <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
> <jmh@joelhalpern.com>>>>>>; 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%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 <mailto:spring@ietf.org
> <spring@ietf.org%20%3cmailto:spring@ietf.org>>>
> > >
> > >  > Subject: [spring] Spring protection - determining applicability
> > >
> > >  >
> > >
> > >  > (WG Chair hat Off, this is merely a note from a slightly
> > confused WG
> > >
> > >  > participant.)
> > >
> > >  >
> > >
> > >  > I have been reading the various repair drafts, and the various
> > >
> > >  > networks programming and service programming draft, and I am
> > trying to
> > >
> > >  > figure out one aspect of the combination.
> > >
> > >  >
> > >
> > >  > How does a node that is doing some form of bypass (suppose, for
> > >
> > >  > simplicity, it is Node N2 deciding to bypass the next SID for
> > a failed
> > >
> > >  > node N3) know that it is safe to do so?
> > >
> > >  >
> > >
> > >  > If the path was just for TE, then it is "safe" if the new path
> > meets
> > >
> > >  > the TE criteria.  or maybe it is safe if it is even close, as
> > long as
> > >
> > >  > it is not used for too long.
> > >
> > >  >
> > >
> > >  > But what if the node were a Firewall, included to meet legal
> > > requirements?
> > >
> > >  > Or was some other necessary programmatic transform (wince we are
> > >
> > >  > deliberately vague about what nodes can do when asked suitably.)
> > >
> > >  >
> > >
> > >  > Is there some "can be bypassed" indication in the routing
> > >
> > >  > advertisements that I missed?
> > >
> > >  >
> > >
> > >  > Thank you,
> > >
> > >  > Yours,
> > >
> > >  > Joel
> > >
> > >  >
> > >
> > >  > _______________________________________________
> > >
> > >  > spring mailing list
> > >
> > >  > spring@ietf.org <mailto:spring@ietf.org <spring@ietf.org>>
> > <mailto:spring@ietf.org <mailto: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>
> > >
> > >  > F%2Fwww.ietf.org
> > <http://2Fwww.ietf.org>%2Fmailman%2Flistinfo%2Fspring
> > >
> > > _______________________________________________
> > >
> > > spring mailing list
> > >
> > > spring@ietf.org <mailto:spring@ietf.org <spring@ietf.org>> <
> mailto:spring@ietf.org
> <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
> > >
> > >
> > >
> > >
> > ------------------------------------------------------------------------
> > > 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>>
> > > https://www.ietf.org/mailman/listinfo/spring
> > >
> >
> > _______________________________________________
> > spring mailing list
> > spring@ietf.org <mailto:spring@ietf.org <spring@ietf.org>>
> > https://www.ietf.org/mailman/listinfo/spring
> >
>
> _______________________________________________
> 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
>
>