Subject: RE: Help/guidance on L2TPv3 MIB draft

From: "Natale, Robert C (Bob)" <[email-masked]>
Date: Sun, 29 Sep 2002 17:33:54 -0400

Hi Andy,

I think you have missed the point of the
discussion around AgentX at the time it
was developed concerning MIB design.  There
are some MIB design approaches that are
preferable for (open standard) extensible
agent implementation in general.  Enabling
multi-sub-agent support of sub-agent-specific
configuration (or similar) attributes --
normally represented as scalar objects in
monolithic agent designs -- via the tabular
approach that you seem to consider "more
complicated" (?) is one of those straight-
forward (my assertion) approaches.  Our hope
was to promote such MIB design choices going
forward.  Improving MIB designs along these
lines *might* become more important if the
SNMP community decides to extend the scope
of MIB functionality as part of an attempt
to rejuvenate SNMP[v3] as the management
protocol of choice in ever-wider arenas.

As per its original design intent -- and
the Applicability statements in section 4.2
of RFC2741 -- AgentX can certainly support
MIB designs that implement a monolithic
agent approach to scalar objects...in which
case a single-sub-agent handles such objects
(which might or might not be a limitation
for any given application...and wouldn't be
for any MIB that is expected to be implemented
only by a single sub-agent with a given
master agent scope).

Cheers,

