forwarding, policies, and standards

[[e-mail]]

Hello everyone,

First a response to some of Yakov's and Tony's questions that continue
to resurface, and then a response to one of Deborah's questions.

1. Hop-by-hop versus source-specified forwarding.

For a moment, divorce yourselves from the context of the Internet,
including the distinctions between intra-domain and inter-domain
routing and the notions of loose and strict IP source routing.  Assume
we have a network composed of a set of nodes and links between the
nodes and that we want to move messages between source and destination
nodes.

With hop-by-hop forwarding, each node forwards messages along routes
that it computes.  A node selects a route, and hence a next hop, for a
message, using information contained in the message such as source,
destination, and requested service.  To ensure routing consistent with
the source node's expectations (and to prevent routing loop
formation), all nodes must possess consistent routing information and
each node must use this information consistently when making
forwarding decisions for a given message.

With source-specified forwarding, each node forwards messages along
routes that the source computes.  The node selects a next hop for a
message using the forwarding information specified in the message.  To
ensure routing consistent with the source node's expectations, each
node must obey the forwarding directives contained within a given
message.

There are varying degrees of source-specified forwarding.  The source
may specify the complete route or only salient hops along the route.
In the first case, each node is constrained to the next hop specified
by the source.  In the second case, each node is constrained by the
next salient hop specified by the source but may use hop-by-hop
forwarding in between salient hopes.

For source-specified forwarding, the source may include the route in
the message or may install the route in the component nodes ahead of
time and include only a route identifier in the message, which by
association indicates the next hop at each node along the route.

Now back to the Internet context.  For IDPR, we have selected
source-specified forwarding at the inter-domain level, but we allow
routers to make their own intra-domain forwarding decisions.  (In this
sense, IDPR operates like IP loose source routing.)

As the Internet grows larger, we expect the consistency among router's
routing information, and hence the consistency of forwarding
decisions, to decrease.  Internet routing information may be too large
to be maintained by any one router.  Hence, routers will have
incomplete routing information.  Moreover, some routers may not want
other routers to know their special forwarding requirements, and so
they may intentionally withhold this information from general
distribution.  For these reasons, we chose source-specified instead of
hop-by-hop forwarding for IDPR.

In general, with IDPR, we stayed away from IP options solutions to
routing, for example using IP loose source routing and carrying
requested services as options.  The reasons are as follows.  There is
a limit to the amount of information we can place in the options and
we expected to exceed this limit.  Every router that received such a
message would have to understand the options.  Moreover, routers are
not in general optimized for messages containing IP options.  And,
perhaps most important, no dependence on IP means that one could use
IDPR in domains other than IP domains.

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.  Moreover, carrying the
route and services in each message is additional overhead on the
links.  For these reasons, we selected route setup instead.

2. Policies

While I agree that in today's Internet, a router can use message
filtering to prevent messages from or to certain domains from using
its domain, this does not give the full funtionality of IDPR.  IDPR
provides route selection not only according to access restrictions,
but also according to quality of service and monetary cost.  Moreover,
by distributing these attributes for each domain, the route servers at
the sources can compute routes that are consistent with their hosts'
requirements and with the transit domains' constraints.  Route setup
provides the filtering mechanism to allow domains to reject routes,
but this need only be performed once, not for every message.

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.

3. IDPR and other inter-domain routing procedure.

The forwarding mechanism at a router must decide, for a given message,
which next hop to take.  This forwarding decision is based on
information contained in the message (for example, source,
destination, and services) as well as information maintained by the
router which is analogous to which messages should be forwarded
according to routes provided by which routing procedures.
I know that the speed of the forwarding engine is the pride and joy of
each router vendor, and that such engines have to be carefully and
cleverly designed for maximum performance.

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.

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.
(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.

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.

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.

m