Subject: [Netslices] Some comments on draft-qiang-netslices-gap-analysis

From: Lou Berger <[email-masked]>
Date: Sun, 9 Jul 2017 15:08:05 -0400

Hi,

With all they "excitement" on slicing I'm sure there is work to be done
on the topic, but I think it would be good for such work to build on
(and at worst, understand) the IETF technology/RFCs.  In reading this
draft, I really felt like the authors were not familiar with the
substantive work that has been on TE networks over the years, notably:

- Section 5.2 cross domain coordination

There are many years of work and related RFCs in this area in IETF TE
that are missing from the 'gap analysis' .  I suggest reading RFC7926 as
a good primer on existing RFCs as well as some background that predates
the current TEAS ACTN work.

- WRT Section 6.2.1 and 2.3 

MPLS-TE solutions are broader than just signaling, i.e., routing is just
as important.  RCF7926 has sufficient pointers to good references for
this.  On a more specific note, this section is missing the intersection
of VPNs and RSVP-TE and L3VPNs, see RFC 6882.  Even more notably, the
section is missing that TE LSPs can support the Guaranteed Quality of
Service defined by RFC2212 (even if some vendors choose not to implement
it), GS is defined as:

   Guaranteed service provides firm (mathematically provable)
   bounds on end-to-end datagram queueing delays.  This service makes it
   possible to provide a service that guarantees both delay and
   bandwidth.

- Also, separately and in the context of Section 6.2.5

I think the 1st paragraph of correctly states that DetNet is concerned
with "low packet loss rates, low packet  delay variation (jitter) and
assured maximum end-to-end delivery latency." (leveraging existing RFCs
to the maximum extent possible.)  But much of the rest of the section
contradicts this and I really can't seem to parse the 2nd paragraph in
any way that makes sense in the context of detnet or delivering low
loss, low jitter and deterministic latency.

Also,  I suggest referencing 802.1TSN in the context or DetNet or
independently.  FWIW there is an 802.1 TSN tutorial scheduled for Sunday
(1345-1445 in Congress Hall III) and we'll be spending some time in the
DetNet WG session on understanding 802.1 TSN's flow
requirements/capabilities and how to they might be leveraged (and
support) by DetNet.

- finally, WRT timing

I'd think mentioned 1588 and other related time sync work in IETF could
be relevant.

Lou

---

From: Daniele Ceccarelli <[email-masked]>
Date: Mon, 10 Jul 2017 13:06:16 +0000

Hi all,

while i totally share Lou's point of view I'd like to add some references that might help understanding what is already there and possibly targeting a better gap analysis.

