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

[Joel Halpern Direct <[e-mail]>]

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 <[e-mail]> on behalf of Joel M. Halpern 
> <[e-mail]>
> *Sent:* Sunday, February 7, 2021 3:50:34 PM
> *To:* Igor Bryskin <i_bryskin=[e-mail]>
> *Cc:* TEAS WG <[e-mail]>
> *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 <[e-mail]> on behalf of Joel M. Halpern 
>> <[e-mail]>
>> *Sent:* Sunday, February 7, 2021 2:15:01 PM
>> *To:* Igor Bryskin <i_bryskin=[e-mail]>
>> *Cc:* TEAS WG <[e-mail]>
>> *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 <[e-mail]> on behalf of Vishnu Pavan Beeram 
>>> <[e-mail]>
>>> *Sent:* Sunday, February 7, 2021, 11:48 AM
>>> *To:* Igor Bryskin
>>> *Cc:* Tarek Saad; Gyan Mishra; TEAS WG; 
>>> [e-mail]
>>> *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 <[e-mail] 
>>> <mailto:[e-mail] <mailto:[e-mail] 
> <mailto:[e-mail]>>>> 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 <[e-mail] <mailto:[e-mail] <mailto:[e-mail] 
> <mailto:[e-mail]>>>>
>>>     on behalf of Vishnu Pavan Beeram <[e-mail]
>>>     <mailto:[e-mail] <mailto:[e-mail] 
> <mailto:[e-mail]>>>>
>>>     *Sent:* Thursday, February 4, 2021 3:49:37 PM
>>>     *To:* Gyan Mishra <[e-mail] <mailto:[e-mail] <mailto:[e-mail] 
> <mailto:[e-mail]>>>>
>>>     *Cc:* Tarek Saad <tsaad=[e-mail]
>>>     <mailto:[e-mail] <mailto:[e-mail] 
> <mailto:[e-mail]>>>>;
>>>     [e-mail]
>>>     <mailto:[e-mail]
>> <mailto:[e-mail] 
> <mailto:[e-mail]>>>
>>>     <[e-mail]
>>>     <mailto:[e-mail]
>> <mailto:[e-mail] 
> <mailto:[e-mail]>>>>; TEAS WG
>>>     <[e-mail] <mailto:[e-mail] <mailto:[e-mail] <mailto:[e-mail]>>>>
>>>     *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 <[e-mail]
>>>     <mailto:[e-mail] <mailto:[e-mail] 
> <mailto:[e-mail]>>>> 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=[e-mail]
>>>         <mailto:[e-mail]
>> <mailto:[e-mail] 
> <mailto:[e-mail]>>>> 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, "[e-mail]
>>>             <mailto:[e-mail] <mailto:[e-mail] 
> <mailto:[e-mail]>>>"
>> <[e-mail]
>>>             <mailto:[e-mail] <mailto:[e-mail] 
> <mailto:[e-mail]>>>>
>> 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
>>>             [e-mail] <mailto:[e-mail] <mailto:[e-mail] <mailto:[e-mail]>>>
>>>             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
>>>         [e-mail] <mailto:[e-mail] <mailto:[e-mail] <mailto:[e-mail]>>>
>>>         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
>>> [e-mail]
>>> 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
>> [e-mail]
>> 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
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/teas 
> <https://www.ietf.org/mailman/listinfo/teas>
>> 
> 
> _______________________________________________
> Teas mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/teas 
> <https://www.ietf.org/mailman/listinfo/teas>