Subject: [OPS-AREA] data models and translations / mappings

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 3 Aug 2012 07:10:42 +0200

Hi,

During the OPS-AREA meeting today, the topic came up how we plan to
deal with the fact that we now have NETCONF and SNMP. One point made
was that consistency of the data models is key. I fully agree with
that statement. Some people asked during the meeting and after the
meeting whether automated translations can not help us solve the
problem.  Since not everyone might be familiar with the history of
similar ideas in the IETF, I thought I write down a few things that
might help to understand what we have today and how we got where we
are.

Back in the late 1990s, policy based management was a big hype.  (To a
large extend, some of today's brand new ideas resemble ideas that were
floating around back then, but lets not get side tracked.) With the
policy work, we got the protocols COPS [RFC 2748] and in particular
COPS-PR [RFC 3084]. Some believed these new protocols will be the
solution to all management problems, but others, of course, did not
think that way. One of the questions that came up back then was how we
can make things work if we now have both SNMP and COPS-PR.  People
agreed that we need at least consistency on the data models. (Did I
hear this today again?) For those who have not been around back then
or happily forgotten the details, COPS-PR was using SPPI [RFC 3159] as
its data modeling language, a variant of SMIv2 [RFC 2578] .

In those days, I thought it should be possible to come up with a new
data modeling language that allows to define data models that can work
with both SNMP and COPS-PR. The idea was to separate the core data
model from the protocol specific bindings. We called this new language
SMIng (and yes, by choosing 'ng', this was doomed to failure - but I
did not realize that until it was too late ;-). SMIng was first
developed in the NMRG of the IRTF and then brought to the IETF. The
resulting SMIng working group was tasked to produce first a
requirements document. The WG delivered the SMIng objectives in
[RFC3216], published in 2001. Subsequently, the working group failed
to achieve agreement on the SMIng language itself and it was finally
shut down without producing any further results. The SMIng proposal
produced by the NMRG was later published in 2004 as [RFC 3780]
together with the SNMP binding [RFC 3781]. A few years later, I wrote
down some thoughts about the lessons learned from the SMIng project
[http://dx.doi.org/10.1109/MCOM.2008.4511663]. I am happy to share an
early version of the paper in case someone is interested why protocol
independence is hard to achieve. Just ask.

When NETCONF needed a data modeling language, the design team started
with the idea that the data modeling language should be as clean and
general as possible but we accepted to include support for protocol
specifics where they were needed to make things work well. YANG [RFC
6020], published in 2010, resembles in part SMIng but goes much
further in expressiveness.  Contrary to SMIng, we allowed protocol
specifics again to be part of the language (most obvious perhaps with
error handling statements that directly relate to how NETCONF signals
errors). One thing that has proven valuable is YANG's insensibility.
(Some implementations use language extensions to drive the generation
of various interfaces out of a YANG specification.)

Since YANG is much less constrained than SMIv2, I started to develop a
translation algorithm that turns SMIv2 data models into YANG data
models. (I started coding this during the first YANG design team
meeting I attended back in 2007.) The resulting specification got
published recently as [RFC 6643]. While the translation is relatively
straightforward, the translation is read-only since the persistence
models of SNMP and NETCONF differ widely.

With the SMIv2 to YANG mapping in place, you get a read-only YANG data
model for any SMIv2 MIB data model (aka MIB) today by simply running a
translator. There are open source tools to do that. Are people happy
with this?  Well, not everybody. While the resulting data model is
usable (in my biased view ;-), the result of the translation is of
course not as good as a handcrafted translation. Some people seem to
also dislike that there is not an authoritative source where
translated modules can be found (which may be a fixable problem). In
the NETMOD working group, we received very recently some requests to
add more handcrafted translations to the YANG modules being developed.

Bottom line: People who believe we can move towards generic data
models that can be machine translated to produce usable data models
for different management protocols may want to study some of the prior
work the IETF/IRTF did in this space. All we know for sure is that
such translations are not easy, if meaningfully possible at all.

/js

PS: And let us not forget that IPFIX lives a life of its own with a
    growing number of "information elements" while SYSLOG is rather
    loosely structured. It is not just SNMP and NETCONF.

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: Ronald Bonica <[email-masked]>
Date: Tue, 7 Aug 2012 15:29:52 -0400

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?

My best guess follows......

- The BEHAVE WG knows what information needs to be configured/monitored/preserved. They MUST specify that.
- 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.
- 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

---

From: Scott Brim <[email-masked]>
Date: Tue, 7 Aug 2012 16:01:53 -0400

On Aug 7, 2012 3:31 PM, "Ronald Bonica" <[email-masked]> wrote:
> - 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.
...
> Comments?

Yup...  but I hesitate to install rules. This is not a situation where the
responsibilities and powers need to be nailed down.  We're better off with
general statements about how we work and the relationships we strive for
than with detailed procedures.

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 7 Aug 2012 22:54:52 +0200

> 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…

For configuration, NETCONF/YANG is the right choice. There is nothing
that really competes for configuration.

For event notifications, you have at least SYSLOG, SNMP notifications,
IPFIX, NETCONF notifications. I think the last one is likely not a
main target. SNMP notifications means one SNMP message per event and
the same holds true for SYSLOG; IPFIX allows to send a collection of
events in one IPFIX message and hence it might be more scalable, which
might be important for some NAT deployments.

For retrieving operational state and debugging, both SNMP and NETCONF
can work. If the data structures tend to be more complex and/or the
data instances are of larger volume, NETCONF has some advances (more
efficient bulk transfer). If data needs to travel over shaky links
(e.g. high levels of packet loss), SNMP _can_ have an advantage.

Perhaps these thoughts help to make a suitable decision. One could of
course also ask what the contributors prefer to implement, e.g. what
they expect to ease integration into management systems relevant for
the protocol domain.

/js

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Tue, 7 Aug 2012 23:01:37 +0200

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Juergen Schoenwaelder
> Sent: Tuesday, August 07, 2012 11:55 PM
> To: Ronald Bonica
> Cc: [email-masked]; [email-masked]; ops-
> [email-masked]
> Subject: Re: [OPS-AREA] Management Requirements
> 
> > 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?
> >
> 
main
> target. SNMP notifications means one SNMP message per event and the
same
> holds true for SYSLOG; IPFIX allows to send a collection of events in
> one IPFIX message and hence it might be more scalable, which might be
> important for some NAT deployments.
> 
data
> instances are of larger volume, NETCONF has some advances (more
(e.g.
> high levels of packet loss), SNMP _can_ have an advantage.
> 
the
> protocol domain.

[[DR]] I agree with all the analysis made by Juergen, maybe with one
reservation: 

> SNMP notifications means one SNMP message per event and the same
> holds true for SYSLOG; IPFIX allows to send a collection of events in
> one IPFIX message and hence it might be more scalable, which might be
> important for some NAT deployments.

You can actually send more than one SNMP message per event if you define
the notifications accordingly, so I say that this really depends upon
modeling. On the other hand if 'real-time'-liness is a requirement -
a.k.a as soon as certain events happen you _may_ have an advantage with
SNMP notifications. 

Regards,

Dan

---

From: Michael MacFaden <[email-masked]>
Date: Tue, 7 Aug 2012 14:17:01 -0700 (PDT)

rbonica writes:
> 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?

Right implementers have to make many choices which are
predisposed by their personal experience and company leanings.

A given implementation might have the following: an SNMP agent with
particular mib modules and notifications to monitor one or more 
instances of this service. 
IPFIX agent might report complimentary information elements and not necessarily match 1:1 
what one would monitor via SNMP. If configuration is more complex than
can be described in SMIv2 then using YANG to express configuration
makes sense even if NETCONF is never deployed. I find it will end up in the
proprietary CLI/API. And yes syslog gets used for detailed reporting 
diagnostics but have not seen any standard ever need to go that far (yet).

So while not all of these might be used by an operator, having all available in a given
product vastly improves its fit into diverse operational environments.
(Vendor speak for less time to get to full deployment & getting paid).

My advice to product teams has always been to consider the data model in the MIB module
for IETF protocols (or whatever the related mgmt spec for non-IETF technology standards). 
I find that the strings for mgmt terms in these specs get propagated into products doc/interfaces/etc
even if the product doesn't implement an SNMP agent.
SMIv2 syntax MIB modules, especially when written with decent REFERENCE
clauses to the underlying spec, really help to frame which operations and
data should be considered by the implementer using whatever mgmt protocols they choose.

HTH,
Mike MacFaden

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 7 Aug 2012 23:47:17 +0200

> a.k.a as soon as certain events happen you _may_ have an advantage with

I have not been considering the case of M>1 messages per event.

I was writing about the case of E>1 events per message. SNMP limits
things to at best to one event per message. IPFIX seems to be able to
batch several events into a single IPFIX message. Of course, there are
other considerations here, the congestion control of the underlying
transport and whether a high-level of event notifications are needed
in the first place. Since this comes up in BEHAVE context, there might
be legal requirements (in some legislations) to do full session
logging of so called carrier grade NATs.

/js

---

From: Dave Thaler <[email-masked]>
Date: Tue, 7 Aug 2012 21:51:44 +0000

> Sent: Tuesday, August 07, 2012 1:55 PM
> To: Ronald Bonica
> Cc: [email-masked]; [email-masked]; [email-masked]
> "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?
> >
> 
> For configuration, NETCONF/YANG is the right choice. There is nothing that
> really competes for configuration.

Currently the Behave WG isn't looking at configuration, only monitoring
and eventing.   And my understanding is that presently it's not a 
requirement that WG's have a configuration solution, it's up to the WG.
 
> For event notifications, you have at least SYSLOG, SNMP notifications, IPFIX,
> NETCONF notifications. I think the last one is likely not a main target. SNMP
> notifications means one SNMP message per event and the same holds true
> for SYSLOG; IPFIX allows to send a collection of events in one IPFIX message
> and hence it might be more scalable, which might be important for some NAT
> deployments.

I've heard it said that IPFIX is for packet sampling not for metadata eventing,
but this isn't an area I know enough about myself to say.   I would like to say
that the Behave WG shouldn't do multiple solutions for the same thing.
I'd like the OPS area folks to help us decide which one is the most appropriate
one.   Currently we have a small number of individuals each advocating
a different protocol, and a large number of individuals (myself included)
that have no preference and want the OPS area experts to give guidance.
 
> can work. If the data structures tend to be more complex and/or the data
> instances are of larger volume, NETCONF has some advances (more efficient
> bulk transfer). If data needs to travel over shaky links (e.g. high levels of
> packet loss), SNMP _can_ have an advantage.

The data instances can have a larger volume and may need to travel over
shaky links.   Also there's an existing MIB that is outdated and we want
to obsolete.   So the WG is currently using SNMP for retrieving 
operational state and debugging, by doing an update that is intended
to obsolete the existing MIB RFC.
 
> course also ask what the contributors prefer to implement, e.g. what they
> expect to ease integration into management systems relevant for the
> protocol domain.

Answered above.   Looking to OPS for clear guidance on what eventing
protocol to use (or what criteria we should use to decide).   I don't want
multiple ones.

-Dave

---

From: Andrew Donati <[email-masked]>
Date: Tue, 7 Aug 2012 17:24:35 -0400

On Tue, Aug 7, 2012 at 5:01 PM, Romascanu, Dan (Dan) <[email-masked]>wrote:

> [AD]  Adding another item to what Juergen listed on the task of monitoring:

> high levels of packet loss), SNMP _can_ have an advantage.

For retrieving operational state and debugging on more than one or a few
devices,
SNMP can have the advantage.  SNMP works well when monitoring
numerous devices at once.

- Andy

---

From: Michael MacFaden <[email-masked]>
Date: Tue, 7 Aug 2012 15:38:34 -0700 (PDT)

> batch several events into a single IPFIX message. Of course, there
> are other considerations here, the congestion control of the underlying
> in the first place. Since this comes up in BEHAVE context, there

I agree with Juergen on mechanics but
think its not entirely an apples to apples comparison.

IPFIX transmits all its state periodically in one go whereas 
SNMP uses notifications to indicate state *has* changed and may not 
provide the entire context of what changed for a reason : that mgmt apps using 
trap a directed polling model will then poll the agent for updated state based
on the type/content of such notifications.

Hence my comment to Ron about the two being more complimentary technologies
than one might think as we've begun to see IPFIX attempt to do more of what SNMP
has done though imo not without solving the problems that trap directed polling
had previously solved.

I'd also note that we provided the following advice to 
mib module authors in RFC 3512:

   No matter which threshold is chosen to govern the
   actual transmission of NOTIFICATION-TYPEs, the idea is to describe an
   aggregated event or related set of events in as few PDUs as possible.
   http://tools.ietf.org/html/rfc3512#section-3.10.2

Mike

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 8 Aug 2012 00:43:07 +0200

> to obsolete the existing MIB RFC.

Out of curiosity, is there meanwhile a clear description you can point
to explaining why the old NAT-MIB is broken?
  
> protocol to use (or what criteria we should use to decide).   I don't want

What are the events considered? How frequent will they occur? How
stringent are the requirements to deliver them (almost) all or is the
even source designed to throttle notifications? How much data is
needed to describe the events? If all that is rather "standard" (in
terms of notification volume and individual notification size), then
SNMP might just do fine.

/js

---

From: Dave Thaler <[email-masked]>
Date: Tue, 7 Aug 2012 23:22:56 +0000

> From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-
> university.de]
> Sent: Tuesday, August 07, 2012 3:43 PM
> To: Dave Thaler
> Cc: Ronald Bonica; [email-masked]; [email-masked]; ops-
> [email-masked]
> Out of curiosity, is there meanwhile a clear description you can point to
> explaining why the old NAT-MIB is broken?

