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

"Joel M. Halpern" <jmh@joelhalpern.com> Tue, 16 February 2021 16:11 UTC

Return-Path: <jmh@joelhalpern.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 775C23A0A0B for <teas@ietfa.amsl.com>; Tue, 16 Feb 2021 08:11:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.799
X-Spam-Level:
X-Spam-Status: No, score=-2.799 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, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.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 U-C_9TjF8woW for <teas@ietfa.amsl.com>; Tue, 16 Feb 2021 08:11:46 -0800 (PST)
Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (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 EB54C3A09EC for <teas@ietf.org>; Tue, 16 Feb 2021 08:11:46 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 4Dg5ZV5CpBz6GWQY for <teas@ietf.org>; Tue, 16 Feb 2021 08:11:46 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1613491906; bh=wtIU5RIDRxk9nYfkf5cXHVCFtt3wOCYo8er92mPNTng=; h=Subject:To:References:From:Date:In-Reply-To:From; b=BZrgR39qQ3bkd3vZ+JFCCvZa8JoFF4QXlPv+HvClyz/3M3J87vN5GZ3QEs9nIb1oA ca9mDiL7mfzdDTCx3nvhJ24JaYZVlqUm2rj0WPg3BbZbHAx5NvlD5jFC/pjwGDxVji T/XwYyzWNoPiNriS7tI+gIR/kQoFG7KfoDUn5yKk=
X-Quarantine-ID: <VpI1kQrvwCqX>
X-Virus-Scanned: Debian amavisd-new at a2.tigertech.net
Received: from [192.168.128.43] (unknown [50.225.209.66]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 4Dg5ZV229fz6GJc1 for <teas@ietf.org>; Tue, 16 Feb 2021 08:11:46 -0800 (PST)
To: "teas@ietf.org" <teas@ietf.org>
References: <cc3949a4-1e60-7f77-45bd-2470be67d9d5@joelhalpern.com> <28233_1613491513_602BED39_28233_126_1_787AE7BB302AE849A7480A190F8B9330315CF830@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
From: "Joel M. Halpern" <jmh@joelhalpern.com>
Message-ID: <1bf03e82-3734-885a-7047-cacf5c63d9cc@joelhalpern.com>
Date: Tue, 16 Feb 2021 11:11:45 -0500
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.7.0
MIME-Version: 1.0
In-Reply-To: <28233_1613491513_602BED39_28233_126_1_787AE7BB302AE849A7480A190F8B9330315CF830@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas/6G_73muhe5s1KhAg0I2-0E7bhjc>
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: Tue, 16 Feb 2021 16:11:48 -0000

The document is not about the request from the external customer (the 
request for the end-to-end network slice). It is about the request from 
other orchestration systems to the IETF Network Slice management 
systems.  Yes, those systems need to know where they intent to utilize 
the IETF network slice.  But the IETF network slice does not need to 
know about that.

In particular, when we get to talking about configuring the IETF Network 
Slice properties, the edge (ingress) that the IETF Network Slice 
controller controls (and corresponding egress) is what needs to be 
provisioned.
It is possible that on the egress side there needs to be information 
about how to deliver the traffic externally.  But that would not be in 
terms of end-points since from the perspective of the IETF Network 
Slice, on the egress that is not an endpoint of anything.

Yours,
Joel

On 2/16/2021 11:05 AM, mohamed.boucadair@orange.com wrote:
> Hi Joel,
> 
> I disagree with this note. I do think that both flavors of "endpoint" should be included in the draft.
> 
>>From the customer standpoint, a slice request cannot be characterized by elements not visible to the customer. The scope of a requested slice can only be characterized between nodes that are known to the requestor. This is usually called, CE.  
> 
> The mapping between a CE and a network device (typically, a PE) is a process that is internal to the slice provider.
> 
> The CE-PE link cannot be systematically excluded as some specific behaviors may need to be enforced in the CE-PE link. Think about a slice that is implemented by means of a PE-based VPN and which requires some specific routing + QoS policies at the CE-PE link.
> 
> Cheers,
> Med
> 
>> -----Message d'origine-----
>> De : Teas [mailto:teas-bounces@ietf.org] De la part de Joel M.
>> Halpern
>> Envoyé : vendredi 5 février 2021 18:04
>> À : teas@ietf.org
>> Objet : [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
> 
> _________________________________________________________________________________________________________________________
> 
> Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
> Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
> 
> This message and its attachments may contain confidential or privileged information that may be protected by law;
> they should not be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and delete this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
> Thank you.
> 
> _______________________________________________
> Teas mailing list
> Teas@ietf.org
> https://www.ietf.org/mailman/listinfo/teas
>