[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: I-D ACTION:draft-ash-multi-area-te-reqmts-01.txt
Hi Yakov,
At 07:33 07/12/2001 -0800, Yakov Rekhter wrote:
>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;
Ossama, code is usually done to address real life problems ....
> 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.
I think the intention of Jerry was just to list the possible ways of
performing inter-area TE with the hope of converging to a minimum subset of
solutions. The draft title should have probably been different (Framework
(?) instead of requirements).
>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...)
Related to this comment and your previous comments I fully agree with you.
JP.
>yakov.