The MPLS WG Archive

[Dave McDysan <dave.mcdysan@wcom.com>]

Neil,

I'll have to download Y.1711 and read it. (As pointed out in ccamp, you can
download 3 ITU recommendations per email address per year for free, and
since email addresses are easy to come by -- no one has the excuse that they
don't want to pay for ITU docs.)

I think that there may be similar concepts in IPPM (the framework doc claims
they are similar and admits to a different use of terminology). What may
help here is a mapping of terminology and concepts. For example, IPPM
connectivity when performed (using probes) over a set of important LSPs may
in fact be very similar to what others may call availability.

Dave

> -----Original Message-----
> From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of
> neil.2.harrison@bt.com
> Sent: Thursday, December 13, 2001 8:43 PM
> To: dave.mcdysan@wcom.com
> Cc: mpls@UU.NET
> Subject: RE: MPLSOAM BOF meeting draft minutes
>
>
> Dave McDysan wrote 13 December 2001 18:33
> >
> > > -----Original Message-----
> > > From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of
> > > neil.2.harrison@bt.com
> > > Sent: Wednesday, December 12, 2001 7:22 PM
> > > To: dcooper@gblx.net; dallan@nortelnetworks.com
> > > Cc: tnadeau@cisco.com; mgibson@orchestream.com; mpls@UU.NET
> > > Subject: RE: MPLSOAM BOF meeting draft minutes
> > >
> > >
> > > Hi Dave (C),
> > >
> > > I think they can co-exist.  Operators need tools that can
> > detect defects
> > > automatically (ie no waiting for the complaint to roll-in) and take
> > > immediate distributed executive actions as needed.  We also
> > need these to
> > > get some consistency amongst vendors for defect definitions
> > (entry/exit
> > > criteria) and ideally an availability metric (this does not
> > imply the
> > > *objectives* that such metrics have to meet, but the metrics
> > > themselves must
> > > be consistent across all parties).  To me these are 1st line
> > > must-have fault
> > > management tools.
> >
> > Agree that these are the essence of some important
> > requirements. Have you
> > looked at the IPPM definition and means to measure
> > "connectivity," which can
> > be interpreted as a measure of "availability."
> >
> > Regards,
> >
> > Dave
> NH=> I confess I have not done so recently.  But I would advise not to use
> QoS metrics as combinatorial inputs to some availability gating
> function as
> it gets far too complex......stick with simple defects so that
> availability
> entry/exit is simply a persistency of such.  Many of the problems I have
> with this area is that people sometimes get too focussed on the QoS stuff
> and forget to do the basic defect/availability stuff 1st...you know ATM
> better than most (I have your text book on my shelf) and I.356 is complex
> and one would not measure this on all connections full time, nor would one
> try and define combinatorial weightings of such metrics as availability
> entry/exit criteria.  I have tried hard to avoid these aspects with the
> stuff in Y.1711....the overiding requirement in here is
> simplicity and avoid
> the pitfalls in ATM.
> On a related topic....you may have noted that Giles seems to disagree with
> us that metrics are important and thus need standardising....or
> at least he
> seem unwilling (for now at least) to share his definition of what such an
> availability metric is.  I don't think we can allow this ad hoc approach
> long-term.  I'd like some agreed metrics here and I have attempted some
> pragmatic definitions in Y.1711 (based on defect persistency).
> Manufacturers need to know what we expect them to measure and its
> an obvious
> requirement for interoperability.
>
> regards, Neil