Subject: [OPSAWG] network management data models - a rewrite

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 17 Nov 2011 05:18:57 +0100

Hi,

draft-ietf-opsawg-management-stds-02 has a section on "Network
Management Data Models" which is structured around FCAPS which I
happen to dislike for several reasons (data model work in the IETF is
not organized around FCAPS, the discussion is constantly changing
abstraction levels, some of the examples picked are somewhat
surprising). To be constructive, I have written a replacement for this
section that I think better summarizes what the IETF has to offer and
how data modeling work happens to be done in the IETF. In addition, it
is also shorter.

I do not mind if my proposed rewrite is followed by a section
discussing how all this fits into an FCAPS view of the world but such
a section should be much shorter and different from what is in the
current section 4. (For me, a short explanation that the IETF does not
organize data models around FCAPS is really sufficient but I guess
Mehmet and Benoit might not agree with that.)

/js

-- 
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: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Thu, 17 Nov 2011 07:05:15 +0100

Hi Juergen,

It's not only Mehmet and Benoit, it's also me (as contributor and AD),
and at least one position expressed in the meeting and also the silent
majority in the WG meeting (to be confirmed on the list) that agree with
us or do not care. You missed I think that part of the OPSAWG meeting,
but what was said and agreed I think (pending on list confirmation) is
that the goal of the document or one of its principal goals is to
provide a view of the IETF data models for NM for external SDOs. Many of
those look at management apps via a FCAPS view, and providing both views
is equally important. This is the reason for which while agreeing with
your view that we must emphasize the way data modeling happens in the
IETF and explain it, I believe that keeping a minimal but meaningful
level of presentation of the models through the FCAPS perspective is
necessary for the participants out of the IETF.

Dan

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Juergen Schoenwaelder
> Sent: Thursday, November 17, 2011 6:19 AM
> To: [email-masked]
> Subject: [OPSAWG] network management data models - a rewrite
> 
> Hi,
> 
happen
> to dislike for several reasons (data model work in the IETF is not
> organized around FCAPS, the discussion is constantly changing
a
> section should be much shorter and different from what is in the

---

From: "Ersue, Mehmet (NSN - DE/Munich)" <[email-masked]>
Date: Thu, 17 Nov 2011 07:17:44 +0100

Dear Juergen,

thank you for your contribution. It is valuable and fits the discussion 
in the OPSAWG session for the second view in the document.

> surprising). 

Please comment on the examples you find as not suitable.

> To be constructive, I have written a replacement for this

As discussed and agreed in the OPSAWG session (by the persons in the 
session; unfortunately you were not in the meeting room at that time) 
the best approach is to have both views in the document. 

>From the very first version of the draft our aim was to provide a
detailed 
data model survey as a guidance for the audience outside of the IETF. 
The survey can be for sure tuned or optimized as necessary. However,
we should strive for a publishing soon rather than having more cycles.

Mehmet

---

From: Christopher LILJENSTOLPE <[email-masked]>
Date: Wed, 16 Nov 2011 22:25:32 -0800

Greetings all,

	To confirm - the temperature check in the room was to include both views in the document, as one view may resonate better with different communities.  I believe that your contribution will be a valuable addition to the document, as it stands.  If you have some specific issues regarding the examples and their suitability, please work with the authors on the document, however we need to do so quickly.  The consensus in the room was to advance the document in short order.  

	If anyone else in the group has a feeling on this topic, please speak up on the list in short order.

	Thank you,
	Chris

On 16Nov2011, at 22.17, Ersue, Mehmet (NSN - DE/Munich) wrote:

> _______________________________________________
> OPSAWG mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/opsawg

--  
李柯睿
Check my PGP key here: https://www.asgaard.org/~cdl/cdl.asc
Current vCard here: https://www.asgaard.org/~cdl/cdl.vcf

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 17 Nov 2011 07:42:01 +0100

> necessary for the participants out of the IETF.

