Re: [MBONED] WGLC for <draft-ietf-mboned-ipv4-uni-based-mcast-04.txt>

On Thu, Jan 24, 2008 at 06:21:33PM -0800, Dino Farinacci wrote:
> >On Thu, Jan 24, 2008 at 04:55:50AM -0800, Dino Farinacci wrote:
> >>>>But you can go get an ASN and not use it for BGP purpose but do use
> >>>>it for GLOP addressing. Then you decouple yourself from your
> >>>>upstream provider.
> >>>>
> >>>
> >>>I think that there is a big problem with this suggestion :
> >>>
> >>>Soon, 16 bit ASN will become unavailable. (January, 2009, the RIRs
> >>>will only give them out by request,
> >>>January 2010, they will not distinguish between the 16 and 32 bit
> >>>pools, which means in practice you
> >>>will get a 32 bit one.)
> >>>
> >>>There is no GLOP space for 32 bit ASN. We are working on a I-D to
> >>>address this, but it is not there yet.
> >>
> >>Use eGLOP ...
> >
> >So where do I get my eGLOP allocation today?
> >
> >eGLOP just seems complicated.  Lots of paperwork (initially and  
> >presumably
> >recurrent), coordination between RIRs (or management by IANA), etc.
> 
> You either get complicated with paperwork or with protocol mechanism.  
> We don't need the later or else we go with MASC, MADCAP, or other.

Unless I'm missing something, this proposal has no paperwork, it just
enables group address 'allocations' automatically.

> >This proposal however is simple, comparatively 'elegant', minimises
> >paperwork, and allows a reasonable allocation size to an enterprise  
> >that
> >has a /16 for unicast.
> >
> >>... and/or draft-ietf-mboned-ipv6-uni-based_mcast-04.txt.
> 
> Sure, so go with it. My point is there shouldn't be anymore obstacles.

It would be nice, yes :)

> >We use that today, for IPv6.   Though in practice embedded-RP is more
> >popular on more global scope IPv6 networks because the (now RFC) you
> >mention only really works with one pre-configured RP (like in m6bone),
> >whereas embedded RP allows any content provider to implictly define  
> >the
> >RP for the group (usually but not always locally).   So we tend to use
> >embedded RP group addresses a lot at present, whether scoped locally
> >or wider.  (Most of that currently is organisation scope IPv6 IPTV,
> >but we have services offered externally as well, and we expect  
> >external
> >services to grow as universities become more competitive in offering
> >material globally.)
> 
> Sure, but if you ever want to use Bidir with embedded-RP groups, there  
> are going to be major issues. Sender-only branches just don't work  
> well, that is, will cause a lot of packet loss.

I'd be interested in any references on this.   At the moment we're only
using embedded-rp to source content that ideally could be done with ssm.

> >Having said that, I appreciate multicast is many things to many  
> >people,
> >and demands and requirements will vary.   We're probably not typical.
> >
> >>>(There are other problems, but this is a big one.)
> >>
> >>I want to start solving the problems so there are no excuses. But my
> >>interpretation of all this is that we have solved the problems so why
> >>are there still obstacles.
> >
> >We'd like to use SSM.   Vendor shortcomings currently make that  
> >somewhat
> >impractical, for IPv4 and IPv6, at least from the enterprise  
> >perspective
> >we're looking from :(
> 
> It would be good to identify them so vendors have specific data to go  
> resolve the issues.

I thought that naming vendors wasn't 'good form' here.   I think people
using multicast on campus-style networks will know the issues, but
of course everyone's scenarios will differ a bit...

-- 
Tim

_______________________________________________
MBONED mailing list
MBONED@ietf.org
https://www1.ietf.org/mailman/listinfo/mboned