Re: [Teas] I-D Action: draft-nsdt-teas-transport-slice-definition-03.txt

Greg Mirsky <gregimirsky@gmail.com> Thu, 13 August 2020 20:49 UTC

Return-Path: <gregimirsky@gmail.com>
X-Original-To: teas@ietfa.amsl.com
Delivered-To: teas@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35DF93A03ED; Thu, 13 Aug 2020 13:49:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AUhn405JaY9J; Thu, 13 Aug 2020 13:49:19 -0700 (PDT)
Received: from mail-lf1-x130.google.com (mail-lf1-x130.google.com [IPv6:2a00:1450:4864:20::130]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 06F1E3A03EE; Thu, 13 Aug 2020 13:48:53 -0700 (PDT)
Received: by mail-lf1-x130.google.com with SMTP id b11so3732385lfe.10; Thu, 13 Aug 2020 13:48:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=HgSz6puRgC4j98HH7t/GohMderV0WVGbLVOxJ+5UH3E=; b=edhvUvcdFVz3YcpK1S3sHQnrrLBABJvuXIRTAvk5DAkwmNzsa0UYiPsP1WQ8LOuGlR kRqD8/syXD4njQlqePOeTMQsAB0AosOD/NvBUhpBXDfk8iRk/3bV88b/cykcnc2kooeI LS+wLssDgce6nVXM7eL8R9EFpwDhcSrvvDhPCd+yGRwHvT8CMxqgS4I9MJFv7JMzQSY1 wbsSdihmR+5ZlZmHoDorrTPXetfbrd9yvpcGkO+nqpsSssV4KIriFhu2Y8avSyTjOugk NlLBdO2fLc2v23nlKMcvSB13QgieKr8DjgwaNxqwmZvFxMp2G7QnunsaCs0zl3peJQ3+ HhNw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=HgSz6puRgC4j98HH7t/GohMderV0WVGbLVOxJ+5UH3E=; b=h73wtrw7eNdgKUY/lc9wo6CjSJHOL2ZiRnrI5BHptRQ0LrnqgIbGUyGC5m5sUHpXCU O/z6Ym/T5AuBzXJwUC0MbQnBWh/LRDv/TYLb3wMWgt0o6POQRZWRQ6nWL1mqlfIBcvyC X3Lrcl9WAQHcxDSP1WgWxq6/M27OtaY8tjx+ExFvr8xAxNUtISnvt9NupV6eQuPG2Uui 3kL71kNCOm0nKAEm8bQ36vcS+5zF03UW/2JTb9ZUhdge8gHRWKdjxPuoBRMUdurRSIHj +uR1dl5zy29E+b2bbEa2QmQC6jquU7U8LGXzG0OoBSpwWCIEDkH2z20/t7QsRJpedGCR Y4Mw==
X-Gm-Message-State: AOAM530dl4CyLQEF/uNNt4q04DVbb3EfGpKys54yrO+O4l0pL8lxS94T O+t0vtw9HI3I5E5r82lUjluc/tZOtJq+HSsbd8ciLg==
X-Google-Smtp-Source: ABdhPJyAZfXnI1w/StMMbwRKobM2cOPrx2M+5ddW30sg7YQpNsLhCiYqEVyirqrvQvN3EvZpZkl5moTUMRrieU/A/hc=
X-Received: by 2002:a05:6512:36c2:: with SMTP id e2mr3016280lfs.98.1597351731814; Thu, 13 Aug 2020 13:48:51 -0700 (PDT)
MIME-Version: 1.0
References: <159460858327.31249.6774312592426516405@ietfa.amsl.com> <a671ad62-65ea-134f-7855-ee3008539e0b@joelhalpern.com> <BYAPR13MB243702009EE457AE8F9415F5D97B0@BYAPR13MB2437.namprd13.prod.outlook.com> <37b6cbcc-5e1e-f4b1-b914-6759f74d59bc@joelhalpern.com>
In-Reply-To: <37b6cbcc-5e1e-f4b1-b914-6759f74d59bc@joelhalpern.com>
From: Greg Mirsky <gregimirsky@gmail.com>
Date: Thu, 13 Aug 2020 13:48:38 -0700
Message-ID: <CA+RyBmVF-5Qs7DGVkLybNt1LfbtDWp2ua0avQupdaBatVzN59Q@mail.gmail.com>
To: "Joel M. Halpern" <jmh@joelhalpern.com>
Cc: Kiran Makhijani <kiranm@futurewei.com>, "teas@ietf.org" <teas@ietf.org>, "teas-ns-dt@ietf.org" <teas-ns-dt@ietf.org>, draft-mirsky-ippm-epm@ietf.org
Content-Type: multipart/alternative; boundary="0000000000008e63b305acc86ec0"
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas/YiEk5xkeNMngbQS49W9zx8hBQLY>
Subject: Re: [Teas] I-D Action: draft-nsdt-teas-transport-slice-definition-03.txt
X-BeenThere: teas@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Traffic Engineering Architecture and Signaling working group discussion list <teas.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/teas>, <mailto:teas-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/teas/>
List-Post: <mailto:teas@ietf.org>
List-Help: <mailto:teas-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/teas>, <mailto:teas-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 13 Aug 2020 20:49:24 -0000

Dear Joel, Kiran, et al.,
I want to bring to your attention a draft that we've submitted right before
IETF-108 - Error Performance Measurement in Packet-switched Networks
<https://datatracker.ietf.org/doc/draft-mirsky-ippm-epm/>. As part of
defining metrics of EPM, the document specifies the method to detect and
measure availability and unavailability. I hope you'll be interested and
much appreciate your comments, including the IPPM WG list <ippm@ietf.org>rg>.

Regards,
Greg

On Mon, Jul 20, 2020 at 8:01 PM Joel M. Halpern <jmh@joelhalpern.com> wrote:

> Comments in-line, marked <jmh></jmh>.
> I still have some substantive concerns.
> Yours,
> Joel
>
> On 7/20/2020 6:53 PM, Kiran Makhijani wrote:
> > Hi Joel,
> > My apologies, I could not reply sooner. Many thanks for paying attention
> to the document and reviewing it.
> > Please see inline.
> > Cheers
> > Kiran
> >
> >> -----Original Message-----
> >> From: Teas <teas-bounces@ietf.org> On Behalf Of Joel Halpern
> >> Sent: Sunday, July 12, 2020 9:00 PM
> >> To: teas@ietf.org
> >> Subject: Re: [Teas] I-D Action:
> draft-nsdt-teas-transport-slice-definition-03.txt
> >>
> >> My thanks to the design team for the update to this document.  It is
> much
> >> improved.
> >>
> >> I a  unable to understand the third paragraph of section 4.1.2.  I do
> not know
> >> what maximum occupancy refers to.  It seems to be talking about some
> kind of
> >> notion of objectives applying to subsets of traffic within a slice.
> But I can't tell.
> >>
> > [KM] Maximum occupancy implies that when transport slice will 'max out'
> or overall limit on the slice after which it becomes best effort (may not
> meet its SLOs). For example, a slice can support 20 flows each with 10 Mbps
> data rate but 21st flow may or may not get desired bandwidth and it is not
> an SLO violation. There could be different kinds of limits using objectives
> such as number of flows, total bandwidth, or may also be other things that
> a user could ask for such as, max number of addresses, nf instances, etc
> (this part is coming from NF related resources). This is important for both
> network operators and transport slice controllers to plan resource
> allocations better.
>
> <jmh>I am having real trouble understanding what you want to accomplish
> with this maximum occupancy.  The example you give is 20 flows of 10
> Mbps each.  However, there is no parameter given taht is bps/flow.  And
> I would hope that there would not be.  How the customer divides his
> bandwidth up among his own traffic is up to him.  Bandwidth as a total
> does not have an "occupancy".  The service is guarnateed up to the
> stated bandwidth.  If you can justify a "number of flows" SLO, then we
> can have that, although from where I sit I can not see why any slice
> service would operate in those terms.  Many years experience with
> Internet Scaling has taught us that core scaling that is based on number
> of flows will fail. </jmh>
>
> >
> >> Appendix A.1 is labeled as discussion, and as such appears to be trying
> to be
> >> informative rather than normative.  However, the last paragraph of
> introduces
> >> things a customer may ask for (i.e. SLOs) that are not described in the
> rest of
> >> the document, and do not actually seem to me to be appropriate.  I
> wowuld ask
> >> that the last paragraph of section A.1 be stricken.
> >
> > [KM] Actually, we are saying these are 'not' SLOs and the customer may
> have specific asks (optionally).  Examples in this paragraph help in
> clarifying meanings of isolations, linking with VPN+  and may also be input
> to NBI. Considering this could be our top-level document, we/I prefer to
> provide some linkage to later documents. An upshot of doing this is we will
> not have to repeat the discussions we had - since it is already agreed upon
> and can be referred to.
>
> <jmh> Given the way the document defines SLOs, if these are parameters
> the customer can request, and may want to monitor, then they are SLOs.
> If they are SLOs, they should not be hidden in an appendix.
> And if this is for framing other discussion, I would have thought that
> was the job of the framework document, not the definitions document.
> And no, I do not think the examples help clarify the meaning of
> "isolation".  And no, I do not agree with the text.  So no, it is not
> "already agreed". </jmh>
>
> >>
> >> Some minor comments:
> >>
> >> At one point the SLA is defined (I believe reasonably)as the contract
> 5that
> >> describes the SLOs with the consequences for missing them.  Then in
> section
> >> 4.1 it says "all SLOs combine to form the SLA".  Believe you mean "form
> the
> >> objective portion of the SLA"  or "contribute to the SLA"
> >> or something, since the contractual and consequence aspects of the SLA
> are
> >> outside of the SLOs?
> > [KM] Yes, that is correct. We should add this statement ( contractual
> aspects of the SLAS are outside the scope) to improve the text.
> >>
> >> Given that availability is defined in terms of the other SLOs (quite
> >> reasonable) and that some of those may not be directly measurable), it
> seems
> >> that availability should itself be considered indirectly measurable?
> >>
> > [KM] Since we define it as "uptime to total_time", it is measurable,
> however that may be.
> <jmh> Since I consider this minor, I will not insist on it.  But as far
> as I can tell, you can't measure uptime.  You measure whether other SLO
> parameters are met, and then calculate what portion of the time any of
> them were out of spec.  That sounds like an indirect measurement to
> me.</jmh>
>
> >
> >> nit - Given that the earlier text says that this is only an initial
> list, there is no
> >> need to include a bullet in the aspects that says "Other objectives
> could be
> >> specified".  It is true.  But has already been stated above.
> >
> > [KM] :-) It is there to separate measurable vs non-measurable asks. If
> the nsdt agrees, I don't mind removing the sub-heading.
> >
> >> In section 4.2 on transport service endpoints, the text seems to say
> that an
> >> endpoint has a specific kind of connectivity (P2P, P2MP, ...).
> >> It seems perfectly valid for a single TSE to be using both P2P and P2MP
> >> communication.  It seems rather odd to have to consider it to be two
> TSEs.
> >>  From later text, it is the slice, not the endpoint, which as a
> particular
> >> connectivity type.
> >
> > [KM] Agree.  It is not supposed to imply 2 TSEs. If I understood
> correctly, you think 'MP2MP' does not make sense. Am I right? If yes, then
> at least I was thinking of direction of the traffic flow. i.e., traffic
> could flow out to different TSEs or flow in from different TSE sources. We
> will discuss how to improve the text - add explanation or remove MP2MP.
> <jmh>I was not commenting on whether there is an MP2MP service.  I was
> commenting on the fact that the text seems to assign types to the TSEs
> rather than to the slice.  Given that you agree that one should not need
> two TSEs, please remove the text that says that TSEs have a type (Pt2Pt,
> Pt2MPT, ...) </jmh>
>
> >
> >>
> >> I wonder if the "Transport Slice Realization endpoint" is useful?
> Given that
> >> many things are in both the sample TSE list and the sample TSRE list,
> it is going
> >> to be hard to tell them apart.  And as far as I can tell, the TSRE is
> internal to the
> >> transport, and therefore outside the scope of this document?  The
> >> differentiation in the diagram that follows the description does not
> seem to
> >> line up with the description, and leaves me more confused.
> > [KM] Yes, it is internal to transport. The reason we have them is to
> highlight the 1:N mappings. There may be more than one TSRE mapped to one
> TSE. Todo: need to think about improving the figure.
>
> <jmh> I understand that things are realized.  And the question of how
> resources are used internally is internal.  I don't see the value in
> discussing it in this document.  I do not think the definition of TSRE
> will be used in any of the followon work. </jmh>
>
> >>
> >> Yours,
> >> Joel
> >>
> >> On 7/12/2020 10:49 PM, internet-drafts@ietf.org wrote:
> >>>
> >>> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> >>>
> >>>
> >>>           Title           : IETF Definition of Transport Slice
> >>>           Authors         : Reza Rokui
> >>>                             Shunsuke Homma
> >>>                             Kiran Makhijani
> >>>                             Luis M. Contreras
> >>>                             Jeff Tantsura
> >>>     Filename        : draft-nsdt-teas-transport-slice-definition-03.txt
> >>>     Pages           : 21
> >>>     Date            : 2020-07-12
> >>>
> >>> Abstract:
> >>>      This document describes the definition of a slice in the transport
> >>>      networks and its characteristics.  The purpose here is to bring
> >>>      clarity and a common understanding of the transport slice concept
> and
> >>>      describe related terms and their meaning.  It explains how
> transport
> >>>      slices can be used in combination with end to end network slices,
> or
> >>>      independently.
> >>>
> >>>
> >>> The IETF datatracker status page for this draft is:
> >>> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdata
> >>> tracker.ietf.org%2Fdoc%2Fdraft-nsdt-teas-transport-slice-definition%2F
> >>>
> >> &amp;data=02%7C01%7Ckiranm%40futurewei.com%7C7b2262bf8d9b41549c
> >> af08d82
> >>>
> >> 6e13aab%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637302096
> >> 09577396
> >>>
> >> 3&amp;sdata=7buYe3eJIHKFpKR09vulM9iebHux1y5ZS%2B8lDucs19A%3D&am
> >> p;reser
> >>> ved=0
> >>>
> >>> There are also htmlized versions available at:
> >>> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftool
> >>> s.ietf.org%2Fhtml%2Fdraft-nsdt-teas-transport-slice-definition-03&amp;
> >>>
> >> data=02%7C01%7Ckiranm%40futurewei.com%7C7b2262bf8d9b41549caf08d
> >> 826e13a
> >>>
> >> ab%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C63730209609577
> >> 3963&amp
> >>>
> >> ;sdata=%2BDoN%2Fj%2BsIG4SidwevIEKt%2BAlEBSl5mGY%2BrV8bOKruxY%3D
> >> &amp;re
> >>> served=0
> >>> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdata
> >>> tracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-nsdt-teas-transport-slice-defini
> >>> tion-
> >> 03&amp;data=02%7C01%7Ckiranm%40futurewei.com%7C7b2262bf8d9b415
> >> 49c
> >>>
> >> af08d826e13aab%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637
> >> 3020960
> >>>
> >> 95773963&amp;sdata=rROaEyLnsvX3i83zAt3DKHD822SQ9cZ4vw05CZzGKYk%
> >> 3D&amp;
> >>> reserved=0
> >>>
> >>> A diff from the previous version is available at:
> >>>
> >> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.
> >>> ietf.org%2Frfcdiff%3Furl2%3Ddraft-nsdt-teas-transport-slice-definition
> >>> -
> >> 03&amp;data=02%7C01%7Ckiranm%40futurewei.com%7C7b2262bf8d9b415
> >> 49caf08
> >>>
> >> d826e13aab%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637302
> >> 09609577
> >>>
> >> 3963&amp;sdata=VDTj6H50YyxvSKeUxXdDTxUmlhVb34%2FKkRIXMWd4W%2
> >> BY%3D&amp;
> >>> reserved=0
> >>>
> >>>
> >>> Please note that it may take a couple of minutes from the time of
> >>> submission until the htmlized version and diff are available at
> tools.ietf.org.
> >>>
> >>> Internet-Drafts are also available by anonymous FTP at:
> >>> https://nam11.safelinks.protection.outlook.com/?url=ftp%3A%2F%2Fftp.ie
> >>> tf.org%2Finternet-
> >> drafts%2F&amp;data=02%7C01%7Ckiranm%40futurewei.com%
> >>>
> >> 7C7b2262bf8d9b41549caf08d826e13aab%7C0fee8ff2a3b240189c753a1d559
> >> 1fedc%
> >>>
> >> 7C1%7C0%7C637302096095783957&amp;sdata=P0ZsXdbhq7q%2BbaTOWOK
> >> w8kXUEQQLn
> >>> W4CILvj3D87Ghg%3D&amp;reserved=0
> >>>
> >>>
> >>> _______________________________________________
> >>> I-D-Announce mailing list
> >>> I-D-Announce@ietf.org
> >>>
> >> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.
> >>> ietf.org%2Fmailman%2Flistinfo%2Fi-d-
> >> announce&amp;data=02%7C01%7Ckiranm
> >>>
> >> %40futurewei.com%7C7b2262bf8d9b41549caf08d826e13aab%7C0fee8ff2a3b
> >> 24018
> >>>
> >> 9c753a1d5591fedc%7C1%7C0%7C637302096095783957&amp;sdata=UKy30l
> >> dThBDSB%
> >>> 2F9513KCraQ4ODcTtq%2F%2FDfHSwi8Y6Nk%3D&amp;reserved=0
> >>> Internet-Draft directories:
> >>>
> >> https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.i
> >>>
> >> etf.org%2Fshadow.html&amp;data=02%7C01%7Ckiranm%40futurewei.com%
> >> 7C7b22
> >>>
> >> 62bf8d9b41549caf08d826e13aab%7C0fee8ff2a3b240189c753a1d5591fedc%
> >> 7C1%7C
> >>>
> >> 0%7C637302096095783957&amp;sdata=c5sC8mBqP2lTaDxRiqMmVWXQVfBi
> >> 0SGf1Nn1A
> >>> 5Tiekg%3D&amp;reserved=0 or
> >>> https://nam11.safelinks.protection.outlook.com/?url=ftp%3A%2F%2Fftp.ie
> >>> tf.org%2Fietf%2F1shadow-
> >> sites.txt&amp;data=02%7C01%7Ckiranm%40futurewe
> >>>
> >> i.com%7C7b2262bf8d9b41549caf08d826e13aab%7C0fee8ff2a3b240189c753
> >> a1d559
> >>>
> >> 1fedc%7C1%7C0%7C637302096095783957&amp;sdata=7kPSpNmxVrwrE6by
> >> 55jlY%2B5
> >>> yBSHeMXgwZhPYM%2F9yj3Y%3D&amp;reserved=0
> >>>
> >>
> >> _______________________________________________
> >> Teas mailing list
> >> Teas@ietf.org
> >> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.i
> >> etf.org%2Fmailman%2Flistinfo%2Fteas&amp;data=02%7C01%7Ckiranm%40fu
> >> turewei.com%7C7b2262bf8d9b41549caf08d826e13aab%7C0fee8ff2a3b24018
> >> 9c753a1d5591fedc%7C1%7C0%7C637302096095783957&amp;sdata=3q4fLZ
> >> 2BdNuYfXsMHmGd%2Be0RO%2BBzxvi4%2FzvL0LCSKPM%3D&amp;reserved=
> >> 0
>
> _______________________________________________
> Teas mailing list
> Teas@ietf.org
> https://www.ietf.org/mailman/listinfo/teas
>