Re: [Teas] [E] Re: What SLOs and SLEs should be in the Slicing Service Model?
"Jalil, Luay" <luay.jalil@verizon.com> Fri, 25 March 2022 20:10 UTC
Return-Path: <luay.jalil@verizon.com>
X-Original-To: teas@ietfa.amsl.com
Delivered-To: teas@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B03F3A07E2 for <teas@ietfa.amsl.com>; Fri, 25 Mar 2022 13:10:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.105
X-Spam-Level:
X-Spam-Status: No, score=-2.105 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, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H5=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=verizon.com header.b=LpOK2LRW; dkim=pass (2048-bit key) header.d=verizon-com.20210112.gappssmtp.com header.b=el6YuM5M
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 cUxBDorfTxsS for <teas@ietfa.amsl.com>; Fri, 25 Mar 2022 13:10:06 -0700 (PDT)
Received: from mx0b-0024a201.pphosted.com (mx0b-0024a201.pphosted.com [148.163.153.92]) (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 A50193A07D6 for <teas@ietf.org>; Fri, 25 Mar 2022 13:10:05 -0700 (PDT)
Received: from pps.filterd (m0115887.ppops.net [127.0.0.1]) by mx0b-0024a201.pphosted.com (8.16.1.2/8.16.1.2) with ESMTP id 22PK4uUQ013985 for <teas@ietf.org>; Fri, 25 Mar 2022 16:10:05 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=verizon.com; h=mime-version : references : in-reply-to : from : date : message-id : subject : to : cc : content-type; s=corp; bh=yaHctK3pL1rsGdGHZfnpULs0Vy4OEXrODRa4PCQwTt0=; b=LpOK2LRW9A4IcshMvkgcu1Msysadgj0/tWOM3bgUfmbroWDp7UDUMBSeGnoi4XusxiVi wI6PcWQDh6swfTIjevJLKV+ucyPm5brw+OgAulPTPjxb1fb53AQ1k4Bua8b9XqJ7WpGK 0COy17vPtLv1HhrtxWrlYGk2LRtNhOFjzqI=
Received: from mail-oo1-f70.google.com (mail-oo1-f70.google.com [209.85.161.70]) by mx0b-0024a201.pphosted.com (PPS) with ESMTPS id 3f1fk2whk4-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT) for <teas@ietf.org>; Fri, 25 Mar 2022 16:10:04 -0400
Received: by mail-oo1-f70.google.com with SMTP id x8-20020a4a3948000000b00320c4f9ae47so5007456oog.15 for <teas@ietf.org>; Fri, 25 Mar 2022 13:10:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=verizon-com.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=yaHctK3pL1rsGdGHZfnpULs0Vy4OEXrODRa4PCQwTt0=; b=el6YuM5MZL8ttA5HIm3ulPI6gahbFtA+t7HA6S0AUd9WEDy/09M2zugsyCdCb8Jaw6 YpfoHdu2C5Oq9V2KmWp5bCdXub3gPTD0E7P9EGIeDLem3n/0kqphePw4hfe64PyqMIJz 4azdN1dPLhSMdL2MAo5GLMPmLGjU/ubBz6lz1m2OYgduyXMe6bhrCDiI/V8AJ4uUj2JO T5b1pJsC+ivOQ8NTNUUcJkNp7b9T1ioHI9fd+HCBmOHAN2FNv6Y4E6RjZkkdXcmVyvfZ OZxDk5ziVbX68yYVBH/cWUtG9DYEbHsp09ulpBDuD2YovO35/bqp08V3IRypcXkQSLNz 8iwA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=yaHctK3pL1rsGdGHZfnpULs0Vy4OEXrODRa4PCQwTt0=; b=MItdUGqXu3tA/FntJtU0KXyWCkmxXsbo1C6OkQ0TOcKkQm9iTWe2v4PS4wLP15ZfPk RfQhBIj6gt1wa0IlWJd43gsMh59cGUWSqOJ1Xd/z0qAVv7efJYywj4yT7eBvP7WB634h c5Nkvrrq/laR6UxboGi9nVPVVXuGWmsNFA9difC/IBNbA1hDYJTOw1xdDA12TwLR0ScI KQGCxLdAvhvHgjVOTGkYlj0QrITKC7+4CiaBH0bC/py3kdfGtMdh4VSRwvA8dNvBzhQi 5IbbJxENIsi8Dh34brMdk6xrSa0pjhtrdlHwc0nBjGXXpAYzjh4vAEjTT6krWX0lIayY R9Fg==
X-Gm-Message-State: AOAM5335brSdaOsqLqw88itKVvSkAET+dps3sC0ea9JbYb52f1LAZo0P v5KSoJ/C0nIsisO452nf4XxXCIyywU6P8fCRyZGF6bdq19vcCdI9GIZCQP+MEGc+XmNWA2hxn07 OMD1B8tA8zWd3kXRiE8/H
X-Received: by 2002:a9d:6501:0:b0:5b2:72d6:9e33 with SMTP id i1-20020a9d6501000000b005b272d69e33mr5179760otl.37.1648239003369; Fri, 25 Mar 2022 13:10:03 -0700 (PDT)
X-Google-Smtp-Source: ABdhPJzAN/9K01j5GmuV4UCMUKRGClwkLmsutUmrprWtCe6KGU2HzKdD/jqRe7VYj+3ILGFnnu4XZA9YYttnvc1/oVA=
X-Received: by 2002:a9d:6501:0:b0:5b2:72d6:9e33 with SMTP id i1-20020a9d6501000000b005b272d69e33mr5179735otl.37.1648239002955; Fri, 25 Mar 2022 13:10:02 -0700 (PDT)
MIME-Version: 1.0
References: <001001d83ebc$759fa480$60deed80$@olddog.co.uk> <5555_1648044491_623B29CB_5555_257_4_8693a9ff074e4aa18f1c6098791f836c@orange.com> <0c243152-e58f-e71d-6d42-df09933dcffe@joelhalpern.com> <15388_1648130629_623C7A45_15388_1_2_9344dd3ead7e404996bc1abfa0e39081@orange.com> <3a917051-7ac5-240b-b738-1cb2ed4b7491@joelhalpern.com> <18986_1648131629_623C7E2D_18986_340_25_72aafee7391b4faa87587f50bf3100fd@orange.com> <e4e48783-4ce9-3a6f-953f-319c934d819e@joelhalpern.com> <2347_1648132547_623C81C3_2347_400_3_530dad9f874a4488b0db998365202dd9@orange.com> <CABNhwV3O0h9-vyke5eUOY5q+9PQ4yQBr6vXtyV1zEik+-z0-BA@mail.gmail.com> <61ab2fb5-c417-a6ce-78c1-ebef67c77311@joelhalpern.com>
In-Reply-To: <61ab2fb5-c417-a6ce-78c1-ebef67c77311@joelhalpern.com>
From: "Jalil, Luay" <luay.jalil@verizon.com>
Date: Fri, 25 Mar 2022 20:09:51 +0000
Message-ID: <CAO8-O7ocondF7CJm+cmc=hmoxzQ6RTk57HLOQnh+QQuPEKthJg@mail.gmail.com>
To: "Joel M. Halpern" <jmh@joelhalpern.com>
Cc: Gyan Mishra <hayabusagsm@gmail.com>, adrian@olddog.co.uk, TEAS WG <teas@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000046c5f205db108c04"
X-mailroute: internal
X-Proofpoint-GUID: _crAJL7hXi3DMNlc18Me0S7IgkToCrRC
X-Proofpoint-ORIG-GUID: _crAJL7hXi3DMNlc18Me0S7IgkToCrRC
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas/n8UlyaSlPRHd5VUJXIz626fQAmY>
Subject: Re: [Teas] [E] Re: What SLOs and SLEs should be in the Slicing Service Model?
X-BeenThere: teas@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Traffic Engineering Architecture and Signaling working group discussion list <teas.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/teas>, <mailto:teas-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/teas/>
List-Post: <mailto:teas@ietf.org>
List-Help: <mailto:teas-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/teas>, <mailto:teas-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 25 Mar 2022 20:10:12 -0000
Agree with Joel. Providers can look at SLOs & SLEs and decide what goes in the SLA (legal agreement) Regards, Luay On Fri, Mar 25, 2022, 7:52 PM Joel M. Halpern <jmh@joelhalpern.com> wrote: > Sounds like we need to clarify the verbiage. SLEs are, as I understand > it, indeed non-measurables. But they are not the legal translation of > the SLOs. They are expression of customer expectations that are not > directly observable or measurable. The example I have the easiest time > understanding is that the customer expects the operator to encrypt the > traffic across the service. > > Yours, > Joel > > On 3/25/2022 3:07 PM, Gyan Mishra wrote: > > Hi Med & Joel > > > > I reread section 4.1 of the slice draft and to me it seems that SLO is > > from provider POV measurable indicators and SLE is the is unmeasurable > > expectations which is makes up the customer fulfillment of obligations > > by the provider which would be like taking the tangible measurement > > characteristics from the SLO and translation into legal obligation > > fulfillment verbiage that goes into the service agreement. So as the > > SLE is not tangible but just a translation of SLO metrics into legal > > verbiage my thoughts are that the framework as well as Yang model need > > only focus on the SLO tangible metrics and leave the intangible for the > > lawyers writing the customer agreement. > > > > > > 4.1 > > < > https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_html_draft-2Dietf-2Dteas-2Dietf-2Dnetwork-2Dslices-2D09-23section-2D4.1&d=DwIGaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=k0DrrBeS0St-D1jEwNQ_u1ZyHQXQly5fgCsWF0VTh7o&m=J9C0uO0pyymUD5TiJjBzWVIBLtm6tjJWU_KbStCzl45FBHTa6b70W0rrKaqLhnKA&s=_9k1Nl-OUCyzLyrk4L_1Zs3rtdk6_Z_-D0_pTvR6Fko&e= > >. > > Objectives for IETF Network Slices > > > > An IETF Network Slice service is defined in terms of quantifiable > > characteristics known as Service Level Objectives (SLOs) and > > unquantifiable characteristics known as Service Level Expectations > > (SLEs). SLOs are expressed in terms Service Level Indicators (SLIs), > > and together with the SLEs form the contractual agreement between > > service customer and service provider known as a Service Level > > Agreement (SLA). > > > > The terms are defined as follows: > > > > * A Service Level Indicator (SLI) is a quantifiable measure of an > > aspect of the performance of a network. For example, it may be a > > measure of throughput in bits per second, or it may be a measure > > of latency in milliseconds. > > > > * A Service Level Objective (SLO) is a target value or range for the > > measurements returned by observation of an SLI. For example, an > > SLO may be expressed as "SLI <= target", or "lower bound <= SLI <= > > upper bound". A customer can determine whether the provider is > > meeting the SLOs by performing measurements on the traffic. > > > > * A Service Level Expectation (SLE) is an expression of an > > unmeasurable service-related request that a customer of an IETF > > Network Slice makes of the provider. An SLE is distinct from an > > SLO because the customer may have little or no way of determining > > whether the SLE is being met, but they still contract with the > > provider for a service that meets the expectation. > > > > > > > > On Thu, Mar 24, 2022 at 10:36 AM <mohamed.boucadair@orange.com > > <mailto:mohamed.boucadair@orange.com>> wrote: > > > > Re-, > > > > They shouldn't! > > > > This is why I'm suggesting to not have that tagging frozen in the > > model. We can simply have a provision for a set of parameters. These > > parameters will be included to characterize the service with a > > service assurance component that will call out the identity of the > > subset of parameters that will be used as committed ones. That > > component will also include other data to ensure the same based used > > for assessment, etc. > > > > Cheers, > > Med > > > > > -----Message d'origine----- > > > De : Joel M. Halpern <jmh@joelhalpern.com > > <mailto:jmh@joelhalpern.com>> > > > Envoyé : jeudi 24 mars 2022 15:29 > > > À : BOUCADAIR Mohamed INNOV/NET <mohamed.boucadair@orange.com > > <mailto:mohamed.boucadair@orange.com>> > > > Cc : 'TEAS WG' <teas@ietf.org <mailto:teas@ietf.org>>; > > adrian@olddog.co.uk <mailto:adrian@olddog.co.uk> > > > Objet : Re: [Teas] What SLOs and SLEs should be in the Slicing > > Service > > > Model? > > > > > > If the others are best effort, why would they be included in the > SLO? > > > (We do not assume that every IETF network slice service will > > specify all > > > possible parameters.) > > > > > > Yours, > > > Joel > > > > > > On 3/24/2022 10:20 AM, mohamed.boucadair@orange.com > > <mailto:mohamed.boucadair@orange.com> wrote: > > > > Re-, > > > > > > > > Some services may be sensitive to delay for example but the > > slice service > > > request may include (for whatever reason) not only the delay, but > > also > > > other attributes that are currently listed as SLOs in the draft. > The > > > provider is requested to only commit on the delay and best effort > > for the > > > other attributes. > > > > > > > > Cheers, > > > > Med > > > > > > > >> -----Message d'origine----- > > > >> De : Joel M. Halpern <jmh@joelhalpern.com > > <mailto:jmh@joelhalpern.com>> Envoyé : jeudi 24 mars > > > >> 2022 15:07 À : BOUCADAIR Mohamed INNOV/NET > > > >> <mohamed.boucadair@orange.com > > <mailto:mohamed.boucadair@orange.com>> Cc : 'TEAS WG' <teas@ietf.org > > <mailto:teas@ietf.org>>; > > > >> adrian@olddog.co.uk <mailto:adrian@olddog.co.uk> Objet : Re: > > [Teas] What SLOs and SLEs should be > > > >> in the Slicing Service Model? > > > >> > > > >> Interesting. If they are indeed not coupled, then you are > clearly > > > >> correct about representation. > > > >> > > > >> Can you give an example so I can understand when they would > not be > > > coupled. > > > >> I had leapt to the (quite possibly incorrect) conclusion that > > the two > > > >> sets of properties went together. > > > >> > > > >> Thank you, > > > >> Joel > > > >> > > > >> On 3/24/2022 10:03 AM, mohamed.boucadair@orange.com > > <mailto:mohamed.boucadair@orange.com> wrote: > > > >>> Hi Joel, > > > >>> > > > >>> It is. > > > >>> > > > >>> As mentioned below, this should be covered as part of service > > > >> assurance/fulfillment/reporting parameters. Which parameters > > to put > > > >> there is deployment-specific. Not all parameters tagged as SLO > > in the > > > >> framework will end up as part of the > > assurance/fulfillment/reporting. > > > >>> > > > >>> Cheers, > > > >>> Med > > > >>> > > > >>>> -----Message d'origine----- > > > >>>> De : Joel M. Halpern <jmh@joelhalpern.com > > <mailto:jmh@joelhalpern.com>> Envoyé : jeudi 24 mars > > > >>>> 2022 14:52 À : BOUCADAIR Mohamed INNOV/NET > > > >>>> <mohamed.boucadair@orange.com > > <mailto:mohamed.boucadair@orange.com>>; adrian@olddog.co.uk > > <mailto:adrian@olddog.co.uk>; 'TEAS WG' > > > >>>> <teas@ietf.org <mailto:teas@ietf.org>> Objet : Re: [Teas] > > What SLOs and SLEs should be in > > > >>>> the Slicing Service Model? > > > >>>> > > > >>>> Isn't it important to distinguish between "these are things I > > > >>>> expect you to do, measure, and report" and "these are things > I > > > >>>> would like you to do even though they are not measurable or > > > reportable"? > > > >>>> > > > >>>> Yours, > > > >>>> Joel > > > >>>> > > > >>>> On 3/23/2022 10:08 AM, mohamed.boucadair@orange.com > > <mailto:mohamed.boucadair@orange.com> wrote: > > > >>>>> Hi all, > > > >>>>> > > > >>>>> This message actually triggers a companion comment I have > > on the > > > >>>>> SLO/SLE > > > >>>> taxonomy. From the service modeling standpoint, I suggest > > that we > > > >>>> don't inherit that taxonomy for various reasons: > > > >>>>> > > > >>>>> * Things would be much simpler if we just focus on service > > > >>>>> requirements > > > >>>> without making an assumption how such requirement is > > expressed and > > > >>>> whether it is > > quantified/quantitative/qualitative/measurable/etc. > > > >>>> Whether/how a specific service requirement is covered by > service > > > >>>> assurance/fulfillment can be part of the slice service > > definition > > > >> itself. > > > >>>>> > > > >>>>> * What we may tag as an SLE today because of the technology > > > >>>>> limitations, > > > >>>> may not stay as such forever. It may be true that an > > "expectation" > > > >>>> may not be easily assessed using current techniques (and > thus be > > > >>>> tagged as SLE), but this does not prevent that innovative > means > > > >>>> would be defined in the future (which means that it is an > > SLO, not > > > >>>> an SLE > > > >> anymore). > > > >>>>> > > > >>>>> * We are artificially adding extra complexity for the > modelling > > > >>>>> part as > > > >>>> service requirement will need to be classified based as SLO > > or SLEs. > > > >>>>> > > > >>>>> * I remember that Kiran agreed at least to not import that > > > >>>>> taxonomy into > > > >>>> the data model when we were discussing the call for adoption > > of the > > > >>>> slice > > > >>>> definition: > > > >>>>> > > > >>>>> ==(the full message from Kiran can be found in the > archives)=== > > > >>>>> "However, it should not imply that NBI models are required > > to have > > > >>>> SLE/SLO indicators and I totally agreed with your comments on > > > >>>> draft-wd- teas-ietf-network-slice-nbi-yang-03" > > > >>>>> == > > > >>>>> > > > >>>>> Cheers, > > > >>>>> Med > > > >>>>> > > > >>>>>> -----Message d'origine----- > > > >>>>>> De : Teas <teas-bounces@ietf.org > > <mailto:teas-bounces@ietf.org>> De la part de Adrian Farrel > > > >>>>>> Envoyé > > > >>>>>> : mercredi 23 mars 2022 14:47 À : 'TEAS WG' <teas@ietf.org > > <mailto:teas@ietf.org>> Objet : > > > >>>>>> [Teas] What SLOs and SLEs should be in the Slicing Service > > Model? > > > >>>>>> > > > >>>>>> Hi, > > > >>>>>> > > > >>>>>> Sorry for my audio being a mess in TEAS today. > > > >>>>>> > > > >>>>>> I believe I heard the discussion between Kireeti and Reza > > > >>>>>> correctly, and there was some follow-up in the chat. > > > >>>>>> > > > >>>>>> I agree that "Protection" is a realisation feature and so > it > > > >>>>>> qualifies as an SLE, if at all. > > > >>>>>> But "Reliability" is clearly an SLO. Usually expressed as > > maximum > > > >>>>>> down- time per unit of time, or maximum lost traffic. > > > >>>>>> > > > >>>>>> There was one thing that I *think* I heard. This was Reza > > saying > > > >>>>>> that the service YANG model was only including the SLOs > > and SLEs > > > >>>>>> noted in the framework. Maybe I misheard "only" because I > > think > > > >>>>>> that might be a mistake. > > > >>>>>> The YANG model should certainly be interested in what the > > > >>>>>> framework says, but it is not a requirement that all SLOs > and > > > >>>>>> SLEs in the framework be in the model if the authors find > that > > > >>>>>> there is no interest in implementing them, and there should > > > >>>>>> certainly be no limitation about including additional SLOs > > or SLEs > > > in the YANG model. > > > >>>>>> Indeed, the SLOs and SLEs listed in the framework are > > presented > > > >>>>>> as > > > >>>> examples. > > > >>>>>> > > > >>>>>> Cheers, > > > >>>>>> Adrian > > > >>>>>> > > > >>>>>> _______________________________________________ > > > >>>>>> Teas mailing list > > > >>>>>> Teas@ietf.org <mailto:Teas@ietf.org> > > > >>>>>> > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_teas&d=DwIGaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=k0DrrBeS0St-D1jEwNQ_u1ZyHQXQly5fgCsWF0VTh7o&m=J9C0uO0pyymUD5TiJjBzWVIBLtm6tjJWU_KbStCzl45FBHTa6b70W0rrKaqLhnKA&s=UtvLV-EiyvqFiTqhgtj81sOzi0cgp2N7loVPcL_2FN0&e= > > < > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_teas&d=DwIGaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=k0DrrBeS0St-D1jEwNQ_u1ZyHQXQly5fgCsWF0VTh7o&m=J9C0uO0pyymUD5TiJjBzWVIBLtm6tjJWU_KbStCzl45FBHTa6b70W0rrKaqLhnKA&s=UtvLV-EiyvqFiTqhgtj81sOzi0cgp2N7loVPcL_2FN0&e= > > > > > >>>>> > > > >>>>> > > __________________________________________________________________ > > > >>>>> __ __ ___________________________________________________ > > > >>>>> > > > >>>>> Ce message et ses pieces jointes peuvent contenir des > > informations > > > >>>>> confidentielles ou privilegiees et ne doivent donc pas etre > > > >>>>> diffuses, exploites ou copies sans autorisation. Si vous > > avez recu > > > >>>>> ce message par erreur, veuillez le signaler a l'expediteur > > et le > > > >>>>> detruire ainsi que > > > >>>> les pieces jointes. Les messages electroniques etant > > susceptibles > > > >>>> d'alteration, Orange decline toute responsabilite si ce > > message a > > > >>>> ete altere, deforme ou falsifie. Merci. > > > >>>>> > > > >>>>> This message and its attachments may contain confidential or > > > >>>>> privileged information that may be protected by law; they > > should > > > >>>>> not be > > > >>>> distributed, used or copied without authorisation. > > > >>>>> If you have received this email in error, please notify the > > sender > > > >>>>> and > > > >>>> delete this message and its attachments. > > > >>>>> As emails may be altered, Orange is not liable for messages > > that > > > >>>>> have > > > >>>> been modified, changed or falsified. > > > >>>>> Thank you. > > > >>>>> > > > >>>>> _______________________________________________ > > > >>>>> Teas mailing list > > > >>>>> Teas@ietf.org <mailto:Teas@ietf.org> > > > >>>>> > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_teas&d=DwIGaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=k0DrrBeS0St-D1jEwNQ_u1ZyHQXQly5fgCsWF0VTh7o&m=J9C0uO0pyymUD5TiJjBzWVIBLtm6tjJWU_KbStCzl45FBHTa6b70W0rrKaqLhnKA&s=UtvLV-EiyvqFiTqhgtj81sOzi0cgp2N7loVPcL_2FN0&e= > > < > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_teas&d=DwIGaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=k0DrrBeS0St-D1jEwNQ_u1ZyHQXQly5fgCsWF0VTh7o&m=J9C0uO0pyymUD5TiJjBzWVIBLtm6tjJWU_KbStCzl45FBHTa6b70W0rrKaqLhnKA&s=UtvLV-EiyvqFiTqhgtj81sOzi0cgp2N7loVPcL_2FN0&e= > > > > > >>> > > > >>> > > ____________________________________________________________________ > > > >>> __ ___________________________________________________ > > > >>> > > > >>> Ce message et ses pieces jointes peuvent contenir des > > informations > > > >>> confidentielles ou privilegiees et ne doivent donc pas etre > > > >>> diffuses, exploites ou copies sans autorisation. Si vous avez > > recu > > > >>> ce message par erreur, veuillez le signaler a l'expediteur et > le > > > >>> detruire ainsi que > > > >> les pieces jointes. Les messages electroniques etant > susceptibles > > > >> d'alteration, Orange decline toute responsabilite si ce > > message a ete > > > >> altere, deforme ou falsifie. Merci. > > > >>> > > > >>> This message and its attachments may contain confidential or > > > >>> privileged information that may be protected by law; they > > should not > > > >>> be > > > >> distributed, used or copied without authorisation. > > > >>> If you have received this email in error, please notify the > > sender > > > >>> and > > > >> delete this message and its attachments. > > > >>> As emails may be altered, Orange is not liable for messages > that > > > >>> have > > > >> been modified, changed or falsified. > > > >>> Thank you. > > > >>> > > > > > > > > > > > ______________________________________________________________________ > > > > ___________________________________________________ > > > > > > > > Ce message et ses pieces jointes peuvent contenir des > informations > > > > confidentielles ou privilegiees et ne doivent donc pas etre > > diffuses, > > > > exploites ou copies sans autorisation. Si vous avez recu ce > message > > > > par erreur, veuillez le signaler a l'expediteur et le detruire > > ainsi que > > > les pieces jointes. Les messages electroniques etant susceptibles > > > d'alteration, Orange decline toute responsabilite si ce message a > ete > > > altere, deforme ou falsifie. Merci. > > > > > > > > This message and its attachments may contain confidential or > > > > privileged information that may be protected by law; they > > should not be > > > distributed, used or copied without authorisation. > > > > If you have received this email in error, please notify the > > sender and > > > delete this message and its attachments. > > > > As emails may be altered, Orange is not liable for messages > > that have > > > been modified, changed or falsified. > > > > Thank you. > > > > > > > > > _________________________________________________________________________________________________________________________ > > > > Ce message et ses pieces jointes peuvent contenir des informations > > confidentielles ou privilegiees et ne doivent donc > > pas etre diffuses, exploites ou copies sans autorisation. Si vous > > avez recu ce message par erreur, veuillez le signaler > > a l'expediteur et le detruire ainsi que les pieces jointes. Les > > messages electroniques etant susceptibles d'alteration, > > Orange decline toute responsabilite si ce message a ete altere, > > deforme ou falsifie. Merci. > > > > This message and its attachments may contain confidential or > > privileged information that may be protected by law; > > they should not be distributed, used or copied without authorisation. > > If you have received this email in error, please notify the sender > > and delete this message and its attachments. > > As emails may be altered, Orange is not liable for messages that > > have been modified, changed or falsified. > > Thank you. > > > > _______________________________________________ > > Teas mailing list > > Teas@ietf.org <mailto:Teas@ietf.org> > > > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_teas&d=DwIGaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=k0DrrBeS0St-D1jEwNQ_u1ZyHQXQly5fgCsWF0VTh7o&m=J9C0uO0pyymUD5TiJjBzWVIBLtm6tjJWU_KbStCzl45FBHTa6b70W0rrKaqLhnKA&s=UtvLV-EiyvqFiTqhgtj81sOzi0cgp2N7loVPcL_2FN0&e= > > < > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_teas&d=DwIGaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=k0DrrBeS0St-D1jEwNQ_u1ZyHQXQly5fgCsWF0VTh7o&m=J9C0uO0pyymUD5TiJjBzWVIBLtm6tjJWU_KbStCzl45FBHTa6b70W0rrKaqLhnKA&s=UtvLV-EiyvqFiTqhgtj81sOzi0cgp2N7loVPcL_2FN0&e= > > > > > > -- > > > > <http://www.verizon.com/> > > > > *Gyan Mishra* > > > > /Network Solutions A//rchitect / > > > > /Email gyan.s.mishra@verizon.com <mailto:gyan.s.mishra@verizon.com>// > > / > > > > /M 301 502-1347 > > > > / > > > > > > _______________________________________________ > Teas mailing list > Teas@ietf.org > > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_teas&d=DwIGaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=k0DrrBeS0St-D1jEwNQ_u1ZyHQXQly5fgCsWF0VTh7o&m=J9C0uO0pyymUD5TiJjBzWVIBLtm6tjJWU_KbStCzl45FBHTa6b70W0rrKaqLhnKA&s=UtvLV-EiyvqFiTqhgtj81sOzi0cgp2N7loVPcL_2FN0&e= >
- [Teas] What SLOs and SLEs should be in the Slicin… Adrian Farrel
- Re: [Teas] What SLOs and SLEs should be in the Sl… mohamed.boucadair
- Re: [Teas] What SLOs and SLEs should be in the Sl… Joel M. Halpern
- Re: [Teas] What SLOs and SLEs should be in the Sl… mohamed.boucadair
- Re: [Teas] What SLOs and SLEs should be in the Sl… Joel M. Halpern
- Re: [Teas] What SLOs and SLEs should be in the Sl… mohamed.boucadair
- Re: [Teas] What SLOs and SLEs should be in the Sl… Joel M. Halpern
- Re: [Teas] What SLOs and SLEs should be in the Sl… mohamed.boucadair
- Re: [Teas] What SLOs and SLEs should be in the Sl… Gyan Mishra
- Re: [Teas] What SLOs and SLEs should be in the Sl… Joel M. Halpern
- Re: [Teas] [E] Re: What SLOs and SLEs should be i… Jalil, Luay
- Re: [Teas] What SLOs and SLEs should be in the Sl… Adrian Farrel
- Re: [Teas] What SLOs and SLEs should be in the Sl… Gyan Mishra
- Re: [Teas] What SLOs and SLEs should be in the Sl… John E Drake
- Re: [Teas] What SLOs and SLEs should be in the Sl… Gyan Mishra
- Re: [Teas] What SLOs and SLEs should be in the Sl… John E Drake
- Re: [Teas] What SLOs and SLEs should be in the Sl… Gyan Mishra
- Re: [Teas] What SLOs and SLEs should be in the Sl… John E Drake
- Re: [Teas] What SLOs and SLEs should be in the Sl… Gyan Mishra
- Re: [Teas] What SLOs and SLEs should be in the Sl… John E Drake
- [Teas] Protection: SLO or SLE? [Re: What SLOs and… Greg Mirsky
- Re: [Teas] Protection: SLO or SLE? [Re: What SLOs… Gyan Mishra
- Re: [Teas] Protection: SLO or SLE? [Re: What SLOs… Greg Mirsky
- Re: [Teas] Protection: SLO or SLE? [Re: What SLOs… Gyan Mishra
- Re: [Teas] What SLOs and SLEs should be in the Sl… mohamed.boucadair