Re: [spring] Spring protection - determining applicability

"Dongjie (Jimmy)" <jie.dong@huawei.com> Tue, 04 August 2020 06:50 UTC

Return-Path: <jie.dong@huawei.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 6E3EE3A0F1F for <spring@ietfa.amsl.com>; Mon, 3 Aug 2020 23:50:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.498
X-Spam-Level:
X-Spam-Status: No, score=0.498 tagged_above=-999 required=5 tests=[HTML_MESSAGE=0.001, PDS_BTC_ID=0.498, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
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 RrtrRLo_kfqr for <spring@ietfa.amsl.com>; Mon, 3 Aug 2020 23:50:43 -0700 (PDT)
Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2805B3A0F20 for <spring@ietf.org>; Mon, 3 Aug 2020 23:50:43 -0700 (PDT)
Received: from lhreml709-chm.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id D8452D2B45CE293DF03F; Tue, 4 Aug 2020 07:50:39 +0100 (IST)
Received: from dggeme702-chm.china.huawei.com (10.1.199.98) by lhreml709-chm.china.huawei.com (10.201.108.58) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1913.5; Tue, 4 Aug 2020 07:50:38 +0100
Received: from dggeme754-chm.china.huawei.com (10.3.19.100) by dggeme702-chm.china.huawei.com (10.1.199.98) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1913.5; Tue, 4 Aug 2020 14:50:36 +0800
Received: from dggeme754-chm.china.huawei.com ([10.6.80.77]) by dggeme754-chm.china.huawei.com ([10.6.80.77]) with mapi id 15.01.1913.007; Tue, 4 Aug 2020 14:50:36 +0800
From: "Dongjie (Jimmy)" <jie.dong@huawei.com>
To: "li_zhenqiang@hotmail.com" <li_zhenqiang@hotmail.com>, "Joel M. Halpern" <jmh@joelhalpern.com>, Robert Raszuk <robert@raszuk.net>
CC: "spring@ietf.org" <spring@ietf.org>
Thread-Topic: [spring] Spring protection - determining applicability
Thread-Index: AQHWaSfMmkgJsZ1580Gn7dLAcCrVYKklNGAAgAA0D4CAAMHVAIAABZ6AgAABgICAASfrmYAAIhaA
Date: Tue, 4 Aug 2020 06:50:36 +0000
Message-ID: <a5193b2356c745ac8bd56c1958631f16@huawei.com>
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> <HK0PR03MB40666777594E9E022BCBB2D1FC4A0@HK0PR03MB4066.apcprd03.prod.outlook.com>
In-Reply-To: <HK0PR03MB40666777594E9E022BCBB2D1FC4A0@HK0PR03MB4066.apcprd03.prod.outlook.com>
Accept-Language: en-US, zh-CN
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.108.243.143]
Content-Type: multipart/alternative; boundary="_000_a5193b2356c745ac8bd56c1958631f16huaweicom_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/spring/UGNFw4AR4ktyOX6M63rKKNG_tvM>
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 06:50:46 -0000

Hi all,

In my understanding, the objective and constraint with SR explicit path (aka. TE) and SR loose path may be different.

As Zhenqiang mentioned, an SR-TE path with a list of adj/End.X SIDs reflects the policy of the controller or the headend node, which may imply that a backup path that can meet the same policy usually is also provided by the controller or headend node. While depends on the policy, local protection may still be helpful.

If an SR path is built with one or a list of prefix-SIDs, the prefix/End SIDs are used to represent some policy/constraints which can be understood by both the controller, the headend, and at least some intermediate nodes, thus it is possible an intermediate node can provide a local protection which still meet the policy/constraints.

Best regards,
Jie

From: spring [mailto:spring-bounces@ietf.org] On Behalf Of li_zhenqiang@hotmail.com
Sent: Tuesday, August 4, 2020 12:14 PM
To: Joel M. Halpern <jmh@joelhalpern.com>om>; Robert Raszuk <robert@raszuk.net>
Cc: spring@ietf.org
Subject: Re: [spring] Spring protection - determining applicability

Hi Joel and All,

I think TE path should be coupled with end to end protection. It is not prudent to allow node or link protection in a TE path since the local protection may not satisfy the SLA requirements or the path constrains. In fact the node en-route except the headend and the controller has no idea about the SLA requirements and the path constrains. TE path only can be reoptimized or rebuilt end to end by the headend or the controller if you want your SLA requirements and path contrains be satisfied.

In my opinion, it is more appropriate to use local protection in IP fowarding scenarios rather than TE or policy paths.

Best Regards,
Zhenqiang Li
________________________________
li_zhenqiang@hotmail.com<mailto:li_zhenqiang@hotmail.com>

From: Joel M. Halpern<mailto:jmh@joelhalpern.com>
Date: 2020-08-04 02:35
To: Robert Raszuk<mailto:robert@raszuk.net>
CC: spring@ietf.org<mailto:spring@ietf.org>
Subject: Re: [spring] Spring protection - determining applicability
(Since the thread has gotten long enough, reiterating that this is as a
participant, not a WG chair.)

Yes, we are talking IP networks.  And yes, I have seen IP networks that
choose to drop packets.  For all sorts of reasons.
I think there are likely other reasons why one may not want a random
path rather than a chosen TE path.  I think it is important we be clear
about what constraints may be / are violated when we tell people they
have this tool (protective rerouting) that is intended to preserve QoS..

