Subject: (FRNETMIB) FR SLA MIB - Issue 6 - Collection Location

From: "Rehbehn, Kenneth" <[email-masked]>
Date: Tue, 2 May 2000 16:27:39 -0400

> > 6) Why is the collection location distinction between
> > source/destination/intermediate so important?  How does the fact
> > that the
> > collection location is "source" versus "destination" versus
> > "intermediate"
> > change how the MIB is used or interpreted?  The actions seem the
> > same and
> > each unit has to use implementation-specific mechanisms to pull
> > together the
> > data from the two endpoints.  These should all be combined into a
> > single
> > value called "cooked" - because they all share the characteristic
> > that all
> > required data has been collected, correlated, and calculated.  This
> > is in
> > contrast the "distributed" model where only information from one end
> > is
> > available.  The distributed distinction should be divided into "raw
> > source"
> > and "raw destination".  This provides the management system with
> > clear
> > indication that the data needs to be combined with another sample
> > set.
> 
> Section 2.6 describes the importance of the collection locations.  In
> that two devices are needed to get the information, the management
> software needs to know where to go to get the appropriate data.

The management software needs a lot more than the vague "location"
information in the MIB today.  The current attributes of location in the MIB
are:

     source(1),       -- Calculations occur at the
                      -- source device.
     destination(2),  -- Calculations occur at the
                      -- destination device.
     intermediate(3), -- Calculations occur at some
                      -- intermediate device such as
                      -- a probe.
     distributed(4)   -- Calculations are distributed
                      -- between source and destination
                      -- devices.

What does the NM application do when the value is "destination"?  Where does
it go to get information?  Not only is there insufficient information to be
able to implement an NM application, but there is too much variety in how
that information might be pulled together.

Make this simple.  Associate the SLA MIB with the FRS MIB (see my comment on
Item 4) and you immediately have a definitive place for the management
software to go.  HOW the MIB is populated with data must be left as an
implementation-specific issue.

X-Info: To unsubscribe, email [email-masked]' with
X-Info: 'unsubscribe frnetmib' in the body of the message.