RE: Standards for IP stats collection? (corrected)

[neil.2.harrison@bt.com]

Bert....I can understand your earlier comment (wrt wanting limiting WG
coverage), but I can probably understand why Vishal wrote to several lists:
-	IP need its own perf management regime
-	MPLS ditto
-	GMPLS ditto....and there can be several layer networks involved
here, eg SDH (which has several distinct internal layer networks) and OTN.

This is unavoidable as each of the above create layer networks that must be
managed in their own right.  And to do a proper job its not simply QoS Perf
stats that are at issue for operators, its more like this:

1	user-plane and control-plane need their own OAM once dealing with CO
paths, eg GMPLS/MPLS-ER-LSPs, since one cannot assume user/control-plane
congruence of function or routing....so they are independent.  In the
user-plane one must have an initial clear view of defects (entry/exit
criteria) and their handling (ie correct consequent actions).  For an
operator this is an operational must-have.

2	After above, the next issue is availability.  This has to be defined
before QoS metrics/objectives can be considered.  Why?  QoS metrics are only
valid when a path is in the up-state, otherwise the QoS metrics have no
viable time-base and/or can get (statistically) distorted by events which
should be regarded as down-time ....so up/down-state transitions need to be
clearly identified next.  Note - this issue is not clear-cut for the IP
layer when dealing with destination-based hop-hop routing.  Indeed, there
are very difficult issues with failures mutating into QoS hits which I have
raised on the MPLS list before which make availability analysis of the IP
layer impossible (IMO) for the *network* (ie as subnetwork partitioned
allocations of a global reference connection) except on a true end-end
basis.

3	Now we can consider QoS.....but be careful.  It costs money to
measure/collect/process (in OSS) these....every technology I have been
involved with has started with a large metric wish-list that gets whittled
down to something more pragmatic later.  My advice is that these should be
of 2 types of QoS metric collection: (i) ad hoc 'sw-on' function for
trouble-shooting as needed by operational people, or the continuous
measurement of 'important' paths, and (ii) general network population
sampling (to get overall network trends and spot latent anomolous
behaviour).

4	policing/re-classification actions need monitoring.

5	nodal/link utilisations need monitoring and fed to a TE function and
the design/forecasting cycle.

So one needs a framework, where these pieces relate but where one piece does
not attempt to the job of all the others.

BTW - We (ie me/Shahram Davari/Ben Mack-Crane/Peter Willis) have just posted
an ID for MPLS user-plane which deals with 1 and 2 above.

neil


> -----Original Message-----
> From: Sambasiva R. Mantha [mailto:sambu.mantha@usa.alcatel.com]
> Sent: 02 March 2001 20:50
> To: terry martin
> Cc: ellanti@home.com; Bora Akyol; Vishal Sharma; 'te-wg@uu.net';
> 'mpls@uu.net'; ccamp@ops.ietf.org
> Subject: Re: Standards for IP stats collection? (corrected)
> 
> 
> I would like to correct a little bit regarding GR-253. The 
> GR-253 requires 8
> hours of 15-minute registers and 7 one-day registers and not 
> 3-5 days. This
> means that a SONET must have 33 15-minute registers (32 
> registers for previous 8
> hours and 1 for current 15 minutes) and 7 1-day (previous 
> day) registers.
> I would agree with Manohar that these PM registers are an 
> over-kill for LSPs as
> they really donot contribute anything to the traffic flowing 
> through the NE.
> 
> Sambu
> 
> 
> terry martin wrote:
> 
> > RMON is the only protocol standard that dictates 
> information collection
> > requirements.  That is the only IP service that is 
> structured to collect
> > trend stats.  I think it is also 15 minute intervals for 
> 3-5 days depending
> > on how much memory you get in the unit.
> >
> > There are structure requirements for collection, type of 
> traffic collected
> > and how it is presented.
> >
> > Need sources- let me know
> >
> > Terry Martin MS Telecommunication Engineering
> > Senior Consultant
> > tmartin@gvnw.com
> > 503-612-4422
> >
> > ----- Original Message -----
> > From: "Manohar Naidu Ellanti" <ellanti@home.com>
> > To: "Bora Akyol" <akyol@pluris.com>; "Vishal Sharma"
> > <vishal@JasmineNetworks.com>
> > Cc: "'te-wg@uu.net'" <te-wg@UU.NET>; "'mpls@uu.net'" <mpls@UU.NET>;
> > <ccamp@ops.ietf.org>
> > Sent: Thursday, March 01, 2001 9:14 PM
> > Subject: RE: Standards for IP stats collection? (corrected)
> >
> > > It will be interesting to see if there is a need for TDM 
> world operational
> > > features to be carried into MPLS world.
> > >
> > > I think the reason for 15 minutes etc PM counters for 
> things like Severely
> > > Errored Seconds etc was to deduce the quality of 
> transmission line and use
> > > this to feed into link cost. For instance realiability 
> metric could be
> > based
> > > on such information for the link.
> > >
> > > For LSPs does it really make sense ? to have TDM world operational
> > features.
> > > There is not even CRC or any header information to 
> determine if MPLS
> > packet
> > > was received correctly. It is more at lower layers. It 
> would be nice to
> > see
> > > some useful features carried forward and avoid 
> unnecessary requirements
> > from
> > > GR-XXX.
> > >
> > > -Manohar
> > >
> > >
> > > -----Original Message-----
> > > From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On 
> Behalf Of Bora
> > > Akyol
> > > Sent: Thursday, March 01, 2001 8:57 PM
> > > To: Vishal Sharma
> > > Cc: 'te-wg@uu.net'; 'mpls@uu.net'; 'ccamp@ops.ietf.org'
> > > Subject: Re: Standards for IP stats collection? (corrected)
> > >
> > >
> > > Vishal
> > >
> > > I don't think that there are such standards for routers. 
> I know that some
> > > routers store such data on flash cards for later 
> retrieval and some on
> > > hard disks.
> > >
> > > I would be curious to see how people are storing this 
> data and for how
> > > long?
> > >
> > > Bora
> > >
> > >
> > > On Thu, 1 Mar 2001, Vishal Sharma wrote:
> > >
> > > > Hello All,
> > > >
> > > > For the TDM world, GR-253 lays out strict standards for
> > > > the length of time that a carrier-class box should collect
> > > > and store statistics on-board, for retrieval later. The
> > > > number is something like 15-min intervals for 3 days.
> > > > The purpose supposedly is that if the connection to the EMS
> > > > dies, the box at least should allow the provider to recover
> > > > statistics data from it.
> > > >
> > > > My question is: what are similar standards (or existing
> > > > best practices) in the IP carrier community today? How much
> > > > statistics-related information do carriers like to have from
> > > > IP boxes?
> > > > What would carriers like to have?
> > > >
> > > > (The only reference I could find on this was Blain Christian's
> > > > draft
> > > >
> > >
> > 
> http://search.ietf.org/internet-drafts/draft-christian-tewg-me
asurement-00.t
> > > xt)
> > >
> > > Are there others?
> > > Do people (read carriers) have any thoughts or suggestions or
> > > pointers?
> > >
> > > Thanks,
> > >
> > > -Vishal
> > >
> >
> >