Subject: Re: [OPSAWG] (final) WGLCon draft-ietf-opsawg-operations-and-management

From: "David Harrington" <[email-masked]>
Date: Fri, 6 Mar 2009 16:33:24 -0500

Hi,

I have recieved quite a few responses to this round of the WGLC (thank
you to those who responded).

I think we need a consensus call on two main questions:
1) should we publish pre-re-organization and then do a bis, and
2) how should the document be (re-)organized?

The first question:
I was asked to author this document to provide guidelines as the IETF
moves away from the "write a MIB" approach to the "consider mgmt
needs, and then select or develop a new mgmt protocol and associated
data models." We are already long past the "write a MIB" stage, and we
have WGs in multiple IETF areas developing new mgmt protocols and new
non-MIB data models, and they are doing so with no guidance from the
OPS+MGMT area because this document is taking so long to get done.
Should we publish this with some of the updates and then immediately
start a bis that reorganizes the document?

The second question:

I have two MAJOR editorial changes requested.
1) "I can't tell the difference between operations and management
considerations; let's just combine them into one section", and
2) "the section on management is ambiguous. Sections like performance
management mix the management of the performance of the targeted
protocol with performance of the protocol doing the management. Can we
better separate these?"

The text in this document frequently mixes discussion of management
protocol issues with the management of protocol issues. 

Is "what should the data model contain?" really an operations
question, or is it a management question? 
Is section 3.3's bullet list of things to look for in a management
protocol really an operations considerastion, or is it a management
consideration?
Is "Interoperability needs to be considered on the syntactic level and
the semantic level." really an operational consideration? or is it a
management consdieration?
Is "The protocol designer should consider the impact on infrastructure
applications like DNS" really a management consideration? or is this
really an operational consideration?

I re-published the "survey" document. This was removed from the
ops+mgmt document because it made the document too large. I wanted to
remind the WG that we are planning to publish both documents, so we
should not need a survey (or even a mini-survey) of available
management protocols in the ops+mgmt doc. I have added a paragraph
saying "go look in the other document for available mgmt
technologies."

I would like some comsensus from the WG about which way forward is
preferred for these two questions.

