Re: [Teas-ns-dt] TEAS-NS-DT Framework Draft Status IETF 108.pptx

[Eric Gray <[e-mail]>]

Jie,

I propose to delete the word “concrete” (I also propose to remove it from the draft as well).  It was included there because saying something like “we will need an NBI” is a lot less “concrete” than it would be to follow that up with “included in section <?>.”

Apparently, that is causing confusion.

I also will remove the parenthetical “(clarify/remove)” from the slides.

To be clear, I do not have an objection to discussing what is meant by “isolation” in the framework draft.  My objection is to repeating the same arguments that have been thoroughly hashed out in discussions about the definition draft.

Since the Framework will not propose specific Service Level Objectives, most of the “same arguments” would be out of scope.

I can imagine a place for a discussion of VPN+ applicability in the Framework draft; perhaps we should simply have a major section that includes “applicability of other IETF work” with a subsection each for both ACTN and VPN+ (though we would more likely refer to it as “enhanced VPN”).

--
Eric

From: Teas-ns-dt <[e-mail]> On Behalf Of Dongjie (Jimmy)
Sent: Friday, July 24, 2020 11:41 AM
To: Eric Gray <eric.gray=[e-mail]>
Cc: [e-mail]
Subject: Re: [Teas-ns-dt] TEAS-NS-DT Framework Draft Status IETF 108.pptx

Hi Eric,

Thanks for your detailed reply.

I am OK with the first one.

As for the second one, I understand you are not motivated to have such discussion in framework draft, while in my memory during a conference call, some members expressed the interests to propose text about isolation also to the framework document. And it would be great if Kiran could provide more information about her comments.

Regarding the reference to VPN+, personally I’m OK with referencing the relevant sections of VPN+ draft in the right place of this document, as this makes the references accurate, and may not be considered as “repetition”. Some additional text to explain the relationship between these two documents might also be helpful, if there is consensus in the design team to add this, I could propose some initial text.

Best regards,
Jie

From: Teas-ns-dt [mailto:[e-mail]] On Behalf Of Eric Gray
Sent: Friday, July 24, 2020 2:46 AM
To: Dongjie (Jimmy) <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]>
Subject: Re: [Teas-ns-dt] TEAS-NS-DT Framework Draft Status IETF 108.pptx


1)      Use of “concrete.”
The fact that the NBI is a new “concrete interface” (using the existing wording) was Kiran’s objection.  😊  It is good enough for the slides, though I should not use this word going forward.  I believe this word was included in the initial strawman proposal and has not previously been objected to (it is the fact that we seem to be saying we’re not going to define new interfaces that Kiran objected to).  My initial proposal would be to remove the word “concrete” and replace “… not intended to be a new set of …” with “… not intended to define new …” – because this is a framework draft and will therefor not define interfaces or technologies.  The text is repeated in both the abstract and introduction – so will need to be fixed in both places.

2)      Adding isolation to, or removing it from, the framework draft.
There was no actual consensus to add isolation text to the framework draft, though I understand why some would have that impression.  What I had proposed was moving the “discussion” text in the definition draft appendix to the framework draft, with others arguing that we should then expand on that in the framework draft.  I have no strong objection to working out some way to be clearer about all of the potential interpretations for “isolation” – as well as explaining why it is that isolation, levels of isolation and types of isolation do not make sense as generic service level objectives and how to translate what customers might want in those terms into SLO parameters that do make sense in a generic transport slice.

That would be a good example of the sort of background information that could be included in a framework draft.

However, at the end of the discussion, there was no agreement to move the text from the definition draft.  Since we have whittled that text down to the bits we can all live with, I am not interested in starting over with this in the framework draft, unless someone else is willing to provide a straw-man proposal for reasonable text to be added and where to add it.

There was certainly no consensus to add text previously removed from the definition draft into the framework draft.

That bullet (in the slides), by the way, comes from one of Kiran’s comments about the following text:
   A Transport Slice could span multiple technologies and multiple
   administrative domains.  Depending on the consumer's requirements, a
   transport slice could be isolated from other, often concurrent
   transport slices in terms of data, control and management planes.

Kiran highlighted the latter part of this paragraph (“… a transport slice could be isolated from other, often concurrent transport slices in terms of data, control and management planes.”)

Kiran’s exact comment was: “In the light of discussions during definitions. This needs some consideration.”  Recalling the discussion she referred to, what I had written as a reply to this (during the meeting), was: “Needs rewording to clarify.  Replace sentence with SLO-related/specific text.”

Replacing text like that (in this example) with SLO-related/specific text is what we did with the definition draft.  I suspect that I will not be able to get entirely away from the existing text in this case, because protection against interference from other slices – in control and management of any specific slice – is essential table stakes and not expressible in terms of SLO parameters – while it is mostly (exclusively?) the data (or user) plane where SLO parameters are more likely to be important.

Kiran also pointed out that we should remove the text (second paragraph after the above) that refers to “degree of isolation.”

Finally, Kiran had wanted to move and change the only other instance in which the framework refers to isolation (in the 4th paragraph of the introduction, on page 3).  The text in that case refers to “logically isolated access [of multiple user groups] to a common network.”  Here we might use “segregated” rather than “isolated.”

Maybe we need to hear from Kiran on what she really meant?

3)      VPN+ references.
Objections to repeated references in IETF documents are often based on the assumption that the reader will read the entire document from start to finish and find these repeated references objectionable.

With Internet Drafts and RFCs, about the only time this really happens is when reviewing the document (frankly, I am glad when it happens in these cases – though I am uncertain this can be relied on).  Most IETF document readers skip around in the document – often really trying to skip directly to the conclusion (I suspect the drama in these documents falls a little flat).

That being the case, repetition is a good thing and – while adding a section that specifically talks about VPN+ applicability might also be a good thing – if you look at my reply to Kiran’s comment on this, you should see that I suggest someone propose reasonable text.  I am not the right person to do that, because my proposal would be to repeat the text in the last paragraph before subsection 3.1 (and I suspect someone would object to the repetition).

--
Eric

From: Dongjie (Jimmy) <[e-mail]<mailto:[e-mail]>>
Sent: Thursday, July 23, 2020 10:59 AM
To: Eric Gray <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
Subject: RE: TEAS-NS-DT Framework Draft Status IETF 108.pptx
Importance: High

Hi Eric,

Thanks for preparing the slides for the presentation.

At a glance here are some quick comments and suggestions about page 4:


1.       The word “concrete” in “a new concrete interface” may note correctly reflect that the NBI interface actually should be abstracted.


2.       Deal with (possibly) vestigial and confusing text related to isolation (clarify/remove)  -- >  My memory is that the DT discussed and agreed that isolation needs to be further discussed in framework document, thus “remove” seems not quite align with our discussion.


3.       Objections to repeated references to VPN+ draft  -- I just noted this comment from Kiran’s review, while this may not be interpreted as an objection, instead it could be “suggestions to have one place to summarize the reference and relationship to VPN+ draft”


Hope this helps.

Best regards,
Jie

From: Teas-ns-dt [mailto:[e-mail]] On Behalf Of Eric Gray
Sent: Thursday, July 23, 2020 10:13 PM
To: [e-mail]<mailto:[e-mail]>
Subject: [Teas-ns-dt] TEAS-NS-DT Framework Draft Status IETF 108.pptx

Currently proposed presentation for next week.  Please send comments to this list…