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

From: Marshall Eubanks <[email-masked]>
Date: Mon, 24 Jul 2006 21:00:33 -0400

Here is the most important bit here :

> So, to answer to your question about GMRP: "It's obsolete. It has been
> replaced by something much better, for bridges' purposes, MMRP.  We do
> not expect hosts and routers to use MMRP for obtaining IP multicasts.
> But, we would like to talk to you about possibilities for  
> satisfying our
> needs for source information, while avoiding a repeat the IGMP
> experience, wherein bridges had to add hardware features in order to
> snoop on the IETF control protocol."

A question I would have : Is there a need for a link layer protocol  
to do this ? If one
were to be developed, would it be used ?  As
Norman Finn says,

> it is unknown whether snooping on IETF protocols, or adding a
> new protocol to hosts' and routers' repertoires is the better way to
> supply bridges with this information.

Personally, I suspect that any new protocol will have a hard road to  
overcome the deployment
of IGMP snooping.

Regards
Marshall

Begin forwarded message:

> From: "Wijnen, Bert (Bert)" <[email-masked]>
> Date: July 20, 2006 7:07:49 PM EDT
> To: Hiroshi Ohta <[email-masked]>, Marshall Eubanks  
> <[email-masked]>
> Cc: "Dan Romascanu (E-mail)" <[email-masked]>, "Bernard Aboba  
> (E-mail)" <[email-masked]>, Pekka Savola <[email-masked]>,  
> "David Kessens (E-mail)" <[email-masked]>
> Subject: RE:  IEEE 802.1 liaison query from MBONED w.r.t usage of GMRP
>
> MBONED WG chairs,
>
> The below proposed answer has been agreed to at this weeks 802.1
> meeting. It is not a formal liaison response, because we also did
> an informal liaison request. But it does represent (informal)
> agreement from 802.1 as discussed at the1r closing plenary
> on 20 july 2006.
>
> I assume you wil further communicate this back to the WG.
>
> Bert and Dan
>
> -----Original Message-----
> From: IEEE 802.1 list-owner On Behalf Of Norman Finn (nfinn)
> Sent: Thursday, July 20, 2006 15:07
> To: [email-masked]
> Subject: [802.1 - 456] Communication with IETF
>
>
> These were the questions from IETF regarding GMRP, along with my
> proposal for an answer.
>
> Question from IETF MBONED WG
> IEEE 802.1D-2004 GMRP implementation/deployment
>
> MBONED WG is in the process of writing a multicast routing  
> architecture
> [1]. One part of that is flooding reduction in LAN networks. The most
> typical solutions deployed include IGMP/MLD snooping, but IEEE
> 802.1D-2004 (and previous, separate specifications) also describe GARP
> Multicast Registration Protocol (GMRP) which could be used between a
> host and a switch to perform multicast flooding reduction.
>
> However, GMRP requires support at both the host stack and the  
> switch. We
> know about at least one switch stack GMRP implementation, but it is  
> not
> clear whether there is more widespread support. It is not clear  
> whether
> host stacks support GMRP.
>
> The current MBONED WG document [1] states that GMRP "implementation
> status is unknown".
>
> What does IEEE 802.1 think is the current status of LAN IP multicast
> flooding reduction?
>
> What does IEEE 802.1 see as the vision for LAN IP multicast flooding
> reduction?
> Deployment/implementation status?
>
> Could you summarize the implementation status of GMRP both at host and
> switch stacks?
>
> Could you summarize the deployment status of GMRP both at host and
> switch stacks?
>
> PROPOSED ANSWER
>
> At the time GMRP was prior to publication in (IEEE Std.  
> 802.1D-1998), it
> was not clear what was the best way for bridges to prune back  
> multicast
> addresses.  The original intention of the standard was that routers  
> and
> hosts would run both L3 multicast control protocols and run GMRP.  A
> host that wanted to receive a particular IP multicast would issue both
> IGMP and GMRP.  The bridges would pass IGMP transparently through, to
> the routers, and use GMRP to prune the bridged paths.
>
> Among the assumptions made by those standardizing GMRP were that
> multicast would be a large proportion, if not most of, the traffic
> carried by a bridge, that there would be other sources of multicast
> frames besides IP.  Furthermore, because IGMP specified that the
> destination MAC address of an IGMP packet was the same as that used by
> the corresponding data flow, it was not clear whether bridge vendors
> would be willing to make the hardware changes to then-current  
> bridges to
> enable them to violating layering rules and "snoop" on IGMP.
>
> In the event, IGMP snooping became the norm.  Implementations of GMRP
> are rare, and in fact, a proposal to remove GMRP from IEEE Std
> 802.1D-2004 was seriously considered.  Similarly, there was very  
> little
> support for GMRP's cousin, GVRP, that pruned back the distribution of
> broadcasts and flooded unicasts based on VLAN, rather than by
> destination MAC address.
>
> New work was begun in 2002 on Provider Bridges.  Whereas 100 VLANs had
> been a very large number in the enterprise space, this new effort made
> it clear that, in the provider space, 4094 VLANs were not enough.
> Pruning back these VLANs became important, and it was realized that  
> GVRP
> could not satisfactorily handle that many VLANs.  Also, the work on
> Provider Backbone Bridges, begun in 2004/2005, gave reason for a
> provider to wish to control the distribution of many thousands of
> (non-IP) multicast destination addresses.
>
> One result of the provider bridging activity has been the creation of
> project P802.1ak, Multiple Registration Protocol, which is just now
> coming to completion.  This protocol allows a bridge to express its
> preferences (and anti-preferences) for approximately 4k VLANs or
> consecutive MAC addresses in a single 1500-byte control packet, and  
> for
> the very efficient propagation of that information through a bridged
> network.
>
> Lastly, 802.1 started P802.1aq Shortest Path Bridging, last year.
> Although this project is not as far along as the other projects
> mentioned, it has become clear that, in order to forward unicast  
> frames
> along optimum paths through the bridged network, and also forward
> multicasts optimally, bridges are likely to place a premium on knowing
> which hosts and routers can serve as sources of each multicast stream,
> as well as knowing which want to be sinks.
>
> At this time, in the absence of widespread knowledge in IEEE 802.1 of
> your work, it is unknown whether snooping on IETF protocols, or  
> adding a
> new protocol to hosts' and routers' repertoires is the better way to
> supply bridges with this information.
>
> So, to answer to your question about GMRP: "It's obsolete. It has been
> replaced by something much better, for bridges' purposes, MMRP.  We do
> not expect hosts and routers to use MMRP for obtaining IP multicasts.
> But, we would like to talk to you about possibilities for  
> satisfying our
> needs for source information, while avoiding a repeat the IGMP
> experience, wherein bridges had to add hardware features in order to
> snoop on the IETF control protocol."
>
> -- Norm

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

