Re: [Teas] network Slice Endpoint in draft-ietf-teas-ietf-network-slice-definition-00

Uma Chunduri <umac.ietf@gmail.com> Fri, 12 February 2021 23:09 UTC

Return-Path: <umac.ietf@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 1A5803A1086 for <teas@ietfa.amsl.com>; Fri, 12 Feb 2021 15:09:02 -0800 (PST)
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 b8CB0F6qjNl6 for <teas@ietfa.amsl.com>; Fri, 12 Feb 2021 15:09:00 -0800 (PST)
Received: from mail-yb1-xb2f.google.com (mail-yb1-xb2f.google.com [IPv6:2607:f8b0:4864:20::b2f]) (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 113E43A1082 for <teas@ietf.org>; Fri, 12 Feb 2021 15:08:59 -0800 (PST)
Received: by mail-yb1-xb2f.google.com with SMTP id d184so1078590ybf.1 for <teas@ietf.org>; Fri, 12 Feb 2021 15:08:59 -0800 (PST)
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=ee6xqlbRYZrKrxD/ktgckVRPT1VvuXC7dKoTjVX+q8A=; b=PgawF1rlSQ9/TXaymbwOSWi5kvlr/Mvc4p2HXx0rok69qCIfmZX7s0h5vPTtkE6x+Z QxkTxQHBUqmx9y0HTqQuj6dilJPanPhD3FZOjOeqd8VVOWaLJMGUzx7N7nxKyQgbJCqM 9H9N/osCbQ942HgnqOoovZHh+ak4kcPlE5RaSdzx37bxbPvNhUBdpq8qZLV3CFZdnvGq NC/eJl7VAKWmFibvgBQlyK/pfI8TFPLTJHvxhKw3QYoBeaZGSwoTtD88PHNIKsc9wdJs 2h3Wgj80r61BulxbAdIJQr4StRZPJ1N2T209/WzZv6qDJl8dkAYG+CGAaGNFaipLH5ml VG7g==
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=ee6xqlbRYZrKrxD/ktgckVRPT1VvuXC7dKoTjVX+q8A=; b=f9cNFS/tICUJQ0s0OqtH8Q8xCBLTxmzVJXRGSgO96d83jMYGPKaXdZy6F5TINXZrQ0 R/HYSZKFB7iS/pP0jMNsoEN+Xv1I3NHu4JGqDZKqYsk4QLB8kwHkUXTIr/K5A70OREwT Fw/hRwReNztumkOvPWtYtuS3MkrzS1IHx8vIbPeLSiwHE1IHb3qlyUA57YFDF3fe0DZO /myjZn3EdY7wYlnAve4IWXnJYEZxU29+TMsqIhEJvRJ4dGxwSVj+poVrhdOSIZJYcgFz ACr1wuRZmNtdf9VhchJstQmKaJXM9mkv1zd3tPd5t2f+0xIq8wHzD54BGVpVJVNKXc19 xczg==
X-Gm-Message-State: AOAM530OJOEvz6nfYyLhCqMNIHl2pEfiyPH3i3XBvBo87Mkkus6i2qVo nVgqMs8LnmX9co/6Bb7jDxq7Sty3ZqwNxOPQn4SfAzaqJPw=
X-Google-Smtp-Source: ABdhPJyGYgk2+jpZVxrAL7ztXmSIlyV/T9jjLe9540/cLyTYeGB/zQrxF31kxX9C2IzMkxhBLicTlzl/k0O8ZFPpe5I=
X-Received: by 2002:a05:6902:1025:: with SMTP id x5mr7218738ybt.21.1613171339264; Fri, 12 Feb 2021 15:08:59 -0800 (PST)
MIME-Version: 1.0
References: <cc3949a4-1e60-7f77-45bd-2470be67d9d5@joelhalpern.com> <022001d6fc0e$4facba70$ef062f50$@olddog.co.uk> <CAF18ct6+fDAf2SwQZ5vJe2ARxpzfxDJbJSXM53k6k9iLr_EWCw@mail.gmail.com> <6D508BD7-CD0E-4B96-BBB1-69F9832AF27A@nokia.com>
In-Reply-To: <6D508BD7-CD0E-4B96-BBB1-69F9832AF27A@nokia.com>
From: Uma Chunduri <umac.ietf@gmail.com>
Date: Fri, 12 Feb 2021 15:08:48 -0800
Message-ID: <CAF18ct7HLkhX0Rbx-mYk=bGjQUR-xtzea2HYUNT+Un7+LcsMWw@mail.gmail.com>
To: "Rokui, Reza (Nokia - CA/Ottawa)" <reza.rokui@nokia.com>
Cc: "adrian@olddog.co.uk" <adrian@olddog.co.uk>, "Joel M. Halpern" <jmh@joelhalpern.com>, TEAS WG <teas@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000a3856205bb2bb8d5"
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas/9sCcECQCFd0i1x4AIzRLWFbZ-hQ>
Subject: Re: [Teas] network Slice Endpoint in draft-ietf-teas-ietf-network-slice-definition-00
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: Fri, 12 Feb 2021 23:09:02 -0000

Thank you!

Modulo the naming as discussed the Figure 1 scope and description is
correctly specified from myview.*

--
Uma C.

*Frankly a bit lost on the objection/discussion (maybe I am missing
something badly).

On Fri, Feb 12, 2021 at 6:31 AM Rokui, Reza (Nokia - CA/Ottawa) <
reza.rokui@nokia.com> wrote:

> Uma,
>
>
>
> Please my previous response to this email thread.
>
> The draft co-authors are working on these terms  but the suggested terms
> (or some of them) might be considered.
>
>
>
> Reza
>
>
>
>
>
> *From: *Teas <teas-bounces@ietf.org> on behalf of Uma Chunduri <
> umac.ietf@gmail.com>
> *Date: *Thursday, February 11, 2021 at 7:32 PM
> *To: *"adrian@olddog.co.uk" <adrian@olddog.co.uk>
> *Cc: *"Joel M. Halpern" <jmh@joelhalpern.com>om>, TEAS WG <teas@ietf.org>
> *Subject: *Re: [Teas] network Slice Endpoint in
> draft-ietf-teas-ietf-network-slice-definition-00
>
>
>
> > I suggest "source/destination" and "IETF network slice ingress/egress".
>
>
> +1 for the above.
>
>
>
> --
>
> Uma C.
>
>
>
> On Fri, Feb 5, 2021 at 2:29 PM Adrian Farrel <adrian@olddog.co.uk> wrote:
>
> Ah, the old "endpoint" discussion.
>
> Yes, Joel is right, we need to disambiguate endpoints from endpoints.
> There are traffic endpoints (the sender and receiver of packets), and there
> are endpoints of the service (the ingress and egress to the slice).
>
> There is probably a risk that we get sucked in to the wider 5G picture, but
> we need to focus (as Joel says) on the IETF network slice.
>
> I suggest "source/destination" and "IETF network slice ingress/egress".
>
> And we can avoid discussion of the wider 5G context, as noted elsewhere in
> the draft, by diverting that material into a dedicated document.
>
> Cheers,
> Adrian
>
> -----Original Message-----
> From: Teas <teas-bounces@ietf.org> On Behalf Of Joel M. Halpern
> Sent: 05 February 2021 17:04
> To: teas@ietf.org
> Subject: [Teas] network Slice Endpoint in
> draft-ietf-teas-ietf-network-slice-definition-00
>
> Rereading this draft, I realized that I am either confused by or
> disagree with the description of the "Network Slice Endpoint" contianed
> there.
>
>
> The endpoint that I think matters is the place where the IETF Network
> Slice Controller starts controlling the QoS and traffic delivery.  The
> Controller doesn't care about the identity of the device outside of that.
>
> Figure 1 in section 4.2 seems to define that endpoint as the network
> slice realiation endpoint, and describes the network slice endpoint as
> the thing outside the IetF network slice.  This seems counter-productive
> to me.  It complicates teh relationship between the endpoitn and the
> service being abstracted.  For example, if the service is beign
> delivered with MPLS, the Network Slice Endpoint likely can not put the
> labels on the packet for the MPLS, as it is outside of the IETF network
> Slice.  So we will need yet another layer of classification, and yet
> more interworking.
> Further, someone has to get the queueing right for traffic coming out of
> the Network Slice Endpoint.  But it is not part of the IETF Network
> Slice, so we don't have any way to get it right.
>
> If we define the edge of the space we care about co-incident with the
> edge of the space we influence, things get a lot cleaner.
>
> Yours,
> Joel
>
> _______________________________________________
> 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
>
>