Subject: Re: [Teas-ns-dt] Pull-request #8: Reza’s proposed text addition to the controller section

From: Eric Gray <[email-masked]>
Date: Wed, 4 Mar 2020 10:55:15 +0000

Bo,

              Okay.

              At present, we say only “endpoints” without qualifying what that means in terms of the TSC NBI.  Because we do not do so, we leave it to detailed NBI specification to do so, intrinsically not restricting the definition of a transport slice endpoint in any way.

              It seems too much information for this document to go into the specifics of an NBI specification of what an endpoint is.

--
Eric

From: Wubo (lana) <[email-masked]>
Sent: Saturday, February 29, 2020 4:46 AM
To: Eric Gray <[email-masked]>; Rokui, Reza (Nokia - CA/Ottawa) <[email-masked]>; John E Drake <[email-masked]>; Dongjie (Jimmy) <[email-masked]>; Jari Arkko <[email-masked]>; [email-masked]
Subject: Re: Pull-request #8: Reza’s proposed text addition to the controller section
Importance: High

Hi Eric,

Sorry, it was my mistake to mislead you.  My suggestion is as follows:
1. The TS endpoint needs a clear definition.  It is recommended that this definition is consistent in both framework and definition draft.
2.  During the interaction between the TSC and the High layer system, the two types of identifying the TS endpoint are described.

Thanks,
Bo

发件人: Eric Gray [mailto:[email-masked]]
发送时间: 2020年2月28日 23:43
收件人: Wubo (lana) <[email-masked]<mailto:[email-masked]>>; Rokui, Reza (Nokia - CA/Ottawa) <[email-masked]<mailto:[email-masked]>>; John E Drake <[email-masked]<mailto:[email-masked]>>; Dongjie (Jimmy) <[email-masked]<mailto:[email-masked]>>; Jari Arkko <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
主题: RE: Pull-request #8: Reza’s proposed text addition to the controller section

I was not actually aware that Reza was proposing an update to his text, as opposed to a “summary” explanation for what he had earlier proposed.

From: Wubo (lana) <[email-masked]<mailto:[email-masked]>>
Sent: Friday, February 28, 2020 2:40 AM
To: Rokui, Reza (Nokia - CA/Ottawa) <[email-masked]<mailto:[email-masked]>>; John E Drake <[email-masked]<mailto:[email-masked]>>; Dongjie (Jimmy) <[email-masked]<mailto:[email-masked]>>; Eric Gray <[email-masked]<mailto:[email-masked]>>; Jari Arkko <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: Pull-request #8: Reza’s proposed text addition to the controller section
Importance: High

I agree with Reza's updated text. It is clear to me.  Thanks!

B.R.
Bo
发件人: Rokui, Reza (Nokia - CA/Ottawa) [mailto:[email-masked]]
发送时间: 2020年2月28日 4:57
收件人: Wubo (lana) <[email-masked]<mailto:[email-masked]>>; John E Drake <jdrake=[email-masked]<mailto:jdrake=[email-masked]>>; Dongjie (Jimmy) <[email-masked]<mailto:[email-masked]>>; Eric Gray <eric.gray=[email-masked]<mailto:eric.gray=[email-masked]>>; Jari Arkko <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
抄送: Rokui, Reza (Nokia - CA/Ottawa) <[email-masked]<mailto:[email-masked]>>
主题: Re: Pull-request #8: Reza’s proposed text addition to the controller section

Thanks Bo, John, Jimmy and Eric.

The comment given by Bo is the closest one to whatever I’ve intended to include in Framework draft.