---

From: Tom Pusateri <[email-masked]>
Date: Mon, 24 Jul 2006 21:10:51 -0400

Ask them to release a spec for MMRP and then we can decide how to respond.

Thanks,
Tom

---

From: Marshall Eubanks <[email-masked]>
Date: Mon, 24 Jul 2006 21:44:22 -0400

Good idea - will do. (Of course, they may not release it publicly   
but I know we have the right to read and
even participate when areas overlap...)

Marshall

---

From: Cao Wei <[email-masked]>
Date: Tue, 25 Jul 2006 10:36:33 +0800

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

---

From: Toerless Eckert <[email-masked]>
Date: Tue, 25 Jul 2006 22:56:17 -0700

> Ask them to release a spec for MMRP and then we can decide how to respond.

Agreed.

> >> snoop on the IETF control protocol."

Can someone translate this into english ? What do they want ?

Obviously, if MMRP simply allows for bridges to define constrained
flooding domains for traffic to MAC multicast addresses, then it does
not improve on it's applicability to IP multicast over GMRP:

 -> Works, but does not provide adequate constrainment.

The bad IGMP experience is likely IGMPv2/MLDv1 requirement to
intercept packets based on IGMP/ICMPv6 protocol types. That particular
requirement is already gone with IGMPv3/MLDv2.

On the other hand, we should get a statement from IEEE why they seem to
insist on maintaining L2 switches to only provide constrained multicast
flooding for MAC address based traffic. The reality of a large number
of IEEE switch vendors has changed to be capable to constrain traffic
based on L3 payload addresses already (like IP multicast source and
destination addresses).  Ignoring this capability and the need to do
so makes MMRP a somewhat futile attempt. What Mac layer multicast traffic
is there that does not actually carry IPv4/IPv6 multicast payload ? 
.. except for a bunch of IEEE protocol traffic like STP ? Which customer
are they trying to define the protocol MMRP for ?

Cheeers
    Toerless

---

From: Cao Wei <[email-masked]>
Date: Wed, 26 Jul 2006 18:00:30 +0800

The latest version of 802.1ak can be find at : http://www.ieee802.org/1/pages/802.1ak.html
Maybe it is a bit late, but I hope this info is helpful.

---

From: "Manfredi, Albert E" <[email-masked]>
Date: Fri, 28 Jul 2006 15:16:38 -0400

I don't know what MMRP looks like, but I do know that there is a need
for an net-layer-agnostic Layer 2 multicast bridging protocol.

Some of us use weird Layer 2 encapsulations that make IGMP snooping a
bit of a kludge. So if there's something more useful or straightforward
than GMRP, let's all have a look!

Bert

> From: Marshall Eubanks [mailto:[email-masked]] 
> Sent: Monday, July 24, 2006 8:01 PM
> To: [email-masked]
> Cc: Pekka Savola
> Subject: mboned: Fwd: IEEE 802.1 liaison query from MBONED 
> w.r.t usage of GMRP
>