Subject: RE: mboned: draft MBONED minutes

From: "Manfredi, Albert E" <[email-masked]>
Date: Fri, 19 Nov 2004 14:03:25 -0500

I know this exact multicast group membership identification is important to ISPs, but I think it's hard to say whether the wg should take this problem until unless the "existing mechanisms" that some feel are adequate are summarized somewhere.

Also, with IGMPv3/MLDv2, where reports are not suppressed, shouldn't this be easier to accomplish without some other protocol?

Bert

> -----Original Message-----
> From: Pekka Savola [mailto:[email-masked]]
> Sent: Friday, November 19, 2004 6:59 AM
> To: [email-masked]
> Subject: Re: mboned: draft MBONED minutes
> 
> 
> Just one question.. because I seem to be forgetting what was the 
> result of the "Well managed IP multicasting" discussion; below:
> 
> On Tue, 9 Nov 2004, David Meyer wrote:
> > -----
> > H. Ohta
> >
> > "Well managed IP multicasting"
> >
> > Network operators want to
> > - build efficient networks
> > - create value added services
> > - build manageable networks
> >
> > IGMP / MLD does not provide accounting
> >
> > Network cannot identify or authenticate or authorize users or keep
> > track of usage
> >
> > This is not sufficient for carrier class services (high 
> quality premium
> > or fee based).
> >
> > Content providers also want this
> >
> > Dave Thaler : Are the existing mechanisms sufficient ?
> >
> > Pekka Savola : I think that existing ISPs can do all of this using
> > existing mechanisms
> >
> > Haixiang He : Layer 2 authentication is not good enough as the link
> > account provider and the  content provider  may not be the 
> same party.
> >
> > Dave Thaler : Layer 3 solutions involving only
> > IGMP and MLD are not at the right layer. For the last hop 
> L2 mechanisms
> >  are a much better fit. If you are talking about end to end 
> then I can
> > agree that this is necessary. You might want to remove the 
> IGMP and MLD
> > from this discussion.
> >
> > Ohta :
> > We need to make it possible for network operators and 
> content providers
> > cooperate and both make money. They need to share revenue, and this
> > means that they need to measure usage. Content providers 
> are not good
> > for networks and network providers are not good for 
> network, They both
> > need to cooperate.
> >
> > I want to find out if the MBONED network
> >
> > [email-masked]
> >
> > http://standards.nortelnetworks.com/archives/mac-external.html
> >
> > Dan Alveraz: MBONED needs to support different business models for
> > multicast. I want the MBONED group to be a repository for all
> > multicast work. I want to evolve this into a framework and
> > requirements document.
> >
> > Pekka Savola : I think that in general this work is useful, and that
> > the current approach is not really useful. We need to take this one
> > level to a frameworks and requirements draft.
> >
> > Dan of Cisco  - That is what this draft is trying to do.
> >
> > David Meyer - How many in the WG think that we should take this on ?
> > (Show of hands - a majority yes, but definitely some no.)
> 
> Was the last one what was asked?  My recollection of the events is 
> pretty dim, but at least I seemed to recall the WG was just asked 
> whether they considered this as an important problem space (and not 
> so much about the draft itself).  Maybe 'this' in the minutes 
> needs be 
> expanded, at least...
> 
> What about others-- anyone remember?
> 
> I think I'd definitely remember if there would have been consensus to 
> take this as WG item, for which there wasn't AFAIR.
> 
> 
> -- 
> 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/
> 

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

---

From: "Daniel Alvarez" <[email-masked]>
Date: Fri, 19 Nov 2004 12:15:24 -0800

Bert,

The discussed draft is not promoting a new protocol.  From my point of view
there are various ways of addressing the current gaps that the draft is
presenting.  One approach is an architectural one, and another could be a
protocol approach.  But now we are getting into solutions....  

I would expect that the architectural approach will require a family of
protocols to provide the AAA and identity requirements not currently
available in multicast deployments.  We might need enhancements to such
protocols in order to satisfy the multicast needs.  Since those protocols
don't reside within any of the multicast working groups, I was looking for
the mboned wg as the place to coordinate the efforts and engage the
necessary folks across other WGs to complete our multicast delivery
solution.

I also expect some protocol approaches to be presented and at that time
those can be discussed in their appropriate forum (i.e. not likely mboned).
But I still think that mboned is a good home for the requirements and
framework docs.

My 2 cents,

dan 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Manfredi, Albert E
Sent: Friday, November 19, 2004 11:03 AM
To: Pekka Savola; [email-masked]
Subject: RE: mboned: draft MBONED minutes

I know this exact multicast group membership identification is important to
ISPs, but I think it's hard to say whether the wg should take this problem
until unless the "existing mechanisms" that some feel are adequate are
summarized somewhere.

Also, with IGMPv3/MLDv2, where reports are not suppressed, shouldn't this be
easier to accomplish without some other protocol?

Bert

> > Dave Thaler : Layer 3 solutions involving only IGMP and MLD are not 
> > at the right layer. For the last hop
> L2 mechanisms
> whether they considered this as an important problem space (and not so 
> much about the draft itself).  Maybe 'this' in the minutes needs be 
> expanded, at least...
>