The text there currently is in my view not suitable to say it
politely. If needed, I can also write a short text explaining why data
models are not organized around FCAPS in the IETF. (There is already
text like that.) If people want text that puts our data models into
FCAPS in some level of detail, you will either produce boring
repetition (as most of our MIB modules do support P and F equally
well) or you have to have text that is much shorter and remains at a
rather abstract level, i.e. data link data models usually support P
and F.

I am not strictly against having some FCAPS discussion in the document
but the text we currently have is IMHO not suitable.

/js

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 17 Nov 2011 07:47:42 +0100

On Wed, Nov 16, 2011 at 10:25:32PM -0800, Christopher LILJENSTOLPE wrote:
 
> To confirm - the temperature check in the room was to include both
> views in the document, as one view may resonate better with
> different communities.  I believe that your contribution will be a
> valuable addition to the document, as it stands.  If you have some
> specific issues regarding the examples and their suitability, please
> work with the authors on the document, however we need to do so
> quickly.  The consensus in the room was to advance the document in
> short order.

I am trying to work with the authors. I think it is now their turn to
revise their text. (I can also write something about FCAPS myself but
that might not get us closer to a solution acceptable for all of us.)

/js

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Thu, 17 Nov 2011 07:48:15 +0100

Juergen,

Text proposals are always welcome. The text needs however include IMO
not only information about 'why data models are not organized around
FCAPS in the IETF' but also 'text that puts our data models into FCAPS
in some level of detail'. Some 'text that is much shorter and remains at
a rather abstract level' could work, so, please, send your proposals. 

Regards,

Dan

> From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-
> university.de]
> Sent: Thursday, November 17, 2011 8:42 AM
> To: Romascanu, Dan (Dan)
> Cc: [email-masked]
> Subject: Re: [OPSAWG] network management data models - a rewrite
> 
> > provide a view of the IETF data models for NM for external SDOs.
Many
> of

---

From: "Ersue, Mehmet (NSN - DE/Munich)" <[email-masked]>
Date: Thu, 17 Nov 2011 07:57:03 +0100

Before producing text we should use the opportunity of the IETF meeting 
to talk to each other. Unfortunately the meeting we planned today did
not 
happen.

Shorting up the FCAPS-based view to a few lines is not helpful. There is
a 
need for a detailed survey as a guidance for the audience of the
document.

Cheers, 
Mehmet 

> From: ext Juergen Schoenwaelder
[mailto:[email-masked]]
> Sent: Thursday, November 17, 2011 7:48 AM
> To: Christopher LILJENSTOLPE
> Cc: Ersue, Mehmet (NSN - DE/Munich); [email-masked]

---

From: "Bert Wijnen (IETF)" <[email-masked]>
Date: Thu, 17 Nov 2011 14:58:07 +0800

I like Juergens contribution.

And although I agree that some text on how our stuff
relates to FCAPS might be good, I would not dwell on it
too much.

Bert

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 17 Nov 2011 08:11:44 +0100

On Thu, Nov 17, 2011 at 07:57:03AM +0100, Ersue, Mehmet (NSN - DE/Munich) wrote:
 
> Shorting up the FCAPS-based view to a few lines is not
> helpful. There is a need for a detailed survey as a guidance for the
> audience of the document.

One more example: Look at section 4.3 Accounting Management providing
a list of different IPFIX information elements. Is that the level of
detail you find appropriate? How many of the information elements
listed there do you think are important for Accounting Management? Do
you propose to have the IEs listed as well in sections 4.1 Fault
Management, 4.4 Performance Management, and 4.5 Security Management?

If we talk about FCAPS, we will only finish in finite time by staying
abstract.

/js

---

From: "Randy Presuhn" <[email-masked]>
Date: Wed, 16 Nov 2011 23:14:58 -0800

Hi -

