Subject: Re: [OPSAWG] Fwd: WGLC on draft-ietf-opsawg-management-stds-01

From: Juergen Schoenwaelder <[email-masked]>
Date: Sun, 9 Oct 2011 18:10:19 +0200

On Sun, Oct 09, 2011 at 02:31:49PM +0200, Benoit Claise wrote:
> Hi Juergen,
> 
> If you can find a few moments to give your feedback to this WGLC,
> this would be appreciated.
> This is a difficult draft as it requires broad knowledge of OPS,
> which you have ;-)

As stated before, I very much dislike section 4 - IETF data models are
not organized around FCAPS. I will not explain again why or make
another proposal how to fix this.

/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: Benoit Claise <[email-masked]>
Date: Mon, 10 Oct 2011 22:32:49 +0200

Juergen,

Thanks for your feedback.
While I understand your concern, I don't have a better classification in 
mind
When I meet some of my customers who are not that experienced in network 
management and who wants "to do network management" , this is still the 
most suitable question. What do you want to do mister customer: Fault, 
Configuration, Accounting, Performance, and Security. And from there, we 
can drill down into each area. Exactly like the appendix A is an 
overview, this document goal is to give pointers.

Regards, Benoit.

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 11 Oct 2011 06:39:20 +0200

On Mon, Oct 10, 2011 at 10:32:49PM +0200, Benoit Claise wrote:
> While I understand your concern, I don't have a better
> classification in mind
> When I meet some of my customers who are not that experienced in
> network management and who wants "to do network management" , this
> is still the most suitable question. What do you want to do mister
> customer: Fault, Configuration, Accounting, Performance, and
> Security. And from there, we can drill down into each area. Exactly
> like the appendix A is an overview, this document goal is to give
> pointers.

I thought the purpose of the document is to educate people what the
IETF has to offer and how the IETF organizes its data models. I fail
to see how pretending data models are organized around FCAPS while
this is de-facto not true can be a good approach if the goal is to
achieve better understanding. And I am not talking about appendix A.

/js

---

From: Benoit Claise <[email-masked]>
Date: Tue, 11 Oct 2011 10:53:13 +0200

Juergen,
> IETF has to offer
Yes
> and how the IETF organizes its data models.
Organized, not really. This document is a list of pointers.

    The purpose of this document is on the one hand to help system developers
    and users to select appropriate standard management protocols and
    data models to address relevant management needs.  On the other hand
    the document can be used as an overview and guideline by other
    Standard Development Organizations or bodies planning to use IETF
    management technologies and data models.

> I fail
> to see how pretending data models are organized around FCAPS
We certainly don't pretend that data models are organized around FCAPS 
at the IETF.
Here is an attempt to stress that point.
OLD:

    4. Network Management Data Models

    This section lists management data models standardized at IETF, which
    can be reused and applied to different management solutions.  The
    subsections below are structured following the management application
    view and focus mainly on the management data models for the network
    management tasks fault, configuration, accounting, performance, and
    security management.

NEW:

    4. Network Management Data Models

    This section lists management data models standardized at IETF, which
    can be reused and applied to different management solutions.  The
    subsections below are structured following the management application
    view and focus mainly on the management data models for the network
    management tasks fault, configuration, accounting, performance, and
    security (FCAPS) management. While the IETF does not logically organize
    data models around FCAPS, this classification was presented in this
    document to help the audience to review and select the appropriate data
    models based on his management needs.

Regards, Benoit.

> while

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 11 Oct 2011 11:35:19 +0200

On Tue, Oct 11, 2011 at 10:53:13AM +0200, Benoit Claise wrote:
> We certainly don't pretend that data models are organized around
> FCAPS at the IETF.

You don't get my point. I believe the whole section 4 needs to be
replaced.

The simple facts are that we have a few base abstractions that are key
to understand (e.g. interfaces and interface stacks; physical
entities) plus lots of interface type specific data models (usually in
the transmission branches) plus a bunch of protocol specific data
models (e.g. layers three routing protocols and layer four
protocols). While attempts were made to create more generic functions,
they only rarely have been successful. Most successful have been
monitoring data models. Writable configuration data models have been
successful only in a few cases, but tend to have higher changes of
success the lower they are in the protocol stack. The hope is that
NETCONF/YANG will have more success in the future but we need to wait
and see. Perhaps it is also necessary to mention that technology
specific data models can be happily be defined by other SDOs and that
in some cases the IETF even transferred stuff to other SDOs (e.g. in
the IEEE 802 case).

