Subject: eGLOB+SSM (was Re: [MBONED] addrarch: IANA allocations and assignments)

From: Toerless Eckert <[email-masked]>
Date: Wed, 20 Dec 2006 16:41:51 -0800

Given that a large chunk of address allocation requests is for stuff that
should be SSM, maybe let's really focus for a second for a solution
to really help customers to migrate into SSM. Specifically for
IPTV and Finance world, or anyone else, who like these two markets is
really in the broadcasting industry (IPTV + finance streams could easily
be outrun by law enforcement entities with their videosurveilance, but luckily
those folks haven't gotten into sharing surveilance camera videos all that
much ;-))

Anyhow:

   -> eGLOB + SSM address assignment and usage strategy:

   -> For the next five years:

   -> Consider requests for addresses used by such "broadcast" SSM
      purposes. Consider eg: an address for every flow which will
      have some minimum average continuous bitrate, eg: 200kbps.

      this should limit requests to the really urgent cases and
      would inhibit landgrab when IPTV folks want to have adresses
      for PIP or finance folks for fine-grained mapping of market data
      to flows. We could also raise this rate over the period of 5 years
      when we run out of addresses faster than expected.
   
   -> Hand out eGLOB+SSM adresses x.y.z for such requests.
      Aka: allows to use 233.x.y.z and 232.x.y.z (see below)!
     
   -> Offer to keep track of a source address for every request
      and/or create some appropriate DNS mapping for the source.

   -> Define that the assignment for the adress in 232/8 does of course
      NOT mean to change the SSM service model used within 232/8. 
      
      Instead it is meant to provide an ability to deploy SSM mapping for
      five years without having overlapping addresses. Nobody using full SSM
      will be affected by this, and any SSM-mapping or similar
      transition method not supporting concurrent use of full SSM (eg:
      (S,G) membership reports and legacy reports) is not in compliance.

    -> After five years, these assignments are automatically revoked
       Aka: Within five years people getting these addresses should
       have done a migration int SSM:

       -> Can start out simply usng the 233/eGLOB address with normal
       ASM today.

       -> Can then also send to the 232/SSM-eGLOB adress and motivate
       the application environment with solutions like SSM mapping or
       the like (or full SSM).

       -> Ultimately those application need to migrate to full SSM
       within five years.

Cheers
    Toerless

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

---

From: Marshall Eubanks <[email-masked]>
Date: Wed, 20 Dec 2006 22:09:37 -0500

Dear Toerless;

>        -> Ultimately those application need to migrate to full SSM

I must admit that I don't like this much - Napoleon said that there  
is nothing as permanent as the
temporary, and after 5 years if they do not migrate, what then ? The  
IETF has no
power to force people to change applications, so the end result would  
likely be a muddled 232/8

Regards
Marshall

---

From: Marshall Eubanks <[email-masked]>
Date: Wed, 20 Dec 2006 22:09:37 -0500

Dear Toerless;

Regards
Marshall

---

From: Toerless Eckert <[email-masked]>
Date: Wed, 20 Dec 2006 19:28:07 -0800

> likely be a muddled 232/8

Sure. That's just as far as i would be willing to go to
in support of ease of initial deployment while still maintaining
the ultimate goal. I don't see how this will muddle 232/8 at all,
because that is exactly what people today do with SSM Mapping, which even though
it was invented by Cisco, is now also supported by other vendors and
used by customers. It is just giving SSM mapping a good entry and exit
strategy.

The end of the road for non-SSM compliance in products that's hindering
customesto use SSM is defnitely coming closer. With SOlaris havng introduced
IGMPv3 in 10.0 and MacOS introducng it in 10.5, we've pretty much closed
the host-OS issue quite a bit more. Next should be stuff like Java-API or
windows CE. Likewise there's positive movement now on L2 nework
elements.

I think that right now is quite a good time to define a clearer
migration process, and i think 5 years is a realistic timeline. Specifically
because that's also the end of special suppot for windows 2000 ;-))

But:

If an idea like this will not fly in the IETF, then i'm back to saying
that i don't want eGLOB to go forward ot all, or anything else that will just
cause more ASM addresses to be used for what actually are SSM applications,
delaying the migration of such applications into SSM without ANY plan.

Seriously: It goes back to the fact that 99% of all adress allocation
requests go back to things inappropriate for global scope ASM. GLOB itself
is a temporary measure, it was long ago recognized that IPv4 multicast
addresss are too few for permanent allocation, so if you want to use a global
ASM address, just use MZAP et. al. to get it dynamically allocated.

So let's jus stop to do stupid workarounds.

Seriously: I don't need and i don't want the IETF to resolve all
business process problem under the cost of messng up the agreed upon
technical directives, scalability, etc.. There's enough stuff we can do
outside of the IETF to overcomes such issues. Worst case people
have to use multicast group NAT.

