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

[Curtis Villamizar <[e-mail]>]

In message <[e-mail]>, David Meyer writes:
> 
> 	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


Dave,

I think you've got a great list of multicast issues and mboned would
be a good place to continue with this.  My first reaction was that
this may be too complete a list and you should concentrate on the
subset of the items that are deemed most important to or considered
barriers to further multicast deployment.

On the original topic of multicast deployment, there were some
assertions that there is financial disincentives for a tier-1 to
deploy multicast.  I have a few comments on that.  First, if multicast
is not offerred and it happens anyway through unicast replication,
then adding multicast does remove a burden from the core.  If
replication is distributed anyway and not laid out according to
topology (p2p stuff, for example), then the savings is greater.  OTOH
if some sort of service is essentially broadcast as multiple unicast
and is huge in volume, lack of multicast provides a visible revenue
source for the provider, the fat pipe to the source.  It was this
(possibly flawed) logic that has motivated some commercial multicast
service where only select participants could be senders and charges
for this priviledge were quite high (high enough in the one case I
have in mind that service penetration was minimal).  Somewhere in the
middle is the multiparty conference, with more than two or three but
no more than a dozen or so participants.  Unicast replication at a
single site can be viable for a small number of satelite sites, but
for larger conferences can become infeasible.  It is these many
smaller scale multicast groups that it would be good to provide on the
same flat rate basis as today's unicast, while avoiding carrying large
scale broadcasts for free.

The topic of counting leaf nodes came up.  For a tier-1 provider, it
is sufficient and perhaps more relevant to know only the number of
exit points from that provider that a sender is reaching.  How much
branching occurs beyond the tier-1 provider is inconsequential to the
tier-1 provider.  The good news is that collection this information is
something that can be confined to the single provider if protocol
support existed to do so.  From the provider's business standpoint, it
may be sufficient to limit bandwidth and this bounds (number of exit
points to the provider) for lower service levels including any default
(comes without charge or a fixed extra) flat rate service and offer a
higher service level in which the sender bandwidth and exit point
count limits are set higher.  This would allow flat rate low usage
multicast such as small conferencing but still provide the means to
generate revenues appropriate to higher bandwidth and wider spread
multicast, such as VOD.

Curtis



> ---
> 
>         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
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/routing-discussion
> 

_______________________________________________
routing-discussion mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/routing-discussion