In summary:

  *   As indicated by Bo, the Endpoints coming to TSC from its NBI, is shown below. Either one is acceptable.

  *   Note that in my original example, CE1 is gNB1 and CE2 is UPF1. Also PE1 and PE2 are ER1 and ER2, respectively.

  *   Endpoints are NOT the network elements but rather their APs (as defined in RFC 8453)

  *   If endpoints are CE1.x  and CE2.z (left picture), when TSC receives the request to create a transport slice between CE1.x and CE2.z, it will find the PE1.w and PE2.y and initiate creation of  L0-L3 services/paths/tunnels between them to realize transport slice. The reason is that neither CE1 nor CE2 supports services/paths/tunnels

  *   If endpoints are PE1.w and PE2.y (right picture), when TSC receives the request to create a transport slice between PE1.w and PE2.y, since network elements PE1 and PE2 supports services/tunnels/paths, TSC will initiate creation of  L0-L3 services/paths/tunnels between them to realize transport slice.

  *   Again as indicated by Bo, both cases shall be supported by TSC NBI. We should not favor one vs. other one. In other words, Framework draft should mention both as potential supported cases.

Reza Rokui, Ph.D.
Director, NSP Product Management
Nokia Canada
IP/Optical Network Automation
T:  +1-613-784-1762
M: +1-613-979-6986
600 March Road, Kanata, Ontario, K2K 2E6
[email-masked]<mailto:[email-masked]>

From: "Wubo (lana)" <[email-masked]<mailto:[email-masked]>>
Date: Thursday, February 27, 2020 at 11:53 AM
To: John E Drake <jdrake=[email-masked]<mailto:jdrake=[email-masked]>>, "Dongjie (Jimmy)" <[email-masked]<mailto:[email-masked]>>, Eric Gray <eric.gray=[email-masked]<mailto:eric.gray=[email-masked]>>, Reza Rokui <[email-masked]<mailto:[email-masked]>>, Jari Arkko <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: Pull-request #8: Reza’s proposed text addition to the controller section

Hi John, Eric,

I don't agree regarding the definition of endpoint and the endpoint parameters to be carried to the TSC.

