Subject: Re: [Teas-ns-dt] Figure in the ACTN Applicability section

From: Zhenghaomian <[email-masked]>
Date: Wed, 13 May 2020 02:13:14 +0000

Hi, Luis, Eric, All,

Thanks for the effort on making the mapping more complete. Actually I think both the updated proposal from {Eric, Dhruv, John} and the one from Luis are applicable in some cases, and how to deploy is fully dependent on the choice of implementation. Compared with the previous version in section 4 of draft-nsdt-teas-ns-framework-03, the main improvement is ‘TS-NBI is using technology-agnostic models’, as said by Eric.

According to our experience in ACTN deployment, there are flexibilities on how many hierarchies of MDSC is needed, depending on the functionality of each hierarchy and the scalability of the network. I believe none of us are trying to exclude any implementation, neither the proposal from Eric nor Luis. So a more generic proposal is shown as follow, thoughts?

Service Model in                                              ACTN
 Transport Slice        Transport Slice Framework           Terminology
Framework [RFC8309]                                         and Concepts
-------------          -------------------------           ------------
                 +------------------------------------+
                 |             Customer               |  |
                 +------------------------------------+
   Customer                        A                     |
   Service                         |
   Model                           V                     |
                 +------------------------------------+
                 |      A highter level system        |  |   +-----+
                 |(e.g e2e network slice orchestrator)| ===> | CNC |
                 +------------------------------------+  |   +-----+
   Service                         A                            A
   Delivery                        | TSC NBI             |      | CMI
   Model                           V                            V (LxSM)
                 +------------------------------------+  |   +-------+
                 |      Transport Slice Controller    | ===> | MDSC-H|
                 +------------------------------------+  |   +-------+
   Network                         A                            A
   Configuration                   | TSC SBI             |      |
   Model                           V                            V
                 +-----------------------------------+   |   +-------+
                 |                                   |  ===> |MDSC-L |
                 |                                   |   |   +-------+
                 |                                   |           A
                 |        Network Controller(s)      |   |       | MPI
                 |                                   |           V
                 |                                   |   |   +-----+
                 |                                   |  ===> | PNC |
                 +-----------------------------------+   |   +-----+

My 2 cents,
Haomian

发件人: Teas-ns-dt [mailto:[email-masked]] 代表 Luis M. Contreras
发送时间: 2020年5月13日 0:03
收件人: Eric Gray <eric.gray=[email-masked]>
抄送: [email-masked]
主题: Re: [Teas-ns-dt] Figure in the ACTN Applicability section

(My apologies for the mail before, with the Confidential Notes by default. Please, ignore it. Repeating mail here).

Hi Eric, all,

Thanks for addressing this point.

I have some few comments and suggestions.

1/ Regarding the figure, I think that as it is now mix things a bit. In my personal subjective view I think it provides a view of how to fit TSC into ACTN rather in the other way around. My suggestion would be to depict the comparison as in the figure below (ignore the service model naming by now for this point). I think it becomes more clear, but again this is subjective, of course.

2/ Regarding the service model naming. I have revisited RFC8309 and I think that the proper mapping to service models in the case of TSC would be the one proposed in the figure below on the left-hand side (please, check Figure 3 in RFC8309).

Here is the figure I propose.

Service Model in                                              ACTN
 Transport Slice        Transport Slice Framework           Terminology
Framework [RFC8309]                                         and Concepts
-------------          -------------------------           ------------
                 +------------------------------------+
                 |             Customer               |  |
                 +------------------------------------+
   Customer                        A                     |
   Service                         |
   Model                           V                     |
                 +------------------------------------+
                 |      A highter level system        |  |   +-----+
                 |(e.g e2e network slice orchestrator)| ===> | CNC |
                 +------------------------------------+  |   +-----+
   Service                         A                            A
   Delivery                        | TSC NBI             |      | CMI
   Model                           V                            V (LxSM)
                 +------------------------------------+  |   +-------+
                 |      Transport Slice Controller    | ===> | MDSC-H|
                 +------------------------------------+  |   +-------+
                                   A                            A
                                   |                     |      |
                                   |                            V
   Network                         |                     |   +-------+
   Configuration                   | TSC SBI                 |MDSC-L |
   Model                           |                     |   +-------+
                                  |                            A
                                   |                     |      | MPI
                                   V                            V (LxNM)
                 +------------------------------------+  |   +-----+
                 |        Network Controller(s)       | ===> | PNC |
                 +------------------------------------+  |   +-----+