The current text by the authors of the update is at
http://tools.ietf.org/html/draft-ietf-behave-nat-mib-02#section-2.1
 
> > > Perhaps these thoughts help to make a suitable decision. One could
> > > of course also ask what the contributors prefer to implement, e.g.
> > > what they expect to ease integration into management systems
> > > relevant for the protocol domain.
> >
> stringent are the requirements to deliver them (almost) all or is the even
> source designed to throttle notifications? How much data is needed to
> describe the events? 

One example would be creation/deletion of a mapping table entry.
Depending on the exact techniques used by the instrumented implementation
it may range from extremely frequent and large volume, to infrequent and
small volume.   There is no discussion of throttling, only of techniques
that one could use to reduce the volume (independent of the protocol
used to report events).   How much data?   Probably tens of bytes per event.

> If all that is rather "standard" (in terms of notification
> volume and individual notification size), then SNMP might just do fine.

Looking not for what "might do fine" per se, as that might be a large number of
protocols, but rather for what single protocol is recommended or alternatively,
a set of guidance on how a WG should choose among various protocols.

-Dave

---

From: David Harrington <[email-masked]>
Date: Tue, 07 Aug 2012 20:16:58 -0400

Hi,

Comments inline ...

On 8/7/12 3:29 PM, "Ronald Bonica" <[email-masked]> 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

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.

