Subject: RE: subnets, VCs, and the IPOA MIB

From: [email-masked]
Date: Wed, 12 Nov 97 16:17:18 EST

Paul,
  Thanks for your reply.

>kennethw> ...  Paul, The
>kennethw> IPOA-MIB doesn't prevent VCs from being shared. Please
>kennethw> indicated where you think this limitation is implied in the
>kennethw> MIB.

>There were two things that triggered my concern; both may be cases of
>reading too much into the text.

>First one: LIS -- which is indexed by subnet -- has a count of active
>VCs (implying "active VCs for this subnet").  With shared VCs, the VC
>isn't "for a subnet".  So it's not clear what to do about that count.

>A node doesn't necessarily know in advance what subnets can use an
>SVC, so it doesn't help to say "count the VC once for each LIS it is
>used for".  For PVCs you can tell (from InARP messages) but for SVCs
>-- as far as I can tell from Classic2 -- the normal address resolution
>mechanism is ONLY ATMARP messages to the server, and those are sent
>only when you have traffic.  (There is a case mentioned where you send
>InARPs on an SVC, but only if you're doing revalidation of an ARP
>cache entry and the server doesn't answer.)  So the two endpoints of
>the SVC may have 3 LIS in common but not know about this, depending on
>what traffic is offered.

>It's not clear to me what purpose the LIS VC counter serves and I
>would rather see it go away.  Alternatively, it could be provided by
>implementations that have per-LIS VCs but omitted by those that use
>shared VCs.  The third possibility is to count the VC for each LIS for
>which you know that the VC can be used -- but in that case it becomes
>somewhat of a random number because the presence of traffic for a
>given LIS will affect whether the VC is counted for that LIS or not.

ipoaLisActiveVcs is the number of active SVCs per LIS. The entire
ipoaLisTable doesn't apply to PVCs. I recommend that ipoaLisActiveVcs
be incremented when either a SVC is being create or reused for
for traffic in a particular LIS. This object was useful in
one of our implementations is finding an error where we were
creating too many SVCs. If you feel that in your implementation
that this object has little value then you can always take
an exception in your agent capabilities statement and not implement it.

>Second one: I took the name "ipoaVcTable" to mean that the table
>describes VCs, and the fact that an IP address indexes the table rows
>then implies an assumption that a VC has associated with it one IP
>address.  In fact, that table doesn't describe VCs but rather ARP
>cache entries, which makes the issue go away.  (Would it be possible
>to rename it to make this more explicit?  I think customers would
>appreciate having object names be suggestive of the thing being
>reported.)

The description of the ipoaVcTable in the MIB is:

   "A system that support IP over ATM is an IP system and
   therefore must support all of the appropriate tables from
   RFC1213, MIB-II. This includes the ipNetToMediaTable (the ARP
   cache). This ipoaVcTable keeps a set of VCs for each entry in
   the ARP cache that was put there by this IP over ATM system
   acting as either a host or server. The ipoaVcTable doesn't
   augment the ipNetToMediaTable (ARP Cache) since the
   the correspondence between tables is not one-to-one."

My opinion is that most table names never imply enough description
to eliminate the need to examine the actual table description and
structure. I don't feel that the pain in changing the ipoaVcTable's
name at this point is worth the benefit.

Regards, Ken

---

From: Paul Koning <[email-masked]>
Date: Wed, 12 Nov 1997 16:38:43 -0500

Thanks Ken...

>>>>> "kennethw" == kennethw  <[email-masked]> writes:

 kennethw> ipoaLisActiveVcs is the number of active SVCs per LIS. The
 kennethw> entire ipoaLisTable doesn't apply to PVCs. I recommend that
 kennethw> ipoaLisActiveVcs be incremented when either a SVC is being
 kennethw> create or reused for for traffic in a particular LIS. This
 kennethw> object was useful in one of our implementations is finding
 kennethw> an error where we were creating too many SVCs. If you feel
 kennethw> that in your implementation that this object has little
 kennethw> value then you can always take an exception in your agent
 kennethw> capabilities statement and not implement it.

Ok, that's always a possibility.

Your explanation does trigger a general issue.  As Ken Virgile
mentioned (in a slightly different context) a few days ago, MIB
objects are for management, not for debugging.  If the justification
for an object is that it was useful to track down a coding error, my
conclusion would be that this explanation justifies its deletion.

Frankly, there are far too many MIB objects already, and many have no
valid reason for existing.  I would rather apply pressure to cut back
on the quantity of new objects being defined.

	paul