Subject: RE: O&M section in RTG documents?

From: "Susan Hares" <[email-masked]>
Date: Tue, 31 Aug 2004 18:38:32 -0400

I think this is a good idea.

Sue

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Tuesday, August 31, 2004 4:43 PM
To: [email-masked]; [email-masked]; [email-masked]
Subject: RE: O&M section in RTG documents?

Sounds like a good idea to me.

> -----Original Message-----
> From: ext Alex Zinin [mailto:[email-masked]]
> Sent: Monday, August 30, 2004 11:02 AM
> To: [email-masked]; [email-masked]
> Subject: O&M section in RTG documents?
> 
> 
> Folks-
> 
>  Two people--Loa and Adrian--have recently mentioned the idea 
> of requiring a
>  mandatory "Operations and Management Considerations" section 
> in the routing
>  area documents. Such section would explain management 
> considerations, such as
>  required changes to MIBs, as well as expected operational 
> impact and required
>  techniques/actions/additional protocols.
> 
>  Opinions appreciated.
>  
> -- 
> Alex
> http://www.psg.com/~zinin
> 
>

---

From: Kireeti Kompella <[email-masked]>
Date: Tue, 31 Aug 2004 15:52:45 -0700 (PDT)

> I think this is a good idea.

I'm generally in favor, but I will reserve judgment until I see a
"Guidelines for Writing an O&M Considerations Section" to assess the
value of this, and the burden it imposes.

If this goes forward, such a guideline is a MUST.  You can't have a
mandatory section and not have guidelines -- let's not repeat what
happened with Security Considerations: "This document does not
introduce any new security concerns."

The other thing is, for non-routing documents, an O&M section may
still be a good idea.  So, while this might be out of scope for the
rtg-dir, an optional O&M section for other docs should be vetted
IETF-wide.

Kireeti.
-------

---

From: Bill Fenner <[email-masked]>
Date: Tue, 31 Aug 2004 16:05:27 -0700

Kireeti says:
>I will reserve judgment until I see a

I think I agree here.  There's been a lot of confusion about what's
needed in security considerations, and even with RFC3552 it sometimes
seems to come down to "Write what you think it should say, then have
it on an IESG telechat to find out what the security ADs think it should
say".

I like the concept, especially if it improves followthrough on
addressing any problems that might be identified, but I am wary
of accomplishing anything just by adding a required section - the
work to fill it in won't just materialize and in some instances
we're having enough trouble just getting the protocol portion
done...

  Bill

---

From: Alex Zinin <[email-masked]>
Date: Tue, 31 Aug 2004 16:20:10 -0700

Makes sense.

So, in the spirit of IETF :), how about Loa and Adrian come up with an
individual draft, containing the guidelines for the O&M section. This
should give some meat for the discussion.

---

From: Loa Andersson <[email-masked]>
Date: Wed, 01 Sep 2004 08:38:37 +0200

All,

should have seen coming and ran for cover int time :).
Will discuss with Adrian.

/Loa

---

From: Jeffrey Haas <[email-masked]>
Date: Wed, 1 Sep 2004 09:06:56 -0400

> it on an IESG telechat to find out what the security ADs think it should

Having such a thing is, I think, a nice idea.  Just to make sure I'm
understanding the proposal, you're suggesting O&M not strictly as
"when you do your MIB, this is what should go in there" but also
a section on expected operational considerations in a live network?

Regarding the MIB portion, many protocol elements that should go into
MIBs are reasonably obvious although I understand that configurability
is still somewhat controversial.

What would be nice for MIB authors is a document that has recommendations
on how to go about representing various elements of protocol data
structurally in the MIB.  As a specific example, much of the lack of
progress on the BGP MIBv2 has been because I seem to continually stump
the IDR MIB doctors (two of them now) in trying to represent elements
in the BGP "routing table" (specifically the RIBs).

Also, a MIB author's FAQ on writing MIBs would be handy.  I've also
hit cases where I represent something that is "structurally sound"
in SMIv2 but it is suggested that I change things because "it looks weird".

