The MPLS WG Archive

[neil.2.harrison@bt.com]

There is a balance to be struck between the effort/time-spent
capturing/agreeing requirements and the effort/time-spent defining
solutions.  Common sense really.  However, there are set of functional
attributes that all network technologies require.....and fault-management is
amongst one of the most basic no-brainers.  So having said that, if we
cannot point to where the defects are identified/documented/specified (wrt
to entry/exit criteria and consequent actions.....which IMO ought to be the
starting point) then I think we are in a pretty poor shape to be making any
statements about trying to achieve perfection.

BTW - sometimes its not looking for solutions to the problems caused by
technology X that is the answer, the real answer maybe that technology X
itself is the problem.  However, this is far harder to recognise/accept and
deal with for many reasons.

regards, Neil 

> -----Original Message-----
> From: Thomas D. Nadeau [mailto:tnadeau@cisco.com]
> Sent: 19 November 2002 18:31
> To: Gray, Eric
> Cc: 'Shahram Davari'; 'mpls@uu.net'
> Subject: RE: Requirements and solutions 
> 
> 
> At 11:20 AM 11/19/2002 -0500, Gray, Eric wrote:
> >Shahram,
> >
> >         We need to be a little less retentive about terms,
> >documents and ordering.
> >
> >         A lot of the time in the IETF, work starts without
> >a formal requirements document.  This is because some set
> >of people - nearly always including authors and often
> >including several others as well - believe they understand
> >the requirements well enough without formally documenting
> >them.  In many cases, a requirements statement of a sort
> >is included in the draft abstract and/or introduction.
> >
> >         Lately, there is a lot of preoccupation with the
> >need for formality.  A point I believe was made today is
> >that it is possible for a requirements document to proceed
> >in parallel and the results compared in an applicability
> >document.  This is quite reasonable.
> >
> >         While some people said something to the effect that -
> >in the event that they don't match up well - a mismatch is
> >an indication of failure on the part of the original draft
> >authors to develop something useful.  I think one could go
> >further and argue that the mismatch may be an indication
> >of future work that may be needed for subsequent versions
> >of the work already done.
> 
>          I totally agree.    Many people much smarter than
> us have tried  to produce the grandest, most perfect solutions
> from the start and failed.  IMHO, a mismatch is a reason to just
> iterate  again to evolve the solution.
> 
>          --Tom
> 
> 
> 
> >Eric W. Gray
> >Systems Architect
> >Celox Networks, Inc.
> >egray@celoxnetworks.com
> >508 305 7214
> >
> >
> > > -----Original Message-----
> > > From: Shahram Davari [mailto:Shahram_Davari@pmc-sierra.com]
> > > Sent: Tuesday, November 19, 2002 11:02 AM
> > > To: 'mpls@uu.net'
> > > Subject: Requirements and solutions
> > >
> > > Hi,
> > >
> > > I am very much troubled by a comment raised in MPLS meeting, that
> > > in the future the order of first requirements and then 
> solution would
> > > quite often change and that hopefully it would not require any
> > > modification
> > > to the already approved solution.
> > >
> > > This may be acceptable in occasional cases (may be MPLS-ping
> > > is one of those cases), but I am not sure it is a good idea
> > > to make this as a general rule.
> > >
> > >
> > > Thanks,
> > > Shahram
> > >
> > > PS- Please not that my comment is not against MPLS-ping, 
> rather about
> > > procedures.
> 
> Success is relative; the more success, the more relatives. -Anonymous
> 
>