Re: [Teas] FW: New Version Notification for draft-bestbar-teas-ns-packet-01.txt

"Joel M. Halpern" <jmh@joelhalpern.com> Sun, 07 February 2021 19:10 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 F00CC3A122C for <teas@ietfa.amsl.com>; Sun, 7 Feb 2021 11:10:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.121
X-Spam-Level:
X-Spam-Status: No, score=-2.121 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_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 WhWx5_34f-iF for <teas@ietfa.amsl.com>; Sun, 7 Feb 2021 11:10:01 -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 08CEC3A122B for <teas@ietf.org>; Sun, 7 Feb 2021 11:10:00 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 4DYdyJ5v37z6GB49; Sun, 7 Feb 2021 11:10:00 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1612725000; bh=S3yQvJ3tYf323hLLcbg2VEKUUihapsTUhNu3vgf7YOk=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=KTdaGecbDvYP1yLEtwQuI7LGimIwDkL/4iGSOrcBNwlDOPIGdI/eQidgyzaAoTKNy rsaAOZH3f60Ht/Jx1s0DH0aEp36rZZ3CDokBv6zNKMCFWN9RyERD4ayUGkX7EG0grB /0rHguCUH0qJo8yt3gfRJGlfDhHBVK95H0tdZjZo=
X-Quarantine-ID: <2RmVxvieg2MK>
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 4DYdyJ2Hjkz6G9yp; Sun, 7 Feb 2021 11:10:00 -0800 (PST)
To: Igor Bryskin <i_bryskin=40yahoo.com@dmarc.ietf.org>
Cc: TEAS WG <teas@ietf.org>
References: <160866255058.12375.3624366295025144530@ietfa.amsl.com> <B5853097-0690-45E9-9123-6F74FBCC4F03@juniper.net> <CABNhwV1u=iiK_2PQTKCquDbVwXanbTfB7U5GEzNRcgNY=iHhqQ@mail.gmail.com> <CA+YzgTvrk7bXDzyChjy1HORbAdb6XWLhaWpZP=gTbXUhTs3+3Q@mail.gmail.com> <BN6PR16MB1683FD38A7080E2BDAC114B0A0B09@BN6PR16MB1683.namprd16.prod.outlook.com>
From: "Joel M. Halpern" <jmh@joelhalpern.com>
Message-ID: <26a122f7-1e4c-21c7-4d82-44d73911830a@joelhalpern.com>
Date: Sun, 07 Feb 2021 14:09:59 -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: <BN6PR16MB1683FD38A7080E2BDAC114B0A0B09@BN6PR16MB1683.namprd16.prod.outlook.com>
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/cVrQLqVmIPpdrcChwuT0hKai4bE>
Subject: Re: [Teas] FW: New Version Notification for draft-bestbar-teas-ns-packet-01.txt
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: Sun, 07 Feb 2021 19:10:03 -0000

Let me draw a small distinction.

When a packet that needs special treatment arrives at a node, it needs 
to get that treatment.
Therefore, it seems reasonable that the packet needs to carry a sutiable 
indication of that treatment.

However, that treatment is not necessarily, nor even likely, one-one 
with the end-to-end network slice.  Adrian has indicated that the vtn is 
intended to represent that sort of aggregation.  The bestbar draft 
explicitly represents that sort of aggregation.

It may be that you intended that sort of aggregation when you saied 
"slice" below.  the range of meanings for "slice" is why I try to be 
explicit with qualifiers or alternatives terms.

Net: I do not not know if what I aid above is a paraphrase of what you 
said or a disagreement.

Yours,
Joel

