forwarding, policies, and standards

[Tony Li <[e-mail]>]

Hi,

In response to Martha:

   [A long tutorial on hop-by-hop vs source-specified routing -- elided.]

   Instead of carrying the entire route in each message, we selected
   route setup for IDPR.  Route setup specifies not only the route but
   also the services requested along the route.  While the route setup
   can incur an initial delay, there is fast forwarding, using the route
   identifier, of subsequent messages along the route.  Also, we expect
   the initial setup delay to be small in comparison to route lifetime.

   Instead of route setup, if each IDPR message carried the route and the
   services, then at each IDPR hop (the domain's entry and exit policy
   gateways) along the route, these routers would have to locate the next
   hop and the services contained in the message and find a path to that
   next hop that supports the requested services.  

Let's look in more detail at the problem.  The next hop is contained
in the message, presumably as the AD number of the next AD.  From
this, the entry router can examine its connections to the next AD and
compare these against the specified services (if any).  This
determines the exit router.  Please note that this information may be
cached.  The entry router then rewrites the encapsulating destination
address and forwards the packet.

With route setup, the incoming packet has a path ID.  The entry router
does a lookup in its path table to determine the exit router.  Note
that the path table is exactly analogous to the above cache, except
that it is much more expensive to maintain (since it must be complete,
at all times) and is much less robust.  The entry router then rewrites
the encapsulating destination and forwards the packet.

I don't find the differences significant.

   Moreover, carrying the
   route and services in each message is additional overhead on the
   links.  For these reasons, we selected route setup instead.

Carrying the path ID around (not to mention the encapsulation) is also
additional overhead.  If you are that concerned about bandwidth, then
the path ID (and other information necessary to reconstruct the
original IP header) should be compressed and attached as an IP option
to the original IP datagram.  

The argument about _current_ IP routers not optimizing IP option
processing is true, but specious.  Current IP routers do not route
IDPR anyway.  If you are going to change the router to route IDPR then
you can consider optimizing IP option processing as well.  One might
want to consider the costs of the router in either case.

Meta-comment: If IDPR is considered as a research project and part of
an experiment, then it needs to either a) exercise due caution and
explore other alternative designs in order to avoid major design flaws
or b) indicate that other experiments need to be performed to evaluate
its design decisions.  See below.

   2. Policies

   Yes, when one adds a policy, all IDPR entities (policy gateways and
   routers) must be able to understand it.  Although we have tried to
   offer a wide range of policies initially and a straightforward way of
   describing them, I expect that in the beginning there will be several
   modifications to these policies as people gain experience using them.
   However, over the long term, I expect few modifications to policies.
   People will select a set that they like, and these will be the ones
   that are used most often.  I also expect that there will be an IETF
   working group specifically targetted to determining what these
   policies should be.

This does not address the problem that I was trying to present.  While
IDPR currently supports a set of policies, there is no extensibility
in the protocol so that it can ever support a superset of these
policies without a version change in IDPR.  This is very painful.
Further, IM(ns)HO, it appears to me that the set of policies that can
be computed based on policy terms is not Turing equivalent.  That is,
given the fundamental set of policy variables and the set of
computable policies which only involve these variables, it is not
possible to state all of the computable policies within the current
policy terms.  Again, a version change of IDPR is required to support
this. 

   3. IDPR and other inter-domain routing procedure.

   In a router that supports multiple routing procedures, all messages
   have to be scanned by a procedure which decides where to forward them.
   Philip Almquist has addressed this issue in his Ruminations on the
   Next Hop.  In a router that accommodates IDPR, the forwarding engine
   must be able to detect messages that require IDPR forwarding.  But it
   is not the case the "everything must go through IDPR" before reaching
   the forwarding engine.

Excuse me, but RotNH does imply that all packets must be examined by
IDPR before they may be forwarded.  How does one detect packets that
require IDPR forwarding?  Anything that depends on inter-domain
routing must, I believe, be considered.  In the face of proposals
which want to spread a single network number across multiple domains,
I see no means of determining which destinations this must cover
without doing at least a routing table lookup.

   4. Proposed standard.

   The reasons for submitting IDPR into the IETF standards track are the
   following:

   (1) To provide a "standard" set of protocols and procedures to satisfy
       the policy routing needs voiced by commercial and
       government-subsidized transit providers in the states, and by
       transit providers in the Pacific rim, Canada, and Europe.

So is IDPR a research project?  Or product development?

   (2) To encourage independent implementations of IDPR for
       interoperability testing.
   (3) To obtain a rigorous review of IDPR by the IETF community.

   I am somewhat surprised by the recent reluctance to submit IDPR as a
   proposed standard, given that the working group has been discussing
   proposed standard status for more than a year and that until a month
   ago there were no objections raised by any working group members.  I
   am also a little curious about the reasons for the recent flood of
   questions, which could have been raised at any time over the past two
   years.  (If I were paranoid, I might almost suspect that the timing
   and the nature of these questions were designed purely to obstruct the
   progress of IDPR rather than to strengthen and improve it.)  But I'm
   not paranoid and so I believe the reluctance is well-intentioned.

For my part, the timing is due to the publication of RFC1310 and
recent experiences with STII.  If IDPR is published as a standard
(even experimental) it will be implemented and deployed.  To do this
with an immature technology is self defeating.  

   I am afraid that if IDPR were labelled an experimental protocol, that
   it would not get the review and experimentation that it needs.  Moreover,
   there are people out there right now that need policy-based routing
   right now.  Currently, IDPR is the only available policy routing
   mechanism that can satisfy those needs.

So it needs experimentation, but it should not be an experimental
protocol?  Yes, it is the only _current_ solution in the problem
domain.  Shall it be set in concrete now?  Only if you believe that it
is not possible to do better.  And if that is the case, why does it
need experimentation?

   According to the guidelines set forth in RFC 1264, IDPR meets all of
   the criteria for submission as a proposed standard.  Whether IDPR is
   accepted as a proposed standard is a decision to be made by the IETF
   community.  The IETF may reject IDPR altogether, but I think we should
   give them a chance to do so.

No argument.  And part of the process is for the working group to
determine just how IDPR should be submitted.  I believe that is what
we're discussing.  I favor that IDPR be submitted as an informational
standard, with limited use.  

Tony