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

[Lou Berger <[e-mail]>]

Hi Stewart,


On 7/10/2017 2:49 PM, Stewart Bryant wrote:
> Hi Lou,
>
> 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!

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

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

> 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. 
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 
> 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.
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
>
> - Stewart
>
>
>
> On 10/07/2017 18:11, Lou Berger wrote:
>> 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:
>>>
>>> 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
>>>
>>> This body part will be downloaded on demand.
>