[rbridge] Proposal for making per-VLAN instance optional (to listen to)

[Radia Perlman]

First an explanation of the issue:

Some people have expressed a scalability concern: that if there are many 
more endnodes
(that the Designated RBridge R1 knows about) than ones that are talking 
to endnodes
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 
locations from
decapsulated traffic rather than from the per-VLAN instance in which the 
Designated RBridge
announces its attached endnodes. (and other RBridges learn from the 
per-VLAN instance).

So it is OK to make *learning* from the IS-IS endnode announcements 
optional. R2
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, 
since anyone
can send data with any source address and cause disruption. The IS-IS 
announcement
can even modify how definitive the attached endnode is "it enrolled" "it 
enrolled
cryptographically" "I learned it just because I heard a data packet with 
that as source
address"
c) the per-VLAN IS-IS endnode announcements also announce the layer 
3/layer 2
correspondence to facilitate proxy ARP/ND (though that could probably be 
learned
from decapsulated data traffic as well).

***********************
OK, now the proposal:

One suggestion of course is to eliminate the per-VLAN IS-IS instance, 
and make
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 
we don't
care about the other potential advantages of advertising endnodes with 
IS-IS.

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 
to learn
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 
VLAN A
endnode announcements stop.

Even if there are endnodes announcements in VLAN A, it is optional for 
an RBridge
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 
announcements
which are definitive, or that it will learn from endnode announcements, 
but if
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 
VLAN A
to only deliver them to RBridges in VLAN A that say that want to learn 
from them.

***************
What do people think?

Radia