Subject: MBONED mailing list

From: "David M. Meyer 541/346-1747" <[email-masked]>
Date: Wed, 10 Jul 1996 15:55:59 -0700 (PDT)

Several people have requested that I create an MBONED
	mailing list to continue the discussion started in
	Montreal at the MBONED BOF. After some discussion about
	which list to use for this purpose, I considered asking
	to use this list ([email-masked]) or rem-conf for this
	purpose. However, general consensus was that mbone and
	rem-conf are more general purpose lists, and that a
	MBONED list should be created. Here is the information: 

	List:		[email-masked]
	To Subscribe:	[email-masked]
	Archive:	ftp://ftp.uoregon.edu/mailing-lists/mboned*

	Thanks,

	Dave

---

From: "Matt Mathis" <[email-masked]>
Date: Thu, 11 Jul 1996 11:26:10 -0400

Some time ago (I hate to admit how long) I drafted the attached MBone
Appropriate Topology document.  It has been dormant due to my lack of
time and quite frankly my queasyness about some of the possible
fallout.

I believe that the primary problem with the MBone is non-alignment
between the multicast topology and the IP topology of the Internet,
and that if this non-alignment is fixed, other problems, such as down
rev implementations will become much easier to address.

What we ("other person singular") should do is to turn this into an
RFC - perhaps a BCP.  Then the providers who are serious about multicast
can make "complaince with RFCxxxx" a requirement for feeds to other
sites.

This work logically belongs in the mboned working group.  Please join
the list, and please move follow up discussion there:
List:           [email-masked]
To Subscribe:   [email-masked]
Archive:        ftp://ftp.uoregon.edu/mailing-lists/mboned*

Thanks to Pete Berger (@psc) and Jeff Young (@MCI) for help and ideas.

Thanks for your attention,
--MM--

----------------
MBONE Appropriate Topology (MBAT)

Our Goal: To evolve the MBone from an experiment to a production quality
global Internet service by fostering the development of MBone infrastructure and
improvements in MBone topology.  In particular:

	* Encouraging all IP providers to offer multicast IP as part of their
	  service offering.
	* Improving the alignment between the topology of the MBone and the
	  topology of the Internet, by fostering the ongoing deployment of
	  native (non-tunneled) multicast.
	* Encouraging the retirement of obsolete and sub-standard multicast
	  implementations which globally interfere with state-of-the-art
	  multicast applications, functions and features.

All sites that subscribe to the MBAT agree to provide feeds only to
other sites who meet the following conditions:

	* All multicast feeds (especially tunnels) must be coordinated with the
	  engineers of all IP infrastructure though which they pass.

	* Any tunnel which passes through any IP infrastructure owned by
	  anyone other than the owners of the tunnel endpoints is by
	  definition not aligned with the underlying IP infrastructure.  The
	  provider of that infrastructure must be given the opportunity (but
	  is not required) to interpose their own multicast infrastructure
	  into the tunnel.

	* Sites must  provide multicast feeds (tunnels or native) to all other
	  topologically near sites who comply with this MBAT and any
	  additional agreements (e.g contracts) as required by the sites.

	* Sites must keep their multicast software up to date.
	  See a separate statement for the current minimal accepted
	  software versions.

	  Note that the MBone is evolving faster than most vendors' software
	  release cycles.  In order to comply with the MBAT, it may
	  be necessary to rely on pre-product software releases.

        * Sites must adopt this MBAT and inductively apply it to
          all of their multicast feeds.

Each site has a 90 day grace period to comply with all of the terms
of this MBAT.
----------------
P.S. I will also point out that there are some extremely powerful ways
to verify MBAT compliance.

For example, PSC gets it's feed from MCI.  MCI has a database with the
precise list of IP routes which PSC is permitted to announce into the
Internet.  MCI could apply 2 tests:
1) That they do not hear non-PSC multicast routes via PSC, and
2) That they do not hear PSC multicast routes via sites other than PSC.
(If they detect exceptions, they need to also check for existence of other
interconnects.)

A tool to perform this test would greatly reduce the need for a
general mapping tool......

Cheers,
--MM--