>- 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.

>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 non-recommended protocols

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-masked]
+1-603-828-1401

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

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 8 Aug 2012 10:19:56 +0200

> Netconf/YANG support is seriously constrained by a lack of standard YANG

This sounds a bit like "do not write standard YANG data models because there
are no standard data models". Anyway, NETMOD has core data models in WG last
call. We are getting there, slowly by surely.

> (e.g., CLI commands with XML tags, not YANG).

I can't let this "CLI commands with XML tags" pass uncommented. While
some (IMHO broken) implementations might do this, there are router
vendors who actually do ship implementations with structured data
models.

> format to provide core data models.

Again, this is not very accurate. The NETMOD WG is not just converting
MIBs.  The routing data model goes far beyond anything out there in
MIB land related to routing by providing a routing model. The IP
configuration model is the first time the IETF every comes up with a
standards-track way to configure IP interfaces.

> I am not aware of much non-scripted application-support for netconf

This sounds a bit like NETCONF is designed for human operators messing
around with devices. At least one big router vendor has reported to
base its management system solely on NETCONF, providing adaptors for
legacy interfaces where necessary.

I think we should be careful not to place NETCONF/YANG into a certain
corner at this point in time by drawing a picture that might not be
adequate. YANG was published just in Octover 2010 and it is only since
then that we are able to work on standard data models. Give the
technology some more time before drawing conclusions like the above.

/js (NETMOD co-chair)

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Wed, 8 Aug 2012 11:01:56 +0200