BobN
- - - - -
> -----Original Message-----
> From: Andy Bierman [mailto:[email-masked]]
> Sent: Sunday, September 29, 2002 4:18 PM
> To: Natale, Robert C (Bob)
> Cc: Jed Lau; [email-masked]; [email-masked]
> Subject: Re: Help/guidance on L2TPv3 MIB draft
> 
> 
> At 03:46 PM 9/29/2002 -0400, Natale, Robert C (Bob) wrote:
> >At 8/19/2002:08:26 PM, Jed Lau <[email-masked]> wrote:
> 
> I have a strong objection to this suggestion to change
> a MIB design solely to make AgentX implementations easier.
> When AgentX was chartered, there was an understanding that 
> sub-agents would be transparent to NMS applications (command 
> generators).  Asking MIB writers to use a more complicated
> design is a hack. It makes the MIB more complicated
> for everybody, for the sake of a corner case. That's not
> good engineering.
> 
> Andy
> 
> 
> 
> >Hi Jed,
> >
> >Please review this MIB for compatibility with the
> >IETF standard SNMP agent extensibility protocol,
> >AgentX (RFC2741...and RFC2742 can also give you
> >some additional insight into AgentX operations).
> >
> >The fundamental issue is that scalar objects are
> >potentially problematic for AgentX. They should be
> >avoided by putting them into a table indexed by
> >some form of "AgentEntityID" object (an exercise
> >left to the implementer for now :-().
> >
> >Note that the issue of AgentX compatibility for
> >MIB writers will be addressed in a forthcoming
> >Internet Draft that I will submit...perhaps with
> >an extended applicability statement for AgentX
> >(Sections 4.2, 4.3, and 4.4 of RFC2741 do a good
> >job of the basics already)...for consideration by
> >the relevant IETF WGs. My hope is that consideration
> >of this Draft will lead to adding a statement or two
> >to the standard "SNMP Framework" boilerplate to
> >document these requirements for MIB writers.
> >
> >Guidance from Bert re where to discuss this
> >issue -- AgentX compatibility guidelines for
> >SNMP MIBs -- will be appreciated. (The AgentX
> >e-mail list is still operative, but the WG is
> >closed pending further work when its time to
> >move to Full Standard status.)
> >
> >Cheers,
> >
> >BobN
> >- - - - -
> >>Hi,
> >>
> >>I am one of three co-authors of the L2TPv3 MIB draft. I 
> attended the IETF
> >in
> >>Yokohama in July, and I got this e-mail address during one of the
> >plenaries. I
> >>understand that somebody behind this e-mail address might be able to
> >provide us
> >>with some guidance in developing our MIB.
> >>
> >>The first draft of the MIB is 
> <draft-ietf-l2tpext-l2tpmib-base-00.txt>.
> >We'd
> >>like to get some feedback regarding our organization of the 
> MIB tables. The
> >>L2TPv3 (Layer Two Tunneling Protocol, Version 3) MIB 
> borrows a lot from its
> >>predecessor, <draft-ietf-l2tpext-l2tp-mib-04.txt>. However, 
> it introduces a
> >>new framework that, we hope, allows us to better modularize 
> the various
> >>components of the tunneling protocol (e.g. pseudowire, 
> payload, transport,
> >>etc.). The intention is to allow future enhancements to the 
> protocol (e.g.
> >>additions to the list of supported payloads or transport 
> types) to occur in
> >>scalable and modular manner.
> >>
> >>I intend to go into further details and ask some specific 
> questions in a
> >>subsequent e-mail. Should I send follow-up e-mails to this 
> address, or
> >should
> >>I interface with a specific individual?
> >>
> >>Thanks in advance.
> >>
> >>Jed Lau 
>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 30 Sep 2002 14:05:37 +0200

>>>>> Natale, Robert C (Bob) writes:

Bob> I think you have missed the point of the discussion around AgentX
Bob> at the time it was developed concerning MIB design.  There are
Bob> some MIB design approaches that are preferable for (open
Bob> standard) extensible agent implementation in general.

[...]

I guess you two are not well communcating. My understanding is that
Bob talks about objects such as ifNumber which are problematic when
the counted ifEntry rows exist in different sub-agents. I do not think
Bob is talking about scalars in general, which is what Andy seem to
have in mind.

/js

-- 
Juergen Schoenwaelder    <http://www.informatik.uni-osnabrueck.de/schoenw/>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 30 Sep 2002 17:52:58 +0200

>>>>> Margaret Wasserman writes:

Margaret> I never understood the value of the "fooNumber" variables to
Margaret> begin with...

[...]

This is just an example. There are other variables that might have
similar implications from an AgentX perspective which are not so
obviously questionable or problematic.

Margaret> Why would it be more useful to present them as a table?
Margaret> And, how would you index such a table?

I guess Bob wants to have them indexed by something which relates to
the sub-agent relationship, which means that the sub-agent structure
would not be transparent for management applications.

<note>
  I am not arguing for Bob's or Andy's position. I am just trying
  to make the discussion more useful to us. And we really should
  agree on a single mailing list if this thread continues.
</note>

Margaret> Not just idle speculation -- I'm working on a MIB right now
Margaret> that (for historical reasons) will probably continue to have
Margaret> one of these irritating little buggers...

Historical reasons translates to STATUS deprecated or obsolete as far
as I am concerned...

/js

---

From: Mark Ellison <[email-masked]>
Date: Mon, 30 Sep 2002 13:55:25 -0400

Hi Margaret,

There is a trade off, with respect to subagents, when implementing AgentX
subagents.

Most of the problematic issues revolve around tables for which there are
"companion scalar attributes".  The most referenced example is ifNumber and
ifTable.

One of the goals for AgentX is to provide a means for horizontal slices
(rows) of tables to owned by different subagents.  So the problem becomes
which subagent knows the (accurate) value of ifNumber when several
subagents each own rows presented during a walk on the ifTable.

As an implemtor, the following are solutions I can think of.

(1) don't design MIB modules with "companion scalar attributes" like
ifNumber.  ifNumber is kind of an extreme example, as you have pointed out.

(2) use an "orchestrator subagent" that registers for the companion scalar
attributes that can return a correct value.  (Note that an orchestrator
subagent that registers the OID just above the table attributes (e.g.
ifEntry or ifTable) is necessary whenever a row can be created within the
table.)

(3) implement the "companion scalar attributes" in a non-default context
(This is essentially what happened with RFC 1493, the bridge MIB, which was
designed for a bridge, when a device implemented a single bridge).  In my
opinion, a non-starter.

Since this thread concerns review of a MIB module, it makes sense to
mention solution (1) above.

For monolithic agents, those that are not designed to be runtime
extensible, accommodating AgentX during MIB design looks like an
unnecessary change.

Regards,

Mark Ellison
Ellison Software Consulting, Inc.

Margaret Wasserman wrote:

> I never understood the value of the "fooNumber" variables to begin
> with...
>
> They are complex to maintain for a large, dynamic table (like a
> routing table).
>
> They don't reflect the number of entries that are actually
> visible to the manager, so a manager can't expect to see that
> number of entries in the table.
>
> And, for a large, dynamic table, the number of entries is likely to
> change in the time it takes to do enough get-nexts and/or get-bulks
> to download it.
>
> But, assuming that you believe that they have any use at all...
>
> Why would it be more useful to present them as a table?  And,
> how would you index such a table?
>
> Not just idle speculation -- I'm working on a MIB right now that (for
> historical reasons) will probably continue to have one of these
> irritating little buggers...
>
> Margaret