I think somethine along these lines is the news that needs to be
conveyed, backed up by pointers to prominent examples. If I look at
the current text, I read about the Meter MIB (which box on the market
implements that?), about the DISMAN-EXPRESSION-MIB (which vendors do
support that?), and I could probably name a few more candidates.

To sum up: I have a serious problem with the _whole_ section 4.

/js

---

From: "Ersue, Mehmet (NSN - DE/Munich)" <[email-masked]>
Date: Tue, 11 Oct 2011 13:03:56 +0200

Dear Juergen,

it is correct that IETF developed MIBs for different technologies,
interfaces and protocols. I believe, it is also correct that a huge
number of IETF data models can be used for the realization of network
management tasks like fault management.

The main audience of this particular document is the developers and SDOs
outside of IETF, which want to use IETF Network Management standards.
This specific audience does not know much about the IETF MIBs. They
rather think on Network Management from the application point of view
and have the management tasks like fault, configuration and performance
management in mind. With this management task view in mind they are not
interested in transmission or protocol related MIBs.

The current structure of the document aims to address this need and
categorizes the data models fitting the view of management tasks. I
reported in recent IETF meetings the positive feedback from SGIP and IEC
guys on the current document.

IOW the document is not for IETF insiders like us and IETF guys wouldn't
need such a document at all. I think we can easily find the appropriate
MIB for an issue in focus and others interested on different technology
MIBs can easily find them in the Internet (e.g. at
http://www.simpleweb.org/ietf/rfcs/rfcbytopic.php).

As discussed and noted in the Prague meeting it might be interesting to
have an overall list of MIBs as additional information in the draft, by
listing the technology related MIBs and other categories, not matching
to management tasks. For this we need your help as contributor.

Another option could be to write a supplementary Internet-Draft, which
aims to give an exhaustive overview of all IETF MIBs focusing also on
the technology and protocol related MIBs, as you described, if there is
sufficient interest.

For addressing the needs of the aimed audience and to achieve better
understanding I believe the current document structure is justifiable.

Cheers, 
Mehmet 

> -----Original Message-----
> From: ext Juergen Schoenwaelder
[mailto:[email-masked]]
> Sent: Tuesday, October 11, 2011 11:35 AM
> To: Benoit Claise
> Cc: [email-masked]; Ersue, Mehmet (NSN - DE/Munich)
> Subject: Re: [OPSAWG] Fwd: WGLC on
draft-ietf-opsawg-management-stds-01

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 11 Oct 2011 13:12:40 +0200

> interested in transmission or protocol related MIBs.

I believe we are better off telling people working in other SDOs what
the IETF has to provide instead of just making them read what they
like to read in the first place.

[...] 

> understanding I believe the current document structure is justifiable.

I do not agree - we simply waste time and energy if we do not manage
to convey how things are done in the IETF. We have 20+ years of data
models history and experience in the IETF. I have been involved for
about 15 years. There simply is no FCAPS structure in what is being
done in the IETF. And how can pointing to data models that are hardly
implemented be of any help?

/js

---

From: Benoit Claise <[email-masked]>
Date: Tue, 11 Oct 2011 14:47:31 +0200

Juergen,

[Dear all, please share your view on the usefulness of section 4.]
> protocols).
BC: But they're not key to understand for the audience (referring to the 
abstract for that) when the question is to able to compare the different 
characteristics of data models such as MIB modules, IPFIX Information 
Elements, SYSLOG Structured Data Elements, and YANG modules... with some 
examples.
This would be key to understand to explain the ifIndex, the interface 
stacks, etc... if this document would be MIB centric only.
> While attempts were made to create more generic functions,
> and see.

