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

[Stewart Bryant <[e-mail]>]

On 10/07/2017 16:34, Alex Galis wrote:
> 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

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 
> infrastructure.
>
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 
>> <[e-mail] 
>> <mailto:[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] <mailto:[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] <mailto:[e-mail]>
>> https://www.ietf.org/mailman/listinfo/netslices
>>
>> _______________________________________________
>> Netslices mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/netslices
>
>
>
> _______________________________________________
> Netslices mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/netslices