Subject: RE: mboned: brief IMAD BOF summary

From: "Manfredi, Albert E" <[email-masked]>
Date: Mon, 8 Aug 2005 17:30:25 -0400

Any amplification on the IGMPv2.1 idea? Is this meant to be a better
IGMPv2 or a simpler version of IGMPv3. Off the top, I see v2.1 as being
an ASM solution, not SSM. Yes?

And what was the motivation? For example, is IGMPv3 seen as something
too complicated?

Thanks.

Bert

> -----Original Message-----
> From: David Meyer [mailto:[email-masked]] 
> Sent: Monday, August 08, 2005 1:15 PM
> To: [email-masked]
> Cc: [email-masked]; [email-masked]
> Subject: mboned: brief IMAD BOF summary
> 
> 
> 	The BOF ended with a number of ideas and tasks. Main
> 	takeaways included: 
> 
> 	o We need to give IANA a policy tool to say no to
> 	  requests for static global space that is not being used
> 	  globally. This is a change in policy and from the IANA
> 	  presentation here lies a world of legal challenges, but
> 	  I find it hard to believe we could not address those.
> 	  In this  
>  
> 	  In addition, it appeared that many of the folks in the
> 	  audience hadn't read the form, as the AS question *is*
> 	  there. However, it phrased in terms of GLOP (and
> 	  RFC2770; note: the web site needs to be updated; should
> 	  be RFC 3180/BCP: 53). Now, one can argue whether folks
> 	  who don't know what GLOP is (or how to read the RFC)
> 	  will or will not know if they have an AS, but on the
> 	  theory that more information is better....  
>  	
> 	o We need to get a handle on how fast we are running out
> 	  of address space, why, and when. Basically getting the
>           predictions for v4 for multicast space would be
> 	  great. This could also help IANA.  
>  
> 	o We need to get the SSM spec out the door. That said, it
> 	  will unlikely help us get rid of all requests but
> 	  rather stop the problem from accelerating.
>  
> 	  David Kessens and David Meyer took this action to talk
> 	  with Bill and Alex about how to accomplish this. 
>  
> 	o Someone in the session said we should pursue EGLOP and
> 	  try to get allocations handled through the RIR
> 	  system. This of course was the point of the EGLOP
> 	  experiment. Another suggestion was to just have the
> 	  IANA assign out of the EGLOP space.
>  
> 	o The issue of address discovery was also raised. There
> 	  where several ideas on how to do it. 
> 
> 	o Invent the "BIG" scope.
> 
> 	  This was an idea proposed by Mark Handley (and proposed
> 	  to be homed in 238/8).  
> 
> 	o IGMP v2.1 (i.e., as simpler IGMP)
> 
> 	o Update the IANA guidelines document, perhaps including
> 	  the flow-chart on the IANA site so it receives review.
> 
> 	o Take EGLOP (RFC 31381) from Informational to BCP (like
> 	  we did with GLOP).  This would be necessary if we
> 	  wanted the IANA to assign from this space. 
> 
>  
>  	Dave

_______________________________________________________________
user interface: http://darkwing.uoregon.edu/~llynch/mboned.html
web archive:  http://darkwing.uoregon.edu/~llynch/mboned/

---

From: David Meyer <[email-masked]>
Date: Mon, 8 Aug 2005 15:51:03 -0700

> And what was the motivation? For example, is IGMPv3 seen as something

	Exactly. 

	Dave

---

From: Marshall Eubanks <[email-masked]>
Date: Mon, 8 Aug 2005 19:16:59 -0400

I was unable to  attend, but the question that I would ask is, would 
v.2.1 support
control messages sent to  224.0.0.22 (or some other well known group). 
That
really helps with snooping switches.

Regards
Marshall

---

From: David Meyer <[email-masked]>
Date: Mon, 8 Aug 2005 16:18:35 -0700

> really helps with snooping switches.

	Again, we were just brainstorming the problem, and this
	arose as a possible way to deal with the lack of SSM
	deployment. 

	Dave

---

From: Tom Pusateri <[email-masked]>
Date: Mon, 08 Aug 2005 21:12:25 -0700

In message <[email-masked]> you write:
>> I was unable to  attend, but the question that I would ask is, would=20
>> v.2.1 support
>> control messages sent to  224.0.0.22 (or some other well known group).=20
>> That
>	deployment.=20

More brainstorming...

IGMPv2.1
--------
So maybe IGMPv2.1 might have made sense a few years ago but at this
point, I'm not sure its a step in the right direction.

Several switch vendors support IGMPv3.
Windows and Linux support IGMPv3.

One can argue that the code running on switches or the version of
operating systems doesn't support IGMPv3 but upgrades are available
in many cases. This means its more of a deployment problem than a
problem with IGMPv3 being too complex to implement. Starting over
by requiring a new code to be developed takes us backwards.

