Re: [Teas-ns-dt] Some thoughts on principles, terms, and scope

["Dongjie (Jimmy)" <[e-mail]>]

Hi Jari and all,

From: Teas-ns-dt [mailto:[e-mail]] On Behalf Of Jari Arkko
Sent: Thursday, October 17, 2019 10:36 PM
To: [e-mail]
Subject: [Teas-ns-dt] Some thoughts on principles, terms, and scope

I wanted to send some of my thoughts on terms and our scope of work.

But I'd  like to start with a principle: We should make a clear separation between requirement and implementation (as also pointed out by Jimmy). I also dislike the use of too broad terms that do not have an exact meaning.

I'm not wedded to my specific terms below, but I hope the following illustrates how I'm thinking about this.

Our scope is to look at transport connections that could be used in various contexts, from 5G to leased connections. This scope is not the full picture of what so called slicing covers in 5G, but is a useful component for those that need to use specific network connectivity. A transport connection is defined as a communications channel between specified parties, with specified transmission characteristics requirements such as latency or bandwidth.

[Jie] Agreed. One thing I’d like to add is that it needs to cover various types of connections, such as point-to-point, point-to-multipoint, multipoint-to-multipoint, etc.

The contribution IETF wants to make for the world in this space is twofold, to specify a "northbound" interface that allows such transport connections to be created and managed, and to specify an implementation or implementations of how a requirement for a transport connection can be realized using specific IETF network technologies.

[Jie] Agreed. And the design team needs to take both aspects into consideration in the architecture.

The northbound interface should be based entirely on requirements and not implementation details. For instance, a requirement might be minimum bandwidth and maximum latency, rather than "use wire type XYZ" or "use two wires". We need to find better terminology for isolation, because I think real issue is traffic guarantees such as maximum latency and ability to withstand faults, not the abstract term "isolation". For instance, if I just want a guaranteed bandwidth and latency, I can achieve this in various different ways even on a shared link. But if I want to ensure that no single physical damage can cut my connection, then I need to place a requirement on a connection using two alternate, physically entirely separate resources.

[Jie] In my understanding, isolation can be another dimension to describe the requirement. Isolation indicates the level of impact from other services in the network, which give the customer different expectations on the behaviour and performance of a network slice. For example, for customer or application which requires 10ms latency, it is different requirement whether it is the latency when there is no congestion in the network (i.e. in best case), or it is the latency which must be met even if there is congestion happened in the network (i.e. in worst case), or it is the latency which is expected to be achieved under other specific conditions.

Best regards,
Jie

Jari