Re: [Teas] A draft on the framework for end-to-end IETF network slicing

Tarek Saad <tsaad.net@gmail.com> Mon, 17 May 2021 15:50 UTC

Return-Path: <tsaad.net@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 319F73A3C5F for <teas@ietfa.amsl.com>; Mon, 17 May 2021 08:50:32 -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 u1eA-AGzAfuB for <teas@ietfa.amsl.com>; Mon, 17 May 2021 08:50:28 -0700 (PDT)
Received: from mail-il1-x12a.google.com (mail-il1-x12a.google.com [IPv6:2607:f8b0:4864:20::12a]) (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 D9CB13A3C5B for <teas@ietf.org>; Mon, 17 May 2021 08:50:27 -0700 (PDT)
Received: by mail-il1-x12a.google.com with SMTP id k4so2789843ili.4 for <teas@ietf.org>; Mon, 17 May 2021 08:50:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:subject:thread-topic:thread-index:date:message-id :references:in-reply-to:accept-language:content-language :mime-version; bh=I2OqSzwOhBqpflNGdt9aNncWld/X9K4RWPCuuy3eLx0=; b=VKOgVIt6UKuJ+fJFmXiZ9x3T12O0pEUIi9y+M2IJfsaYKZDQTG4JXKpLljkv7ihZSF 7lUc1PlBZk2q4gcciIWZj5m6IWjVtNjv92RovGsUXgUM3bNpel3OHN3bT+sWM97r+irE UMhOxgM1EZDIjEc+1+b4LUu5Q6scfzOdJdYNCfG/VxTncm2DhygiB9NYGE6QKWpggnun 6m5JJrxDe5JvNcsF2841A6E25P3h8d13lW7PuscNHrYxmK5FsyAAQeJBWEzQSEK55noz /UwKmSZha8f2shdunBqW8HE/fT62Tz0maJ6Wn8/HEIItpDSV38hdPS9mXuGsmO9wBsi6 AFbg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:subject:thread-topic:thread-index:date :message-id:references:in-reply-to:accept-language:content-language :mime-version; bh=I2OqSzwOhBqpflNGdt9aNncWld/X9K4RWPCuuy3eLx0=; b=mcyLZIV6mAtiAWqDmv8MrqFmsGbfHWJhJbgqi2/BpXSATMtdazVvAToXagW2H+zZkm 1UXeqQ+YeAHLFljWvCDe5vj+BKHiJIZGKJRHh59vx0+rW+CGzSt+WcSpWxeJuZGccaQI t1d4SZpKtTXlHyK0ilWe3yHxyzMfq42snXV5nIbDWlg8QKvmCU+CgIVOTHUYeB5Tr6uw pgqUW06+zqWQAgZbIxI8aW/f5wrHGIfq6uYochkKxbwGaZbwLDUGCuqisZ7TRP3RX6fa e7Kmjj6zdfkQYgwI5tdpHsPsxO+QH1i/K96BiGDY6UjAJ2UQ/kZwHFYyTFHjE9easRbB Q6Jg==
X-Gm-Message-State: AOAM533ao6JmJfqjtJNP6zE7yeF2xeZnNkzorr7AKS5LyEznii1vh0Wt NrzvtFDz/UrZmnAmk4WeDKw=
X-Google-Smtp-Source: ABdhPJxZnTo8zqwNdkLq9Olg5bLMC/I/tLLb9uXQSyZpn1yieHg0rYV98saIgS15zxlMDDxb8Cx6zA==
X-Received: by 2002:a05:6e02:1a07:: with SMTP id s7mr271307ild.251.1621266626616; Mon, 17 May 2021 08:50:26 -0700 (PDT)
Received: from DM5PR1901MB2150.namprd19.prod.outlook.com ([2603:1036:4:9e::5]) by smtp.gmail.com with ESMTPSA id h11sm8668899ilo.72.2021.05.17.08.50.25 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 17 May 2021 08:50:25 -0700 (PDT)
From: Tarek Saad <tsaad.net@gmail.com>
To: "Joel M. Halpern" <jmh@joelhalpern.com>, "Dongjie (Jimmy)" <jie.dong@huawei.com>, "teas@ietf.org" <teas@ietf.org>
Thread-Topic: [Teas] A draft on the framework for end-to-end IETF network slicing
Thread-Index: AddHoyBLABnySO+KTBWZMMOaXQaqcQAEBiaAAN+JRz8=
X-MS-Exchange-MessageSentRepresentingType: 1
Date: Mon, 17 May 2021 15:50:22 +0000
Message-ID: <DM5PR1901MB21507A1107A655DE1AA104F6FC2D9@DM5PR1901MB2150.namprd19.prod.outlook.com>
References: <c7bb7462db8f4149912d644adbd4760b@huawei.com>, <e8e5e968-f6af-a910-d2ec-510fc98ff1d6@joelhalpern.com>
In-Reply-To: <e8e5e968-f6af-a910-d2ec-510fc98ff1d6@joelhalpern.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-Exchange-Organization-SCL: -1
X-MS-TNEF-Correlator:
X-MS-Exchange-Organization-RecordReviewCfmType: 0
Content-Type: multipart/alternative; boundary="_000_DM5PR1901MB21507A1107A655DE1AA104F6FC2D9DM5PR1901MB2150_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas/xSpsNm17QaNUGMC0WBimq9JSXn4>
Subject: Re: [Teas] A draft on the framework for end-to-end IETF network slicing
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, 17 May 2021 15:50:32 -0000

Hi Joel/all,

Indeed, not all usecases necessitate distinguishing packets belonging to different slices/aggregates on a transit router. For example, packets of different slice/aggregates can share the same queue(s) on specific resource/link. Slicing of BW resources can still happen in control plane (e.g. assigning max guaranteed bandwidth per slice/aggregate, and/or allowing sharing of available bandwidth amongst slice aggregates, etc.). We have described this in draft-bestbar-teas-ns-packet<https://datatracker.ietf.org/doc/html/draft-bestbar-teas-ns-packet> as the “control plane” slicing mode (3GPP may also refer to this as “soft slicing”).


In other cases, assigning dedicated queues per slice aggregate is desirable to achieve certain level of isolation between different slice aggregate traffic (I reference “isolation” requirement from section 4.1.2.1<https://datatracker.ietf.org/doc/html/draft-ietf-teas-ietf-network-slices-02#section-4.1.2.1>.1>. of draft-ietf-teas-ietf-network-slices). In such cases, packets of different slice aggregates will need to distinguishable. We have described two methods in MPLS to distinguish such packets (either by carrying a slice-ID in the packet, or by allocating a different label per prefix for different slice/aggregates – in draft-bestbar-spring-scalable<https://datatracker.ietf.org/doc/html/draft-bestbar-spring-scalable-ns>)s>).



Regards,

Tarek


On 5/13/21, 12:48 AM, "Teas" <teas-bounces@ietf.org> wrote:


It is not at all clear that any identifiers are needed inside the
various networks, and specifically it is not clear that an internal
identifier for the end-to-end network slice is needed at the level of
the IETF network slice as is being defined by teas.  Since path
selection, QoS parameter handling, and resource allocation needs to be
handled in aggregate, it seems likely that no such identifier is needed.

Yours,
Joel

On 5/12/2021 10:53 PM, Dongjie (Jimmy) wrote:
> Hi WG,
>
> Recently we published a draft on the framework for end-to-end IETF
> network slicing:
> https://datatracker.ietf.org/doc/html/draft-li-teas-e2e-ietf-network-slicing
> <https://datatracker.ietf.org/doc/html/draft-li-teas-e2e-ietf-network-slicing>
>
> This document describes the scenarios of end-to-end network slicing, and
> the framework of network slice mapping between different network
> segments and network domains. Multiple network slice related identifiers
> are defined to covers different network scopes.
>
> The network slice related identifiers of different network scopes can be
> instantiated with MPLS or IPv6 data plane, which are further described
> in the following drafts:
>
> https://datatracker.ietf.org/doc/draft-li-mpls-e2e-ietf-network-slicing/
> <https://datatracker.ietf.org/doc/draft-li-mpls-e2e-ietf-network-slicing/>
>
> https://datatracker.ietf.org/doc/html/draft-li-6man-e2e-ietf-network-slicing
> <https://datatracker.ietf.org/doc/html/draft-li-6man-e2e-ietf-network-slicing>
>
> https://datatracker.ietf.org/doc/html/draft-li-spring-sr-e2e-ietf-network-slicing
> <https://datatracker.ietf.org/doc/html/draft-li-spring-sr-e2e-ietf-network-slicing>
>
> Your review and comments are welcome. (Comments on the specific data
> plane draft can go to the corresponding WG mail list).
>
> Best regards,
>
> Jie
>
>
> _______________________________________________
> Teas mailing list
> Teas@ietf.org
> https://www.ietf.org/mailman/listinfo/teas
>

_______________________________________________
Teas mailing list
Teas@ietf.org
https://www.ietf.org/mailman/listinfo/teas