The text you propose depends totally on the final figure and the consideration of the service models that apply, so I would prefer to discuss first about the figure and once it is closed to discuss the text, to ensure consistency.

Thanks

Luis

El mar., 12 may. 2020 a las 16:03, Eric Gray (<eric.gray=[email-masked]<mailto:[email-masked]>>) escribió:

John and I had a discussion with Dhruv about some ambiguity in the relationship between some of the entities in the ACTN architecture and the related concepts in our NS-DT work in the Framework draft.

The upshot is that there is a bit of a slushy relationship between some of the terms that we (the NS design team) have defined (see the definitions draft) and loosely corresponding concepts defined in ACTN.  In particular, there are currently issues with the positioning of the TSC as directly analogous to MDSC, impacting interfaces between these logical components as well.

After a few iterations in discussion, Dhruv, John and I agreed to propose a replacement figure and text as shown immediately below.

       +------------------------------------+

       |             Customer               |  |

       +------------------------------------+

                         A                     |     ACTN

                         |                        Terminology

                         V                     |  and Concepts

       +------------------------------------+

       |      A highter level system        |  |   +-----+

       |(e.g e2e network slice orchestrator)| ===> | CNC |

       +------------------------------------+  |   +-----+

                         A                            A

                         | TSC NBI             |      | CMI

                         V                            V (LxSM)

       +------------------------------------+  |   +-------+

       |      Transport Slice Controller    | ===> | MDSC-H|

       +------------------------------------+  |   +-------+

                         A                            A

                         | TSC SBI (LxNM)      |      |

                         V                            V

       +------------------------------------+  |   +-------+

       |        Network Controller(s)       | ===> |MDSC-L |

       +------------------------------------+  |   +-------+

                                                      A

                Terminology/Concepts           |      | MPI

               Used in this Document                  V

                                               |   +-----+

                                                   | PNC |

                                               |   +-----+

We would also add further clarifying text along the lines of:

The TS-NBI would be at the same level as the customer service models (LxSM), except that it uses a technology agnostic service model where as LxSM does not.

We add hierarchy to the MDSC concept in this figure so that the mapping with LxNM might be easier to see.  But the TSC could also directly interact with multiple domain controllers in which case we have a single MDSC.

If nobody objects, or has additional input they would like to provide, we would like to go ahead and make this change to the Framework draft.

If necessary, we can discuss this at the meeting on Thursday (14 May).

--

Eric
--
Teas-ns-dt mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/teas-ns-dt

--
___________________________________________
Luis M. Contreras
[email-masked]<mailto:[email-masked]>
[email-masked]<mailto:[email-masked]>
Global CTIO unit / Telefonica

---

From: Dhruv Dhody <[email-masked]>
Date: Wed, 13 May 2020 18:23:09 +0530

Hi Luis, Haomian,

Few comments on mapping with RFC 8305 -

(1) From the point of view of the network (and taking RFC 8305 as
reference), I would consider the higher level E2E system as the RFC
8305's "customer" and map customer service model to the TSC NBI (and
CMI). The interface between Customer box in our figure (center-top)
and the higher level system is out of scope for our work in the IETF.

(2) If we agree on (1), then the TSC SBI could map to a service
delivery or network configuration based on the hierarchy of the
network controllers (as mentioned by Haomian).

-- 

