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

[Daniele Ceccarelli <[e-mail]>]

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:[e-mail]] 
Sent: lunedì 10 luglio 2017 23:11
To: Daniele Ceccarelli <[e-mail]>; Lou Berger <[e-mail]>; [e-mail]
Subject: Re: [Netslices] Some comments on draft-qiang-netslices-gap-analysis

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" <[e-mail] on behalf of [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 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:[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