Re: [Teas] Protection: SLO or SLE? [Re: What SLOs and SLEs should be in the Slicing Service Model?]

[Gyan Mishra <[e-mail]>]

Hi Greg

Very nicely stated on the protection caveats which historically optical
networks optical bypass UPSR BLSR APS switching from working to protect
yields a 50ms has always been the bogie number as well for RSVP-TE FRR that
within that contracted packet loss ratio SLO for TDM optical and Unified
Transport GMPLS optical yielding the same non zero SLO between 0-50ms.

Very good point on the DETNET PREOF function  yields 0 packet loss
guarantee.

Are you aware of any implementations of DETNET PREOF as that would be a
tremendous benefit for operators and Network slicing as well?

Many Thanks

Gyan

On Sat, Mar 26, 2022 at 4:28 PM Greg Mirsky <[e-mail]> wrote:

> Hi Gyan, et al.,
> I want to share my view on one example that is often used in the
> discussion of ETF Network Slice SLO/SLE - the protection. I can agree that
> in a contract between a client and the service provider protection can be
> listed as SLE with its set of parameters that characterize guaranteed
> failure detection time and the efficiency of the service switchover (number
> of services to be switched over within guaranteed time interval after the
> failure detection). At the same time, all that might be left to the service
> provider choice as part of the mechanism to deliver service with below the
> contracted packet loss ratio SLO. The provider then decides which
> protection method to use and how to tune the parameters.
> On a side note. DetNet's PREOF guarantees zero packet loss because the
> Elimination function accepts all copies of a packet. In the traditional 1+1
> protection (circuit or path), the receiver accepts flow only from the
> working circuit/path. In the case of failure, it would take some time for
> the receiver to detect it and switch to the backup source. Thus, even in
> 1+1 protection, there will be a non-zero packet loss resulting from a
> working path failure that is determined by the failure detection time.
>
> Regards,
> Greg
>
> On Sat, Mar 26, 2022 at 12:19 PM Gyan Mishra <[e-mail]>
> wrote:
>
>>
>> Hi John
>>
>> Comments in-line
>>
>> Kind Regards
>>
>> Gyan
>>
>> On Sat, Mar 26, 2022 at 11:35 AM John E Drake <[e-mail]> wrote:
>>
>>> Hi,
>>>
>>>
>>>
>>> Comments inline below.
>>>
>>>
>>>
>>> Yours Irrespectively,
>>>
>>>
>>>
>>> John
>>>
>>>
>>>
>>>
>>>
>>> Juniper Business Use Only
>>>
>>> *From:* Gyan Mishra <[e-mail]>
>>> *Sent:* Friday, March 25, 2022 8:17 PM
>>> *To:* John E Drake <[e-mail]>
>>> *Cc:* Joel M. Halpern <[e-mail]>; [e-mail]; TEAS
>>> WG <[e-mail]>
>>> *Subject:* Re: [Teas] What SLOs and SLEs should be in the Slicing
>>> Service Model?
>>>
>>>
>>>
>>> *[External Email. Be cautious of content]*
>>>
>>>
>>>
>>> John / All
>>>
>>>
>>>
>>> Per this thread where we are discussing what SLO/SLE taxonomy should be
>>> in the service model does bring up some questions related to the network
>>> slice draft.
>>>
>>>
>>>
>>> In the thread as Adrian started off the thread stating that Protection
>>> qualifies as an SLE  but Reliability is definitely an SLO and there may be
>>> a gray area of whether or not it's one or the other.
>>>
>>>
>>>
>>> *[JD]  Protection is actually a technique that a service provider may
>>> use to provide reliability*
>>>
>>>
>>>
>>      Gyan>  I think most of the SLEs are options or parameters that are
>> provisioned and realized by the provider.
>>
>>> I wonder if there could be characteristics that could be both SLO & SLE?
>>>
>>>
>>>
>>> *[JD]  Do you have any in mind?*
>>>
>>>  Gyan> After thinking about it further the definitions of SLE and SLO is
>>> very clear and I think one key point is that SLO is “directly” measurable
>>> as which more a L1 characteristic of the slice where the ones which I might
>>> think maybe in that gray area are not directly measurable for example
>>> protection.  Protection during a failure the result on the 1+1 protected
>>> link is 0 packet loss which is realized by the provider and that
>>> realization is in the SLE description.  So the definition is very clear.
>>>
>> The term measurable  & unmeasurable realization feature really helps
>>> define what characteristics define an SLO or SLE.
>>>
>>>
>>>
>>> *[JD]  Correct.  I think this argues against a characteristic that can
>>> be both an SLO and an SLE *
>>>
>>>  Gyan> I completely agree it’s impossible for characteristic to be both
>>> an SLO and SLE
>>>
>>> Does not have to be an exhaustive list but I think more than just the
>>> common SLO's & SLE's.  I think the gray area ones we should try to spell
>>> out in the draft.
>>>
>>>
>>>
>>> *[JD]  I would love to hear of a characteristic which is both.  If we
>>> find any we can deal with them *
>>>
>>>  Gyan> Agreed.  I think the directly measurable and being a “L1
>>> characteristic” it is crystal clear and that does make it quite clear and
>>> in my mind difficult to find one but as you stated we can deal with them if
>>> it comes up.
>>>
>>> Below are good points that Med brought up and I think are applicable to
>>> section 4 of the draft. Especially that over time the what maybe an SLE
>>> today maybe an SLO tomorrow and vice versa.
>>>
>>>
>>>
>>> *[JD]  That’s fine, but  1) there was never any intention to enumerate
>>> all possible characteristics, which is probably impossible, and tag each as
>>> either an SLO or an SLE and 2)  the set of SLOs and SLEs negotiated between
>>> a customer and its service provider(s) is ultimately a matter between
>>> them;  i.e., it is not a matter in which we are involved*
>>>
>>>  Gyan> Understood and agreed.  The key is defining what an SLO and SLE
>>> is utmost importance over listing an exhaustive list.  With the clear
>>> definition gives the reader of the specification a solid understanding so
>>> no room for misinterpretation.  I believe the we have all done a excellent
>>> job many thanks to the WG!
>>>
>>> Flip side of that is maybe to only spell out the concrete ones that will
>>> never change sides.
>>>
>>>
>>>
>>> *[JD]  See above*
>>>
>>>
>>>
>>> **Mentioned by Med at the beginning of this thread***
>>>
>>>
>>>
>>> * 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.
>>>
>>
>>      Gyan> Agreed on this point
>>
>>>
>>>
>>> * What we may tag as an SLE today because of the technology limitations,
>>> may not stay as such forever.
>>>
>>      Gyan> I think this is doubtful to happen but if it does we can deal
>> with it at that time
>>
>>> 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).
>>>
>>      Gyan> With the definition of SLO being directly measurable and a L1
>> slice characteristic there are only so many today and the common ones which
>> seems to be the current exhaustive are already listed.  I guess it’s
>> possible with a new technology could yield a new type of L1 slice
>> characteristic that is measurable and then that SLE would become an SLO.
>> It’s possible.  I don’t think that impacts the draft in any way and SLOs
>> and SLE can in theory slide back and forth based on our definition and that
>> is not an issue in my mind.
>>
>>>
>>> * We are artificially adding extra complexity for the modelling part as
>>> service requirement will need to be classified based as SLO or SLEs.
>>>
>>>
>>>
>>> *[JD]  I agree with the second statement, above, but since we are simply
>>> trying to introduce the concepts of SLO and SLE, which are clearly
>>> different, and not enumerate all possible characteristics and tag each as
>>> being either an SLO or an SLE, I think it’s largely irrelevant*
>>>
>>>  Gyan> Agreed
>>>
>>> We can branch this off on a separate thread if everyone thinks there is
>>> any merit to follow up on this topic.
>>>
>>>  Gyan> I am all set.  Thanks!
>>>
>>> Kind Regards
>>>
>>>
>>>
>>> Gyan
>>>
>>>
>>>
>>> On Fri, Mar 25, 2022 at 5:55 PM John E Drake <[e-mail]> wrote:
>>>
>>> Did we not make it clear that SLOs and SLEs are used to create an SLA?
>>>
>>> Yours Irrespectively,
>>>
>>> John
>>>
>>>
>>> Juniper Business Use Only
>>>
>>> > -----Original Message-----
>>> > From: Teas <[e-mail]> On Behalf Of Joel M. Halpern
>>> > Sent: Friday, March 25, 2022 3:52 PM
>>> > To: Gyan Mishra <[e-mail]>
>>> > Cc: [e-mail]; TEAS WG <[e-mail]>
>>> > Subject: Re: [Teas] What SLOs and SLEs should be in the Slicing
>>> Service Model?
>>> >
>>> > [External Email. Be cautious of content]
>>> >
>>> >
>>> > 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.com/v3/__https://datatracker.ietf.org/doc/html/draft-
>>> <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft->
>>> > ietf-teas-ietf-network-slices-09*section-4.1__;Iw!!NEt6yMaO-
>>> > gk!VrEVB46KF20816iW_4FlbM4JGWGSLyFu-vk4PGWX_-
>>> > LiOR92MnzCJzyL9ESsViw$ >.
>>> > > 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 <[e-mail]
>>> > > <mailto:[e-mail]>> 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 <[e-mail]
>>> > >     <mailto:[e-mail]>>
>>> > >      > Envoyé : jeudi 24 mars 2022 15:29
>>> > >      > À : BOUCADAIR Mohamed INNOV/NET
>>> > <[e-mail]
>>> > >     <mailto:[e-mail]>>
>>> > >      > Cc : 'TEAS WG' <[e-mail] <mailto:[e-mail]>>;
>>> > >     [e-mail] <mailto:[e-mail]>
>>> > >      > 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, [e-mail]
>>> > >     <mailto:[e-mail]> 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 <[e-mail]
>>> > >     <mailto:[e-mail]>> Envoyé : jeudi 24 mars
>>> > >      > >> 2022 15:07 À : BOUCADAIR Mohamed INNOV/NET
>>> > >      > >> <[e-mail]
>>> > >     <mailto:[e-mail]>> Cc : 'TEAS WG'
>>> > <[e-mail]
>>> > >     <mailto:[e-mail]>>;
>>> > >      > >> [e-mail] <mailto:[e-mail]> 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, [e-mail]
>>> > >     <mailto:[e-mail]> 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 <[e-mail]
>>> > >     <mailto:[e-mail]>> Envoyé : jeudi 24 mars
>>> > >      > >>>> 2022 14:52 À : BOUCADAIR Mohamed INNOV/NET
>>> > >      > >>>> <[e-mail]
>>> > >     <mailto:[e-mail]>>; [e-mail]
>>> > >     <mailto:[e-mail]>; 'TEAS WG'
>>> > >      > >>>> <[e-mail] <mailto:[e-mail]>> 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, [e-mail]
>>> > >     <mailto:[e-mail]> 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 <[e-mail]
>>> > >     <mailto:[e-mail]>> De la part de Adrian Farrel
>>> > >      > >>>>>> Envoyé
>>> > >      > >>>>>> : mercredi 23 mars 2022 14:47 À : 'TEAS WG' <
>>> [e-mail]
>>> > >     <mailto:[e-mail]>> 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
>>> > >      > >>>>>> [e-mail] <mailto:[e-mail]>
>>> > >      > >>>>>>
>>> >
>>> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/teas__;!!N
>>> <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/teas__;!!N>
>>> > Et6yMaO-gk!VrEVB46KF20816iW_4FlbM4JGWGSLyFu-vk4PGWX_-
>>> > LiOR92MnzCJzyLzCREI4M$
>>> > >
>>> > <
>>> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/teas__;
>>> <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/teas__;>
>>> !!
>>> > NEt6yMaO-gk!VrEVB46KF20816iW_4FlbM4JGWGSLyFu-vk4PGWX_-
>>> > LiOR92MnzCJzyLzCREI4M$ >
>>> > >      > >>>>>
>>> > >      > >>>>>
>>> > >
>>> > _________________________________________________________________
>>> > _
>>> > >      > >>>>> __ __
>>> > ___________________________________________________
>>> > >      > >>>>>
>>> > >      > >>>>> 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
>>> > >      > >>>>> [e-mail] <mailto:[e-mail]>
>>> > >      > >>>>>
>>> >
>>> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/teas__;!!N
>>> <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/teas__;!!N>
>>> > Et6yMaO-gk!VrEVB46KF20816iW_4FlbM4JGWGSLyFu-vk4PGWX_-
>>> > LiOR92MnzCJzyLzCREI4M$
>>> > >
>>> > <
>>> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/teas__;
>>> <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/teas__;>
>>> !!
>>> > NEt6yMaO-gk!VrEVB46KF20816iW_4FlbM4JGWGSLyFu-vk4PGWX_-
>>> > LiOR92MnzCJzyLzCREI4M$ >
>>> > >      > >>>
>>> > >      > >>>
>>> > >
>>> > _________________________________________________________________
>>> > ___
>>> > >      > >>> __ ___________________________________________________
>>> > >      > >>>
>>> > >      > >>> 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
>>> > >     [e-mail] <mailto:[e-mail]>
>>> > >
>>> >
>>> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/teas__;!!N
>>> <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/teas__;!!N>
>>> > Et6yMaO-gk!VrEVB46KF20816iW_4FlbM4JGWGSLyFu-vk4PGWX_-
>>> > LiOR92MnzCJzyLzCREI4M$
>>> > >
>>> > > <
>>> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/tea
>>> <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/tea>
>>> > > s__;!!NEt6yMaO-gk!VrEVB46KF20816iW_4FlbM4JGWGSLyFu-vk4PGWX_-
>>> > LiOR92MnzC
>>> > > JzyLzCREI4M$ >
>>> > >
>>> > > --
>>> > >
>>> > > <
>>> https://urldefense.com/v3/__http://www.verizon.com/__;!!NEt6yMaO-gk!V
>>> <https://urldefense.com/v3/__http:/www.verizon.com/__;!!NEt6yMaO-gk!V>
>>> > > rEVB46KF20816iW_4FlbM4JGWGSLyFu-vk4PGWX_-LiOR92MnzCJzyLqOCoT3c$
>>> > >
>>> > >
>>> > > *Gyan Mishra*
>>> > >
>>> > > /Network Solutions A//rchitect /
>>> > >
>>> > > /Email [e-mail] <mailto:[e-mail]
>>> >//
>>> > > /
>>> > >
>>> > > /M 301 502-1347
>>> > >
>>> > > /
>>> > >
>>> > >
>>> >
>>> > _______________________________________________
>>> > Teas mailing list
>>> > [e-mail]
>>> >
>>> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/teas__;!!N
>>> <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/teas__;!!N>
>>> > Et6yMaO-gk!VrEVB46KF20816iW_4FlbM4JGWGSLyFu-vk4PGWX_-
>>> > LiOR92MnzCJzyLzCREI4M$
>>>
>>>
>>>
>>>
>>> --
>>>
>>>
>>> <https://urldefense.com/v3/__http:/www.verizon.com/__;!!NEt6yMaO-gk!RvVLz0GpjIyf2oVvTxnMgHzO5_TsnvXLYRGzpTsQSjwAIOP5-Q9vlZiJlwa0Nuw$>
>>>
>>> *Gyan Mishra*
>>>
>>> *Network Solutions Architect *
>>>
>>> *Email [e-mail] <[e-mail]>*
>>>
>>> *M 301 502-1347*
>>>
>>>
>>>
>> --
>>
>> <http://www.verizon.com/>
>>
>> *Gyan Mishra*
>>
>> *Network Solutions A**rchitect *
>>
>> *Email [e-mail] <[e-mail]>*
>>
>>
>>
>> *M 301 502-1347*
>>
>> _______________________________________________
>> Teas mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/teas
>>
> _______________________________________________
> Teas mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/teas
>
-- 

<http://www.verizon.com/>

*Gyan Mishra*

*Network Solutions A**rchitect *

*Email [e-mail] <[e-mail]>*



*M 301 502-1347*