We also need to make a change in definition draft where we describe
TSC-SBI - LxSM yang models are mentioned as example there [See
https://tools.ietf.org/html/draft-nsdt-teas-transport-slice-definition-01#section-5.2].

As mentioned by Sergio, this was the main reason for the earlier mapping!

--

Thanks!
Dhruv

On Wed, May 13, 2020 at 7:43 AM Zhenghaomian <[email-masked]> wrote:
> El mar., 12 may. 2020 a las 16:03, Eric Gray (<eric.gray=[email-masked]>) escribió:
>
> [email-masked]
> [email-masked]
> [email-masked]
>
> [email-masked]

---

From: "Belotti, Sergio (Nokia - IT/Vimercate)" <[email-masked]>
Date: Wed, 13 May 2020 14:38:09 +0000

Hi Dhruv, Haomian, all,

First an answer for point (1) from Dhruv, definitely I agree .

About point (2) , the fact SBI is mapped to a service delivery or network configuration model is important because it would help to clarify the role of TSC .

When in ACTN we have introduced the terms MDSC-H and MDSC-L, this was done above all in the context of scalability , when a hierarchy structure of MDSC could be foreseen.

In my view, the real improvement  triggered by Italo mail, and my and others comments as well, was to clarify functionality mapping with respect interface, so LxSM as customer service model has been considered in the context of NBI not as SBI as previously done.

Now in the view of possible mapping of functionality I think in RFC 8453 there is a picture that could be better mapped in the TS context and TSC functionality in particular.

This is a question for all for my understanding, if what is foreseen for TSC functionality is better represented by just a service delivery model at SBI (MPI in the picture here) or TSC can do more , and SBI can be better represented by Network configuration model.

Thanks

Sergio

-----Original Message-----
From: Teas-ns-dt <[email-masked]> On Behalf Of Dhruv Dhody
Sent: Wednesday, May 13, 2020 2:53 PM
To: Zhenghaomian <[email-masked]>
Cc: Eric Gray <eric.gray=[email-masked]>; [email-masked]; Luis M. Contreras <[email-masked]>
Subject: Re: [Teas-ns-dt] Figure in the ACTN Applicability section

Hi Luis, Haomian,

(1) From the point of view of the network (and taking RFC 8305 as reference), I would consider the higher level E2E system as the RFC 8305's "customer" and map customer service model to the TSC NBI (and CMI). The interface between Customer box in our figure (center-top) and the higher level system is out of scope for our work in the IETF.

(2) If we agree on (1), then the TSC SBI could map to a service delivery or network configuration based on the hierarchy of the network controllers (as mentioned by Haomian).

--

We also need to make a change in definition draft where we describe TSC-SBI - LxSM yang models are mentioned as example there [See https://tools.ietf.org/html/draft-nsdt-teas-transport-slice-definition-01#section-5.2].

--

Thanks!

Dhruv

On Wed, May 13, 2020 at 7:43 AM Zhenghaomian <[email-masked]<mailto:[email-masked]>> wrote:

> 发件人: Teas-ns-dt [mailto:[email-masked]] 代表 Luis M.

> Contreras

> 收件人: Eric Gray <eric.gray=[email-masked]<mailto:eric.gray=[email-masked]>>

> 抄送: [email-masked]<mailto:[email-masked]>

> El mar., 12 may. 2020 a las 16:03, Eric Gray (<eric.gray=[email-masked]<mailto:eric.gray=[email-masked]>>) escribió:

--

Teas-ns-dt mailing list

---

From: "Luis M. Contreras" <[email-masked]>
Date: Wed, 13 May 2020 23:45:27 +0200

Hi all,

from this discussion my take away is that several interpretations of the
mapping between TSC and ACTN could be possible and valid (at least, there
is not a unique mapping).

With that in mind, I think it is confusing to keep the mapping in section 4
of the framework document. I would prefer to move it to another document
reporting all possible mappings, or at least to an annex. I think we are
trying to explain TSC from ACTN eyes, but probably it is better for the TSC
framework document to think on TSC by itself and later on to see how
existing solutions fit to it (doing the reverse, that is, think how TSC
fits to existing solutions can condition the behavior/interfaces/purpose of
TSC).

Best regards

Luis

El mié., 13 may. 2020 a las 16:38, Belotti, Sergio (Nokia - IT/Vimercate) (<
[email-masked]>) escribió:

> About point (2) , the fact SBI is mapped to a service delivery or network
> configuration model is important because it would help to clarify the role
> of TSC .
>
> When in ACTN we have introduced the terms MDSC-H and MDSC-L, this was done
> above all in the context of scalability , when a hierarchy structure of
> MDSC could be foreseen.
>
> In my view, the real improvement  triggered by Italo mail, and my and
> others comments as well, was to clarify functionality mapping with respect
> interface, so LxSM as customer service model has been considered in the
> context of NBI not as SBI as previously done.
>
> Now in the view of possible mapping of functionality I think in RFC 8453
> there is a picture that could be better mapped in the TS context and TSC
> functionality in particular.
>
>
>
> This is a question for all for my understanding, if what is foreseen for
> TSC functionality is better represented by just a service delivery model at
> SBI (MPI in the picture here) or TSC can do more , and SBI can be better
> represented by Network configuration model.
>
>
>
> Thanks
>
> Sergio
>
>
>
> Cc: Eric Gray <eric.gray=[email-masked]>;
> [email-masked]; Luis M. Contreras <[email-masked]>
> reference), I would consider the higher level E2E system as the RFC 8305's
> "customer" and map customer service model to the TSC NBI (and CMI). The
> interface between Customer box in our figure (center-top) and the higher
> level system is out of scope for our work in the IETF.
>
>
>
> (2) If we agree on (1), then the TSC SBI could map to a service delivery
> or network configuration based on the hierarchy of the network controllers
> (as mentioned by Haomian).
>
>
>
> --
>
>
>
> > Thanks for the effort on making the mapping more complete. Actually I
> think both the updated proposal from {Eric, Dhruv, John} and the one from
> Luis are applicable in some cases, and how to deploy is fully dependent on
> the choice of implementation. Compared with the previous version in section
> 4 of draft-nsdt-teas-ns-framework-03, the main improvement is ‘TS-NBI is
> using technology-agnostic models’, as said by Eric.
>
> >
>
> >
>
> >
>
> > According to our experience in ACTN deployment, there are flexibilities
> on how many hierarchies of MDSC is needed, depending on the functionality
> of each hierarchy and the scalability of the network. I believe none of us
> are trying to exclude any implementation, neither the proposal from Eric
> nor Luis. So a more generic proposal is shown as follow, thoughts?
>
> >
>
> >
>
> >
>
> > Service Model in                                              ACTN
>
> >
>
> > 发件人: Teas-ns-dt [mailto:[email-masked]
> <[email-masked]>] 代表 Luis M.
>
> > Contreras
>
> > 发送时间: 2020年5月13日 0:03
>
> > (My apologies for the mail before, with the Confidential Notes by
> default. Please, ignore it. Repeating mail here).
>
> >
>
> >
>
> >
>
> > Hi Eric, all,
>
> >
>
> >
>
> >
>
> > 1/ Regarding the figure, I think that as it is now mix things a bit. In
> my personal subjective view I think it provides a view of how to fit TSC
> into ACTN rather in the other way around. My suggestion would be to depict
> the comparison as in the figure below (ignore the service model naming by
> now for this point). I think it becomes more clear, but again this is
> subjective, of course.
>
> >
>
> >
>
> >
>
> > 2/ Regarding the service model naming. I have revisited RFC8309 and I
> think that the proper mapping to service models in the case of TSC would be
> the one proposed in the figure below on the left-hand side (please, check
> Figure 3 in RFC8309).
>
> >
>
> >
>
> >
>
> > The text you propose depends totally on the final figure and the
> consideration of the service models that apply, so I would prefer to
> discuss first about the figure and once it is closed to discuss the text,
> to ensure consistency.
>
> >
>
> >
>
> >
>
> > Thanks
>
> >
>
> >
>
> >
>
> > Luis
>
> >
>
> >
>
> >
>
> > El mar., 12 may. 2020 a las 16:03, Eric Gray (<
> eric.gray=[email-masked]>) escribió:
>
> >
>
> > John and I had a discussion with Dhruv about some ambiguity in the
> relationship between some of the entities in the ACTN architecture and the
> related concepts in our NS-DT work in the Framework draft.
>
> >
>
> >
>
> >
>
> > The upshot is that there is a bit of a slushy relationship between some
> of the terms that we (the NS design team) have defined (see the definitions
> draft) and loosely corresponding concepts defined in ACTN.  In particular,
> there are currently issues with the positioning of the TSC as directly
> analogous to MDSC, impacting interfaces between these logical components as
> well.
>
> >
>
> >
>
> >
>
> > After a few iterations in discussion, Dhruv, John and I agreed to
> propose a replacement figure and text as shown immediately below.
>
> >
>
> >
>
> >
>
> > The TS-NBI would be at the same level as the customer service models
> (LxSM), except that it uses a technology agnostic service model where as
> LxSM does not.
>
> >
>
> >
>
> >
>
> > We add hierarchy to the MDSC concept in this figure so that the mapping
> with LxNM might be easier to see.  But the TSC could also directly interact
> with multiple domain controllers in which case we have a single MDSC.
>
> >
>
> >
>
> >
>
> > If nobody objects, or has additional input they would like to provide,
> we would like to go ahead and make this change to the Framework draft.
>
> >
>
> >
>
> >
>

---

From: "Belotti, Sergio (Nokia - IT/Vimercate)" <[email-masked]>
Date: Thu, 14 May 2020 07:46:37 +0000

Hi Luis,
Maybe you misunderstood my purpose that is not to map TSC to ACTN, but starting from common accepted assumption that ACTN is one of the possible realization of TS concept , I’ve just trying to clarify better the role and functionality of the controller in the TS chain, exploiting what is the different roles in the controllers chain in ACTN.
Moreover there was a mistake to be corrected , as reminded by Dhruv,  in draft-nsdt-teas-transport-slice-definition-01#section-5.2 regarding the mapping of LxSM at SBI .
I disagree on your proposal about chapter 4, that instead in my view can help do not reinvent the wheel if other IETF application already have proven to be able to create “slice” in the network even if under specific condition e.g. for ACTN to have TE network.

Thanks
Sergio

Sergio Belotti
Senior System Engineer and Standardization Architect
IP/Optical Networks, Optics BU
Nokia
M: +39-335761776
Via Energy Park, 20871 Vimercate (MB) , Italy
[email-masked]<mailto:[email-masked]>

From: Luis M. Contreras <[email-masked]>
Sent: Wednesday, May 13, 2020 11:45 PM
To: Belotti, Sergio (Nokia - IT/Vimercate) <[email-masked]>
Cc: Dhruv Dhody <[email-masked]>; Zhenghaomian <[email-masked]>; Eric Gray <eric.gray=[email-masked]>; [email-masked]; Italo Busi <[email-masked]>
Subject: Re: [Teas-ns-dt] Figure in the ACTN Applicability section

Hi all,

from this discussion my take away is that several interpretations of the mapping between TSC and ACTN could be possible and valid (at least, there is not a unique mapping).

With that in mind, I think it is confusing to keep the mapping in section 4 of the framework document. I would prefer to move it to another document reporting all possible mappings, or at least to an annex. I think we are trying to explain TSC from ACTN eyes, but probably it is better for the TSC framework document to think on TSC by itself and later on to see how existing solutions fit to it (doing the reverse, that is, think how TSC fits to existing solutions can condition the behavior/interfaces/purpose of TSC).

Best regards

Luis

El mié., 13 may. 2020 a las 16:38, Belotti, Sergio (Nokia - IT/Vimercate) (<[email-masked]<mailto:[email-masked]>>) escribió:

Hi Dhruv, Haomian, all,

Thanks

Sergio

-----Original Message-----
From: Teas-ns-dt <[email-masked]<mailto:[email-masked]>> On Behalf Of Dhruv Dhody
Sent: Wednesday, May 13, 2020 2:53 PM
To: Zhenghaomian <[email-masked]<mailto:[email-masked]>>
Cc: Eric Gray <eric.gray=[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; Luis M. Contreras <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Teas-ns-dt] Figure in the ACTN Applicability section

Hi Luis, Haomian,

--

--

Thanks!

Dhruv

On Wed, May 13, 2020 at 7:43 AM Zhenghaomian <[email-masked]<mailto:[email-masked]>> wrote:

--

Teas-ns-dt mailing list

---

From: "Luis M. Contreras" <[email-masked]>
Date: Thu, 14 May 2020 10:39:07 +0200

Hi Sergio,

yes, I acknowledge ACTN as one of the possible realizations of TS. And also
I'm fine with your exercise. My only point is that there could be some
other exercises equally valid, so what of them should be reflected?

That is why I would see more convenient focus on TSC concept first and
document alternative options w.r.t. ACTN (or any other) separately, or
subsequently if you wish.

I mean, I'm not against that, but I think that maybe we should focus first
on what do we expect the TSC to be, what kind of interfaces should be
supported here and there, etc, and then look to avoid re-invent the wheel
as much as we can.

That is only my point,

Best regards

Luis

El jue., 14 may. 2020 a las 9:46, Belotti, Sergio (Nokia - IT/Vimercate) (<
[email-masked]>) escribió:

> Hi Luis,
>
> Maybe you misunderstood my purpose that is not to map TSC to ACTN, but
> starting from common accepted assumption that ACTN is one of the possible
> realization of TS concept , I’ve just trying to clarify better the role and
> functionality of the controller in the TS chain, exploiting what is the
> different roles in the controllers chain in ACTN.
>
> Moreover there was a mistake to be corrected , as reminded by Dhruv,  in
> draft-nsdt-teas-transport-slice-definition-01#section-5.2 regarding the
> mapping of LxSM at SBI .
>
> I disagree on your proposal about chapter 4, that instead in my view can
> help do not reinvent the wheel if other IETF application already have
> proven to be able to create “slice” in the network even if under specific
> condition e.g. for ACTN to have TE network.
>
>
>
> Thanks
>
> Sergio
>
>
>
> Sergio Belotti
>
> [email-masked]
> *From:* Luis M. Contreras <[email-masked]>
> *Sent:* Wednesday, May 13, 2020 11:45 PM
> *To:* Belotti, Sergio (Nokia - IT/Vimercate) <[email-masked]>
> *Cc:* Dhruv Dhody <[email-masked]>; Zhenghaomian <
> [email-masked]>; Eric Gray <eric.gray=
> [email-masked]>; [email-masked]; Italo Busi <
> [email-masked]>
> *Subject:* Re: [Teas-ns-dt] Figure in the ACTN Applicability section
>
>
>
> Hi all,
>
>
>
> With that in mind, I think it is confusing to keep the mapping in section
> 4 of the framework document. I would prefer to move it to another document
> El mié., 13 may. 2020 a las 16:38, Belotti, Sergio (Nokia - IT/Vimercate)
> (<[email-masked]>) escribió:
>
> Hi Dhruv, Haomian, all,
>
>
>

---

From: "Belotti, Sergio (Nokia - IT/Vimercate)" <[email-masked]>
Date: Thu, 14 May 2020 09:55:58 +0000

Hi Luis,
I see you point, and we are on the same page on that.
In fact my intention behind the picture I proposed was a bit provocative to understand e.g. if TSC would encompass service-related function and network-related function or instead just providing the former one, forcing network controller to assume network orchestrator functionality. This question exactly is in the scope you mention implying “what kind of interfaces should be supported” ,  in one case to have some sort of internal service delivery model interface and  an SBI  based on a Network configuration model or in the other an SBI  based on service delivery model.
For this exercise , to have ACTN at section 4 does not create any issue instead providing hints to stimulate discussion in TS specific scope.

Cheers
Sergio

Sent: Thursday, May 14, 2020 10:39 AM

Hi Sergio,

yes, I acknowledge ACTN as one of the possible realizations of TS. And also I'm fine with your exercise. My only point is that there could be some other exercises equally valid, so what of them should be reflected?

That is why I would see more convenient focus on TSC concept first and document alternative options w.r.t. ACTN (or any other) separately, or subsequently if you wish.

I mean, I'm not against that, but I think that maybe we should focus first on what do we expect the TSC to be, what kind of interfaces should be supported here and there, etc, and then look to avoid re-invent the wheel as much as we can.

That is only my point,

Best regards

Luis

El jue., 14 may. 2020 a las 9:46, Belotti, Sergio (Nokia - IT/Vimercate) (<[email-masked]<mailto:[email-masked]>>) escribió:
Hi Luis,
Maybe you misunderstood my purpose that is not to map TSC to ACTN, but starting from common accepted assumption that ACTN is one of the possible realization of TS concept , I’ve just trying to clarify better the role and functionality of the controller in the TS chain, exploiting what is the different roles in the controllers chain in ACTN.
Moreover there was a mistake to be corrected , as reminded by Dhruv,  in draft-nsdt-teas-transport-slice-definition-01#section-5.2 regarding the mapping of LxSM at SBI .
I disagree on your proposal about chapter 4, that instead in my view can help do not reinvent the wheel if other IETF application already have proven to be able to create “slice” in the network even if under specific condition e.g. for ACTN to have TE network.

Thanks
Sergio

Sergio Belotti

From: Luis M. Contreras <[email-masked]<mailto:[email-masked]>>
Sent: Wednesday, May 13, 2020 11:45 PM
To: Belotti, Sergio (Nokia - IT/Vimercate) <[email-masked]<mailto:[email-masked]>>
Cc: Dhruv Dhody <[email-masked]<mailto:[email-masked]>>; Zhenghaomian <[email-masked]<mailto:[email-masked]>>; Eric Gray <eric.gray=[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; Italo Busi <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Teas-ns-dt] Figure in the ACTN Applicability section

Hi all,

Best regards

Luis

Hi Dhruv, Haomian, all,

Thanks

Sergio

-----Original Message-----
From: Teas-ns-dt <[email-masked]<mailto:[email-masked]>> On Behalf Of Dhruv Dhody
Sent: Wednesday, May 13, 2020 2:53 PM
To: Zhenghaomian <[email-masked]<mailto:[email-masked]>>
Cc: Eric Gray <eric.gray=[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; Luis M. Contreras <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Teas-ns-dt] Figure in the ACTN Applicability section

Hi Luis, Haomian,

--

--

Thanks!

Dhruv

On Wed, May 13, 2020 at 7:43 AM Zhenghaomian <[email-masked]<mailto:[email-masked]>> wrote:

--

Teas-ns-dt mailing list

---

From: Kiran Makhijani <[email-masked]>
Date: Thu, 14 May 2020 13:15:55 +0000

If we want to keep generalized mapping section clear, one option could be to describe both the approaches the way it is discussed here for the sake of clarity.
-Kiran

From: Teas-ns-dt <[email-masked]> On Behalf Of Belotti, Sergio (Nokia - IT/Vimercate)
Sent: Thursday, May 14, 2020 2:56 AM
To: Luis M. Contreras <[email-masked]>
Cc: Dhruv Dhody <[email-masked]>; [email-masked]; Eric Gray <eric.gray=[email-masked]>; Zhenghaomian <[email-masked]>; Italo Busi <[email-masked]>
Subject: Re: [Teas-ns-dt] Figure in the ACTN Applicability section

Hi Luis,

Cheers
Sergio

Cc: Dhruv Dhody <[email-masked]<mailto:[email-masked]>>; Zhenghaomian <[email-masked]<mailto:[email-masked]>>; Eric Gray <eric.gray=[email-masked]<mailto:eric.gray=[email-masked]>>; [email-masked]<mailto:[email-masked]>; Italo Busi <[email-masked]<mailto:[email-masked]>>

Hi Sergio,

That is only my point,

Best regards

Luis

Thanks
Sergio

Sergio Belotti

Hi all,

Best regards

Luis

Hi Dhruv, Haomian, all,

Thanks

Sergio

-----Original Message-----
From: Teas-ns-dt <[email-masked]<mailto:[email-masked]>> On Behalf Of Dhruv Dhody
Sent: Wednesday, May 13, 2020 2:53 PM
To: Zhenghaomian <[email-masked]<mailto:[email-masked]>>
Cc: Eric Gray <eric.gray=[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; Luis M. Contreras <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Teas-ns-dt] Figure in the ACTN Applicability section

Hi Luis, Haomian,

--

We also need to make a change in definition draft where we describe TSC-SBI - LxSM yang models are mentioned as example there [See https://tools.ietf.org/html/draft-nsdt-teas-transport-slice-definition-01#section-5.2<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-nsdt-teas-transport-slice-definition-01%23section-5.2&data=02%7C01%7Ckiranm%40futurewei.com%7C5edfb6fd2d9f45666e1208d7f7ed095d%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637250469782987713&sdata=f1eDiGUd3F03i59jNQ7sCE6pXkPhP9fiyf0j6XDFWDs%3D&reserved=0>].

--

Thanks!

Dhruv

On Wed, May 13, 2020 at 7:43 AM Zhenghaomian <[email-masked]<mailto:[email-masked]>> wrote:

> https://www.ietf.org/mailman/listinfo/teas-ns-dt<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fteas-ns-dt&data=02%7C01%7Ckiranm%40futurewei.com%7C5edfb6fd2d9f45666e1208d7f7ed095d%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637250469782997715&sdata=Y%2Ftmv0pH7UhSmHIyiWW03z00Ax3Z3%2BF%2BbvS9cNcrfI4%3D&reserved=0>

> https://www.ietf.org/mailman/listinfo/teas-ns-dt<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fteas-ns-dt&data=02%7C01%7Ckiranm%40futurewei.com%7C5edfb6fd2d9f45666e1208d7f7ed095d%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637250469782997715&sdata=Y%2Ftmv0pH7UhSmHIyiWW03z00Ax3Z3%2BF%2BbvS9cNcrfI4%3D&reserved=0>

--

Teas-ns-dt mailing list

https://www.ietf.org/mailman/listinfo/teas-ns-dt<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fteas-ns-dt&data=02%7C01%7Ckiranm%40futurewei.com%7C5edfb6fd2d9f45666e1208d7f7ed095d%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637250469783007710&sdata=wMZUrhHl%2BRC3HX3tuXJvdyd%2FkTMKsqTmlqQ1F1x24LQ%3D&reserved=0>