Subject: [Teas-ns-dt] Models Discussion - specifically, SLO groups, in the current model draft

From: Eric Gray <[email-masked]>
Date: Mon, 20 Apr 2020 16:55:16 +0000

Fellow design team members, et al:

I have a number of issues with both the draft, and the discussions we've had about it, but I would prefer to use this thread to focus on the issues with Transport Slice "End-Points" (or, perhaps, Transport Slice Members.  I have already tried to start a discussion about the issues with "SLO Group" as discussed in today's meeting and in the draft.

Again, AFAICT, we've had very little discussion about Modeling work on the mailing list - beyond simple announcements about new versions of Bo's draft, and a few (mostly unanswered) comments about the draft.

And, again, I have looked at the latest version of the model draft, and I was present during the discussion of this draft today, and the discussion of the previous draft last Thursday.

In today's discussion, we talked briefly about TS end-points.  A number of examples were given, and Bo said that we had likely reached some agreement of what we mean by a transport slice end-point.  I would like to have a better understanding of what that agreement is, because I did not see any such agreement.

Speaking as someone who has been to this rodeo a few times, I think what we really need to do is define an abstract interface that exists between a transport slice realization and a transport slice user.

It is not clear to me that we have even agreed whether or not we want to define that abstract interface in a way that would mean it exists "on the wire" (the link between a TS and its user) or on a node at one end of the "wire" or the other (or both ends).

If we do think we have such an agreement, I would prefer to see it very clearly spelled out, before  signing off on it.

--
Eric

--
Eric

---

From: "Wubo (lana)" <[email-masked]>
Date: Wed, 22 Apr 2020 06:36:38 +0000

Hi Eric,

I agree what I said at the meeting is confusing and there is no agreement on the definition of the TS End point yet.
Thank you for setting up the thread for the discussion. I think endpoint definition is a key part of the NBI model.

Please see the reply inline below.

Thanks,
Bo

发件人: Teas-ns-dt [mailto:[email-masked]] 代表 Eric Gray
发送时间: 2020年4月21日 0:55
收件人: [email-masked]
主题: [Teas-ns-dt] Models Discussion - specifically, SLO groups, in the current model draft

I have a number of issues with both the draft, and the discussions we’ve had about it, but I would prefer to use this thread to focus on the issues with Transport Slice “End-Points” (or, perhaps, Transport Slice Members.  I have already tried to start a discussion about the issues with “SLO Group” as discussed in today’s meeting and in the draft.

Again, AFAICT, we’ve had very little discussion about Modeling work on the mailing list – beyond simple announcements about new versions of Bo’s draft, and a few (mostly unanswered) comments about the draft.

In today’s discussion, we talked briefly about TS end-points.  A number of examples were given, and Bo said that we had likely reached some agreement of what we mean by a transport slice end-point.  I would like to have a better understanding of what that agreement is, because I did not see any such agreement.

Speaking as someone who has been to this rodeo a few times, I think what we really need to do is define an abstract interface that exists between a transport slice realization and a transport slice user..

It is not clear to me that we have even agreed whether or not we want to define that abstract interface in a way that would mean it exists “on the wire” (the link between a TS and its user) or on a node at one end of the “wire” or the other (or both ends).
[Bo] The TS Endpoint definition in the draft is a logical identifier, which could be existed on either end of the “wire”. So it means both ends, and ‘node-id, tp-id and ts-traffic-criteria’
are used to specify, e.g. node-id could be CE node or PE node, the higher system and TSC need to agree.
If you think that the figure, EP “on the wire”, is misleading, we will correct it in the next revision.

--
Eric

--
Eric