> Behalf Of Dave Thaler
> Sent: Wednesday, August 08, 2012 2:23 AM
> To: Juergen Schoenwaelder
> Cc: [email-masked]; [email-masked]; tsv-
> [email-masked]
> > Cc: Ronald Bonica; [email-masked];
> > [email-masked]; ops- [email-masked]
> > > shaky links.   Also there's an existing MIB that is outdated and
we
> want
> > needed to describe the events?
> 
> Depending on the exact techniques used by the instrumented
> implementation it may range from extremely frequent and large volume,
to
> infrequent and
> > If all that is rather "standard" (in terms of notification volume
and
> > individual notification size), then SNMP might just do fine.
> 
> Looking not for what "might do fine" per se, as that might be a large
> number of protocols, but rather for what single protocol is
recommended
> or alternatively, a set of guidance on how a WG should choose among
> various protocols.
> 
> -Dave
> 

[[DR]] It looks like there are two levels in this discussion. One
relates specifically to the domain currently managed by using the
existing NAT MIB, with the analysis of the gaps (and brokenness) and
solutions for the specific problems. The other is about ' a set of
guidance on how a WG (any WG, not only BEHAVE) should choose among
various protocols'. If my guess that BEHAVE would rather have the first
specific level addressed without waiting for a generic solution to the
later level, I suggest that we focus on the NAT management problem space
first. We (in the OPS area) may learn some lessons about how to deal
with the more general level as well. 

Dan

---

From: David Harrington <[email-masked]>
Date: Wed, 08 Aug 2012 11:16:19 -0400

Hi,

Inline ...
--
David Harrington
[email-masked]
+1-603-828-1401

>call. We are getting there, slowly by surely.

I'm sorry you saw this as being negative. The following sentences discuss
the active efforts to mitigate the issue.
And no where did I say standardized YANG data models shouldn't be written.

I strongly support the development of core models consistent with the MIB
information models (for consistency in management),
PLUS the development of new YANG modeling that MIB modules cannot do well,
such as routing technologies.
The MIB problem (a whole box cannot be managed using SNMP, largely because
there are not MIB modules representing everything in a box) is also a
problem for Netconf - the lack of YANG modeling for everything in a box.
Part of the MIB problem is that SMIv2 is not good for representing some
aspects of a box, such as nested tables; Hopefully YANG will overcome that
problem so more things in a box can be modeled reasonably.

>vendors who actually do ship implementations with structured data

Some vendors have used a CLI with XML tags proprietary approach; others
use structured data, such as proprietary XMLSchema models.
My observation is that currently implementations often use proprietary
data modeling approaches rather than YANG.
I would much rather see standardized YANG models widely deployed.
I just don't think that is the current state of deployment.

>MIBs.  

Where did I say they were JUST converting MIBs? Read the following
sentence in my email.
Please look at my whole comment; don't just react sentence by sentence.

>The routing data model goes far beyond anything out there in

And what does my next sentence say?

>technology some more time before drawing conclusions like the above.

That is exactly my point. The YANG standard database needs "some more
time" to be expanded and to mature.

However, BEHAVE needs to be able to develop usable standardized management
NOW, 
In a few years, after YANG has had additional time for industry adoption
and standardized YANG modules are abundant, then using YANG would be a
good thing.
But NATs interact with multiple parts of systems. There are standardized
MIB modules for many of those core system parts available now, so MIB
modules to support BEHAVE technologies will likely find MIB modules that
support many of the core system features that NATs must interact with.
OTOH, many of those same core technologies do not yet have a standardized
YANG data module, so BEHAVE would need to either build support for those
other things into their YANG data models (where they are not necessarily
the experts) or wait for standardized YANG modules to be developed.

I don't think standardized configuration is mature enough YET, or widely
deployed enough YET, to justify BEHAVE allocating its scarce resources to
modeling YANG configurations, and then trying to convince the industry to
widely deploy Netconf and those data models. In the future, yes; now, no.
I think the Netconf/YANG technology needs "some more time" to mature and
for the Internet-industry's demand for cross-vendor standardized
configuration to grow.
In comparison, SNMP monitoring and Syslog logging are very mature, and
already supported by wide deployment both at the device and application
level.

I think SNMP and Syslog make sense NOW to meet the BEHAVE current
requirements for monitoring, eventing, and logging.
Standardized configuration for BEHAVE can come later  - which fits well
with the time needed for core+other YANG models to be developed and
deployed.

Dbh (ex-NETMOD co-chair, ex Syslog co-chair, ex SNMPv3 co-chair, ex BEHAVE
AD )

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 9 Aug 2012 07:46:57 +0200

> data modeling approaches rather than YANG.

I do not know which sample you take your observations from. Since
NETCONF well predates YANG, it did not mandate YANG and hence data
models specified in say XSD are not a surprise. What is broken is the
notion of <tag>lots of proprietary unstructured cli</tag> and your
text was somehow hinting at this being the state of that art.

> Please look at my whole comment; don't just react sentence by sentence.

Your sentence did make it sound like a format conversion exercise,
which I have to object to. The NETMOD working group, in particular, is
not "converting many MIB modules into YANG format to provide core data
models".
 
> time" to be expanded and to mature.

So then give it time and please do not draw a picture about NETCONF
and YANG which I think is not fair.

Thanks.

/js

---

From: t.petch <[email-masked]>
Date: Thu, 9 Aug 2012 09:51:51 +0100

----- Original Message -----
From: "Dave Thaler" <[email-masked]>
To: "Juergen Schoenwaelder" <[email-masked]>
Sent: Wednesday, August 08, 2012 12:22 AM
> > > shaky links.   Also there's an existing MIB that is outdated and
we want
> http://tools.ietf.org/html/draft-ietf-behave-nat-mib-02#section-2.1