The 9 requirements shown in table 1 and mapped against 4 KEY requirements are very valuable but I struggle to see the difference between them and the ACTN requirements ,where we have 8 service-related requirements and 5 network-related requirements (https://tools.ietf.org/html/draft-ietf-teas-actn-requirements-05 WG document since Oct 2015).

When it comes to the solutions for those requirements Lou correctly pointed out at RFC 7926 (Problem Statement and Architecture for Information Exchange between Interconnected Traffic-Engineered Networks) and on the TEAS WG and PCE WG pages you can find a number of documents including framework, abstraction methods, info model, interfaces, applicability of PCE and YANG models to ACTN, telemetry. In particular I'd like to mention the ACTN VN, which is a construct that sees to address many of the requirements for the network slicing. 

My analysis of the gaps is as follows (please correct what I'm missing).
Req 1 - Network Slicing Specification: To me this looks like exactly an ACTN Virtual Network. In section 4.1 one thing that I understand to be missing to the VN is the reachability scope (limited scope vs Internet-wide).
Req 2 - Network Slicing Cross-Domain Coordination: This seems to be one of the MDSC functionalities, actually the most important.
Req 3 - Network Slicing Performance Guarantee and Isolation: This is a target that can be reached via a Virtual Network, where resources can be dedicated to a slice or shared among slices and the computation done with constraints. Extensions for VN Telemetry are already available (even if this is at an earlier stage).
Req 4 - Network Slicing OAM (NS-OAM). Being the VN members defined as a set of stitched tunnels and LSPs the OAM tools available for tunnels and LSPs are automatically inherited.

Two more detailed comments:

1. Section  5.2.3.
It is said that: " However, ACTN focuses on resource
   abstraction and management on Layer 2 and Layer 1.  For transport
   network slicing, resources abstraction and management on Layer 3+
   (e.g., IP routing table, etc.) may also be necessary but have not
   been addressed by ACTN."
I don't know where MPLS is positioned in your analysis (according to some people it's layer 2, to some others it's 2.5, and someone believes it's layer 3), but ACTN covers any kind of TE technology, including MPLS-TE and SR-TE. Building a slice without TE, well, it can be done, but how is it possible to guarantee KPIs, SLA, and so on? 

2. Section 6.2.3.
It is said that: "RSVP-TE LSPs can be used as the underlay tunnels
   of the VPN service connections.  However, the requirement of some
   emerging services is not only about traffic bandwidth, but also has
   quite strict requirement on latency, jitter, etc.  Such requirements
   can hardly be met with existing RSVP-TE."
RSVP-TE is used to reserve the resource along the path meeting the required constraints. If such path exists, RSVP-TE can reserve it, otherwise no one can.

Hence my disagreement with the conclusions in Table 2.

Thank you
Daniele  

-----Original Message-----
From: Netslices [mailto:[email-masked]] On Behalf Of Lou Berger
Sent: domenica 9 luglio 2017 21:08
To: [email-masked]
Subject: [Netslices] Some comments on draft-qiang-netslices-gap-analysis

Hi,

With all they "excitement" on slicing I'm sure there is work to be done on the topic, but I think it would be good for such work to build on (and at worst, understand) the IETF technology/RFCs.  In reading this draft, I really felt like the authors were not familiar with the substantive work that has been on TE networks over the years, notably:

There are many years of work and related RFCs in this area in IETF TE that are missing from the 'gap analysis' .  I suggest reading RFC7926 as a good primer on existing RFCs as well as some background that predates the current TEAS ACTN work.

MPLS-TE solutions are broader than just signaling, i.e., routing is just as important.  RCF7926 has sufficient pointers to good references for this.  On a more specific note, this section is missing the intersection of VPNs and RSVP-TE and L3VPNs, see RFC 6882.  Even more notably, the section is missing that TE LSPs can support the Guaranteed Quality of Service defined by RFC2212 (even if some vendors choose not to implement it), GS is defined as:

I think the 1st paragraph of correctly states that DetNet is concerned with "low packet loss rates, low packet  delay variation (jitter) and assured maximum end-to-end delivery latency." (leveraging existing RFCs to the maximum extent possible.)  But much of the rest of the section contradicts this and I really can't seem to parse the 2nd paragraph in any way that makes sense in the context of detnet or delivering low loss, low jitter and deterministic latency.

Also,  I suggest referencing 802.1TSN in the context or DetNet or independently.  FWIW there is an 802.1 TSN tutorial scheduled for Sunday
(1345-1445 in Congress Hall III) and we'll be spending some time in the DetNet WG session on understanding 802.1 TSN's flow requirements/capabilities and how to they might be leveraged (and
support) by DetNet.

- finally, WRT timing

I'd think mentioned 1588 and other related time sync work in IETF could be relevant.

Lou

_______________________________________________
Netslices mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/netslices

---

From: Alex Galis <[email-masked]>
Date: Mon, 10 Jul 2017 16:34:41 +0100

Hi Lou, Daniele and All

Thank you for your constructive comments  and views.

Please note that there are references and suggestions on how ACTN tenologieies could be used in part for Network Slicing in the following drafts:

• Network Slicing - Revised Problem Statement draft-galis-netslices-revised-problem-statement-01
• Network Slicing Architecture draft-geng-netslices-architecture-02
• Network Slicing Use Cases: Network Customization and Differentiated Services draft-netslices-usecases-01

Please also note that we are not proposing an other VPN++ or an other overlay to be defined /designed at IETF. What would be the point of such unnecessary proposals  which would create at best yet an other network with best effort support for all services?

Some of the requirements for NetSlicing are similar to ACTN requirements however they differ in the following key characterisations:
• NS is mainly an in-band management concept in support  well at least one service at a given time. It is also coordinating/orchestrating network functions and resources.

• NS is dynamically and non-disruptively reprovisioned.

• Network slices are concurrently deployed as multiple logical, self-contained and independent, partitioned network & service functions and resources (connectivity, storage and computation  resources) a common physical infrastructure in order to support well at least one service at a given time.

* NS has as the ability to dynamically expose and possibly negotiate the parameters that characterise an network slice. Network slices are configurable and programmable.

• NS has its own operator that sees it as a complete network infrastructure and to use part of the network resources to meet stringent resource requirements.

• NS is supporting tenant(s) that are strongly independent on infrastructure.

• NS is introducing an additional layer of abstraction by the creation of logically or physically isolated groups of network resources and network function/virtual network functions configurations separating its behaviour from the underlying physical network.  

As such NS is not an overlay or an underlay (i.e. a VPN++)

I hope that the above would be of help to you.

Best Regards
Alex

> On 10 Jul 2017, at 14:06, Daniele Ceccarelli <[email-masked]> wrote:
> 
> Hi all,
> 
> Req 1 - Network Slicing Specification: To me this looks like exactly an Ato be CTN Virtual Network. In section 4.1 one thing that I understand to be missing to the VN is the reachability scope (limited scope vs Internet-wide).

---

From: Stewart Bryant <[email-masked]>
Date: Mon, 10 Jul 2017 17:08:09 +0100

On 10/07/2017 16:34, Alex Galis wrote:
> Please note that there are references and suggestions on how ACTN 
> tenologieies could be used in part for Network Slicing in the 
> following drafts:
>
> • Network Slicing - Revised Problem 
> Statement draft-galis-netslices-revised-problem-statement-01
> • Network Slicing Use Cases: Network Customization and 
> Differentiated Services draft-netslices-usecases-01

How is that relevant to these slides, they do not talk about ACTN.

>
> Please also note that we are not proposing an other VPN++ or an other 
> overlay to be defined /designed at IETF. What would be the point of 
> such unnecessary proposals  which would create at best yet an 
> other network with best effort support for all services?

I am talking about VPN+, these new slides do not. Although the issue of 
how you instantiate your ideas in the dataplane is something I look 
forward to you explaining to us. Here I don't want a pointer to an 
obscure theoretical text. If you were asked to build a physical system 
to shift the bits in a project starting the week after IETF, how would 
you do it?

>
> Some of the requirements for NetSlicing are similar to ACTN 
> requirements however they differ in the following key characterisations:
>
> • NS is mainly an in-band management concept in support  well at least 
> one service at a given time. It is also coordinating/orchestrating 
> network functions and resources.
>

Don't you immediately hit Turing's problem with that? You need to create 
the service out of band, and you are going to have to do a lot of other 
management out of band?

> • NS is dynamically and non-disruptively reprovisioned.

I don't think we have said otherwise, although I don't see how you 
achieve that in a strict definition of non-disruptive. Indeed I think 
that you can prove that this is infeasible. For example if you 
reprovision a path to one with greater capacity (or less capacity to 
free up unused resources) how you avoid the latency change or packet 
misorder?

> • Network slices are concurrently deployed as multiple logical, 
> self-contained and independent, partitioned network & service 
> functions and resources (connectivity, storage and computation 
>  resources) a common physical infrastructure in order to support well 
> at least one service at a given time.
>

What does that mean in practice? I really think you need to show us data 
plane types how you achieve that.

> * NS has as the ability to dynamically expose and possibly negotiate 
> the parameters that characterise an network slice. Network slices are 
> configurable and programmable.
>

We agree, show me where the slides say otherwise?

> • NS has its own operator that sees it as a complete network 
> infrastructure and to use part of the network resources to meet 
> stringent resource requirements.
>

The devil is in the detail here which I look forward to you describing 
to the rest of us.

> • NS is supporting tenant(s) that are strongly independent on 
Where has anyone said otherwise?

> • NS is introducing an additional layer of abstraction by the creation 
> of logically or physically isolated groups of network resources and 
> network function/virtual network functions configurations separating 
> its behaviour from the underlying physical network.
>
I think you need to explain that to us, or at least to me a little more 
clearly. All abstractions need to resolve to the physics of the service, 
so lets understand what your statement means in practical terms.

> As such NS is not an overlay or an underlay (i.e. a VPN++)

OK, put your description of  the physics on the table, because I can 
guarantee you will get that question at the BOF.

> I hope that the above would be of help to you.

No, I need to understand how I actually build one of these systems, and 
in none of your work have you explained to me how you get a tenant's 
packets from A to B with the constraints you propose. So without 
reference to am obscure text please explain how we generate the the 
physical realization of one of these systems?

Best Regards

- Stewart
>
> Best Regards
> Alex
>
>
>
>> On 10 Jul 2017, at 14:06, Daniele Ceccarelli 
>> <[email-masked] 
>> <mailto:[email-masked]>> wrote:
>>
>> Hi all,
>>
>> while i totally share Lou's point of view I'd like to add some 
>> references that might help understanding what is already there and 
>> possibly targeting a better gap analysis.
>>
>> The 9 requirements shown in table 1 and mapped against 4 KEY 
>> requirements are very valuable but I struggle to see the difference 
>> between them and the ACTN requirements ,where we have 8 
>> service-related requirements and 5 network-related requirements 
>> (https://tools.ietf.org/html/draft-ietf-teas-actn-requirements-05 WG 
>> document since Oct 2015).
>>
>> When it comes to the solutions for those requirements Lou correctly 
>> pointed out at RFC 7926 (Problem Statement and Architecture for 
>> Information Exchange between Interconnected Traffic-Engineered 
>> Networks) and on the TEAS WG and PCE WG pages you can find a number 
>> of documents including framework, abstraction methods, info model, 
>> interfaces, applicability of PCE and YANG models to ACTN, telemetry. 
>> In particular I'd like to mention the ACTN VN, which is a construct 
>> that sees to address many of the requirements for the network slicing.
>>
>> Req 1 - Network Slicing Specification: To me this looks like exactly 
>> an Ato be CTN Virtual Network. In section 4.1 one thing that I 
>> understand to be missing to the VN is the reachability scope (limited 
>> scope vs Internet-wide).
>> Req 2 - Network Slicing Cross-Domain Coordination: This seems to be 
>> one of the MDSC functionalities, actually the most important.
>> Req 3 - Network Slicing Performance Guarantee and Isolation: This is 
>> a target that can be reached via a Virtual Network, where resources 
>> can be dedicated to a slice or shared among slices and the 
>> computation done with constraints. Extensions for VN Telemetry are 
>> already available (even if this is at an earlier stage).
>> Req 4 - Network Slicing OAM (NS-OAM). Being the VN members defined as 
>> a set of stitched tunnels and LSPs the OAM tools available for 
>> tunnels and LSPs are automatically inherited.
>>
>> I don't know where MPLS is positioned in your analysis (according to 
>> some people it's layer 2, to some others it's 2.5, and someone 
>> believes it's layer 3), but ACTN covers any kind of TE technology, 
>> including MPLS-TE and SR-TE. Building a slice without TE, well, it 
>> can be done, but how is it possible to guarantee KPIs, SLA, and so on?
>>
>>
>> 2. Section 6.2.3.
>> RSVP-TE is used to reserve the resource along the path meeting the 
>> required constraints. If such path exists, RSVP-TE can reserve it, 
>> otherwise no one can.
>>
>> To: [email-masked] <mailto:[email-masked]>
>> With all they "excitement" on slicing I'm sure there is work to be 
>> done on the topic, but I think it would be good for such work to 
>> build on (and at worst, understand) the IETF technology/RFCs.  In 
>> reading this draft, I really felt like the authors were not familiar 
>> with the substantive work that has been on TE networks over the 
>> years, notably:
>>
>> that are missing from the 'gap analysis' .  I suggest reading RFC7926 
>> as a good primer on existing RFCs as well as some background that 
>> predates the current TEAS ACTN work.
>>
>> MPLS-TE solutions are broader than just signaling, i.e., routing is 
>> just as important.  RCF7926 has sufficient pointers to good 
>> references for this.  On a more specific note, this section is 
>> missing the intersection of VPNs and RSVP-TE and L3VPNs, see RFC 
>> 6882.  Even more notably, the section is missing that TE LSPs can 
>> support the Guaranteed Quality of Service defined by RFC2212 (even if 
>> some vendors choose not to implement it), GS is defined as:
>>
>> I think the 1st paragraph of correctly states that DetNet is 
>> concerned with "low packet loss rates, low packet  delay variation 
>> (jitter) and assured maximum end-to-end delivery latency." 
>> (leveraging existing RFCs to the maximum extent possible.)  But much 
>> of the rest of the section contradicts this and I really can't seem 
>> to parse the 2nd paragraph in any way that makes sense in the context 
>> of detnet or delivering low loss, low jitter and deterministic latency.
>>
>> (1345-1445 in Congress Hall III) and we'll be spending some time in 
>> the DetNet WG session on understanding 802.1 TSN's flow 
>> [email-masked] <mailto:[email-masked]>

---

From: Lou Berger <[email-masked]>
Date: Mon, 10 Jul 2017 12:57:37 -0400

> tenologieies could be used in part for Network Slicing in the

Umm, ACTN was not really the main subject of my email.  It was more
about the full breadth of IETF TE technologies (of which ACTN is a
recent addition), the existence of Guaranteed Service (RFC2212) and
scope of DetNet...

Lou

---

From: Lou Berger <[email-masked]>
Date: Mon, 10 Jul 2017 13:11:25 -0400

Stewart,

    Your mail is a bit hard to follow as it seems that you are
disagreeing with Alex's comments but attributing them to Daniel.

It seems you are really just trying to understand data plane details,
and I suspect you are more interested in traffic handling vs marking. Is
this correct?  If so, I suggest starting with RFC2112 for the IETF
definition of a bonded delay and bandwidth service and to see where
detnet headed see 802.1 TSN (http://www.ieee802.org/1/ -- there is even
802.1CM - Time-Sensitive Networking for Fronthaul). 

If you're interested in marking, existing TE solutions are MPLS based
(control can be whatever you'd like) and DetNet is currently planning
MPLS+PWs and IPv6.

Lou

PS In case you missed it: There is an 802.1 TSN tutorial scheduled for
Sunday
(1345-1445 in Congress Hall III) and we'll be spending some time in the
DetNet WG session on understanding 802.1 TSN's flow
requirements/capabilities and how to they might be leveraged (and
support) by DetNet.

On 7/10/2017 12:08 PM, Stewart Bryant wrote:
> I am talking about VPN+, these new slides do not. Although the issue
> of how you instantiate your ideas in the dataplane is something I look
>> • NS is mainly an in-band management concept in support  well at
>> least one service at a given time. It is also
>> coordinating/orchestrating network functions and resources.
>>
>
> Don't you immediately hit Turing's problem with that? You need to
> create the service out of band, and you are going to have to do a lot
> of other management out of band?
>
> What does that mean in practice? I really think you need to show us
> data plane types how you achieve that.
>
>> • NS is introducing an additional layer of abstraction by the
>> creation of logically or physically isolated groups of network
>> resources and network function/virtual network functions
>> configurations separating its behaviour from the underlying physical
>> network. 
>>
> I think you need to explain that to us, or at least to me a little
> more clearly. All abstractions need to resolve to the physics of the
> service, so lets understand what your statement means in practical terms.
>
> No, I need to understand how I actually build one of these systems,
> and in none of your work have you explained to me how you get a
> tenant's packets from A to B with the constraints you propose. So
> without reference to am obscure text please explain how we generate
> the the physical realization of one of these systems?
>
> Best Regards
>
> - Stewart
>>
>> Best Regards
>> Alex
>>
>>
>>
>>> understand to be missing to the VN is the reachability scope
>>> (limited scope vs Internet-wide).
>>> Req 4 - Network Slicing OAM (NS-OAM). Being the VN members defined
>>> as a set of stitched tunnels and LSPs the OAM tools available for
>>> There are many years of work and related RFCs in this area in IETF
>>> TE that are missing from the 'gap analysis' .  I suggest reading
>>> RFC7926 as a good primer on existing RFCs as well as some background
>>> that predates the current TEAS ACTN work.
>>>
>>> support the Guaranteed Quality of Service defined by RFC2212 (even
>>> if some vendors choose not to implement it), GS is defined as:
>>>
>>> to parse the 2nd paragraph in any way that makes sense in the
>>> context of detnet or delivering low loss, low jitter and
>>> deterministic latency.
>>>
> This body part will be downloaded on demand.

---

From: Stewart Bryant <[email-masked]>
Date: Mon, 10 Jul 2017 19:49:24 +0100

Hi Lou,

Ah yes, you should be confused, I was confused and mixed up two threads!

What I have been looking at is a tighter integration between the 
customer layer and the service underlay to understand how to deliver the 
packets properly.

I did take a quick look at RFC2212 and this tells us something of how to 
specify performance guarantees, but seems to assume nothing more 
sophisticated than policing and WFQ. I am not sure that this is enough.

I will not arrive in time for the 802 presentation, but I seem to 
remember attending one in the past where the focus was more on what 
documents there were than n how it worked and why it looked like it does.

My interest with this is bottom up: how to get the bits across the 
network with the right characteristics. I don't think it matters much 
what the various abstraction layers look like unless the lower layers 
can physically deliver the tenants' bits across the network with the 
right characteristics. Of course we do need the upper layers to 
interface with the system dynamically collecting user requirements and 
then talk the network layer into delivering the bits, but that is a 
problem that I hope that others more qualified will consider, and for 
the moment I have no opinion on them.

- Stewart

---

From: Lou Berger <[email-masked]>
Date: Mon, 10 Jul 2017 15:14:40 -0400

Hi Stewart,

> Ah yes, you should be confused, I was confused and mixed up two threads!
glad I'm not loosing my mind -- I'll save that for next week!

> sophisticated than policing and WFQ. I am not sure that this is enough.
I agree with this too, at least in the DetNet context, but it *is* the
established IETF starting point.  There's also support for MEF10.1
traffic parameters in RFC6003, but I think this is less interesting..

> documents there were than n how it worked and why it looked like it does.
I believe the slides are posted
(https://datatracker.ietf.org/group/edu/materials/) and the normal
youtube should be available Late Monday or Tuesday.   I'm hoping to get
to the interesting parts (traffic description and handling/queuing) in
the TSN discussion in Thursday AM's DetNet WG Session.

> right characteristics. 
100% agree and that's why much of our current discussion is on data
plane in DetNet.  My hope is that we'll leave this meeting with solid
direction on tagging and protection, and the TSN discussion will help
focus future discussion on service traffic description (flow spec).
 
> Of course we do need the upper layers to 
That parallels DetNet as well.  In addition to nailing down the data
plane, we're looking to develop an information model (we'll be
discussing some individual work on this in Prague) and a YANG data model
in the current set of deliverables.  Once that's done, we're aiming to
dovetail into existing/ongoing work in other WGs, but this is a
discussion for the future.

Cheers,
Lou

---

From: "Kiran.Makhijani" <[email-masked]>
Date: Mon, 10 Jul 2017 21:10:51 +0000

Hello Danielle,
Thanks for going through the documents.

We captured most of ACTN information from framework document, I have read draft-king-teas-applicability-actn-slicing - Please clarify that you are trying to say either ACTN entirely covers all aspects of network slices or it is one of the approaches.

The intent in gaps is latter, to say that ACTN is one of the options/tool to support slicing partially or entirely. 
 
We were not thinking just in terms of abstraction and virtual networks but slices as a total solution – dynamic network customization. ACTN is an approach which I consider as a hierarchical programmable interface, therefore, we also mention other possible alternatives ANIMA/CPNP for resource coordination – something that ACTN may not concern with but may also be desirable.
 
-Req 1, is purely from protocol independent resource specification, it will have service, slice, operational and monitoring, resource type – it may very well be same for ACTN.
-Req 2, In fact this is different than MDSC. MDSC may equal {netslice provider + domain to domain interface}. Interface for domain to domain will be used for coordination/negotiation.
-Req 3 and Req 4, I do agree with you in principle. Again, we are thinking of a resource-level coordinated OAM. Traditional VNs may mainly concern with port/link/path, QoS, permit/deny etc. In slice’s context – we need to describe state of NFs, placement, NFV coordination etc. Details will depend on how Req1 and 2 evolves (if at all).

Just a few thoughts. But we definitely need more discussions.
Kiran

On 7/10/17, 6:06 AM, "Netslices on behalf of Daniele Ceccarelli" <[email-masked] on behalf of [email-masked]> wrote:

    Hi all,

    

    
    1. Section  5.2.3.

    2. Section 6.2.3.

    Thank you
    Daniele  
    
    -----Original Message-----
    From: Netslices [mailto:[email-masked]] On Behalf Of Lou Berger
    Sent: domenica 9 luglio 2017 21:08
    To: [email-masked]
    Subject: [Netslices] Some comments on draft-qiang-netslices-gap-analysis
    
    Hi,

    

    

    
    
    - finally, WRT timing

    Lou

---

From: "qiangli (D)" <[email-masked]>
Date: Tue, 11 Jul 2017 03:41:43 +0000

Hi Lou,

Thank you for your comments, please see my reply marked as [Cr] inline.

Best regards,

Cristina QIANG

-----Original Message-----
From: Netslices [mailto:[email-masked]] On Behalf Of Lou Berger
Sent: Monday, July 10, 2017 3:08 AM
To: [email-masked]
Subject: [Netslices] Some comments on draft-qiang-netslices-gap-analysis

Hi,

[Cr] I have taken a quick look at RFC 7926, If I understand it correctly the cross-domain coordination here is addressed through Step 1) abstracting TE information; Step 2) advertising the abstracted Infor in the abstraction layer network. I agree with you that there are a lot of related work on these two points (e.g., ACTN for abstraction, BGP for advertisement), netslicing specific extension on these related work may be enough. As we clarified in section 8, what is missing is the data model for flat cross-domain coordination IMHO.

