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

[Eric Gray <[e-mail]>]

Jie, et al,

              I thought I had sent out a modified version to be presented that was different from the version Jie used in making his comments on slide 4.

              I checked, and that was the case (see attached E-Mail).

              One of the changes should deal with any potential issues related to the wording of the bullet about “vestigial” isolation text.  Because the version that Jie suggested changing did not include that change, it may be that his issue with that bullet was dealt with already.

              The revised bullet reads:

     *   “Deal with confusing and (possibly) vestigial text related to isolation”

              The reason for making this change in the ordering of “confusing” and “(possibly) vestigial” text is to avoid giving the impression that the text that was a subject of the comment(s) might be both confusing and vestigial.

              What we had discussed was that some of the text commented on needs clarification, and it is possible that some other text should have been removed (essentially, isolation was misused in at least one place in text that was from before the many discussions we had about what isolation means).

              Hence some of the text on isolation will require (possibly extensive) clarification, while it is possible that the best way to address issues with some other parts of the text is simply to remove it.

              As I had said about the objections to repeated references to the enhanced VPN (VPN+) draft was that I do not see repeated references as an issue but I think we should be willing to consider any text proposals that might consolidate discussion about that draft.

              Note that – assuming someone actually proposes text (I believe Jie indicated he would) – the existing references will likely remain, but will be changed to refer to the section that we decide to include where there would be some consolidated discussion of the enhanced VPN draft.  That section will also need to explicitly refer to the enhanced VPN draft itself, so (at the end of the day) we would end up with more references to that draft (both direct and indirect), rather than less.

              Also note that – it is likely that we may well decide not to include such a section, because comparing the inclusion of text for ACTN is different from similar inclusion of any detailed discussion of the enhanced VPN draft because the ACTN reference is an RFC and the enhanced VPN draft yet remains a draft (that was only reposted recently with extensive changes as a -03 WG draft after having gone through 7 versions as an individual draft) – and is therefore very likely to change (probably repeatedly) before publication.

              Based on the discussions we have had in the design team, it would very likely be a bad idea, for example, to use such an extra section as a way to repeat a lot of the text in the enhanced VPN draft (on isolation, for example) that we have already seen extensive objections to in the design team, and which seems to change a lot from one version to the next in the enhanced VPN draft.

              The best way to avoid trickle-down perturbance as a result would be to keep the references to the enhanced VPN draft at a high level.  And if we were going to do that, it is not clear how much value having a new section to provide the same high-level references (we already include) will provide.

              So, I am very reluctant to assume that we will actually be including any such section in the very near future, at least until I see proposals to add specific text and some indication that the design team will not be spending several months whittling that down to text we can all agree to.

--
Eric

From: Dongjie (Jimmy) <[e-mail]>
Sent: Monday, July 27, 2020 12:36 PM
To: Eric Gray <[e-mail]>om>; Eric Gray <eric.gray=[e-mail]>
Cc: [e-mail]
Subject: RE: TEAS-NS-DT Framework Draft Status IETF 108.pptx
Importance: High

Hi Eric,

Thanks for the update, please see some replies inline, and one update of page 4 is attached for review:

From: Eric Gray [mailto:[e-mail]]
Sent: Monday, July 27, 2020 9:35 PM
To: Dongjie (Jimmy) <[e-mail]<mailto:[e-mail]>>; Eric Gray <eric.gray=[e-mail]<mailto:eric.gray=[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]>
Subject: RE: TEAS-NS-DT Framework Draft Status IETF 108.pptx

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 <?>.”

[Jie] OK, thanks.

Apparently, that is causing confusion.

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

[Jie] Thanks, this could reflect the DT’s discussion better, although the words “(possibly) vestigial” may not be quite necessary…

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.

[Jie] Understood.

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”).

[Jie] In the bullet about VPN+, I’d suggest to change the “objections to” to “deal with” to match with Kiran’s editorial nit comment, and also align with other bullets (begin with verb). A section as you suggested could be helpful, and it can be discussed further in the design team.

Hope this helps to improve the slides.

Best regards,
Jie

--
Eric

From: Teas-ns-dt <[e-mail]<mailto:[e-mail]>> On Behalf Of Dongjie (Jimmy)
Sent: Friday, July 24, 2020 11:41 AM
To: Eric Gray <eric.gray=[e-mail]<mailto:eric.gray=[e-mail]>>
Cc: [e-mail]<mailto:[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…

--- Begin Message ---

Modified as discussed...

--- End Message ---