Re: I-D ACTION:draft-ash-multi-area-te-reqmts-01.txt

[Yakov Rekhter <yakov@juniper.net>]

Osama,

> See my comments below

see inline...

> Venkata,
> 
> > Jerry:
> >
> >    my 2 cents...
> >
> > -> > here are the follow-up questions:
> > -> >
> > -> > a. do we need multi-area te?
> >
> >    Yes!
> >
> > -> > if yes, then
> > -> > b. do we need multi-area te requirements?
> >
> >    Yes, for a unified solution.
> *
> * if a unified solution can't be produced without multi-area te
> * requirements, then perhaps we could pursue a non-unified
> * solution...
> *
> > -> > if yes, then
> > -> > c. should we add these requrements to
> > -> draft-ietf-restore-hierarchy-00.txt?
> > -> > if no, then
> > -> > d. what should we do about multi-area te requirements?
> >
> >    Place doesn't matter - content matters!
> *
> * Actually what really matters is working code and operational
> * experience. And it is far from obvious (at least to me) that a
> * requirements document is going to provide a useful contribution to
> * either the working code or the operational experience.
> *
> * yakov.
> 
> 
> In My opinion, What really matters is the network ability to deliver
> deterministic QoS guarantee End-to-End to network subscribers; at the end of
> the day the subscriber will not benefit from TE engineering capabilities,
> unless its world is confined to a single area within an AD.
> 
> Working code that meets requirements is good; but if requirements are not
> addressing a real life problem; then the code and its requirements do not
> really matter that much.

Which suggest that we need working code that addresses a real life
problem.  I would certainly agree with that. 

But I don't think that in order to produce a working code that
addresses a real life problem it is necessary to have a requirements
document produced by the IETF WG. In fact, I have an existence
proof that plenty of working code that addresses real life problems
have been produced with no requirements documents produced by the
IETF WGs (just think of OSPF, BGP, etc...)

yakov.