IDMR met in one session at the Minneapolis IETF.  These minutes were
collected by Bill Fenner.

Administrivia: Bill Fenner's new email address is <fenner@research.att.com>

Jennifer Hou presented some QoS extensions to CBT.  These extensions
provide the capability to ensure a certain QoS along a CBT-built
tree.  The desired QoS can be specified as an upper or lower bound
on some parameter (such as delay, loss, available bandwidth) or as
a bound on the inter-receiver difference (e.g. inter-receiver delay
jitter bound).

When a QoS-aware member joins, the on-tree router performs an
eligibility test, based upon information that was collected as the
join traveled towards the tree and information that the on-tree
router has, and only replies with a Join-Ack if the test succeeds.
On-tree routers need only keep state about the maximum (or minimum)
value of a parameter within the subtree rooted at that router.

In simulation, the worst case message overhead was twice unmodified
CBT.


Bill Fenner talked about rechartering IDMR.  IDMR has been an
unfocused "catch-all" working group for all multicast-related
issues for years.  Previous attempts to get the working group
interested in fixing the charter have more or less failed, and the
current charter has very little applicability to what the working
group has been doing.  Bill proposed rechartering IDMR to finish
work on the existing "catch-all" documents: IGMPv3, Multicast Router
Discovery, Domain-Wide Reports, IGMP Proxying, Multicast Traceroute,
the Multicast Interoperability draft, and any others that may have
been forgotten.  New working groups would be chartered for any
other work (such as BGMP); minor issues could be handled in the
Routing Area meetings or MADDOGS.

Bill proposed renaming the working group to Internet-Draft Multicast
Remnants, and set a firm latest acceptable work item due date of
April 2000.  The only two comments were positive ones.  Bill will
send a proposed revised charter to the IDMR mailing list.


Following in the same vein, Bill talked about chartering a BGMP
working group.  Its charter would effectively be to complete the
BGMP protocol specification (and related MIBs) and follow them
through the standards track.  Goals and Milestones include security,
interoperability, monitoring and measurement.  Developing a transition
plan was added to the goals by suggestion.  Bill will send a proposed
charter to the BGMP mailing list.


Dave Thaler talked about BGP Path attributes for multicast tree
construction.  These help provide policies on how routes may be
used to construct multicast trees; they are independent of the
multicast routing protocol but provide information which "policy-clueful"
protocols like BGMP could use.

The two proposed attributes are a forwarder preference and a
directional policy attribute.  The forwarder preference is a
non-transitive attribute which allows the election of a designated
forwarder per prefix.  Electing the designated forwarder at the
time of route exchange eliminates the need for a mechanism like
PIM's "Assert" process to resolve multiple forwarders.  This
procedure is already present in BGMP, but if it were in BGP it
could be used by other multicast routing protocols.  In addition,
there is a race condition when using BGMP to elect a forwarder; if
the route is learned via BGP, then data arrives before BGMP has
noticed the new route and elected a forwarder, then there is not
yet a designated forwarder.

The directional policy attribute allows the annotation of a route
as "come-from", "go-to", or "both".  "both" is the default, and
are the only routes that may be used by bidirectional tree protocols.
"Go-to" routes may be useful for non-member senders, especially in
a UDLR environment.  Come-From routes can be of two types.  A
Come-From route for a source may be used to perform reverse-path
forwarding.  A Come-From route for a group indicates that that
group requires a unidirectional tree.  Come-From routes may optionally
be annotated with an encapsulation destination for sending to the
root of the bidirectional tree (like PIM's Registers).

One use for the directional policy attribute is that an ISP which
only supports unidirectional trees may annotate all routes with
the Come-From attribute.  This allows the tree to be bidirectional
in the parts of the network that support it but unidirectional in
the parts that don't.  It can also potentially create a debugging
nightmare.  "Lots of rope".

In discussion, it was mentioned that BGP is not necessarily the
right place for these options.  In fact, BGP was originally considered
but discarded for the Forwarder Preference attribute and that
attribute was added to BGMP (introducing the synchronization problem
mentioned earlier).  The desire for a directional attribute raises
the same kind of problem.  Since these attributes are (or are
considered to be) protocol independent, perhaps they belong in BGP.