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

Joel Halpern Direct <jmh.direct@joelhalpern.com> Sun, 07 February 2021 21:20 UTC

Return-Path: <jmh.direct@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 3240B3A134B for <teas@ietfa.amsl.com>; Sun, 7 Feb 2021 13:20:27 -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 O8-IFBwhPid9 for <teas@ietfa.amsl.com>; Sun, 7 Feb 2021 13:20:24 -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 0DEAC3A134A for <teas@ietf.org>; Sun, 7 Feb 2021 13:20:23 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 4DYhrl67NCz6GD6Y; Sun, 7 Feb 2021 13:20:23 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1612732823; bh=4AF7eBjPsMCyK/SbSngzAetIp5OL880jT3Nyxg0zuhU=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=AqAKLHzELzB8Q+Pj3bGkWy9+aGqIozPUtLro4o1gmBffFi58rU0XbF251sdghtl1L o/Gn3eeVLICl0AKynaMPqKarsHurqLNzAmDsroIsSgzV5LvPW9NvdnorPsW/RAt7DK 3AotU87+7ymsLQLEZlj63MnNK3Cp3ArGRYqOpk9U=
X-Quarantine-ID: <c-bk4HBoy_kO>
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 4DYhrl1qVmz6GB76; Sun, 7 Feb 2021 13:20:23 -0800 (PST)
To: Igor Bryskin <i_bryskin@yahoo.com>
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> <CA+YzgTuqj7W7=oz3M1m7Pys9P5xSPm9+QCA1WRPiYUoyBhbWDQ@mail.gmail.com> <BN6PR16MB1683185500A8DF1FDE745D6FA0B09@BN6PR16MB1683.namprd16.prod.outlook.com> <c1870f42-f7ab-9e09-a0a0-2125469c4fc8@joelhalpern.com> <BN6PR16MB1683FAFC90E125D756F0F466A0B09@BN6PR16MB1683.namprd16.prod.outlook.com> <4356b8aa-f6af-586d-3bfc-9c57ffdffe61@joelhalpern.com> <BN6PR16MB168398BBA8F6706A770EFBE3A0B09@BN6PR16MB1683.namprd16.prod.outlook.com>
From: Joel Halpern Direct <jmh.direct@joelhalpern.com>
Message-ID: <279f4d4e-9fb6-ce58-61f1-94a74697f4d1@joelhalpern.com>
Date: Sun, 7 Feb 2021 16:20:22 -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: <BN6PR16MB168398BBA8F6706A770EFBE3A0B09@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/Ef9U7XWC-mCRdtn3iYIe0LD2l3s>
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 21:20:27 -0000

I do not define "slice".   Do you mean "IETF network slice"?  If so, I 
will defer to the framework draft work, which the authors tell me hopes 
to include a definition of IETF Network Slice.  If you mean RAN Slice, 
Core Slice, or end-to-end slide, I either use the 3GPP definition or 
various corporate definitions depending upon what I am doing.

Yours,
Joel

