Subject: [OPS-AREA] comments on draft-harrington-operations-and-management-00

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 15 Mar 2007 20:58:33 +0100

Hi,

I have read <draft-harrington-operations-and-management-00> and I like
to provide some high-level feedback (I am too lazy to write up the
more editorial comments since it is easier to pass them directly on
paper to David in a few days).

I generally like the goals of the document and I hope that protocol
developers will take a look at this document. While it is a noble goal
to consider management from the very early start of new protocol work,
we also have to accept that sometimes management requirements will
only be understood once a technology has been deployed and some
experience has been gained.

I mostly like the sections 1-3 as they are and the beginning of
section 4. Some later parts of section 4 require IMHO some rewording,
but nothing critical (there also seems to be some redundancy that can
be removed).

Section 5 reviews which protocols the IETF has to offer for management
and, what I really like, the text discusses for which applications
they were designed or already successfully deployed. I like to perhaps
see even stronger guidelines; perhaps we know more at the end of next
week.

Protocols missing are in my view EPP (I am wondering for some years
now why management people like to ignore this since dealing with
registries is a rather natural activity for people running networks)
and perhaps XCAP (although I am not follwing this too closely).

The weakest part of the document is IMHO section 6. It is not clear to
me what David's intention were here; sometimes he gives general advise
while at ther places he kind of surveys data models and such things.
I am also not sure all the stuff listed there is actually useful to
list; for example, has anybody ever deployed the technology which came
out of the snmpconf working group? So we need to be more selective and
probably also organize our pointers based on the protocol layer people
are working on (transmission specific MIB modules are kind of widely
used, people managing application servers usually do not use much of
SNMP; the IETF application management MIBs we have produced have not
gained large deployments as far as I can tell). Routing and control
plane people may likely prefer NETCONF since it is close to CLIs which
seem to rule in this space.

What could be added, but may be too much since it might make the
document too long, could be guidelines for people who like to design
special purpose management protocols so that they avoid making
mistakes, that is Guidelines for Management Protocol Designers. But
perhaps this is really a different document.

Finally: I think it is useful to work on such a document. But we
should also be careful that the document really just provides
guidelines and can't be misused to slow down protocol development
since sometimes it is better to get a protocol out in a timely fashion
without management considerations insteat of being delayed some years
when it is too late to be successful.

/js

-- 
Juergen Schoenwaelder		 Jacobs University Bremen
<http://www.eecs.iu-bremen.de/>	 P.O. Box 750 561, 28725 Bremen, Germany

_______________________________________________
OPS-AREA mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ops-area

---

From: "Wijnen, Bert \(Bert\)" <[email-masked]>
Date: Fri, 16 Mar 2007 16:44:57 +0100

Hi,
 
I have read <draft-harrington-operations-and-management-00> 
and in general I think it is going in the right direction.
We ought to make sure we also get OPERATORS to see it
and try to get feedback from them. After all, we seem to
be changing direction/guidance in IETF and so we need to make
sure that this jives with users and intended deployment
scenarios/environments.

some comments (and things  to think about):

- sect 2.1.  Motivation

   The IETF Standard Management Framework for years has stressed the use
   of SMI MIB modules [RFC2578].  The IETF designed the SMI MIB module
   approach to permit multiple protocols to utilize the MIB data
   [RFC1052], but it became a common misunderstanding that a MIB module
   could only be used with the SNMP protocol.  [RFC3410]

  Although one can indeed use MIB modules with other protocols, is it
not
  such that in all practicallity, right now, SNMP is the only protocol
  that actually does transport MIB data? I don't want to make an issue
of
  this. We should indeed explain and make it clear that non-SNMP
  protocols *** could *** be used, but at the other hand, we should also
  not give the impression that such is actually done today. One would
have
  to dveleop a protocol to do so.

  I remember that several years back I suggested to the COPS-PR
proponents
  that they would tryu to define how MIB data could be transported. But 
  I never saw even an initial write-up on it.

- I think we need to say something about "thinking about NETWORK
management"
  as opposed to thinking about "DEVICE management". The one issue that
we
  have always struggled with (and for which I think we still have no
good
  guidance) is the problem of how to configure multiple
reletaed/co-operating
  devices and how to back off if one of those configs fails/causes
trouble.
  NETCONF hels somewhat because it allows to lock multiple devices,
  perform the configuration settings/changes, check that they are OK
(undo
  if not) and then unlock the devices.

  Maybe towards the end of sect 2.1 (or maybe a sect 2.2) would be
  usefull.

  Mmm... I see there is a sentence about it in sect 3.2
  Possibly that is sufficient. But I think it would be good to elaborate

  a bit on the typicla issues that need to be considered for this.

- W.r.t. 4.2.  Fault Management

   If notifications are used to alert operators to certain conditions,
   then the working group shoul discuss mechanisms to throttle
   notifications to prevent congestion.

  Would it be usefull (I think it would) to also suggest that the WG 
  describes what sort of corrective action can be taken by an operator
  for each of the notifictaions that are being defined?

