Re: [Teas] Moving forward with draft-ietf-teas-ietf-network-slices

Igor Bryskin <i_bryskin@yahoo.com> Fri, 07 May 2021 16:35 UTC

Return-Path: <i_bryskin@yahoo.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 AB52C3A2918 for <teas@ietfa.amsl.com>; Fri, 7 May 2021 09:35:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 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_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yahoo.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 51pH2V9D8iNJ for <teas@ietfa.amsl.com>; Fri, 7 May 2021 09:35:10 -0700 (PDT)
Received: from sonic313-56.consmr.mail.ne1.yahoo.com (sonic313-56.consmr.mail.ne1.yahoo.com [66.163.185.31]) (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 361AA3A2937 for <teas@ietf.org>; Fri, 7 May 2021 09:35:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1620405309; bh=ZDxldsuMnp13Y013YCM/d+P/VYCFS7cPG7/53ajGzF8=; h=Date:From:To:Cc:In-Reply-To:References:Subject:From:Subject:Reply-To; b=nk6GoNYHzpyzw2gFbc/20Ap8/Ap89VKuDweI0r1jIjWG8a3H33OtQpSnBl3UWbsQpWXyA6IORbi13pxz6VFgL9zdqbAc4ZVDIfZw0V9bvyY0+BSXycTaKZUXazczZz+Kspwy9JHWmuCNK4qY41zmFmqR3g6HTXkB88IlPaILz9Dx4SSHb7E09MDcFv9Jdm4IudAB2oSWRJ3qYgDAHP7ZS5jK22eqAQp+66oEcVbXUbgrgjVEZBFGFbxq+Qd0TBv+ft7sBwnR1vfxVDZ9+PysHC/yQmRpAIP7aZfM+fcC3EGFua9mkGeZ+5R+xIrQJBxkCCiOWtXfjZZdVGMMJ/p67A==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1620405309; bh=c4G92VEd0hw0EnOz7zw9n0NWCB4zhJcr/2/nRCoUChR=; h=X-Sonic-MF:Date:From:To:Subject:From:Subject; b=RPVopmrqF79Q6tUSawdERoiXehEwZzkaiY1D8+10ybSuSA0660ly0SenXyRNt9xoWcQYplt7e0TTCuy8Yy/B6Aw51/iUIA1dFxj/OvGanP/EeSy0YDwHo5R0DeAjAdbb1mD8KNES8Iscg/GgBFZLdMJ4TizFRZQ9iOKYwpkwknLzg5xKCxZzsEIfu6+Rdat6SaUgjbhFDnVXxRwSlnbr12lbABywliyCSVfQBm1f2Yjc/vbMEU9LpQN1Wd+aTED0WrYlPZiaQY51qN0FfFyYVDJdgGZ7M2Vx+TQ6XTMxbQZr67CSm4jm5FmKdcVtKWS5gdpG1MK3puK/XrnIk/auBw==
X-YMail-OSG: i4KCiO0VM1nuH7VpwsYGgZ5mLtD0xXVFShOZzbaoHebY8DqG2G5bDGLnuw6w4hn Y7ivFuGRFESgbEBmLL.UHpDGVY.53LTrWHb854JkSi1olu9Cisnh4SbaqDZwrX8.7ltE9PfI4x4k dABW_9RYuq6tbVICyfT6CTX03.7WU.oifgSUnEPNM308v9kMFTf7VHqRxtCXEf5xMMQoyC3i1SQJ r58PJQ1.nODCVqUOojnMASggJ6nYYJRVjJmFBPoWhNIhVT7h6u3j6HPJ6rBUu8y09GFeNVgLEnOJ 3tQL..3EakRyyb67asUxFBU3OcMfVjnoLIYNGp1M2CF23gk8kgMY3XuaSOfiGRtZBaD4ZMKRbJWy hOBwXrjWX9VQpgUdsTWpNjLuBy10nGRKFXYydGiWXoDCmDjIZsQs2lJDGQ.oz6c5BSo2qO7kLJ9G iN3fMFD3KrefSD2N2wuDSwJjJJJjZ8X5FIOmS4vn5Z0msurxI1P_LIkxQZWc64kH6byGfIKmB2lc GhcjR8gUlNXwGbgPEViRBJSjpVKUSK1PILMC.UqeP8a6QPfJ4GNokd1MUNr52tMOqNJ2wMhL1l3N Oz.5Qg.UCVDmlj7g0zOcsPl1fjDKKYQU6ZbfMfKHsqM4jPl48tzuKaZ6d8TqC0fidwi8Grv05QE5 1nTkcwr9LevcvEOZJt2c27xRFuCmzJV9ov1A2vA2bHmcuvefiyRPXAlG6W_9dQEqZbzm4EiNb64s HAmxYCGLooe7sLuaq2LJHGVervlToYGHEtXsXVHplqlFHPr6zn4H6UjOWUaGU2l8y8r51VsNzQc. 9EGj03Iu6_V4MCySFk7F98moO6qO_MVVYAFVwre7l2Jvm6_iddxx.a7TE_piGMMX9DQOBSIwLJPo XAt3UCmaVK5VEPdOly2xqCGqKrFkWtCZoixOmMHVi7duqWijkjw7xhOvym0.cEJ4nRT0moObJJyg xFGDpNVLWCwMKm5c5b6VaG4vhib.pFyKP8V2kXqaBmRsNLU50t8pwPFBbLAjoPRdvVNck3mH6x.O eA_wIuxYeW6DX7hmpiBTvlsyEj0EX1kuLyRJKRilFAnXS_g_N1jvVOlyIvQF_ZH3HpY7Yf3YxxEC iSaKn_FH1.unXRupIbFfEdrbPzSzUzjTo0j2JveaRnc2NOF4SK5wI6lYkCodAGgVTx8j7acaxSJO zP.3yg2NEcfWSASoZ4xN9rSKqVVHNWw07gZJ__m1uCulMwvS6VQ_haAz3s_YFtC_O0eidOhRjjUw 9NGT2Kfj5Z9DH8gtHecU3ZkoMcJa.ydoz0hV6C7TowIKzyR9MbxzHpyKjqWKV6DjojUzBEDFxiOr eVxw3Lask57V5T4Ep84AY3UtxbiEM7fMO9k.LXoc8aYVhD_ONrgjqIJrPYYHC3tumoNhCnMU13uU VGc4epKBlV.8vUgdvSwN9gohJ22tKwKh19tip5ReOQIq.eyraFSttkMm86gCorlu2WOyeNU5M6rn vM6l3SlJRZqzS0nf6gBWPIGgGNmZx.w.Tn3_npe7TRLpD2.f.xYJBWUcq8LMxDAazIQ1RlNSet.F 1Y3kUqO0JcVZdjdJFs676abrgKLU.y.Xu1QQhWpTOJFtOwwZtVbd6b0JlTJPzxndEeNAv6EM1JEB 12iXYTaXSQ.rJZOIQrk6hJxX97h30legTWXBXpMk_hVH0ud_xN2pMWQ_8arCzBxK9YCrIaqr0E9R 1WCYbt9WCvIjb0lOeYQxz8gmcuKU.RYnou9jCeF6CYdMq8WTkXlfOBUKnBalvFDepLJG6OZGq39C AcOnRb657m6wpsaqM5b3jK9SarFSFm6U9Vzr_7zDh38VkpjHdILgddDtu2zWYWAfy7tOZ4WAR4Ul N6sxP1OKy.z3PEOjxNh45W_A.eSpQmEhH_Y5fLoeR_IB4U5d9zfPNEqqGoi.roO2OBbfNmu7ZNEJ leSW753wjvratbQYulGYwhSujWU7zN58yq14IpQxqPiGnz0nrDHnI4llYFtogeiaXprijLh3IfeX d8Pe6kp6hh9HdyvHpJS7sBg72Rp0YMNj5DlAjnlAg6X5IIkrO0t9VuJp5YXu0WGIRNuWOuynFDEE WX0asIt72PVCvqs2Jna.wbWuipunEmD_DzSwuRKRM8yYk0nRUyrHzAarZ4adDZdbHr3ZG.1HVq8_ HUTptjlDjOz45YWxiYbuy_HeJu5ID1gQCuByQtx18O_fXyekdQDE4vr.KkQCQtQOZVqYbzTttNBa tMuyzhY5h6QRkGFN66H8Yzr1roi_p5fE3AaHiHw5opTRjnz1coqqWMfVAiYCQB_PtNVhZSyRByhx q_BbBQ9IxTgzHSiqW4d6sR69mJDcaiBR3FgpRd6.LYMcambNNM5Os9vJEq3qkMTE_HJc_gtLhSHw fl2GWuALx0aXe6V5rssaBoL2G7nwg8mSqpjAA7DZlCePwCHwxHgx6oKbq8rDRvMxuADGOzGgZ_N0 koDh2UQK3vV6KAVdgb0o_R78TqYefOem43H9qyioP0Hp_LKxSzWekhXUMWeS_.GIaZ9wTZzW9DWj 17x8Tz_NyMFZpGxcx3ooU4ODhJS7AGEMVbQe7JV_IN0z1M1IGVsSkaA_A_iv_jh_jZVU-
X-Sonic-MF: <i_bryskin@yahoo.com>
Received: from sonic.gate.mail.ne1.yahoo.com by sonic313.consmr.mail.ne1.yahoo.com with HTTP; Fri, 7 May 2021 16:35:09 +0000
Date: Fri, 7 May 2021 16:35:07 +0000 (UTC)
From: Igor Bryskin <i_bryskin@yahoo.com>
To: Igor Bryskin <i_bryskin=40yahoo.com@dmarc.ietf.org>, "Joel M. Halpern" <jmh@joelhalpern.com>
Cc: "teas@ietf.org" <teas@ietf.org>
Message-ID: <678103316.1567754.1620405307630@mail.yahoo.com>
In-Reply-To: <cb0a7b04-2ac3-3133-e969-236f1c0b2ecb@joelhalpern.com>
References: <037401d740c5$70a9cc30$51fd6490$@olddog.co.uk> <3ea262cf-e4c0-5ec0-9736-aedaf6d5d4d8@pi.nu> <009401d74195$41fd70a0$c5f851e0$@olddog.co.uk> <9933_1620212302_60927A4E_9933_344_1_787AE7BB302AE849A7480A190F8B933035376DFA@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <00a001d7419e$99e5a040$cdb0e0c0$@olddog.co.uk> <03cf404d-59a7-0ec5-e18f-0a98bf638c0f@pi.nu> <PAXPR06MB7872B2DEF299B15988966A9DFD589@PAXPR06MB7872.eurprd06.prod.outlook.com> <CAKr2Fb9Krrqe7SWB4Zxyp8y8q1S1-jR2=Z3KkoF89cwhOEV4bg@mail.gmail.com> <846651974.1600663.1620396654181@mail.yahoo.com> <cb0a7b04-2ac3-3133-e969-236f1c0b2ecb@joelhalpern.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_Part_1567753_1740677227.1620405307623"
X-Mailer: WebService/1.1.18231 YMailNorrin Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/90.0.4430.93 Safari/537.36 Edg/90.0.818.51
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas/Lidm9JkA-fO5z3wQ1YvZDRDoFDI>
Subject: Re: [Teas] Moving forward with draft-ietf-teas-ietf-network-slices
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, 07 May 2021 16:35:26 -0000

 Thanks Joel,
I was hoping you'd say something like that, because this is what  I was kind of getting at :) In TEAS we are working on SF-aware abstract topology model that IMHO can help.
draft-ietf-teas-sf-aware-topo-model-07 - SF Aware TE Topology YANG Model



Regards,Igor
    On Friday, May 7, 2021, 10:31:08 AM EDT, Joel M. Halpern <jmh@joelhalpern.com> wrote:  
 
 I will let others comment on the best way to express constraints at the 
ietf network slice service level.  I do expect that there is an abstract 
topological representation at that level.

With regard to expressing a delay constraint between service function 
instances, my reaction is a combination of two opposites.  First, I ahve 
trouble, given the nature of service functions, seeing why that would be 
needed.  If there is a dialog (outside of the service function chain 
itseslf) among the instances, then something much more complex is going on.

If we really need to represent it, we can presumably do so in the 
abstract service topology.

Yours,
Joel

On 5/7/2021 10:10 AM, Igor Bryskin wrote:
> Hi Joel,
> 
> As far as I can tell, the client should not be trying to control the
> details of which instance is used to fill the service function
> requirements.
> IB>> But is not possible that in  the chain:
> AccessPoint 1 -> SF1->SF2->...-> AccessPoint2
>   the client cares about SF1->SF2 delay more than  about AccessPoint1 to 
> AccessPoint2 delay ?
> 
>        Constraints like "stay out of a certain country", or
> "stay within a given country" would be expressed in terms of the
> properties the slice is to meet (service level expectations).  Not by
> controlling particular aspects of the service.
> 
> IB>> What if I want to stay away, say, from a particular DC? Would it be 
> easier and more flexible to express such exclusions/inclusions in terms 
> of an abstract topology nodes representing countries, DCs, internal 
> networks, etc.?
> 
> Igor
> 
> 
> On Thursday, May 6, 2021, 11:14:07 PM EDT, Shunsuke Homma 
> <shunsuke.homma.ietf@gmail.com> wrote:
> 
> 
> Hi,
> 
> Firstly, I also follow the WG consensus, and I’m ok to use “customer” if 
> WG prefers it.
> 
> I assume there are mainly two types of use cases on (IETF) network slices:
> 1. Providing slices to externals(customers) as a network service
> 2. Operating some internal network resources with the same slice system 
> with case1
> 
> As far as I read other comments on the terms, most of people seem to 
> focuses on use cases where IETF network slices are provided as a type of 
> network services (i.g., case1), and I’d like to confirm if case2 is also 
> in our scope and “customer” can cover both cases. (I personally want to 
> avoid using different terms depending on assumed use cases).
> 
> 
> Btw, I agree with that slice management would be important, and we’ll 
> need to clarify what “customers” and “providers” can do on slice 
> managements. In my memory, the NS-DT’s study was started with an 
> assumption that resources should be abstracted from several reasons, 
> such as usability, scalability, security, etc. In this assumption, in my 
> understanding, who controls network resources will be always slice 
> provider (i.e., the owner of NSC). In other words, customers never 
> manage resources structuring a slice directly, and a customer will send 
> a service request to a slice provider/NSC when he/she wants to 
> create/change/delete a slice. (I think this is fit to operation models 
> considered in other SDOs such as TMF.)
> 
> 
> What can be done via service request will depend on design of slice 
> service, and the current definition part provides just minimal sets of 
> selectable parameters as SLOs. More details are provided in NBI drafts.
> 
> 
> Regards,
> 
> 
> Shunsuke
> 
> 
> 2021年5月6日(木) 20:53 Oscar González de Dios 
> <oscar.gonzalezdedios@telefonica.com 
> <mailto:oscar.gonzalezdedios@telefonica.com>>:
> 
>    Hi Adrian,
> 
>              I think what is really relevant is to have a clear
>    definition on the chosen term to avoid misunderstandings.
>    Unfortunately today customer/consumer/client are used also in other
>    contexts that might bring extra implications.
> 
>                Said that, I am fine with the term customer. There are
>    still a couple of places in the document where the term "service
>    customer" is used. Please change those to "IETF Network Slice
>    customer" to be coherent.
> 
>              One argument in favor of the term customer is that the
>    "IETF Network slice customer" makes use of the slice to fulfill its
>    needs (can be carry the traffic from a to b with a set of SLOs) and
>    manage the granted slice (that is, it can rearrange the resources it
>    is allowed to).  The term consumer misses the management part, which
>    is a key differentiator of a slice.
> 
>              In the definition of customer, Can we just say: " A
>    customer may manage the granted IETF Network Slice.
> 
>              Also, I'd like to clarify between the management of the
>    IETF Network slice that the customer can do and the management the
>    provider can do. The customer can "play" within the allocated
>    resources, but may have some limitations. One question, the ability
>    to manage the slice, is part of an SLO? Or should be defined
>    separately with a different term? It would be interesting to have
>    the possibility to indicate what the slice customer can manage and
>    what not...
> 
>              I support moving earlier in the document the definition of
>    the IETF Network Slice Customer and, also, add a definition for the
>    IETF Network Slice Provider (although only "provider" is used
>    thought the text).
> 
>              Best Regards,
> 
>                      Oscar
> 
> 
>    -----Mensaje original-----
>    De: Teas <teas-bounces@ietf.org <mailto:teas-bounces@ietf.org>> En
>    nombre de Loa Andersson
>    Enviado el: jueves, 6 de mayo de 2021 9:31
>    Para: adrian@olddog.co.uk <mailto:adrian@olddog.co.uk>;
>    mohamed.boucadair@orange.com <mailto:mohamed.boucadair@orange.com>;
>    teas@ietf.org <mailto:teas@ietf.org>
>    Asunto: Re: [Teas] Moving forward with
>    draft-ietf-teas-ietf-network-slices
> 
>    Adrian,
> 
>    That is acceptable.
> 
>    As you said it is late in the document, and really not in a
>    definitions section. I don't know if we can we place something in
>    Section "2.  Terms and Abbreviations", but there seems to be only
>    abbreviations.
> 
>    Your wholesale example:
> 
>    I think you forget about wholesale. What do you call the school that
>    buys food at the shop to provide to the children? Do you call the
>    school the customer, or do you refer to the cook who buys the food
>    as the customer? The contract is with the school, negotiated by the
>    cook, signed by the bursar.
> 
>    I think "the school! is the customer, which is OK in this context.
>    The cook and the school kids could be viewed as consumers", one
>    removed from the system.
> 
>    It strikes me that "Customer System" and "IETF Slice" are somewhat
>    similar, the risk is that we talk about "customer" (even if we
>    change it), and "slice" (even though if is really "IETF Slice)",
> 
>    Having said that, though it is not my task to call consensus, I
>    think we have a enough support to use "customer".
> 
>    I rest my case.
> 
>    /Loa
> 
> 
>    On 05/05/2021 13:05, Adrian Farrel wrote:
>      > We currently have (in section 5.1, which may be a bit late in the
>      > document)
>      >
>      >     Customer:  A customer is the requester of an IETF Network Slice.
>      >        Customers may request monitoring of SLOs.  A customer may
>    manage
>      >        the IETF Network Slice service directly by interfacing
>    with the
>      >        IETF NSC or indirectly through an orchestrator.
>      >
>      > We could add "A customer may be an entity such as an enterprise
>      > network or a network operator, an individual working at such an
>      > entity, a private individual contracting for a service, or an
>      > application or software component."
>      >
>      > Cheers,
>      > Adrian
>      >
>      > -----Original Message-----
>      > From: mohamed.boucadair@orange.com
>    <mailto:mohamed.boucadair@orange.com> <mohamed.boucadair@orange.com
>    <mailto:mohamed.boucadair@orange.com>>
>      > Sent: 05 May 2021 11:58
>      > To: adrian@olddog.co.uk <mailto:adrian@olddog.co.uk>; 'Loa
>    Andersson' <loa@pi.nu <mailto:loa@pi.nu>>; teas@ietf.org
>    <mailto:teas@ietf.org>
>      > Subject: RE: [Teas] Moving forward with
>      > draft-ietf-teas-ietf-network-slices
>      >
>      > Hi all,
>      >
>      >> Anyone else got anything to say on the topic?
>      >
>      > I would simply use "customer" and make sure the definition is generic
>      > enough to denote a role/entity.
>      >
>      > Thanks.
>      >
>      > Cheers,
>      > Med
>      >
>      >> -----Message d'origine-----
>      >> De : Teas [mailto:teas-bounces@ietf.org
>    <mailto:teas-bounces@ietf.org>] De la part de Adrian Farrel
>      >> Envoyé : mercredi 5 mai 2021 11:59 À : 'Loa Andersson'
>    <loa@pi.nu <mailto:loa@pi.nu>>;
>      >> teas@ietf.org <mailto:teas@ietf.org> Objet : Re: [Teas] Moving
>    forward with
>      >> draft-ietf-teas-ietf-network- slices
>      >>
>      >> Hi Loa,
>      >>
>      >>> On customer vs. consumer Adrian says:
>      >>>
>      >>>>    c. "Consumer" vs "customer". I have made this consistent (we
>      >> only need to
>      >>>>         use one term). I selected "Customer" because that seemed
>      >> best, but I
>      >>>>         know some people prefer "consumer". Please discuss if you
>      >> are not
>      >>>>         happy.
>      >>>
>      >>> If the choice is between customer vs. consumer, I prefer customer.
>      >>
>      >> OK. So I made an improvement, but...
>      >>
>      >>> I don't know if it is too late to bring this up.
>      >>
>      >> It's never too late to bring things up.
>      >>
>      >>> But I really don't like either, normal language has a strong
>      >>> indication that that that a customer is a person (a person that
>      >> walks
>      >>> inte to your
>      >>> shop) and consumer is also a person /that eats what I bought at
>      >> your shop).
>      >>
>      >> I think you forget about wholesale. What do you call the school that
>      >> buys food at the shop to provide to the children? Do you call the
>      >> school the customer, or do you refer to the cook who buys the
>    food as
>      >> the customer? The contract is with the school, negotiated by the
>      >> cook, signed by the bursar.
>      >>
>      >>> IETF specifies "systems", including what goes into SW and HW, but
>      >> we
>      >>> don't specify normative rules for human behavior.
>      >>>
>      >>> I don't know if we can talk about Customer System?
>      >>
>      >> I'm afraid of this getting heavy for the reader. There are 73
>      >> instances of "customer" in the document, and "customer system" may
>      >> become tiresome to read.
>      >>
>      >> Anyone else got anything to say on the topic?
>      >>
>      >> 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>
>      >
> 
>    --
> 
>    Loa Andersson                        email: loa@pi.nu <mailto:loa@pi.nu>
>    Senior MPLS Expert loa.pi.nu@gmail.com <mailto:loa.pi.nu@gmail.com>
>    Bronze Dragon Consulting             phone: +46 739 81 21 64
> 
>    _______________________________________________
>    Teas mailing list
>    Teas@ietf.org <mailto:Teas@ietf.org>
>    https://www.ietf.org/mailman/listinfo/teas
>    <https://www.ietf.org/mailman/listinfo/teas>
> 
>    ________________________________
> 
>    Este mensaje y sus adjuntos se dirigen exclusivamente a su
>    destinatario, puede contener información privilegiada o confidencial
>    y es para uso exclusivo de la persona o entidad de destino. Si no es
>    usted. el destinatario indicado, queda notificado de que la lectura,
>    utilización, divulgación y/o copia sin autorización puede estar
>    prohibida en virtud de la legislación vigente. Si ha recibido este
>    mensaje por error, le rogamos que nos lo comunique inmediatamente
>    por esta misma vía y proceda a su destrucción.
> 
>    The information contained in this transmission is privileged and
>    confidential information intended only for the use of the individual
>    or entity named above. If the reader of this message is not the
>    intended recipient, you are hereby notified that any dissemination,
>    distribution or copying of this communication is strictly
>    prohibited. If you have received this transmission in error, do not
>    read it. Please immediately reply to the sender that you have
>    received this communication in error and then delete it.
> 
>    Esta mensagem e seus anexos se dirigem exclusivamente ao seu
>    destinatário, pode conter informação privilegiada ou confidencial e
>    é para uso exclusivo da pessoa ou entidade de destino. Se não é
>    vossa senhoria o destinatário indicado, fica notificado de que a
>    leitura, utilização, divulgação e/ou cópia sem autorização pode
>    estar proibida em virtude da legislação vigente. Se recebeu esta
>    mensagem por erro, rogamos-lhe que nos o comunique imediatamente por
>    esta mesma via e proceda a sua destruição
>    _______________________________________________
>    Teas mailing list
>    Teas@ietf.org <mailto:Teas@ietf.org>
>    https://www.ietf.org/mailman/listinfo/teas
>    <https://www.ietf.org/mailman/listinfo/teas>
> 
> _______________________________________________
> Teas mailing list
> Teas@ietf.org <mailto:Teas@ietf.org>
> https://www.ietf.org/mailman/listinfo/teas 
> <https://www.ietf.org/mailman/listinfo/teas>
> 
> _______________________________________________
> Teas mailing list
> Teas@ietf.org
> https://www.ietf.org/mailman/listinfo/teas
> 

_______________________________________________
Teas mailing list
Teas@ietf.org
https://www.ietf.org/mailman/listinfo/teas