Yakov Rekhter's comment on IDPR architecture

[[e-mail]]

I have just finished reading Yakov Rekhter's intresting observations on IDPR
architecture document and also your answers to these observations.

In the introduction, the document gives impression as if, the main driving 
force behind IDPR is to provide paths with specific QOS requirements in 
addition to meeting the policy requirements of transit and stub
ADs. But then, when it comes to route computation ( see section 4.2), 
architecture document says that routes will not be globally optimum.

As Yakov has already pointed out in his comments, this is in direct
contradiction of one of the main goals mentioned for the architecture.
Therefore, if it can not search for optimum routes, it is denying a 
service to the user that is actually available.
I could not trace any answer to this inherent contradiction in the
your replies.

With out ability to search optimum routes, the architecture, IMHO, hardly 
provides any great functionality over IDRP. Is IDPR really justified for 
whatever additional policy control that comes with it at the cost of huge 
overheads and complexity? My question is important because a) part of the 
additional IDPR functionality can also be provided by using different QOS 
FIBs in IDRP ( or in BGP in future) b). the additional functionality of 
IDPR (without the ability to select optimum routes) over IDRP (with multiple 
FIBs) may never be used in reality.  

If you think I am wrong in my assertion, please do point out to me.

Thanks,

bkumar