The MPLS WG Archive

Cell Relay Retreat>MPLS WG Archive>month:2002-Nov> msg00120



[Date Prev][Date Next][Thread Prev][Thread Next]  
  [Date Index][Thread Index][Author Index][Subject Index]

Requirements and solutions

  • From: Shahram Davari <Shahram_Davari@pmc-sierra.com>
  • Date: Tue, 19 Nov 2002 11:02:33 -0800
  • Cc: "'Gray, Eric'" <egray@celoxnetworks.com>, "'mpls@uu.net'" <mpls@UU.NET>

Monique,

I totally agree with you that customers need should be taken
to account first. And I have no problem with MPLS-ping or the
requirements doc. 

I understand the urgency, but to get a response in the meeting that
people should get used to this kind of process, and expect more to
happen in the future was a bit surprising to me.

Thanks,
-Shahram

> -----Original Message-----
> From: Monique Morrow [mailto:mmorrow@cisco.com]
> Sent: Tuesday, November 19, 2002 1:41 PM
> To: Shahram Davari
> Cc: 'Gray, Eric'; 'mpls@uu.net'
> Subject: RE: Requirements and solutions 
> 
> 
> Shahram,
> 
> I believe that we are all striving for a balance between 
> pragmatism and 
> architectural perfectionism -  the former being dictated by immediate 
> customer needs.
> 
> Kireeti has suggested that we run due diligence of these requirements 
> against the proposed solution --- something that is 
> reasonable and can be 
> done in parallel IMHO.
> Customers want solutions now not later and certainly, we can 
> dialogue on 
> evolving these requirements to the short-term, mid-term and long-term 
> proposed implementations as these develop.
> 
> Looking forward to a prolific collaborative effort Shahram -
> 
> Best regards,




> 
> >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.
> >
> >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.
> > >
>