The MPLS WG Archive

["Thomas D. Nadeau" <tnadeau@cisco.com>]

At 10:14 AM 11/19/2002 -0800, Shahram Davari wrote:
>Eric,
>
>As I said in my email, this is not a rule that is written in stone
>(like ten commandments). But I think it should be the general practice.
>
>I understand that in some cases, solution is developed without formal
>requirements. But I am wondering whether a follow up requirements RFC
>makes sense in those cases.

         As we discussed during the meeting, LSP ping was designed
to be flexible and EVOLUTIONARY, so yes, if we need to fix
something that we discover is wrong, we can fix it incrementally
later.   For now, I think that LSP ping is a tool that is quite useful to
solve the problems it was designed to solve. If we discover later
that it needs some patching, it was designed to handle this.

         --Tom


>Yours,
>-Shahram
>
>
> > -----Original Message-----
> > From: Gray, Eric [mailto:egray@celoxnetworks.com]
> > Sent: Tuesday, November 19, 2002 11:20 AM
> > To: Shahram Davari; 'mpls@uu.net'
> > Subject: RE: Requirements and solutions
> >
> >
> > 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.
> >
> >
> > 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