Internet Multicast Documentation, Oversight, and Coordination (IMDOC)?

David Meyer <dmm@1-4-5.net> Thu, 10 July 2003 14:57 UTC

Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05828 for <routing-discussion-archive@lists.ietf.org>; Thu, 10 Jul 2003 10:57:34 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19acqz-0006w8-Kw; Thu, 10 Jul 2003 10:57:01 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19acqX-0006vP-EI for routing-discussion@optimus.ietf.org; Thu, 10 Jul 2003 10:56:33 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05753 for <routing-discussion@ietf.org>; Thu, 10 Jul 2003 10:56:27 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19acqU-0003ca-00 for routing-discussion@ietf.org; Thu, 10 Jul 2003 10:56:30 -0400
Received: from sith.maoz.com ([205.167.76.10]) by ietf-mx with esmtp (Exim 4.12) id 19acqT-0003cG-00 for routing-discussion@ietf.org; Thu, 10 Jul 2003 10:56:30 -0400
Received: (from dmm@localhost) by sith.maoz.com (8.12.9/8.12.9) id h6AEuCOM017902; Thu, 10 Jul 2003 07:56:12 -0700
From: David Meyer <dmm@1-4-5.net>
To: mboned@network-services.uoregon.edu
Cc: wg-multicast@internet2.edu, mtp@shepfarm.com, routing-discussion@ietf.org
Subject: Internet Multicast Documentation, Oversight, and Coordination (IMDOC)?
Message-ID: <20030710075612.A17872@1-4-5.net>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
User-Agent: Mutt/1.2.5.1i
X-public-key: http://www.maoz.com/~dmm/public-key.asc
X-philosophy: "I just had to let it go" -- John Lennon
Sender: routing-discussion-admin@ietf.org
Errors-To: routing-discussion-admin@ietf.org
X-BeenThere: routing-discussion@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/routing-discussion>, <mailto:routing-discussion-request@ietf.org?subject=unsubscribe>
List-Id: Routing Area General mailing list <routing-discussion.ietf.org>
List-Post: <mailto:routing-discussion@ietf.org>
List-Help: <mailto:routing-discussion-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/routing-discussion>, <mailto:routing-discussion-request@ietf.org?subject=subscribe>
List-Archive: <https://www1.ietf.org/pipermail/routing-discussion/>
Date: Thu, 10 Jul 2003 07:56:12 -0700

	Here's something I've been discussing with the ADs
	(and hoping to learn the lessons of the MADDOGs
	"experience").  

	I put it on the mboned agenda, so we can also discuss this
	there. As always, comments greatly appreciated.

	Dave

---

        This note proposes the creation the Internet Multicast
	Documentation, Oversight, and Coordination (IMDOC)
	function. The IMDOC, residing in mboned, will serve as
	the locus of documentation, cross-coordination, and
	oversight function for the muticast activity in the IETF
	at large, and will create two crucial missing pieces of
	the multicast puzzle: (i). A comprehensive IETF multicast
	framework document, and (ii). the Internet Multicast
	Reference Architecture (IMRA). Both are discussed briefly
	below.

	IMDOC documents will be published in the mboned working
	group and will:

	(i).	Provide a comprehensive framework document. This
		document will cover all multicast issues under
		consideration within IETF, and will provide a
		systematic way determining when new working
		groups are needed. 

	(ii).	Provide the Internet Multicast Reference
		Architecture document. Importantly, the IMRA will
		cover both intra and inter-domain multicast
		architectures.  

	(iii).	Outline domain-specific problem spaces (for
		example, as was done in mboned with
		draft-ietf-mboned-imrp-some-issues-01.txt).   

        (iv).	Preserve the archival knowledge of what has
		worked and what hasn't, and why. This knowledge
		is currently folklore (or very ad hoc at best).   
 
	The IMDOC coordination and oversight functions will be
	organized by the mboned working group in conjunction with
	the appropriate working group chairs and area directors.

	The following list of areas (which are in scope for the
	IMDOC) is not intended to exhaustive, but rather to
	illustrate the requirement for oversight and
	coordination:   

	(i).	Addressing

		Including dynamic address assignment (malloc,
		etc), IANA issues (IPv4 and IPv6, e.g. RFC
		3171/BCP51), scoping mechanisms and
		methodologies, multicast address derivation
		(e.g. RFCs 2770 and 3138) and Unicast Based
		Addresses (IPv6).    

	(ii).	Source discovery

		Including in-band source discovery methods such as
		BSR (which touches pim) and embedded RP (which
		touches ipv6)), and out-of-band mechanisms such
		as proposed for SSM (which touches ssm), and
		their associated applications and APIs (which
		touches mmusic). Examples of documents in this
		area include RFC 3569.

	(iii).	Security    

		Including key exchange (which touches msec), and
		data encryption (which touches ipsec), as well as
		the general problem of a security architecture
		for multicast.

	(iv).	L2 aliasing

		For example, 802.x (which touches ipoib and
		others), IGMP/MLD Snooping, CGMP, PIM Snooping,
		and RGMP (which touches on MAGMA).

	(v).	Routing

                For example, BGP4+ and associated extensions
		which effect multicast, Multi-Topology IGPs. 

	(vi).	Forwarding

		Including discussions on all PIM forwarding
		modes, DVMPR, CBT, etc.  Also includes issues
		associated with RP mapping approached for PIM-SM,
		and general discussions on ASM vs. SSM models
		(covering bidirectional and unidirectional status
		as well)

	(vii).	Reliable Transport

		Including discussions on RMT generated building
		blocks as well as issues associated with
		PGM. Covers FEC, CC, etc. 

	(viii).	Session Control

		Will include issues associated with source and
		receiver control, example MSNIP, RTS/CTS issues,
		floor-control, etc.

	(ix).	Application Layer Issues

		Examples include BCPs for writing multicast
		applications (e.g. RFC 3170), discussions on
		default address use, traffic patterns (example
		implications of bursty traffic, low frequency
		traffic), and APIs for SSM.

	(x).	Tunneling
		
		Including any potential new dynamic tunneling
		proposals which come from Last Mile Multicast, etc.

	(xi).	VPN
		
		Both L2 (pwe3, l2vpn), and L3 (ppvpn, l3vpn)

        

	


_______________________________________________
routing-discussion mailing list
routing-discussion@ietf.org
https://www1.ietf.org/mailman/listinfo/routing-discussion