Re: [Netslices] Some comments on draft-qiang-netslices-gap-analysiswe are not

[Alex Galis <[e-mail]>]

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 <[e-mail]> 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. 
> 
> 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 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.
> 
> 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:[e-mail]] On Behalf Of Lou Berger
> Sent: domenica 9 luglio 2017 21:08
> To: [e-mail]
> 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:
> 
> - 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
> 
> 
> _______________________________________________
> Netslices mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/netslices
> 
> _______________________________________________
> Netslices mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/netslices