Cheers
    Toerless

---

From: Toerless Eckert <[email-masked]>
Date: Wed, 20 Dec 2006 19:28:07 -0800

But:

Cheers
    Toerless

---

From: Leonard Giuliano <[email-masked]>
Date: Thu, 21 Dec 2006 08:07:45 -0800 (PST)

Toerless- I understand your goal, but I just don't think this scheme will 
ever accomplish it.  There are ways to push for SSM deployment- static 
mcast assignment restrictions don't strike me as particularly effective in 
that regard, especially when (I suspect) the number of folks needing this 
is too insignificant to matter.  After all, these are mostly folks who 
have no ASN- are they really going to be the drivers of a transition to 
SSM more effectively than our best efforts for 6+ years?  And what about 
the rest (majority) of the world out there that has ASNs and can just do 
GLOP?

The fact is, there is a really simple way of solving this- EGLOP.  That 
the only barrier has been not finding an entity to adminster this 
extremely simple scheme strikes me as an emminently solvable problem.  
Simply put, I'm sure we can find someone to do this.  And since this 
space is limited and finite, we can make such assignments renewable every 
year or so.

I also believe it would be worthwhile to resurrect unicast-prefix mapping.  
It's just as easy as GLOP, requires no administration like GLOP, and is 
more widely available (you only need a /24 or bigger block, no ASN 
needed).  I recall the reason it died was mostly lack of interest/demand.  
If there really is interest out there, I see this as a nice additional 
solution.

As for MADCAP, I would reclassify into whatever category fairies and pixie 
dust are contained.

On Wed, 20 Dec 2006, Toerless Eckert wrote:

-) On Wed, Dec 20, 2006 at 10:09:37PM -0500, Marshall Eubanks wrote:
-) > I must admit that I don't like this much - Napoleon said that there  
-) > is nothing as permanent as the
-) > temporary, and after 5 years if they do not migrate, what then ? The  
-) > IETF has no
-) > power to force people to change applications, so the end result would  
-) > likely be a muddled 232/8
-) 
-) Sure. That's just as far as i would be willing to go to
-) in support of ease of initial deployment while still maintaining
-) the ultimate goal. I don't see how this will muddle 232/8 at all,
-) because that is exactly what people today do with SSM Mapping, which even though
-) it was invented by Cisco, is now also supported by other vendors and
-) used by customers. It is just giving SSM mapping a good entry and exit
-) strategy.
-) 
-) The end of the road for non-SSM compliance in products that's hindering
-) customesto use SSM is defnitely coming closer. With SOlaris havng introduced
-) IGMPv3 in 10.0 and MacOS introducng it in 10.5, we've pretty much closed
-) the host-OS issue quite a bit more. Next should be stuff like Java-API or
-) windows CE. Likewise there's positive movement now on L2 nework
-) elements.
-) 
-) I think that right now is quite a good time to define a clearer
-) migration process, and i think 5 years is a realistic timeline. Specifically
-) because that's also the end of special suppot for windows 2000 ;-))
-) 
-) But:
-) 
-) If an idea like this will not fly in the IETF, then i'm back to saying
-) that i don't want eGLOB to go forward ot all, or anything else that will just
-) cause more ASM addresses to be used for what actually are SSM applications,
-) delaying the migration of such applications into SSM without ANY plan.
-) 
-) Seriously: It goes back to the fact that 99% of all adress allocation
-) requests go back to things inappropriate for global scope ASM. GLOB itself
-) is a temporary measure, it was long ago recognized that IPv4 multicast
-) addresss are too few for permanent allocation, so if you want to use a global
-) ASM address, just use MZAP et. al. to get it dynamically allocated.
-) 
-) So let's jus stop to do stupid workarounds.
-) 
-) Seriously: I don't need and i don't want the IETF to resolve all
-) business process problem under the cost of messng up the agreed upon
-) technical directives, scalability, etc.. There's enough stuff we can do
-) outside of the IETF to overcomes such issues. Worst case people
-) have to use multicast group NAT.
-) 
-) Cheers
-)     Toerless
-) 
-) _______________________________________________
-) MBONED mailing list
-) [email-masked]
-) https://www1.ietf.org/mailman/listinfo/mboned
-)

---

From: Leonard Giuliano <[email-masked]>
Date: Thu, 21 Dec 2006 08:07:45 -0800 (PST)

---

From: Toerless Eckert <[email-masked]>
Date: Thu, 21 Dec 2006 09:43:43 -0800

On Thu, Dec 21, 2006 at 08:07:45AM -0800, Leonard Giuliano wrote:
> ever accomplish it.

Why not ?

See, i brought this up not only because of the thread around Pekka's
mail on IANA policies, etc, but also because content providers did
ask me how to best transition into SSM. In the edge there's still non
SSM compliant L2 equipment (DSLAM, ... - that's mostly in the IPTV
world of course) and even non-IGMPv3 capable hosts (mac, solaris,
older linux, eve win 2000 is still strongly used - that's mostly the
finance world).