Which worries me.  Section 2 makes a very brief summary of all the
new facilities that have been introduced, eliminates all the much more
detailed description of what is there but is now deprecated.

I did not at first see the new objects and tables since they have been
placed in the I-D after the conformance clauses, not wrong but unusual.

Since almost all of RFC4008 has been deprecated and much new introduced,
to carry on using
natMIB MODULE-IDENTITY
::= { mib-2 123 }
seems inappropriate.

More fundamentally, the considerable amount of detailed work on the
OBJECT-TYPEs and the lack of an explanation in section 2 suggests
that this work has embarked on detailed design before defining the
requirements, an approach which does not always lead to a successful
outcome.

Tom Petch

> Depending on the exact techniques used by the instrumented
implementation
> Looking not for what "might do fine" per se, as that might be a large
number of

---

From: Benoit Claise <[email-masked]>
Date: Thu, 09 Aug 2012 12:14:21 +0200

Hi Juergen,

Good summary. This piece of history (about SMIng, amongst others 
things), could have been perfect for an appendix in RFC 6632.

What I mentioned in the OPS-AREA is that we need a consistent 
information model.
 From RFC3444 (I guess that you know about that one ;-)

              IM                --> conceptual/abstract model
               |                    for designers and operators
    +----------+---------+
    |          |         |
    DM        DM         DM     --> concrete/detailed model
                                    for implementors

Maybe we don't need a protocol independent data modeling language?
Maybe we don't need an automatic translation between data models?
I understand that it would be ideal to have one of the two, but I agree 
with your conclusions:

In EMAN, we stressed that, what was important, was the information 
model. Therefore, we used UML to define the information model. And in 
the same documents, we have the MIB module(s).
See
     http://tools.ietf.org/html/draft-ietf-eman-framework-05
     http://tools.ietf.org/html/draft-ietf-eman-energy-aware-mib-06
http://tools.ietf.org/html/draft-ietf-eman-energy-monitoring-mib-03
Disclaimer: I guess the diagrams are not really UML compliant, but this 
could easily be fixed.
So someone could take the UML and produce a YANG module out of it, as 
opposed to the MIB module

Another example is 
http://tools.ietf.org/html/draft-ietf-ipfix-configuration-model-11, 
which contains UML diagrams, and the YANG module in the same document.

My point is that someone could take the same UML diagrams and deduce 
another data models (YANG, MIB module, IPFIX)

Granted, the UML doesn't provide all the information. Example: possible 
commands on objects, notifications, etc...
Granted, the NMS would require some sort of  proxy function between data 
models (the YANG module leaf X = the MIB OID Y = IPFIX Information 
Element Z).  However, the consistent source (i.e. the UML) should help a 
lot. Let's take the following UML diagram from 
http://tools.ietf.org/html/draft-ietf-ipfix-configuration-model-11

     +------------------------------+
     | SctpExporter                 |
     +------------------------------+    0..1 +------------------------+
     | ipfixVersion = 10            |<>-------| TransportLayerSecurity |
     | sourceIPAddress[0..*]        |         +------------------------+
     | destinationIPAddress[1..*]   |
     | destinationPort = 4739|4740  |    0..1 +------------------------+
     | ifName/ifIndex[0..1]         |<>-------| TransportSession       |
     | sendBufferSize {opt.}        |         +------------------------+
     | rateLimit[0..1]              |
     | timedReliability = 0         |
     +------------------------------+

                        Figure 17: SctpExporter class

If the object "IPFIX Version" would have the same "ipfixVersion" name in 
multiple data models (assuming that the naming convention in the 
different data models are respected), that would help already.

Feedback?

Btw, I like your article at 
http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=4511663

Regards, Benoit.

---

From: Benoit Claise <[email-masked]>
Date: Thu, 09 Aug 2012 13:30:07 +0200

Dave,

Answering a single point below (still reading the entire email thread)
> but this isn't an area I know enough about myself to say.
IPFIX is an push-based export protocol. This is not only for packet 
sampling.
How data are produced is out of the scope of IPFIX (Full Flow, Sampled 
Flow, …).
It's true that the PSAMP WG defined a Metering Process for packet 
sampling, and that the chosen export protocol is IPFIX, but that doesn't 
limit IPFIX to packet sampling only.
Actually, IPFIX became a generic push mechanism these days, not only 
reporting flow information.

Regards, Benoit.

---

From: Thomas Nadeau <[email-masked]>
Date: Thu, 9 Aug 2012 08:44:15 -0400

Maybe UML diagrams are all we need to guide the detailed model/implementations as a "framework" document each WG would be required to produce as a base charter item for any new protocol definitions?    This approach would then give the WG the flexibility with which to define the actual management interfaces as it sees. Note, I do understand the comments some WG chairs made at the OPS meeting in this regard to cross-WG coordination, but that is something again, that a common UML model would address as well as cross-WG "shepherding" from the OPS AD or a designee to help keep things consistent.

	I agree that auto-generated stuff is difficult at best. The other thing to keep in mind is that doing a lot of work in this regard is going to only apply to new stuff going forward - its always a huge challenge to do anything backwards-compatable.   

	--Tom

On Aug 9, 2012:6:14 AM, at 6:14 AM, Benoit Claise <[email-masked]> wrote:

