Re: [Teas] Thoughts about draft-nsdt-teas-ietf-network-slice-definition and isolation

Jeff Tantsura <> Mon, 09 November 2020 22:45 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5BB333A133D; Mon, 9 Nov 2020 14:45:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.097
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: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id fBGjv9lMy_Tt; Mon, 9 Nov 2020 14:45:53 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::52e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 215B23A14B3; Mon, 9 Nov 2020 14:45:53 -0800 (PST)
Received: by with SMTP id e21so8391216pgr.11; Mon, 09 Nov 2020 14:45:53 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=date:from:to:cc:message-id:in-reply-to:references:subject :mime-version; bh=TWhPruCPVW0f4TgvRaCnLopTdbascnEnWhorx17Z8/4=; b=e5+Xab9oZjtaQ3yDGa5ZYtoFzf6TcOW7whAqn14EU84Fpo2+ZX5zNVJZ6LVcOPimrl hhzE+N7XOw67fxaM+vm/Ig01drKlIk0Ka0dehluxJ9s0NruEfwE5FN00l+eFA6whQ2vu fiB8EWNVV+j0Xm++SpHzF/S0r2XpIlaGB1lfqmVHDtekl7jM9gTS5spsAtjuK+xiNT/A o/sMTBjWST1xzLqt7EA4uagK9hdsqD9hm1qJUPGV1IiFHGslYJDKzHh3py+tOYDa9oI4 uJObFSZRmcwfw1IaeRrxBPf36iHy5jRVVhDPGMQy+aj0fRB3Fo5EEZ/wBR+7x4XI3dfJ /zwQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:date:from:to:cc:message-id:in-reply-to :references:subject:mime-version; bh=TWhPruCPVW0f4TgvRaCnLopTdbascnEnWhorx17Z8/4=; b=t2cZlcvhOsl763+BZguBjfloUqO4s57TcWVedaKAdPDpA52b3Q7Y/Lq3m8OUzVRo9K l2KqD7zCIO1Kbn8yMJ4C6A+/HNtxpdS7Fq3H0h4cn3ohTUnu4fwEDOGb9vnRn8NO3qXE 5xBC0kcHv4WkUGgHzw1J6cgzo6VoicFpA0PvQbgWcm9EknlsFfcVNvyXnut5Hj0n0CUu zEbYL1LEjuCATCrBCGcE3GezVC/zh3TlUlCy/xyEd/7JH5fKCme9sAQNtH/7iwvGtVa7 p9g09/uQ7RPuKjIMzs4nAiFmaywyJRCrkJUM7iAhaF7XEeN38PtVin7A1PALNKZRaHHj bHlw==
X-Gm-Message-State: AOAM530KN/xfnJ0lA2DYTBQnSZTyIbrqxSBb9xJYWLEAdBJrLywdIgYx LUEymtRWkhj+YxLkVlDvxIiaRQx5exQ=
X-Google-Smtp-Source: ABdhPJyAs2zWG3FFOllS7J8TFEd3OamdJhZ+kv8aFfF1coCTb62vV9n3tnncCfD0RO1MW6WVRs0eJg==
X-Received: by 2002:aa7:8205:0:b029:18b:3691:e447 with SMTP id k5-20020aa782050000b029018b3691e447mr15782934pfi.69.1604961952131; Mon, 09 Nov 2020 14:45:52 -0800 (PST)
Received: from [] ( []) by with ESMTPSA id z206sm12602078pfc.3.2020. (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 09 Nov 2020 14:45:51 -0800 (PST)
Date: Mon, 09 Nov 2020 14:45:44 -0800
From: Jeff Tantsura <>
Message-ID: <45f66559-cf4b-4473-bee0-71bb1f36d395@Spark>
In-Reply-To: <059e01d6b6ce$0f74a830$2e5df890$>
References: <059e01d6b6ce$0f74a830$2e5df890$>
X-Readdle-Message-ID: 45f66559-cf4b-4473-bee0-71bb1f36d395@Spark
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="5fa9c69d_3f2dba31_6e9"
Archived-At: <>
Subject: Re: [Teas] Thoughts about draft-nsdt-teas-ietf-network-slice-definition and isolation
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Traffic Engineering Architecture and Signaling working group discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 09 Nov 2020 22:45:55 -0000

Thanks for your comments Adrian.
The co-authors will review and come back to you ASAP.

On Nov 9, 2020, 11:25 AM -0800, Adrian Farrel <>, wrote:
> 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 ==
> 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.
> 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 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:
> 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.
> Isolation may be an important requirement of IETF network slices
> for some critical services. A consumer may express this request as
> an SLO.
> == 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