> Perhaps it is also necessary to mention that technology
BC: Agreed on the last point. This should be mentioned.
> implements that?),
BC: Btw, the Meter MIB has been identified has to be removed, as we 
removed RTFM in a previous version.
So the following paragraph will disappear.

    Traffic Flow Measurement: Meter MIB [RFC2720  <http://tools.ietf.org/html/rfc2720>] defines a MIB for use
    in the 'Traffic Flow Measurement: Architecture' [RFC2722  <http://tools.ietf.org/html/rfc2722>], in
    particular for specifying the flows to be measured and provides a
    mechanism for retrieving flow data from the meter using SNMP.

> about the DISMAN-EXPRESSION-MIB (which vendors do
> support that?),
BC: My company does, btw,
> and I could probably name a few more candidates.
>
BC:
Ideally what do you want to do from here?
1. remove the entire section 4?
Well, on one side, when the read the charter, it doesn't mention the 
data models

    (A) Development of a BCP document that will provide guidelines for
    authors and a reference for reviewers of IETF documents that specify
    new protocols or protocol extensions about the information about
    operational and manageability requirements that needs to be covered in
    these documents

However, if we don't cover the data models, then I question the 
usefulness of the document.

2. complete the section 4 with way more MIB modules. Some years ago, I 
discussed with Dave Harrington about producing a draft containing the 
most useful MIB modules at the IETF. Sound interested, but how to 
classify them? The only solution was to query all vendors and to rank 
the MIB modules accordingly. Obviously, this was a gigantic task... 
which never took off. And I don't want to do that.

3. change the section 4 structure, but as you mentioned "I will not  
make another proposal how to fix this"

Regards, Benoit.

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 11 Oct 2011 15:16:56 +0200

On Tue, Oct 11, 2011 at 02:47:31PM +0200, Benoit Claise wrote:

> 2. complete the section 4 with way more MIB modules. Some years ago,
> I discussed with Dave Harrington about producing a draft containing
> the most useful MIB modules at the IETF. Sound interested, but how
> to classify them? The only solution was to query all vendors and to
> rank the MIB modules accordingly. Obviously, this was a gigantic
> task... which never took off. And I don't want to do that.
> 

It seems I am expressing myself extremely badly. (And taking words out
of context does not really help either I think.) Lets simply hear other
opinions from people who have read section 4.

/js

PS: The charter axe does not really swing well because the quoted text
    dates back to at least 2007-06-13 while Mehmet's I-D first
    appeared on 2010-10-18, and Mehmet's I-D is on purpose very
    different from the quoted charter text. See also Mehmet's Beijing
    slides that subsequently lead to the WG adoption of this document.
    (As a matter of fact, adopted work items do not make it into the
    charter in the opsawg.)

---

From: "t.petch" <[email-masked]>
Date: Tue, 11 Oct 2011 16:27:56 +0200

---- Original Message -----
From: "Juergen Schoenwaelder" <[email-masked]>
To: "Benoit Claise" <[email-masked]>
Cc: <[email-masked]>
Sent: Tuesday, October 11, 2011 11:35 AM
> To sum up: I have a serious problem with the _whole_ section 4.

My concern is with all the other sections as well:-)  I do not believe that we
have the resources to do the subject justice, which is similar to a view that
Juergen expressed some time ago.

Juergen's suggestion of a narrower, more tightly-focused (and, I would say,
stand-alone) document, would make a lot more sense.

If we stay with the all encompassing approach, then I do think that FCAPS is
needed, since it is how other organisaitions approach the topic, even though we
do not.

And by including the MPLS/ITU-T definition of OAM, but excluding any of the
protocols which would be understood by those to come under that name, given the
current fiery debate about which way OAM for MPLS-TP should go, on the IETF and
MPLS lists, seems like tossing a hand grenade into a petrol tanker.

Uh huh, not very helpful:-(

Tom Petch
> _______________________________________________

---

From: "Randy Presuhn" <[email-masked]>
Date: Tue, 11 Oct 2011 11:05:38 -0700

Hi -

> To: "Ersue, Mehmet (NSN - DE/Munich)" <[email-masked]>
> Cc: <[email-masked]>
> Sent: Tuesday, October 11, 2011 4:12 AM
> Subject: Re: [OPSAWG] Fwd: WGLC on draft-ietf-opsawg-management-stds-01
...
> done in the IETF.  ...

Experience shows that FCAPS is pretty useless for purposes of
*structuring* models.  FCAPS can be helpful for sorting out application
requirements, but at the level of the models it might be better to consider
FCAPS as "aspects" - but that'd be a research topic, since the tools
we've given ourselves provide woefully inadequate support for aspect-
oriented model building.

If we mention FCAPS, we need to immediately note that this is a theory
that has had little effect on IETF model-building practice, and is not used
as an organizing priciple in our models.

Randy

---

From: "Ersue, Mehmet (NSN - DE/Munich)" <[email-masked]>
Date: Wed, 12 Oct 2011 17:43:09 +0200

Hi Tom,

> Juergen expressed some time ago.

We actually do have sufficient experts involved in the work described in
the document.
The document contributors are well-known names and active WG chairs at
the IETF.
 
> needed, since it is how other organizations approach the topic, even
though we
> do not.

This exactly is the issue we have and need to address. A document for
IETF guys 
is actually not needed. There are different web sites providing a
complete list 
of MIBs with different sort criteria. What we essentially need is a
document 
for people outside of IETF, giving an overview from their application
pov.
 
> MPLS lists, seems like tossing a hand grenade into a petrol tanker.

I have a different opinion on this. RFC 5586 uses this abbreviation the
same way.
Also draft-ietf-opsawg-mpls-tp-oam-def-10 states in section 3 that IETF
recommended 
the expansion of the OAM acronym as we did.
We actually did not discuss anything related to MPLS-TP OAM and the
debate with ITU-T. 
Can you please elaborate what exactly should be changed or you think
looks like a 
hand grenade ;) ?