Taken Reza’s example, also referenced by Eric:
                                                  +----+
                      .----.                       +UPF1|
    [gNB1] +----+    (      )---.                 /+--=-+
         \ |    |===========================[ER2]+
          \| ER1|  (      Network       )          +----+
          /|    |===========================[ER3]+-|UPF2|
         / +----+    `----------------'         +  +----+
    [gNB2]                                       \
                                                  \+----+
                                                   +UPF3|
                                                   +----+
    Legends
      === : Tunnels & Services
      ER: Edge Router

1.endpoint definition
The gNB and the UPF are not part of the transport network.
Only the assess links connected to these devices are shared with the transport network.
The RFC8453(ACTN framework) defines the access point to identify the boundary. I think perhaps we can use a similar definition.

Access Point (AP): An AP is a logical identifier shared between the customer and the operator used to identify an access link.
        The AP is used by the customer when requesting a VNS(Virtual Network Service).

2.endpoint parameters definition
I think there are two possible ways to carry different parameters based on the functionality of the higher-level system and TSC.

1). A higher-level system maintains an NNI connection topology of RAN, core, and transport network.
Therefore, after the slice instance is created in the RAN and the core, ‘provider edge (PE)’ device can be found by the higher-level system,
so it will use endpoints to carry PE access information to the TSC to create the transport slice.

2). The transport network maintain the connection topology with the RAN and the core.
 Therefore, the higher-level system will use endpoints parameters associated with CE or wireless devices to the TSC.

I think the framework should not have only one option.

Thanks,
Bo

发件人: Teas-ns-dt [mailto:[email-masked]] 代表 John E Drake
发送时间: 2020年2月27日 3:20
收件人: Dongjie (Jimmy) <[email-masked]<mailto:[email-masked]>>; Eric Gray <eric.gray=[email-masked]<mailto:eric.gray=[email-masked]>>; Rokui, Reza (Nokia - CA/Ottawa) <[email-masked]<mailto:[email-masked]>>; Jari Arkko <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
主题: Re: [Teas-ns-dt] Pull-request #8: Reza’s proposed text addition to the controller section

Hi,

As I indicated in an email yesterday, I agreed with Eric’s point :

In another view (or way of looking at it), the higher-level entity asks the TSC to connect two or more addressable entities providing both connectivity and SLO parameters, where (at least from the perspective of the higher-level entity, the service terminates at each of the addressable entities included in the request to the TSC.  In this view, the links connecting any ER in the transport service  to the specific entities are part of the requested service – hence any edge router involvement is within the service, not a termination point for the service.  Also, in this view, “finding” the appropriate edge router is not any different from finding the path (or route) for the connection.  This applies during creation of, maintenance or and deletion of the Slice – hence this view is actually the simplest one to use in discussion.  Also note that this view may be significantly more correct, in any case where any specific connected entity may be reached via more than one link.

In other words a transport slice endpoint is always a tenant device (or in IETF terminology a ‘customer equipment (CE)’ device) and the services provided to that transport slice endpoint (e.g., VPNs, service chains, or 5G specific functions) are part of the service definition for that transport slice endpoint.  So, the two types of endpoints defined in section 5.2.1 are actually within the transport slice provider’s network and are not visible outside of it, and section 5.2.1 is incorrect as currently written.

These functions may either be located entirely within the ‘provider edge (PE)’ device (IETF terminology) to which a transport slice endpoint is attached or distributed between the PE and other nodes within the tenant slice provider’s network.  (As an aside I don’t think the functionality associated with ‘transport type endpoint’ actually exists because at a very minimum a packet needs to be tagged with the tenant identifier (or in IETF terminology the ‘VPN identifier’.)

To answer Jimmy’s point, below,  we could state that a given tenant has the option of supplementing the services provided by a transport slice with services of its own.  However, the devices providing these supplemental services are attached to a transport slice as transport slice endpoints and that the transport slice provider is completely unaware of them.  In IETF terminology a device providing such services is a ‘Customer-Provider Edge (C-PE)’ device.

Yours Irrespectively,

John

Juniper Business Use Only
From: Teas-ns-dt <[email-masked]<mailto:[email-masked]>> On Behalf Of Dongjie (Jimmy)
Sent: Wednesday, February 26, 2020 7:33 AM
To: Eric Gray <eric.gray=[email-masked]<mailto:eric.gray=[email-masked]>>; Rokui, Reza (Nokia - CA/Ottawa) <[email-masked]<mailto:[email-masked]>>; Jari Arkko <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: [Teas-ns-dt] Pull-request #8: Reza’s proposed text addition to the controller section

Agree that some explanation about the terms would be needed.

It seems a little odd that the “transport slice endpoints” refers to the nodes “gNB, UPF…” which are outside the transport domain, while the “service endpoints” are actually the nodes which are the border nodes of the transport network.

Best regards,
Jie

From: Teas-ns-dt [mailto:[email-masked]] On Behalf Of Eric Gray
Sent: Tuesday, February 25, 2020 10:40 PM
To: Rokui, Reza (Nokia - CA/Ottawa) <[email-masked]<mailto:[email-masked]>>; Jari Arkko <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: [Teas-ns-dt] Pull-request #8: Reza’s proposed text addition to the controller section

I agree that more explanation is needed somewhere.  For one thing, we need to agree on the definition for “Service Endpoints” (and whether ot not they are – or can be – distinct from slice end points.

I suspect that this needs to be handled in the definitions draft.  See also my detailed comments in separate mail – which address a disconnect in the figure you used in your explanation…

From: Rokui, Reza (Nokia - CA/Ottawa) <[email-masked]<mailto:[email-masked]>>
Sent: Tuesday, February 25, 2020 8:45 AM
To: Jari Arkko <[email-masked]<mailto:[email-masked]>>; Eric Gray <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Cc: Rokui, Reza (Nokia - CA/Ottawa) <[email-masked]<mailto:[email-masked]>>
Subject: Re: Pull-request #8: Reza’s proposed text addition to the controller section
Importance: High

Jari,
My response is inline.

Reza

From: Jari Arkko <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, February 25, 2020 at 11:20 AM
To: Reza Rokui <[email-masked]<mailto:[email-masked]>>, Eric Gray <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: Pull-request #8: Reza’s proposed text addition to the controller section

FWIW, I’m happy with the conclusions your Reza and Eric drew. But this one requires further thinking:

    * Using the network abstract topology, it provides mechanism to find
      the Service endpoints (these are technology specific).
      (TODO: this seems unclear. What endpoints are these, are why
      are they different from endpoints discussed earlier?)

EG > Obviously.  IMO, the requesting application (higher-level controller, for example) MUST specify the end-points for the transport service, at least using some abstraction (e.g. – name), and the precise technology of the connecting interface.  This is fairly obvious as the request is based on some knowledge about what is connecting to the Transport Slice at each end that the TSC controller cannot know a priori.  Since this information MUST be in the “API” request, there should be nothing for the TSC to “discover.”

Rewording:

  *   Provides requested services and endpoint connectivity.

[Reza] Modified rewording:

  *   Using the abstract topology of the interconnected networks and provided transport slice endpoints , it will find the Service endpoints.

Explanation:
The concept is shown in our  original Definition draft which later has been removed due to number of pages of the draft to be included in framework draft (or other drafts).
This picture is for 5G use-case but demonstrates the idea.
In summary, the transport slice request is between “transport slice endpoints” gNB1, gNB2, UPF1, UPF2 and UPF3 where the realization of this transport slice is between “service endpoints” ER1, ER2 and ER3.
So, it is clear that the “transport slice endpoints” are different from  “service endpoints”.

Jari: I think this is still confusing, at least to me. From what I can understand there needs to be two things:

  *   At the NBI, the requester needs to tell the controller what endpoints it wants the transport slice to be connecting. This I think we already say. So, for instance, I want this virtual ethernet in this computer connected with a transport slice Slice1 at 10 gbit/s with another virtual ethernet in that other computer.
  *   The controller needs to maintain an internal mapping of how a given slice is realized, so that, for instance, Slice1 in the first computer corresponds to VLAN 123 on physical interface ethx on that computer, switch configuration for VLAN 123, and again VLAN 123 and physical interface ethy on the second computer.

But I’m confused whether your text above talks about the first or the second bullet. In fact it seems to talk about some other function, where the controller somehow analyses abstract topologies to find some endpoints… why? Sorry, maybe not enough caffeinated drinks this morning but I don’t understand ☹

Maybe this would work better:

The controller maintains the connections of the transport slice to the endpoints specified by the consumer. In addition, it will keep track of how communication from those endpoints is mapped to specific underlying components of the realization of the transport slice (such as VPN tunnel endpoints or MPLS labels).

[Reza] It is mainly option 2 above. I am fine with your text Jari but it definitely needs more explanations somewhere either in this draft or other drafts. This is basically related to Section-6 of the original Definition draft which was removed. At that time we wanted to include them in Framework draft.

Jari

---

From: Eric Gray <[email-masked]>
Date: Wed, 4 Mar 2020 11:22:53 +0000

Based on Reza’s Pull #8 and the extensive discussion that followed, I plan to add the following text to the framework document:

Transport Slice Controller (TSC)
The transport slice controller takes abstract requests for
transport slices and implements them using a suitable underlying
technology. A transport slice controller is the key building
block for control and management of the transport slice. It
provides the creation/modification/deletion, monitoring and
optimization of transport Slices in a multi-domain, a
multi-technology and multi-vendor environment.
In discussion in this document, a southbound interface (SBI)
is used as a logical construct (that may or may not exist in
practice) representing mechanisms used by the TSC in
communicating with the underlying (abstract) network.
A TSC northbound interface is needed for communicating
details of a transport slice, as well as providing information
to a slice requester/consumer about transport slice status
and performance. The details for this NBI are not in scope
for this document.
The controller provides the following functions:

  *   Provides a technology-agnostic NBI for creation/modification/
deletion of the transport slices. The API exposed by this NBI
communicates the endpoints of the transport slice, transport
slice SLO parameters (and possibly monitoring thresholds),
applicable input selection (filtering) and various policies, and
provides a way to monitor the slice.
  *   Determines an abstract topology connecting the endpoints of
the transport slice that meets criteria specified via the NBI.The
TSC also retains information about the mapping of this abstract
topology to underlying components of the transport slice as
necessary to monitor transport slice status and performance.

  *   Provides "Mapping Functions" for the realization of transport slices.
In other words, it will use the mapping functions which:
- map technology-agnostic NBI request to technology-specific SBIs.
- map filtering/selection information as necessary to entities in the
   underlay network.
  *   Via an SBI, the controller collects Telemetry data (e.g. OAM results,
Statistics, States etc.) for all elements in the abstract topology used
to realize the transport slice.
  *   Using the Telemetry data from the underlying realization of a
transport slice (i.e. services/paths/tunnels), evaluates the
current performance against transport slice SLO parameters and
exposes them to the transport slice consumer via the NBI. The
TSC NBI may also include a capability to provide notification in
case the transport slice performance reaches threshold values
defined by the transport slice consumer.

---

From: "Wubo (lana)" <[email-masked]>
Date: Thu, 5 Mar 2020 06:55:58 +0000

Hi Eric,

I agree that if the main purpose of the framework is to give general description of TS NBI and TSC , the definition of endpoint is too specific.

Thanks,
Bo

发件人: Teas-ns-dt [mailto:[email-masked]] 代表 Eric Gray
发送时间: 2020年3月4日 18:55
收件人: Wubo (lana) <[email-masked]>; Rokui, Reza (Nokia - CA/Ottawa) <[email-masked]>; John E Drake <[email-masked]>; Dongjie (Jimmy) <[email-masked]>; Jari Arkko <[email-masked]>; [email-masked]
主题: Re: [Teas-ns-dt] Pull-request #8: Reza’s proposed text addition to the controller section

Bo,

              Okay.

--
Eric

From: Wubo (lana) <[email-masked]<mailto:[email-masked]>>
Sent: Saturday, February 29, 2020 4:46 AM
To: Eric Gray <[email-masked]<mailto:[email-masked]>>; Rokui, Reza (Nokia - CA/Ottawa) <[email-masked]<mailto:[email-masked]>>; John E Drake <[email-masked]<mailto:[email-masked]>>; Dongjie (Jimmy) <[email-masked]<mailto:[email-masked]>>; Jari Arkko <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: Pull-request #8: Reza’s proposed text addition to the controller section
Importance: High

Hi Eric,

Thanks,
Bo

B.R.
Bo

In summary:

-          As indicated by Bo, the Endpoints coming to TSC from its NBI, is shown below. Either one is acceptable.

-          Note that in my original example, CE1 is gNB1 and CE2 is UPF1. Also PE1 and PE2 are ER1 and ER2, respectively.

-          Endpoints are NOT the network elements but rather their APs (as defined in RFC 8453)

-          If endpoints are CE1.x  and CE2.z (left picture), when TSC receives the request to create a transport slice between CE1.x and CE2.z, it will find the PE1.w and PE2.y and initiate creation of  L0-L3 services/paths/tunnels between them to realize transport slice. The reason is that neither CE1 nor CE2 supports services/paths/tunnels

-          If endpoints are PE1.w and PE2.y (right picture), when TSC receives the request to create a transport slice between PE1.w and PE2.y, since network elements PE1 and PE2 supports services/tunnels/paths, TSC will initiate creation of  L0-L3 services/paths/tunnels between them to realize transport slice.

-          Again as indicated by Bo, both cases shall be supported by TSC NBI. We should not favor one vs. other one. In other words, Framework draft should mention both as potential supported cases.

Reza Rokui, Ph.D.

Hi John, Eric,

1.endpoint definition

Thanks,
Bo

Hi,

Yours Irrespectively,

John

Best regards,
Jie

Jari,
My response is inline.

Reza

Rewording:

Explanation:

Jari

---

From: Xufeng Liu <[email-masked]>
Date: Thu, 5 Mar 2020 09:36:19 -0500

Hi Eric and All,

This section looks good to me. I have one minor comment in-line below.
Thanks,
- Xufeng

On Wed, Mar 4, 2020 at 6:23 AM Eric Gray <eric.gray=
[email-masked]> wrote:

> Based on Reza’s Pull #8 and the extensive discussion that followed, I plan
> to add the following text to the framework document:
>
>
>
> details of a transport slice,
>
The word "details" here is vague to me. To what extent of the "details" the
NBI needs to communicate? what kind of details? The next sentence says "The
details for this NBI are not in scope", making the term here more
confusing. May I suggest some rewording? Maybe:
"the applied configuration, selected policies, and operational state"?

as well as providing information
>    - Provides a technology-agnostic NBI for creation/modification/
>    - Determines an abstract topology connecting the endpoints of
>    - Provides "Mapping Functions" for the realization of transport slices.
>    - Via an SBI, the controller collects Telemetry data (e.g. OAM results,
>    - Using the Telemetry data from the underlying realization of a
> Teas-ns-dt mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/teas-ns-dt
>

---

From: Eric Gray <[email-masked]>
Date: Thu, 12 Mar 2020 14:51:22 +0000

Xufeng,

              So, what we are trying to say is that some information (we say “details”) could be provided between the Transport Slice consumer and the TSC via an NBI.

              That statement is intended as a high-level summary and – because we are not defining the “details” of the NBI in this document – the actual details are (of course) out of scope (this is pretty much a tautology; it would be curiously weird, actually, to describe the details and then say that describing the details is out of scope).

              Do you have any suggestion for how we could make this clearer at the intended level, and without providing information we do not intend to provide?

              If you do have a proposal that folks can get behind, I would be happy to put it in for the “-01” version…

--
Eric

From: Xufeng Liu <[email-masked]>
Sent: Thursday, March 5, 2020 9:36 AM
To: Eric Gray <[email-masked]>
Cc: [email-masked]; Wubo (lana) <[email-masked]>; Dongjie (Jimmy) <[email-masked]>; Rokui, Reza (Nokia - CA/Ottawa) <[email-masked]>; Jari Arkko <[email-masked]>; John E Drake <[email-masked]>
Subject: Re: [Teas-ns-dt] Pull-request #8: Reza’s proposed text addition to the controller section
Importance: High

Hi Eric and All,

On Wed, Mar 4, 2020 at 6:23 AM Eric Gray <eric.gray=[email-masked]<mailto:[email-masked]>> wrote:

The word "details" here is vague to me. To what extent of the "details" the NBI needs to communicate? what kind of details? The next sentence says "The details for this NBI are not in scope", making the term here more confusing. May I suggest some rewording? Maybe:

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

---

From: Xufeng Liu <[email-masked]>
Date: Thu, 12 Mar 2020 16:17:58 -0400

Hi Eric,

On Thu, Mar 12, 2020 at 10:51 AM Eric Gray <[email-masked]> wrote:

> Xufeng,
>
>
>
>               So, what we are trying to say is that some information (we
> say “details”) could be provided between the Transport Slice consumer and
> the TSC via an NBI.
>
>
>
>               That statement is intended as a high-level summary and –
> because we are not defining the “details” of the NBI in this document – the
> actual details are (of course) out of scope (this is pretty much a
> tautology; it would be curiously weird, actually, to describe the details
> and then say that describing the details is out of scope).
>
Right. That is my feeling. Replacing one of these "details" would be better.

>
>
>               Do you have any suggestion for how we could make this
> clearer at the intended level, and without providing information we do not
> intend to provide?
>
Maybe using "the applied configuration, selected policies, and operational
state", or something like that. Like mentioned, anything other than
"details" would sound better.

>
>
>               If you do have a proposal that folks can get behind, I would
> be happy to put it in for the “-01” version…
>
>
>
> --
>
> Eric
>
>
>
> *From:* Xufeng Liu <[email-masked]>
> *Sent:* Thursday, March 5, 2020 9:36 AM
> *To:* Eric Gray <[email-masked]>
> *Cc:* [email-masked]; Wubo (lana) <[email-masked]>; Dongjie
> (Jimmy) <[email-masked]>; Rokui, Reza (Nokia - CA/Ottawa) <
> [email-masked]>; Jari Arkko <[email-masked]>; John E Drake
> <[email-masked]>
> *Subject:* Re: [Teas-ns-dt] Pull-request #8: Reza’s proposed text
> addition to the controller section
> *Importance:* High
>
>
>
> Hi Eric and All,
>
>
>
> The word "details" here is vague to me. To what extent of the "details"
> the NBI needs to communicate? what kind of details? The next sentence says
> "The details for this NBI are not in scope", making the term here more

---

From: Eric Gray <[email-masked]>
Date: Mon, 16 Mar 2020 16:24:15 +0000

That is a reasonable suggestion.  Thanks!

--
Eric

Sent: Thursday, March 12, 2020 4:18 PM

Hi Eric,

On Thu, Mar 12, 2020 at 10:51 AM Eric Gray <[email-masked]<mailto:[email-masked]>> wrote:
Xufeng,

              Do you have any suggestion for how we could make this clearer at the intended level, and without providing information we do not intend to provide?
Maybe using "the applied configuration, selected policies, and operational state", or something like that. Like mentioned, anything other than "details" would sound better.

--
Eric

From: Xufeng Liu <[email-masked]<mailto:[email-masked]>>
Sent: Thursday, March 5, 2020 9:36 AM
To: Eric Gray <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; Wubo (lana) <[email-masked]<mailto:[email-masked]>>; Dongjie (Jimmy) <[email-masked]<mailto:[email-masked]>>; Rokui, Reza (Nokia - CA/Ottawa) <[email-masked]<mailto:[email-masked]>>; Jari Arkko <[email-masked]<mailto:[email-masked]>>; John E Drake <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Teas-ns-dt] Pull-request #8: Reza’s proposed text addition to the controller section
Importance: High

Hi Eric and All,

---

From: Jari Arkko <[email-masked]>
Date: Mon, 16 Mar 2020 16:54:52 +0000

> That is a reasonable suggestion.  Thanks!

Ok for me as well.

Jari

---

From: John E Drake <[email-masked]>
Date: Mon, 16 Mar 2020 17:21:01 +0000

I agree

Sent from my iPhone

Ok for me as well.

Jari

---

From: Eric Gray <[email-masked]>
Date: Fri, 20 Mar 2020 18:51:27 +0000

The suggested change is now in the current iteration of the “-02” version of the framework draft in GitHub (https://github.com/teas-wg/teas-ns-dt).

--
Eric

From: Teas-ns-dt <[email-masked]> On Behalf Of Eric Gray
Sent: Monday, March 16, 2020 12:24 PM
To: Xufeng Liu <[email-masked]>
Cc: John E Drake <[email-masked]>; [email-masked]; Jari Arkko <[email-masked]>; Dongjie (Jimmy) <[email-masked]>; Wubo (lana) <[email-masked]>; Rokui, Reza (Nokia - CA/Ottawa) <[email-masked]>
Subject: Re: [Teas-ns-dt] Pull-request #8: Reza’s proposed text addition to the controller section

--
Eric

Hi Eric,

--
Eric

Hi Eric and All,