---

From: Andy Bierman <[email-masked]>
Date: Mon, 30 Sep 2002 11:37:47 -0700

>As an implemtor, the following are solutions I can think of.

Here is one more design approach:

(4) Allow for sub-agent to sub-agent queries.  E.g., the sub-agent that
    registers for ifNumber sends a request to every other sub-agent for 
    the number of rows in ifEntry owned by that sub-agent.  

Either this or (2) below are acceptable because they don't force 
MIB design changes. 

Andy

---

From: Mark Ellison <[email-masked]>
Date: Mon, 30 Sep 2002 16:24:58 -0400

Hi Andy,

Allowing for subagent to subagent queries would be predicated upon having
sufficient security in place.  Support for the SNMPv3 security has been proposed
as work items (see the "security credentials"  and "isAccessAllowed()" threads
on the agentx-email list).

Until there is an update to the AgentX protocol, this sort of orchestration must
occur "out of scope" or "out of band" to a standards compliant snmp agent.

I would suspect the subagent knowing about certain scalars would likely be part
of the same daemon or process as that responsible for spawning instance daemons,
so would probably already contain the instrumentation, or access to it the local
instrumentation's of the scalar without additional demands on the snmp agent.  I
think this true for both monolithic and run time extensible agents.

If the eos and sming working groups create changes to the operations and the
underlying PDU structure, then there is a definite need to make changes to
AgentX to support these new features  (One option would be to convert everything
per `on the wire' for compatibility with the current set of AgentX PDUs, but
this would be extremely inefficient).  So I think there'll be ample time to
discuss subagent to subagent requests as well.

In the meantime, pointing out issues to MIB designers is still a very good tool.

Regards,

Mark

Andy Bierman wrote:

> [deletions]

[deletions]

---

From: "David T. Perkins" <[email-masked]>
Date: Mon, 30 Sep 2002 15:04:42 -0700

HI,

I suggest that this is really a system problem, and not an agentX
or SNMP problem.  Its a system problem because a well designed system
that supports management should not require an agentX hack to add
support for another interface. So if I was the first developer to
add support for a new interface and there was not an system interface
to add in the support for management, I would add one to an open
source OS, and for closed source OSs, then I would work with the
vendor. Only after ALL other available options were exhausted would
I add an agentX hack.

Why do I call it a hack? It is because ideally all management information
should be available via all management interfaces to a system. That is,
there should be system calls to present info on a CLI, present via
a WEB server, and SNMP agent. As soon as you do a "quick and dirty"
job to circumvent the OS, then you find you need to provide it for
other management interfaces. The result being extra cost and lower
integrity than if the wholistic approach is taken. Note that there
are some vendors (such as MicroSoft) that make things difficult. But
for all others it is criminal to go the hack approach.

>> Either this or (2) below are acceptable because they don't force
Regards,
/david t. perkins