Mehmet

---

From: "Ersue, Mehmet (NSN - DE/Munich)" <[email-masked]>
Date: Wed, 12 Oct 2011 17:54:31 +0200

Hi Randy,

> as an organizing priciple in our models.

We actually do not aim to build models or give them any structure.
The attempt is rather to give guidance to people outside of IETF, who 
try to match and use data models for their management applications.

You are right we should note explicitly that FCAPS is not used at IETF 
internally as an organizing principle in our models.

Mehmet

---

From: "t.petch" <[email-masked]>
Date: Thu, 13 Oct 2011 12:10:12 +0200

----- Original Message ----- 
From: "Ersue, Mehmet (NSN - DE/Munich)" <[email-masked]>
To: "ext t.petch" <[email-masked]>
Cc: <[email-masked]>; "Benoit Claise" <[email-masked]>
Sent: Wednesday, October 12, 2011 5:43 PM

Hi Tom,

<tp>

There is currently a lively debate on the main ietf list over 
draft-sprecher-mpls-tp-oam-considerations-01.txt
which reviews the current position whereby the IETF have
recommended one approach to OAM for MPLS-TP while the 
ITU-T are ratifying an incompatible one.

Proponents of the ITU-T approach, who have been involved in
the discussions all along, question the IETF processes by which
the IETF arrived at its conclusions, and have been doing so
for some years, implying, to me, that they do not think that 
their views got proper consideration.

Were this to go into IETF LC now, with its claim to cover
'existing and ongoing development of IETF standards-track
 network management protocols and data models'
without any mention of the MPLS-TP work with its 
contributions by ITU-T participants over the years, 
would seem to me likely to aggravate
the situation; as a hand grenade would in a petrol 
tanker:-)

Tom Petch
<tp>

Mehmet

---

From: "Ersue, Mehmet (NSN - DE/Munich)" <[email-masked]>
Date: Thu, 13 Oct 2011 14:12:20 +0200

Hi Tom,

after some discussion we decided to not include MPLS-TP OAM into this
document.
There is a note in the draft stating that the document does not cover
OAM 
technologies on the data-path, e.g. OAM of tunnels, MPLS-TP OAM,
Pseudowire, etc.  
and points to two active WG drafts (draft.ietf-opsawg-oam-overview and 
draft.ietf-mpls-tp-oam-framework), which cover it appropriately.

I think it is sufficient if we point to this work and by this avoid
carrying 
the ongoing difficult debate to our draft and its LC.

So, I would suggest to let the grenades where they are ([email-masked])
right now ;)

Cheers, 
Mehmet 

> From: ext t.petch [mailto:[email-masked]]
> Sent: Thursday, October 13, 2011 12:10 PM
> To: Ersue, Mehmet (NSN - DE/Munich)
> Cc: [email-masked]; Benoit Claise
> > protocols which would be understood by those to come under that
name,
> given the
> > current fiery debate about which way OAM for MPLS-TP should go, on
the
> IETF and

---

From: Benoit Claise <[email-masked]>
Date: Fri, 14 Oct 2011 13:09:39 +0200

Hi Randy,
> Hi -
>
>> From: "Juergen Schoenwaelder"<[email-masked]>
>> To: "Ersue, Mehmet (NSN - DE/Munich)"<[email-masked]>
>> Cc:<[email-masked]>
This was exactly my intention with this proposal, made some days ago to 
the mailing list.

OLD:

NEW:

Regards, Benoit.

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

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 17 Oct 2011 16:24:08 +0200

> internally as an organizing principle in our models.

Then you should also remove the sections that try to list data models
under FCAPS section titles. An example why this does not work well:
The perhaps most widely used MIB module is the IF-MIB. It currently
pops up under "4.2.  Configuration Management" (and only there). I
suggest to count the number of non-deprecated writable objects in
there. ;-) As far as I can tell, the IF-MIB is used heavily for
_monitoring_ - and interface _monitoring_ is used for fault mgmt,
accounting mgmt, performance mgmt, and perhaps even security mgmt.
With your structure, you would have to mention the IF-MIB in several
sections. This is an example, similiar arguments apply to other data
models listed in the current I-D.

/js

PS: Some interesting historic background can be found in this paper
    published 1989: <http://dx.doi.org/10.1109/49.44558>