RE: Opsdir last call review of draft-ietf-teas-actn-framework-13

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Scott,

Thanks for your comment on this draft. 

In regards to Nits, we have resolved all Bruno's comments and updated the draft. 

Thank you for your meta-level comment. I see your point --- throwing more bandwidth would solve some problem; however, this work is about providing network resources partitioned/sliced for different customers. Throwing more bandwidth to the network would not solve all of the customer's requirements such as monitoring and controlling of their virtual networks flexibly with expected QoS and Traffic Engineering constraints. In addition, the solution work is in progress utilizing data models for abstraction in the hierarchical network controller environments. There are many vendors and operators that are implementing ACTN solutions as they see this has value and usefulness. 

Hope this answers your comment.

Thanks & best regards,
Young & Daniele

-----Original Message-----
From: Scott Bradner [mailto:sob@xxxxxxxxx] 
Sent: Sunday, April 29, 2018 2:35 PM
To: ops-dir@xxxxxxxx
Cc: draft-ietf-teas-actn-framework.all@xxxxxxxx; ietf@xxxxxxxx; teas@xxxxxxxx
Subject: Opsdir last call review of draft-ietf-teas-actn-framework-13

Reviewer: Scott Bradner
Review result: Has Nits

I did an OPS-DIR review of Framework for Abstraction and Control of Traffic Engineered Networks (draft-ietf-teas-actn-framework-13). As a framework document rather than a technical specification this document does not have any direct operational issues though the framework is for a technology that is "all operations." With that in mind I did not see any particular operational worry other than the overall complexity of the solution.

I will defer to Bruno Decranene's review for his detailed listing of nits.

My only real comment is a meta one - I generally question the likelihood of widespread use of a system of this level of multi-player complexity in environments where it is reasonably easy to throw bandwidth at this class of problem.

That said, I see no reason to not publish this as an Informational RFC just in case the thought that went into this could be useful to others or, maybe, if the use of the technology itself proves to be more cost effective than adding bandwidth.






[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Mhonarc]     [Fedora Users]

  Powered by Linux