Subject: [rbridge] Must/Should flooding optimization

From: Radia.Perlman at sun.com (Radia Perlman)
Date: Tue, 21 Mar 2006 12:34:48 -0800

When a multicast or unknown destination packet is forwarded by RBridges, 
it is sent along the
ingress RBridge rooted at the ingress RBridge. However, RBRidges along 
the way can prune
the packet so that the packet only reaches links that have interested 
receivers. There are two
pieces of pruning information:
a) which egress RBridges are attached to which VLANs (so a packet marked 
VLAN A need not be forwarded
to RBridges that have no links attached to VLAN A)
b) which egress RBridges have interested receivers for IP-derived 
multicast addresses (as learned through IGMP
and multicast router discovery)

Eric Gray pointed out that doing this pruning is only an optimization. 
Bandwidth would be wasted if some
RBridge that was only in the "core" ignored IGMP and VLANs, and 
forwarded all non-unicasts (received
on the expected ingress port for the specified ingress RBridge tree) to 
all potential
outgoing ports in that ingress RBridge tree.

So, he argued that both forms of flooding optimization should be SHOULD, 
because
a) a vendor can build a cheaper device if it doesn't have to bother 
filtering based on these things
b) customers can buy the cheaper device it they'd like to save money, 
and don't care about saving bandwidth,
especially because in their deployment they might not be using VLANs at 
all, and have very little multicast
traffic, or there might be sections of their campus in which filtering 
won't matter for bandwidth
c) even if a vendor were planning on eventually doing all features, this 
would make phased implementation possible.

Others argued that flooding optimization should be a MUST because:
a) the spec is more complicated if things are options
b) "your cheapo nonfiltering RBridge is putting more stress on my 
good-guy RBridge downstream"
c) it's more options for customers to understand in the purchasing decision

Anyway, what do people think?

Should VLAN filtering be a MUST?
Should IP-multicast filtering be a MUST?

Radia

---

From: Radia.Perlman at sun.com (Radia Perlman)
Date: Tue, 21 Mar 2006 12:54:04 -0800

Another issue that we should discuss is how to do IGMP learning. After 
talking
to some multicast people, here is how I think it should work, and it is
different from what I'd specified in the protocol draft:

a) instead of flooding IGMP announcements to every link "in case there's 
an IP multicast
router there" (which is what the current draft says), there is a way for 
RBridges
to learn if there is a multicast router on their port. If so, then the 
RBridge must
announce "I have a link with an IP multicast router" in its 
core-instance of IS-IS.

b) IGMP announcements need not be flooded; they only need to go to links 
on which
there are IP multicast routers. And actually, IGMP announcements must 
not go onto
links with IP endnodes, because some versions of IGMP have an endnode 
suppress an
announcement if they hear an announcement that some other endnode is 
also in that
group (since the IP endnode thinks the whole campus is one link).

This would seem like a contradiction, since the announcement MUST go 
onto a link if
there is an IP multicast router there, and MUST NOT go onto a link if 
there is
an IP endnode...so what would one do with a link that has both? But the 
answer is
that the announcement MUST go onto the link, which will suppress the 
announcement
of the endnode (for some versions of IGMP). But that's OK, because all 
IP multicast
traffic MUST be delivered to all links containing an IP multicast router 
(in that
VLAN).

***********
So now the design:

a) RBridges must do IP multicast router discovery
b) The Designated RBridge must announce,
in the per-VLAN instance of IS-IS, "I have an attached IP
multicast router"
c) The Designated RBridge must listen to IGMP announcements, and learn which
IP multicast addresses have listeners on its attached link
d) The Designated RBridge must flood IGMP announcements, and internal 
RBridges
distribute this along the ingress RBridge tree (of the Designated 
RBridge that
injects the IGMP announcement), and filter whether there are any IP 
Multicast
Routers downstream on that ingress RBridge tree
e) Designated RBridges that see this forwarded IGMP announcement decapsulate
and forward the announcement on any attached links for which there are 
IP Multicast
Routers
f) The Desiganted RBridge announces, in its per-VLAN instance of IS-IS, 
which IP
multicast groups it has receivers for
g) A Designated RBridge that sees a multicast packet (with MAC address 
derived from
an IP multicast address) encapsulates the packet and sends it into the 
campus
on the ingress RBridge tree with itself as "ingress RBridge".
h) Other RBridges forward based on that tree, but filter based on VLAN 
as well as
multicast address. To be more specific, if ports p1, p2, and p3 are 
outgoing ports for that ingress RBridge tree, and if the packet is 
marked VLAN A, then if no VLAN A links
exist on p3, then don't forward onto p3. Now (given that VLAN A is 
reachable from
both ports p1 and p2), forward on p1 if there are multicast listeners 
for that group
reachable on that branch, OR if there are multicast IP routers reachable 
on that branch.

Does this seem right to people?

Radia

---

From: erik.nordmark at sun.com (Erik Nordmark)
Date: Tue, 21 Mar 2006 14:21:25 -0800

Shouldn't the rbridges behavior for IGMP just be identical to IGMP 
snooping bridges?

My (perhaps incorrect) understanding is that this is specified in
	draft-ietf-magma-snoop-12.txt
	RFC 4286 Multicast Router Discovery

The only thing special for rbridges is how they handle the "overlay 
topology" (the topology between the rbridges) - presumably this should 
be viewed as a virtual switch port on each rbridge.

    Erik

---

From: dino at cisco.com (Dino Farinacci)
Date: Wed, 22 Mar 2006 08:43:50 -0800

>> group (since the IP endnode thinks the whole campus is one link).

    Not some but mostly all of them do.

>> traffic MUST be delivered to all links containing an IP multicast router 

    I hate to muddy the waters Radia, but when IGMPv3 is in use, there are
    some router implementations that do explicit tracking of receivers that
    join (S,G). There is no problem here but just wanted to raise attention
    that the IGMPv3 message on this segment would be sent by the end-node and 
    there is no suppression happening (in IGMPv3 only).

>> a) RBridges must do IP multicast router discovery
    
    Which means packets addressed to 224.0.0.13 (or 01005e.00000d) must be
    flooded on the broadcast tree (per VLAN) built by IS-IS.

>> on the ingress RBridge tree with itself as "ingress RBridge".

    So you didn't say where it forwards the packet. And it is implied from
    this text that it could be on the ports where you received IGMP reports.
    But I know from our conversation yesterday it is based on the group
    advertisements in LSPs.

>> Does this seem right to people?

    At a high-level yes. You could add to f):

    "The outgoing port list is made of the ports that lead to all egress-
    Rbridges which have announced the group MAC address within a VLAN."

    Then you can refer to this port list in h).

Dino

---

From: dino at cisco.com (Dino Farinacci)
Date: Wed, 22 Mar 2006 17:04:53 -0800

>> Bandwidth would be wasted if some

    Wasting bandwidth is a non-starter. These boxes can go into enterprises
    who abandoned dense-mode PIM 8 years ago. And dense-mode PIM does "flood
    then prune". 

    We shouldn't repeat past sins.

    We need to prune by default, this has to be a part of the foundational
    design. Or else, we have a non-starter. I mentioned this in the working
    group hence my strong position on making this a MUST.

>> Radia

    I had a conversation with Radia, and these were points we wanted to post
    to make people think and comment about:

    o Router discovery is done by listening to 224.0.0.0/24 packets
      from routers which need to be flooded to all router ports (ports leading
      to routers on the edge of the rBridge network) versus flooding on
      the broadcast tree to all edge rBridges.

    o IGMP reports which need to be forwarded through the rBridge network
      are encapsualted in a new special MAC group address when encapsulation 
      occurs so core rBridges can forward such packets on router ports. If
      this is not done and the inner group address is used as the outer
      group address, then data packets to the group and IGMP reports to the 
      group would have to go everywhere. We want data packets to go to
      receivers only and IGMP reports to go to routers only (and no where
      else).

    Comments?

Dino