dbh

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Juergen Schoenwaelder
> Sent: Tuesday, January 27, 2009 3:38 AM
> To: Scott O. Bradner
> Cc: [email-masked]
> Subject: Re: [OPSAWG] (final) WGLCon 
> draft-ietf-opsawg-operations-and-management
> 
> On Sun, Jan 25, 2009 at 11:40:13AM -0500, Scott O. Bradner wrote:
>  
> > This is a (hopefully final) WGLC for
> > draft-ietf-opsawg-operations-and-management there was not enough
> > respose to the last one back in October
> 
> My review of draft-ietf-opsawg-operations-and-management-05.txt:
> 
> I find this a difficult document to review and I like to state
clearly
> upfront that I very much appreciate the efforts spend on putting
this
> document together. The reason for starting with this diclaimer is
that
> I find it difficult to provide constructive comments in the form of
> concrete suggestions for changes. While reading, I observed the
> following:
> 
> - The document makes a distinction between "Operational
>   Considerations" (section 3) and "Management Considerations"
(section
>   4) and I am not sure where the difference really is. I appears
that
>   section 4 is much more management technology oriented and
organized
>   following the FCAPS model but in general, I do not really see why
>   some issues are operational considerations and others management
>   considerations. Perhaps the document can be streamlined by merging
>   these two sections together. (For example, 3.6 and 4.3.1 do in my
>   view pretty much belong together.)
> 
> - At times, the document reads like a collection of text fragments
>   taken from other documents without a very clear story line. I
>   sometimes had the feeling that things were not developing in a
>   "natural way" (but it is difficult for me to say what such a
>   "natural way" would look like without going through the whole
>   exercise to dissect the document into its fragments and
reassembling
>   the puzzle again).
> 
> - I am not sure the discussion what the "IETF Management Framework"
>   means (historically and today) is that useful for designers of new
>   protocols and it might raise controversial discussions. Why not
>   replace this material with a section that provide a high-level
>   summary of the management technologies that can be considered by
>   protocol designers? In terms of structure, this could mean that
the
>   document should have this structure (in terms of top-level
>   sections):
> 
>   1. Introduction
>   2. Available Management Technologies
>      (briefly mention SNMP, SYSLOG, RADIUS/DIAMETER, NETCONF, IPFIX,
>      CLIs, GUIs, ...  and outline where they are particularly strong
>      and where not; this should be short and not a long elaboration)
>   3. Operational and Management Considerations
>   4. Documentation Guidelines
>   .. ...
> 
>   This would lift some of the text currently in section 4 into
section
>   2. I also killed the current section 2 since the core of this is
>   already discussed in the introduction. As an alterntative, one
could
>   keep a section "Design for Operations and Management" but then
some
>   of the discussion currently in the introduction should be moved.
> 
> - The "Terminology" section explains why RFC 2119 language is not
used
>   and then defines the terms "new protocol" and "protocol
designers".
>   The document later has quite some text related to terminology
(e.g.
>   the discussion of information model vs. data model). One option to
>   consider is to move all text discussing or clarifying terminology
>   into this "Terminology" section (including the text fragments
>   pointing to RFC 3198 and RFC 3444).
> 
> Some editorial nits:
> 
> - Define the acronym CLI the first time it is used.
> 
> - Is "later/never phase" a typo or there by intention?
> 
> - I am not sure this sentence is correct:
> 
>     This document sets forth a list of subjective guidelines 
> and a list
>     of objective criteria by which a protocol designer can evaluate
>     whether the protocol that he/she has developed addresses common
>      operations and management needs. 
> 
>   I am actually not sure whether the distinction between "subjective
>   guidelines" and "objective criteria" is worth to have. What I
>   believe is valuable is the checklist phrased as a collection of
>   questions to consider.
>   
> - The first paragraph in 2.1 should in my opinion cite RFC 3410. But
>   as mentioned above, I am not a big fan of this discussion at all.
> 
> - s/algoithms/algorithms
> 
> - Some text on top of page 8 that looks scratch pad text.
> 
> - s/should there be/Should there be
> 
> - s/gyaranteed/guaranteed
> 
> - garbaled sentence
> 
>      or can the right
>      counters that can be polled as needed?
> 
> - s/desoigners/designer
> 
> - s/For example, Sometimes/For example, sometimes
> 
> - s/should they stop counting/Should they stop counting
> 
> - A.1: Make it clear that scalability in terms of operations and
>   management is meant, not in terms of the primary protocol
functions.
> 
>   OLD
> 
>   Does the solution scale well?
> 
>   NEW
> 
>   Does the solution scale well from the operational and management
>   perspective?
> 
> - A.1: Capitalize the sentences with the questions consistently.
> 
> - A.1: Add the following:
> 
>     Are there any coexistance issues?
> 
> - A.1: Add some more detailed questions for the items refering to
3.5,
>        3.6 and 4.1.
> 
> - Appendix A tries to make a distinction between Operational
>   Considerations and Management Considerations and I am not sure
this
>   is a clear cut line. Earlier, the document talks about a single
>   "Manageability Considerations" section. See also my more general
>   comments above.
> 
> /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/>
> _______________________________________________
> OPSAWG mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/opsawg
>

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Sun, 8 Mar 2009 16:08:56 +0100

Speaking as a contributor: 

1) Please ship ASAP for the reasons that you have described. 

2.1) I believe that the difference between operational impact and
manageability considerations is clearly stated in the document and that
the level of superposition between the two does not justify a
reorganization of the document and the related delays at this point in
time. 

2.2) I actually believe that section 4.6 makes quite clear that the
focus is on the management of the performance of the managed protocol.
The protocol that performs management is mentioned only in the context
of the data modeling limitations. If judged necessary one more phrase in
the first paragraph of 4.6 could clarify these. 

The rest of the comments seem to me valuable, but detail level, and none
of them a show stopper. 

See again 1). 

Regards,

Dan

> [mailto:[email-masked]] On Behalf Of David Harrington
> Sent: Friday, March 06, 2009 11:33 PM
> To: [email-masked]; 'Scott O. Bradner'
> Cc: [email-masked]
> Subject: Re: [OPSAWG] (final)WGLCon 
> I have recieved quite a few responses to this round of the 
> WGLC (thank you to those who responded).
> 
> I was asked to author this document to provide guidelines as 
> the IETF moves away from the "write a MIB" approach to the 
> "consider mgmt needs, and then select or develop a new mgmt 
> protocol and associated data models." We are already long 
> past the "write a MIB" stage, and we have WGs in multiple 
> IETF areas developing new mgmt protocols and new non-MIB data 
> models, and they are doing so with no guidance from the
> Should we publish this with some of the updates and then 
> immediately start a bis that reorganizes the document?
> 
> The second question:
> 
> 1) "I can't tell the difference between operations and 
> management considerations; let's just combine them into one 
> section", and
> 2) "the section on management is ambiguous. Sections like 
> performance management mix the management of the performance 
> of the targeted protocol with performance of the protocol 
> doing the management. Can we better separate these?"
> 
> The text in this document frequently mixes discussion of 
> management protocol issues with the management of protocol issues. 
> 
> Is section 3.3's bullet list of things to look for in a 
> management protocol really an operations considerastion, or 
> is it a management consideration?
> Is "Interoperability needs to be considered on the syntactic 
> level and the semantic level." really an operational 
> consideration? or is it a management consdieration?
> Is "The protocol designer should consider the impact on 
> infrastructure applications like DNS" really a management 
> consideration? or is this really an operational consideration?
> 
> remind the WG that we are planning to publish both documents, 
> so we should not need a survey (or even a mini-survey) of 
> available management protocols in the ops+mgmt doc. I have 
> added a paragraph saying "go look in the other document for 
> available mgmt technologies."
> 
> I would like some comsensus from the WG about which way 
> forward is preferred for these two questions.
> 
> dbh
>  
> 
> >     This document sets forth a list of subjective guidelines and a 
> > list

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 9 Mar 2009 09:27:31 +0100

