Subject: [rbridge] IPMC

From: Selvaraj Rajan <[email-masked]>
Date: Wed, 25 May 2011 23:33:43 -0700

Hi,
Nowadays, a switch forwards IPv4 orIPv6 multicast data packets not just
based on the corresponding derived multicast MAC address, but based on IP
address. Because, this is due to the well known issue that more than one IP
multicast addresses maps to the same l2 MAC address.

So, how does a TRILL enabled switch allows to accomplish IP based multicast
forwarding ?
The usual forwarding logic for switches would be that they should do IP
based switching if the L2 Destination MAC address is 01-00-5e-xx-xx-xx
otherwise L2 multicast switching. But I don't see anything mentioned in this
regard in the draft 16.

Probably this would have been already discussed or eliminated.
whatever it would have been, I would appreciate if you can share me the
details.

Thank you!
Selvaraj
_______________________________________________
rbridge mailing list
[email-masked]
http://mailman.postel.org/mailman/listinfo/rbridge

---

From: James Carlson <[email-masked]>
Date: Thu, 26 May 2011 07:45:36 -0400

Selvaraj Rajan wrote:
> So, how does a TRILL enabled switch allows to accomplish IP based
> multicast forwarding ?
> otherwise L2 multicast switching. But I don't see anything mentioned in
> this regard in the draft 16.

A simple way to do this would be to do what an ordinary bridge would do.
 That is, if you're unaware of IP-based multicast forwarding, then just
forward on the L2 address as always.  If you're aware of it, then
inspect the L3 address contained within those TRILL frames, and prune as
necessary (based on the IGMP/MLD-learned groups) when forwarding.

-- 
James Carlson         42.703N 71.076W         <[email-masked]>
_______________________________________________
rbridge mailing list
[email-masked]
http://mailman.postel.org/mailman/listinfo/rbridge

---

From: Donald Eastlake <[email-masked]>
Date: Thu, 26 May 2011 09:05:12 -0400

See below.

>> So, how does a TRILL enabled switch allows to accomplish IP based

All multi-destinaton frame forwarding in TRILL uses the same
distribution tree or trees. It does not matter if the frame is
broadcast, multicast derived from IP (see RFC 5342, Sections 2.1.1 and
2.3.1 ), multicast not derived from IP, or a unicast frame whose
destination location is unknown.

>> based switching if the L2 Destination MAC address is 01-00-5e-xx-xx-xx

Actually 01-00-5e-00-00-00 through 01-00-5e-7F-FF-FF and
33-33-00-00-00-00 through 33-33-FF-FF-FF-FF as per RFC 5342 reference
above.

>> this regard in the draft 16.

If does not make any difference to basic TRILL forwarding that a
multi-destination frame is IP derived. (As Jim Carlson comments below,
it does make a difference to pruning that tree.) The frame is
forwarded on the distribution tree and it is up to each RBridge to
determine if it should decapsulate a copy of the original native frame
(which it generally does if it is Appointed Forwarder on any port for
the VLAN of the frame) and if it should output a copy of that original
native frame on any particular port (which it generally does if there
is a listener out that port for the multicast group or a multicast
router out that port).

> necessary (based on the IGMP/MLD-learned groups) when forwarding.

I'm not sure, as a practical matter, how much better pruning on IP
address is than just pruning on derived MAC but I believe some
implementations do perform deeper packet inspection and prune on IP
address. They communicate the information about multicast listeners by
IP multicast address using sub-TLVs in the Group Address TLV. The
Group Address TLV is specified in draft-ietf-isis-trill-05.txt, which
is an approved standard. That draft also specifies the Group MAC
Address sub-TLV. The Group IPv4 Address sub-TLV and Group IPv6 Address
sub-TLV are currently specified in draft-drao-isis-otv-00.txt.

Thanks,
Donald
=============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 155 Beaver Street
 Milford, MA 01757 USA
 [email-masked]

---

From: Selvaraj Rajan <[email-masked]>
Date: Thu, 26 May 2011 09:43:39 -0700

Thank you all!
I will come back to discussion if I still see any issue.

Thanks!