Subject: [MBONED] MBONED WG Announcement!!

From: Greg Shepherd <[email-masked]>
Date: Mon, 1 Jun 2015 12:01:28 -0700

Who's listening?

We have some proposed work that showed solid support in the WG meeting but
when asked for support on the list we hear nothing. Is anyone there??

As a participant in the MBONED WG, we need your input whether you support
the work or not. We can't adopt work without support, but we can't gauge
support without any feedback.

PLEASE, somehow we need to wake MBONED out of its coma and see if there's
any life left.

So if you get this, read this AND want to participate in the WG in any
capacity, please respond to this message.

Thanks,
Chairs.

---

From: John Kristoff <[email-masked]>
Date: Mon, 1 Jun 2015 14:16:21 -0500

On Mon, 1 Jun 2015 12:01:28 -0700

> Who's listening?

Hi Greg.

> As a participant in the MBONED WG, we need your input whether you
> support the work or not. We can't adopt work without support, but we
> can't gauge support without any feedback.

While I might not actively oppose any of the items that have or might
be brought to this group, I'm also not particularly supportive of
any either.  I am starting to personally advocate to students,
colleagues and friends that it is time to seriously consider if not
outright actively dismantle any active inter-domain IP multicast and
give up on things like AMT.

My apologies to you, Lenny and any others if this is not what you
wanted to here, it is not my intention to discourage anyone from all
the years of effort and passion that has gone into this group.  I don't
think the work has been a waste, but I fear much more of it will be.

John

---

From: Greg Shepherd <[email-masked]>
Date: Mon, 1 Jun 2015 12:23:24 -0700

The first response is a derail.. :-) But that's ok, it's a response!! I
have questions below:

> give up on things like AMT.

But AMT is the first chance we've had to actually utilized mcast without
end-to-end coordination, which I feel has been our weakness for decades.
Why dismantle now that we've finally progressed it to RFC status?

Greg

---

From: "Manfredi, Albert E" <[email-masked]>
Date: Mon, 1 Jun 2015 20:01:15 +0000

> -----Original Message-----
> From: MBONED [mailto:[email-masked]] On Behalf Of John Kristoff

> think the work has been a waste, but I fear much more of it will be.

John pretty much echoes my thinking on this topic. In my work, and in other applications of IP multicast I see out there (e.g. TV over IPTV nets), the multicast domain remains constrained to a single administrative domain. For my work, very deliberately done this way. Wouldn't want it to be otherwise.

So this makes me less likely to become personally invested in much broader applications of IP multicast.

Bert

---

From: John Kristoff <[email-masked]>
Date: Mon, 1 Jun 2015 15:29:06 -0500

On Mon, 1 Jun 2015 12:23:24 -0700
Greg Shepherd <[email-masked]> wrote:

> The first response is a derail.. :-) But that's ok, it's a response!!

Hehe, again I know this isn't what you were hoping to hear, sorry.

> But AMT is the first chance we've had to actually utilized mcast
> without end-to-end coordination, which I feel has been our weakness
> for decades. Why dismantle now that we've finally progressed it to
> RFC status?