> 1) Please ship ASAP for the reasons that you have described. 

I like to understand (a) what really pressures us to push this out
quickly and (b) what it will take time wise to rework this document
into a better shape.

How is this document been used once it has been published as RFC? Why
can't this usage not be achieved now already with an ID in place?

/js

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Mon, 9 Mar 2009 09:59:27 +0100

> From: Juergen Schoenwaelder 
> [mailto:[email-masked]] 
> Sent: Monday, March 09, 2009 10:28 AM
> To: Romascanu, Dan (Dan)
> Cc: David Harrington; Scott O. Bradner; [email-masked]
> Subject: Re: [OPSAWG] 
> (final)WGLCondraft-ietf-opsawg-operations-and-management
> 
> I like to understand (a) what really pressures us to push 
> this out quickly and (b) what it will take time wise to 
> rework this document into a better shape.
> 
> How is this document been used once it has been published as 
> RFC? Why can't this usage not be achieved now already with an 
> ID in place?
> 
> /js
> 
> -- 

Speaking as AD: 

>From the Abstract: 

>   The purpose of this document is to provide guidance to authors and
   reviewers of documents defining new protocols or protocol extensions,
   about covering aspects of operations and management that should be
   considered.

There is a difference between having a BCP as reference, and having an
I-D which is work-in-progress. 

Sealing as a contributor: 

I believe that that the document is in good enough shape to meet its
principal goals, and to be submitted by the WG to the IESG. 

Speaking as both: 

We already discussed this document in the WG for more than one year. I
hope that by sending it to the IESG and entering IETF Last Call we shall
generate a level of response from other areas in the IETF who are
'customers' and 'users' of this document. 

Dan

---

From: "Hannes Tschofenig" <[email-masked]>
Date: Mon, 9 Mar 2009 11:36:04 +0200

>RFC?

That's a question I had as well.

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Mon, 9 Mar 2009 11:03:59 +0100

Appendix A will be used in the future as a reference for the authors and
OPS-DIR reviewers. 

As I mentioned OPS-DIR I am copying them, in case they are not all
subscribed to opsawg. I apologize for the double posting. 

Dan

> From: Hannes Tschofenig [mailto:[email-masked]] 
> Sent: Monday, March 09, 2009 11:36 AM
> To: [email-masked]; Romascanu, Dan (Dan)
> Cc: [email-masked]
> Subject: RE: [OPSAWG](final)WGLCon 
> >How is this document been used once it has been published as RFC?
>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 9 Mar 2009 12:13:07 +0100

> 'customers' and 'users' of this document.

Discussed for more than one year, but not intensively as far as I
recall from the mailing list and the WG meetings I have attended. And
discussed without reaching a clear consensus what the scope, target,
and organization of this document should be as I read the WG last
reviews.

/js

---

From: "David Harrington" <[email-masked]>
Date: Mon, 9 Mar 2009 12:16:06 -0400

Hi,

Here is my take on the discussions of scope, target, and organization.
Juergen, you did not clearly identify what you meant by these terms,
so my answers are based on my interpretation of those terms.

***** Scope *****
The WG discussed not getting into the mire of trying to distinguish
services and networks and devices. Many SDOs have tried to do that,
with varying levels of success. We do not want to boil the ocean. A
later discussion in opsawg brought up the inconsistencies of what OAM
means; another work-in-progress addresses that discussion.

The IETF focuses on protocols, and the WG had the discussion that this
document should focus on protocols, not services. The charter also
defines the scope:
"(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"

