PANET drafts (was Re: PANET side-meeting)

[Curtis Villamizar <[e-mail]>]

In message <[e-mail]>
Mingui Zhang writes:
 
> Hi Curtis,
>  
> One clarification: when I said the "other drafts", I actually meant
> the following drafts.
>  
> Power-Aware Networks (PANET): Problem Statement,
>  https://datatracker.ietf.org/doc/draft-zhang-panet-problem-statement/
>  
> Use Cases for Power-Aware Networks,
>  https://datatracker.ietf.org/doc/draft-zhang-panet-use-cases/
>  
> Requirements for Power Aware Network,
> https://datatracker.ietf.org/doc/draft-dong-panet-requirement
>  
> Thanks,
> Mingui


Mingui,

OK.  Comments below.  Do to other obligations, I have to go through
these quickly but they are so far off the mark that it is OK to go
through them quickly.

The underlying flaw in all of this is that you have not done the
fundamental research into where power goes and where gains can be
made.  That exercise needs to be done for each of the type of domain
within scope: core, edge, aggregation, access, enterprise, data
center.  The problem statement should have a clear statement of which
of these are within scope and an analysis of where power goes for each
within scope, and where gains can be made for each within scope.

You can't have a good requirements document and framework until you
have a good problem statement, so don't bother to write them until you
have done the underlying research and have a good problem statement.

Curtis


Power-Aware Networks (PANET): Problem Statement
draft-zhang-panet-problem-statement

  Intro could be shorter.  We all know that power is an issue for
  numerous resasons.  Money is an issue and that CO2 is an issue.  In
  the past fitting higher capacity into the same space and power has
  been the dominant issue.

  A problem statement should not have solution approaches.  This
  narrows the solution space unnecessarily too early in the process.
  The choice of solution approaches is poor and ignores the many types
  of equipment drawing power.

  There is no mention of the scope of the work.  Is it core networsk,
  edge, aggregation (metro), access, enterprise, data center, or all
  of the above.  Different solutions will apply to difference
  situations.

  For example, does putting a router link into sleep mode affect the
  400W laser in the transport equipment?  If transport lasers are
  turned off, how long do they need to restabilize (hint: minimum for
  ULH is usually minutes to get power levels right, stabilize
  temperatures within the actively cooled lasers, etc.  Can take tens
  of minutes before fully stabilized during which time periods of
  errors may occur).

  A good engineering approach is to start by figuring out where most
  of the power goes, and focus on where large gains can be made.  That
  is what *should* go into a problem statement.

  Problem Areas for IETF outlines what should be in this document.
  You could take the bullet list and try to make that into a WG BOF
  rather than offer this as a problems statement.

  If you are going to write a problem statement draft, address the
  questions under Motivation and Problem Scope.

  The bullets in the Technical Development and Operation Practice
  belong in requirements and framework documents, filled in, not
  unanswered.

  A proper "problem statement" in IETF is a clear and concise
  statement of a well defined problem to be solved.  You don't have
  that.

Use Cases for Power-Aware Networks
https://datatracker.ietf.org/doc/draft-zhang-panet-use-cases/

  This document is useless as a use cases document.  It mostly
  reiterates the solution set proposed in the problem statement.

  Instead of anecdotal examples a good analysis of where power goes in
  core, edge, aggregation (metro), access, enterprise, data center and
  where power could be potentially reduced would make for a better use
  case document if that wasn't in the problem statement.

Requirements for Power Aware Network
https://datatracker.ietf.org/doc/draft-dong-panet-requirement

  The requirements makes the assumption that a solution involving
  changes in the control plane will be found necessary.  Since we
  don't have the research to support that, this document is premature
  and should be ignored for now.

  It is entirely possible that some 90% of the gains could come from
  local power optimizations alone and the remaining 10% requires
  enough complexity that it is not worth it.  We don't know that until
  the underlying research into where the power goes and where we can
  make gains is done.