[Cr] Good point.

[Cr] Statement in 2rd paragraph will be modified in the next version.

- finally, WRT timing

Lou

---

From: "qiangli (D)" <[email-masked]>
Date: Tue, 11 Jul 2017 07:12:24 +0000

Hi Daniele,

Best regards,

Cristina QIANG

-----Original Message-----
From: Netslices [mailto:[email-masked]] On Behalf Of Daniele Ceccarelli
Sent: Monday, July 10, 2017 9:06 PM
To: Lou Berger; [email-masked]
Subject: Re: [Netslices] Some comments on draft-qiang-netslices-gap-analysis

Hi all,

[Cr] It's not difficult to understand that NetSlicing and ACTN have different requirements if you can accept NetSlicing and ACTN are not the same thing. I suggest you jump out of ACTN and try to look at network slicing in an independent perspective.

[Cr] We will never deny that ACTN could be one of the solutions for NetSlicing.

[Cr] There are two aspects here --- describe the network resources/functions & capture the NetSlicing requirements. 
ACTN does provide a certain degree of resource abstraction, but probably not enough. As we stated in section 4.2.2.2, ACTN focuses on Traffic Engineering aspect and some resources such as IP routing table is not covered.
Meanwhile, the NetSlicing requirements such as path restriction (e.g., specify some points that must be passed through for security reasons--different from deterministic routing), high-availability guidelines (e.g., restoration within 10ms, 100ms, or 1 second) also need to be considered.

