Subject: Re: Help/guidance on L2TPv3 MIB draft

From: "Natale, Robert C (Bob)" <[email-masked]>
Date: Sun, 29 Sep 2002 15:46:45 -0400

At 8/19/2002:08:26 PM, Jed Lau <[email-masked]> wrote:

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: Andy Bierman <[email-masked]>
Date: Sun, 29 Sep 2002 13:17:59 -0700

>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

---

From: Andy Bierman <[email-masked]>
Date: Sun, 29 Sep 2002 15:25:05 -0700

At 05:33 PM 9/29/2002 -0400, Natale, Robert C (Bob) wrote:

>Hi Andy,
>
>I think you have missed the point of the
>discussion around AgentX at the time it
>was developed concerning MIB design.  There

I don't think it's a good idea to force a MIB designer
to use a table when a scalar is needed, just for the
sake of AgentX.  Why would multiple sub-agents need
to register for a scalar anyway?  Monolithic vs.
sub-agent design has nothing to do with whether or not
a MIB object is designed to have one instance or many instances.

Andy

>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
>> 
>> 
>> >>The first draft of the MIB is 
>> <draft-ietf-l2tpext-l2tpmib-base-00.txt>.
>> >We'd

---

From: "Natale, Robert C (Bob)" <[email-masked]>
Date: Mon, 30 Sep 2002 21:23:18 -0400

Ha!  That's what I love/hate about getting into discussions of
fundamental concepts on SNMP lists:  Before you know it, you're
into "criminal hacks".  Amazing.

Let me drop back to "thinking about MIBs 101":  The cases
in which a MIB *should* be designed from the perspective of
being instantiated by only a single agent entity on a managed
system (host:port) are a few special cases.  In the general
case, a MIB should *always* be designed from the perspective
of multiple instances being supported concurrently, by multiple
independent agent entities, on a managed system.  When you think
this through, you will come to the realization that it is
nearly axiomatic wrt design principles.  Extrapolating from
that axiom leads you to the realization that scalar objects
are as out-of-place in MIBs as non-normalized constructs are in
a relational database schema.  Avoiding the problem is trivial,
both in terms of identifying a logical approach and in terms
of implementation effort and runtime overhead.

The one thing Dave said below that I can agree with is that
this is not an AgentX issue (and hence I suggest that any
further follow up should go only to the [email-masked] list
...I've bcc'd the AgentX list to give everyone a chance to join
the mibs list).  AgentX provides the standardized extensible SNMP
agent framework that makes best use of multiply instantiable MIBs,
but readily supports the (degenerate) case of a MIB designed for
single instance use only (RFC2741, Sec. 4.2.1), as well as a range
of applications that span both models.

To sum it up, my basic assertion is:  MIBs designed to be
multiply instantiable are better designed MIBs in the general
case than MIBs that are designed to be singly instantiable.
That they also enable maximum benefit from AgentX is a freebie
by-product of their design.  However, there may be some special
cases where singly instantiable MIBs are not inappropriate.
Nonetheless, it is also axiomatic that a multiply instantiable
MIB can inherently support single instance configurations, while
the converse, in the general case, does not hold.

I can't wait to see what the level after "criminal hack" is! :-)

Cheers (sincerely...this is not a matter of life and death
for me),

BobN
- - - - -
> From: David T. Perkins [mailto:[email-masked]]
> Sent: Monday, September 30, 2002 6:05 PM
> To: Mark Ellison; Andy Bierman
> Cc: Margaret Wasserman; Juergen Schoenwaelder; [email-masked];
> [email-masked]; [email-masked]
> 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.
>  
> 
> At 04:24 PM 9/30/2002 -0400, Mark Ellison wrote:
> >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]
> >>
> >> 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
> >>
> >
> >[deletions]
> Regards,
> /david t. perkins
>