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

Igor Bryskin <i_bryskin@yahoo.com> Mon, 08 February 2021 14:58 UTC

Return-Path: <i_bryskin@yahoo.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 130883A0061 for <teas@ietfa.amsl.com>; Mon, 8 Feb 2021 06:58:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 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, RCVD_IN_MSPIKE_H2=-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=yahoo.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 xprAvt3wFIr1 for <teas@ietfa.amsl.com>; Mon, 8 Feb 2021 06:58:12 -0800 (PST)
Received: from sonic307-9.consmr.mail.ne1.yahoo.com (sonic307-9.consmr.mail.ne1.yahoo.com [66.163.190.32]) (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 3435F3A0045 for <teas@ietf.org>; Mon, 8 Feb 2021 06:58:12 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1612796291; bh=fO8OLsYyoHcDwTvj0h6PF7t1/5yGR6fBdH6keZOSQJc=; h=Date:From:To:Cc:In-Reply-To:References:Subject:From:Subject:Reply-To; b=iXV5uguEbVA0Q1Igi4PogEVwoHMloSRpBXgHgkzt21WkHAbJ4FEhTpZoW1Hc1a7E9gssExMLF3dbY8jBNYWybWJKaUce5hJFhXgOFGLzNQj1rcoKAMS2qcn+MSCKl/RZe8NfSHd6vA0oxwuROv6hqHWjPq69uVHwVYR/LAhsbN8nafwUPol/zW5GqE+nT6NKTCr9l2qf6Y1B7LZ4b8PX1a1pnmLe5nDgMlAW3rahkz+UAef1xw0rCATdfAFUCLNNjPaM+FdylrIuCHDfdf2EDy+bOgIuI6U7CR6gNQc7bzfgAKpzKHoQ4sfjYjBK5LmFIR07hrRDrmVUoahLSxOtNA==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1612796291; bh=EqIpTY2rV475HjvX5EjDxfUxmzi3GCXicbanCF0lKwR=; h=X-Sonic-MF:Date:From:To:Subject:From:Subject; b=Hl4aXynLOUWrVriN1dyW+waF082YJ5bnGg4uSuTIxyO43ojYhzj8bPSyv9hCeW/L8tNbU39jV+WzQom71pqYyncXggOcjjQpC0jnFuVPO6WITHMm3B8gxqrISj0tCdLolPGJ9mxbob+lOp2XdZkR85e0JSe3N8CiTQ7zI2U9N5hlhHweEGSMpYZ4pjTMI1psOzKDYDC0N9Fw/w4xTJA4hprGcTLPSmrVHIQnMG2p2JO4UHMttssQkLqTMlKUFgPmYlqSdT0LTVTKUdr7HWZfL51hCGWyFpkRnjWu4gqeYsh4BlVXU3BmwrVfeWEpqTMvDspKFX7tE49EPMDApWZG6Q==
X-YMail-OSG: 0gMvoTQVM1lqRvBUYa74OLmEfsW7Jfak7ixwlJ25eFIpF3L3bhUbGcNdf51nMFN cDky0hsmWGxy1ci22KOq.CZ3coAMbqJ776pbfkFv8ZeFoQ9SSNBtqkkunhvvmQdzOTSaSMLIXGsB m_08SkQbsgZyYXUJ8gNUhwD6FaItFAmF94Q95BvA6dFDhls9ebRs11X568X_O.Yt3SNxcPqrGLJo fKi_hAi5g6jipOxLgLluoflooyDgRICNkx3jOSFxjNoVId1e60o4JHm9EwJDClTJDEGVsdeyJs10 lJF.1xsGcAnQU4rDN8yhqZBtI8xTnt.rAw9oKsOW0i7qWCosZqv5iidw_FBk6yTZzPqaCmooJb5K CeVmY55rhtuxEUXsJ4QJCUn2L5K83P4Az13sVVZOXg.2_TVqqhdkHNMoQNq9a8Rx_cMY.XSmJAQr JnetkSVr_C9_khkalKDvrgrEBQqU.4MZ3tO1KU8Z6PGG9osCOdqLYcX4dXLdi60EipKcoZoXtIRb BAfUhD1Es7ikefWWKqOjKHAv.gGbNMzeMZs948KcC_Wf7ZNAJ09jRdrsOpWw61hgHI80dL76jMhy .YcLUIu7gHcwyE7a_6Rgy2B72ZyUrS6QPqZjvpDDbtnDaU3XQI4LLPcYb8oebu5OUZ3d4KhDb3Tz PdaT2eHefXzWW_h49SfO_ORHCd8le7yn9Y9IK5T9Dk.e0zVJ6XOvjhbYDcVhVOPO1loDxmLGdBCp K3yvLtkY9NQ29Dv.QtITe8_g5earXU6TNzCJXbF9KDmgZK.cwDlHRMNeYZ1Q1215SobRFLCu3sHc IlksxG2CcO__v9mvwqWJa2oxzV2pN1u5kWv9vhSY0NGhPieU8w6WcoaCSKxoE0MrTgrJk599ES01 6X6IPLqYSHqG0L7aYnfFlRMtajrgySDrbSVnrY62U4bewSafJX9D_wPtQRHkfza8Bg.9MMQtzMIu UVbuSoSiFIjZElYObil0ab1KOdBIdmRZFavRtL_Nu.RH2S4vv7g5dFBwJRIFEJW9UMjzyly2.0xx ijQ2OQ5M8Z2iCIsuHaSrs7MUuM3mK1YS7vUP6mJ2by2AywaGMApeAaPCD9qNGLt1f8jtzBEbci0d it4vpE5WVe1gR7hVQLcMJ35CGVU1RKtfSPvVFf_vpN1vfTG2u7Qxn__Rptvrq4z6zFjyV1m1861n Ph3VELad8H6RUo0i_cDbsZwhnbXV4ZvWBaUpTpcAGaCm8RXcn46Keh5cNsuKsQ2PNRrzmPPJrqIn 6K1UEefwFqOk1HLdcTZttLonmy8yuktOQWCB4stYdyTW8Q7avzcVx.jDC7gEYoa3nd25NEPvl5XF yjXrbQcfp4EzKHnkmtF9VCtXSVN.Wtj.JdvP9CzMCx.c2b2a3bdsSrzPR_KNTBT4tYTtCUpKngeS qBZS6FOL4ioSWE4poeyemOB__rU.gNaLLzZ3k6rrODV3UUnm_0pD8qktqeSRD8_VrgDFRktZ2gyO p289Klf7yhE6hIOnaj8x3lR0zuNplwWlJP4ph_Cu8TkZtTINeKep.KJovSDF68hs.KHrp7ON5b6T .NTT56_Mrk9Qex8CHj9Zpcf82qQwQAc68HFk53YKTv.iCkSgEqTb5g_.jlmcKX1Z91Of46RCyigg hvWEXThd37Ag7sPwno1b41mCH98hxksl8BngT8f_BnssAODsXW.GnKrTccWL.k.DxdYiyfoeP4Q0 _aBFvM.Etkukf9W0ZwTzEJ1jIOC2KaMCEFY8dpi2XD7rVPLFyRoQ4YswdU8wfy4pJx8xvpYNJ9Kh ii2fEmrEty5xqjS3.qaWfqdtswPxfm_XUIFpgDjTGF4GyKj75lYGcGtRWQnmxCkfJpwnYD_ENrqj FY0qkDw6QMIs.LtxOSIaemdPssNzJGAr5QLWfZYMXiHpiivlFRcjs3L_QQH5EPHbvRuYWwd04gQ4 A.jgzIPSKpRnMFTUYFM1gzV13SX7AvgWun6rooGamIt7hVQIRwQ.E67L5aXMWWHuuDYg9XgBoi15 wkWZEzr7IbW_CxZTyXPk0ZA0nUzN31Pt4oI9kRnZtw1RdkAjqMLXJ3Ri.P9EptYIHcMSP09wB3o5 Sk9YSO2mWmmQ3H5Nth8hVgWah7Jv1LwIxTID8XtGWxs.zVU995HJanxCj62EFrRpt_feoGMTSHnk 6Zaqq8bW_zjIQMOVnMqTAgJzAXby25kHKxmj.bD40xIIakpRedReu3h5b.v4RDEBf6ve_aX_cuAi tz_R1QLsLk.qhfKw7S76PdunXR97D1mngUk1kWVf0kh3QJ5SYfQI5TDDJUxQ5uoiOb5nUMCi0V.X ocXEzKTuu.YxLK2BBoxKs9TME5wG6fpYXRXl8YWndWTBXzBxCSqG_s1G2YbdI0K.iNVw1K4uJzYX L8nzwfM9UDZAY5YI_ve4pMFkHcm6uaDH2LVpSW0YQJupdI2MxpqDPv4E19SFz7QzZHhDBXzxYUFW b6DqS6YIoHiTjyfoioBFHf0nbPlXpXnB9yDkn7su1obmJVQUIIXGpJ73YbornzqE.BP200D5P08P b2rv8Moe4rCnER6DbRXz.BIFn7p1tKXDscY4LJheFggkljfbYwuHWXzOvIeuhkToJE1Rmyv0GDR_ zrPq8JaSTFjWxviliS6oTKJ2Q0Nxs
X-Sonic-MF: <i_bryskin@yahoo.com>
Received: from sonic.gate.mail.ne1.yahoo.com by sonic307.consmr.mail.ne1.yahoo.com with HTTP; Mon, 8 Feb 2021 14:58:11 +0000
Date: Mon, 8 Feb 2021 14:58:10 +0000 (UTC)
From: Igor Bryskin <i_bryskin@yahoo.com>
To: "Joel M. Halpern" <jmh@joelhalpern.com>, John E Drake <jdrake=40juniper.net@dmarc.ietf.org>
Cc: TEAS WG <teas@ietf.org>
Message-ID: <1196296124.724894.1612796290084@mail.yahoo.com>
In-Reply-To: <MN2PR05MB6623AD4E25E56F0B655158B0C7B09@MN2PR05MB6623.namprd05.prod.outlook.com>
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> <MN2PR05MB6623AD4E25E56F0B655158B0C7B09@MN2PR05MB6623.namprd05.prod.outlook.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_Part_724893_892200345.1612796290075"
X-Mailer: WebService/1.1.17648 YMailNorrin Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/88.0.4324.150 Safari/537.36 Edg/88.0.705.63
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas/I3WsCsc8Qp-ejxhFSCMvo9imrl8>
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: Mon, 08 Feb 2021 14:58:16 -0000

 Hi John,
In the definitions document I found:
"An IETF network slice is a logical network topology connecting a
   number of endpoints using a set of shared or dedicated network
   resources that are used to satisfy specific Service Level Objectives
   (SLOs).

   An IETF network slice combines the connectivity resource requirements
   and associated network behaviors such as bandwidth, latency, jitter,
   and network functions with other resource behaviors such as compute
   and storage availability.
"It does not sound to me that IETF network slice is a "single point" even from the client's point of view. It does sound that a client may request not just a connectivity across the slice, but also, say, a few network functions along the path connected and synchronized in a certain way. How this could be done if the slice is perceived as a single point?
Thanks,Igor
    On Sunday, February 7, 2021, 03:42:40 PM EST, John E Drake <jdrake=40juniper.net@dmarc.ietf.org> wrote:  
 
 #yiv6228045449 #yiv6228045449 -- _filtered {} _filtered {} _filtered {}#yiv6228045449 #yiv6228045449 p.yiv6228045449MsoNormal, #yiv6228045449 li.yiv6228045449MsoNormal, #yiv6228045449 div.yiv6228045449MsoNormal {margin:0in;font-size:11.0pt;font-family:sans-serif;}#yiv6228045449 a:link, #yiv6228045449 span.yiv6228045449MsoHyperlink {color:blue;text-decoration:underline;}#yiv6228045449 span.yiv6228045449EmailStyle18 {font-family:sans-serif;color:windowtext;}#yiv6228045449 p.yiv6228045449msipfooter30b3d538, #yiv6228045449 li.yiv6228045449msipfooter30b3d538, #yiv6228045449 div.yiv6228045449msipfooter30b3d538 {margin-right:0in;margin-left:0in;font-size:11.0pt;font-family:sans-serif;}#yiv6228045449 .yiv6228045449MsoChpDefault {font-size:10.0pt;} _filtered {}#yiv6228045449 div.yiv6228045449WordSection1 {}#yiv6228045449 
Igor,
 
  
 
Please see:  https://datatracker.ietf.org/doc/html/draft-ietf-teas-ietf-network-slice-definition-00  andhttps://datatracker.ietf.org/doc/html/draft-nsdt-teas-ns-framework-05. 
 
  
 
I have always considered a network slice to be a VPN with QoS requirements;  i.e., it is a set of endpoints with connectivity constructs (MP2MP, P2MP, P2P) between subsets of theses endpoints, and QoS requirements for each sender to each connectivity construct.  How the network delivers a VPN with QoS requirements is its own business.
 
  
 
Yours Irrespectively,
 
  
 
John
 
  
 
  
 
Juniper Business Use Only
 
From: Teas <teas-bounces@ietf.org> On Behalf Of Igor Bryskin
Sent: Sunday, February 7, 2021 3:07 PM
To: Igor Bryskin <i_bryskin=40yahoo.com@dmarc.ietf.org>rg>; Joel M. Halpern <jmh@joelhalpern.com>
Cc: TEAS WG <teas@ietf.org>
Subject: Re: [Teas] FW: New Version Notification for draft-bestbar-teas-ns-packet-01.txt
 
  
 
[External Email. Be cautious of content]
 
  
 
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
 
GetOutlook for Android
 
  
 
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>
> 
> ------------------------------------------------------------------------
> *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>> 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>
>     ------------------------------------------------------------------------
>     *From:* Teas <teas-bounces@ietf.org <mailto:teas-bounces@ietf.org>>
>     on behalf of Vishnu Pavan Beeram <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>>
>     *Cc:* Tarek Saad <tsaad=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>
>     <draft-bestbar-teas-ns-packet@ietf.org
>     <mailto:draft-bestbar-teas-ns-packet@ietf.org>>; TEAS WG
>     <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>> 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
> 

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