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

From: Jari Arkko <[email-masked]>
Date: Thu, 17 Oct 2019 14:35:50 +0000

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.

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.

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.

Jari

---

From: Jeff Tantsura <[email-masked]>
Date: Thu, 17 Oct 2019 09:31:59 -0700

Jari,

Unfortunately the meeting couldn’t be recorded, we need to figure out how to make it work if it is not you, hosting.

Very good discussions, good progress, thanks everyone!

action points from the meeting:
ALL: work on stable vocabulary, we still don’t agree on terminology used
Reza/Xufeng/Jeff/more?: review CMI (RFC8453) as a potential base for the NBI

please see inline

Cheers,
Jeff
> 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 n…
[jeff] we are in agreement here
> 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 i…
[jeff] agreed
> 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 t…
[jeff] agreed, good progress on the discussion
>
> Jari
>
> --
> Teas-ns-dt mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/teas-ns-dt

---

From: "Dongjie (Jimmy)" <[email-masked]>
Date: Fri, 18 Oct 2019 03:49:30 +0000

Hi Jari and all,

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

[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.

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

[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

---

From: Xufeng Liu <[email-masked]>
Date: Sat, 19 Oct 2019 12:37:23 -0400

On Thu, Oct 17, 2019 at 11:50 PM Dongjie (Jimmy) <[email-masked]>
wrote:

> Hi Jari and all,
>
>
>
> *From:* Teas-ns-dt [mailto:[email-masked]] *On Behalf Of *Jari
> Arkko
> *Sent:* Thursday, October 17, 2019 10:36 PM
> *To:* [email-masked]
> *Subject:* [Teas-ns-dt] Some thoughts on principles, terms, and scope
>
>
>
> 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.
>
>
>
> 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.
>
>
>
> 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.
>

Agree with the direction that Jari outlined.

Most of these parameters are achievable:

The current TE topology model can specify the followings on a link
(physical or virtual):
- cost
- delay
- load
- bandwidth

There is also objective-functions at the network (or topology) level, which
is based on current PCE spec:
- cost
- load
- bandwidth
(the scope can be easily extended)

The isolation-level in Luis' template spreadsheet (GSMA NG.116)
provides a reasonable intent for isolation requirement (though there
could be some confusions and out-of-scope values):
- Physical
  * Process and threads isolation
  * Physical memory isolation
  * Physical network isolation
- Logical
  * Virtual resources isolation
  * Network functions isolation
  * Tenant/Service Isolation
These (or some of these) can be augmented to the existing IETF models.

By the way, the IETF topology models already support the requirement
aspect, and they also support the representations of shared or separated
underlying resources.

Thanks,
- Xufeng

---

From: Jeff Tantsura <[email-masked]>
Date: Sat, 19 Oct 2019 10:17:24 -0700

Looks good to me.
Perhaps we could follow on Luis’ spreadsheet and create a number of augmentations that should be shared with potential consumers to see whether it addresses their intent wrt isolation. On PCE side of things “degree/level” of isolation should become a regular constraint that is used in the computation.

Regards,
Jeff

> On Oct 19, 2019, at 09:37, Xufeng Liu <[email-masked]> wrote:
> 
> 
> 
> 
>> On Thu, Oct 17, 2019 at 11:50 PM Dongjie (Jimmy) <[email-masked]> wrote:
>> Hi Jari and all,
>> 
>>  
>> 
> The current TE topology model can specify the followings on a link (physical or virtual):
> - cost
> - delay
> - load
> - bandwidth
> 
> There is also objective-functions at the network (or topology) level, which is based on current PCE spec:
> - cost
> - load
> - bandwidth
> By the way, the IETF topology models already support the requirement aspect, and they also support the representations of shared or separated underlying resources.
> 
> Thanks,
> - Xufeng 
>>  
>> 
>> Best regards,
>> 
>> Jie
>> 
>>  
>> 
>> Jari
>> 
>>  
>> 
>> -- 
>> Teas-ns-dt mailing list
>> [email-masked]