If the chairs would like to codify the scope with a consensus call or
a declaration of scope, we can solve that issue.

***** Target *****
The target is IETF protocol developers. I was initially asked to write
such a document because the IESG was relaxing the "write a MIB"
requirement, and the IESG wanted something that gave guidelines to
protocol developers and reviewers about things that should be
considered for operating and managing new protocols (and extensions). 
The charter text above seems pretty clear what the target is.

***** Document Organization *****
When I first published this document, I mixed operations and
management together. But immediate feedback from people with
operations experience was that the document as written really was a
managment guidelines document, and said little about operations.
Operators seem to consider the two things to be different, while NM
protocol developers seem to see them as one thing. 

So, on advice from the operator community, and I believe based on
consensus of this WG, I separated out the issues and sought
contributions for the operations portion to build separate chapters.
And people did contribute, mostly in little snippets of operational
considerations. 

Unfortunately, I could not get solid advice about any overall approach
that let us organize the snippets into a story-line or anything,
because, as far as I have been able to determine from talking with
operators, every organization has their own "story-line" - their own
way of doing things. I suspect all we can really do is present these
snippets of information, and hope that subsequent feedback will
identify commonalities so we can develop a better storyline.

About the best I could see us providing for a storyline was some
discussion of the motivation for writing the document, and providing
some history of efforts to identify "requirements" for operations and
management. That is why I have a whole section discussing previous
efforts, starting with the decision to try to keep a separation
between data models and protocols and modeling languages, and
differentiating data models and information models, and repeated
attempts to identify common requirements for configuration, and
information models for things like policy-based management.

***** Document Status *****
I think the current document is very rough. I agree it has no
storyline like most good internet-drafts. I tried to organize the
snippets to provide some conceptual absractions of the storyline of
operating a network - installation, config, performance monitoring,
notifications, usage accounting. I welcome new text. I welcome
suggestions to move text from section to section. I welcome
suggestions to rename sections. But it is hard for me as editor to
reorganize the whole document without clear consensus that
operations+mgmt should be separated/mixed-together or that the whole
history/motivation section should be thrown out.

Some consensus determination would help me edit this document.
Some active discussion might motivate me to spend more time editing
this document to represent WG consensus. My previosu attempts to
stimulate discussion have generally led to me being emailed another
snippet or so, and no serious discussion of guidelines for things to
be considered about operating and managing new protocols.

***** Non-document Issues *****
I think that one of the issues that really needs some resolution, that
is not related to the editing function, is how the ADs/IESG plan to
use such a document. If this is going to be used to require an
"Operations and Management Considerations" section in every document,
and to dictate what content must be in such a section, then the WG
probably wants to severely limit what goes into this document (if they
are willing to publish the document at all). If this document is
informational "guidelines", not requirements, then we can add more
(optional) guidelines for people to consider. 

dbh

> Sent: Monday, March 09, 2009 7:13 AM
> To: Romascanu, Dan (Dan)
> Subject: Re: 
> [OPSAWG](final)WGLCondraft-ietf-opsawg-operations-and-management
>

---

From: "David Harrington" <[email-masked]>
Date: Mon, 9 Mar 2009 15:02:53 -0400

Hi,

inline. 
I am responding to input because I am not sure how to convert reviews
like this into editing instructions.

> [mailto:[email-masked]] On Behalf Of Juergen Schoenwaelder
[...]
(section
that
organized
>   view pretty much belong together.)

They are obviously closely related. They are separated because
feedback from operators say there is a distinction. I notice that our
area is called the "operations and Management Area"; if they are the
same, why do we name the area this way?

Are specific snippets of text more one than the other, or equally so?
Yeah, possibly. If there is something under operations you think is
really only about management, please let me know and we will look at
moving it. But sometimes, how a protocol designer expects operators to
deploy management for their protocol is an operational consideration.
It cna be tough to separate the two related concepts.

reassembling
>   the puzzle again).

That is exactly what it is. I have had difficulty finding a storyline
in the many snippets contributions I have received, without getting
into debates about which "management architecture" or "operational
architectures" are reflected. One of the reasons this document is so
hard to edit is because there are few standard "architectures" for
operations and for management. This document hopefully will begin to
guide people toward some similar "best current practices", but "best"
is surely debatable if you try to craft a full storyline. 

