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

[Jeff Tantsura <[e-mail]>]

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 <[e-mail]> wrote:
> 
> 
> 
> 
>> On Thu, Oct 17, 2019 at 11:50 PM Dongjie (Jimmy) <[e-mail]> wrote:
>> 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.
>> 
> 
> 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 
>>  
>> 
>> Best regards,
>> 
>> Jie
>> 
>>  
>> 
>> Jari
>> 
>>  
>> 
>> -- 
>> Teas-ns-dt mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/teas-ns-dt
> -- 
> Teas-ns-dt mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/teas-ns-dt