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: Toerless Eckert <[email-masked]>
Date: Thu, 21 Dec 2006 14:07:47 -0800

I don't think anyone is calling GLOP a hack. It is actually as good
an addressing assignment as we can get in IPv4. Otherwise we could
call rfc3306 also a hack, and i love rfc3306. I am only criticising that
GLOP was intended to be a transition solution, and it has rather
help to reaffirm and prolong the status quo. So it didn't achieve
the goal it was intended for.

Cheers
    Toerless

On Thu, Dec 21, 2006 at 11:52:20AM -0600, John Kristoff wrote:
> On Thu, 21 Dec 2006 08:07:45 -0800 (PST)
> Leonard Giuliano <[email-masked]> wrote:
> 
> > 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 
> > dust are contained.
> 
> 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
> 

-- 
Thanks
   Toerless Eckert

---

From: Toerless Eckert <[email-masked]>
Date: Thu, 21 Dec 2006 14:07:47 -0800

Cheers
    Toerless

-- 
Thanks
   Toerless Eckert