> Hi Juergen,
> 
> Good summary. This piece of history (about SMIng, amongst others things), could have been perfect for an appendix in RFC 6632.
> 
> What I mentioned in the OPS-AREA is that we need a consistent information model.
> I understand that it would be ideal to have one of the two, but I agree with your conclusions:
> In EMAN, we stressed that, what was important, was the information model. Therefore, we used UML to define the information model. And in the same documents, we have the MIB module(s). 
> See 
> Disclaimer: I guess the diagrams are not really UML compliant, but this could easily be fixed.
> So someone could take the UML and produce a YANG module out of it, as opposed to the MIB module
> 
> Another example is http://tools.ietf.org/html/draft-ietf-ipfix-configuration-model-11, which contains UML diagrams, and the YANG module in the same document. 
> 
> My point is that someone could take the same UML diagrams and deduce another data models (YANG, MIB module, IPFIX)
> 
> Granted, the UML doesn't provide all the information. Example: possible commands on objects, notifications, etc...
> Granted, the NMS would require some sort of  proxy function between data models (the YANG module leaf X = the MIB OID Y = IPFIX Information Element Z).  However, the consistent source (i.e. the UML) should help a lot. Let's take the following UML diagram from http://tools.ietf.org/html/draft-ietf-ipfix-configuration-model-11
> If the object "IPFIX Version" would have the same "ipfixVersion" name in multiple data models (assuming that the naming convention in the different data models are respected), that would help already.
> 
> Feedback?
> 
> Btw, I like your article at http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=4511663
> 
> Regards, Benoit.
>> Hi,
>>

---

From: Benoit Claise <[email-masked]>
Date: Thu, 09 Aug 2012 15:54:58 +0200

Ron,

I read the entire email thread. So let me reply to this email with 
information from different participants

I agree with Dan that there are two problems.
1. a set of guidance on how a WG (any WG, not only BEHAVE) should choose 
among various protocols'
2. what to do specifically in the BEHAVE case

Let me focus on 1., it's time to update RFC1052, as Dan and Tom 
explained during the OPS-AREA meeting
We should set the guidance for the entire community.
The fact that there are not many YANG modules today shouldn't play 
against NETCONF/YANG. The guidance could still be: if you want to do 
configuration, YANG/NETCONF is the way to go
What we need is a flowchart type of things, to make it very easy for 
non-OPS group to follow
As an _example _:

    - Document the operational requirements, and what information needs
    to be configured/monitored/preserved. Ideally, use an information
    model language (see the previous thread)
    - Is there an existing data models you want to extend. If yes,
    extend it
    - Configuration? Use NETCONF/YANG
            no configuration now: do you plan on having configuration in
    the future?
            if "yes", investigate NETCONF/YANG
            if "maybe", use an information model language (see the
    previous thread)
    - Operational data?
         If there is a MIB, feel free to extend it?
         If there is no MIB module so far, insert the operational data
    in the YANG module
    - you want to push some data at a high rate ? Investigate IPFIX
    - you want some events
             if you have a MIB module, evaluate the SNMP notification
             if you have a YANG modue, evaluate the YANG notification
             if you want plain english text events, evaluate syslog
             if you want some structured events, evaluate syslog SDE
    - etc...

    Note: obviously, when comparing technologies, the pros/cons must be
    explained.

It's true that RFC 5706 and RFC 6632 will help, but we should really set 
some guidance between the different OPS architectures.

This exercise will certainly require some discussions with the couple of 
first requests, to make sure we document everything. So that's maybe 
what we should do in the BEHAVE case: have a live discussion.

Regards, Benoit.

---

From: "Randy Presuhn" <[email-masked]>
Date: Thu, 9 Aug 2012 12:36:22 -0700

Hi -

> From: "Thomas Nadeau" <[email-masked]>
> To: "Benoit Claise" <[email-masked]>
> Cc: <[email-masked]>
> Sent: Thursday, August 09, 2012 5:44 AM
> Subject: Re: [OPS-AREA] data models and translations / mappings
>
> Maybe UML diagrams are all we need to guide the detailed model/implementations
> as a "framework" document each WG would be required to produce as a
> base charter item for any new protocol definitions?    This approach would then
> give the WG the flexibility with which to define the actual management interfaces
> as it sees. Note, I do understand the comments some WG chairs made at the
> OPS meeting in this regard to cross-WG coordination, but that is something
> again, that a common UML model would address as well as cross-WG "shepherding"
> from the OPS AD or a designee to help keep things consistent.
>
> I agree that auto-generated stuff is difficult at best. The other thing to keep in mind
> is that doing a lot of work in this regard is going to only apply to new stuff going forward -
> its always a huge challenge to do anything backwards-compatable.   

UML diagrams can be a great help in capturing requirements, and I'd like
to see them used more for the really high level stuff.  But sometimes
the tools provided by a particular protocol / data modeling combination
result in decisions beyond or at odds with what the UML might say.  For example,
the indexes in an SNMP table might be ordered so that a subset of the
entries in a table will be clustered so that for certain use cases, management
applications can avoid walking through the entire table.  Or there may even
be multiple tables to provide access to the same information, but with differing
index structures to support different use cases.  With other protocols, other
data model tricks might be used to accomplish the same goal with more
sophisticated query mechanisms.  With "framework" models, UML or otherwise,
we need to be wary of accidental over-specification.

Randy

---

From: Ronald Bonica <[email-masked]>
Date: Thu, 9 Aug 2012 20:53:40 -0400

Benoit,

IMHO, our first priority should be to provide concrete guidance to BEHAVE. The BEHAVE WG will become grumpy if we ask them to wait while OPS debates abstractions.

Our second priority should be to issue general guidance to WGs. Guidance should answer the following questions:

-          Does the WG need model managed data?