So, we all now have products supportng SSM Mapping, but how do you best
suggest to deploy SM mapping ? The problem wih SM mapping is that you
still would like to guarantee non-reuse of the group-addresses used
with SSM, mapping, or else you will be overloading L2 edge equipment
that is eiher not SM capable, or even if it's SSM capable, it's only
doing L2 DMAC based forwarding. So, that's where the idea for
using GLOB like adresses comes from. Then there's two choices: Either
you try to apply SSM mapping to actual 233 addreses, or you use
such GLOB addresses wihin 232 - both approaches have pro and cons,
and so the best is maybe to allow both of them.

Coming from that pespective to provide clear guidance into SSM with
SSM mapping then of course also allows i think to take pressure off
adress allocation requests if we will hand out addresses for this purpose
and within the bounds of beng a transition support.

 There are ways to push for SSM deployment- static 
> SSM more effectively than our best efforts for 6+ years?

Most fnance enterprise and even content providers won'thave ASN numbers.
Likewise only IPTV conrtent providers with some background in being also
an ISP will have AS numbers. Lastly it is actually a benefit of
not tying the allocation to AS numbers, becaue we would even the playing
field. And we can also put more appropriate policies for allocation in
rather than the "have or have not" AS/GLOP way.

Also, if i remember some of the recent big block allocations that
id happen, then this is actually all for SSM like content, and folks
managed to sneak it through. So i don't think that allocation requests
for content distribution are insignificant. I would claim that it's
the mayority or in any case a significant percentage that we should
try to find a better solution to help them out now and guide them towards
SSM as much as possible.

> And what about the rest (majority) of the world out there that has ASNs
> and can just do GLOP?

I think once we capture all folks wanting addresses with better mechanisms
than GLOB we can start thinking about retiring GLOB (eg: AS based
assignment). It is after all defned tob e temporarily too.

As i said in a different mail, i thnk that beside content distribution
rquests the rest of address requests are for addresses developers of
applications would like to burn into their applications such that
their customers can depoy the applications and they will work out of
the box. I would first like to see whether we can validate or
invalidate that assumption. Aka: first try to classify really the base
reason for allocation requests. If we can then really determine
those types, then we can come up with appropriate solutions for those
as well. But let's maybe try to do this approach first for addresses
required for content distribution (aka: SSM style).
> space is limited and finite, we can make such assignments renewable every 

Sure. eGLOB without modification is a way to open the floodgates of
ASM address allocation more. What i was sugesting was to conrol this
somewhat more with "eGLOB+SSM", by bringing in the migration into SSM
into this type of allocation. I haven't met a single customer whose
network folks didn't buy into SSM as a concept when their application
was content distribution. They where just never presented with a
transition plan from the IETF that would help them best to get started
now and develop a plan to close the SSM gaps on their vendors equipment
in time. That's what that eGLOB+SSM idea is about.

> If there really is interest out there, I see this as a nice additional 

Well. It's even mor autopilot than eGLOB. It really depends on the goals
you have. 

Cheers
    Toerless

---

From: Toerless Eckert <[email-masked]>
Date: Thu, 21 Dec 2006 09:43:43 -0800

Why not ?

Cheers
    Toerless

---

From: John Kristoff <[email-masked]>
Date: Thu, 21 Dec 2006 11:52:20 -0600

On Thu, 21 Dec 2006 08:07:45 -0800 (PST)

> The fact is, there is a really simple way of solving this- EGLOP.  That 
[...]
> I also believe it would be worthwhile to resurrect unicast-prefix mapping.  
[...]
> As for MADCAP, I would reclassify into whatever category fairies and pixie 

I have little to add other than I want to be sure to express at least
some sentiment of "I agree" with Lenny.

GLOP has actually been fairly easy to implement and manage from the
operator perspective.  I may not be as smart as many of you who have
been around doing multicast a lot longer than I.  Yet, I am somewhat
bewildered that GLOP seems to be seen as an inelegant hack and that
this community seems unwilling to give up on some sort of "multicast
addressing holy grail scheme".  GLOP and even administratively scoped,
with all it's improper use in deployment, seems most well suited for
the Internet community today.

Pekka's drafts were very helpful.  They have helped me come to the
conclusion that I don't think multicast addressing needs any more
engineering as this point.  The schemes that Lenny mentioned seem to
be perfectly valid and in some aspects quite elegant in and of
themselves.  While people can continue to work on alternatives, I
would be very interested in seeing more effort on actual "deployment"
(the 'd' in this group's name after all) for schemes like
administratively scoped, GLOP, eGLOP and unicast-derived addressing.
If someone of some influence agrees, I offer you my help in any way
I am able to contribute.

Sorry if that was a bit of a rant.  Since I haven't had to debug a
multicast problem for about a year now perhaps I was just experiencing
withdrawal symptoms?  :-)

