Subject: RE: Dso Groups (Was Re: Creating DS0s and DS0Bundles.)

From: Jason Perreault <[email-masked]>
Date: Fri, 6 Feb 1998 17:00:07 -0500

David,

In response to Gary's comments, I put together some text and
ASN.1 for the model I'm advocating; see attached file. Essentially,
it defines a ds0BundleIfTable that can represent DS0 allocation 
with a bitmap, and provides a ds0BundleIndex cross-reference
back into ds0BundleTable (e.g. for deleting a ds0Bundle interface
known only by its ifIndex; this table might be needed independent
of DS0 representation, to get the ifIndex -> bundleIndex mapping).
There are also a couple MIB-crafting changes that might be 
worth incorporating (defining an intermediate "Objects" node which
is the root for object definitions, and is a peer to the conformance
node).

I hope this proposal will attract responses from others on the list,
whether pro or con. Lacking support, I won't delay things further
with this issue.

I thank you and Gary for the feedback.

Jason

> -----Original Message-----
> From:	Dave Fowler [SMTP:[email-masked]]
> Sent:	Friday, February 06, 1998 3:37 PM
> To:	Jason Perreault
> Cc:	Gary Hanson; [email-masked]
> Subject:	Dso Groups (Was Re: Creating DS0s and DS0Bundles.)
> 
> Jason Perreault wrote:
> 
> > I propose a model where the DS0 and DS0Group interface types
> > are peers at the same layer. A DS0 interface has an integer
> attribute
> > that identifies its channel number; a DS0Group interface has a
> bitmask
> > attribute or enumerating table to expose the DS0s it encompasses.
> > 
> > Implementations are free to choose how fine- or coarse-grained a
> > representation to provide, according to what makes sense for the
> > functionality being offered and the degree of overhead the
> > implementation
> > is willing to incur, in terms of management representation. Those
> that
> > choose a coarse-grained approach shouldn't necessarily be branded
> > as nonconformant.
> > 
> > Would it be reasonable to define a third interface type (DS0Group)
> > which is distinguished from DS0Bundle in that it is directly stacked
> > on DS1, and represents DS0 allocation outside of ifStackTable? Or,
> > augment DS0Bundle to provide this flexibility?
> > 
> > Does anyone on the list have implementation experience with the
> > current stacking model? Pros and cons?
> 
> Jason,
> 
> I can certainly understand your concerns.  There is a fair number of
> entries in 
> the ifTable.  I'm not inclined to change things at this point because
> there already has
> been a working group last call on this document and it has been
> sitting
> in limbo
> waiting for the ifmib to get sorted out.
> 
> I think we are missing any significant implementation experience in
> this
> area.  We are only
> looking at making this document a proposed standard.  If
> implementation
> shows that we need
> to change things, we will.  My company has one product that uses these
> MIBs and the implementors didn't have any problems.
> 
> I am adding some things to make life easier.  The channlization flag
> and
> the channel to
> ifIndex mapping will be helpful for managers.
> 
> 
> Does that sound OK for now?
> Regards,
> David
>

---

From: David Fowler <[email-masked]>
Date: Wed, 11 Feb 1998 18:33:04 -0400

Jason,

Thanks for your contribution.  I think your idea is quite good, I do not
think that we should adopt it because:

I do not think implementers should have a choice in this bundle
representation issue as this makes it much more difficult for a manager
to support boxes from different vendors who chose different option.

The approaches are fundamentally different.  If we are going to go with your
proposal, then we should take away the requirement (or option if you prefer)
for representing individual ds0s that are in a bundle.  (and replace it with
the bitmap)

There was a desire to represent attributes of individual ds0s from the
members of the trunk mib group.  We shouldn't take that away as it is
useful.  (robbedBit and seized and idle codes). In addition, other MIBs have
already gone ahead (ISDN and Frame Relay Service). Therefore I think we need
to keep the document as it is.

Regards,
David

--
David Fowler
Newbridge Networks
613-591-3600

---

From: Fred Baker <[email-masked]>
Date: Wed, 11 Feb 1998 15:20:36 -0800

>whether pro or con. Lacking support, I won't delay things further

In my opinion, there has not been demonstrated a great deal of support for
your proposed change, and it gives me concern in several areas. As much as
anything, it seems that, while it has a demonstrable value for a certain
class of management application, it doesn't solve a problem that cannot be
solved with the existing approach. Given that the number of publicly
specified objetcs is lareay huge and proprietary MIBs are often as big or
bigger, specifying additional optional objects seems to be asking for
non-implementation; better to solve it with the objects already defined,
cache the result, and be done with it. And we are significantly past last
call on this; we are resolving a few minor issues raised by the IESG and
Network Management Directorate review (which was redone for some reason,
and surfaced additional comments), not doing significant new work.

I'd therefore like to give this a rest.

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
"The best way to predict the future is to create it"
	---Peter Drucker

---

From: Gary Hanson <[email-masked]>
Date: Fri, 13 Feb 1998 16:42:22 -0800 (PST)

Jason,

I have to say that I agree with Dave and Fred.  I'm not convinced
that there is sufficient reason for modifying the interface stacking
paradigm for ds0s and ds0Bundles, especially in expanding it to
include two alternate approaches (i.e., one with and one without
explicit ifTable entries for individual ds0s).

I would also be concerned about the instrumentation necessary to select
which approach should be used for stacking above individual ds1s.  I
was not convinced that your proposed set of MIB objects was adequate
to address the needs of systems that may need to support BOTH of the
stacking models for different ds1 interfaces, and I think that such
instrumentation would be a very necessary component of any expanded
paradigm that allowed two different approaches.

If the main goal of your proposal is to find an alternate way to
represent bundles of DS0s that would reduce the number of ifTable
entries, I would agree that such an approach may be better received
if we have some direct implementation experience that tells us that
we cannot live with the current approach which explicitly represents
the individual ds0s.

I am certain that the trunk-mib WG wants to get an initial version
of MIBs published for ds0s and ds0Bundles, so that we can truly start
gaining such implementation experience.  Perhaps we will find holes
more serious than the one you mention of "too many interfaces".  It
would then be appropriate to plug all of those holes at the same time,
should they start to appear.

Regards,
Gary