> From: "Romascanu, Dan (Dan)" <[email-masked]>
> To: "Juergen Schoenwaelder" <[email-masked]>
> Cc: <[email-masked]>
> Sent: Wednesday, November 16, 2011 10:48 PM
...
> Some 'text that is much shorter and remains at

Here's a stab at a beginning:

IETF network management data models are not organized in terms of
FCAPS.  However, one can generally categorize the use cases supported
by a given model in those terms.  For example, most (but not all) of the use
cases one might envision for the VACM MIB are clearly related to security.
For other MIBs, things are not necessarily as clear-cut, and the obvious
use cases (which are not always documented in the RFCs) may relate to
multiple FCAPS aspects.

Randy

---

From: "Ersue, Mehmet (NSN - DE/Munich)" <[email-masked]>
Date: Thu, 17 Nov 2011 08:41:59 +0100

> Management, 4.4 Performance Management, and 4.5 Security Management?

I tend to agree that the IPFIX IEs are not needed in this level of
detail.
Benoit promised to provide an update.

Mehmet

---

From: Benoit Claise <[email-masked]>
Date: Fri, 18 Nov 2011 13:00:33 +0800

> Benoit promised to provide an update.
Yes, I agree too. Let me revisit this section (can't do before end of 
next week)

Regards, Benoit.

---

From: "t.petch" <[email-masked]>
Date: Thu, 24 Nov 2011 10:40:05 +0100

----- Original Message -----
From: "Romascanu, Dan (Dan)" <[email-masked]>
To: "Juergen Schoenwaelder" <[email-masked]>;
<[email-masked]>
Sent: Thursday, November 17, 2011 7:05 AM
> provide a view of the IETF data models for NM for external SDOs.

Mmmm

Looking at the minutes of the meeting, I would not have known that that was the
outcome, but no matter.

Writing this doubtless debars me from being in the silent majority, but I do
think that FCAPS should be in, as the least bad way of surveying the subject.  I
started off with a seven topic structure of management, saw that expand to ten
and shrink to six and three.  Any one would do, but we do need something in that
space; FCAPS seems the most likely to be understood.

By contrast, saying that IETF MIB modules are not like that is an
'implementation detail'.  It is how the IETF has chosen to implement its design
in the problem space, and omitting the 'big picture' of the problem space can
only reinforce the view that the IETF is something of an oddball.

In passing, you could do with a reference for [FCAPS].

Tom Petch

Many of

---

From: Benoit Claise <[email-masked]>
Date: Fri, 25 Nov 2011 17:59:13 +0100

Hi Juergen,

Thanks for your contribution.
Here is some feedback:
On 25/11/2011 17:31, Benoit Claise wrote:
> * Network Management Data Models
>
> The data models defined by the IETF can be broadly classified into
> the following categories depicted in Figure X.
>
>   +-----------+  +-------------------------------+  +-----------+
>   |           |  | application layer data models |  |  network  |
>   |  generic  |  +-------------------------------+  | management|
>   |  infra-   |  |  transport layer data models  |  |  infra-   |
>   | structure |  +-------------------------------+  | structure |
>   |   data    |  |   network layer data models   |  |   data    |
>   |  models   |  +-------------------------------+  |  models   |
>   |           |  |    link layer data models     |  |           |
>   +-----------+  +-------------------------------+  +-----------+
>
>   Figure X: Categories of network management data models
>
> Each of the categories is briefly described below. Note that the
> classification used here intends to provide orientation and reflects
> how most data models have been developed in the IETF by the various
> working groups. It is not a goal of this classification to easily and
> correctly classify all data models that have been defined by the IETF
> so far. The network layering model in the middle of Figure X follows
> the four layer model of the Internet as defined in [RFC1021].
>
> There are many technology-specific IETF data models which are not
> mentioned in this document but can be found at [RFCSEARCH].
>
> * Generic Infrastructure Data Models
>
>   Generic infrastructure data models provide core abstractions that
>   many other data models built upon. The most important of these is
>   the interfaces data model defined in the IF-MIB [RFC2863]. It
>   provides the basic notion of network interfaces and it allows to
>   express stacking/layering relationships between interfaces. The
>   interfaces data model also provides basic monitoring objects that
>   are widely used for performance and fault management.
>
>   The second important infrastructure data model is defined in the
>   Entity MIB [RFC4133]. It exports the containment hierarchy of the
>   physical entities (slots, modules, ports) that make up a networking
>   device and as such it is a key data model for inventory management.
>   Physical entities can have pointers to other data models that
>   provide more specific information about a physical entity (e.g.
>   physical ports usually point to the related network interface).
>   Entity MIB extensions exist for physical sensors such as temperature
>   sensors embedded on line cards or sensors that report fan rotation
>   speeds [RFC3433]. 
BC> I would not mention this ENTITY-MIB extension about sensor. To the 
audience, it might seem that we have master the Internet of Things with 
SNMP, which is not correct at all!

