[Teas] Thoughts about draft-nsdt-teas-ietf-network-slice-definition and isolation
Adrian Farrel <adrian@olddog.co.uk> Mon, 09 November 2020 19:25 UTC
Return-Path: <adrian@olddog.co.uk>
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 146F83A12CF; Mon, 9 Nov 2020 11:25:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level:
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no
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 T2yNb1S70L4o; Mon, 9 Nov 2020 11:25:27 -0800 (PST)
Received: from mta7.iomartmail.com (mta7.iomartmail.com [62.128.193.157]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D46BA3A0985; Mon, 9 Nov 2020 11:25:22 -0800 (PST)
Received: from vs1.iomartmail.com (vs1.iomartmail.com [10.12.10.121]) by mta7.iomartmail.com (8.14.4/8.14.4) with ESMTP id 0A9JPKur006117; Mon, 9 Nov 2020 19:25:20 GMT
Received: from vs1.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 330D72203B; Mon, 9 Nov 2020 19:25:20 +0000 (GMT)
Received: from asmtp2.iomartmail.com (unknown [10.12.10.249]) by vs1.iomartmail.com (Postfix) with ESMTPS id 1D9172203A; Mon, 9 Nov 2020 19:25:20 +0000 (GMT)
Received: from LAPTOPK7AS653V ([87.113.103.132]) (authenticated bits=0) by asmtp2.iomartmail.com (8.14.4/8.14.4) with ESMTP id 0A9JPJ6u026863 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 9 Nov 2020 19:25:19 GMT
Reply-To: adrian@olddog.co.uk
From: Adrian Farrel <adrian@olddog.co.uk>
To: teas@ietf.org
Cc: draft-nsdt-teas-ietf-network-slice-definition@ietf.org
Date: Mon, 09 Nov 2020 19:25:18 -0000
Organization: Old Dog Consulting
Message-ID: <059e01d6b6ce$0f74a830$2e5df890$@olddog.co.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 16.0
Thread-Index: Ada2zgXwmf5+OFnxRYqFnccOiBIQNA==
Content-Language: en-gb
X-Originating-IP: 87.113.103.132
X-Thinkmail-Auth: adrian@olddog.co.uk
X-TM-AS-GCONF: 00
X-TM-AS-Product-Ver: IMSVA-9.0.0.1623-8.2.0.1013-25778.002
X-TM-AS-Result: No--12.037-10.0-31-10
X-imss-scan-details: No--12.037-10.0-31-10
X-TMASE-Version: IMSVA-9.0.0.1623-8.2.1013-25778.002
X-TMASE-Result: 10--12.037400-10.000000
X-TMASE-MatchedRID: 9/TK1B57K5Uaf3p8Lo2lejjNGpWCIvfT+IfriO3cV8RYbPLopoBzQhG1 oZ5GLaI6p6/UNwZiQheMMO8Rav5LAf85GCR7+GthzfqlpbtmcWiRAgbvhPsYZnt4azXv2W1Zyjk 3nUNNTCOyr5yM4sIBNAixHRxPbcjQv6f6ZfKrj12Cr5xa2StlIfy3gqNDWibmRjNrjV0arFL1WU YGMIOdyMP6JzL63XJ9N9G3aZxhTqCNLlUtyxEd4pi/JtCbSi1TVBDQSDMig9GqvcIF1TcLYJ0lh LiscuITwoYdoBXfXuCQ7V25qORQ/FINdcWc2YUwgYFDtM3wGBpOxMIe1e/Q+uG3yXbqLuSXEj34 Bad2yLy/zxbgJNKcUPe9/6CDBX917OZ6UkKeApBJ3Nmzw52/qhQEj9RZgbsWfgEkkNnfgxMnDf+ 57mBigQvOoXG9wbeDa02rDzfoxJOKv8OoSrxC1g/XiPxsF75mWNbBpQ++I1nYxn9UZJpcf/eHaP JtCROSVBBgX6cCfGNsOVVC9GwpO2/GIjRDG0ew40jcxy3aXNplu8AJBkPNMAp2l9r0rJf/zTfBL 7TcF3hup1MD8Gu7VTpAl2xjT0UHvfVGskJ98+g+NrfDUTEXxOPWyqHbi6tBoGn9Pl1KzZOZI53P KmUqN0Zu8mjmYfDdb+8anoKmoxH3uvD+1Bkl7eIfK/Jd5eHmAamcV4T1THL8kFwgcyoo4SMIN1X fvZow+b+Z1D4sFD0lDmW2cHTiB56rJwVlCc0LvOAv94sAIMS36rOEul8OH1ORLtWYh2UoMFddv+ pLbrcjSmW2ycHZeGJwCsb/Z8alTX7PJ/OU3vL+xOhjarOnHis3zPQeiEbe+gtHj7OwNO2+IjsEE OIzYn9IDmLPtd2SkElkgidlDwSJWivaEtY6y2rpHL9QI70f
X-TMASE-SNAP-Result: 1.821001.0001-0-1-12:0,22:0,33:0,34:0-0
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas/_BIYUFEvHmiUlkJN8dz17yWcYUU>
Subject: [Teas] Thoughts about draft-nsdt-teas-ietf-network-slice-definition and isolation
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: Mon, 09 Nov 2020 19:25:30 -0000
Hi, I'm not sure where the right place to discuss this document is. Since it replaces the previous terminology document, and since that was proposed for adoption on the TEAS list, I think this is probably the right place (feel free to redirect me). I'd like to focus this email just on Section 9 - the text on isolation. I suspect that this is the largest remaining obstacle to WG adoption. Firstly, we have to recall that this is a terminology document, not a broader architecture. Therefore we should aim to reduce the text to clear and simple definitions: further text belongs in some other document such as the framework draft or a focus-specific document that describes some facet in detail. So I guess I agree with the Editor's statement at the top of Section 9... > Editor's note: This content is a work in progress. The section on > isolation is too descriptive. A way to reduce this would be... == Section 9 == OLD An IETF Network Slice consumer may request, that the IETF Network Slice delivered to them is isolated from any other network slices of services delivered to any other customers. It is expected that the changes to the other network slices of services do not have any negative impact on the delivery of the IETF Network Slice. In a more general sense, isolation can be classified in the following ways: Traffic Separation: Traffic of one network slice should not be subjected to policies and forwarding rules of other network slices. Interference Avoidance: Changes in other network slices should not impact to the SLOs of the network slice. Here the changes in other network slice may include the changes in connectivity, traffic volume, traffic pattern, etc. Service Assurance: In case service degradation is unacceptable due to unpredictable network situations producing service degradation (e.g., major congestion events, etc.), explicit reservation of resources in the network maybe requested for a reduces set IETF network slices. NEW An IETF Network Slice consumer may request, that the IETF Network Slice delivered to them is isolated from any other network slices of services delivered to any other customers. It is expected that the changes to the other network slices of services do not have any negative impact on the delivery of the IETF Network Slice. END In making this change I'd note that while these three principles are an important part of the discussion of isolation they are out of context here. Traffic separation is a feature of how isolation may be achieved, but it is not something that a consumer can or should specifically ask for: they have no way of measuring it and, indeed, since they don't know the purpose of policies and forwarding rules within an operator's network they shouldn't ask for control over them. Interference avoidance is a fine goal for a consumer to ask for, but you already have this captured in the preceding paragraph. Service assurance seems to capture two things: that the consumer may wish for protection of their service in the event of network failure (that's not really an isolation thing) and that a way to protect against failure situations is to reserve resources (that's not necessarily an isolation thing, and is certainly a question of realisation). == Section 9.1 == I think that this section is a little over-stated. Maybe: OLD Isolation is an important requirement of IETF network slices for services like critical services, emergencies, etc. A consumer may express this request through the description of SLOs. NEW Isolation may be an important requirement of IETF network slices for some critical services. A consumer may express this request as an SLO. END == Section 9.2 == While I think there is value in having this section to note that there is a concept of isolation in the realisation of a network slice, I don't think you should get into details with examples etc. If you want to talk about how realisation of network slices works, that should be in another document. Thus, I think you could drop the whole of the fist paragraph: it just duplicates some of the ideas in the second paragraph which says it more clearly. Furthermore, the final paragraph in the section seems to be all about realisation. I think you should drop it partly because it is technically suspect (an L3VPN does not achieve traffic separation in the network, that is exactly the point of an L3VPN), but mainly because it is a discussion of the details and technologies of realisation. == Section 9.3 == I tend to think that there will be value in a full and careful discussion of how IETF network slices meet the requirements of 3GPP transport slices, but I don't think it should be in this document. Thus, I agree with the editor's note that the section should be removed. Maybe interested parties could start a new document "Applicability of IETF Network Slices to 3GPP Transport Slices." Thanks, Adrian
- [Teas] Thoughts about draft-nsdt-teas-ietf-networ… Adrian Farrel
- Re: [Teas] Thoughts about draft-nsdt-teas-ietf-ne… Joel M. Halpern
- Re: [Teas] Thoughts about draft-nsdt-teas-ietf-ne… Adrian Farrel
- Re: [Teas] Thoughts about draft-nsdt-teas-ietf-ne… Jeff Tantsura
- Re: [Teas] Thoughts about draft-nsdt-teas-ietf-ne… Jeff Tantsura
- Re: [Teas] Thoughts about draft-nsdt-teas-ietf-ne… Joel Halpern Direct
- Re: [Teas] Thoughts about draft-nsdt-teas-ietf-ne… Jeff Tantsura
- Re: [Teas] Thoughts about draft-nsdt-teas-ietf-ne… Joel Halpern Direct
- Re: [Teas] Thoughts about draft-nsdt-teas-ietf-ne… Jari Arkko
- Re: [Teas] Thoughts about draft-nsdt-teas-ietf-ne… Stewart Bryant
- Re: [Teas] Thoughts about draft-nsdt-teas-ietf-ne… Joel Halpern Direct
- Re: [Teas] Thoughts about draft-nsdt-teas-ietf-ne… Stewart Bryant
- Re: [Teas] Thoughts about draft-nsdt-teas-ietf-ne… Joel M. Halpern
- Re: [Teas] Thoughts about draft-nsdt-teas-ietf-ne… Stewart Bryant