The deployment problem will get fixed once there is an application
that people want to use.

AMT
---
Mark Handley, Dino, and I were talking after the meeting and we all
had the idea that AMT could provide a transition mechanism for SSM.
It will allow hosts that support IGMPv3 to get SSM data directly
from AMT relays. It also provides a way to get IPv6 multicast across
an IPv4 network. It was mentioned at the meeting that maybe we
should concentrate on IPv6 multicast instead of IPv4 multicast. If
so, then it could intially be tunneled until it can be run native.

Tom

---

From: Hitoshi Asaeda <[email-masked]>
Date: Tue, 09 Aug 2005 18:36:07 +0900 (JST)

> point, I'm not sure its a step in the right direction.

The SSM deployment problem is not due to IGMPv3's development delay. 
Talking about the host-side implementation, my original igmpv3 code
was released to public more than three years ago, and KAME has been
supported to apply it for all *BSDs for more than two years. Linux and
Windows XP have already supported it. I heard Solaris too. I'm not
sure about MacOS, but from now on it would be trivial I guess.
Major router vendors have already supported the router-side
implementation. I thought implementation of the snooping function on
switch may be a bit delayed, but now the situation can be slightly
changed since as Tom said upgrades are available in many cases.

On the other hand -- this is the different discussion --, defining
SSM-only IGMP may be beneficial for some small equipment (e.g. PDA or
other mobile terminal).
In fact, in my implementation, the state change procedure between
INCLUDE mode and EXCLUDE mode are fairly complex and the relative code
size is not small. It would be tough work to sprit each function and
discard EXCLUDE mode from the current code; nevertheless, it may be
beneficial for such small equipment to support only INCLUDE mode
because the code size (and thus kernel itself) will be considerably
minimized (less than half, I guess) if we eliminate EXCLUDE mode from
the complete IGMPv3 implementation.

Again, defining IGMPv3-Lite/MLDv2-Lite (*), which only supports
INCLUDE mode, does not solve the current deployment problem. However
it may be able to increase the chance for new users to live with SSM.
(*) A new protocol naming with older version (i.e. IGMPv2.1) puts some
negative image to people who do not know our intention. It's not a
good idea to use older version number here. For me, IGMPv3-Lite/
MLDv2-Lite is much better to work for a positive approach.

--
Hitoshi Asaeda

---

From: Pekka Savola <[email-masked]>
Date: Tue, 9 Aug 2005 13:22:44 +0300 (EEST)

On Tue, 9 Aug 2005, Hitoshi Asaeda wrote:
> supported to apply it for all *BSDs for more than two years.

Yes, but it hasn't come bundled by default on BSDs.  I think they've 
cited IPR concerns over the Apple's SSM patent.  Now, at least some 
BSDs have been merging IGMPv3 _host-side_ code, believing that it 
should be safe at least.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
_______________________________________________________________
user interface: http://darkwing.uoregon.edu/~llynch/mboned.html
web archive:  http://darkwing.uoregon.edu/~llynch/mboned/

---

From: Stig Venaas <[email-masked]>
Date: Tue, 9 Aug 2005 14:47:06 +0200

> really helps with snooping switches.

I think the main problem is replacing existing switches with new ones
that can do IGMPv3. Getting yet another IGMP protocol which might
require replacing switches sounds like a bad idea to me.

One thing that was mentioned, is that some vendors have some work-
arounds where a router is told that when someone joins a particular
G, it should be translated into (S,G). Another potential work-around
that could work with IGMPv2 snooping switches would be to send a
normal IGMPv2 for G, but do additional signalling to specify S. Well,
maybe this is the idea of 2.1?

I still think we should consider alternatives to snooping, but it
seems most are happy with snooping...

Stig

---

From: Stig Venaas <[email-masked]>
Date: Tue, 9 Aug 2005 15:12:47 +0200

> MLDv2-Lite is much better to work for a positive approach.

So this is the idea with 2.1? IGMPv3-lite would be a better name then
(although I think it may be used already). If a client is only to do
SSM, then we don't need EXCLUDE mode which makes it easier as you say.
Could one possibly also skip the backwards compatibility? Seems to me
all this backwards compatibility causes lots of complexity as well. A
host only supporting SSM (only source specific joins, and only in the
SSM range) would not need to be backwards compatible, would it?

My main concern is that changes to IGMP may require changes in snooping
switches. But doing a subset of IGMPv3 would probably be safe...

BTW, at least one router implementation seems to go into compatibility
mode when it sees an MLDv1 report for an SSM group, thereby making the
SSM group useless for everyone. Seems IGMPv3/MLDv2 specs don't make
any exceptions for SSM groups though.

