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

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
On Oct 17, 2019, 7:36 AM -0700, Jari Arkko <jari.arkko=40ericsson.com@dmarc.ietf.org>, wrote:
> 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.
[jeff] we are in agreement here
>
> 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.
[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 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.
[jeff] agreed, good progress on the discussion
>
> Jari
>
> --
> Teas-ns-dt mailing list
> Teas-ns-dt@ietf.org
> https://www.ietf.org/mailman/listinfo/teas-ns-dt