Report from Maestro BOF

["David Oran" <oran at cisco.com>]

This is being sent to the IETF to distribute this information
out to the part of the community that might not be monitoring the
routing-oriented lists.


The Routing Area held a BoF at the Oslo IETF whose purpose was to discuss
potential refinements to the IP multicast model in two areas:
  1) Enhanced two-part multicast addressing to ease scalability and
     deployment headaches,
  2) Optimizations to exploit the single-sender case

The BoF announcement, along with its scope and agenda, may be found at:
http://www.ietf.org/ietf/99jul/maestro-agenda-99jul.txt

The minutes of BoF are attached below. One of the conclusions from the BoF
was to continue discussions on these subjects to ascertain if there is a
critical mass of support to charter one or more Working Groups to pursue
IETF standards (or other outputs) in these areas. We are therefore
resurrecting a moribund Routing Area mailing list for this purpose:
	routing-discussion at ietf.org
Subscription is via majordomo at ietf.org

Thanks to all who participated in the BoF and in advance for useful
low-flamability discussion on the mailing list.

Regards, Dave Oran (routing co-area director)




MAESTRO BOF, Dave Oran
----------------------

AGENDA

History - modify multicast model, do we need a working group
on this?

A number of people think if we simplify the multicast model
there are significant benefits in reducing complexity.
changes: addressing model, assume single sender.

We want to look at the problems today and see how proposed
simplications might help.

Ground rules: talk about problems and how they map to the
proposed simplifications.  from two perspectives, isp's
and architectural view.


Bryan Lyles, Sprint Deployment Strategy
---------------------------------------
Today, multicast enabled, working with vendors and customers to make
it work.  built on PIM-SM, MSDP, MBGP, IGMPV2, GLOP.

Short Term - push current protocols, work in ietf to enhance base.

Certain kinds of applications want single server (radio station,
politician giving speech, dont want opposition heckling him)


Hugh Holbrook, Stanford/Cisco
-----------------------------
Some multicast applications work well with unicast
others its impossible, high data rates, many receivers
questions to isp's - how do you bill for it.  make billing reflect
cost.  so charge by size of group.

	dmm - if i am a source, receivers on same isp are onnet,
	other receivers are offnet. want to billed for offnet folks.

	brad cain - bill by bandwidth, can isp's break even on multicast.

Queries flow down tree, counts flow back up, somehow gather data
to bill src.  access control for large groups, restrict senders
in advance (pirates on tv station), important for commercial
applications too.

	kevin almeroth - why does it work with radia, lawyers are
	the answers, no one owns a multicast address, if they did
	you could sue someone for using yours without permission.

security - source provides passwd to receivers

www.dsg.stanford.edu/hollbrook/express


Jeremy Hall, uunet
------------------
Problems - scalability, single source model ok, hard to implement.
you are trying to restrict something that is not restrictable.
lots of protocols running as ships in the night, ok when it works,
never know which one is not working correctly.  way too much ad hoc
stuff going on. which protocol is broken.  nice to be able to trace
a problem from the sender, to the receiver.  receiver says i'm not
receiving this content.  have to figure out from that info, where
the source is and what the problem is.

Some applications hide the group, so you cant figure out where
to troubleshoot.  people dont understand how it works, so they
cant help you debug.  need education.

Billing problems, counting receivers might be nice but is hard
as groups get big.  onnet vs offnet.  tried to employ things
that are parallel to unicast.  unicast routing tries to dump traffic
asap, mulitcast wants to keep as long as possible.  current model
doesnt scale.  anyone can source to any group and thats a security
problem.  there are a lot of security issues with multicast.


Mark Handley, ACIRI
-------------------
Internet Standard Multicast, where it came from and why it had
nice properties.  direct extension of the unicast model, host
sends packets to destination address, it gets there.  nice
architecure, senders dont need to know about receivers.
recievers dont need to know who senders are.  distributed binding
is useful resource.  senders and receivers dont need to know about
topology, robust, route around failures etc.  hosts dont need to
knows about routing protocool.  need distinction between service
model and its implementation in the network.  separates what
the application wants and how the network achieves it.  clean
separation of routing and transport/application layer.

What can we do with it:

Regular one to many applications - video distribution, data distribution
many to many applications - conferening, games, dont know members in
advance, distributed binding is very robust, changes the way you design
applications (eg wb)

Many to few applications - server discovery

Scoping, used to have ttl scoping, poor for traffic engineering,
great for self organizing applications, expanding ring search,
we lost the ttl in pim, admin scoping getting it back, mzap

Security - can only restrict traffic safely with encryption.
content providers want authentication, have the mechanisms already.

problems:

	forwarding table size, aggregation helps some;
	how can isp's make money;
	lack of scalable routing protocol, bgmp, hierarchical pim,
	  bi-direction pim with grib, bgmp will probably work,
	  hierarchical pim too;
	lack or good network management and diagnostic tools.

serious growing pains, transition from dvmrp painful

distributed binding a key - wb, sdr, mimaze applications

important to avoid constraining network mechanisms to support only one
  to many applications


Bryan - lots of differences of opionion in the community.
Hugh  - avoid overly commplicating things for futures applications
	when we have existing applications that need support now.


jon crowcroft, ucl, www.cs.ucl.ac.uk/research/rama
--------------------------------------------------
Enhancing deering multicast, enhancing the addressing scheme.
class D address is a channel, not really an ip address.
Anonymously names a group of receivers, allows anyone to send to it.
alternatives, allow end systems to be explicit
DCM/connectionless multicast - add list of addresses,
transparency and fault tolerance


David Oran - Final Questions
----------------------------
we have 5 minutes, where should we go with this?

Brian Whetten - wishes had heard more from isps about problems.

TODO - decide which problems are of deployment and which are based
on what we are deploying.

Scott Petrak - 3 things: think about low bandwidth hosts at the end,
  like wireless; thing 2 i missed; small number of senders a worthy
  optimization.

Dorian Kim - deployment problems have been maturity of implementation issues
and how to make all the hacks play together.  havent tried running native
multicast at scales we want.  will find more answers as we deploy and ramp
up, at this point probably not worth limiting model.

Hum votes
	create a mailing list   2/3 hum
	no mailing list 	1/3 hum