On 2/7/2021 9:03 AM, Igor Bryskin wrote:
> Gyan and Pavan,
> 
> When a packet arrives at a node participating in a multi-slice network, 
> the packet needs to be treated and *routed* according to the slice it 
> belongs to. Because the physical data link over which the packet has 
> arrived could be used by more than one slices, the packet needs to carry 
> somewhere the slice ID. IMHO because the slice topology may dynamically 
> change, it would be simpler and cleaner to carry the slice ID, rather 
> than slice aggregate ID, as suggested by the draft. I also agree with 
> Gyan that the COS field may not be the best choice for the task.
> 
> Regards,
> Igor
> 
> Get Outlook for Android <https://aka.ms/ghei36>
> ------------------------------------------------------------------------
> *From:* Teas <teas-bounces@ietf.org> on behalf of Vishnu Pavan Beeram 
> <vishnupavan@gmail.com>
> *Sent:* Thursday, February 4, 2021 3:49:37 PM
> *To:* Gyan Mishra <hayabusagsm@gmail.com>
> *Cc:* Tarek Saad <tsaad=40juniper.net@dmarc.ietf.org>; 
> draft-bestbar-teas-ns-packet@ietf.org 
> <draft-bestbar-teas-ns-packet@ietf.org>; TEAS WG <teas@ietf.org>
> *Subject:* Re: [Teas] FW: New Version Notification for 
> draft-bestbar-teas-ns-packet-01.txt
> Gyan, Hi!
> 
> Thanks for taking the time to review the document. Please see inline for 
> responses (prefixed VPB).
> 
> Regards,
> -Pavan (as a co-author)
> 
> On Wed, Feb 3, 2021 at 8:14 PM Gyan Mishra <hayabusagsm@gmail.com 
> <mailto:hayabusagsm@gmail.com>> wrote:
> 
> 
> 
>     Dear authors
> 
>     I reviewed the draft and have some comments.
> 
>     I noticed the draft  name and throughout the document it mentions
>     Network Slice in IP/MPLS networks and wonder if it would be more
>     appropriate to say network slice in SR/MPLS networks.  As NS
>     involves traffic steering either RSVP-TE or SR steering my thoughts
>     are it would be appropriate
> 
> 
> [VPB] I’m not sure if I understood the comment. As you are aware, 
> Segment Routing can be instantiated on MPLS or IPv6 dataplanes. The 
> solution proposed in draft-bestbar-teas-ns-packet is intended for 
> realizing network slicing in IP(v4/v6) / MPLS networks. The proposed 
> solution works with any type of path control technology (e.g.RSVP-TE 
> paths, SR paths, FlexAlgo paths). If you are interested in how the 
> proposed solution works in SR deployments, please refer to 
> draft-bestbar-spring-scalable-ns.
> 
> 
>     This drafts main focus it seems is an example of NS using QOS CS
>     selector marking Differential service to be used for network slicing.
> 
> 
> 
> [VPB] Not really. The focus in this document is on the Slice Policy 
> construct which includes rules that control the following slice 
> aggregate attributes:
> - Data plane policies (Slice Selectors, QOS profiles)
> - Control plane policies (Guaranteed BW, Reservation priorities)
> - Topology membership policies (Customized/Pre-defined)
> 
> There are 3 types of Slice Policy Modes depending on how/where the 
> shared network resources are partitioned –
> (1) Data Plane Slice Policy Mode
> (2) Control Plane Slice Policy Mode
> (3) Data and Control Plane Slice Policy Mode
> 
> In modes (1) and (3), a Slice Selector (SS) is carried in the packet to 
> identify the slice aggregate and apply specific forwarding treatment 
> (scheduling treatment and drop probability). But this is not needed in 
> mode (2).
> 
>     In my mind QOS is completely orthogonal to the concept of network
>     slicing.  QOS involves shared resources and traffic classification
>     and scheduling based on shared pipe resources which is completely
>     orthogonal to network slicing which is a cross section of underlying
>     resources involving a degree of isolation during provisioning to
>     meet a customer  SLA.  QOS has been around for a long time and the
>     big downside to QOS is that it is independent of underlying network
>     resources.
> 
>     When QOS PHB scheduling occurs based on CS AF or EF selector, packet
>     are marked at the edge of trust boundary and PHB hop by hop
>     scheduled matching dscp value providing bandwidth guarantees for
>     profile traffic at or below the scheduling bandwidth which is based
>     on the shared physical link.
> 
> 
> 
> [VPB] As noted above, it is certainly possible for a network slicing 
> solution to be put together without requiring a specific 
> per-hop-behavior to be applied on packets belonging to a slice aggregate 
> (we refer to this as “Control Plane Slice Policy Mode” - Section 4.2 of 
> draft-bestbar-teas-ns-packet-01). However, there are cases where the 
> Slice service requires strict QOS guarantees and differentiation from 
> other traffic – this is where the Data Plane Slice Policy Mode comes 
> into play.
> 
>     Kind Regards
> 
>     Gyan
> 
> 
>     On Tue, Dec 22, 2020 at 1:59 PM Tarek Saad
>     <tsaad=40juniper.net@dmarc.ietf.org
>     <mailto:40juniper.net@dmarc.ietf.org>> wrote:
> 
>         Hi WG,____
> 
>         __ __
> 
>         We have published a new revision of this draft (just in time for
>         your holidays reading).____
> 
>         The changes include:____
> 
>           * additional co-authors have joined____
>           * introduction of new terms “slice policy” and “slice
>             aggregate”____
>           * editorial nits to align with new terms introduced____
> 
>         __ __
> 
>         As usual, reviews and comments are welcome.____
> 
>         __ __
> 
>         Regards,____
> 
>         Tarek (on behalf of co-authors)____
> 
>         __ __
> 
>         __ __
> 
>         On 12/22/20, 1:42 PM, "internet-drafts@ietf.org
>         <mailto:internet-drafts@ietf.org>" <internet-drafts@ietf.org
>         <mailto:internet-drafts@ietf.org>> wrote:____
> 
>         __ __
> 
>              [External Email. Be cautious of content]____
> 
>         __ __
> 
>         __ __
> 
>              A new version of I-D, draft-bestbar-teas-ns-packet-01.txt____
> 
>              has been successfully submitted by Tarek Saad and posted to
>         the____
> 
>              IETF repository.____
> 
>         __ __
> 
>              Name:           draft-bestbar-teas-ns-packet____
> 
>              Revision:       01____
> 
>              Title:          Realizing Network Slices in IP/MPLS
>         Networks____
> 
>              Document date:  2020-12-22____
> 
>              Group:          Individual Submission____
> 
>              Pages:          27____
> 
>              URL:
>         https://urldefense.com/v3/__https://www.ietf.org/archive/id/draft-bestbar-teas-ns-packet-01.txt__;!!NEt6yMaO-gk!UopixISsH-6laFtUNIg5vIaLsXzFthS8C65TCDCRk-5ayO6AAa-8IPzvuhQQRw$
>         <https://urldefense.com/v3/__https://www.ietf.org/archive/id/draft-bestbar-teas-ns-packet-01.txt__;!!NEt6yMaO-gk!UopixISsH-6laFtUNIg5vIaLsXzFthS8C65TCDCRk-5ayO6AAa-8IPzvuhQQRw$>____
> 
>              Status:
>         https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-bestbar-teas-ns-packet/__;!!NEt6yMaO-gk!UopixISsH-6laFtUNIg5vIaLsXzFthS8C65TCDCRk-5ayO6AAa-8IPwWnIEvoQ$
>         <https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-bestbar-teas-ns-packet/__;!!NEt6yMaO-gk!UopixISsH-6laFtUNIg5vIaLsXzFthS8C65TCDCRk-5ayO6AAa-8IPwWnIEvoQ$>____
> 
>              Htmlized:
>         https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draft-bestbar-teas-ns-packet__;!!NEt6yMaO-gk!UopixISsH-6laFtUNIg5vIaLsXzFthS8C65TCDCRk-5ayO6AAa-8IPxBddbTdg$
>         <https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draft-bestbar-teas-ns-packet__;!!NEt6yMaO-gk!UopixISsH-6laFtUNIg5vIaLsXzFthS8C65TCDCRk-5ayO6AAa-8IPxBddbTdg$>____
> 
>              Htmlized:
>         https://urldefense.com/v3/__https://tools.ietf.org/html/draft-bestbar-teas-ns-packet-01__;!!NEt6yMaO-gk!UopixISsH-6laFtUNIg5vIaLsXzFthS8C65TCDCRk-5ayO6AAa-8IPznNKoLDg$
>         <https://urldefense.com/v3/__https://tools.ietf.org/html/draft-bestbar-teas-ns-packet-01__;!!NEt6yMaO-gk!UopixISsH-6laFtUNIg5vIaLsXzFthS8C65TCDCRk-5ayO6AAa-8IPznNKoLDg$>____
> 
>              Diff:
>         https://urldefense.com/v3/__https://www.ietf.org/rfcdiff?url2=draft-bestbar-teas-ns-packet-01__;!!NEt6yMaO-gk!UopixISsH-6laFtUNIg5vIaLsXzFthS8C65TCDCRk-5ayO6AAa-8IPzsN9oeaw$
>         <https://urldefense.com/v3/__https://www.ietf.org/rfcdiff?url2=draft-bestbar-teas-ns-packet-01__;!!NEt6yMaO-gk!UopixISsH-6laFtUNIg5vIaLsXzFthS8C65TCDCRk-5ayO6AAa-8IPzsN9oeaw$>____
> 
>         __ __
> 
>              Abstract:____
> 
>                 Network slicing provides the ability to partition a
>         physical network____
> 
>                 into multiple logical networks of varying sizes,
>         structures, and____
> 
>                 functions so that each slice can be dedicated to
>         specific services or____
> 
>                 customers.  Network slices need to operate in parallel
>         while____
> 
>                 providing slice elasticity in terms of network resource
>         allocation.____
> 
>                 The Differentiated Service (Diffserv) model allows for
>         carrying____
> 
>                 multiple services on top of a single physical network by
>         relying on____
> 
>                 compliant nodes to apply specific forwarding treatment
>         (scheduling____
> 
>                 and drop policy) on to packets that carry the respective
>         Diffserv____
> 
>                 code point.  This document proposes a solution based on
>         the Diffserv____
> 
>                 model to realize network slicing in IP/MPLS networks.____
> 
>         __ __
> 
>         __ __
> 
>         __ __
> 
>         __ __
> 
>              Please note that it may take a couple of minutes from the
>         time of submission____
> 
>              until the htmlized version and diff are available at
>         tools.ietf.org <http://tools.ietf.org>.____
> 
>         __ __
> 
>              The IETF Secretariat____
> 
>         __ __
> 
>         __ __
> 
> 
>         Juniper Business Use Only
> 
>         _______________________________________________
>         Teas mailing list
>         Teas@ietf.org <mailto:Teas@ietf.org>
>         https://www.ietf.org/mailman/listinfo/teas
>         <https://www.ietf.org/mailman/listinfo/teas>
> 
>     -- 
> 
>     <http://www.verizon.com/>
> 
>     *Gyan Mishra*
> 
>     /Network Solutions A//rchitect /
> 
>     /M 301 502-1347
>     13101 Columbia Pike
>     /Silver Spring, MD
> 
> 
>     _______________________________________________
>     Teas mailing list
>     Teas@ietf.org <mailto:Teas@ietf.org>
>     https://www.ietf.org/mailman/listinfo/teas
>     <https://www.ietf.org/mailman/listinfo/teas>
> 
> 
> _______________________________________________
> Teas mailing list
> Teas@ietf.org
> https://www.ietf.org/mailman/listinfo/teas
>