[Fecframe] frameowrk ops and mgmt

["David Harrington" <[e-mail]>]

Hi,

I don't know why, but I never received the message sent by Vincent on
5/18.
I am pretty satisfied with the latest rev.
Vincent raised some questions. 
Here is my thinking on these, preceded by DBH>

> 3)
* syslog is standardized in RFC 5424, so we probably need to refer
to this RFC, and similarly we need to refer to RFC 3411 for SNMP.
Since implementing/using one of these protocols is RECOMMENDED, these
references should go to the Normative References section (both are
Standards Track documents, so there's no downward ref issue here).

DBH> I think informative is fine. The recommendation is to use
standard protocols, 
and syslog and snmp are just examples of standardized protocols.
Having this recommendation increases the likelihood that implementers
will choose one of these examples, increasing the likelihood of
interoperability.


* Is that sufficient to increase the probability that independent
products interoperate? No, we need to go a bit further and define
SNMP notification/syslog message formats. So the followup should be
to start defining a MIB... Unless the implementer chooses an in-band,
RTCP based, approach, which already includes useful information
from the FECFRAME point of view.

DBH> The WG has argued that the use cases are so varied that a single
solution wouldn't work.
You guys are the experts on this environment, so I need to accept that
such is the case.
But, I don't buy into the argument that ops and mgmt is out of scope
as a result.
Some environments can use in-band mechanisms such as RTCP; that's
great.
Some environments are better suited to out-of-band.
Network management applications that work with syslog and/or snmp
typically support proprietary data models as well as standard data
models. So an operator can use their existing syslog and/or snmp tools
to access provided feedback, even if the provided mib objects or
syslog messages are proprietary.
Would I rather see some standardization of the data models? sure,
because that would be even better for operators.
But if the environments really are that different, then it may not be
possible to have one MIB module to represent them all. Maybe we need
multiple MIB modules to support multiple use cases. 
At least with the recommendation of using standardized mgmt protocols,
such as syslog or snmp, it is more likely that implementers will
develop MIB modules and/or syslog messages that operators can access,
rather than providing nothing. 

* We RECOMMEND two different out-of-band solutions, which creates
interoperability risks. 

DBH> There are different types of interoperability. 
Management often has a different perspective on interoperability than
lower-layer protocols. 
Operators use a variety of tools to monitor/manage their networks. 
Which tools they use depends on the task they are trying to perform
(and what's available).
An operator might use syslog to monitor logged information, maybe to
determine the cause of a fault on a device.
An operator might use SNMP to monitor their whole network, using an
NMS with pretty colored icons of devices, etc., because SNMP is good
for periodic polling of statistics (and testing reachability). SNMP
can also be used as a troubleshooting tool, because it gives access to
information (when provided) such as configuration parameters. It's a
good state-query tool.
SNMP notifications can be used to alert operators to significant
events.
Each of these tools can be useful to operators, but an operator can
only use it if implementers support them in their implementations. 
As an operator, what I most care about is that the information is
provided somehow so I can monitor the system and debug network
problems using available tools - even if I have to write the tools. 

* As I understand, mappings exist between the
syslog/SNMP solution: RFC 5675 explains how to map SNMP notifications
to syslog messages, while RFC 5676 discusses the opposite mapping.
I don't know if these mappings are common or not, but this may also
increase the probability that different products interoperate.
So we can perhaps add a third sentence:

    When required, a mapping mechanism between the syslog and SNMP
    reporting mechanisms COULD be used, as described in [RFC5675]
    and [RFC5676].

DBH> I'm OK with this text, even though I think it is unnecessary.
Whether an implementation provides the information I need as a MIB or
syslog messages or via a web server on the device is less important
than having the information available somehow. Operators frequently
use shell scripts to customize their management.
It is certainly helpful if the access mechanism is standardized, such
as syslog or snmp or http/html, since a variety of available tools
support these standardized mechanisms. And many syslog or snmp tools
have command-line versions available that work well with shell
scripting. The ability to integrate with existing shell-scripted
in-house tools and with other applications is where using standardized
management **protocols** is really helpful to operators.

* So the followup should be to start defining a MIB...  

DBH> A standardized data model for the information can certainly be
helpful, so an operator can do direct comparison across devices to
uncover anomalies. But different environments (including different
vendor designs of devices, or different use cases) may demand
different data models. Sometimes it takes experience with a new
technology to understand the best way to model it and manage it. There
are good reasons why many standard MIB modules never get implemented -
often a proprietary model can better model the specific device or use
case. It is common for NMS applications to model their network using
databases, often based on an open source implementation like MySQL, or
a commercial database like Oracle. Then they have a mapping table
between OIDs and their database objects. They use SNMP to query the
standard or proprietary MIB object by OID, extract the value, and then
store the value in a field in their own database format, translating
the type if necessary. It really doesn't matter to many NMS
applications whether the MIB module is standard or proprietary as long
as they know the vendor-specific OID to query for a particular piece
of information, and how to massage the value to fit their database
model. And operators can write scripts to massage the information from
command line tools into the format they want. The benefit of standard
data models to operators is they wouldn't necessarily need to write a
script for each new device model if more devices used standard MIBs;
the published documentation for standard MIBs tends to be better, more
up-to-date, and more publicly available than those for proprietary
MIBs; and more off-the-shelf applications already support the standard
MIBs.
(The same is true to varying degrees for syslog and other standard
protocols, whether IETF or not.)

David Harrington
Director, IETF Transport Area
[e-mail] (preferred for ietf)
[e-mail]
[phone] (cell)