Subject: RE: Creating DS0s and DS0Bundles.

From: Jason Perreault <[email-masked]>
Date: Thu, 5 Feb 1998 19:13:22 -0500

Hi Gary,

I understand your explanation regarding ifStackTable, but 
the structure of ifStackTable reflects the lowest common
denominator for representing stacking of interfaces of any type.
The tight coupling of DS0Bundles, DS0s, and DS1s offers an
opportunity for much more economical representation, at the
(justifiable?) cost of impurity to the ifStackTable model.

Lets look at some numbers.

Suppose I have a channelized DS3 configured to have 
4 DS0Bundles of 6 DS0s each per DS1, for a total of
112 DS0Bundles. The layers would look like this:

    112    DS0Bundles
    672    DS0s
      28    DS1s
        1    DS3

This totals 813 ifTable entries, of which 672, or 83%, are DS0s;
and 1485 ifStackTable entries (including top-most and bottom-most
entries) of which 1344, or 91%, are pairings of DS0s with higher- 
and lower-layer interfaces.

Whew!

Compare this to an implementation that groups DS0s into higher-rate
interfaces (DS0Groups), but excludes DS0s from being individually 
represented as interfaces:

    112    DS0Groups
      28    DS1s
        1    DS3

totaling 141 interfaces and 253 stacking entries.

This difference illustrates the overhead for a scenario where the 
DS0Groups, but not the DS0s, are considered "interesting" as interfaces;
thus, the only motivation for representing DS0s as interfaces is to
conform 
to a model that mandates use of ifStackTable to represent DS0
allocation.

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?

Apologies if I'm overlooking issues regarding other technologies
such as Circuit Emulation, someone please set me straight.

Jason

PS Some minor comments to your response below, tagged JP>.

> -----Original Message-----
> From:	Gary Hanson [SMTP:[email-masked]]
> Sent:	Thursday, February 05, 1998 3:28 PM
> To:	Jason Perreault
> Cc:	[email-masked]
> Subject:	RE: Creating DS0s and DS0Bundles.
> 
> JP> <snip>
> 
> > > [JJP]  <I ask:>
> > > 
> > > Some implementations might choose to offer a coarser
> representation
> > > of interfaces on a channelized ds1. Should the MIB really insist
> that
> > > all ds0s
> > > on a channelized ds1 be represented as interfaces?
> 
> I think that that is the general idea.  If there really is an concrete
> aspect in which the interface is channelized, then populate it in the
> ifTable with an entry for each lower-speed interface.  If these
> channel
> interfaces are ignored by the manager application, at least the agent
> cannot be faulted for not presenting the truth.
> 
> JP> It's not that I don't want to tell the truth; I just want to
> JP> phrase it more succinctly :-)
> 
> > > Is there such a thing as a channelized ds1 implementation that
> > > supports configurable bundles of one or more ds0s, but omits 
> > > representation of every ds0 as an interface? 
> 
> That is a good question.  If there is, it sounds like it would not be
> implemented in the spirit in which the DS0-MIB and DS0BUNDLE-MIB is
> heading.  That is either ok or not ok, depending upon whether support
> for it by a standard MIB is not wanted or is wanted.
> 
> > > Suppose a ds0Bundle is stacked directly over ds1, and a ds0Bundle
> > > table exposes the ds0 channel numbers associated with the bundle 
> > > (for example, an enumerating table indexed by
> > > <ds0Bundle_ifIndex>.<ds0_channel_number>,
> > > or more simply a bitmask object per ds0Bundle interface, if this
> is
> > > viable for the channel range).
> 
> That would be possible as a supplement to the ifStackTable.  However,
> it goes against the general intention of the ifStackTable in being the
> common place where ifEntry stacking of every imaginable complexity is
> shown (other than, of course, providing interfaces for individual
> VCs).
> 
> JP> I'm questioning whether DS0s need to be represented as 
> JP> interfaces in all circumstances, i.e. a thrust/payload argument.
> JP> IF-MIB, in discussing representing circuits as interfaces, 
> JP> recommends against doing so, but acknowledges there may
> JP> arise situations where it is useful. Can a similar argument
> JP> be made regarding DS0s? Sometimes it's practical to treat
> JP> them as interfaces; and sometimes it's not....
> 
> > > This eliminates much ifTable/ifStackTable clutter when ds0s are of
> > > little management interest other than knowing whether they are in 
> > > use, and how they are grouped. (In this approach, a bundle could 
> > > consist of a single ds0).
> 
> Ah, but here the clutter is informative, since it reveals the actual
> channelization that is in use....  
> 
> JP> Yes, but can the representation be made more compact?
> JP> Does the generalized use of ifStackTable warrant an ifEntry's
> JP> worth of information be maintained for every DS0, in all
> JP> circumstances?
>

