IDPR as a Proposed Standard

[[e-mail]]

Gene,	
Thanks for your prompt response.
Your answers, however, generated more questions.
To make the whole stuff understandable I prepended my original comments
with ">>", your response with ">", and my new comments are just
indented.
Yakov.

>  > Do you have any specific details  that would substantiate your claim
>  > that there is "no efficient source-specified forwarding" ?
>
>  > You also claim that "IP source routing is not efficient for forwarding
>  > large numbers of data messages". First of all, I wonder whether you
>  > have any data in support of such claim. Second of all, does your
>  > statement implies that IP source routing is efficient for forwarding
>  > SMALL numbers of data messages and "is not efficient" ONLY when
>  > the number of messages to be forwarded is large ? If the answer is
>  > yes, then how could you justify a need for a special network layer
>  > protocol when the number of messages is not large ?
>
>
>There are two types of IP source routing: strict(SSR) and loose(LSR).
>SSR is all but useless as we'd like to be able to hide intra-domain
>structure from the inter-domain traffic. Also, in the "unlikely" event
>that a router goes down we'd like to handle the situation without having to
>bounce a packet and recompute a different SSR.
>
>LSR is a wee bit better. It allows us to hide the intra-domain structure by
>specifiying only the border routers as part of an LSR. However,
>we would still have a problem of not being able to switch to a parallel
>border router when one of the routers specified in an LSR goes down.
>Also, we introduce two types of overhead:
>
>i) overhead due to LSR itself (extra length) and
>
>This one is not a big deal as bits are cheap nowadays. The only worrisome
>issue has to do with really looooong routes. IP is limited to 60 bytes of
>header length (which includes options). 20 out of these 60 bytes are taken up
>by the standard IP header which leaves 40. 4 more are used up by option id,
>option length and padding. This leaves 36 bytes which leaves enough space
>for up to 9 IP addresses, i.e., 9 hops max. Hence, only Policy Routes of
>5 AD hops or less can be accommodated (including endpoint AD hops).
>
>IDPR, being a protocol in its own right, wouldn't have this problem even if
>it chose to include full routes in the header. However, IDPR header is
>quite short (except when exotic authentication is used).
>
>ii) overhead due to LSR option processing in EVERY intervening IP router.
>
>The problem is that every IP option is
>visible to (and is, therefore, processed by) each and every IP router
>encountered. This, of course, includes all non-border routers in all
>intervening domains. IMHO, it is fair to assume that there are many more
>non-border (intra-AD) than border routers in an average PR. Therefore,
>the combined overhead of extra processing in every router may add up...
>
>IDPR, on the other hand, is "visible" only to IDPR Policy Gateways (PGs), i.e.,
>only to the border routers. Of course, the overhead in each PG is
>can be substantial, especially with large PR tables and per PG-hop
>authentication (for truly paranoid :-}).
>

	First of all, you still did not answer my question about
	source-specified forwarding. I'd like to point out that
	source-specified forwarding may be implemented in a variety
	of ways, including, BUT NOT LIMITED TO, source route in every
    packet, or source setup (like in IDPR).

	The ability "to switch to a parallel border
	router when one of the routers specified in an LSR goes down"
	assumes that there is such "parallel border router". Would
	you consider to take a look at the existining Internet and
	count the percentage of domain pairs that have more than
	one link connecting the pair. That may give us much better
	understanding of the importance of this feature.

	With respect to only 5 AD hops restriction, I think you
	are incorrect. I can certainly show you a scheme that would
	let you have 9 AD hops.
	
	As was indicated to Tony Li, I was not presuming only the
	available source routing facilities, though I was not
	ruling them out either. Moreover, as Tony indicated
	"there are other ways of doing source routing" that
	apparently were discussed between some of the IDPR WG members.
	It would be really helpful to get information on why the WG
	rejected "other ways".

	Do you have any data that would substantiate your assumption
	that "there are many more non-border than border routers in an
	average PR" ?

	Do you have any data on how much extra processing (how many
	instructions)  it would take to process source-route option ?

Yakov Rekhter ([e-mail])