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

Hi Lou,

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

Best regards,

Cristina QIANG

-----Original Message-----
From: Netslices [mailto:netslices-bounces@ietf.org] On Behalf Of Lou Berger
Sent: Monday, July 10, 2017 3:08 AM
To: netslices@ietf.org
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.

[Cr] I have taken a quick look at RFC 7926, If I understand it correctly the cross-domain coordination here is addressed through Step 1) abstracting TE information; Step 2) advertising the abstracted Infor in the abstraction layer network. I agree with you that there are a lot of related work on these two points (e.g., ACTN for abstraction, BGP for advertisement), netslicing specific extension on these related work may be enough. As we clarified in section 8, what is missing is the data model for flat cross-domain coordination IMHO.

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

[Cr] Good point.

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

[Cr] Statement in 2rd paragraph will be modified in the next version.

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
Netslices@ietf.org
https://www.ietf.org/mailman/listinfo/netslices