Editor's Note: Minutes received 11/24/92

CURRENT_MEETING_REPORT_

Reported by Martha Steenstrup/BBN

Minutes of the Inter-Domain Policy Routing Working Group (IDPR)

At the November 1992 IETF meeting, the IDPR Working Group met for two
consecutive sessions during the afternoon of Monday the 16th.  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

       o The IESG and IAB accepted the IDPR architecture and protocol
         documents as Proposed Standards in August 1992.

       o SRI is expecting to implement a large part of the IDPR MIB.

       o Rob Austein has designed the the DNS changes (address to domain
         identifier mapping queries and responses) required for IDPR.

       o 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:

       o Conforms to the protocol specification.
       o Has clear and complete documentation.
       o 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 idpr-wg@bbn.com, 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.


                                   1





  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:

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

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

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

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

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

Attendees

Cengiz Alaettinoglu      ca@cs.umd.edu

                                   2





Ken Carlberg             Carlberg@cseic.saic.com
Dilip Chatwani           dilip@synoptics.com
Osmund de Souza          osmund.desouza@att.com
Barbara Denny            denny@erg.sri.com
Paul Griffiths           griff@chang.austin.ibm.com
John Hedderman           jjh@ans.net
Jonathan Hsu             brenda@penril.com
Dwight Jamieson          djamies@bnr.ca
Fong-Ching Liaw          fong@eng.sun.com
Olli-Pekka Lintula       olli-pekka.lintula@ntc.nokia.com
Peder Norgaard           pcn@tbit.dk
John Scudder             jgs@merit.edu
William Simpson          Bill.Simpson@um.cc.umich.edu
Lansing Sloan            ljsloan@llnl.gov
Frank Solensky           solensky@andr.ub.com
Martha Steenstrup        msteenst@bbn.com
Robert Woodburn          woody@sparta.com



                                   3