Subject: [bmwg] Rtgdir last call review of draft-ietf-bmwg-sdn-controller-benchmark-term-07

From: Ines Robles <[email-masked]>
Date: Fri, 02 Feb 2018 13:27:20 -0800

Reviewer: Ines Robles
Review result: Has Nits

Hello,

I have been selected as the Routing Directorate reviewer for this draft.
The Routing Directorate seeks to review all routing or routing-related drafts
as they pass through IETF last call and IESG review, and sometimes on special
request. The purpose of the review is to provide assistance to the Routing ADs.
For more information about the Routing Directorate, please see
​http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir

Although these comments are primarily for the use of the Routing ADs, it would
be helpful if you could consider them along with any other IETF Last Call
comments
 that you receive, and strive to resolve them through discussion or by updating
 the draft.

Document: draft-ietf-bmwg-sdn-controller-benchmark-term-07
Reviewer: Ines Robles
Review Date: 02-02-2018
Intended status: Informational

Summary:
I have some minor concerns about this document that I think should be resolved
before publication.

Comments:

I believe the draft is technically good. This document is well written and
clear to understand. The figures are clear and helpful.

Major Issues:

No major issues found.

Minor Issues:

-There is a definition of Northbound Interface (NI) in section 2.1.2, but there
is no a definition for Southbound Interface(SI). A definition for SI, was
available in the version 00 of this document [1], but deleted in further
versions. There is a reason for that? I think it would be nice to have a
definition for SI, or a pointer to one such as for NI.

- In section 2.1.2 in the Discussion, where it states: "...and orchestration
systems to program...", I think it would be nice to add an example, "...and
orchestration systems such as [add example here] to program..."

- In section 2.1.8 you mention Cluster/Redundancy Mode.
  Does it include a "Distributed Controller" mode/function, like e.g. mentioned
  in [2]?

- Section 2.3.2.2 in the Definition paragraph: "...(number of nodes, links and
hosts)..." it seems to me like the hosts are not considered nodes in here?. Is
that correct?

Nits:

Section 2.1.2: is same Service... => is same as the Service...
Section 2.3.1.4: in the Definition paragraph: "at it Southbound..." => "at its
Southbound..." Section 2.3.1.5: in the Definition paragraph: "at it
Southbound..." => "at its Southbound..." Section 4: The test coverage table
  -In the column 1, file 1: there is an empty space, maybe it would be nice to
  add a description for that column like "Stage" or something like that. What
  do you think? -In the Speed column, in the Setup stage: 1- Network Topology
  Discovery => Network Topology Discovery time. -In the Reliability column, in
  the Operational stage: 2- Exception Handling Detection Time => Exception
  Handling

Thanks for this document,

Best Regards,

Ines.

[1] https://tools.ietf.org/html/draft-ietf-bmwg-sdn-controller-benchmark-term-00
[2] https://datatracker.ietf.org/meeting/96/materials/slides-96-sdnrg-11/

---

From: [email-masked]
Date: Mon, 26 Feb 2018 15:52:29 +0000

We would  like to thank Al and all DIRs for taking time to review and share insightful comments on both the drafts.

We have submitted  new version of SDN controller benchmarking drafts into IETF, addressing the review comments received during IESG last call- draft-ietf-bmwg-sdn-controller-benchmark-term-09- draft-ietf-bmwg-sdn-controller-benchmark-meth-08
Key changes to the  terminology draft:
1. Fixed Nits 2. Updated the draft first paragraph to reference RFC 8174 in addition to RFC 21193. Added definitions for Southbound Interface and Leaf-Spine Topology
Key changes to the  methodology draft:
1. Fixed Nits & references2. Updated the draft first paragraph to reference RFC 8174 in addition to RFC 2119
3. Added Variance Measurement for all the tests.4. Updated the Test Setup Diagram to reflect Leaf Spine Topology5. Updated test objectives for Reactive & Proactive Path Provisioning Rate tests to reflect the rate measurement 
@Al, Please let us know for any  further actions on the drafts.
Thank you,Bhuvan

DISCLAIMER: Privileged and/or Confidential information may be
contained in this message. If you are not the addressee of this message,
you may not copy, use or deliver this message to anyone. In such
event,you should destroy the message and kindly notify the sender by
reply e-mail.
It is understood that opinions or conclusions that do not relate to the
official business of the company are neither given nor endorsed by the
company.

---

From: Warren Kumari <[email-masked]>
Date: Tue, 27 Feb 2018 13:36:25 -0500

Thank you for making these changes - I'll kick off the IESG Eval and
put them on the telechat.

Unfortunately, because a number of ADs are stepping down (and because
we are close to IETF101) the next telechat is quite full, as is the
following one (2018-04-05), and so I'm planning on putting this on the
2018-04-19 telechat. This is ~7 weeks out - sorry.

W

On Mon, Feb 26, 2018 at 10:52 AM,
<[email-masked]> wrote:
> We have submitted  new version of SDN controller benchmarking drafts into
> IETF, addressing the review comments received during IESG last call
> - draft-ietf-bmwg-sdn-controller-benchmark-term-09
> - draft-ietf-bmwg-sdn-controller-benchmark-meth-08
>
> 1. Fixed Nits
> 2. Updated the draft first paragraph to reference RFC 8174 in addition to
> RFC 2119
> 3. Added definitions for Southbound Interface and Leaf-Spine Topology
>
> 1. Fixed Nits & references
> 2. Updated the draft first paragraph to reference RFC 8174 in addition to
> RFC 2119
> 3. Added Variance Measurement for all the tests.
> 4. Updated the Test Setup Diagram to reflect Leaf Spine Topology
> 5. Updated test objectives for Reactive & Proactive Path Provisioning Rate
> tests to reflect the rate measurement
>
> Thank you,
> Bhuvan
> DISCLAIMER: Privileged and/or Confidential information may be contained in
> this message. If you are not the addressee of this message, you may not
> copy, use or deliver this message to anyone. In such event,you should
> destroy the message and kindly notify the sender by reply e-mail. It is
> understood that opinions or conclusions that do not relate to the official
> business of the company are neither given nor endorsed by the company.

-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf