RE: Regarding draft-ash-multi-area-te-reqmts-01.txt

["Ash, Gerald R (Jerry), ALCTA" <gash@att.com>]

Vishwas,

Thanks for your email, see responses below.

Thanks,
Jerry

>1. I guess you have not taken into consideration the draft 
>http://www.ietf.org/internet-drafts/draft-srisuresh-ospf-te-01.txt
>
>This draft does figure on the TE page too, and there has been discussion on
>the draft especially on the OSPF list. This uses an approach of summary LSA
>for TE, infact it has defined new TE LSA's corresponding to an LSA in OSPF.

Yes, it should be mentioned.  There are other summary LSA mechanisms mentioned, e.g., http://search.ietf.org/internet-drafts/draft-venkatachalam-ospf-traffic-02.txt, however the I-D is intended to be inclusive.

>2. The requirements for multi-area TE talk about 
>a) maximize network utilization and minimize cost, considering QoS
>objectives
>b) minimize routing overhead (includes LSAs, crankbacks, queries, etc.),
>i.e., maximize scalability
> The requirements are related. The requirements should be to maximize
>network utilization even while sending minimum routing overhead. (Try and
>convey as much even without sending too much information)

Agreed.

>3. Here are some general requirements like point a) and b) could be:-
>
>  a) Promptness could be another requirement. To adapt to topological
>changes quickly i mean.
>  b) It should be extensible.(for example the new TE method as in point 1.
>is not extensible as are methods that use specific formats(particular LSA's)
>while TLV methods are extensible)
>  c) Also minimum routing overhead in case of change(for instance the TLV's
>as defined in OSPF, force the entire contents of the LSA to be resent if
>only a part of the LSA is modified.)

All sensible requirements.  The task if this work moves forward is to include the minimal set of essential, agreed-to requirements.

>4. Section 3 talks about LSA's/ABR's. Also else where there are talks of
>LSA's. It should be specified that most of the text relates to OSPF, as ISIS
>we do not have LSA's, but LSPDU's.

Yes, we are using OSPF terminology and this should be clarified.