Subject: Major barrier to MBone

From: Yves Lepage <[email-masked]>
Date: Tue, 20 May 97 08:35:42 -0400

Hello,

Just a thought, discard it if you feel I shouldn't send mail like this early
in the morning.

Mbone is a very promising technology. However, it is still little known and I suspect that
a lot of people would like to benefit from it but they simply can't.

The reason would be that there is a major barrier to entering the Mbone and this barrier
is what makes the technology so great: multicasting.

Almost nobody routes multicast traffic natively still and while the Mbone core may be doing it,
end points still use tunnels to connect. However, tunnels are complicated to setup. You have
to send mail to the mbone list, hoping for an answer. If the answer doesn't come, you're in the
dark. When the answer comes, it is often a generic one like: "hmmm, try talking to Sprint".

For the mere mortal, a sentence like this means going through support services at the NSP
and explain what MBone is to 12,012 people before (and if) you get to someone who actually can
help you. Not the NSP's fault but today's support services are procedures based.

The real fix to thi will be IPv6, but IPv6 is still as much fiction as teleportation is
(yes, there are implementations, I know but routing it properly on the whole planet is not quite  
done yet).

To remedy to this situation, why not consider automatic tunnel setup?

The scenario would be:

An end point wants to get on the MBone. They send mail to the MBone list about it and
they get " try talking to Sprint about it". The end point sets up an mrouted (Unix or router based)
and point it to Mbone.sprint.net, where the mcast router there does some sanity
checking to see if it would be appropriate to actually setup this tunnel. If not,
informative/error messages could be returned to the end point. Such messages could be:

"Sorry, there is already another mrouter that is closer to you netwise. It is: mbone.isp.net,  
talk to them"

or

"Sorry, the path from you to me already crosses MCI's backbone, talk to MCI"

and other similar messages.

The end point would then point its tunnel to the new location and get more information or the
tunnel would actually be valid.

Ideally, this would have to be in the multicast routing protocols but since it is unlikely
that Internet standards are going to change in a timely fashion, and then implemented and then
be widely used, This auto-setup facility could be implemented in an "MBone tunnel configuration
server", which could even be accessible with a web interface.

This server would do all the necessary checking to point the end-point to the
Mbone router closest to them (netwise).

Of course, it means that an automatic tunnel setup mechanism would have to run
on all major mcast routers so the tunnels can be established without human intervention.

This mechanism could even allow for automatic fixing of assymetric metrics.

I think this is a good idea and it would do the Mbone community if it was implemented. At this
point, it is only an idea, more polishing would be required.

I want to add that I am only an idea provider today, I don't actually plan to
implement this.

Trying to help,
Yves Lepage

---

From: Petri Helenius <[email-masked]>
Date: Tue, 20 May 1997 16:50:35 +0300 (EEST)

> Just a thought, discard it if you feel I shouldn't send mail like this early
I think scarce resources are better spent on developing and
implementing an inter domain multicast routing system, not extending a
currently overgrowded global-distance-vector based system any
further than neccessary.

Pete

---

From: Jon Crowcroft <[email-masked]>
Date: Tue, 20 May 1997 14:53:04 +0100

>on all major mcast routers so the tunnels can be established without human intervention.
 
if yo uhad integrated unicast/multicast, this would be easy, but thats
like saying that a journey started at the destination is short:-)

hey - but what about this:

register a small number of "core" mbone tunnel routers.....these form
a well known core list...

then anyone simply runs a mbone tunnel set up protocol as follows.

1/ send a (as yet unspecified IGMP type) message from your tunnel end point,   
to 1 (try a 2nd or 3rd if you timeout) from one of the well known core
routers unicast addrs, asking for a tunnel end point to be found....

2/ the mbone tunnel endpoint that receives this runs a traceroute back
to the source IP address of the request and gets a list of ip
addresses on the way.....

3/it examines the list of routers and metrics in the DVMRP (or
underlying unicast table if its PIM), to see  if any are in the
traceroute, and if they are, forwards the request to one of those.....

