comments on the architecture document

[Robert Woody Woodburn <[e-mail]>]

Hi Yakov, 

Let me quickly add my two cents...

I haven't had time to compare these two documents in detail.  That should
raise some eyebrows, since I'm the sole implementor right now (who's
working from the current spec anyway) The fact is that the last ID that was
posted was never implemented because I was too busy getting the previous
prototype into gated, playing with some radix things in the kernel, getting
pulled off onto proposals, etc, etc...

I believe that you'll find that the guts of the protocol(s) have not changed
significantly.  A lot of the new material goes toward the description of a
sample routing algorithm, the addition of the "route query" protocol (which
isn't really a big deal), more interesting policies, and other explanatory
text where it was thought helpful.

I don't think these are particularly significant changes as far as the
protocols themselves go.  Aside from the 17 pages difference, you'll
probably just find the newer spec a bit more thorough.  (Though as you'll
have noticed from my previous messages, I'm still muddling through a few
things as I get to them.  However, once again I would not call message
formats "significant".)

IDPR may not be the greatest thing in the world, and sure it is going to
have some problems and I'm very sure that there are improvements that could
be made, both in the architecture and in the protocols.  However, it is the
only protocol right now that can offer Inter-AD Source Routing and I would
say that its design is sufficient to gain experience with an LS SR protocol.
A lot of problems will be resolved as we see some experimental deployment.
But we have to start somewhere, lest we design forever and try to solve
all possible issues, which was where, as we all remember only too well, the
original ORWG wasted too much of its time.

[Next paragraphs to be read partially tongue in cheek please...]

So Yakov, what's your real beef?  Is it technical?  Then please make
suggestions to help us improve the spec.  I certainly want to see IDPR
have more rough edges smoothed.  Or if you see essential design flaws, then
please elaborate and suggest constructive alternatives.  I have lots of
criticisms of IDPR myself, but I don't feel it is productive for me to
voice many of them until I have time to develop constructive alternatives,
otherwise it just wastes everybody's time.

Is it procedural?  Then perhaps we need to take it up with the procedural
body of the IETF for clarification of how the process is really supposed to
work.

But I'm afraid over the past two weeks that we've been bashing this thing
back and forth, I haven't seen your point.  All I can conjecture is that
either:

	A.  You don't like IDPR or see it as problematic
	    competition and want to sabotage it.
	B.  You feel slighted in some way by how IDPR is being
	    progressed and feel that it is unfair compared with
	    what you see your experience with progressing BGP.
	C.  You see severe technical problems with IDPR
	    and are crusading to save the Internet from
	    its deployment lest all gateways known to man
	    burst into spontaneous combustion when the	
	    silly thing gets turned on.
	D.  You like keeping me from being home on time and
	    seeing my wife.

Cheers... and good night,

wood y