[Cr] Different domain controllers could coordinate through a common platform like the (hierarchical) MDSC; or through a flat way.

[Cr] In additional to VN (TE-tunnel), there are also many other technologies such as VPN, SR, FlexE could be extended and reused for this requirement.

[Cr] If you think ACTN is NetSlicing (or VN is network slice instance), I will not oppose your above statement. Then please think about how will you provide OAM if the slice is implemented by SFC technology. NS-OAM is not an OAM tool related problem, as Section 7.2.1 stated there are lots of technology-specific tools can be reused in the context of network slicing, no gap identified so far. The problem of NS-OAM is that, the network slicing has completely changes the granularity of OAM. 

1. Section  5.2.3.

2. Section 6.2.3.

Thank you
Daniele  

-----Original Message-----
From: Netslices [mailto:[email-masked]] On Behalf Of Lou Berger
Sent: domenica 9 luglio 2017 21:08
To: [email-masked]
Subject: [Netslices] Some comments on draft-qiang-netslices-gap-analysis

Hi,

- finally, WRT timing

Lou

---

From: Daniele Ceccarelli <[email-masked]>
Date: Tue, 11 Jul 2017 14:38:59 +0000

Hi Kiran,

I apologize for focusing my analysis mostly on ACTN, I should have made clearer that ACTN is just one of the tools available in the IETF tool kit for traffic engineering. 

I don't still see any gap to fill when it comes to the transport aspect of a network slice and I'd like to better understand what you mean with "total solution". I see much more than just the transport part in an end to end slice but I don't know what could fall in the IETF domain. 
Just to make an example, there is all the cloud part of the network slice and all the radio part, and they are not actually addressed in IETF (AFAIK) simply because there are other SDOs in charge to do it. 
This becomes clear from your comment on Req3 and Req4 where you speak about NF and NFV. This is all another story...

Thank you
Daniele  

-----Original Message-----
From: Kiran.Makhijani [mailto:[email-masked]] 
Sent: lunedì 10 luglio 2017 23:11
To: Daniele Ceccarelli <[email-masked]>; Lou Berger <[email-masked]>; [email-masked]
Subject: Re: [Netslices] Some comments on draft-qiang-netslices-gap-analysis

Hello Danielle,

 

    Hi all,

    

    
    1. Section  5.2.3.

    2. Section 6.2.3.

    Thank you
    Daniele  
    
    -----Original Message-----
    From: Netslices [mailto:[email-masked]] On Behalf Of Lou Berger
    Sent: domenica 9 luglio 2017 21:08
    To: [email-masked]
    Subject: [Netslices] Some comments on draft-qiang-netslices-gap-analysis
    
    Hi,

    

    

    
    
    - finally, WRT timing

    Lou

