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

[Daniele Ceccarelli <[e-mail]>]

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

Hi Daniele,

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

Best regards,

Cristina QIANG


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

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

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

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. 

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


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

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

[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.
[>DC] Please see above.

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.

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

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