Re: [Teas] What SLOs and SLEs should be in the Slicing Service Model?
Gyan Mishra <hayabusagsm@gmail.com> Fri, 25 March 2022 21:32 UTC
Return-Path: <hayabusagsm@gmail.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 8C5593A0A9A for <teas@ietfa.amsl.com>; Fri, 25 Mar 2022 14:32:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.095
X-Spam-Level:
X-Spam-Status: No, score=-2.095 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, FREEMAIL_FROM=0.001, HTML_FONT_FACE_BAD=0.001, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01, 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 (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 qNuJ01QpO49J for <teas@ietfa.amsl.com>; Fri, 25 Mar 2022 14:31:55 -0700 (PDT)
Received: from mail-pg1-x535.google.com (mail-pg1-x535.google.com [IPv6:2607:f8b0:4864:20::535]) (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 D916D3A0BEE for <teas@ietf.org>; Fri, 25 Mar 2022 14:31:54 -0700 (PDT)
Received: by mail-pg1-x535.google.com with SMTP id q19so7431582pgm.6 for <teas@ietf.org>; Fri, 25 Mar 2022 14:31:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=G+MtTFeXxnCdD9GBFi0cZVVv6WTtVUEqB+kQF0Sd+IA=; b=hZzlLS7ObBnIZm+dbon662WWZY9lwbQjkeUPwsSlC0ojzsOm83JUCfGhFgkA9IGtCS TusqEke0ngVv4zXD9f3saO5dB7GeMRbobqwEArNfmgjxBFOyW7f2cuLwZT023+I51Swc cUSv4RAlquAD4oAzWd/+UsD0k5A2F2LozW7mxZTVtE4cdqkyNJVoclpteH+p/Zrggqy0 +Xr1rXmqdfGGKx+iWsrW6Jwb/T/vZNRtBPzO/wyFrIkhm+UVbFs9IBvSbV4I7ESCnWZ/ JgZeVq8VQg2YDtFXsHBw2tE2b1XlW1xyT9sIUa+dAXqoXDY9/7qKnW3529vYypGhFF5W KyKQ==
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=G+MtTFeXxnCdD9GBFi0cZVVv6WTtVUEqB+kQF0Sd+IA=; b=5uKa+ibd+YWvpJ7bRg+I1ef5sq/VZ70Vq1rW5GvlCN59MfIIf7YrwTcCQKEn/IdEYJ gLcBVZIKvgwFbHvdkRDdrnx2a4jHb8rVQnb6JUA6Cxr5824AfN7esS98HsYEmWSENWng +vCvvZTncIeK/Evh37yViTQiW8w0hWUPlBBiNPc80M7WowvvP1kRhFyNC/cyuJbCfvIO ySEhERfrEmgZhwgqC2JIzkHUP8Hq8coWayOmnnpay9YNcrXSxe2MI8Xmz9RUFfB5rgcR W17SlZrRDBG8uutWme6WLgA2T0AE5/CnOfrdpQHCmzF1KcBE6W9FZsbtdVLHdsRnhGmc +E1A==
X-Gm-Message-State: AOAM532qc9RDtho/nSEJ2NjyFLE9hKkp15LbIKHVoO4NSmXtAlW0d6k3 92WH/6HYsaF22KxPkqgBcVi3hc2F/ZnLLH24t6fMOD9A
X-Google-Smtp-Source: ABdhPJxm1PsWubl+Apy5gUussP/dOTWEYmhPS/L+K5RLFfiI7Kvpe3eIlKkfTlU1YkZMb9PZhU+cxse9YymojB5Q0kk=
X-Received: by 2002:a05:6a00:810:b0:4fa:e869:f4b5 with SMTP id m16-20020a056a00081000b004fae869f4b5mr11275201pfk.54.1648243913642; Fri, 25 Mar 2022 14:31:53 -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> <04f101d8408e$5a536c60$0efa4520$@olddog.co.uk>
In-Reply-To: <04f101d8408e$5a536c60$0efa4520$@olddog.co.uk>
From: Gyan Mishra <hayabusagsm@gmail.com>
Date: Fri, 25 Mar 2022 17:31:42 -0400
Message-ID: <CABNhwV3eC_Jwme9E46xYb4dDFuNRkKrmS0S_5RoPruPmoe3g-g@mail.gmail.com>
To: adrian@olddog.co.uk
Cc: "Joel M. Halpern" <jmh@joelhalpern.com>, TEAS WG <teas@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000f9d88b05db11b0a3"
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas/OCloXDPETsvkSZp_LuelKRx2be8>
Subject: Re: [Teas] 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 21:32:01 -0000
H Adrian, The example Joel gave is the perfect one which made me think maybe help make the verbiage clearer maybe using the word like Network parameter, feature or option. A Service Level Expectation (SLE) is an expression of an unmeasurable service-related request that may consist of various network parameters, features or options that a customer of an IETF Network Slice makes of the provider. How does that sound? Gyan On Fri, Mar 25, 2022 at 5:21 PM Adrian Farrel <adrian@olddog.co.uk> wrote: > I'd be happy to clarify the verbiage, but re-reading, I can't reach the > conclusion that Gyan does. That makes it hard to find other words that > convey the meaning more clearly. > > Obviously, the quoted text (from 4.1) is far briefer than the description > in 4.1.2 and reading that might help understanding the concepts. > > Cheers, > Adrian > > -----Original Message----- > From: Joel M. Halpern <jmh@joelhalpern.com> > Sent: 25 March 2022 19:52 > To: Gyan Mishra <hayabusagsm@gmail.com> > Cc: TEAS WG <teas@ietf.org>; adrian@olddog.co.uk > Subject: Re: [Teas] What SLOs and SLEs should be in the Slicing Service > Model? > > 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://datatracker.ietf.org/doc/html/draft-ietf-teas-ietf-network-slices-09#section-4.1>. > > > 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://www.ietf.org/mailman/listinfo/teas > > <https://www.ietf.org/mailman/listinfo/teas> > > > >>>>> > > > >>>>> > > __________________________________________________________________ > > > >>>>> __ __ ___________________________________________________ > > > >>>>> > > > >>>>> 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://www.ietf.org/mailman/listinfo/teas > > <https://www.ietf.org/mailman/listinfo/teas> > > > >>> > > > >>> > > ____________________________________________________________________ > > > >>> __ ___________________________________________________ > > > >>> > > > >>> 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://www.ietf.org/mailman/listinfo/teas > > <https://www.ietf.org/mailman/listinfo/teas> > > > > -- > > > > <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 > > > > / > > > > > > -- <http://www.verizon.com/> *Gyan Mishra* *Network Solutions A**rchitect * *Email gyan.s.mishra@verizon.com <gyan.s.mishra@verizon.com>* *M 301 502-1347*
- [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