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

Igor Bryskin <i_bryskin@yahoo.com> Sun, 07 February 2021 20:07 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 8FBD73A12A4 for <teas@ietfa.amsl.com>; Sun, 7 Feb 2021 12:07:04 -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=unavailable 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 xljdC1B3rmfv for <teas@ietfa.amsl.com>; Sun, 7 Feb 2021 12:07:01 -0800 (PST)
Received: from sonic309-21.consmr.mail.ne1.yahoo.com (sonic309-21.consmr.mail.ne1.yahoo.com [66.163.184.147]) (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 8DE273A12A5 for <teas@ietf.org>; Sun, 7 Feb 2021 12:07:01 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1612728419; bh=VUzlKg0WJdBRo+e6PqIiYf6Q4iKg8IwbgywrVmx7MUg=; h=From:To:CC:Subject:Date:References:In-Reply-To:From:Subject:Reply-To; b=bL88hQLRxvwcxER5Zsx9LA3Qd/TeU98BE+JmeqkJvMbGIBqhbTDz07vVpNin7Zda0vDR4dpZJgujEmE5J8Eaifj5vYv36Jqzd+b41y9RB5peqzZSDaHaUzI/YynhZOeaLL+87KkBdNx39H/fpkmOqyuKA+QJR46RHiP3b7ntIamXsE3lt+BjellmWVZ6jCkVybNHbHHtKddB4x7lY8JEHn0kgTkJeVZLhG+Jy5m+BlXRYZVwuO0RXO0yEZlV0b44mA+QKz8Np0dBM/na3T93/Oke3yYEc8Rsrgpjoiouiv/5mLIAqudkmTkl/vXSb+my8ln6Buz5ASBHZCS1w/IQbg==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1612728419; bh=gjiBbQboSC4QqQ+39lt1z4vHNRfV0kQw0hqLJZ4+s90=; h=X-Sonic-MF:From:To:Subject:Date:From:Subject; b=lbC4J9MdYnRgwduuOxuyi1VX8LksoounLDkyWzqnTaEEFeSN8NqSooKkovpc316wbjQJnNLhnO+1hdq/l4T2S+/ux1OZIjttwuDlrLDPW/AXb+rvxilPl2J4X54obvbaFXZQHWTeLx4/HKtRLdty0gC0IMpSEVH6MN1WSRvj3NTaLpD5vaK6Jf1T6jG9pwCt7bEQu1iCXUOLCxcKJNHgKhnyIa+67BexLQ/Yi4zaywak0EQmYHl5WfXgyQF/U1pSb5jKhmMF3pg+YOhBM3KlpYEBZL7PTXWonK6i+Pg+d7sEni5nnRWQXvDSnuX0zUSfOoWRXgHUkgbWP8bCuSTNUQ==
X-YMail-OSG: ZSL_r4YVM1lRjluOBMYokus263qgdviNGufI8C7dWiZiD3RRyPMaZB2hWHErQ90 Vru9fS2L6aIdM2.PDhARVD6S3SL95tNiwZJR9ffCW2WWziO.mOsx1m0GnQKxG7g2mgW9BWhAfefG nQlQqXS9TGU2edRUGHIhD3W469AwgLXxBpHMTD38fC30dDYWu2KjMLSN_nH2wGpLuh3esvpetsuG jPxkfMSuv7th06k9av2dQ.Q1dSlHyy6IMvUT7y8Fwy2Rmybc7Ux6HgPkqwkii3PAdMIapr4qrN9E JgwRGToM4_Xv_9q_x9OeENPjJ1AlAhbCq1x0hHRkzcvcZ7gl9tpY8tPhthtn0UkHN.KjqdK3rISO aUVMhPYZE.skofzdUfGSSh6wvp6WPHqfvf7LW066be3VKHWH_RaZt6_w5xAkp.YtQD.pIhFqd5H. 05CksA6c8_zpbDYEKwYe5StBXy5hNNYFk8bLo1M8oFyASTiDtM_CnqOyGU3p_vT51WY_je2ZbJI6 srwsBNavL.FvsZ.QPuWPiuOuj5fTrTjr9R1QsutF6KkYzei_QZ0uDbLoS8Ek6.oQI05DnaQqDiBG EwStQhfAN4JRcG_GIfzbywfkoAJpJz15fa.q6CzWhoX8Qlh0fHUlqV_RxNFe3ItvCNJbFNurJOIf lVO74QUmUam7VOKMKLbA2cNFwXawaq_s.xw8EpeZeshiNZp_NfuRHE_e16sBOFtX0evKCYoNq3jo XgozX77T3kpgDy_ZUmVAwlDTfDEZclTJqfBo2CqsuZtmBbRZzB.d2wdpwnEo7MSaU0e26W0mHyaZ I3VTJUo12kUrSMjyQnTz1m_ODS.wHVtXDQWF8Upmn1KbFfWVZuVHXyiEK4wx5MZ75POYageQ78EP Gcp0d8PFjoyq1Arp3f0pTmYnBEGS7hV4j7aKINv3niUj4zDu7955nxQbMyBqpz2AHC6xvrZ6WOqa tSRDJhRAthewuj8ksXFRA3amfRkxzMFROv1pICTX.IywGw6e5tpIaBQgogEggmm5otZO__yLCUHQ nBjNOOOoBsiGilrNok76hZzO_.v4JD0wBa_LoG_txFb40S5bw2k7QNSkcWBihUjfR61zRJ9.saBc 1DZ3q2zIBJksFqjMgSsMljWqKTLkvXsaecfPhw1.Q7yM73PjHp__3fuiHYxL0M9Ygn0ExI9_6oR7 6BAN0AQ26CZ036QmDm8UQ.UrU.b_I83a6aUjwZY7OCO.dp1Ho8dAjhpCh6kK8iV1uHb_jBs3gwbd P2AKgEcvclMCOq2lMhIFWydfo8tO5PIJdIILUOHCsIlZ3j5cyNwMwpxrS9O2Ej.Zz7pt3krx5T7u t.s8Lr3p6EfnzGjPT_WN2nhcGnF6Vd4QcSrpYSDrVyvsfdv7cdZ2GrxRJcB_X93FkCK6V.FLaMZ0 JXlzsedJLbbFHnUmBsfjMq1bAJTWv79mO.1qSbJrwMtcQIq5G2O2DND6jyK_0jcxedFIF2S4EROK EtpyRRFoxnbe6fSSUyOVuqjnYRgnyCIsYJdvQODZHGwolWF1K378IWQubyKv6I0ru7Cq5zHhCi1O n895k7JMbX6J33oKb4I1mV8W8Kmk8honlPobG_P_k2XsBqKxLivSdpt_YfjD8g2vznBLX58VPsty PXbU.CPR0pJgYl_aROevFF2MBYhxg1c4KZr4ax9il2qtmtrq_QFThoFLMxH6A83NH5CSlhxb9l1k Xsw5xwTlwQ_9F3vF.czPMqUT7PlC8R.EhL3Z_JNhJByE_25vvssvS.X6CSjoWWn1GFUhI4Wz3WIq DXhNxV75RvZWX6qBMVUX2Co56mjOyL8OHXQkoBGGWDfCo52MNYKZ7Tzxd72K3UwLp_aMgPXXy1Vp 5ZD.snpmHRzvHqhW4uXAla8KMoRoqoZEZiI3xd6xj_t.TooSDPr4FG23RoZHLOiK2cmAN_s7toDp XeAMQcmMs3GXgTgJUrtsdvXmDlAXYntXE4IAkXgQJZRqFsz6yV8lEDtb9MUALbepvq25Z47uZ1TR KHoffMy6wGtE0a09C_10AS2kzA3dZRMlbCy9yJiPieO__NMti7LIQOrvcXqFBuD6irqh7qeFilRK Zs0OesVztzrm_6EgicEMAsWGCP.7tonUS770KK3n7vd0hcoe2ZtU9Q3NyBKNee6DQ0OiUzIDRJ8T 18zh1BDBskd2oF9o08aBZWYdQVORVPV_N9OVrdkW6ZybNALu0YhZtdrXHZzox6n2z_cS1CJIbDGb bB110cRHGrOg5bm5MNgNg3CjzimlzzM1vQCp1l92DyUOrOVequ6wjHnVP.08YqCc06idYwTDvPjU azpz_6G76Y0gMf3KOsB3zWOnSAbaTz.YjPYttrAl0AWGgSsphwTsF7R0jsBgtwfjAIHay0ww3EHH XyAKniCDLzqbl_jlGHEAWOAz8aUW8fK2pDiiFTUlbEmlOgQcUztU44AvKcao7Iqpw632vSYaNrVM EplWtQZg2DtLKMztw48j4hv2D69C8r3O5OHAD.lojdffbPx27SpJwSny.bBO0uoGYfrx2KFPbeAz HqXepifLnIeWQRI0.GPNaWr3O34C8sAeep5HWtXBR01_tiRssN4U8tQPXP_yzxnWAM5FvC3M8Qy0 KC774sPKXUAZHStqCJ1M-
X-Sonic-MF: <i_bryskin@yahoo.com>
Received: from sonic.gate.mail.ne1.yahoo.com by sonic309.consmr.mail.ne1.yahoo.com with HTTP; Sun, 7 Feb 2021 20:06:59 +0000
Received: by smtp407.mail.ne1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID bb16a135e4e0e8093db43a497cb40640; Sun, 07 Feb 2021 20:06:57 +0000 (UTC)
From: Igor Bryskin <i_bryskin@yahoo.com>
To: Igor Bryskin <i_bryskin=40yahoo.com@dmarc.ietf.org>, "Joel M. Halpern" <jmh@joelhalpern.com>
CC: TEAS WG <teas@ietf.org>
Thread-Topic: [Teas] FW: New Version Notification for draft-bestbar-teas-ns-packet-01.txt
Thread-Index: ATAyMzcwz1nVZ13L8uB/thznweqMNTNGMjQ3UVJUcWlRVFcxN8bm4pNmgAAyJgCAAB+cfIAACV6AgAALhnk=
X-MS-Exchange-MessageSentRepresentingType: 1
Date: Sun, 7 Feb 2021 20:06:56 +0000
Message-ID: <BN6PR16MB1683FAFC90E125D756F0F466A0B09@BN6PR16MB1683.namprd16.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>
In-Reply-To: <c1870f42-f7ab-9e09-a0a0-2125469c4fc8@joelhalpern.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-Exchange-Organization-SCL: -1
X-MS-TNEF-Correlator:
X-MS-Exchange-Organization-RecordReviewCfmType: 0
Content-Type: multipart/alternative; boundary="_000_BN6PR16MB1683FAFC90E125D756F0F466A0B09BN6PR16MB1683namp_"
MIME-Version: 1.0
X-Mailer: WebService/1.1.17648 mail.backend.jedi.jws.acl:role.jedi.acl.token.atz.jws.hermes.yahoo Apache-HttpAsyncClient/4.1.4 (Java/11.0.8)
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas/Yc4MBaAonDLOV2R98BOaYsCc19Q>
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 20:07:05 -0000

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>

________________________________
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