Re: [Teas] New term for the underlay construct used for slice realization

"Luis M. Contreras" <contreras.ietf@gmail.com> Thu, 12 August 2021 11:30 UTC

Return-Path: <contreras.ietf@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 681293A0B03 for <teas@ietfa.amsl.com>; Thu, 12 Aug 2021 04:30:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, 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 n1ywAM-PV_99 for <teas@ietfa.amsl.com>; Thu, 12 Aug 2021 04:30:28 -0700 (PDT)
Received: from mail-qk1-x72d.google.com (mail-qk1-x72d.google.com [IPv6:2607:f8b0:4864:20::72d]) (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 3AC963A0B01 for <teas@ietf.org>; Thu, 12 Aug 2021 04:30:28 -0700 (PDT)
Received: by mail-qk1-x72d.google.com with SMTP id t66so6154983qkb.0 for <teas@ietf.org>; Thu, 12 Aug 2021 04:30:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Y8zo9NuJNVd160iy4qBf2cCEEAT7P4WekibT9dHCjGk=; b=WN8lzmcmH7XLHMnKHS9JCPfCsEZUYQDX3bdTxAaJxd+j8js3GisiU4IFmfuxE7Apqx G6OrRxDGAWYUaohlemu+89Ay2Si7276P0McO8aQdFty7vAvAsGcg4TgIAnUMOE4/N2RA qNy8S6KoRm4xl292xsalYUfNgM2Yi5cs/msjIR63Uxq7Izblb/GLSxJ45PmGx/7iv4PM +jTp8emctuTrl7aWMYl+x6ldy+60CNAw4bP/4kRIQ1BXbG5Vu5UyZincTf9bQ22G0GoR 91RA5q7Iz3hkgbQfJ8qOgdF0MkTZcDq2gYYWxOWscFfbzPcbaWD/oDRfp4aEBKkBc5oF BCPQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Y8zo9NuJNVd160iy4qBf2cCEEAT7P4WekibT9dHCjGk=; b=dzb1DW8eNOP2vTkjRmELTmKH8tKMxZlin9qRQsPnHxA9/uq/++FuSC1kSCgJRUWQ6Q Y5J2EYph35LAX9XnOe7YfsfZrGhB/hYOEdfJkJG08lQEY2C4omEofiy+iq9qmCuOqxu0 3Hx00qT7LMJb/K0hhv78tomqi2P4xLUxmnXkNJZl0BjX6MpxRXaCGqJKCUUv5kR+07uc Sarmsm60EI4a6ZI+1kaG35xOa/8/1aSzgewvTOdK4vpjoJW+eJaoYg2HPi8u2oWJinuP 8o/JESCkxRBPS9F+Y9z3YFxw259To0opo+/ATM+Si7rNADgggRCH4Kb/aMyboRsPCtMu vm1Q==
X-Gm-Message-State: AOAM531LPr3ebU8WzFweAIYFajWYAUJdf1qFnRlbWxFOG90G6ow/1nOg mK4hx6Ftokkyv2a71BbO4xOOm2RXQfDQ6T/PjDg=
X-Google-Smtp-Source: ABdhPJxqYxtTun+P/XcR5TdD8OPPIofilXdxC226MD3MIG+PpB/M4u/F4WAM/qvjIMsIqp+oLyYdRwq2zWV8s15sFV0=
X-Received: by 2002:ae9:e30c:: with SMTP id v12mr3874406qkf.206.1628767825392; Thu, 12 Aug 2021 04:30:25 -0700 (PDT)
MIME-Version: 1.0
References: <2ae53e44d60548e6ac961ac992615e9b@huawei.com> <BY3PR05MB80819A0E7F8CAFD5BAE79A91C7F79@by3pr05mb8081.namprd05.prod.outlook.com> <33ca73966af4490d84b88c765e183a98@huawei.com> <BY3PR05MB80816B3982271C1FEA86E46CC7F89@by3pr05mb8081.namprd05.prod.outlook.com> <eme7fd3b03-1b2a-47d5-a8f5-b45ecdadeb90@kmak-book2> <00e401d78ee8$5ea55790$1bf006b0$@olddog.co.uk> <em1310ead9-1b78-4908-80a4-1767f5357260@tromso.local> <019f01d78f62$3f4c9730$bde5c590$@olddog.co.uk>
In-Reply-To: <019f01d78f62$3f4c9730$bde5c590$@olddog.co.uk>
From: "Luis M. Contreras" <contreras.ietf@gmail.com>
Date: Thu, 12 Aug 2021 13:30:14 +0200
Message-ID: <CAE4dcxkDBnZC_D+jCFS5PS95P=O8Tq+3UMH9zxyejw8CTLq_pA@mail.gmail.com>
To: adrian@olddog.co.uk
Cc: Kiran M <kiran.ietf@gmail.com>, TEAS WG <teas@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000a7772c05c95b0f27"
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas/tLNs0bm_fqOBL1-pK6C5jwL-r_U>
Subject: Re: [Teas] New term for the underlay construct used for slice realization
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: Thu, 12 Aug 2021 11:30:36 -0000

Hi all,

as pointed out by Adrian, draft-contreras-teas-slice-controller-models
already contain some details in line with this 4 layering proposal. In
figure 2 of the draft it is proposed the following functional architecture.

                                    Higher Level System
                                             |
                                             |
                                ---------------------------
                                | NSC        | (a)        |
                                |            v            |
                                |   -------------------   |
                                |   |                 |   |
                                |   |    NS Mapper    |   |
                                |   |                 |   |
                                |   -------------------   |
                                |            | (b)        |
                                |            v            |
                                |   -------------------   |
                                |   |                 |   |
                                |   |    NS Realizer  |   |
                                |   |                 |   |
                                |   -------------------   |
                                |            | (c)        |
                                ---------------------------
                                             |
                                             v
                                    Network Controllers


In my view, this is the relation with the 4 layering:

IETF network slice service (customer view) --> (a) in the figure, as NBI of
the IETF NSC and input to the NS Mapper

IETF network slice (operator view) --> (b) in the figure, as input to the
NS Realizer

Resource partition (delivery mechanism) --> (c) in the figure, as NBI to
the different Network Controllers involved in the realization of an IETF
Network Slice

Underlay network (network used to support the slice) --> not represented in
the figure, being the networks under control of the Network Controllers
mentioned before


I think this is a consistent view.


Best regards


Luis

El jue, 12 ago 2021 a las 12:10, Adrian Farrel (<adrian@olddog.co.uk>)
escribió:

> Hi Kiran,
>
> You make an important observation about functional architectures. I recall
> having a similar discussion back in around 2004 in Geneva as we worked on
> G.7712 and associated Recommendations.
>
> The points are:
> - Functional components do not need to be implemented as separate
>    software components.
> - Where functional components are bundled together in software, they
>    do not need to implement the formal functional interfaces between
>    the functional components.
> - Where a function is "not needed" in an implementation or deployment
>    it may be present as a "null" or "pass-through" function, but it
> actually
>    doesn't need to be present at all.
>
> Thus, while it is possible to treat a functional architecture as a high
> level design for a software implementation, it may not necessarily be the
> best approach.
>
> Now, to your specific points...
>
> > In this 4-tier architecture (for the sake of convenience), few things
> > could be documented after clarification:
> >
> > 1) is it mandatory that operator must have an 'IETF Network slice
> > instance' to realize an IETF network slice service?
>
> As above, no it is not mandatory. Just as in L3VPN, an operator could map
> direct from a VPN service request at the NBI (using L3SM) to programming of
> the forwarding plane.
>
> > - One of the things we discussed early on was that it should be
> >   possible to map a customer’s network slice request even when the
> >   operator does not have slice-infrastructure. This is why Southbound
> >   interface had lot of discussions on using existing data models. Should
> >   we now redefine what a SBI would be? Is it between 2nd and 3rd tier?
> >   Should architecture allow 1st to 3rd? Since resource-partitioning is
> an
> >   important part of slices should we name the interface between 3rd to
> >   4th tier?
>
> Well, let's be really careful about the term "SBI". Southbound to what?
> An Orchestrator may have an SBI to a Network Slice Controller.
> A Network Slice Controller may an SBI to a Network Controller.
> And a Network Controller may have an SBI to the devices.
> draft-contreras-teas-slice-controller-models may give some good context
> for this.
>
> I'm setting aside "even when the operator does not have
> slice-infrastructure" since I don't know what it means. But I will say that
> it entirely possible for an operator to map direct from an IETF Network
> Slice Service request to "programming" the data plane. I believe that is
> possible with this 4-layer functional model. Furthermore, I believe the
> functional model allows any or all forms of "pass-through". That is, to
> repeat myself, it is a functional model not a mandatory implementation
> guide (notwithstanding RFC 8962, there is no Protocol Police!).
>
> > 2) in order to scale the slices, hierarchical slices were defined. The
> >   stitching could be done horizontally or vertically over the
> >   resource-partitions. are they still needed in this architecture.
>
> Architectures are recursive. That recursion may be transparent or visible.
> Hierarchical slicing "comes for free".
>
> Lateral stitching of slices is, of course, more complicated because it
> requires coordination between adjacent "domains". But the architecture
> should easily allow this.
>
> > In my mind, what you call a resource partition is nothing but an
> > abstraction of connected network resources (vaguely resembles the
> > definition of slice, isn’t it?). What happens above that is an
> > orchestration on different slice segments to produce the desired
> > effects.
>
> "Orchestration" is a key word.
>
> I think "vaguely resembles the definition of a slice" is not completely a
> surprise because what is going on is a marshalling of resources to support
> a slice.
>
> Is it an abstraction? No! It is actually the identification of specific
> resources. I think the network slice, itself, (the 2nd layer down) is the
> abstraction.
>
> > So I think, with this architecture we would need to clean up/edit the
> > text on 3 items in the document - SBI, optionality of 2nd tier (if you
> > agree - related to your 4c/d/e), section on hierarchical structure.
>
> I agree that cleaning of text is what this is all about. A lot of the text
> is still in its inherited form and needs work.
> Currently the document mainly uses "SBI" to mean the device-facing
> interface. But it also talks about the "NSC SBI", I find the term SBI
> over-used, and I think we can tidy that up.
> Yes, it should be clear about the fact that this is a functional
> architecture and that you don't have to implement it like that.
> Yes we should have some text (although probably not a lot) on the fact
> that you can recurse the architecture and that you can orchestrate and
> stitch across adjacent domains/networks.
>
> Cheers,
> Adrian
>
>
> On 8/11/2021 12:37:49 PM, "Adrian Farrel" <adrian@olddog.co.uk> wrote:
>
> >I wonder whether we can pick this apart and put it back together in a way
> >that makes sense.
> >
> >The customer's view of all this is an "IETF network slice service". I
> think
> >(hope) we are all agreed on this. The customer may ask (in shorthand) for
> a
> >"network slice", but:
> >- they are talking about IETF technology, so they asking for an "IETF
> >network slice"
> >- they actually want behavioural characteristics and have no right to tell
> >the operator
> >   how to manage the network, so they are asking for an "IETF network
> slice
> >service."
> >
> >The operator has a bigger set of things to worry about.
> >
> >1. At the top of the operator's view is the "IETF network slice service"
> as
> >     requested by the customer. We have this defined already, so nothing
> more
> >     to say.
> >
> >2. The operator maps the request for a slice service into the "IETF
> network
> >     slice" which is the expression of the service in terms of network
> >connectivity
> >     in the context of the operator's network. The relationship here is
> like
> >the
> >     relationship between the L3SM and L3NM.
> >
> >3. At the bottom of their view is an underlying network. The technology of
> >this
> >    network depends, of course, on the operator's offering, but this is
> the
> >network
> >    technology being sliced. It may be an IP network, and MPLS network, an
> >OTN,
> >    or whatever. I would call this the "Underlay Network." This network
> may,
> >in
> >    turn, be built upon an underlay network of the same or a different
> >technology,
> >    and it may be facilitated through network slicing - but this need not
> >concern
> >    us here.
> >
> >4. That leaves the glue in the middle: the bit that enables the scaling
> and
> >maps
> >    the network slice to the network. And I think it is this bit that is
> >causing the
> >    most debate about terminology. There are some points to consider:
> >
> >    a. The term "network resources" applies to the bandwidth, queues,
> >buffers,
> >        etc. available on the links and nodes in the network. That may be
> >        extended to refer to whole links and nodes.
> >
> >    b. The number of IETF network slice services is potentially large and
> the
> >        operator needs a mechanism to scale the mapping of services to
> >        network resources.
> >
> >    c. The IETF network slices may be grouped for identical treatment to
> >        achieve scaling, where the grouping collects IETF network slices
> with
> >        similar SLAs.
> >
> >    d. It may be that different traffic flows within a single IETF network
> >slice
> >         have different characteristics. In this case, it may be
> beneficial
> >to group
> >         together some of the traffic flows from different slices.
> >
> >    e. The grouped slices/flows are enabled in the network using network
> >         resources assigned for that purpose. The assignment may be
> anything
> >         from a fully-fledged virtual network (such as in ACTN or VPN+),
> >through
> >         network reserved resources (such as in MPLS-TE), and centrally
> >         accounted resources (such as SDN or possible SR), to
> statistically
> >         shared resources.
> >
> >There seems to be various points for and against 4d. But, it would appear
> >that this is an implementation or deployment issue that doesn't change
> what
> >the protocols need to do. So we should probably allow it architecturally,
> or
> >at least, not disallow it.
> >
> >Of course, as Kiran points out, 4c/d/e may be a pass-through. That is, it
> is
> >not necessary to implement such groupings either because there are only a
> >few slices (which has been the view of some operators) or because the
> >network systems can handle the number of slices. And it is in the nature
> of
> >architectures of this sort that all functions can be nulled out without
> loss
> >of generality, and we have to recall that the internals of provisioning
> >systems may appear as functional blocks in our architectures, but we don't
> >compel implementations to adhere to that type of architecture. So I don't
> >think we have to worry on that account.
> >
> >And that brings the question of how we name the resources that are
> gathered
> >in 4e.
> >
> >I can't decide whether it is helpful to spend time saying why I don't like
> >each of the proposed terms. I certainly have things I don't like about
> (for
> >example) "slice aggregate" (because of 4d, which means it is really a
> "slice
> >sub-flow aggregate"), and I am not a fan of "VTN" (because of "transport"
> >and maybe it is not really a network). But maybe it is better for me to
> say
> >what I think we should call things? I think we have...
> >
> >-      IETF network slice service (customer view)
> >-      IETF network slice (operator view)
> >-      Resource partition (delivery mechanism)
> >-      Underlay network (network used to support the slice)
> >
> >Why "resource partition"? Well it is a collection of "nodes, links, and
> >network resources that are marked within the network for use by a set of
> >network slice traffic flows".
> >It is possible that the word "partition" is too strong because it may
> imply
> >to some people that resources in a partition cannot be shared, but I don't
> >feel that.
> >Softer words than "partition" would be "group", "bundle", "pool", and I
> >could live with any of them.
> >
> >Best,
> >Adrian
> >
> >
> >-----Original Message-----
> >From: Teas <teas-bounces@ietf.org> On Behalf Of Kiran Makhijani
> >Sent: 11 August 2021 16:00
> >To: John E Drake <jdrake=40juniper.net@dmarc.ietf.org>rg>; Dongjie (Jimmy)
> ><jie.dong@huawei.com>i.com>; Lizhenbin <lizhenbin@huawei.com>om>; teas@ietf.org
> >Subject: Re: [Teas] New term for the underlay construct used for slice
> >realization
> >
> >Hi John, (and all),
> >
> >Two very basic clarification questions:
> >1. How do we differentiate between  the slice-segments that are
> >resource-aware vs those that are not? I had assumed that since a slice
> >has an SLO, it will need network resource allocations in some form.
> >
> >2. Is it ok to assume that the customer view of slice is an 'IETF
> >network slice service' and the 'IETF slice realization' of that service
> >in a provider network is raises the question of underlay and overlay
> >constructs. Am I right?
> >(a) if so, then we are acknowledging  the presence of another layer of
> >abstraction (for realization). It could be underlay/overlay or
> >aggregate/??. Then the term 'slice aggregate' is better and my
> >preference, it is easier to see that different slice-services are
> >aggregated into a single construct  in a provider network. Use of
> >underlay/overlay are confusing.
> >(b) for a leaner provisioning, I would also prefer to see it documented
> >that the aggregate is optional and it should be possible to directly map
> >a slice-service to physical or real resources in the network.
> >specifically useful when a single domain is carving out slices for
> >different purposes.
> >
> >Thanks
> >Kiran
> >
> >
> >------ Original Message ------
> >From: "John E Drake" <jdrake=40juniper.net@dmarc.ietf.org>
> >To: "Dongjie (Jimmy)" <jie.dong@huawei.com>om>; "Lizhenbin"
> ><lizhenbin@huawei.com>i.com>; "teas@ietf.org" <teas@ietf.org>
> >Sent: 8/11/2021 5:38:05 AM
> >Subject: Re: [Teas] New term for the underlay construct used for slice
> >realization
> >
> >>Jimmy,
> >>
> >>Snipped, comments inline.
> >>
> >>Yours Irrespectively,
> >>
> >>John
> >>
> >>
> >>Juniper Business Use Only
> >>
> >>>   -----Original Message-----
> >>>   From: Dongjie (Jimmy) <jie.dong@huawei.com>
> >>>   Sent: Tuesday, August 10, 2021 11:03 PM
> >>>   To: John E Drake <jdrake@juniper.net>et>; Lizhenbin <
> lizhenbin@huawei.com>gt;;
> >>>teas@ietf.org
> >>>   Subject: RE: New term for the underlay construct used for slice
> >realization
> >>>
> >>>   [External Email. Be cautious of content]
> >>>
> >>underlay construct for network slice realization bound to
> >>>   > > network slice services? That is, is the underlay construct only
> for
> >>>   > > use in network slicing, or should it be generalized for more
> >possible uses?
> >>>   >
> >>>   > [JD] Absolutely yes
> >>>
> >>>   [Jie] I guess you mean "Yes" to the latter case, which is "it should
> be
> >generalized
> >>>   for more possible uses", is my understanding correct?
> >>
> >>[JD]  Yes to the latter
> >>
> >>>
> >>>   >
> >>>   > >
> >>>   > > 2.      If the answer to question 1 is YES, should it reflect the
> >following
> >>>   > > characteristics?
> >>>   > >
> >>>   > > a.      It is about the underlay
> >>>   > > b.      It is about the partitioned resources used to deliver the
> >network slice
> >>>   > > services
> >>>   > > c.      It allows the 1:1, N:1, and 1:N mapping models between
> the
> >network
> >>>   > slice
> >>>   > > services and the underlay construct. The 1:1 and N:1 mapping may
> be
> >>>   > > straightforward. Does it also make sense to divide the elements
> or
> >>>   > > traffic flows in a single network slice service to carry them in
> >>>   > > different
> >>>   > underlay constructs?
> >>>   >
> >>>   > [JD]  Yes to all of the above.  Please see:
> >>>   >
> https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draf
> >>>   > t-drake-bess-enhanced-vpn-06__;!!NEt6yMaO-
> >>>   gk!TCiJHCZCwFgwpuFoujxVlZ4r9
> >>>   > F6mLpE4nJ-9zpqkY-kls-ROxL4C2_xNaR2ImI4$
> >>>   > >
> >>>   > > Lastly, here are some candidates of the "new term":
> >>>   > >
> >>>   > > Option 1: The network slice service is called "overlay slice",
> then
> >>>   > > the underlay construct is called "underlay slice".
> >>>   > >
> >>>   > > Option 2: The network slice service is called "service slice",
> then
> >>>   > > the underlay construct is called "resource slice".
> >>>   >
> >>>   > [JD]  I don't think we need another term for what we are already
> >>>   > calling an 'IETF Network Slice Service'.  Adrian and I are
> considering
> >>>   > the term 'resource partition' to describe the partitioning of
> underlay
> >>>   > network resources in support of various overlay services such as
> IETF
> >Network
> >>>   Slice Services.
> >>>   > This is congruent with the ideas expressed in:
> >>>   >
> https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draf
> >>>   > t-ietf-spring-resource-aware-segmen__;!!NEt6yMaO-
> >>>   gk!TCiJHCZCwFgwpuFouj
> >>>   > xVlZ4r9F6mLpE4nJ-9zpqkY-kls-ROxL4C2_xNxEfwaXg$
> >>>   > ts-03.  What this allows one to build is an 'partitioned underlay
> >>>   > network topology'.
> >>>
> >>>   [Jie] Agree that here we are talking about the term for the underlay
> >construct.
> >>>   "Resource partition" captures one of its key characteristics, while
> IMO
> >another
> >>>   thing the term needs to reflect is that the resource partition is
> needed
> >on a
> >>>   subset of the links and nodes (rather than on a single node or link)
> in
> >the physical
> >>>   network, which together builds a logical network topology.
> >>
> >>[JD]  In my initial email, above, I was proposing 'partitioned underlay
> >network topology'
> >>
> >>>
> >>>   Best regards,
> >>>   Jie
> >>>
> >>>   >
> >>>   > >
> >>>   > > Your opinion about these candidates are much appreciated. You may
> >>>   > > also propose other new term if it complies with the above two
> >points.
> >>>   >
> >>>   > [JD]  I think you have exceeded your remit.
> >>>   >
> >>>   > >
> >>>   > >
> >>>   > >
> >>>   > > Best Regards,
> >>>   > > Robin
> >>>   > >
> >>>   > > _______________________________________________
> >>>   > > Teas mailing list
> >>>   > > Teas@ietf.org
> >>>   > >
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/te
> >>>   > > as
> >>>   > > __;!!N
> >>>   > > Et6yMaO-gk!Q0ycOf0ELxT6mG1GbnO4LSL-Q99J4uu7jfdUtBECaI-
> >>>   > > O08HqD31TGJciNjuxL2A$
> >>>   >
> >>>   > _______________________________________________
> >>>   > Teas mailing list
> >>>   > Teas@ietf.org
> >>>   >
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/teas
> >>>   > __;!!NEt6yMaO-gk!TCiJHCZCwFgwpuFoujxVlZ4r9F6mLpE4nJ-9zpqkY-kls-
> >>>   ROxL4C2
> >>>   > _xNDCrPaNQ$
> >>
> >>_______________________________________________
> >>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
> >
>
> _______________________________________________
> Teas mailing list
> Teas@ietf.org
> https://www.ietf.org/mailman/listinfo/teas
>


-- 
___________________________________________
Luis M. Contreras
contreras.ietf@gmail.com
luismiguel.contrerasmurillo@telefonica.com
Global CTIO unit / Telefonica