Subject: AW: mboned: Fwd: IEEE 802.1 liaison query from MBONED w.r.t usage of GMRP

From: "Leymann, Nicolai" <[email-masked]>
Date: Tue, 25 Jul 2006 11:40:22 +0200

Hi,

> -----Ursprüngliche Nachricht-----
> Von: [email-masked] 
> [mailto:[email-masked]] Im Auftrag von Cao Wei
> Gesendet: Dienstag, 25. Juli 2006 04:37
> An: Marshall Eubanks; Tom Pusateri
> Cc: [email-masked]; Pekka Savola
> Betreff: Re: mboned: Fwd: IEEE 802.1 liaison query from 
> MBONED w.r.t usage of GMRP
> 
> In my point of view, GMRP is complex and is not a good solution.
> 
> I don't know what MRP is, but I want to know if the new 
> protocol also requires host's participation or not. The key 
> question is how to provide multicast information to bridges. 
> 
> Cao Wei
>
MRP (Multiple Registration Protocol) and MMRP (Multiple Multicast Registration 
Protocol) are defined in 802.1ak which is currently under standardization by
IEEE. From my understanding only group addresses are used (because no L3 infor-
mation is available on L2) for forwarding and membership decisions (Source
Specific Multicast seems to be not possible).
 
But I will have a more detailed look on the standard during the next days.

  Regards

    Nic
 
--
Dipl. Inf. Nicolai Leymann
 
T-Systems Enterprise Services
Senior Expert, IP-Technologies
Systems Integration
Technologiezentrum
Engineering Networks, Products & Services 
Packet based Carrier Transport Networks 
Goslarer Ufer 35, D- 10589 Berlin 
Tel +49 30 3497-3570 
Fax +49 30 3497-3571 
Mobile +49 170 2275345
E-Mail: [email-masked]
Internet: http://www.t-systems.com

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

---

From: Beau Williamson <[email-masked]>
Date: Tue, 25 Jul 2006 15:23:15 -0500

>Specific Multicast seems to be not possible).

This sounds like a non-starter to me.

We HAVE TO move to a L3-aware L2 forwarding model or SSM can't be properly 
supported at L2.  Thus, this MMRP thingy would totally kill SSM before 
we've had a chance to truly get it off the ground.

Beau Williamson

---

From: Pekka Savola <[email-masked]>
Date: Wed, 26 Jul 2006 07:37:27 +0300 (EEST)

On Tue, 25 Jul 2006, Beau Williamson wrote:
>> MRP (Multiple Registration Protocol) and MMRP (Multiple Multicast 
>> Registration Protocol) are defined in 802.1ak which is currently 
>> under standardization by IEEE. From my understanding only group 
>> addresses are used (because no L3 infor- mation is available on L2) 
>> for forwarding and membership decisions (Source Specific Multicast 
>> seems to be not possible).
>
> supported at L2.  Thus, this MMRP thingy would totally kill SSM before we've 
> had a chance to truly get it off the ground.

My understanding of what Nicolai said was subtly different.  My take 
was: SSM would still work just fine, but flooding reduction would be 
done in the context of the group address.  Hence, if G in (S,G) or 
(*,G)'s received on a LAN would overlap, non-receivers would get 
multicast at L2 and it would be filtered out at L3.  I do not 
necessarily see this as a show-stopper, as IP->MAC multicast mapping 
has significant overlap as it is already so this can already happen.

That said, I'm rather skeptical of deployability of any changes that 
would involve host modifications..

-- 
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: John Zwiebel <[email-masked]>
Date: Wed, 26 Jul 2006 09:37:04 -0700

On Jul 25, 2006, at 9:37 PM, Pekka Savola wrote:

>
> My understanding of what Nicolai said was subtly different.  My  
> take was: SSM would still work just fine, but flooding reduction  
> would be done in the context of the group address.  Hence, if G in  
> (S,G) or (*,G)'s received on a LAN would overlap, non-receivers  
> would get multicast at L2 and it would be filtered out at L3.  I do  
> not necessarily see this as a show-stopper, as IP->MAC multicast  
> mapping has significant overlap as it is already so this can  
> already happen.
>
> That said, I'm rather skeptical of deployability of any changes  
> that would involve host modifications..
>

2cents, if an L2 switch can not restrict its forwarding to a single
multicast (S,G) customers will not buy that switch.  Which leads to
vendors having to promulgate a proprietary protocol.  (Perhaps
that's a good thing for my company? ;-)

Caveats:
   -- where is the switch deployed
   -- what does the customer anticipate as the distribution of receivers
   -- what is the performance of the switch  (ie a low-end switch may  
not
	have enough receivers on it to matter.)

Pekka is correct that we already have the L3/L2 multicast address  
overlap,
but that model has been broken since the beginning of multicast.  (One
understands the reasons for the choice though, one just doesn't  
understand
why no effort has been made to remedy the problem).

I view the address overlap as a significant problem.  Of course, that's
because I believe that there will "someday" be a lot of multicast.  (But
then I also believe that L2 switches are becoming as complicated as  
L3 routers
and "soon" will be unable to maintain the significant improvement in  
performance
or cost that would keep them viable. Depends, of course, on one's  
time horizon.
Maybe "soon" is really "someday"?  How 'soon' 'someday' gets here is  
the question.)

Given that the new proposals do not address how to differentiate the  
L3 stream,
I would conclude that these new IEEE proposals are going to go down the
same path as GMRP.
_______________________________________________________________
user interface: http://darkwing.uoregon.edu/~llynch/mboned.html
web archive:  http://darkwing.uoregon.edu/~llynch/mboned/