> Another extension models states and alarms of
>   physical entities [RFC4268]. Some vendors have extended the basic
>   Entity MIB with several proprietary data models.
>
> * Link Layer Data Models
>
>   A number of data models exist in the form of MIB modules covering
>   the link layers IP runs over, such as ADSL [RFC4706], VDSL
>   [RFC5650], GMPLS [RFC4803], ISDN [RFC2127], ATM [RFC2515, RFC3606],
>   Cable Modems [RFC4546] or Ethernet [RFC4188, RFC4318,
>   RFC4363]. These so called transmission data models typically extend
>   the generic network interfaces data model with interface type
>   specific information. Most of the link layer data models focus on
>   monitoring capabilities that can be used for performance and fault
>   management functions and to some lesser extend for accounting and
>   security management functions. The IEEE has meanwhile taken over the
>   responsibility to maintain and further develop data models for the
>   IEEE 802 family of protocols [RFC4663]. The cable modem industry
>   consortium DOCSIS is working with the IETF to publish data models
>   for cable modem networks as IETF standards-track specifications.
>
> * Network Layer Data Models
>
>   There are data models in the form of MIB modules covering IP/ICMP
>   [RFC4293, RFC4292] network protocols and their extensions (e.g.,
>   mobile IP), the core protocols of the Internet. In addition, there
>   are data models covering popular unicast routing protocols (OSPF
>   [RFC4750], ISIS [RFC4444], BGP-4 [RFC4273]) and multicast routing
>   protocols (PIM [RFC5060]).
>
>   Detailed models also exist for performance measurements in the form
>   of IP performance metrics [RFC2330]. IP performance metrics include
>   the definition of measurement methodologies with the goal to produce
>   repeatable and comparable measurement results. There is a growing
>   number of metrics defined for measuring loss, delay, connectivity,
>   etc.
>
>   The necessary data model infrastructure for configuration data
>   models covering network layers are currently being defined using
>   NETCONF and YANG.
>
> * Transport Layer Data Models
>
>   There are data models for the transport protocols TCP [RFC4022], UDP
>   [RFC4113], and SCTP [RFC3873]. For TCP, a data model providing
>   extended statistics is defined as well [RFC4898].
>
> * Application Layer Data Models
>
>   Some data models have been developed for specific application
>   protocols (e.g., SIP [RFC4780]). In addition, there are data models
>   that provide a generic infrastructure for instrumenting applications
>   in order to obtain data useful primarily for performance management
>   and fault management [RFC2287, RFC2564]. In general, however,
>   generic application MIB modules have been less successful in gaining
>   wide-spread deployment.
>
> * Network Management Infrastructure Data Models
>
>   A number of data models are concerned with the network management
>   system itself. This includes, in addition to a set of SNMP MIB
>   modules for monitoring and configuring SNMP itself [RFC3410], some
>   MIB modules providing generic functions such as the calculation of
>   expressions over MIB objects, generic functions for thresholding and
>   event generation, event notification logging functions and data
>   models to represent alarms [RFC2981, RFC2982, RFC3014, RFC3877]. In
>   addition, there are data models that allow to execute basic
>   reachability and path discovery tests [RFC4560].  Another collection
>   of MIB modules provides remote monitoring functions, ranging from
>   the data link layer up to the application layer. This is known as
>   the RMON family of MIB modules [RFC3577].
>
>   The IPFIX protocol [RFC5101] is used to export information about
>   network flows collected at so called observation points (typically a
>   network interface). The information elements [RFC5102] carried in
>   IPFIX cover the network and transport layer very well but also
>   provides some link layer specific information elements. Work is
>   underway to further extend the standardized information that can be
>   carried in IPFIX.
Let's add a reference to [IPFIX-IANA]. Note: [IPFIX-IANA] already exists 
as a reference in the draft.