which then goes to step 2, and runs it and 3 again (this is to get
across PIM/DVMRP/MOSPF clouds.....)

when there are no mbone routers listed in the routing table that
appear in a traceroute, then we stop, and run a tunnel setup protocol,
add the new requestor to a database, and so on....

 >I want to add that I am only an idea provider today, I don't actually plan to

 jon

---

From: John Meylor <[email-masked]>
Date: Tue, 20 May 1997 09:29:57 -0700

> currently overgrowded global-distance-vector based system any

I'd like to second Pete's point. Le's not defer resources
to fixing an interim problem, but rather getting native multicast
established as a ubiquitous and co-resident service with unicast.

- John

---

From: Dino Farinacci <[email-masked]>
Date: Tue, 20 May 1997 10:14:45 -0700

>> established as a ubiquitous and co-resident service with unicast.

    Make that another ditto.

Dino

---

From: Dino Farinacci <[email-masked]>
Date: Tue, 20 May 1997 10:55:42 -0700

>> what if solving this problem leads to better mbone firewall
>> solutions?

    Wonderful, but don't hold your breath.

Dino

---

From: Jon Crowcroft <[email-masked]>
Date: Tue, 20 May 1997 18:36:21 +0100

>>> I'd like to second Pete's point. Le's not defer resources
                   
	i think you mean divert...

 jon

---

From: "Louis A. Mamakos" <[email-masked]>
Date: Tue, 20 May 1997 14:14:32 -0400

> established as a ubiquitous and co-resident service with unicast.

I think the real problem isn't native or co-resident multicast; it's lack
of inter-domain routing protocols for multicast.  Having or not having
congruent multicast and unicast topologies is a completely different issue.
It may, in fact, be a non-issue hidden within a multicast routing domain.

Louis Mamakos

---

From: John Meylor <[email-masked]>
Date: Tue, 20 May 1997 12:18:15 -0700

> It may, in fact, be a non-issue hidden within a multicast routing domain.

  Agreed that our efforts should be focused on establishing an
idmr which will allow individual ISPs deal with their internal 
mrouting topology independently.   But lack of native mrouting
interfaces on a shared interexchange point (FIX/MAE-West eg.)
will make deployment of idmr problematic at best.
  Yes the issues are different, but I believe a successful
interdomain solution will need to address both. 

- John

---

From: Petri Helenius <[email-masked]>
Date: Tue, 20 May 1997 22:21:50 +0300 (EEST)

> what if solving this problem leads to better mbone firewall
I would trade 'better-than-packet-filter' "MBone firewalls" in an
instant for interdomain multicast routing.

And if you're really into it, rtptrans can be used to do 'application
level' MBone firewalls. If you really want to.

Pete

---

From: Petri Helenius <[email-masked]>
Date: Tue, 20 May 1997 22:33:51 +0300 (EEST)

> interdomain solution will need to address both. 
But we _do_ have specifications for transmission of multicast
datagrams over all media we do currently have. The IDMRP has to
just provide information to populate the OIF-list and control
loops. (and the latter may just be simple RPF-check)

Pete

---

From: John Meylor <[email-masked]>
Date: Tue, 20 May 1997 15:12:32 -0700

> loops. (and the latter may just be simple RPF-check)

I'm not saying the specs are not available, by "lack of native
routing interfaces" I mean "lack of participation by resident
ISPs to use native multicast" at places where idmr will likely
be implemented.  Getting back to the original thread: we should
focus on idmr, not tunneling, and proactively move away from
tunneling if this expedites the task of deploying idmr.

---

From: Petri Helenius <[email-masked]>
Date: Wed, 21 May 1997 08:16:18 +0300 (EEST)

> tunneling if this expedites the task of deploying idmr.

Or as Loius stated, this is an internal matter to the NSP, which
should not be of external concern. Like it's not whether you run OSPF,
IS-IS or even EIGRP within your network.

Pete