Subject: correcting a mistake from my multicast plenary talk ...

From: Van Jacobson <[email-masked]>
Date: Tue, 15 Dec 98 00:11:46 PST

Several people have pointed out that I left a major
mis-impression during my IETF plenary talk.  In the summer of
'92, two independent groups started working on new approaches to
multicast.  One was the PIM development I described in the first
part of my talk, which started from an idea of mine but was
primarily developed and made real by Deborah Estrin of USC and
Dino Farinacci of cisco.  The other was CBT (Core Based Trees)
which was conceived by Paul Francis (then at Bellcore but
working on his PhD at University College London under Jon
Crowcroft) and developed and made real by Paul and Tony
Ballardie (& probably others that I don't know).  The PIM & CBT
efforts were entirely independent -- in the first few months of
their existence neither group knew of the other and even when they
became aware of one another, their only coupling was an intense
spirit of competition.  [There is still widespread
mis-information on this point.  Many people passionately believe
that PIM was based on CBT or vice-versa.  In fact, for reasons I
won't go into, the beginnings of both projects are pretty well
documented & we can establish that neither was based on the
other.]

Although PIM & CBT both use a unicast address to create a
multicast distribution tree, they do multicast in *very*
different ways.  PIM uses the unicast (`RP') address as the root
of a unidirectional distribution tree (i.e., all multicast data
flows down the tree from the RP to interested receivers).  CBT
uses the unicast (`core') address to define a bidirectional
spanning tree used to create a loop-free multicast distribution
(in much the same way that spanning tree bridges work).  For an
inter-domain multicast protocol, PIM's model can create an
undesirable "third party dependency" (e.g., since all data has
to come from the RP, which might be anywhere, communication
between adjacent domains A & B might depend on an RP in some
competitor's remote domain C).  Since data can originate
anywhere on a CBT tree & simply flows from where it originates
to the rest of the tree, CBT has no third party dependencies.
For this reason its trees were the basis for the inter-domain
BGMP protocol that was the focus of my talk.  [It turns out that
unidirectional trees are desirable for some multicast business
models.  We recently realized that uni- or bi- directional has
to do with how one `uses' the tree, not with how one creates it
(i.e., directionality is a policy attribute & not intrinsic) so
BGMP is evolving to support either type of tree.  But it started
from CBT-like domain spanning trees.]

In my talk I had intended to describe the UCL CBT work and
point out that its model was used for BGMP.  Unfortunately I was
trying to rush the talk & skipped that whole page of my notes.
I apologize for not having described this groundbreaking work
and for any confusion caused by the omission.

 - Van

---

From: Masataka Ohta <[email-masked]>
Date: Tue, 15 Dec 98 23:39:04 JST

Van;

> mis-impression during my IETF plenary talk.

Mis=impression? No, major mistakes.

The most obvious mistake among many was that you said PIM use
bidirectional trees.

But, your most serious mistake is to give the talk, of course.

> competitor's remote domain C).

Thank you for demostrating your poor understanding on multicast
issues once again.

With CBT with the following topology and location of the Core:

	A---D---E---F---C---Core
	               /
	              /
	             /
	B---G---H---I

The adjacent domains A and B must use C as the transit domain.

Note that that A and B are adjacent does not mean they must share
the same path to a hostile domain C.

Note also that domains A and B has no control over the location of
the Core of CBT nor RP of PIM. The Core may even be located
within C.

	A---D---E---F---C(Core)
	               /
	              /
	             /
	B---G---H---I

In general, the multicast policy issues can be defined only on the
Core/RP and the senders/receivers.

Worse, as was discussed in IDMR ML just recently, CBT/BGMP has less
power to control policy than PIM, because with bidirectional tree,
it can't control the policy independently for each direction.

The recommended reading on multicast policy issues is section 7
of draft-ohta-static-multicast-01.txt.

But, it does not help those who are obsessed with TCP so much.

						Masataka Ohta

---

From: Masataka Ohta <[email-masked]>
Date: Tue, 15 Dec 98 23:39:04 JST

Van;

	A---D---E---F---C---Core
	               /
	              /
	             /
	B---G---H---I

	A---D---E---F---C(Core)
	               /
	              /
	             /
	B---G---H---I

						Masataka Ohta