[rbridge] Proposal for making per-VLAN instance optional (to listen to)
Radia.Perlman at sun.com
Tue Apr 17 12:37:50 PDT 2007
First an explanation of the issue:
Some people have expressed a scalability concern: that if there are many
(that the Designated RBridge R1 knows about) than ones that are talking
on Designated RBridge R2's link, there is no reason for R2 to know about
all those other
endnodes, and the traffic to keep R2 informed about R1's endnodes'
comings and goings
might be a concern.
TRILL will work if some RBridges decide they want to learn endnode
decapsulated traffic rather than from the per-VLAN instance in which the
announces its attached endnodes. (and other RBridges learn from the
So it is OK to make *learning* from the IS-IS endnode announcements
could learn only from the source MAC address of frames it decapsulates
onto its link, even
if other RBridges are learning from the IS-IS endnode announcements.
But we can't make *advertising* attached endnodes optional, because if
there's any RBridge R3
that does NOT want to learn from decapsulated traffic, and wants to
learn from IS-IS announcements, then if all the other RBridges stop
advertising, then R3 will flood everything.
So--you ask--why don't we *only* learn from decapsulated data traffic?
The reasons are as follows:
a) some people have said that router products don't like to learn from
the data plane; they
want to forward traffic without thinking very hard, and want to do the
work of updating
forwarding tables based on control traffic
b) there are some layer 2 technologies in which endnodes enroll, and
being able to announce
these attached endnodes is nice because it is definitive -- you know
when they attach,
you know when they go away -- it's more secure than learning from data,
can send data with any source address and cause disruption. The IS-IS
can even modify how definitive the attached endnode is "it enrolled" "it
cryptographically" "I learned it just because I heard a data packet with
that as source
c) the per-VLAN IS-IS endnode announcements also announce the layer
correspondence to facilitate proxy ARP/ND (though that could probably be
from decapsulated data traffic as well).
OK, now the proposal:
One suggestion of course is to eliminate the per-VLAN IS-IS instance,
everyone learn from data traffic. I don't have strong opinions on that,
but we should
make sure the people doing router products can cope with this, and that
care about the other potential advantages of advertising endnodes with
But I think we can have a compromise that will make both sides happy.
The idea is to have RB1 announce, in its core instance, whether it wants
from IS-IS endnode announcements. If any RBridge in VLAN A wants to learn
from endnode announcements, then all the RBridges in VLAN A MUST send
IS-IS endnode announcements.
But if *all* the RBridges in VLAN A say they don't want them, then the
endnode announcements stop.
Even if there are endnodes announcements in VLAN A, it is optional for
whether it wants to learn from data or from the announcements, or from some
combination of the two (like perhaps it will only learn from endnode
which are definitive, or that it will learn from endnode announcements,
it runs out of room to store them, it will fall back on learning from data).
We could even have core RBridges filter IS-IS endnode announcements for
to only deliver them to RBridges in VLAN A that say that want to learn
What do people think?
More information about the rbridge