-          Can managed data be divided into categories? If so, how? (Configuration versus operational state?  candidate versus current versus previous state? Data that is sampled versus data that is retained completely? Data that must be retained versus data that can be lost?)

-          What protocol does the IETF recommend for each category?

-          Does the IETF recommendation give implementers latitude to use a protocol other than that which is recommended? How much latitude?

-          How should data be modeled? Using an abstract notation or a protocol specific notation?

Comments?

                    Ron

From: Benoit Claise [mailto:[email-masked]]
Sent: Thursday, August 09, 2012 9:55 AM
To: Ronald Bonica
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [OPS-AREA] Management Requirements

Ron,

I read the entire email thread. So let me reply to this email with information from different participants

I agree with Dan that there are two problems.
1. a set of guidance on how a WG (any WG, not only BEHAVE) should choose among various protocols'
2. what to do specifically in the BEHAVE case

Let me focus on 1., it's time to update RFC1052, as Dan and Tom explained during the OPS-AREA meeting
We should set the guidance for the entire community.
The fact that there are not many YANG modules today shouldn't play against NETCONF/YANG. The guidance could still be: if you want to do configuration, YANG/NETCONF is the way to go
What we need is a flowchart type of things, to make it very easy for non-OPS group to follow
As an example :
- Document the operational requirements, and what information needs to be configured/monitored/preserved. Ideally, use an information model language (see the previous thread)
- Is there an existing data models you want to extend. If yes, extend it
- Configuration? Use NETCONF/YANG
       no configuration now: do you plan on having configuration in the future?
       if "yes", investigate NETCONF/YANG
       if "maybe", use an information model language (see the previous thread)
- Operational data?
    If there is a MIB, feel free to extend it?
    If there is no MIB module so far, insert the operational data in the YANG module
- you want to push some data at a high rate ? Investigate IPFIX
- you want some events
        if you have a MIB module, evaluate the SNMP notification
        if you have a YANG modue, evaluate the YANG notification
        if you want plain english text events, evaluate syslog
        if you want some structured events, evaluate syslog SDE
- etc...

Note: obviously, when comparing technologies, the pros/cons must be explained.

It's true that RFC 5706 and RFC 6632 will help, but we should really set some guidance between the different OPS architectures.

This exercise will certainly require some discussions with the couple of first requests, to make sure we document everything. So that's maybe what we should do in the BEHAVE case: have a live discussion.

Regards, Benoit.

Folks,

Comments?

                                              Ron

OPS-AREA mailing list

[email-masked]<mailto:[email-masked]>

---

From: "Adrian Farrel" <[email-masked]>
Date: Fri, 10 Aug 2012 03:19:09 +0100

Hi Benoit, 
 
This is a reasonable start, but does omit the whole "information model" thing.
I confess to finding UML diagrams not very useful. I prefer an information model
written in some form of semi-formal language. I am wondering whether YANG isn't
exactly that language. (Yes, that gives the YANG module an unfair advantage).
 
BTW, I really wish we didn't always write "NETCONF/YANG". They are separate
entities and one could use one without the other.
 
Cheers,
Adrian
 
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Benoit Claise
Sent: 09 August 2012 14:55
To: Ronald Bonica
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [OPS-AREA] Management Requirements
 
Ron,

I read the entire email thread. So let me reply to this email with information
from different participants

I agree with Dan that there are two problems.
1. a set of guidance on how a WG (any WG, not only BEHAVE) should choose among
various protocols'
2. what to do specifically in the BEHAVE case

Let me focus on 1., it's time to update RFC1052, as Dan and Tom explained during
the OPS-AREA meeting
We should set the guidance for the entire community.
The fact that there are not many YANG modules today shouldn't play against
NETCONF/YANG. The guidance could still be: if you want to do configuration,
YANG/NETCONF is the way to go
What we need is a flowchart type of things, to make it very easy for non-OPS
group to follow
As an example :
- Document the operational requirements, and what information needs to be
configured/monitored/preserved. Ideally, use an information model language (see
the previous thread)
- Is there an existing data models you want to extend. If yes, extend it 
- Configuration? Use NETCONF/YANG
       no configuration now: do you plan on having configuration in the future?
       if "yes", investigate NETCONF/YANG
       if "maybe", use an information model language (see the previous thread) 
- Operational data? 
    If there is a MIB, feel free to extend it?
    If there is no MIB module so far, insert the operational data in the YANG
module
- you want to push some data at a high rate ? Investigate IPFIX
- you want some events
        if you have a MIB module, evaluate the SNMP notification
        if you have a YANG modue, evaluate the YANG notification
        if you want plain english text events, evaluate syslog
        if you want some structured events, evaluate syslog SDE
- etc...

It's true that RFC 5706 and RFC 6632 will help, but we should really set some
guidance between the different OPS architectures.

This exercise will certainly require some discussions with the couple of first
requests, to make sure we document everything. So that's maybe what we should do
in the BEHAVE case: have a live discussion.

Regards, Benoit.
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 BEHAVE WG knows what information needs to be
configured/monitored/preserved. They MUST specify that.
- 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.
- 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

---

From: Benoit Claise <[email-masked]>
Date: Fri, 10 Aug 2012 15:04:33 +0200