---

From: Daniele Ceccarelli <[email-masked]>
Date: Tue, 11 Jul 2017 14:54:50 +0000

Hi Cristina,

My email ended up focusing on ACTN because it's my area of expertise, but my incipit was that I totally share Lou's point of view on the fact that there are a lot of consolidated solutions in the routing area (among which ACTN, DetNet, and many other TE initiatives) that seem to have already addressed the requirements that are being defined against the TE network.

Please see my further replies in line.

BR/Daniele  

-----Original Message-----
From: qiangli (D) [mailto:[email-masked]] 
Sent: martedì 11 luglio 2017 09:12
To: Daniele Ceccarelli <[email-masked]>; Lou Berger <[email-masked]>; [email-masked]
Subject: RE: [Netslices] Some comments on draft-qiang-netslices-gap-analysis

Hi Daniele,

Best regards,

Cristina QIANG

-----Original Message-----
From: Netslices [mailto:[email-masked]] On Behalf Of Daniele Ceccarelli
Sent: Monday, July 10, 2017 9:06 PM
To: Lou Berger; [email-masked]
Subject: Re: [Netslices] Some comments on draft-qiang-netslices-gap-analysis

Hi all,

[Cr] It's not difficult to understand that NetSlicing and ACTN have different requirements if you can accept NetSlicing and ACTN are not the same thing. I suggest you jump out of ACTN and try to look at network slicing in an independent perspective.
[>DC] Thanks, I will try...but I guess I jump too low since from a transport point of view I still see none.