John

---

From: John Kristoff <[email-masked]>
Date: Thu, 21 Dec 2006 11:52:20 -0600

[...]
[...]

John

---

From: Beau Williamson <[email-masked]>
Date: Thu, 21 Dec 2006 11:55:28 -0600

>space is limited and finite, we can make such assignments renewable every

Good point.

I've proposed the following before and I don't remember what the issue is 
in taking this direction so I'll bring it up again.

Let's provide whatever "guidance" is necessary to IANA and have them 
"allocate" all future ASM multicast addresses from the EGLOP block.

Why do we have to sit and wait for some RIR to take this over and make 
money.  Let's start by just having IANA "STOP" providing these static 
assignments for addresses (to ostensibly clueless entities) that really 
should be GLOP, EGLOP or SSM and start issuing them EGLOP addresses.  Or 
even better, if the IANA finds that the entity owns an ASN, issue the 
entity the GLOP space that is already associated with the entity's ASN.

So it then simplifies to :

   1) If the entity has an ASN, issue them their own ASN-based GLOP address 
range.

      1a) If the entity complains that they were just issued their "own" GLOP
          space, then proceed to step (2).

   2) If the entity has no ASN or have already been assigned their GLOP address
      range, issue them addresses from the EGLOP space.

      2a) If the entity complains that they were just issued EGLOP space, then
          only THEN issue them addresses from the AD-HOC range.

The net affect of the above is that we will stop issuing blocks of AD-HOC 
space to truly clueless entities.  They will get "A" block of multicast 
addresses and will go away fat, dumb and happy.

Beau Williamson

---

From: Beau Williamson <[email-masked]>
Date: Thu, 21 Dec 2006 11:55:28 -0600

Good point.

Beau Williamson

---

From: Marshall Eubanks <[email-masked]>
Date: Thu, 21 Dec 2006 13:05:24 -0500

Dear Beau;

On Dec 21, 2006, at 12:55 PM, Beau Williamson wrote:

> I've proposed the following before and I don't remember what the  
> issue is in taking this direction so I'll bring it up again.
>
> Let's provide whatever "guidance" is necessary to IANA and have  
> them "allocate" all future ASM multicast addresses from the EGLOP  
> block.
>

This has been set into motion.

> Why do we have to sit and wait for some RIR to take this over and  
> make money.  Let's start by just having IANA "STOP" providing these  
> static assignments for addresses (to ostensibly clueless entities)  
> that really should be GLOP, EGLOP or SSM and start issuing them  
> EGLOP addresses.  Or even better, if the IANA finds that the entity  
> owns an ASN, issue the entity the GLOP space that is already  
> associated with the entity's ASN.
>

>   1) If the entity has an ASN, issue them their own ASN-based GLOP  
> address range.
>

Of course, we need a means of figuring this out for 32 bit ASN. Or do  
they go directly to step 2 ?

Marshall

> The net affect of the above is that we will stop issuing blocks of  
> AD-HOC space to truly clueless entities.  They will get "A" block  
> of multicast addresses and will go away fat, dumb and happy.
>
> Beau Williamson
>
>

---

From: Marshall Eubanks <[email-masked]>
Date: Thu, 21 Dec 2006 13:05:24 -0500

Dear Beau;

Marshall

---

From: Leonard Giuliano <[email-masked]>
Date: Thu, 21 Dec 2006 11:48:43 -0800 (PST)

On Thu, 21 Dec 2006, Beau Williamson wrote:

-) 
-) So it then simplifies to :
-) 
-)   1) If the entity has an ASN, issue them their own ASN-based GLOP address
-) range.
-) 
-)      1a) If the entity complains that they were just issued their "own" GLOP
-)          space, then proceed to step (2).
-) 
-)   2) If the entity has no ASN or have already been assigned their GLOP
-) address
-)      range, issue them addresses from the EGLOP space.
-) 
-)      2a) If the entity complains that they were just issued EGLOP space, then
-)          only THEN issue them addresses from the AD-HOC range.
-) 

This sounds like a good process for IANA or whatever RIR eventually does 
get the task of assigning mcast/EGLOP space.  Only problem is that it 
seems to lack unnecessary complexity.

The only thing I might add is: 

1.1) If entity has /24 or larger block, use unicast-prefix mapping.

	1.1a) If entity requires more addresses than can be derived from 
	unicast-prefix mapping, proceed to step 2

I think the goal should be to minimize the number of folks who make it to 
step 2, and as 32b ASNs become popular, this may become a bigger issue.

---

From: Leonard Giuliano <[email-masked]>
Date: Thu, 21 Dec 2006 11:48:43 -0800 (PST)

-)