Ron,
>
> Benoit,
>
> IMHO, our first priority should be to provide concrete guidance to 
> BEHAVE. The BEHAVE WG will become grumpy if we ask them to wait while 
> OPS debates abstractions.
>
Agreed.
Since we don't have the clear guidelines written down right now, I 
believe that conf. call is the way to go in this case.
>
> Our second priority should be to issue general guidance to WGs. 
> Guidance should answer the following questions:
>
> -Does the WG need model managed data?
>
> -Can managed data be divided into categories? If so, how? 
> (Configuration versus operational state?  candidate versus current 
> versus previous state? Data that is sampled versus data that is 
> retained completely? Data that must be retained versus data that can 
> be lost?)
>
> -What protocol does the IETF recommend for each category?
>
> -Does the IETF recommendation give implementers latitude to use a 
> protocol other than that which is recommended? How much latitude?
>
> -How should data be modeled? Using an abstract notation or a protocol 
> specific notation?
>
That's a good series of questions to start with.

Regards, Benoit
>
> Comments?
>
> Ron
>
> *From:*Benoit Claise [mailto:[email-masked]]
> *Sent:* Thursday, August 09, 2012 9:55 AM
> *To:* Ronald Bonica
> *Cc:* [email-masked]; [email-masked]; 
> [email-masked]
> *Subject:* Re: [OPS-AREA] Management Requirements
>
> Ron,
>
> - Document the operational requirements, and what information needs to 
> be configured/monitored/preserved. Ideally, use an information model 
> language (see the previous thread)
> It's true that RFC 5706 and RFC 6632 will help, but we should really 
> set some guidance between the different OPS architectures.
>
> This exercise will certainly require some discussions with the couple 
> of first requests, to make sure we document everything. So that's 
> maybe what we should do in the BEHAVE case: have a live discussion.
>
> Regards, Benoit.
>
>     Folks,
>
>       
>
>     [email-masked]  <mailto:[email-masked]>
>

---

From: Benoit Claise <[email-masked]>
Date: Fri, 10 Aug 2012 15:10:34 +0200

Hi Adrian,

Thanks for your feedback.
> This is a reasonable start, but does omit the whole "information 
I'm not sure how we could have some sort of data models consistency 
without a common information model.
>
> I confess to finding UML diagrams not very useful. I prefer an 
> information model written in some form of semi-formal language. I am 
> wondering whether YANG isn't exactly that language.
>
I'll investigate if this is the case...
>
> (Yes, that gives the YANG module an unfair advantage).
>
That would be nice.
>
> BTW, I really wish we didn't always write "NETCONF/YANG". They are 
> separate entities and one could use one without the other.
>
What was meant is: define your data model in YANG, and manage your boxes 
with the NETCONF protocol

Regards, Benoit.
>
> Cheers,
>
> Adrian
>
> *From:[email-masked] [mailto:[email-masked]] 
> *On Behalf Of *Benoit Claise
> *Sent:* 09 August 2012 14:55
> *To:* Ronald Bonica
> *Cc:* [email-masked]; [email-masked]; 
> [email-masked]

---

From: Andrew Donati <[email-masked]>
Date: Fri, 10 Aug 2012 10:31:07 -0400

non-OPS group to follow
>As an *example *:- Document the operational requirements

As part of the operational requirements,  we also need insight on how
management information will be used in the field .  Knowing this
information will also help determine the appropriate tool or set of tools
to use.  Here are a few  questions to start with.

- Is configuration required ?
- Will numerous devices (i.e. hundreds of devices) be monitored  by any one
management entity ?
- When monitoring any one device, does it require the collection of a large
amount of data?  If so , how large?
- How frequently will any one device be monitored?
- Will any one device be monitored periodically or only when it sends an
unsolicited event ?
- How busy and reliable will the management network be ?

- Andy

On Thu, Aug 9, 2012 at 8:53 PM, Ronald Bonica <[email-masked]> wrote:

> Benoit,****
>
> ** **
>
> IMHO, our first priority should be to provide concrete guidance to BEHAVE.
> The BEHAVE WG will become grumpy if we ask them to wait while OPS debates
> abstractions.****
>
> ** **
>
> Our second priority should be to issue general guidance to WGs. Guidance
> should answer the following questions:****
>
> ** **
>
> **-          **Does the WG need model managed data?****
>
> **-          **Can managed data be divided into categories? If so, how?
> (Configuration versus operational state?  candidate versus current versus
> previous state? Data that is sampled versus data that is retained
> completely? Data that must be retained versus data that can be lost?)****
>
> **-          **What protocol does the IETF recommend for each category? **
> **
>
> **-          **Does the IETF recommendation give implementers latitude to
> use a protocol other than that which is recommended? How much latitude?***
> *
>
> **-          **How should data be modeled? Using an abstract notation or
> a protocol specific notation?****
>
> ** **
>
> Comments?****
>
> ** **
>
>                     Ron****
>
> ** **
>
> ** **
>
> *From:* Benoit Claise [mailto:[email-masked]]
> *Subject:* Re: [OPS-AREA] Management Requirements****
>
> ** **
>
> Ron,
>
> As an *example *:****
> configured/monitored/preserved. Ideally, use an information model language
> (see the previous thread)
> explained.****
> first requests, to make sure we document everything. So that's maybe what
> we should do in the BEHAVE case: have a live discussion.
>
> Regards, Benoit.****
>
> 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?****
>
> ** **
>
> My best guess follows......****
>
> ** **
>
> - The BEHAVE WG knows what information needs to be configured/monitored/preserved. They MUST specify that.****
>
> - 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.****
>
> - 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****
>
> ** **
>
> ** **
>
> ** **
>
> _______________________________________________****
>
> OPS-AREA mailing list****
>
> [email-masked]****
>
> https://www.ietf.org/mailman/listinfo/ops-area****
>
> ** **
>
> ** **
>
> ** **
>

-- 
Andy Donati
Motorola Mobility
978-614-3190