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

Vishnu Pavan Beeram <vishnupavan@gmail.com> Mon, 08 February 2021 09:56 UTC

Return-Path: <vishnupavan@gmail.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 94AE83A1552 for <teas@ietfa.amsl.com>; Mon, 8 Feb 2021 01:56:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 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, 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=gmail.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 Wp7BdTcsNCpb for <teas@ietfa.amsl.com>; Mon, 8 Feb 2021 01:55:58 -0800 (PST)
Received: from mail-il1-x12e.google.com (mail-il1-x12e.google.com [IPv6:2607:f8b0:4864:20::12e]) (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 44FDE3A154F for <teas@ietf.org>; Mon, 8 Feb 2021 01:55:58 -0800 (PST)
Received: by mail-il1-x12e.google.com with SMTP id o7so7644308ils.2 for <teas@ietf.org>; Mon, 08 Feb 2021 01:55:58 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=+5/mnZDrhkq1nAYiCCVibw8+XsHJITuE8YfTVcgWnkw=; b=UoeZVft1wSePgOmRAfzzrPw6zzWFIPlip/jR1bZIghPrJupF+drsQWj3BOSBg6vZM+ 4hgVjNp/XwUfA4j0Yl/wCSi4Pwk/dkdkpoBMnirtzrvl2M2R/Z/JrRoDUEJcRgdlWk/W ZR9TQ1ZhnpCWf/FCC6uKsEOFgwbkDgj29bl/0H6oUWs44aYdG/eiuScBxwlTa/XeAWn3 7oBGrT0wZOWTBtRiGobeDlx2iL/6tpTbzJeRPeKzq2UYGuySI/dZjsHKhN3BXIVU63Es ctkBG+5Iar8oXKVLnYmm/NvnPO+XlIbmVhL3gHwYlIuGQHGxFETdbPpFv5EqhIe/Bo/Q UgxQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=+5/mnZDrhkq1nAYiCCVibw8+XsHJITuE8YfTVcgWnkw=; b=KFJRynYJOp6lulqOOZ7BA6NS2pJL85tPpmTvcm1V54fpAl2XIky8IU+mbpuGTKPWXu d2a2YkmBaOp/1FUGr4ICcaNfxqI8T7Chafr7VGkQjrhKrVyLQx88FmOHpH5J2ROZBGbE EdoAtyiBx5PQ2CugMrXaUPwao23Gvyxba4gHwh1Y02PsVhkJ4TlGO7qLUV5zdmPwJ7rg tXG6yH57C/2vD1JYrgh3R7k6A/aEojONObJKzGM7DO71AVKbKizYs7cLys9vDWyhyq8Q mqu4DtqOQ9M97EFQ0C/VZuA9k8JI8N9w0dQ/XQl8uZshFQsGGssP0z0LKN3okCg5y1jN C1gw==
X-Gm-Message-State: AOAM533KHm9Grt4ioYujT+YdG8DKLaDTho34aVcA/NPtcYbvS4/qS3cj RNRCVTHNm1kLF1fh8LB4GnaIAVGUP617bumLKGhhyjn4TDjMQA==
X-Google-Smtp-Source: ABdhPJyHb8Ie4AN18rnud5i4qVzK52LlGZnJRu7GrXpZZzzWWTMh1vhAMcMGF7NdHvjzykroMF7W5BJjHwcFxcDco38=
X-Received: by 2002:a92:b011:: with SMTP id x17mr14729007ilh.179.1612778157325; Mon, 08 Feb 2021 01:55:57 -0800 (PST)
MIME-Version: 1.0
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> <279f4d4e-9fb6-ce58-61f1-94a74697f4d1@joelhalpern.com>
In-Reply-To: <279f4d4e-9fb6-ce58-61f1-94a74697f4d1@joelhalpern.com>
From: Vishnu Pavan Beeram <vishnupavan@gmail.com>
Date: Mon, 08 Feb 2021 03:55:45 -0600
Message-ID: <CA+YzgTtgzRQcYp+0COmegYCfriEhuQpqL8=u45ZQSyGCj8wnrQ@mail.gmail.com>
To: Joel Halpern Direct <jmh.direct@joelhalpern.com>
Cc: Igor Bryskin <i_bryskin@yahoo.com>, TEAS WG <teas@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000002b401705bad02da2"
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas/tjukdYPZXBEtDDlelD44m961fEI>
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 09:56:03 -0000

@Joel – Thanks for chiming in!



The slice aggregate is defined in <draft-bestbar-teas-ns-packet> as follows:

**

   Slice aggregate:

      a collection of packets that match a slice policy selection

      criteria and are given the same forwarding treatment; a slice

      aggregate comprises of one or more IETF network slice traffic

      streams; the mapping of one or more IETF network slices to a slice

      aggregate is maintained by the IETF Network Slice Controller.

**

All the relevant pieces of functionality required for realizing network
slicing (in packet networks) are specified in this document in terms of the
slice aggregate (Slice aggregate aware TE, per hop forwarding treatment
etc). Adrian also seems to be saying (different thread in SPRING) that the
VTN as proposed in the enhanced-vpn work exists to serve a similar purpose.
I guess if we just get consensus on how (/what it takes) to realize this
slice aggregate, we are done 😊.



<draft-bestbar-teas-ns-packet> also introduces a policy construct called
the slice policy to realize this slice aggregate by instantiating specific
control and data plane behaviors on select topological elements in IP/MPLS
networks. The various elements of a slice policy are discussed in detail in
Section 5.1 (and I believe this is where most of the debate/discussion
would lie going forward). The slice policy definition used to realize a
slice aggregate is consistent across the slice policy domain; this policy
construct needs to exist on nodes along a slice aggregate path if they are
to provide the necessary forwarding treatment for the slice aggregate.



Regards,

-Pavan (as a co-author)

On Sun, Feb 7, 2021 at 3:20 PM Joel Halpern Direct <
jmh.direct@joelhalpern.com> wrote:

> 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>
>
> _______________________________________________
> Teas mailing list
> Teas@ietf.org
> https://www.ietf.org/mailman/listinfo/teas
>