IDPR as a Proposed Standard

[Gene Tsudik <[e-mail]>]

This message is intended as partial response to recent comments on IDPR by
Y. Rekhter. Actually, I'd like to address only one point that has to do with
IP source routing.

  > 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 :-}).

Gene