Meeting Report of IDPR-WG

[Martha Steenstrup <[e-mail]>]

At the November 1992 IETF meeting, the IDPR working group met for
two consecutive sessions during the afternoon of Monday 16 November.
The first session was a working meeting, while the second session
was conducted as an overview for newcomers.  We organized the first
session as follows:

(1) General status report:
    (a) The IESG and IAB accepted the IDPR architecture and protocol
        documents as Proposed Standards in August 1992.
    (b) SRI is expecting to implement a large part of the IDPR MIB.
    (c) Rob Austein has designed the the DNS changes (address to
        domain identifier mapping queries and responses) required
        for IDPR.
    (d) We are seeking eager volunteers to produce an independent
        implementation of IDPR.

(2) Gated version of IDPR:

Woody Woodburn of Sparta led the gated implementation effort, with
additional participation by BBN.  SRI is presently using the gated
version of IDPR as the basis for policy routing in a network for one
of their clients.  Currently, SRI and BBN are taking responsibility
for the IDPR gated software.  We will eventually turn over the gated
version of IDPR to Cornell, but before doing so, we need to ensure
that the software:
- Conforms to the protocol specification.
- Has clear and complete documentation.
- Has been tuned to provide good performance.
We welcome all those interested in working on the IDPR gated software
or in developing their own IDPR implementations.  Please send a
message to [e-mail], if you're interested in working on IDPR
software development.

(3) Planned Internet pilot installation:

The target date is February 1993.  The installation will initially
include three backbone domains (NSFnet, NSInet, and TWBnet) and four
source domains.  We will exercise both source and transit policies.
This will give transit service providers a chance to observe IDPR in
action.  The results of the pilot installation, including ease of use
and management, general performance, and any problems encountered,
will be published as an Internet draft.

(4) Policy survey:

The policies initially available with IDPR were extrapolated from a
survey of federal agencies conducted several years ago.  As IDPR moves
from the testbed to the Internet, we should reevaluate the policy
support provided.  We intend to conduct a systematic survey of users
and transit service providers to determine what types of source and
transit policies are most desired.  Results of this survey will be
folded back into the policy offerings within IDPR.  Anyone interested
in helping to conduct the survey, please respond to the idpr-wg
mailing list.

(5) Multicast IDPR

To provide multicast support in an internetwork in which policy is
important, one cannot leave the forwarding decisions to intermediate
routers.  Rather multicast distribution should be defined by the
source, just as it is for unicast distribution.  To provide multicast
support within IDPR, we plan to make the following modifications to
IDPR:
- All multicast groups of which hosts within a domain are members will
  be distributed as part of the existing routing information messages
  for the domain.  This information will be used by a source to generate
  a multicast tree to other members of a multicast group.
- The path identifier will carry a special multicast bit indicating that
  it is a multicast packet.  All paths in a multicast tree will carry
  the same path identifier.
- One or more path setup packets will be used to set up the multicast
  tree in sections or all at once.  Each intermediate policy gateway in
  a path must keep track of all of the destination domains in the
  multicast tree that are reachable through the subtree of which it is
  the root.
- The source will be notified through a teardown message when all hosts
  within a domain leave a the multicast group.  The teardown will only
  affect the portion of the tree set up to that domain.  A source should
  be able to initiate teardown to selected destinations or to all
  destinations within a multicast tree.
- Intra-domain multicast, when available, will be used in conjunction
  with IDPR multicast.
In early 1993, we will distribute an Internet draft describing the initial
version of multicast routing for IDPR.