MEETING DETAILS HAVE CHANGED. SEE LATEST DETAILS BELOW.
The MBONE Deployment (mboned) Working Group will hold
a virtual interim meeting on 2020-04-21 from 09:00 to 11:00 America/Los_Angeles
(16:00 to 18:00 UTC).
Agenda:
IETF 107/Virtual Interim
MBONED Agenda
Tues, Apr 21, 2020
9-11AM PDT
The MBONE Deployment (mboned) Working Group will hold
a virtual interim meeting on 2020-04-21 from 09:00 to 11:00 America/Los_Angeles.
Agenda:
Would like to meet jointly with PIM WG.
Information about remote participation:
Remote participation information will be obtained at the time of approval
The MBONE Deployment (mboned) working group in the Operations and
Management Area of the IETF has been rechartered. For additional
information please contact the Area Directors or the WG Chairs.
MBONE Deployment (mboned)
Current Status: Active WG
The MBONE Deployment (mboned) working group in the Operations and
Management Area of the IETF is undergoing rechartering. The IESG has not
made any determination yet. The following draft charter was submitted,
and is provided for informational purposes only. Please send your
comments to the IESG
churning bits around that almost nobody would ever read.
Pre-emptive flood fill is an 'interesting' strategy to say the least.
Many ISPs no longer support it. Comcast charges extra.
I think that the reasonable question to ask here is 'does MBONE have a
future?' If I was asked to design a new media
On Sep 15, 2005, at 7:34 PM, Hallam-Baker, Phillip wrote:
Sure bittorrent is probably not great design by many standards.
For the record, I think bittorrent is a superb design, especially
when seen as a first cut. It will improve. -Tim
___
Behalf Of John Kristoff
What is interesting is that these numbers haven't moved all
that much over the past few years. Multicast deployment has
peaked, but one might consider 10% (using address coverage as
one measure) to be pretty widely deployed.
Does MBONE work through any NAT box
On Thu, 15 Sep 2005, Hallam-Baker, Phillip wrote:
Does MBONE work through any NAT box on the planet?
I can't imagine bothering to download a program if there is less than a
10% chance it will work for me.
A communication program by definition needs two sites so the probability
of it working
, you need a system with the following requirements:
- A machine with Windows 98 or later, Linux, or Mac OS X
- You need to have a DSL, Cable Modem, or better connection (you do *not*
need mbone to view this event)
Also, to chat on IRC:
server: irc.freenode.net
chatroom: #ESM
Thanks!
David Murray
, you need a system with the following requirements:
- A machine with Windows 98 or later, Linux, or Mac OS X
- You need to have a DSL, Cable Modem, or better connection (you do *not*
need mbone to view this event)
Also, to chat on IRC:
server: irc.freenode.net
chatroom: #ESM
Thanks!
David Murray
Ole didn't say Realplayer supports Multicast. He is asking why we can't
use Real stream (or something along that line) instead.
FYI, I didnt get mbone since 1995 when I stop working for an ISP. I have
managed to get any of my current ISPs to get it either. It is time we
have to admit mbone
[EMAIL PROTECTED] (James Seng) writes:
...
FYI, I didnt get mbone since 1995 when I stop working for an ISP. I have
managed to get any of my current ISPs to get it either. It is time we
have to admit mbone is not going mainstream.
today shep reminded me that we (shepfarm and isc
Just a pov.
I love MBONE. I see no reason not to try and have it.
for APNIC member meetings we decided to go with Quicktime RTSP: and SDP: url
encoded streams. they worked well. one onsite, one offsite. avoid congestion.
they have really bad scaling for hundreds of people. but lets
On 4-mrt-04, at 6:14, Joel Jaeggli wrote:
There's a reasonable cross-section of clients for most platforms the
supports a set of mostly interoperable codecs and transports. It is
possible to source with real/darwin streaming server/videolan a source
that will be visbile to users of
On 4-mrt-04, at 2:44, Hallam-Baker, Phillip wrote:
In case you had not noticed there are now tens of millions of NAT
devices in use. End users are not going to pay $10 per month for
an extra IP address when they can connect unlimited numbers of
devices to the net using a $40 NAT box.
Sounds like
On Wed, 3 Mar 2004, Ole Jacobsen wrote:
Paul,
This is simply silly.
What you are saying is that for religious reasons you are unwilling to use
FREE and widely used tools in order to help us develop our own.
Next thing you'll be telling me PDF is a bad thing.
If you want the IETF to
Sounds like a conspiracy... ISPs charging orders of magnitude
more than
cost for additional addresses forcing people to use NAT.
Its called a monopoly.
There are good reasons why ISPs are encouraging their customers
to use NAT, they provide a weak firewall capability and that
in turn
From: Hallam-Baker, Phillip [EMAIL PROTECTED]
I am generally in agreement with your comments, but I have a few quibbles:
NAT is the big bad dog here, that is what breaks the end to end
connectivity.
The core architecture is NOT end-to-end, that is a political shiboleth
From: Hallam-Baker, Phillip [EMAIL PROTECTED]
Oh, one other thing I wanted to rant about:
I don't know of any serious security professionals who now claim that
firewalls are bogus or that they will go away as the myth has it.
Perimeter security is here to stay.
Perimeter
A nit, perhaps, but:
On Wed, 2004-03-03 at 20:17 -0800, Ole Jacobsen wrote:
..Note that Real
Player is available for multiple platforms for free, ..
The Linux version, last I tried [8.0.3.412], didn't include support for
multicast.
signature.asc
Description: This is a digitally signed
Perimeter security is brittle, inflexible, complex security.
You have to have
understanding of the semantics of an application at the
perimeter to check
whether the operation is allowed - which is bad so many ways
I don't feel
like listing them all.
It is only useful in my view if you
At 09:51 PM 3/3/2004, Joel Jaeggli wrote:
On Wed, 3 Mar 2004, Ole Jacobsen wrote:
begin naive question
Apart from the eating our own dogfood bit ...
Most other Internet events I attend, or follow remotely, use Real
audio/video, or sometimes Windows Media Player.
Can anyone tell me if
On 4-mrt-04, at 14:42, Hallam-Baker, Phillip wrote:
There are good reasons why ISPs are encouraging their customers
to use NAT, they provide a weak firewall capability and that
in turn significantly reduces exposure to being hacked which
in turn reduces the cost of chasing zombie machines.
Hm,
Or are you referring to the issue that some client/server type
interactions are broken when the client is behind NAT? This should
probably be fixable in most cases (I wouldn't call updating huge
installed bases trivial though), but that still leaves the
applications
and protocols that
On the economic front, there have been offers, at least from me, to PAY for
remote attendance. Let's face it, I'd have been happy to pay $500 to have
access to all WG sessions and plenaries via Real Player or other Unicast
mechanism in Seoul. There's just no way my company can afford the travel
Right, but multicast appears to be a large part of the problem.
I know this is heresy, but good engineers are usually able to use
available tools. It is possible to use the handle of a screwdriver to hit
the head of nail and drive it into the wall --- when you don't have a
hammer.
Now, it was a
FWIW, I tried to participate in a couple of WG meetings this week. I
had to go to work to get multicast access - efforts to set up a tunnel
to my home failed (partially because there wasn't any obvious way to try
it out in advance of the actual meeting).
Even when I could get multicast access,
Hi,
I'd like to watch the MARID BOF on mbone,
but unfortunately my IP provider does not
support multicast.
Can anyone give me a hint about where to get
an mbone tunneling access point?
regards
Hadmut
On Wed, Mar 03, 2004 at 04:18:42PM -0500, Joe Abley wrote:
If you find an answer, telling this list would be good.
In the past the answer has been you don't, often coupled with
enthusiastic statements about the mbone being in full production, and
tunnels no longer being necessary
On Wednesday, March 3, 2004, at 04:18 PM, Joe Abley wrote:
In the past the answer has been you don't, often coupled with
enthusiastic statements about the mbone being in full production, and
tunnels no longer being necessary.
I contacted my ISP last week about getting multicast routing
- Original Message -
From: Melinda Shore [EMAIL PROTECTED]
To: Joe Abley [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Sent: Thursday, March 04, 2004 6:54 AM
Subject: Re: MBONE access?
On Wednesday, March 3, 2004, at 04:18 PM, Joe Abley wrote:
In the past the answer has been you don't, often coupled
On 3-mrt-04, at 22:54, Melinda Shore wrote:
BTW, the only multicast stream working during last night's plenary
was the MPEG-1 one, and because of the high bit rate it was very lossy.
The other, lower bitrate streams weren't working and the guy running
the service kind of blew me off (and I quote:
On Wed, 3 Mar 2004, Melinda Shore wrote:
BTW, the only multicast stream working during last night's plenary
was the MPEG-1 one, and because of the high bit rate it was very lossy.
The other, lower bitrate streams weren't working and the guy running
the service kind of blew me off (and I
I'm all for eating our own dog food, but IMO workable remote
access is more
important.
The point about eating the dog food is so that you improve it
to the point where it is acceptable.
I think it is time to accept that the MBONE technology is
fatally flawed and is not going to be deployable
Equally flawed and useless are the H.323 protocols that do not
tunnel through NAT or even work with a firewall in a remotely
acceptable fashion.
NAT is the big bad dog here, that is what breaks the
end to end connectivity. restart NAT war /
In case you had not noticed there are now
Massar' [EMAIL PROTECTED]; Hallam-Baker, Phillip [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Sent: Thursday, March 04, 2004 10:44 AM
Subject: RE: MBONE access?
Equally flawed and useless are the H.323 protocols that do not
tunnel through NAT or even work with a firewall
begin naive question
Apart from the eating our own dogfood bit ...
Most other Internet events I attend, or follow remotely, use Real
audio/video, or sometimes Windows Media Player.
Can anyone tell me if there are any TECHNICAL reasons why we can't
do this for the IETF meetings?
Ole
Ole J.
PALET MARTINEZ [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Sent: Thursday, March 04, 2004 11:30 AM
Subject: Re: MBONE access?
begin naive question
Apart from the eating our own dogfood bit ...
Most other Internet events I attend, or follow remotely, use Real
audio/video, or sometimes Windows
In message [EMAIL PROTECTED], Ole Jacobsen wr
ites:
begin naive question
Apart from the eating our own dogfood bit ...
Most other Internet events I attend, or follow remotely, use Real
audio/video, or sometimes Windows Media Player.
Can anyone tell me if there are any TECHNICAL reasons why we
On Wed, 3 Mar 2004, Hallam-Baker, Phillip wrote:
I'm all for eating our own dog food, but IMO workable remote
access is more
important.
The point about eating the dog food is so that you improve it
to the point where it is acceptable.
I think it is time to accept that the MBONE
Actually, the use of Windows Media Player is quite rare for the events I
am talking about, Real is probably used in 90% of them, I only mentioned
the other one because it does appear from time to time. Note that Real
Player is available for multiple platforms for free, and so is Windows
Media
Paul,
This is simply silly.
What you are saying is that for religious reasons you are unwilling to use
FREE and widely used tools in order to help us develop our own.
Next thing you'll be telling me PDF is a bad thing.
If you want the IETF to be a place where more people can participate you
.
The point about eating the dog food is so that you improve it
to the point where it is acceptable.
I think it is time to accept that the MBONE technology is
fatally flawed and is not going to be deployable.
There is nothing wrong with Mbone, per se--though, as someone mentioned,
it might
I think it is time to accept that the MBONE technology is
fatally flawed and is not going to be deployable.
There is nothing wrong with Mbone, per se--though, as someone mentioned,
it might be nice to have better codecs. The problem is that multicast is
flawed, and not going to be globally
What you are saying is that for religious reasons you are unwilling to
use FREE and widely used tools in order to help us develop our own.
well, actually, that's not what i said at all.
Next thing you'll be telling me PDF is a bad thing.
and no, that won't be the next thing i'll tell you.
On Wed, 3 Mar 2004, Ole Jacobsen wrote:
What you are saying is that for religious reasons you are unwilling to use
FREE and widely used tools in order to help us develop our own.
The focus in clients is a little misguided...
There's a reasonable cross-section of clients for most platforms
On Wed, 3 Mar 2004, Hallam-Baker, Phillip wrote:
If the IETF put a tenth the effort that has gone into multicast into
fixing the spam problem, or something the end users (not geeks) care
about...
Comparing one apparently intractable problem to another doesn't seem
productive or useful.
Paul,
As has been pointed out, this is a little more complicated than just
the choice of client, in particular multicast is not widely available
to the average Internet user.
But I still find it ironic that I can watch a webcast from an ICANN
meeting but I am unable to do the same for an IETF
As has been pointed out, this is a little more complicated than just
the choice of client, in particular multicast is not widely available
to the average Internet user.
that could be punctuated very differently and thus become even more factual.
But I still find it ironic that I can watch a
:45 AM
Subject: Re: MBONE access?
In message [EMAIL PROTECTED], Ole Jacobsen wr
ites:
begin naive question
Apart from the eating our own dogfood bit ...
Most other Internet events I attend, or follow remotely, use Real
audio/video, or sometimes Windows Media Player.
Can anyone tell me
PROTECTED]; [EMAIL PROTECTED]
Sent: Thursday, March 04, 2004 1:17 PM
Subject: Re: MBONE access?
Actually, the use of Windows Media Player is quite rare for the events I
am talking about, Real is probably used in 90% of them, I only mentioned
the other one because it does appear from time
On Wed, 3 Mar 2004, Hallam-Baker, Phillip wrote:
If the IETF put a tenth the effort that has gone into multicast into
fixing the spam problem, or something the end users (not geeks) care
about...
Hmm. That would be real work... ;-) ;-)
Equally flawed and useless are the H.323 protocols
Ole,
the multicast services are provided by the UOregon team supported by a
grant from Cisco (+ some support from ISOC via the IETF Chair's fund).
This grant is in its final year, and the end of the grant is a convenient
time to stop and reconsider exactly what services we (the IETF community)
Hi,
just a summary of my last night's (german time) experiences:
- mbone is not available at most (german) provider's
- there are no tunnel providers anymore
- even those who had mbone access couldn't receive
the IETF stream
- The oregon multicast crew took several hours to
answer
gm From: Gary E. Miller [mailto:[EMAIL PROTECTED]]
gm Sent: Monday, September 23, 2002 2:24 PM
gm Here is a link to how it is done:
gm http://dhar.homelinux.com/dhar/downloads/Sniffers.pdf
gm Gary E. Miller Rellim 20340 Empire Blvd, Suite E-3, Bend, OR 97701
gm
Gary E. Miller wrote:
Yo Joe!
On Fri, 13 Sep 2002, Joe Touch wrote:
Without a dobut you are right, though I think the degree of difference is
awful small. Through hosts with root on switches or through wireless into
the mix and you are back to being roughly equivalent.
Hosts with root
Gary E. Miller wrote:
Yo Joe!
On Mon, 23 Sep 2002, Joe Touch wrote:
root has no problem seeing adjacent UDP even on a switch. Just
overflow the arp cache or poison it.
That all presumes the switch doesn't detect this as an attack and
shutdown that link, which is an entirely reasonable
Kevin C. Almeroth wrote:
Multicast is necessarily a LOT weaker:
1) I can get a copy of packets by normal operation
(join a group). there is no equivalent for UDP,
notably for paths that aren't shared.
Again, not in all cases. You over-simplify the effectiveness of scoping.
Joe Touch wrote:
Gary E. Miller wrote:
...
Barring that, please name ONE switch, or cite ONE credible reference
source, where arpspoofing is prevented at the switch by any means short
of harcoding the MACs.
Practical != economical. Further, there are MACs which are hardcoded
(i.e. to
Matt Crawford wrote:
Barring that, please name ONE switch, or cite ONE credible reference
source, where arpspoofing is prevented at the switch by any means short
of harcoding the MACs.
Never mind, even hard-coding the MACs to the right ports doesn't
solve the problem. Eve on port X can keep
Kevin C. Almeroth wrote:
It only requires being on a non-IGMP'd switch or a hub; at that point,
you can snoop the traffic and see any packet going to any multicast group.
It's much harder to snoop UDP; for non-broadcast, you'd have to be
in-line (on the wire, effectively) or on a hub. While
Multicast is necessarily a LOT weaker:
1) I can get a copy of packets by normal operation
(join a group). there is no equivalent for UDP,
notably for paths that aren't shared.
Again, not in all cases. You over-simplify the effectiveness of scoping.
You can't have it both
Kevin C. Almeroth wrote:
Multicast is necessarily a LOT weaker:
1) I can get a copy of packets by normal operation
(join a group). there is no equivalent for UDP,
notably for paths that aren't shared.
Again, not in all cases. You over-simplify the effectiveness of scoping.
Yo Joe!
On Fri, 13 Sep 2002, Joe Touch wrote:
Without a dobut you are right, though I think the degree of difference is
awful small. Through hosts with root on switches or through wireless into
the mix and you are back to being roughly equivalent.
Hosts with root can't snoop anything
Yo Joe!
On Mon, 23 Sep 2002, Joe Touch wrote:
root has no problem seeing adjacent UDP even on a switch. Just
overflow the arp cache or poison it.
That all presumes the switch doesn't detect this as an attack and
shutdown that link, which is an entirely reasonable reaction.
resonable
On Fri, 13 Sep 2002 08:06:25 PDT, Joe Touch said:
Hosts with root can't snoop anything but broadcast UDP on switches
unless the switch is configurable; many switches aren't.
Unfortunately, this isn't actually true - unless you've nailed down the
switch with a hardwired MAC-address-per-port
Barring that, please name ONE switch, or cite ONE credible reference
source, where arpspoofing is prevented at the switch by any means short
of harcoding the MACs.
Never mind, even hard-coding the MACs to the right ports doesn't
solve the problem. Eve on port X can keep up a steady stream of
Yo Joe!
On Mon, 23 Sep 2002, Joe Touch wrote:
PS - as I also raised on private email earlier, some ISPs definitely
hardcode which MAC can attach to a port (i.e., they lock on the first
one that gets there, and prevent subsequent ones until there's an
override).
Specific case: Santa
Date:Mon, 23 Sep 2002 17:58:21 -0500
From:Matt Crawford [EMAIL PROTECTED]
Message-ID: [EMAIL PROTECTED]
| Eve on port X can keep up a steady stream of ARP
| replies to Alice on port Y and Bob on port Z, telling each that the
| MAC address corresponding to their
Fro the people that were interested I found:
http://www.sprintlabs.com/Department/IP-Interworking/multicast/linux-igmpv3/
Which is an alpha implementation of IGMPv3 released under GPL. No router capabilities yet... but promising...
Cheers.
Franck
the ones who have Canadian
divisions do not bother to extend it to Canada. None of them are willing to
tunnel anything anymore.
While in attendance at IETFs, in multicast enabled sessions, I've never
heard a single comment from the mbone.
According to:
http://videolab.uoregon.edu/events/ietf
Sorry, I could not find an answer or a pointer through
http://www.ietf.org/meetings/multicast.html
My provider said that it supports mbone, but only enable it on demand
for specific addresses. Therefore, could anyone please inform me the
multicast group addresses of the coming 47th
72 matches
Mail list logo