- Mmmm ... I see on page 13:

   Textual configuration files should be able to contain international
   characters.  Human-readable strings should utilize UTF-8.  Protocol
   elements should be in case insensitive ASCII.

  Are we sure that we (from a operations and management point of view)
  want to sort of prescribe that it should be case-insensitive ASCII??

- sect 4.3.1

  I worry/wonder if this is "suggesting that protocol debug facilities
  be considered as management function". I believe protocol debugging is
  NOT part (and should not be part) of the NM tools/hooks in a system.

- Page 16:

   Listed here are a number of protocols that have reached Proposed
   Standard status within the IETF.

  I'd say: Proposed Standard or higher.

  And then in the following sections I would add at what level each 
  protocol is.

- sect 5.1:

   SNMP is not considered a good choice for configuration.

  I would add (at en of sentence) "by many".
  Now you post it as a FACT or TRUTH. I believe there are people whho
  actually use SNMP for configuration in various
environments/technologies
  and seem to be in good shape doing so. There is no need to be pedantic
  and tell them they made a bad choice, is there?

  In general, I think sect 5.1 is a bit too negative about SNMP.
  I know (and agree) with a number of shortcomings of SNMP, but I think
this
  section is focussing too much on the negatives. Just my personal
opinion.

- Section 5/6.
  I wonder if we need to say anything about protocols that have been
  developed outside of IETF. I think we should avoid to try and list
  them individually, but some ptrs to other SDOs that do work on
  NM protocols and/or Information/Data Modeling might make sense?
  I am bringing it up for discussion. I have not made up my mind
  yet if such is usefull or not.

- I wonder if we should discuss (at all) the use/need of COMPLIANCE
  specifications. We know that we have tools in SMI for MIB modules,
  but we also know that it is not easy to use and certainly the
  sysORTable in the SNMPv2-MIB module seems not much/often used by
agents
  to report how they comply with a MIB module compliance.

  Maybe the topic is not easy to discuss/describe in general. But if
  we do include it, I think it should tend toward generic/genral 
  aspects of it and not go indetails about the SMI methods.

Bert

---

From: "David Harrington" <[email-masked]>
Date: Fri, 16 Mar 2007 11:59:24 -0400

Hi,

Just a quick response. Much of the text/ideas in this document came
from RFC3535 - the report from the IAB Network Management workshop. 

If you qyuestion why some things are included here, you might want to
see if something was said in the IAB workshop on the topic.

I will respond to your comments in greater detail later.

dbh

> -----Original Message-----
> From: Wijnen, Bert (Bert) [mailto:[email-masked]] 
> Sent: Friday, March 16, 2007 11:45 AM
> To: [email-masked]
> Subject: RE: [OPS-AREA] comments 
> ondraft-harrington-operations-and-management-00
> 
> Hi,
>

---

From: "Randy Presuhn" <[email-masked]>
Date: Fri, 16 Mar 2007 09:59:34 -0800

Hi -

> From: "David Harrington" <[email-masked]>
> To: "'Wijnen, Bert (Bert)'" <[email-masked]>; <[email-masked]>
> Sent: Friday, March 16, 2007 7:59 AM
> Subject: RE: [OPS-AREA] commentsondraft-harrington-operations-and-management-00
... 
> see if something was said in the IAB workshop on the topic.
...
> >  and tell them they made a bad choice, is there?
...

Bert's formulation is a better fit with the spirit of the discussion at
the IAB workshop, IMO.  The focus there was not "why can't SNMP do X"
but rather "why aren't operators using SNMP to do X".  Though we have
(yet) to deal with the answers we got there,  my impression is that most
of us there did not find the reasoning terribly persuasive as an
indictment of SNMP.  However, "the customer is always right,"
and that *is* persuasive as a motivation for doing something else.
However, the stuff we've done subsequently does little to address
the operators' core complaints.

Randy

---

From: "Romascanu, Dan \(Dan\)" <[email-masked]>
Date: Fri, 16 Mar 2007 22:27:05 +0200

> From: Juergen Schoenwaelder [mailto:[email-masked]] 
> 
> Finally: I think it is useful to work on such a document. But 
> we should also be careful that the document really just 
> provides guidelines and can't be misused to slow down 
> protocol development since sometimes it is better to get a 
> protocol out in a timely fashion without management 
> considerations insteat of being delayed some years when it is 
> too late to be successful.
> 

Delaying publication of protocol documents by years is certainly not the
goal. Releasing IETF documents including protocol definition without any
consideration about how the protocol and networks running the protocol
will be managed and what are the operational implications of deployment
also seems wrong to me. This document should try to find the right
balance - what is the minimal information that needs to be included in a
protocol definition document that shows how the protocol will be
deployed and managed. Minimal but not less than this. 

Dan