On 2/7/2021 4:06 PM, Igor Bryskin wrote:
> This means that you define slice as logical/abstract single node, rather 
> than logical network. Agree?
> 
> Igor
> 
> Get Outlook for Android <https://aka.ms/ghei36>
> 
> ------------------------------------------------------------------------
> *From:* Teas <teas-bounces@ietf.org> on behalf of Joel M. Halpern 
> <jmh@joelhalpern.com>
> *Sent:* Sunday, February 7, 2021 3:50:34 PM
> *To:* Igor Bryskin <i_bryskin=40yahoo.com@dmarc.ietf.org>
> *Cc:* TEAS WG <teas@ietf.org>
> *Subject:* Re: [Teas] FW: New Version Notification for 
> draft-bestbar-teas-ns-packet-01.txt
> As John Drake pointed out, the TEAS proposal (adotped WG document, but
> not completed document)is that the slice client expresses its needs in
> terms of the behavior (generally QoS / SLO terms) it requires.  The IETF
> Network slice implementation delivers that.  The client does not need or
> want to see the internal topology.
> 
> Depending upon the requirements, the IETF Network Slice implementation
> may or may not be able to aggregate the traffic into internal artifacts.
>    The assumption, which matches the vast majority of use cases, is that
> it will be able to aggregate.
> 
> Yours,
> Joel
> 
> On 2/7/2021 3:06 PM, Igor Bryskin wrote:
>> Thanks Joel,
>> So, you are saying that a slice client has no say as to how its packets 
>> forwarded / treated by the network. There is no even  need to expose the 
>> slice topology in some form to the client, because the client can't do 
>> much with such information,  correct?
>> Also, can you envision a use case when a slice topological elements may 
>> have independent name space?
>> 
>> Thanks,
>> Igor
>> 
>> Get Outlook for Android <https://aka.ms/ghei36 <https://aka.ms/ghei36>>
>> 
>> ------------------------------------------------------------------------
>> *From:* Teas <teas-bounces@ietf.org> on behalf of Joel M. Halpern 
>> <jmh@joelhalpern.com>
>> *Sent:* Sunday, February 7, 2021 2:15:01 PM
>> *To:* Igor Bryskin <i_bryskin=40yahoo.com@dmarc.ietf.org>
>> *Cc:* TEAS WG <teas@ietf.org>
>> *Subject:* Re: [Teas] FW: New Version Notification for 
>> draft-bestbar-teas-ns-packet-01.txt
>> I disagree.
>> The edge of the domain receives and classifies the packet.  It can use
>> any information it can to decide what aggregate the slice belongs in.
>> Once that is done, the IETF network slice implementation network should
>> simply obey the instruction as to what aggregate the packet belongs in.
>>    The carrying network does not need to care about the external network
>> slices.  And by avoiding such concern, all the parts scale better and we
>> get a clean division of responsibility.
>> 
>> Yours,
>> Joel
>> 
>> On 2/7/2021 1:58 PM, Igor Bryskin wrote:
>>> Pavan,
>>> 
>>> I assume:
>>> - that a node, generally speaking, needs to make a forwarding decision 
>>> based on the packet's slice topology;
>>> - said topology may change dynamically, and so is the slice membership 
>>> in the slice aggregate.
>>> Therefore. It is better, in my opinion, to carry slice ID in packets and 
>>> let nodes (re-)define slice aggregate membership independently.
>>> 
>>> Igor
>>> 
>>> Get Outlook for Android <https://aka.ms/ghei36 <https://aka.ms/ghei36 <https://aka.ms/ghei36>>>
>>> 
>>> ------------------------------------------------------------------------
>>> *From:* Teas <teas-bounces@ietf.org> on behalf of Vishnu Pavan Beeram 
>>> <vishnupavan@gmail.com>
>>> *Sent:* Sunday, February 7, 2021, 11:48 AM
>>> *To:* Igor Bryskin
>>> *Cc:* Tarek Saad; Gyan Mishra; TEAS WG; 
>>> draft-bestbar-teas-ns-packet@ietf.org
>>> *Subject:* Re: [Teas] FW: New Version Notification for 
>>> draft-bestbar-teas-ns-packet-01.txt
>>> 
>>> Igor, Hi!
>>> 
>>> Please see inline.
>>> 
>>> Regards,
>>> -Pavan (as a co-author)
>>> 
>>> On Sun, Feb 7, 2021 at 8:03 AM Igor Bryskin <i_bryskin@yahoo.com 
>>> <mailto:i_bryskin@yahoo.com <mailto:i_bryskin@yahoo.com 
> <mailto:i_bryskin@yahoo.com>>>> 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.
>>> 
>>> 
>>> [VPB] The packet needs to carry some identifier that would help 
>>> determine the specific forwarding treatment (scheduling and drop policy) 
>>> to be applied before the packet is forwarded further (this is not needed 
>>> in the "Control Plane Slice Policy" mode). In the model that is proposed 
>>> in the draft, we have one or more IETF Network Slices mapped onto a 
>>> single slice aggregate and each slice aggregate has a specific Per Hop 
>>> Behavior associated with it. In other words, the packet needs to carry 
>>> an identifier that maps onto the slice aggregate. Also note that in the 
>>> proposed model, multiple slice aggregates can map onto the same topology.
>>> 
>>> 
>>>     I also agree with Gyan that the COS field may not be the best choice
>>>     for the task.
>>> 
>>> 
>>> [VPB] I'm not sure what you mean by the COS field here.  If there is a 
>>> need to allow differentiation of forwarding treatments for packets 
>>> within a slice aggregate, the slice aggregate traffic may further carry 
>>> a Diffserv Class Selector.
>>> 
>>> 
>>>     Regards,
>>>     Igor
>>> 
>>>     Get Outlook for Android <https://aka.ms/ghei36 <https://aka.ms/ghei36 <https://aka.ms/ghei36>>>
>>>     ------------------------------------------------------------------------
>>>     *From:* Teas <teas-bounces@ietf.org <mailto:teas-bounces@ietf.org <mailto:teas-bounces@ietf.org 
> <mailto:teas-bounces@ietf.org>>>>
>>>     on behalf of Vishnu Pavan Beeram <vishnupavan@gmail.com
>>>     <mailto:vishnupavan@gmail.com <mailto:vishnupavan@gmail.com 
> <mailto:vishnupavan@gmail.com>>>>
>>>     *Sent:* Thursday, February 4, 2021 3:49:37 PM
>>>     *To:* Gyan Mishra <hayabusagsm@gmail.com <mailto:hayabusagsm@gmail.com <mailto:hayabusagsm@gmail.com 
> <mailto:hayabusagsm@gmail.com>>>>
>>>     *Cc:* Tarek Saad <tsaad=40juniper.net@dmarc.ietf.org
>>>     <mailto:40juniper.net@dmarc.ietf.org <mailto:40juniper.net@dmarc.ietf.org 
> <mailto:40juniper.net@dmarc.ietf.org>>>>;
>>>     draft-bestbar-teas-ns-packet@ietf.org
>>>     <mailto:draft-bestbar-teas-ns-packet@ietf.org
>> <mailto:draft-bestbar-teas-ns-packet@ietf.org 
> <mailto:draft-bestbar-teas-ns-packet@ietf.org>>>
>>>     <draft-bestbar-teas-ns-packet@ietf.org
>>>     <mailto:draft-bestbar-teas-ns-packet@ietf.org
>> <mailto:draft-bestbar-teas-ns-packet@ietf.org 
> <mailto:draft-bestbar-teas-ns-packet@ietf.org>>>>; TEAS WG
>>>     <teas@ietf.org <mailto:teas@ietf.org <mailto:teas@ietf.org <mailto: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 <mailto: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
>> <mailto: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 <mailto:internet-drafts@ietf.org 
> <mailto:internet-drafts@ietf.org>>>"
>> <internet-drafts@ietf.org
>>>             <mailto:internet-drafts@ietf.org <mailto: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$> 
> 
>> <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$>>
>>>             <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$ 
> <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$> 
> 
>> <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$>>
>>>             <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$ 
> <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$> 
> 
>> <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$>>
>>>             <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$ 
> <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$> 
> 
>> <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$>>
>>>             <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$ 
> <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$> 
> 
>> <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$>>
>>>             <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$ 
> <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 <http://tools.ietf.org <http://tools.ietf.org>>>.____
>>> 
>>>             __ __
>>> 
>>>                  The IETF Secretariat____
>>> 
>>>             __ __
>>> 
>>>             __ __
>>> 
>>> 
>>>             Juniper Business Use Only
>>> 
>>>             _______________________________________________
>>>             Teas mailing list
>>>             Teas@ietf.org <mailto:Teas@ietf.org <mailto:Teas@ietf.org <mailto:Teas@ietf.org>>>
>>>             https://www.ietf.org/mailman/listinfo/teas 
> <https://www.ietf.org/mailman/listinfo/teas>
>> <https://www.ietf.org/mailman/listinfo/teas 
> <https://www.ietf.org/mailman/listinfo/teas>>
>>>             <https://www.ietf.org/mailman/listinfo/teas
>> <https://www.ietf.org/mailman/listinfo/teas 
> <https://www.ietf.org/mailman/listinfo/teas>>>
>>> 
>>>         -- 
>>> 
>>>         <http://www.verizon.com/ <http://www.verizon.com/ <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 <mailto:Teas@ietf.org <mailto:Teas@ietf.org>>>
>>>         https://www.ietf.org/mailman/listinfo/teas 
> <https://www.ietf.org/mailman/listinfo/teas>
>> <https://www.ietf.org/mailman/listinfo/teas 
> <https://www.ietf.org/mailman/listinfo/teas>>
>>>         <https://www.ietf.org/mailman/listinfo/teas
>> <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 
> <https://www.ietf.org/mailman/listinfo/teas>
>> <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 
> <https://www.ietf.org/mailman/listinfo/teas>
>> <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 
> <https://www.ietf.org/mailman/listinfo/teas>
>> 
> 
> _______________________________________________
> Teas mailing list
> Teas@ietf.org
> https://www.ietf.org/mailman/listinfo/teas 
> <https://www.ietf.org/mailman/listinfo/teas>