There actually isn't all that much to dismantle.  Practically all the
students I see now-a-days, if they have any experience whatsoever with
IP multicast, it has usually been with things like Norton Ghost. The
long running C-SPAN over IP multicast service my former colleagues at
Northwestern University ran is no longer, neither is IP multicast TV
service to the dorms (thanks Comcast).  I can't easily even tell what
the trends have been more generally since Marshall Eubanks' once helpful
status pages are now long gone (and the archives and tools are not
available, I've asked), but the numbers now appear to be lower than
there were a decade ago.  The only seemingly useful and maintained
general monitoring is the JANET beacon page, which isn't particularly
encouraging.

To answer your question, operationally I think fewer people have a
compelling reason to keep it running, and leaving it running does come
with some support cost.

We've had tunneling before.  Maybe it wasn't very good, but back then
we couldn't wait to get rid of it.  Maybe you'll forgive me for
thinking we're just trying to hard to get IP multicast widely deployed.

John

---

From: "Manfredi, Albert E" <[email-masked]>
Date: Mon, 1 Jun 2015 20:42:50 +0000

From: MBONED [mailto:[email-masked]] On Behalf Of Greg Shepherd

> for decades. Why dismantle now that we've finally progressed it to

One problem that has emerged in the last few years, from my perspective anyway, is a much increased emphasis on security. This makes any thought of interdomain IP multicast "without end to end coordination" generally a very bad thing, at least in my work.

Not to say the work should be dismantled. Just explaining why it might not apply broadly, and why you might not be getting a lot of support for it now.

Bert

---

From: joel jaeggli <[email-masked]>
Date: Mon, 1 Jun 2015 13:45:26 -0700

On 6/1/15 12:23 PM, Greg Shepherd wrote:
> On Mon, Jun 1, 2015 at 12:16 PM, John Kristoff <[email-masked]
> <mailto:[email-masked]>> wrote:
> 
>     Greg Shepherd <[email-masked] <mailto:[email-masked]>> wrote:
> 
>     > Who's listening?
> 
>     Hi Greg.
> 

IMHO I see plenty of application for AMT or AMT-like tunnels in
non-interdomain cases as well as inter domain ones. AMT  use versus any
other application is ultimately a decision on the part of origins not
the intermediate networks over which it may have to jump over.

Overall I've stopped thinking or worrying about the interdomain global
deployment of ip multicast. Interdomain ip mutlicast works fine for
interested and coordinated parities and is/will be used when it is the
appropriate technology, then we can and should do work on that protocal
suite as necessary. If you want to operate across uncoordinated networks
we have tools for that now.

>     think the work has been a waste, but I fear much more of it will be.

If there are areas of work where we have no energy or interest then we
don't have to worry about those.

>     John
> 
> 
> 
> 
> _______________________________________________
> MBONED mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mboned
>

---

From: "Williamson, Beau" <[email-masked]>
Date: Mon, 1 Jun 2015 20:57:03 +0000

Bert,

What sort of Security Functionality do you think is missing?  Remember, due to the explicit join nature of multicast, you don't have the same security issues as unicast.  You can't just "send" multicast to any old destination like you can unicast.  

Beau Williamson
CCIE #1346 R/S Emeritus
Principle Member of Technical Staff
Corporate Engineering
metroPCS/T-Mobile
Internal: 314982
Office:   469.330.4982
Mobile:   972.679.4334

-----Original Message-----
From: MBONED [mailto:[email-masked]] On Behalf Of Manfredi, Albert E
Sent: Monday, June 01, 2015 3:43 PM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [MBONED] MBONED WG Announcement!!

> for decades. Why dismantle now that we've finally progressed it to RFC 
> status?

Bert

---

From: William Atwood <[email-masked]>
Date: Mon, 01 Jun 2015 17:06:49 -0400

Beau,

I am trying to parse your statement, and coming up with two possibilities:
1) the security issues are different
2) the security issues are not severe (or are non-existent).

Since I (and my graduate students) have spent quite a bit of time
looking at multicast security and multicast access control, I hope that
you mean the first one, but I would like to understand exactly what you
intended.

  Bill

-- 
Dr. J.W. Atwood, Eng.             tel:   +1 (514) 848-2424 x3046
Distinguished Professor Emeritus  fax:   +1 (514) 848-2830
Department of Computer Science
   and Software Engineering
Concordia University EV 3.185     email:[email-masked]
1455 de Maisonneuve Blvd. West    http://users.encs.concordia.ca/~bill
Montreal, Quebec Canada H3G 1M8

---

From: "Manfredi, Albert E" <[email-masked]>
Date: Mon, 1 Jun 2015 21:09:45 +0000

> From: Williamson, Beau [mailto:[email-masked]]

> Bert,
> 
> What sort of Security Functionality do you think is missing?  Remember, due
> to the explicit join nature of multicast, you don't have the same security
> issues as unicast.  You can't just "send" multicast to any old destination
> like you can unicast.

For what I have to do, we have to make sure to prevent any host from one platform's network from being able to receive the multicasts from any other platform. When info is to be made available between these nets, it has to be very deliberately controlled. So we can't allow joining multicast groups indiscriminately, across platforms.

Causal observation of commercial ISP nets implies that they feel much the same way, although not usually for security reasons. More because each ISP net prefers to manage how they charge their clients for the bandwidth used.

Bert

---

From: "Williamson, Beau" <[email-masked]>
Date: Mon, 1 Jun 2015 21:11:08 +0000

Bill,

My intention was to understand what Security Issues you have identified.  I'm not saying there are none, just that the Security Problem space for Multicast is different than Unicast hence there are some things one doesn't have to worry with.  Of course that may mean there are other issues for Multicast that are not in the Unicast Problem Space.

Basically, I'm just trying to understand the concerns, not say there aren't any.

Beau Williamson
CCIE #1346 R/S Emeritus

-----Original Message-----
From: MBONED [mailto:[email-masked]] On Behalf Of William Atwood
Sent: Monday, June 01, 2015 4:07 PM
To: [email-masked]
Subject: Re: [MBONED] MBONED WG Announcement!!