Another item of concern that crosses both the operational and the SNMP
concerns for an O&M section is when one should put elements in a MIB
that aren't specifically related to the protocol.  I had received
a request from Tom Nadeau to take a last look at the l3vpn MIB since
there were interaction considerations with BGP.  While the l3vpn
MIB contained most of the protocol elements that I would want to
represent, it also contained "high water marks" and a pointer to
policy elements that weren't specifically part of the protocol.

Certainly these things are useful, but I'm not certain that they
belong as part of the MIB.  Thus, if we're going to write such a thing,
we should also suggest things that do NOT belong.

> we're having enough trouble just getting the protocol portion

I would tend to agree.  I still consider myself an amateur at writing
MIBs, but given some of my conversations with other people it sounds
like I almost should list MIBs as a "skill" in my rtg-dir profile.
This doesn't mean I'm qualified to say what's good or bad O&M practice
from a MIB doctor's point of view, but I can at least review them
from the level of protocol practice->MIB.

-- 
Jeff Haas 
NextHop Technologies

---

From: "Adrian Farrel" <[email-masked]>
Date: Wed, 1 Sep 2004 11:53:58 +0100

Tush!

I thought the idea for a draft came from Kireeti!

Loa and I will examine our process list and current CPU drain and see what we can achieve.

A
----- Original Message ----- 
From: "Loa Andersson" <[email-masked]>
To: "Alex Zinin" <[email-masked]>
Cc: "Bill Fenner" <[email-masked]>; <[email-masked]>; <[email-masked]>;
<[email-masked]>
Sent: Wednesday, September 01, 2004 7:38 AM
Subject: Re: O&M section in RTG documents?

---

From: "Adrian Farrel" <[email-masked]>
Date: Wed, 1 Sep 2004 15:27:26 +0100

Jeffrey,

> a section on expected operational considerations in a live network?

Absolutely.
Concerns include what you need to do to manage your proposals. For
modifications.extensions to existing work, this would clearly discuss the impact on
existing schemes.

While MIBs are an important aspect, I think the thing that has driven the comments from
both Loa and me is the fact that MPLS OAM (e.g. LSP liveness and correctness testing) has
been retro-fitted to the protocol architecture. Should have been thought about up front.

> in the BGP "routing table" (specifically the RIBs).

Agree with you, but I don't think this proposed draft is the same one as you are
proposing.

> we should also suggest things that do NOT belong.

There are essential, desirable, nice, useful and bad. Something external to the actual
protocol elements, but which is fundamental to the coherent operation of a network of
protocol elements may be considered not bad.

> from the level of protocol practice->MIB.

Oh good!
Can you take a look at the GMPLS MIBs? No-one else seems to want to ;-)

Adrian

---

From: Jeffrey Haas <[email-masked]>
Date: Wed, 1 Sep 2004 11:39:50 -0400

> Agree with you, but I don't think this proposed draft is the same one as you are

Excellent.  Does anyone have a suggestion as to the appropriate forum
to take up the MIB specific issues?

As for the OAM considerations, I think one of our biggest challenges
will be demarcing where operational elements goes from "bits on the
wire" to specific implementations.  The MPLS OAM (lsp-ping, etc.)
are good elements of OAM on the wire.  But...

> protocol elements may be considered not bad.

"not bad" may include things that aren't "on the wire".  To refer back
to my original example, the high water marks within the l3vpn MIB are
*very* useful, however they inherently suggest to an implementor that
these are protocol elements.

Should an implementation have these things?  If yes, then make sure
they're in the base specification or at least an OAM considerations
document for that protocol.

So, I think we're saying the same thing: Make sure that when things
have operational significance that they are included in the appropriate
place.  This may mean MIB objects or this may mean an OAM consideration.

I somewhat wonder if the applicability document may be the appropriate
place for this.

> Can you take a look at the GMPLS MIBs? No-one else seems to want to ;-)

Um. I really stuck my foot in that. :-)

Feel free to continue this part of the conversation off-line. 

-- 
Jeff Haas 
NextHop Technologies