the
>   document should have this structure (in terms of top-level

I think the "IETF Management Framework" section provides some
background and motivation for the guidelines. I can rename the section
Motivation and background if you prefer. Ultimately, I think it comes
down to "the IETF had a framework, but operators are not happy eith
it, so the the IETF has been considering how to change that framework.
In the absence of any real framework, these guidelines might help
produce protocols that can be added to operational environment without
major accident, and then can be managed effectively using a variety of
manageent protocols that conform to contradictory management
requirements."

I have commented out the section in the current sources, and I can
post an update with this section removed, if that is WG consensus. But
I think that the motivation and background for the guidelines will be
sorely lacking if we remove this section. The community has done lots
of work trying to determine best current practice for ops+mgmt, and
this section points people to those previous discussiosn so they don't
have to repeat those discussions all over again. Have some things
changed since those discussions? Of course. But we will never finish
if we just keep discussing requirements for almost-the-same wheels
over and over and over. Let's point out what has already been
discussed, and try to keep things moving forward.

The WG consensus was to move the discussion of available management
technologies into a separate document from the guidelines.

section
could
some
used
designers".
(e.g.
>   pointing to RFC 3198 and RFC 3444).

Information and Data models seem to be very management-oriented to me.
I do not view these typically as exercises undertaken by operators
operating networks, but by engineers providing support for management.
So, in my opinion, this discussion belongs under "management
considerations", not operational considerations.

> - Define the acronym CLI the first time it is used.

done.

> - Is "later/never phase" a typo or there by intention?

fixed.

>   believe is valuable is the checklist phrased as a collection of

Yes. I have had a particular problem with the checklist. Because the
main text is all snippets, and there is no storyline or prioritization
of snippets, the checklist could easily end up being a repeat of all
the snippets.

>   as mentioned above, I am not a big fan of this discussion at all.

In my copy of the -05- revision, the first paragraph of 2.1 already
cites RFC3410.

> - s/algoithms/algorithms
fixed.

> - Some text on top of page 8 that looks scratch pad text.
I capitalized the first word in each sentence. I can put bullet
symbols in fron of each of these snippets, which related to the last
paragraph on page 7. Would that be more acceptable? I would merge them
into a paragraph, but they are making different points.

> - s/should there be/Should there be
fixed.
> - s/gyaranteed/guaranteed
fixed
>      counters that can be polled as needed?
fixed.
> - s/desoigners/designer
fixed.
> - s/For example, Sometimes/For example, sometimes
fixed.
> - s/should they stop counting/Should they stop counting
fixed.
functions.
>   Does the solution scale well from the operational and management
done.
> - A.1: Capitalize the sentences with the questions consistently.
I think I got them all.

>     Are there any coexistance issues?
done.
3.5,
>        3.6 and 4.1.

I could use some specific suggestions about which detailed questions
should appear in the checklist.

dbh

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Mon, 9 Mar 2009 20:23:26 +0100

> Sent: Monday, March 09, 2009 1:13 PM
> To: Romascanu, Dan (Dan)
> > hope that by sending it to the IESG and entering IETF Last Call we 
> > shall generate a level of response from other areas in the IETF who 
> > are 'customers' and 'users' of this document.
> 
> Discussed for more than one year, but not intensively as far 
> as I recall from the mailing list and the WG meetings I have 
> attended. And discussed without reaching a clear consensus 
> what the scope, target, and organization of this document 
> should be as I read the WG last reviews.
> 
> /js
> 

As a contributor my opinion is that the scope and the target is well
explained in the introductory section. The organization is certainly
debatable, but this is to a certain extent in the eye of the beholder,
and I do not have a clear feeling that further discussions in the WG
will help improve the document in a revolutionary manner. 

As an A-D I believe that the IETF needs this document yesterday.
Actually it was needed already three years ago. 

Dan

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 9 Mar 2009 21:22:31 +0100

> Actually it was needed already three years ago. 

To do what with it?

/js

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Tue, 10 Mar 2009 09:55:51 +0100

... to provide guidance to authors and
   reviewers of documents defining new protocols or protocol extensions,
   about covering aspects of operations and management that should be
   considered.

(as the document Abstract and the OPSAWG say)

Dan

> Sent: Monday, March 09, 2009 10:23 PM
> To: Romascanu, Dan (Dan)
> Subject: 
> Re:[OPSAWG](final)WGLCondraft-ietf-opsawg-operations-and-management
>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 10 Mar 2009 10:17:44 +0100

> (as the document Abstract and the OPSAWG say)

Probably the text in the abstract is a bit to abstract for me. I guess
I have to read the revised version David just posted as it might be
clearer than the version I reviewed in spelling out what the concrete
recommendations are for authors and reviewers.

/js

---

From: "tom.petch" <[email-masked]>
Date: Thu, 12 Mar 2009 16:49:47 +0100

David

Picking up on the question of Operations and Management,  I see a distinction
between these two which comes across most clearly in the IETF work that used to
be known as Sub-IP, where there is a distinct ITU-T flavour, doubtless not a
coincidence.  It seems possible that the operators you allude to are making the
same distinction.

I see a three way split.  Management is something static, it makes a change
which stays changed until changed again, usually via SNMP and SMI, but could be
by an equivalent functionality.

Control may achieve the same result but is dynamic, by signalling, by routing,
by invoking protection and such like.

Operations, often referred to as OAM, which may stand for Operations,
Administration and Maintenance is functionality in the data plane to verify its
correct operation - ping, traceroute and such like (as in
draft-vigoureux-mpls-tp-oam-requirements ).  On this basis, you can and probably
should have some OAM built into your control protocols <and> your management
protocols (eg as OSPF has, but SNMP has not)

And this last is usually configurable by the first and must operate
independently of the first.

So for me, a good protocol will have this last built into its semantics and
state machine, so that when things go wrong, that shows.  And for me, this last
is more important than the first even though the first encompasses more; usually
full FCAPS, with a data model, a protocol to access the data model and with the
ability to make changes where this is not inherent in the data model (perhaps
the ability to fire off a traceroute and get back the results).  SNMP takes the
view that everything is part of the data model, but other management systems do
not, and have separate protocol elements to cause actions and if you are moving
on from SNMP, then you should allow for that.

Tom Petch

----- Original Message -----
From: "David Harrington" <[email-masked]>
To: <[email-masked]>; "'Romascanu, Dan (Dan)'"
<[email-masked]>
Cc: <[email-masked]>
Sent: Monday, March 09, 2009 5:16 PM
Subject: Re: [OPSAWG](final)WGLCondraft-ietf-opsawg-operations-and-management

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 12 Mar 2009 23:06:58 +0100

On Thu, Mar 12, 2009 at 04:49:47PM +0100, tom.petch wrote:

> Operations, often referred to as OAM, which may stand for
> Operations, Administration and Maintenance is functionality in the
> data plane to verify its correct operation - ping, traceroute and
> such like (as in draft-vigoureux-mpls-tp-oam-requirements ).  On
> this basis, you can and probably should have some OAM built into
> your control protocols <and> your management protocols (eg as OSPF
> has, but SNMP has not)

I do not understand the last sentence or the whole paragraph. It is
not clear which OAM functions OSPF has and that are missing in SNMP,
given your definition of OAM as "functionality in a X plane protocol
to verify its correct operation".

/js

---

From: "tom.petch" <[email-masked]>
Date: Fri, 13 Mar 2009 11:19:52 +0100

---- Original Message -----
From: "Juergen Schoenwaelder" <[email-masked]>
To: "tom.petch" <[email-masked]>
Cc: <[email-masked]>
Sent: Thursday, March 12, 2009 11:06 PM
Subject: Re: [OPSAWG](final)WGLCondraft-ietf-opsawg-operations-and-management

> to verify its correct operation".

OSPF, in the routing/signalling plane, has a keepalive mechanism built in, which
IMO is comparable to role of ping for IP.  And in its use of multicast for DR
and BDR and the acknowledgements from other routers thereto it cleverly ensures
that everyone knows what is still alive.

SNMP the protocol, in the management plane, has no such functionality.  When a
crisis blows up and a Notification must be sent, only then does the engine find
that the network went down some hours ago and nothing can get through.  The onus
is on the SNMP application, which I am not counting here as part of SNMP, to
ensure what it needs to ensure, eg by polling some harmless object in the system
group every so many seconds.

Different protocols, different approaches.

In-band OAM I see at its richest in the 'sub-IP' protocols, GMPLS for example.

Tom Petch

---

From: "Natale, Bob" <[email-masked]>
Date: Fri, 13 Mar 2009 11:39:15 -0400

Tom's note prompts me to ask whether the Ops Area might want to consider the topic of OAM evolution and/or co-evolution with higher-order management protocols at some point in the future.  GMPLS and other CCAMP work would likely be central to such work.  At what point(s) and via what mechanisms do/should signaling/control plane protocols interact with management plane interfaces on the one hand and OAM in the data plane on the other?  How can the benefits (e.g., timeliness) and costs (e.g., how much OAM do you want in data streams, what happens when the in-band path is not accessible, etc.) be leveraged/offset by management plane protocols (and maybe we would need to include management applications as well)...?

Or are these non-questions (already adequately addressed in industry (and I'm too out-of-touch to know it)) or nonsensical ones or just not in scope for the Ops Area, etc.?

Cheers,
BobN

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of tom.petch
Sent: Friday, March 13, 2009 6:20 AM
To: Juergen Schoenwaelder
Cc: [email-masked]
Subject: Re: [OPSAWG] (final)WGLCondraft-ietf-opsawg-operations-and-management

---- Original Message -----
From: "Juergen Schoenwaelder" <[email-masked]>
To: "tom.petch" <[email-masked]>
Cc: <[email-masked]>
Sent: Thursday, March 12, 2009 11:06 PM
Subject: Re: [OPSAWG](final)WGLCondraft-ietf-opsawg-operations-and-management

Tom Petch

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Sun, 15 Mar 2009 14:21:00 +0100

Bob,

These are generic questions that can be debated extensively. Do you have
a concrete proposal for IETF work that is missing and that should /
could be done in the OPS Area? The OPS Area is us, so ....

Regards,

Dan

> [mailto:[email-masked]] On Behalf Of Natale, Bob
> Sent: Friday, March 13, 2009 5:39 PM
> To: [email-masked]
> Subject: [OPSAWG] In-band OAM
> 
> Tom's note prompts me to ask whether the Ops Area might want 
> to consider the topic of OAM evolution and/or co-evolution 
> with higher-order management protocols at some point in the 
> future.  GMPLS and other CCAMP work would likely be central 
> to such work.  At what point(s) and via what mechanisms 
> do/should signaling/control plane protocols interact with 
> management plane interfaces on the one hand and OAM in the 
> data plane on the other?  How can the benefits (e.g., 
> timeliness) and costs (e.g., how much OAM do you want in data 
> streams, what happens when the in-band path is not 
> accessible, etc.) be leveraged/offset by management plane 
> protocols (and maybe we would need to include management 
> applications as well)...?
> 
> Or are these non-questions (already adequately addressed in 
> industry (and I'm too out-of-touch to know it)) or 
> nonsensical ones or just not in scope for the Ops Area, etc.?
> 
> Cheers,
> BobN
> 
> [mailto:[email-masked]] On Behalf Of tom.petch
> OSPF, in the routing/signalling plane, has a keepalive 
> mechanism built in, which IMO is comparable to role of ping 
> for IP.  And in its use of multicast for DR and BDR and the 
> acknowledgements from other routers thereto it cleverly 
> ensures that everyone knows what is still alive.
> 
> SNMP the protocol, in the management plane, has no such 
> functionality.  When a crisis blows up and a Notification 
> must be sent, only then does the engine find that the network 
> went down some hours ago and nothing can get through.  The 
> onus is on the SNMP application, which I am not counting here 
> as part of SNMP, to ensure what it needs to ensure, eg by 
> polling some harmless object in the system group every so 
> many seconds.
>

---

From: "tom.petch" <[email-masked]>
Date: Tue, 17 Mar 2009 09:19:10 +0100

----- Original Message -----
From: "Natale, Bob" <[email-masked]>
To: <[email-masked]>
Sent: Friday, March 13, 2009 4:39 PM
Subject: [OPSAWG] In-band OAM

> Tom's note prompts me to ask whether the Ops Area might want to consider the
topic of OAM evolution and/or co-evolution with higher-order management
protocols at some point in the future.  GMPLS and other CCAMP work would likely
be central to such work.  At what point(s) and via what mechanisms do/should
signaling/control plane protocols interact with management plane interfaces on
the one hand and OAM in the data plane on the other?  How can the benefits
(e.g., timeliness) and costs (e.g., how much OAM do you want in data streams,
what happens when the in-band path is not accessible, etc.) be leveraged/offset
by management plane protocols (and maybe we would need to include management
applications as well)...?

Currently this is a hot topic, taking up a lot of bandwidth, on the mpls-tp
list, which is at the stage of specifying - separately - the overall
requirements and those for management, OAM etc.

Tom Petch

> Or are these non-questions (already adequately addressed in industry (and I'm
too out-of-touch to know it)) or nonsensical ones or just not in scope for the
Ops Area, etc.?

---

From: Phil Shafer <[email-masked]>
Date: Tue, 17 Mar 2009 10:46:01 -0400

>requirements and those for management, OAM etc.

Would it be good to have these folks read
draft-ietf-opsawg-operations-and-management and see if it helps
them see what needs addressed?  Seems like a great place to get
feedback.

Thanks,
 Phil

---

From: "Natale, Bob" <[email-masked]>
Date: Tue, 17 Mar 2009 11:32:41 -0400

Yes, Phil's suggestion would be very helpful.

To answer Dan's response to my original posting: No, I don't have a formal proposal -- I asked some questions because I really don't know what course of action should be taken.

I am aware of long-term development projects that need to be able to manage the emerging control plane behaviors via management plane applications (sometimes via or in coordination with signaling plane mechanisms).  I would like to be able to address those needs via IETF standard mechanisms, where possible, to the extent appropriate.

I personally would like to see the OpsArea play a more active/leading role -- it seems like the signaling/control plane work is out-pacing management plane developments -- but I am not up-to-date on or actively engaged in the distribution of work across the IESG Areas (and probably unable to contribute anything helpful in that respect in any case).

Cheers,
BobN

-----Original Message-----
From: Phil Shafer [mailto:[email-masked]] 
Sent: Tuesday, March 17, 2009 10:46 AM
To: tom.petch
Cc: Natale, Bob; [email-masked]
Subject: Re: [OPSAWG] In-band OAM 

Thanks,
 Phil

---

From: "tom.petch" <[email-masked]>
Date: Wed, 18 Mar 2009 10:09:25 +0100

----- Original Message -----
From: "Phil Shafer" <[email-masked]>
To: "tom.petch" <[email-masked]> <[email-masked]>
Sent: Tuesday, March 17, 2009 3:46 PM

> them see what needs addressed?  Seems like a great place to get

In a sense, we have already done this.  Adrian Farrel, who has been very active
in the nexus of WGs - mpls, gmpls, mpls-tp, pce, pwe3 - where OAM is prevalent,
and especially active w.r.t operations, security, management etc commented on
this I-D last month.

And my comments, which dbh thought appropriate to a different I-D, were driven
by what I see, in mpls-tp in particular.  I think it would have been helpful to
have had something earlier to point to as what the IETF thinks, as an
alternative to the ideas originating in ITU-T Recommendations.

Tom Petch

---

From: "David Harrington" <[email-masked]>
Date: Wed, 18 Mar 2009 11:00:13 -0400

Hi,

I don't want to get into a debate about what OAM means. As Ron and Dan
pointed out in Dublin or Minneapolis, the meaning of OAM differs
across standards development organizations. This has become more
obvious as the IETF has dropped the "write a MIB" approach, MPLS and
related virtual wires WGs started defining requirements for "OAM", and
the IETF started working with ITU-T to reach consensus about MPLS-TP
OAM standards. The result is that people involved in that work,
including IAB members, are planning to author a document to discuss
what OAM means, to describe the different approaches, and I think to
identify which aspects were appropriate to IETF work. I think this is
the document Tom wants to see. I absolutely agree that would be a
useful document to help define what the new "IETF Management
Framework" or "IETF Operations and Management Framework" should be
going forward.

Most IETF network management protocols defined in the OPS area follow
the IETF Management Framework as originally defined in RFC1052, which
treated Internet management as a collection of standardized data
objects (THE MIB), accessed using protocols that were separate from
the protocols being managed (expected to be SNMP for the short-term,
migrating to CMIP for the long term). OAM in other SDOs often build
management into the protocols to be managed. That is a very different
approach than the IETF Standard Management Framework in use since
RFC1052.

The guidelines document is really a guide to writing an "Operations
and Management" section in IETF documents, as an alternative to
continuing the simplistic "write a MIB" approach. Part of the goal is
to "standardize" what should be considered, as other BCPs have
standardized the Security Considerations section and the IANA
Consideration section. Part of the goal is to "standardize" what
should be considered in an expert review to prevent surprises late in
the approval process, much as RFC4181 does. MIB Doctor reviews used to
vary a lot depending on which Doctor did the review; RFC4181 now tells
authors what to expect from reviews, to a degree constrains Doctors
from raising pet peeves, and makes it easier to gain agreement between
authors and reviewers so expert reviews go easier and faster. This
guidelines document should do the same, allowing for different
protocols and data models best suited to the needs of operations and
management of the targeted protocol.

My interpretation of the consensus of the WG is that we should NOT get
involved in the debate about different meanings of OAM; we should
focus on guidelines that follow the existing conceptual IETF
Management Framework, but expand the options to include different
protocols, such as Netconf and syslog and CLI, and different data
modeling languages, such as XML Schema and Netmod and English-language
information models. If the IETF reaches consensus on a new IETF
Management Framework, then this guidelines BCP can be updated.

If it would make people feel more comfortable, we can change the title
to "Guidelines to Authors and Reviewers for Considerations of
Management and Operations of New Protocols and Protocol Extensions" -
although I think there might be a limit to how long a title can be,
and this might exceed the limit. 

dbh

> Sent: Wednesday, March 18, 2009 5:09 AM
> To: Phil Shafer