Subject: Re: mboned: BGMP & DVMRP status Q.

From: Bill Fenner <[email-masked]>
Date: Tue, 23 Mar 2004 11:37:39 -0800

>I was wondering what kind of discussion has preceeded these
>decisions, as and what the large group of people is that is in
>agreement with it.

The BGMP status was a bug in the presentation; it is indeed planning
to go to Informational (although the only feedback on the BGMP WG
mailing list was that it should go Experimental instead).

The DVMRP status discussion happened on the IDMR WG list.  As far as
I know, nothing has changed about DVMRP being an acceptable routing
protocol for small networks.  It achieves not insignificant optimization
by combining tree buidling and route dissemination.

  Bill

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

---

From: Bill Nickless <[email-masked]>
Date: Wed, 24 Mar 2004 14:10:07 -0600

(Resent to get through the various mail filters)

At 10:52 AM 3/24/2004 -0800, John Zwiebel wrote:

>It -might- be a good idea to suggest some number of participants
>in a conference (or whatever kind of application) under which
>unicast should be the preferred transport method.
>
>It would be "fine" with me if everything was multicast (in fact
>I'd probably prefer it) but that would interfere with the deployment
>of some applications.
>
>I'm looking for a way of suggesting to the user that "for right now,
>until certain multicast questions are answered and deployment established,
>you should use unicast with a view toward transitioning to multicast
>as each of these barriers are removed.
>
>It makes the app developers problem more difficult to solve, but
>provides a realistic roadmap with which they can make informed decisions.

This is not inconsistent with an end-to-end automatic tunneling model, 
designed in such a way that the internetwork can optimize the transport 
when the capability is available or desired.

What do I mean?

Consider the existing SSM model.  Multicast traffic is requested by 
interested receivers, and is identified by the (S,G) (Source,Group) 
addresses.  This receiver request effectively "grafts" the receiver onto a 
source-rooted distribution tree for the (S,G).  Once the distribution tree 
is created, traffic flows from the source to each interested receiver.

Such a process could be implemented entirely by hosts, without any explicit 
network support.  The distribution tree would still be rooted at the 
source, but the tree would look more like a star.  In other words, for 
small groups the source host itself would receive the receiver traffic 
requests and handle the replication.  Each receiver would get a copy of the 
requested traffic over the existing unicast infrastructure.

Explicit network support could be deployed incrementally.  If the network 
element (router?) was prepared to do multicast replication, it would 
intercept any receiver traffic requests and "bundle" them together as they 
go towards the source.  Likewise, as the traffic comes from the source 
towards interested receivers, the network element would handle replication.

===
Bill Nickless    http://www.mcs.anl.gov/people/nickless      +1 630 252 7390
PGP: 021D EB98 03B3 2E83 3D71  0397 251D 819A D0BE EA32 [email-masked]

---

From: "Manfredi, Albert E" <[email-masked]>
Date: Wed, 24 Mar 2004 15:31:32 -0500

> From: Toerless Eckert [mailto:[email-masked]]

> We would probably
> say that using multicast offhand is fine for this size of 
> receivers, but
> if 49,999 are in the USA and one lonely guy in mongolia wants 
> to watch it too,
> you'd probably argue that the 10 hop branch down to mongolia 
> might not want 
> to waste a state on that.

But you wouldn't begrudge a unicast connection to that guy in Mongolia, so why conceptually should multicast be different? Seems like a PIM-SM type of model should be capable of supporting the 50K-1 US users and one Mongolian user, or vice versa?

The trick is to locate the rendezvous point correctly, or to allow for multiple RPs when the multicast tree calls for them? If two large clusters of users are spread far apart, seems like two RPs and a tunnel between them makes sense. But done dynamically, maybe using topology info already available to multicast routers.

Bert

---

From: "Manfredi, Albert E" <[email-masked]>
Date: Wed, 24 Mar 2004 15:31:32 -0500

Bert

---

From: Bill Nickless <[email-masked]>
Date: Wed, 24 Mar 2004 14:10:07 -0600

What do I mean?

===

---

From: "Manfredi, Albert E" <[email-masked]>
Date: Wed, 31 Mar 2004 13:03:26 -0500

Masataka Ohta wrote:

> Another major wrongness is in IGMP, which should be independent
> from multicast routing protocols but is revised as new multicast
> routing protocols are invented.

But IGMP is independent. I guess you're referring to v3, which adds the source address filtering capability. But that has nothing to do with routing. It has to do with providing the necessary extra specificity when SSM is available.

Bert

---

From: "Manfredi, Albert E" <[email-masked]>
Date: Wed, 31 Mar 2004 13:03:26 -0500

Bert