Let's be clear.  I am not arguing that this is not a good idea.  It is a
good idea.  And useful.  I am trying to figure otu what combination of
additional mechanisms and clear descriptions will lead to everyone
getting the behavior they expect (which may not be the behavior they
desire, but sometimes is the best we can do.)

Yours,
Joel

On 8/3/2020 2:30 PM, Robert Raszuk wrote:
> Joel,
>
> Are we still talking about IP networks here ? Or perhaps some hard
> slicing with real resource reservations or detnets ?
>
> Because if we are talking about IP networking I have two observations:
>
> A) If you need to traverse via a specific node (ie. firewall) you better
> apply IP encapsulation to that node. I don't think IP encapsulation can
> be hijacked today such that destination address of the packet is ignored.
>
> B) Have you seen any IP network where upon topology change (link or node
> failure) you suddenly start dropping flows in spite of SPT offering
> perhaps few ms longer path with 10 ms more jitter ?
>
> Or are some SR marketing slides promise to turn IP networks in
> something new ? Worse ... do they mention path quality guarantees,
> resource reservations ? I hope not.
>
> Thx,
> R.
>
>
>
>
>
>
>
>
>
> On Mon, Aug 3, 2020 at 8:10 PM Joel M. Halpern <jmh@joelhalpern.com
> <mailto:jmh@joelhalpern.com>> 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>
>     <mailto:Alexander.Vainshtein@ecitele.com>
>      >
>      > -----Original Message-----
>      > From: spring <spring-bounces@ietf.org
>     <mailto:spring-bounces@ietf.org>> On Behalf Of Mach Chen
>      > Sent: Monday, August 3, 2020 6:30 AM
>      > To: Joel M. Halpern <jmh@joelhalpern.com
>     <mailto:jmh@joelhalpern.com>>; spring@ietf.org<mailto:spring@ietf.org> <mailto:spring@ietf.org>
>      > Subject: Re: [spring] Spring protection - determining applicability
>      >
>      > Hi Joel,
>      >
>      > I think this is a good point that may not be discussed in the
>     past. And
>      > I also don't think there is a "can be bypassed" indication in the
>      > routing advertisement for now.
>      >
>      > IMHO, the information advertised by routing is neutral, such
>     information
>      > (can or cannot be bypassed) is more path specific, thus normally the
>      > controller should be responsible for deciding whether/which SID
>     can be
>      > bypassed.
>      >
>      > Best regards,
>      >
>      > Mach
>      >
>      >  > -----Original Message-----
>      >
>      >  > From: spring [mailto:spring-bounces@ietf.org
>     <mailto:spring-bounces@ietf.org>] On Behalf Of Joel M.
>      >
>      >  > Halpern
>      >
>      >  > Sent: Monday, August 3, 2020 7:51 AM
>      >
>      >  > To: spring@ietf.org<mailto:spring@ietf.org> <mailto:spring@ietf.org>
>     <mailto:spring@ietf.org <mailto:spring@ietf.org<mailto:spring@ietf.org%20%3cmailto:spring@ietf.org>>>
>      >
>      >  > Subject: [spring] Spring protection - determining applicability
>      >
>      >  >
>      >
>      >  > (WG Chair hat Off, this is merely a note from a slightly
>     confused WG
>      >
>      >  > participant.)
>      >
>      >  >
>      >
>      >  > I have been reading the various repair drafts, and the various
>      >
>      >  > networks programming and service programming draft, and I am
>     trying to
>      >
>      >  > figure out one aspect of the combination.
>      >
>      >  >
>      >
>      >  > How does a node that is doing some form of bypass (suppose, for
>      >
>      >  > simplicity, it is Node N2 deciding to bypass the next SID for
>     a failed
>      >
>      >  > node N3) know that it is safe to do so?
>      >
>      >  >
>      >
>      >  > If the path was just for TE, then it is "safe" if the new path
>     meets
>      >
>      >  > the TE criteria.  or maybe it is safe if it is even close, as
>     long as
>      >
>      >  > it is not used for too long.
>      >
>      >  >
>      >
>      >  > But what if the node were a Firewall, included to meet legal
>      > requirements?
>      >
>      >  > Or was some other necessary programmatic transform (wince we are
>      >
>      >  > deliberately vague about what nodes can do when asked suitably.)
>      >
>      >  >
>      >
>      >  > Is there some "can be bypassed" indication in the routing
>      >
>      >  > advertisements that I missed?
>      >
>      >  >
>      >
>      >  > Thank you,
>      >
>      >  > Yours,
>      >
>      >  > Joel
>      >
>      >  >
>      >
>      >  > _______________________________________________
>      >
>      >  > spring mailing list
>      >
>      >  > spring@ietf.org<mailto:spring@ietf.org> <mailto:spring@ietf.org>
>     <mailto:spring@ietf.org <mailto:spring@ietf.org<mailto:spring@ietf.org%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/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> <mailto:spring@ietf.org> <mailto:spring@ietf.org
>     <mailto: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> <mailto:spring@ietf.org>
>      > https://www.ietf.org/mailman/listinfo/spring
>      >
>
>     _______________________________________________
>     spring mailing list
>     spring@ietf.org<mailto:spring@ietf.org> <mailto:spring@ietf.org>
>     https://www.ietf.org/mailman/listinfo/spring
>

_______________________________________________
spring mailing list
spring@ietf.org<mailto:spring@ietf.org>
https://www.ietf.org/mailman/listinfo/spring