[Cr] We will never deny that ACTN could be one of the solutions for NetSlicing.
[>DC] But few lines above you said that Netslicing and ACTN have different requirements...

[Cr] There are two aspects here --- describe the network resources/functions & capture the NetSlicing requirements. 
ACTN does provide a certain degree of resource abstraction, but probably not enough. As we stated in section 4.2.2.2, ACTN focuses on Traffic Engineering aspect and some resources such as IP routing table is not covered.
[>DC] IP routing tables are not addressed by ACTN but they are from e.g. I2RS. In any case, if you want to guarantee end to end SLA and KPI with routing tables...good luck 

Meanwhile, the NetSlicing requirements such as path restriction (e.g., specify some points that must be passed through for security reasons--different from deterministic routing), high-availability guidelines (e.g., restoration within 10ms, 100ms, or 1 second) also need to be considered.
[>DC] This is just adding path computation constraints and configuration parameters to the existing tools.

Req 2 - Network Slicing Cross-Domain Coordination: This seems to be one of the MDSC functionalities, actually the most important.
[Cr] Different domain controllers could coordinate through a common platform like the (hierarchical) MDSC; or through a flat way.
[>DC] what do you mean with flat way? Peering? Since hierarchy is already there why defining another methods to reach the same? Multiple parallel solutions always decrease the chances of interop.

[>DC] Please see above.

[Cr] If you think ACTN is NetSlicing (or VN is network slice instance), I will not oppose your above statement. Then please think about how will you provide OAM if the slice is implemented by SFC technology. NS-OAM is not an OAM tool related problem, as Section 7.2.1 stated there are lots of technology-specific tools can be reused in the context of network slicing, no gap identified so far. The problem of NS-OAM is that, the network slicing has completely changes the granularity of OAM. 
[>DC] This is a good point. The obvious solution that comes to my mind is to bind the SFCs with the same characteristics to the same VN (there are already the YANG models available for VPN to VN binding, extending them to include also the SFC shouldn't be difficult...provided it's a good idea), but I admit here there is room for improvement. 

1. Section  5.2.3.

2. Section 6.2.3.

Thank you
Daniele  

-----Original Message-----
From: Netslices [mailto:[email-masked]] On Behalf Of Lou Berger
Sent: domenica 9 luglio 2017 21:08
To: [email-masked]
Subject: [Netslices] Some comments on draft-qiang-netslices-gap-analysis

Hi,

- finally, WRT timing

Lou