Stig

---

From: Beau Williamson <[email-masked]>
Date: Tue, 09 Aug 2005 10:55:50 -0500

It turns out that none of these things are the key problem with regard to 
Content Providers doing a "land-grab" on multicast addresses with the IANA.

Almost all of these address allocation requests/problems are being 
generated by Financial data service/content providers who are providing 
direct feeds (read, NOT via the Internet) into their customers' 
networks.  Since these Financial data content providers don't control the 
end workstation nor do they even know for sure WHAT sort of workstation the 
customer is using, they are not interested in dealing with the POSSIBILITY 
of any problems associated with SSM.  Instead, they just want to take the 
easy way out and that is to use ASM in these extranets.

All of this means that until SSM becomes the defacto standard for 
everyone's enterprise network multicast, they will not be likely to move to 
an SSM model. Basically this boils down to Fear and Laziness which means 
these people will not move to the new world until forced to do so.

Folks, there isn't a technology solution to Fear and Laziness.  The only 
thing that can have any hope of fixing this is for the IANA to "Just Say 
No".  This probably also means that they need to "recall" (or reassign to 
GLOP or eGLOP space) all other previous assignments to NASDAQ, etc that was 
given out by mistake in the past.

The longer IANA waits to "Just Say No", the harder this problem becomes to 
get under control.  If the IANA's concern is that they will be sued if they 
don't give in to these "tantrum throwing children" for saying "No" and they 
don't wish to deal with that, then they need to state that and we should 
just stop wasting our time with this issue as it can't be solved and move 
on to something productive.

Beau Williamson

---

From: Dino Farinacci <[email-masked]>
Date: Tue, 9 Aug 2005 17:37:18 -0700

>> 	Exactly.=20

    Why is it complicated now and wasn't when it was standardized? If the
    IETF made the call to standarize IGMPv3, we shouldn't back-peddle now.

    I vote for no IGMPv2.1. It just doesn't make sense. Why we don't channel
    our effort for an SSM source-discovery-based directory, something that is
    needed.

Dino

---

From: Dino Farinacci <[email-masked]>
Date: Tue, 9 Aug 2005 17:41:03 -0700

>> had the idea that AMT could provide a transition mechanism for SSM.

    Tom, agree about the conversation, but I think the more serious problem
    is getting IGMPv2 hosts to play in an SSM core. Upgrading the routers is
    the easier change IMO.

    So I'm not sure AMT is right for this problem. I do believe AMT is right
    for getting more wide-area multicast going so then people will later feel
    more compelled to put multicast natively in more parts of the network.

>> so, then it could intially be tunneled until it can be run native.

    Right. If we concentrate on IPv6 multicast the multicast address allocation
    problem pretty much goes away.

Dino

---

From: Dino Farinacci <[email-masked]>
Date: Tue, 9 Aug 2005 17:51:28 -0700

>> on to something productive.

    Could someone explain to me what's so wrong with running out of IPv4
    multicast space? It sounds like when it happens some good discpline will
    begin to happen?

Dino

---

From: Joel Jaeggli <[email-masked]>
Date: Tue, 9 Aug 2005 19:44:32 -0700 (PDT)

>    multicast space? It sounds like when it happens some good discpline will

running out might indicate that people are using it. which would be nice.

-- 
--------------------------------------------------------------------------
Joel Jaeggli  	       Unix Consulting 	       [email-masked]
GPG Key Fingerprint:     5C6E 0104 BAF0 40B0 5BD3 C38B F000 35AB B67F 56B2

---

From: Dino Farinacci <[email-masked]>
Date: Tue, 9 Aug 2005 20:40:33 -0700

>> running out might indicate that people are using it. which would be nice.

    And then we can put in proper procedures since there will be no space
    to allocate. 

    And if it doesn't get all allocated, we have our answer about use.

Dino

---

From: Marshall Eubanks <[email-masked]>
Date: Wed, 10 Aug 2005 04:36:16 -0400

I will say again what I said in Minneapolis :

These people should get e-Glop space and I would be glad to spend the
cycles to help them get it. The first allocation should be a pain, the 
rest a
matter of routine.

Regards
Marshall

---

From: John Kristoff <[email-masked]>
Date: Thu, 11 Aug 2005 10:23:49 -0500

On Tue, 9 Aug 2005 17:51:28 -0700
Dino Farinacci <[email-masked]> wrote:

>     Could someone explain to me what's so wrong with running out of
>     IPv4 multicast space? It sounds like when it happens some good
>     discpline will begin to happen?

Quite frankly I think we are already in danger of the space running out
whether it is officially assigned or managed.  The balkanization by a
number of rogue apps picking random space is causing some of it to be
lost due to filtering.

John