Re: Management Requirements

Hi,


Comments inline ...

On 8/7/12 3:29 PM, "Ronald Bonica" <[email protected]> wrote:

>Folks,
>
>The BEHAVE WG brings us a concrete example of a problem that we discussed
>in Vancouver. According to their charter, the BEHAVE WG "creates
>documents to enable IPv4/IPv4 and IPv6/IPv4 NATs to function in as
>deterministic a fashion as possible." Also, according to their charter,
>the BEHAVE WG "will update the NAT MIB (RFC 4008) to be
>consistent with the management aspects of its IPv6/IPv4 NAT solutions,
>and specify IPFIX information elements to meet logging requirements,
>reusing existing elements, if possible."
>
>Now BEHAVE is asking whether SNMP and IPFIX are the right tools. Maybe
>NETCONF is the right tool for configuration? Maybe SNMP is right for
>fault monitoring? Maybe syslog is right for maintaining a record of
>address mappings? Who knows?

The operator should know, based on their operational/management
environment.
Since we don't know their operational/management environment, it is hard
for us to decide which protocols are appropriate.
What we can do is design our technologies to meet certain needs, and then
to provide guidelines/applicability statements for our technologies.

>
>My best guess follows......
>
>- The BEHAVE WG knows what information needs to be
>configured/monitored/preserved. They MUST specify that.

Agreed. 
An information model is a good place to start; it should describe what
information we expect to be configured/monitored/preserved.
Of course, in some environments other things might also need to be
configured/monitored/preserved, and we can only really provide guidance on
our standards.
And we can provide guidance on how our management protocol standards could
be used to configure/monitor/preserve.


>- The BEHAVE WG and the OPS Area have an equal stake in determining which
>tool is recommended to manage each type of data. They should work
>together to make a recommendation. In the best of all possible worlds,
>that decision would be informed by a well-documented guideline. However,
>in the world that we inhabit, that decision may need to be facilitated by
>a conversation.

I would express this differently:
We are talking about tasks to be performed, and the BEHAVE WG and the OPS
Area have an equal stake in determining which tool is recommended for each
task.
The type of data, and the protocol to manipulate that data, is determined
by the nature of the task.
I believe there are already some guidelines published by the OPS area
about NM protocol applicability, such as rfc5706 and RFC6632.

We have four standard NM protocols because we have identified four major
task-oriented aspects of management to be addressed:

SNMP is good for monitoring (and emitting noritifations for) faults and
performance, particularly for the overall system, and specific protocols
(especially transmission protocols).

SNMP is session-less, by design, which makes it applicable to broken
networks and repetitive polling of small amounts of data.
SNMP is supported by a wide range of devices.

SNMP can be used to tweak system variables, but many agent implementations
do not support SET commands.
SNMP is typically constrained by a lack of MIB modules (especially
standardized modules) for all features in a box.
SNMP was designed to be NMS-application-friendly.
SNMP is supported by a wide range of management applications that automate
aspects such as congestion awareness, root-cause analysis and policy-based
response systems.
NMS applications with graphical user interfaces often integrate/correlate
SNMP, Syslog, and command line tools such as ping and traceroute, and
graphically identify network problems.
(In my experience, advanced GUI tools typically support SNMP, while
non-SNMP tools designed for other tasks tend to have less advanced GUIs.)

2) Whole-box configuration is addressed mainly by proprietary CLIs and
shell scripts.

3) Standardized whole-box config is being addressed by netconf/yang
(partial config can be supported as well).
Netconf/YANG support is seriously constrained by a lack of standard YANG
models. 
Netconf is often implemented with proprietary data modeling approaches
(e.g., CLI commands with XML tags, not YANG).
The IETF community is working on converting many MIB modules into YANG
format to provide core data models.
The IETF community is working on developing YANG models for technologies
not well supported by SMIv2 modeling.
Netconf was designed with eye toward operators logging in via SSH sessions
to configure devices.
This approach can be automated by shell scripts.
I am not aware of much non-scripted application-support for netconf
automation yet. 

4) Syslog is the defacto standard for logging.
The IETF syslog has a standard message header, and standardized security.
Syslog messages deliberately include a non-standardized text portion so
vendors can pass useful, human-readable, vendor-specific information in
the message.
The syslog community (mostly implementers) was adamant they do not want to
standardize text portions of syslog messages, because that doesn't meet
their needs.
Syslog is a one-way protocol, often with no congestion control, with no
ack to ensure delivery succeeded.
This unacknowledged one-way approach of syslog/UDP may have legal
ramifications.
Syslog/TLS can help verify delivery and message integrity.
"Signed syslog" can help verify the integrity of messages, both in transit
and in subsequent storage (designed for legal use cases).

 5) I know less about ipfix, but if I understand correctly:
ipfix uses a template approach, so operators can choose what information
they want delivered.

ipfix was designed to generate messages quickly to address short-lived
phenomena (e.g., ip sessions).
Ipfix was designed to generate messages with potentially significant
amounts of data per event.
The template approach saves the overhead of sending naming and type
information in the message; it sends only the data.
Ipfix was designed to offload messages quickly to support devices with
constrained resources.
And I think ipfix was designed to support usage accounting, with support
for reliability and integrity-checking.

 

>- The BEHAVE WG MUST produce protocol-specific data models (SMI, YANG)
>for the recommended protocols
>- The BEHAVE WG MAY produce protocol-specific data models (SMI, YANG) for
>the non-recommended protocols
>
>Comments?
>
>                                              Ron

I think that we should recommend ALL of these IETF-standard protocols,
using applicability statements (and the existing guidelines) to specify
under what circumstances each use is recommended.
We should develop one or two standard data models for BEHAVE-standardized
NAT management to prove the BEHAVE WG information model is viable (and for
interoperability, of course).
Which one or two should be decided by asking the operator community which
are most important to them in the near term (I.e. within 24 months).
We can always develop other standard data models, possibly as non-WG
drafts, based on market demand later.

IMHO, as ex-AD, the BEHAVE WG should focus on making **the protocols
standardized in the WG** manageable (e.g., DNS64, v6v4 stateful and
stateless translation, ftp64, bih, turn, stun, etc.).
When and if lsn-requirements is approved as an IETF standard, then the WG
should develop management support needed for interoperability.

I think NATs are still too vendor-specific and deployment-specific to
standardize configuration data models; we need more field experience and
convergence of the NAT configuration information model.


Given my understanding of what operators are saying they need for their
deployments, the commonality/stability of information that needs to be
modeled, and my understanding of the strengths and weaknesses of the four
protocols, my personal recommendation for near-term usage is to develop a
MIB module for monitoring/alerting, and syslog/TLS for logging, with
signed-syslog support encouraged to support legal requirements. Your
mileage may vary.


Dbh
--
David Harrington
[email protected]
+1-603-828-1401





>
>
>
>_______________________________________________
>OPS-AREA mailing list
>[email protected]
>https://www.ietf.org/mailman/listinfo/ops-area