July IETF minutes

[Martha Steenstrup <[e-mail]>]

Hello everyone, and to the new members, welcome!

The IDPR working group met in two sessions during the July 1992 IETF
meeting in Boston.  In the first session we talked about shorter-term
as well as longer-term work on IDPR, and in the second session we
offered a spur of the moment demo and shared the remainder of the
session with the NIMROD group.

Shorter-term topics:

- Work on the gated version of IDPR.  Currently, Woody Woodburn has a
version of IDPR that runs as part of gated.  Woody provided a detailed
description of the status of the gated implementation at the first
session and at the second session gave a demo of the software.  To
obtain a copy of the IDPR software, please contact [e-mail].
We plan a pilot demonstration of this software in the Internet in late
summer or early fall.  Moreover, we expect that, as a result of this
experimentation, we will want to make changes to the software and
perhaps to the protocols as well.  The IDPR working group needs a set
of people that are able and interested in working on enhancing the
IDPR gated software.

- MIB development.  We need to implement the MIB, and we need to
update the Internet Drafts describing both the IDPR MIB and the IDPR
configuration and usage guide.

- Adding facilities to the DNS.  The DNS should be able to return
domain information in response to a query giving entity name or
address.

- Adding the capability for hosts to request source policies
dynamically.  In the current version of IDPR, source policies are
specified as part of path agent configuration and remain active for a
given host until they are reconfigured.  Thus, hosts needn't do
anything special to communicate this information to the path agents.
We made this choice so that no host changes were necessary to reap the
benefits of IDPR.  However, we expect that in the future, hosts may
want to have different source policies, depending upon the application
active at the moment, and hence need a way to communicate this
information to the path agents.  SRI is working on a subset of this
problem, but we may require a more general solution.

At the working group sessions, several of you volunteered to work on
the shorter-term topics, pending approval from employers.  Would those
of you who have obtained such approval and who are still interested in
working on these topics, please send mail to me at [e-mail] so
that we can move these efforts along.

The longer-term topics include:

- Multicast support.  IDPR should have the ability to construct
multicast trees and establish the appropriate paths associated with
these trees.  Moreover, IDPR should be able to take advantage of
intra-domain multicast where available, both for IDPR control
information distribution and for multicast user applications.  We are
pursuing solutions targeted for IDPR.  However, those of you
interested in inter-domain multicasting in general may also wish to
join the mailing list set up by Jon Crowcroft and Tony Ballardie of
UCL.  To subscribe to the list, send email to
[e-mail].

- Multipath support.  IDPR should have the ability to maintain as a
unit multiple paths of the same service between the same source and
destination.  Multiple paths provide a vehicle for obtaining
sufficient bandwidth, for load-balancing, and for providing backups
when a primary path fails.

- Resource allocation.  IDPR should be able to interoperate with
resource reservation and flow control mechanisms to provide service
guarantees.

- Super domains.  As the Internet grows, one may wish to aggregate
domains into super domains in order to reduce the amount of
information and computation related to routing.  Aggregation produces
a hierarchy of domains.  IDPR should provide a domain address format
that permits addressing of domains at arbitrary positions in a domain
hierarchy.

Any comments on any of these topics are most welcome on the IDPR
mailing list, [e-mail].