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

From: Gyan Mishra <[email-masked]>
Date: Wed, 3 Feb 2021 21:14:23 -0500

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

This drafts main focus it seems is an example of NS using QOS CS selector
marking Differential service to be used for network slicing.  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.

Kind Regards

Gyan

On Tue, Dec 22, 2020 at 1:59 PM Tarek Saad <tsaad=
[email-masked]> 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, "[email-masked]" <
> [email-masked]> 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$
>
>     Status:
> 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$
>
>     Htmlized:
> 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$
>
>
>
>     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.
>
>
>
>     The IETF Secretariat
>
>
>
>
>
> Juniper Business Use Only
> _______________________________________________
> Teas mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/teas
>
-- 

<http://www.verizon.com/>

*Gyan Mishra*

*Network Solutions A**rchitect *

*M 301 502-134713101 Columbia Pike *Silver Spring, MD

---

From: Vishnu Pavan Beeram <[email-masked]>
Date: Thu, 4 Feb 2021 14:49:37 -0600

Gyan, Hi!

Thanks for taking the time to review the document. Please see inline for
responses (prefixed VPB).

Regards,
-Pavan (as a co-author)

> 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.

> 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.
>
[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.

---

From: Igor Bryskin <[email-masked]>
Date: Sun, 7 Feb 2021 14:03:30 +0000

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. I also agree with Gyan that the COS field may not be the best choice for the task.

Regards,
Igor

Get Outlook for Android<https://aka.ms/ghei36>
________________________________
From: Teas <[email-masked]> on behalf of Vishnu Pavan Beeram <[email-masked]>
Sent: Thursday, February 4, 2021 3:49:37 PM
To: Gyan Mishra <[email-masked]>
Cc: Tarek Saad <tsaad=[email-masked]>; [email-masked] <[email-masked]>; TEAS WG <[email-masked]>
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 <[email-masked]<mailto:[email-masked]>> wrote:

Dear authors

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=[email-masked]<mailto:[email-masked]>> 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

Regards,

On 12/22/20, 1:42 PM, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>> wrote:

    IETF repository.

    Revision:       01

    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$

    Status:         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$

    Htmlized:       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$

    Abstract:

       functions so that each slice can be dedicated to specific services or

    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

_______________________________________________
Teas mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/teas
--

[http://ss7.vzw.com/is/image/VerizonWireless/vz-logo-email]<http://www.verizon.com/>

Gyan Mishra

Network Solutions Architect

M 301 502-1347
13101 Columbia Pike
Silver Spring, MD

_______________________________________________
Teas mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/teas

---

From: Vishnu Pavan Beeram <[email-masked]>
Date: Sun, 7 Feb 2021 10:48:22 -0600

Igor, Hi!

Please see inline.

Regards,
-Pavan (as a co-author)

On Sun, Feb 7, 2021 at 8:03 AM Igor Bryskin <[email-masked]> 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 <[email-masked]> on behalf of Vishnu Pavan Beeram <
> [email-masked]>
> *Sent:* Thursday, February 4, 2021 3:49:37 PM
> *To:* Gyan Mishra <[email-masked]>
> *Cc:* Tarek Saad <tsaad=[email-masked]>;
> [email-masked] <
> [email-masked]>; TEAS WG <[email-masked]>
> *Subject:* Re: [Teas] FW: New Version Notification for
> draft-bestbar-teas-ns-packet-01.txt
>
> Gyan, Hi!
>
> 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
> *M 301 502-1347 13101 Columbia Pike  *Silver Spring, MD
>

---

From: Igor Bryskin <[email-masked]>
Date: Sun, 7 Feb 2021 18:58:49 +0000

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

________________________________
From: Teas <[email-masked]> on behalf of Vishnu Pavan Beeram <[email-masked]>
Sent: Sunday, February 7, 2021, 11:48 AM
To: Igor Bryskin
Cc: Tarek Saad; Gyan Mishra; TEAS WG; [email-masked]
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 <[email-masked]<mailto:[email-masked]>> 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 <[email-masked]<mailto:[email-masked]>> on behalf of Vishnu Pavan Beeram <[email-masked]<mailto:[email-masked]>>
Sent: Thursday, February 4, 2021 3:49:37 PM
To: Gyan Mishra <[email-masked]<mailto:[email-masked]>>
Cc: Tarek Saad <tsaad=[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>; TEAS WG <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Teas] FW: New Version Notification for draft-bestbar-teas-ns-packet-01.txt

Gyan, Hi!

Regards,
-Pavan (as a co-author)

Dear authors

Kind Regards

Gyan

Hi WG,

The changes include:

Regards,

    IETF repository.

    Revision:       01

    Pages:          27

    Abstract:

    The IETF Secretariat

Gyan Mishra

M 301 502-1347
13101 Columbia Pike
Silver Spring, MD

---

From: "Joel M. Halpern" <[email-masked]>
Date: Sun, 7 Feb 2021 14:09:59 -0500

Let me draw a small distinction.

When a packet that needs special treatment arrives at a node, it needs 
to get that treatment.
Therefore, it seems reasonable that the packet needs to carry a sutiable 
indication of that treatment.

However, that treatment is not necessarily, nor even likely, one-one 
with the end-to-end network slice.  Adrian has indicated that the vtn is 
intended to represent that sort of aggregation.  The bestbar draft 
explicitly represents that sort of aggregation.

It may be that you intended that sort of aggregation when you saied 
"slice" below.  the range of meanings for "slice" is why I try to be 
explicit with qualifiers or alternatives terms.

Net: I do not not know if what I aid above is a paraphrase of what you 
said or a disagreement.

Yours,
Joel

On 2/7/2021 9:03 AM, Igor Bryskin wrote:
> change, it would be simpler and cleaner to carry the slice ID, rather 
> than slice aggregate ID, as suggested by the draft. I also agree with 
> Gyan that the COS field may not be the best choice for the task.
> 
> Regards,
> Igor
> 
> ------------------------------------------------------------------------
> *From:* Teas <[email-masked]> on behalf of Vishnu Pavan Beeram 
> <[email-masked]>
> [email-masked] 
> <[email-masked]>; TEAS WG <[email-masked]>
>     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.
> 
> 
> 
> construct which includes rules that control the following slice 
> aggregate attributes:
> There are 3 types of Slice Policy Modes depending on how/where the 
> shared network resources are partitioned –
> (scheduling treatment and drop probability). But this is not needed in 
> mode (2).
> 
>     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.
> 
> 
> 
> 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=[email-masked]
>     <mailto:[email-masked]>> 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, "[email-masked]
>         <mailto:[email-masked]>" <[email-masked]
>         <mailto:[email-masked]>> 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$>____
> 
>              Status:
>         <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$>____
> 
>              Htmlized:
>         <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$>____
> 
>         __ __
> 
>              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____
> 
>         __ __
> 
>         __ __
> 
> 
>         [email-masked] <mailto:[email-masked]>
>         <https://www.ietf.org/mailman/listinfo/teas>
> 
>     -- 
> 
>     /Network Solutions A//rchitect /
> 
>     /M 301 502-1347
>     13101 Columbia Pike
>     /Silver Spring, MD
> 
> 
>     [email-masked] <mailto:[email-masked]>
>     <https://www.ietf.org/mailman/listinfo/teas>
> 
>

---

From: "Joel M. Halpern" <[email-masked]>
Date: Sun, 7 Feb 2021 14:15:01 -0500

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:
> Therefore. It is better, in my opinion, to carry slice ID in packets and 
> let nodes (re-)define slice aggregate membership independently.
> 
> Igor
> 
> *Sent:* Sunday, February 7, 2021, 11:48 AM
> *To:* Igor Bryskin
> *Cc:* Tarek Saad; Gyan Mishra; TEAS WG; 
>     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.
> 
> 
> [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
> 
>     *From:* Teas <[email-masked] <mailto:[email-masked]>>
>     on behalf of Vishnu Pavan Beeram <[email-masked]
>     <mailto:[email-masked]>>
>     *To:* Gyan Mishra <[email-masked] <mailto:[email-masked]>>
>     *Cc:* Tarek Saad <tsaad=[email-masked]
>     <mailto:[email-masked]>>;
>     <mailto:[email-masked]>
>     <[email-masked]
>     <mailto:[email-masked]>>; TEAS WG
>     <[email-masked] <mailto:[email-masked]>>
>         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
> 
> 
>     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.
> 
> 
> 
>     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
> 
> 
>             We have published a new revision of this draft (just in time
>             for your holidays reading).____
> 
>             The changes include:____
> 
>                  has been successfully submitted by Tarek Saad and
>             posted to the____
> 
>                  IETF repository.____
> 
>             __ __
> 
>                     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____
> 
>                  Please note that it may take a couple of minutes from
>             the time of submission____
>

---

From: Igor Bryskin <[email-masked]>
Date: Sun, 7 Feb 2021 20:06:56 +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

________________________________
From: Teas <[email-masked]> on behalf of Joel M. Halpern <[email-masked]>
Sent: Sunday, February 7, 2021 2:15:01 PM
To: Igor Bryskin <i_bryskin=[email-masked]>
Cc: TEAS WG <[email-masked]>
Subject: Re: [Teas] FW: New Version Notification for draft-bestbar-teas-ns-packet-01.txt

I disagree.

Yours,
Joel

---

From: John E Drake <[email-masked]>
Date: Sun, 7 Feb 2021 20:42:25 +0000

Igor,

Please see:  https://datatracker.ietf.org/doc/html/draft-ietf-teas-ietf-network-slice-definition-00  and https://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 <[email-masked]> On Behalf Of Igor Bryskin
Sent: Sunday, February 7, 2021 3:07 PM
To: Igor Bryskin <i_bryskin=[email-masked]>; Joel M. Halpern <[email-masked]>
Cc: TEAS WG <[email-masked]>
Subject: Re: [Teas] FW: New Version Notification for draft-bestbar-teas-ns-packet-01.txt

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://urldefense.com/v3/__https:/aka.ms/ghei36__;!!NEt6yMaO-gk!S_VvA6mf2AmOIWFf6rkeEuaobWVZxh3S2-X2ThtuXv-jPlkHS-PbYXuKCWk0toY$>

________________________________
From: Teas <[email-masked]<mailto:[email-masked]>> on behalf of Joel M. Halpern <[email-masked]<mailto:[email-masked]>>
Sent: Sunday, February 7, 2021 2:15:01 PM
To: Igor Bryskin <i_bryskin=[email-masked]<mailto:i_bryskin=[email-masked]>>
Cc: TEAS WG <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Teas] FW: New Version Notification for draft-bestbar-teas-ns-packet-01.txt

I disagree.

Yours,
Joel

On 2/7/2021 1:58 PM, Igor Bryskin wrote:
> Get Outlook for Android <https://aka.ms/ghei36<https://urldefense.com/v3/__https:/aka.ms/ghei36__;!!NEt6yMaO-gk!S_VvA6mf2AmOIWFf6rkeEuaobWVZxh3S2-X2ThtuXv-jPlkHS-PbYXuKCWk0toY$>>
>
> *From:* Teas <[email-masked]<mailto:[email-masked]>> on behalf of Vishnu Pavan Beeram
> <[email-masked]<mailto:[email-masked]>>
> [email-masked]<mailto:[email-masked]>
> On Sun, Feb 7, 2021 at 8:03 AM Igor Bryskin <[email-masked]
<mailto:[email-masked]%20%0b>> <mailto:[email-masked]>> wrote:
>     Get Outlook for Android <https://aka.ms/ghei36<https://urldefense.com/v3/__https:/aka.ms/ghei36__;!!NEt6yMaO-gk!S_VvA6mf2AmOIWFf6rkeEuaobWVZxh3S2-X2ThtuXv-jPlkHS-PbYXuKCWk0toY$>>
<mailto:[email-masked]%0b>>     <mailto:[email-masked]>>
>     *Cc:* Tarek Saad <tsaad=[email-masked]
<mailto:tsaad=[email-masked]%0b>>     <mailto:[email-masked]>>;
>     [email-masked]<mailto:[email-masked]>
<mailto:[email-masked]%0b>>     <mailto:[email-masked]>>; TEAS WG
>     On Wed, Feb 3, 2021 at 8:14 PM Gyan Mishra <[email-masked]
>             <mailto:[email-masked]>" <[email-masked]
<mailto:[email-masked]%0b>>             <mailto:[email-masked]>> wrote:____
>             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$>>____
>
>                  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$>>____
>
>                  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$>>____
>
>                  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$>>____
>
>             __ __
>
>                  Abstract:____
>
>             tools.ietf.org <http://tools.ietf.org<https://urldefense.com/v3/__http:/tools.ietf.org__;!!NEt6yMaO-gk!S_VvA6mf2AmOIWFf6rkeEuaobWVZxh3S2-X2ThtuXv-jPlkHS-PbYXuKBtnAFoU$>>.____
>
>             __ __
>
>                  The IETF Secretariat____
>
>             __ __
>
>             __ __
>
>
>             [email-masked]<mailto:[email-masked]> <mailto:[email-masked]>
>             https://www.ietf.org/mailman/listinfo/teas<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/teas__;!!NEt6yMaO-gk!S_VvA6mf2AmOIWFf6rkeEuaobWVZxh3S2-X2ThtuXv-jPlkHS-PbYXuK9MiU5Bg$>
>             <https://www.ietf.org/mailman/listinfo/teas<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/teas__;!!NEt6yMaO-gk!S_VvA6mf2AmOIWFf6rkeEuaobWVZxh3S2-X2ThtuXv-jPlkHS-PbYXuK9MiU5Bg$>>
>
>         --
>
>         <http://www.verizon.com/<https://urldefense.com/v3/__http:/www.verizon.com/__;!!NEt6yMaO-gk!S_VvA6mf2AmOIWFf6rkeEuaobWVZxh3S2-X2ThtuXv-jPlkHS-PbYXuKxK95nyI$>>
>
>         *Gyan Mishra*
>
>         [email-masked]<mailto:[email-masked]> <mailto:[email-masked]>
>         https://www.ietf.org/mailman/listinfo/teas<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/teas__;!!NEt6yMaO-gk!S_VvA6mf2AmOIWFf6rkeEuaobWVZxh3S2-X2ThtuXv-jPlkHS-PbYXuK9MiU5Bg$>
>         <https://www.ietf.org/mailman/listinfo/teas<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/teas__;!!NEt6yMaO-gk!S_VvA6mf2AmOIWFf6rkeEuaobWVZxh3S2-X2ThtuXv-jPlkHS-PbYXuK9MiU5Bg$>>
>
>
>
> https://www.ietf.org/mailman/listinfo/teas<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/teas__;!!NEt6yMaO-gk!S_VvA6mf2AmOIWFf6rkeEuaobWVZxh3S2-X2ThtuXv-jPlkHS-PbYXuK9MiU5Bg$>
>

_______________________________________________
Teas mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/teas<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/teas__;!!NEt6yMaO-gk!S_VvA6mf2AmOIWFf6rkeEuaobWVZxh3S2-X2ThtuXv-jPlkHS-PbYXuK9MiU5Bg$>

---

From: "Joel M. Halpern" <[email-masked]>
Date: Sun, 7 Feb 2021 15:50:34 -0500

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?
> *From:* Teas <[email-masked]> on behalf of Joel M. Halpern 
> <[email-masked]>
> *Sent:* Sunday, February 7, 2021 2:15:01 PM
> *To:* Igor Bryskin <i_bryskin=[email-masked]>
> *Cc:* TEAS WG <[email-masked]>
>> Get Outlook for Android <https://aka.ms/ghei36 <https://aka.ms/ghei36>>
>> 
>> <mailto:[email-masked] <mailto:[email-masked]>>> wrote:
>> 
>>     Gyan and Pavan,
>> 
>>     Get Outlook for Android <https://aka.ms/ghei36 <https://aka.ms/ghei36>>
>>     *From:* Teas <[email-masked] <mailto:[email-masked] <mailto:[email-masked]>>>
>>     <mailto:[email-masked] <mailto:[email-masked]>>>
>>     *To:* Gyan Mishra <[email-masked] <mailto:[email-masked] <mailto:[email-masked]>>>
>>     <mailto:[email-masked] <mailto:[email-masked]>>>;
>>     <mailto:[email-masked] 
> <mailto:[email-masked]>>
>>     <mailto:[email-masked] 
> <mailto:[email-masked]>>>; TEAS WG
>>     <[email-masked] <mailto:[email-masked] <mailto:[email-masked]>>>
>>     <mailto:[email-masked] <mailto:[email-masked]>>> wrote:
>> 
>> 
>> 
>>         Dear authors
>> 
>>         <mailto:[email-masked] 
> <mailto:[email-masked]>>> wrote:
>> 
>>             Hi WG,____
>> 
>>             __ __
>> 
>>             <mailto:[email-masked] <mailto:[email-masked]>>" 
> <[email-masked]
>>             <mailto:[email-masked] <mailto:[email-masked]>>> 
> wrote:____
>> 
>>             __ __
>> 
> <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$>>____
>> 
>>                  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$>>____
>> 
>>                  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$>>____
>> 
>>                  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$>>____
>> 
>>             __ __
>> 
>>                  Abstract:____
>> 
>>             tools.ietf.org <http://tools.ietf.org <http://tools.ietf.org>>.____
>> 
>>             __ __
>> 
>>                  The IETF Secretariat____
>> 
>>             __ __
>> 
>>             __ __
>> 
>> 
>>             [email-masked] <mailto:[email-masked] <mailto:[email-masked]>>
>>             <https://www.ietf.org/mailman/listinfo/teas 
> <https://www.ietf.org/mailman/listinfo/teas>>
>> 
>>         -- 
>> 
>>         <http://www.verizon.com/ <http://www.verizon.com/>>
>> 
>>         *Gyan Mishra*
>> 
>>         [email-masked] <mailto:[email-masked] <mailto:[email-masked]>>
>>         <https://www.ietf.org/mailman/listinfo/teas 
> <https://www.ietf.org/mailman/listinfo/teas>>
>> 
>> 
>>

---

From: Igor Bryskin <[email-masked]>
Date: Sun, 7 Feb 2021 21:06:50 +0000

This means that you define slice as logical/abstract single node, rather than logical network. Agree?

Igor

Sent: Sunday, February 7, 2021 3:50:34 PM

Yours,
Joel

---

From: Joel Halpern Direct <[email-masked]>
Date: Sun, 7 Feb 2021 16:20:22 -0500

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:
> *Sent:* Sunday, February 7, 2021 3:50:34 PM
>>> Get Outlook for Android <https://aka.ms/ghei36 <https://aka.ms/ghei36 <https://aka.ms/ghei36>>>
>>> 
>>> <mailto:[email-masked] <mailto:[email-masked] 
> <mailto:[email-masked]>>>> wrote:
>>> 
>>>     Gyan and Pavan,
>>> 
>>>     Get Outlook for Android <https://aka.ms/ghei36 <https://aka.ms/ghei36 <https://aka.ms/ghei36>>>
>>>     *From:* Teas <[email-masked] <mailto:[email-masked] <mailto:[email-masked] 
> <mailto:[email-masked]>>>>
>>>     <mailto:[email-masked] <mailto:[email-masked] 
> <mailto:[email-masked]>>>>
>>>     *To:* Gyan Mishra <[email-masked] <mailto:[email-masked] <mailto:[email-masked] 
> <mailto:[email-masked]>>>>
>>>     <mailto:[email-masked] <mailto:[email-masked] 
> <mailto:[email-masked]>>>>;
> <mailto:[email-masked]>>>
> <mailto:[email-masked]>>>>; TEAS WG
>>>     <[email-masked] <mailto:[email-masked] <mailto:[email-masked] <mailto:[email-masked]>>>>
>>>     <mailto:[email-masked] <mailto:[email-masked] 
> <mailto:[email-masked]>>>> wrote:
>>> 
>>> 
>>> 
>>>         Dear authors
>>> 
> <mailto:[email-masked]>>>> wrote:
>>> 
>>>             Hi WG,____
>>> 
>>>             __ __
>>> 
>>>             <mailto:[email-masked] <mailto:[email-masked] 
> <mailto:[email-masked]>>>"
>>>             <mailto:[email-masked] <mailto:[email-masked] 
> <mailto:[email-masked]>>>>
>> wrote:____
>>> 
>>>             __ __
>>> 
> <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:____
>>> 
>>>             tools.ietf.org <http://tools.ietf.org <http://tools.ietf.org <http://tools.ietf.org>>>.____
>>> 
>>>             __ __
>>> 
>>>                  The IETF Secretariat____
>>> 
>>>             __ __
>>> 
>>>             __ __
>>> 
>>> 
>>>             [email-masked] <mailto:[email-masked] <mailto:[email-masked] <mailto:[email-masked]>>>
> <https://www.ietf.org/mailman/listinfo/teas>>>
>>> 
>>>         -- 
>>> 
>>>         <http://www.verizon.com/ <http://www.verizon.com/ <http://www.verizon.com/>>>
>>> 
>>>         *Gyan Mishra*
>>> 
>>>         [email-masked] <mailto:[email-masked] <mailto:[email-masked] <mailto:[email-masked]>>>
> <https://www.ietf.org/mailman/listinfo/teas>>>
>>> 
>>> 
>>>

---

From: John E Drake <[email-masked]>
Date: Sun, 7 Feb 2021 21:27:33 +0000

Right, the network looks like a point

Sent from my iPhone

On Feb 7, 2021, at 4:07 PM, Igor Bryskin <i_bryskin=[email-masked]> wrote:

Igor

Get Outlook for Android<https://urldefense.com/v3/__https://aka.ms/ghei36__;!!NEt6yMaO-gk!XAib3Ij0cpKEbCZ4YA_kp0I64b-EjDmCf6HtpPiJ9VFvH25jGHUTikb6bNmdcDk$>

Yours,
Joel

On 2/7/2021 3:06 PM, Igor Bryskin wrote:
> Get Outlook for Android <https://aka.ms/ghei36<https://urldefense.com/v3/__https://aka.ms/ghei36__;!!NEt6yMaO-gk!XAib3Ij0cpKEbCZ4YA_kp0I64b-EjDmCf6HtpPiJ9VFvH25jGHUTikb6bNmdcDk$>>
>
>> Get Outlook for Android <https://aka.ms/ghei36 <https://aka.ms/ghei36<https://urldefense.com/v3/__https://aka.ms/ghei36__;!!NEt6yMaO-gk!XAib3Ij0cpKEbCZ4YA_kp0I64b-EjDmCf6HtpPiJ9VFvH25jGHUTikb6bNmdcDk$>>>
>>
>>     Get Outlook for Android <https://aka.ms/ghei36 <https://aka.ms/ghei36<https://urldefense.com/v3/__https://aka.ms/ghei36__;!!NEt6yMaO-gk!XAib3Ij0cpKEbCZ4YA_kp0I64b-EjDmCf6HtpPiJ9VFvH25jGHUTikb6bNmdcDk$>>>
>>             tools.ietf.org <http://tools.ietf.org <http://tools.ietf.org<https://urldefense.com/v3/__http://tools.ietf.org__;!!NEt6yMaO-gk!XAib3Ij0cpKEbCZ4YA_kp0I64b-EjDmCf6HtpPiJ9VFvH25jGHUTikb65yRzRZI$>>>.____
>>
>>             __ __
>>
>>                  The IETF Secretariat____
>>
>>             __ __
>>
>>             __ __
>>
>>
>>             https://www.ietf.org/mailman/listinfo/teas<https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/teas__;!!NEt6yMaO-gk!XAib3Ij0cpKEbCZ4YA_kp0I64b-EjDmCf6HtpPiJ9VFvH25jGHUTikb6nsXBnaw$>
> <https://www.ietf.org/mailman/listinfo/teas<https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/teas__;!!NEt6yMaO-gk!XAib3Ij0cpKEbCZ4YA_kp0I64b-EjDmCf6HtpPiJ9VFvH25jGHUTikb6nsXBnaw$>>
> <https://www.ietf.org/mailman/listinfo/teas<https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/teas__;!!NEt6yMaO-gk!XAib3Ij0cpKEbCZ4YA_kp0I64b-EjDmCf6HtpPiJ9VFvH25jGHUTikb6nsXBnaw$>>>
>>
>>         --
>>
>>         <http://www.verizon.com/ <http://www.verizon.com/<https://urldefense.com/v3/__http://www.verizon.com/__;!!NEt6yMaO-gk!XAib3Ij0cpKEbCZ4YA_kp0I64b-EjDmCf6HtpPiJ9VFvH25jGHUTikb60oPn3ZQ$>>>
>>
>>         *Gyan Mishra*
>>
>>         https://www.ietf.org/mailman/listinfo/teas<https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/teas__;!!NEt6yMaO-gk!XAib3Ij0cpKEbCZ4YA_kp0I64b-EjDmCf6HtpPiJ9VFvH25jGHUTikb6nsXBnaw$>
> <https://www.ietf.org/mailman/listinfo/teas<https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/teas__;!!NEt6yMaO-gk!XAib3Ij0cpKEbCZ4YA_kp0I64b-EjDmCf6HtpPiJ9VFvH25jGHUTikb6nsXBnaw$>>
> <https://www.ietf.org/mailman/listinfo/teas<https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/teas__;!!NEt6yMaO-gk!XAib3Ij0cpKEbCZ4YA_kp0I64b-EjDmCf6HtpPiJ9VFvH25jGHUTikb6nsXBnaw$>>>
>>
>>
>>
>> https://www.ietf.org/mailman/listinfo/teas<https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/teas__;!!NEt6yMaO-gk!XAib3Ij0cpKEbCZ4YA_kp0I64b-EjDmCf6HtpPiJ9VFvH25jGHUTikb6nsXBnaw$>
> <https://www.ietf.org/mailman/listinfo/teas<https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/teas__;!!NEt6yMaO-gk!XAib3Ij0cpKEbCZ4YA_kp0I64b-EjDmCf6HtpPiJ9VFvH25jGHUTikb6nsXBnaw$>>
>>
>
> https://www.ietf.org/mailman/listinfo/teas<https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/teas__;!!NEt6yMaO-gk!XAib3Ij0cpKEbCZ4YA_kp0I64b-EjDmCf6HtpPiJ9VFvH25jGHUTikb6nsXBnaw$>
> <https://www.ietf.org/mailman/listinfo/teas<https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/teas__;!!NEt6yMaO-gk!XAib3Ij0cpKEbCZ4YA_kp0I64b-EjDmCf6HtpPiJ9VFvH25jGHUTikb6nsXBnaw$>>
>
> https://www.ietf.org/mailman/listinfo/teas<https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/teas__;!!NEt6yMaO-gk!XAib3Ij0cpKEbCZ4YA_kp0I64b-EjDmCf6HtpPiJ9VFvH25jGHUTikb6nsXBnaw$>
>

_______________________________________________
Teas mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/teas<https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/teas__;!!NEt6yMaO-gk!XAib3Ij0cpKEbCZ4YA_kp0I64b-EjDmCf6HtpPiJ9VFvH25jGHUTikb6nsXBnaw$>
_______________________________________________
Teas mailing list
[email-masked]
https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/teas__;!!NEt6yMaO-gk!XAib3Ij0cpKEbCZ4YA_kp0I64b-EjDmCf6HtpPiJ9VFvH25jGHUTikb6nsXBnaw$

---

From: "Adrian Farrel" <[email-masked]>
Date: Sun, 7 Feb 2021 21:50:08 -0000

Maybe also look at draft-ietf-teas-enhanced-vpn for some context.

Cheers,
Adrian

-----Original Message-----
From: Teas <[email-masked]> On Behalf Of Joel M. Halpern
Sent: 07 February 2021 20:51
To: Igor Bryskin <i_bryskin=[email-masked]>
Cc: TEAS WG <[email-masked]>
Subject: Re: [Teas] FW: New Version Notification for draft-bestbar-teas-ns-packet-01.txt

Yours,
Joel

---

From: "Dongjie (Jimmy)" <[email-masked]>
Date: Mon, 8 Feb 2021 03:56:46 +0000

Agree that the delivery of a network slice with IETF technologies is likely via a VPN with a set of connectivity and QoS requirements. To provide such a VPN service, technologies in different layers needs to be combined, the overlay and underlay resources needs to be integrated. This may or may not be exposed to the customer. More about this is described in draft-ietf-teas-enhanced-vpn, an updated revision of which is coming soon. 

Best regards,
Jie

> From: Teas [mailto:[email-masked]] On Behalf Of Adrian Farrel
> Sent: Monday, February 8, 2021 5:50 AM
> To: 'Igor Bryskin' <i_bryskin=[email-masked]>
> Cc: 'TEAS WG' <[email-masked]>
> 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
> 
> > 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?
> > 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
> >
> >> - that a node, generally speaking, needs to make a forwarding
> >> decision based on the packet's slice topology;
> >> Therefore. It is better, in my opinion, to carry slice ID in packets
> >> and let nodes (re-)define slice aggregate membership independently.
> >>
> >> Igor
> >>
> >> 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.
> >>
> >>
> >> [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
> >>
> >>     *To:* Gyan Mishra <[email-masked]
> <mailto:[email-masked] <mailto:[email-masked]>>>
> <mailto:[email-masked]>>>;
> >> https://urldefense.com/v3/__https://www.ietf.org/archive/id/draft-bes
> >> tbar-teas-ns-packet-01.txt__;!!NEt6yMaO-gk!UopixISsH-6laFtUNIg5vIaLsX
> >> zFthS8C65TCDCRk-5ayO6AAa-8IPzvuhQQRw$
> > <https://urldefense.com/v3/__https://www.ietf.org/archive/id/draft-bes
> > tbar-teas-ns-packet-01.txt__;!!NEt6yMaO-gk!UopixISsH-6laFtUNIg5vIaLsXz
> > FthS8C65TCDCRk-5ayO6AAa-8IPzvuhQQRw$>
> >>
> >> <https://urldefense.com/v3/__https://www.ietf.org/archive/id/draft-be
> >> stbar-teas-ns-packet-01.txt__;!!NEt6yMaO-gk!UopixISsH-6laFtUNIg5vIaLs
> >> XzFthS8C65TCDCRk-5ayO6AAa-8IPzvuhQQRw$
> > <https://urldefense.com/v3/__https://www.ietf.org/archive/id/draft-bes
> > tbar-teas-ns-packet-01.txt__;!!NEt6yMaO-gk!UopixISsH-6laFtUNIg5vIaLsXz
> > FthS8C65TCDCRk-5ayO6AAa-8IPzvuhQQRw$>>____
> >>
> >>                  Status:
> >>
> >> https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-be
> >> stbar-teas-ns-packet/__;!!NEt6yMaO-gk!UopixISsH-6laFtUNIg5vIaLsXzFthS
> >> 8C65TCDCRk-5ayO6AAa-8IPwWnIEvoQ$
> > <https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-be
> > stbar-teas-ns-packet/__;!!NEt6yMaO-gk!UopixISsH-6laFtUNIg5vIaLsXzFthS8
> > C65TCDCRk-5ayO6AAa-8IPwWnIEvoQ$>
> >>
> >> <https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-b
> >> estbar-teas-ns-packet/__;!!NEt6yMaO-gk!UopixISsH-6laFtUNIg5vIaLsXzFth
> >> S8C65TCDCRk-5ayO6AAa-8IPwWnIEvoQ$
> > <https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-be
> > stbar-teas-ns-packet/__;!!NEt6yMaO-gk!UopixISsH-6laFtUNIg5vIaLsXzFthS8
> > C65TCDCRk-5ayO6AAa-8IPwWnIEvoQ$>>____
> >>
> >>                  Htmlized:
> >>
> >> https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/dra
> >> ft-bestbar-teas-ns-packet__;!!NEt6yMaO-gk!UopixISsH-6laFtUNIg5vIaLsXz
> >> FthS8C65TCDCRk-5ayO6AAa-8IPxBddbTdg$
> > <https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/dra
> > ft-bestbar-teas-ns-packet__;!!NEt6yMaO-gk!UopixISsH-6laFtUNIg5vIaLsXzF
> > thS8C65TCDCRk-5ayO6AAa-8IPxBddbTdg$>
> >>
> >> <https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/dr
> >> aft-bestbar-teas-ns-packet__;!!NEt6yMaO-gk!UopixISsH-6laFtUNIg5vIaLsX
> >> zFthS8C65TCDCRk-5ayO6AAa-8IPxBddbTdg$
> > <https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/dra
> > ft-bestbar-teas-ns-packet__;!!NEt6yMaO-gk!UopixISsH-6laFtUNIg5vIaLsXzF
> > thS8C65TCDCRk-5ayO6AAa-8IPxBddbTdg$>>____
> >>
> >>                  Htmlized:
> >>
> >> https://urldefense.com/v3/__https://tools.ietf.org/html/draft-bestbar
> >> -teas-ns-packet-01__;!!NEt6yMaO-gk!UopixISsH-6laFtUNIg5vIaLsXzFthS8C6
> >> 5TCDCRk-5ayO6AAa-8IPznNKoLDg$
> > <https://urldefense.com/v3/__https://tools.ietf.org/html/draft-bestbar
> > -teas-ns-packet-01__;!!NEt6yMaO-gk!UopixISsH-6laFtUNIg5vIaLsXzFthS8C65
> > TCDCRk-5ayO6AAa-8IPznNKoLDg$>
> >>
> >> <https://urldefense.com/v3/__https://tools.ietf.org/html/draft-bestba
> >> r-teas-ns-packet-01__;!!NEt6yMaO-gk!UopixISsH-6laFtUNIg5vIaLsXzFthS8C
> >> 65TCDCRk-5ayO6AAa-8IPznNKoLDg$
> > <https://urldefense.com/v3/__https://tools.ietf.org/html/draft-bestbar
> > -teas-ns-packet-01__;!!NEt6yMaO-gk!UopixISsH-6laFtUNIg5vIaLsXzFthS8C65
> > TCDCRk-5ayO6AAa-8IPznNKoLDg$>>____
> >>
> >>                  Diff:
> >>
> >> https://urldefense.com/v3/__https://www.ietf.org/rfcdiff?url2=draft-b
> >> estbar-teas-ns-packet-01__;!!NEt6yMaO-gk!UopixISsH-6laFtUNIg5vIaLsXzF
> >> thS8C65TCDCRk-5ayO6AAa-8IPzsN9oeaw$
> > <https://urldefense.com/v3/__https://www.ietf.org/rfcdiff?url2=draft-b
> > estbar-teas-ns-packet-01__;!!NEt6yMaO-gk!UopixISsH-6laFtUNIg5vIaLsXzFt
> > hS8C65TCDCRk-5ayO6AAa-8IPzsN9oeaw$>
> >>
> >> <https://urldefense.com/v3/__https://www.ietf.org/rfcdiff?url2=draft-
> >> bestbar-teas-ns-packet-01__;!!NEt6yMaO-gk!UopixISsH-6laFtUNIg5vIaLsXz
> >> FthS8C65TCDCRk-5ayO6AAa-8IPzsN9oeaw$
> > <https://urldefense.com/v3/__https://www.ietf.org/rfcdiff?url2=draft-b
> > estbar-teas-ns-packet-01__;!!NEt6yMaO-gk!UopixISsH-6laFtUNIg5vIaLsXzFt
> > hS8C65TCDCRk-5ayO6AAa-8IPzsN9oeaw$>>____
> >>
> >>             __ __
> >>
> >>                  Abstract:____
> >>

---

From: Vishnu Pavan Beeram <[email-masked]>
Date: Mon, 8 Feb 2021 03:55:45 -0600

@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 <
[email-masked]> wrote:

> and
> policy)
> >>>     I also agree with Gyan that the COS field may not be the best
> choice
> >>>     for the task.
> >>>
> >>>
> >>>     Get Outlook for Android <https://aka.ms/ghei36 <
> https://aka.ms/ghei36 <https://aka.ms/ghei36>>>
> >>>
> >>>     *To:* Gyan Mishra <[email-masked] <mailto:
> [email-masked] <mailto:[email-masked]
> >>>     Thanks for taking the time to review the document. Please see
> inline
> >>>     for responses (prefixed VPB).
> >>>
> >>>     Regards,
> >>>     -Pavan (as a co-author)
> >>>
> > <
> 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://datatracker.ietf.org/doc/draft-bestbar-teas-ns-packet/__;!!NEt6yMaO-gk!UopixISsH-6laFtUNIg5vIaLsXzFthS8C65TCDCRk-5ayO6AAa-8IPwWnIEvoQ$>
>
> >
> >> <
> > <
> >>>             <
> >> <
> > <
> >>>____
> > <
> 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://tools.ietf.org/html/draft-bestbar-teas-ns-packet-01__;!!NEt6yMaO-gk!UopixISsH-6laFtUNIg5vIaLsXzFthS8C65TCDCRk-5ayO6AAa-8IPznNKoLDg$>
>
> >
> >> <
> > <
> >>>             <
> >> <
> > <
> >>>____
> > <
> https://urldefense.com/v3/__https://www.ietf.org/rfcdiff?url2=draft-bestbar-teas-ns-packet-01__;!!NEt6yMaO-gk!UopixISsH-6laFtUNIg5vIaLsXzFthS8C65TCDCRk-5ayO6AAa-8IPzsN9oeaw$>
>
> >
> >> <
> > <
> >>>             <
> >> <
> > <
> >>>____
> >>>             tools.ietf.org <http://tools.ietf.org <
> http://tools.ietf.org <http://tools.ietf.org>>>.____
> >>>
> >>>             __ __
> >>>
> >>>                  The IETF Secretariat____
> >>>
> >>>             __ __
> >>>
> >>>             __ __
> >>>
> >>>

---

From: Young Lee <[email-masked]>
Date: Mon, 8 Feb 2021 19:32:43 +0900

Please also look at:
https://tools.ietf.org/html/draft-ietf-teas-actn-vn-yang-10

and

https://tools.ietf.org/html/draft-king-teas-applicability-actn-slicing-03

for a larger scope as to how to apply ACTN to network slicing. This was
also Luis' request in the adoption call on the network slicing framework
draft. We need to synchronize the existing WG documemts as much as possible
to avoid confusion and duplicate efforts.

Thanks.
Young

2021년 2월 8일 (월) 오전 6:50, Adrian Farrel <[email-masked]>님이 작성:

> https://aka.ms/ghei36>>
> [email-masked] <mailto:[email-masked]>>>
> wrote:
> http://tools.ietf.org>>.____
> >>
> >>             __ __
> >>
> >>                  The IETF Secretariat____
> >>
> >>             __ __
> >>
> >>             __ __
> >>
> >>

---

From: Igor Bryskin <[email-masked]>
Date: Mon, 8 Feb 2021 14:58:10 +0000 (UTC)

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=[email-masked]> 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. 

 
Yours Irrespectively,

John

 

 
Thanks Joel,

 
Thanks,
 
Igor
 
GetOutlook for Android

 
I disagree.

Yours,
Joel

On 2/7/2021 1:58 PM, Igor Bryskin wrote:
> <mailto:[email-masked]>> wrote:
> 
>     Gyan and Pavan,
> 
>     <mailto:[email-masked]>> wrote:
> 
> 
> 
>         Dear authors
>

---

From: John E Drake <[email-masked]>
Date: Mon, 8 Feb 2021 16:04:33 +0000

Igor,

I think the definition needs a little work.  It’s really no different than today’s VPNs, which are opaque to the customer.  Service functions could be added within the provider network as specified by an agreement between the customer and the provider without the customer knowing where or how they are instantiated within the provider network.

Yours Irrespectively,

John

Juniper Business Use Only
From: Teas <[email-masked]> On Behalf Of Igor Bryskin
Sent: Monday, February 8, 2021 9:58 AM
To: Joel M. Halpern <[email-masked]>; John E Drake <jdrake=[email-masked]>
Cc: TEAS WG <[email-masked]>
Subject: Re: [Teas] FW: New Version Notification for draft-bestbar-teas-ns-packet-01.txt

Hi John,

"

An IETF network slice is a logical network topology connecting a

   (SLOs).

"

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=[email-masked]<mailto:jdrake=[email-masked]>> wrote:

Igor,

Please see:  https://datatracker.ietf.org/doc/html/draft-ietf-teas-ietf-network-slice-definition-00<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-ietf-teas-ietf-network-slice-definition-00__;!!NEt6yMaO-gk!TMLvcQszUxXi_HEDqcX_-7X61giV5_sil4o5LjMZ4o0o2CxnuGGnfy1x_9y2Sic$>  and https://datatracker.ietf.org/doc/html/draft-nsdt-teas-ns-framework-05<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-nsdt-teas-ns-framework-05__;!!NEt6yMaO-gk!TMLvcQszUxXi_HEDqcX_-7X61giV5_sil4o5LjMZ4o0o2CxnuGGnfy1x7yWosOM$>.

Yours Irrespectively,

John

From: Teas <[email-masked]<mailto:[email-masked]>> On Behalf Of Igor Bryskin
Sent: Sunday, February 7, 2021 3:07 PM
To: Igor Bryskin <i_bryskin=[email-masked]<mailto:i_bryskin=[email-masked]>>; Joel M. Halpern <[email-masked]<mailto:[email-masked]>>
Cc: TEAS WG <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Teas] FW: New Version Notification for draft-bestbar-teas-ns-packet-01.txt

Thanks Joel,

Thanks,

Igor

I disagree.

Yours,
Joel

---

From: Gyan Mishra <[email-masked]>
Date: Tue, 9 Feb 2021 20:57:46 -0500

Hi Pavan

I read the draft a few times to try to understand what the benefit of using
the QOS PHP CS would be for the instantiation or a network slice by the
slice controller.  In my mind I think you can accomplish the instantiation
of the network slices which can be done without the use of any concept of a
slice selector control plane mode or data plane mode without slice selector
using CS.

See draft below of how the network slice can be provisioned using BGP-LS.

https://datatracker.ietf.org/doc/draft-drake-bess-enhanced-vpn/

I think I have a little better understanding of leveraging the QOS diffserv
model CS using a Network Slice controller concept of a slice selector using
QOS CS selector packet marking as means of mapping overlay VPN or
aggregation of VPNs the same SLA called an aggregate slice  to underlay
resources slice  with some degree of hard isolation.

I think the disconnect I am having is the use of QOS DSCP PHB scheduling
that exists for customer flows.  So let’s say an operator has 10 different
QOS service models that provisions to its customers Gold, Bronze, Silver
etc and each one has different discrete CS AF or EF that are voice or video
centric or data centric or a mix.  So now the customer packets on ingress
get mapped to the QOS IP SLAs provisioned.  What does seem to be a gap is
in the use of DSCP for slice selector is that a customer may have many
markings on their packet that map to a particular provider class of service
offering which will still be made up of up to 8 classes.  So how do you
know what slice selector to use.  In the framework of RG RAN and core there
may still be multiple classes for the 3GPP user plane traffic.  So how does
that mapping work as you may have multiple CS values and corresponding
queues which all have different forwarding treatment and bandwidth in
profile requirements.  So is all traffic for a network slice mapped to a
single slice selector but then how is that slice selector determined is the
problem if you have multiple classes CS values which is always the case.
I don’t think the data plane mode is valid since it used CS which is in the
customer payload and the control plane mode how do you determine what slice
selector to use when their are multiple CS values which as I said is common
for any operator SLA given to a customer.

Another point I want to make is that with MPLS the payload had the customer
packet inner encapsulation or on SR case SR-MPLS or SRv6 it is the payload
that had the CS.  Throughout the operator core PHB the customer QOS marking
CS value is only seen at the ingress edge node and once the remark happens
DSCP to EXP to the customer SLA chosen for provisioning, within the core
the MPLS label stack topmost transport label contains EXP marking and not
CS markings.  This is true as well for IP based SRv6 as the identical
remark happens with SRv6 Ingres source node as happens with MPLS but not
you have 64 bit dscp values to play with versus the limitations of 8 EXP
bits.  So bottom line is that this draft is referring to the customer
packet CS marking which is not visible or acted on PHB within the core as
it sits in the payload.

So what seems to be described here is DS TE model RFC 4124 RDM and MAM
models mapping customer flows to RSVP TE tunnels.  So in this case the
overlay VPN is mapped to underlay DS TE tunnel based on IP SLA
requirements.  How is this draft provide a greater degree or improvement as
far as granularity of  achieving hard isolation of resources allocated
dedicated to the VPN or aggregate of VPNs with the same SLA.  The advantage
of DS TE over this draft is that at ingress the packets CS is mapped to EXP
which then the VPN is then mapped to discrete DS  TE tunnels.  Also the
core does not have to be CS aware and their is no concept of CS as that is
within the customer packet that is preserved end to end untouched.

Responses in-line

Thank you

Gyan

> deployments, please refer to draft-bestbar-spring-scalable-ns.

Gyan> Understood.  To be more clear my suggestion is to state SRv6 as IPv6
data plane although it used by SRv6 it can be used for global table routing
where VPN overlay does not exist.  Similarly MPLS is vague as it can be
used for LDPv4 LDPv6 and do to be more clear it is better to specify
RSVP-TE clearly as the topmost label or SR-MPLS which reuses MPLS data
plane using SR-TE binding sid for ERO path instantiation.

> (scheduling treatment and drop probability). But this is not needed in mode

Gyan> Understood.  See my comments at the top of this reply.

> traffic – this is where the Data Plane Slice Policy Mode comes into play.

Gyan> Understood.  See my comments at the top of my reply.

Kind Regards
>>> allocation.
>> *M 301 502-134713101 Columbia Pike
>> <https://www.google.com/maps/search/13101+Columbia+Pike?entry=gmail&source=g> *Silver
>> Spring, MD
>>

*Gyan Mishra*