---

From: Gary Hanson <[email-masked]>
Date: Thu, 5 Feb 1998 17:21:30 -0800 (PST)

Jason,

I see what you are saying about the uneconomical use of the ifTable
and ifStackTable resources in cases where individual DS0s are not
really being used.  I guess it really boils down to how expensive
it is on the agent and/or manager to have such large populations of
ifTable and ifStackTable entries.

For the single DS3 case that you cited, I imagine that some would say
that 813 ifTable entries and 1485 ifStackTable entries are TOO MUCH,
especially if the agent implementation actually creates separate data
structures for each ifTable entry, or if the manager's needs require
it to walk the tables frequently.  On the other hand, I also imagine
that others might say that this is only a use of virtual resources,
anyway.

At one extreme of this stance I could point out that an ifTable could
hold 2641431 of these DS3's, each with 813 ifTable entries, before
using up the 2^31-1 ifTable entries.  At the other extreme one may say
that even 141 ifTable entries and 253 ifStackTable entries is beyond
what they would ever like to see in their systems.  It's simply hard
to determine if we are stepping into that dangerous zone of TOO MANY
interfaces.

It's also hard to say whether the actual savings warrants introducing
a second way of creating DS0 bundles.  Numbers are interesting things.
You can argue that the compression of the ifTable is 813/141, or a
factor of about 5.77 to 1, or you can say it is a savings of 82.7%.
Same thing with the ifStackTable, which in your example is being
compressed by a factor of 5.87 to 1, which is a savings of 83.0%.
Is that enough savings?  I don't know.  I think it would depend.
(Actual savings may vary depending upon the number of bundles....)

What do others think about this?

It occurs to me that what you would like to see would be another
sort of variation on the old dsx1FracTable, in which the manager is
able to control the allocation of individual DS0s to groups/bundles
without there actually having to be ds0(81) entries for them.  In
addition, you would want some sort of control variable to cause the
channelization of the ds1(18) to occur in this fashion rather than
in the currently-proposed fashion of creating all possible ds0(81)
interfaces each time channelization is enabled.  You would also want
to have the agent be in charge of assigning ifIndex values for the
interfaces representing the bundles.

I would have no problem with this approach, other than to note that
it would be nice to not invent YET-ANOTHER ifType for the bundle.
If ds0Bundle(80) could be used for your purposes, it already exists.

Would you like to propose some set of control tables and objects for
the paradigm you are outlining?  I for one would be interested in
seeing it given a fair shake, in order to be sure that we can have
another approach up our sleeve in the event that we run into ifEntry
overpopulation.  It would be great if your proposed approach did not
conflict directly with the existing DS0-MIB and DS0BUNDLE-MIB approach.

(more comments included below....)

> > JP> phrase it more succinctly :-)

Good point.  I hope you knew no accusation was intended.  :-)

> > JP> them as interfaces; and sometimes it's not....

Sounds like you have made such an argument.

> > JP> worth of information be maintained for every DS0, in all

Maybe not, as you have noted.

I for one am likely to be off-line all of next week, so I don't expect
to reply on these trunk-mib WG threads until 2/16.

Regards,
Gary

---

From: Dave Fowler <[email-masked]>
Date: Fri, 06 Feb 1998 15:37:13 -0500

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

-- 
David Fowler                                   email:
[email-masked]
Newbridge Networks Corporation                 voice: (613) 599-3600 
ext.6559
600 March Rd, Kanata, Ontario, Canada K2K 2E6  fax:   (613) 599-3619