Also add the following sentence "For example, the information element 
extension for packet sampling is
specified in the the "information model for packet sampling reports" 
[RFC5477]
>
>   The SYSLOG protocol document [RFC5424] defines an initial set of
>   Structured Data Elements (SDEs) that relate to content time quality,
>   content origin, and meta-information about the message, such as
>   language. Proprietary SDEs can be used to supplement the IETF-
>   defined SDEs.
>
I guess that we should say a few words about RADIUS and Diameter TLV/AVP 
in this " Network Management Infrastructure Data Models " section.
This way we would cover all entries (except CAPWAP) from "Table 5: Data 
Models and their Extensibility"

Regards, Benoit.

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 25 Nov 2011 20:43:57 +0100

On Fri, Nov 25, 2011 at 05:59:13PM +0100, Benoit Claise wrote:

> BC> I would not mention this ENTITY-MIB extension about sensor. To
> the audience, it might seem that we have master the Internet of
> Things with SNMP, which is not correct at all!

You mentioned this earlier and this is why I wrote text that is more
specific: "physical sensors such as temperature sensors embedded on
line cards or sensors that report fan rotation speeds". If people
still misunderstand this because they are only used to scan for
keywords and then make up their own story I think we can't help.
 
> Let's add a reference to [IPFIX-IANA]. Note: [IPFIX-IANA] already
> exists as a reference in the draft.
> 
> Also add the following sentence "For example, the information
> element extension for packet sampling is

Fine.

> I guess that we should say a few words about RADIUS and Diameter
> TLV/AVP in this " Network Management Infrastructure Data Models "
> section.
> This way we would cover all entries (except CAPWAP) from "Table 5:
> Data Models and their Extensibility"

I am less familiar with their AVPs and how to summarize them. I agree
that they should be mentioned - would be great is someone can propose
text.

/js

---

From: Benoit Claise <[email-masked]>
Date: Mon, 28 Nov 2011 11:44:31 +0100

Juergen,
> keywords and then make up their own story I think we can't help.
Ok, I give up. Fine with your text.

For a draft that is supposed to educate about IETF OPS, promote it, and 
at the end ease our OPS lives (*), not sure why it became so sensitive....

(*) For example, this draft was mentioned as a potential solution for  
the "Next Generation Mobile Networks (NGMN) requirements on Next 
Generation Converged Operations Requirements (NGCOR)" liaison 
presentation during the last IETF opsarea meeting.

Busy now improving the FCAPS sections.

Regards, Benoit.

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Mon, 28 Nov 2011 15:45:42 +0100

Hi, 

One comment on Benoit's comment: 

 

From: [email-masked] [mailto:[email-masked]] On Behalf
Of Benoit Claise

[[DR]] I respectfully disagree with Benoit's comment. There is not claim
that 'we have mastered the IoT management', just an example of the way
the Entity MIB can be used and extended to represent information from
physical sensors, followed by another example about alarms. I would
rather leave them as written by Juergen. 

Dan

(speaking as contributor)