comments on IDPR architecture

[[e-mail]]

Martha,
>Distance Vector Distribution Graphs
>-------- ------ ------------ ------
>

	Your text is still confusing. As you mentioned yourself,
	this is just "a way to control distribution" of routing information.
	If, indeed, you'll decide to control distribution of routing
	information based on a single acyclic directed graph, then you would not
	get fallback routes. But note, that this has nothing to do
	with BGP, but is a direct consequence of how you decided to
	distribute the information.

	So, I can't see how you can make a claim that this is BGP/IDRP
	problem. To reiterate, this is a direct consequence of your
	local decision, that has nothing to do with the protocol.
	In fact, you may end up with exactly the same scenario
	in IDPR, if you would not flood all the information everywhere
	but rather distribute information selectively.
	(I understand, that this is not in the protocol, but the
	architecture claims to support this).

>
>Hop-by-Hop Forwarding
>---------- ----------
>
>Yakov, as you know we have argued about the example (on page 9 of the
>text version of the architecture document) before, in the context of
>your paper with Deborah Estrin and Steve Hotz.  I convinced Deborah
>and I thought (but was apparently mistaken) that I had convinced you
>as well that this state is not "transient".  While a distance vector
>routing procedure could detect loops of this type, as far as I know,
>neither BGP nor IDRP has such a detection mechanism - and with good
>reason: it's expensive.  Hence, this loop will persist until either X
>or Y chooses another route Z, which may not happen for a long time.

	Actually, the state you refering to persists ONLY in the presence
	of persistent syncronization between the peers. Since both BGP and IDRP
	require jitter on their route selection process, the probability
	of remaining in that state decreases rather rapidly with each
	oscillation (it decreases as geometrical series). I personally
	don't find jitter requirement "expensive".

>
>"Optimal" Routes
>--------- ------
>
>I was not sure how you intended the word "optimal".  You mentioned
>that finding the "optimal" route takes exponential time.  If you mean
>"optimal" in the sense of the following routing problem "find a route
>between A and B that has delay no more that X and monetary cost no
>more than Y", then you are correct.  This search does take exponential
>time.  While an individual route server can do multi-criteria
>optimization if it wishes, we recommend instead that the domain
>administrator prioritize requested qualities of service according to
>what is needed.  The route selected should provide the highest
>priority type of service, but will be only "best effort" on the other
>services requested.

	Your comments about doing multi-criteria optimization and
	the exponential complexity associated with it would be
	quite useful to add to the architecture document.

>
>However, if you mean "optimal" in the sense of minimizing delay,
>minimizing cost, or maximizing bandwidth, then your statement isn't
>true.  All of these functions can be performed in polynomial time,
>using for example Dijkstra's SPF search or even a simple breadth-first
>search.

	Sketching Dijkstra that would compute min cost route
	in presence of different charging schemes would certainly help
	to support your claim.

>
>BGP/IDRP
>--------
>
>Yakov, I used BGP as a comparison point for two reasons.  One is that
>I did this comparison in the early part of 1991.  BGP was much more
>solid than IDRP at that time.  The second reason was that I was
>interested in IETF routing procedures.  At that point, IDRP was slated
>for ANSI and not IETF.  I realize that much has happened since that
>time, and that I should go back and make the comparison with IDRP.
>However, at the time the comparison was a reasonable one to make.

	We are in full agreement on this subject.


Yakov.

P.S.There are still few questions/issues raised in my original
	  mail that you did not answer.