Beau,

Since I (and my graduate students) have spent quite a bit of time looking at multicast security and multicast access control, I hope that you mean the first one, but I would like to understand exactly what you intended.

  Bill

---

From: "Williamson, Beau" <[email-masked]>
Date: Mon, 1 Jun 2015 21:16:09 +0000

Ah, ok.  Well in the cases you've outlined below, most router Vendors supply tools to control this at domain boundaries.  Some better than others but in this case, solutions do exist. 

Maybe what is needed is a Multicast Security Best Practices RFC if we don't already have such a thing (I don't remember off the top of my head).  [BTW, I'm not volunteering for this.  Just saying it might help with such concerns.]

Good discussion.  Keep your concerns coming, Bert.  I'd like to learn more about them.

Beau Williamson
CCIE #1346 R/S Emeritus

-----Original Message-----
From: Manfredi, Albert E [mailto:[email-masked]] 
Sent: Monday, June 01, 2015 4:10 PM
To: Williamson, Beau; [email-masked]
Cc: [email-masked]
Subject: RE: [MBONED] MBONED WG Announcement!!

> Bert,
> 
> What sort of Security Functionality do you think is missing?  
> Remember, due to the explicit join nature of multicast, you don't have 
> the same security issues as unicast.  You can't just "send" multicast 
> to any old destination like you can unicast.

Bert

---

From: Leonard Giuliano <[email-masked]>
Date: Thu, 4 Jun 2015 16:55:01 -0700

The history of networking suggests a tendency towards connecting more 
things over time.  Perhaps multicast will be the exception- thus far, it 
has mostly seemed to go that way.  But I would point out that it wasn't 
too long ago that IPv6 faced a similiar ennui and most evidence at the 
time pointed to IPv6 never taking off.  However, IPv6 seems to have turned 
a corner in recent years and appears to be making real strides in 
deployment.  Put another way, don't judge a technology by the 
content/business models of the moment, but rather by what it makes 
possible.  Content/business models are ephemeral, whereas advances in 
underlying enabling technologies make possible things which can't be 
imagined today.  AMT may be the crucial missing piece, and now that 
commercially-available, carrier-grade implementations finally exist, it 
might be a bit premature to pull the plug.  Time will tell.

Back to the original issue Greg brought up (perhaps we should rename to 
ADHD WG), we'd love to get some comments for/against adoption of 
draft-singer-appsawg-mcast-url.  This draft was presented in Dallas and 
receives solid support in the meeting, fits with the spirit and goals of 
MBONED, and really has nothing to do with this latest interdomain debate.  
It's a very short, straightforward draft.  Please do speak up with 
opinions on whether you think the WG should or shouldn't adopt this doc.

Thanks,
Lenny

On Mon, 1 Jun 2015, John Kristoff wrote:

| On Mon, 1 Jun 2015 12:23:24 -0700
| Greg Shepherd <[email-masked]> wrote:
| 
| > The first response is a derail.. :-) But that's ok, it's a response!!
| 
| Hehe, again I know this isn't what you were hoping to hear, sorry.
| 
| > But AMT is the first chance we've had to actually utilized mcast
| > without end-to-end coordination, which I feel has been our weakness
| > for decades. Why dismantle now that we've finally progressed it to
| > RFC status?
| 
| There actually isn't all that much to dismantle.  Practically all the
| students I see now-a-days, if they have any experience whatsoever with
| IP multicast, it has usually been with things like Norton Ghost. The
| long running C-SPAN over IP multicast service my former colleagues at
| Northwestern University ran is no longer, neither is IP multicast TV
| service to the dorms (thanks Comcast).  I can't easily even tell what
| the trends have been more generally since Marshall Eubanks' once helpful
| status pages are now long gone (and the archives and tools are not
| available, I've asked), but the numbers now appear to be lower than
| there were a decade ago.  The only seemingly useful and maintained
| general monitoring is the JANET beacon page, which isn't particularly
| encouraging.
| 
| To answer your question, operationally I think fewer people have a
| compelling reason to keep it running, and leaving it running does come
| with some support cost.
| 
| We've had tunneling before.  Maybe it wasn't very good, but back then
| we couldn't wait to get rid of it.  Maybe you'll forgive me for
| thinking we're just trying to hard to get IP multicast widely deployed.
| 
| John
| 
| _______________________________________________
| MBONED mailing list
| [email-masked]
| https://www.ietf.org/mailman/listinfo/mboned
|