[rbridge] Proposed details for announcing endnodes

[Radia.Perlman@sun.com]

The unfortunate choice of the words ('per-VLAN instance of IS-IS") for the protocol in
which endnodes would be announced has definitely confused people, so let me
give details about how I think it should work.

What we want to accomplish: If R1 is a VLAN-A forwarder on at least one link, R1 wants to inform
other VLAN-A forwarders about at R1's attached VLAN-A endnodes.

The proposal:

a) R1 multicasts a packet throughout the campus, directed at VLAN-A. This packet is encoded as a link
state packet, with a sequence number. If it is too large to fit into a single packet IS-IS allows LSP "fragments",
where each fragment is separately flooded, and has its own sequence number. If data in one fragment changes,
that fragment needs to be flooded, but unchanged fragments do not need to be.

b) An RBridge that is not a VLAN-A forwarder on any of its links participates in the
flooding of the packet on the tree chosen by ingress R1, but does not otherwise process the packet.

c) If R2 is a VLAN-A forwarder on at least one of its ports, it stores R1's most recently generated packet, in order
to fold the information into its endnode learning table (to know that those endnodes should be forwarded
to R1)

d) To ensure reliable delivery of R1's announcement, we need for one of the VLAN-A forwarders to take
on the responsibility of sending an IS-IS CSNP periodically.

e) Traditionally, IS-IS would choose which switch is responsible for sending a CSNP, by sending Hello messages
and doing a DR election. However, in this case, the LSPs in the "core instance" of IS-IS gives enough information
for all the RBridges to know which RBridge should be issuing the CSNP. The necessary information is for R1
to announce (in its core LSP), which VLANs R1 is VLAN forwarder for. Note: This information is already
in the protocol spec.

However, since generating and processing VLAN A endnodes announcements is optional, we should add
a flag that says "I participate in the endnode announcement protocol for VLAN A".
There are two reasons for this flag: one is that if R1 is the only VLAN-A forwarder that participates, then R1
should not make announcements (since they'll just be ignored). The other reason is to elect (without
further protocol message", the VLAN-A forwarder that will periodically send CSNPs.

f) Based on (priority, ID) one VLAN-A forwarder will be elected to periodically issue CSNPs. However, if
any VLAN-A forwarder hasn't seen a CSNP recently, it is not problem for it to send a CSNP.

********************
So...what is the cost of this?

Already we have the information in R1's LSP about which VLANs R1 is forwarder for. I'm not sure whether we
already have the flag "I participate in endnode announcements for VLAN A".

The information about attached endnodes is in the format of IS-IS endnode announcements. No other information
appears. The endnode announcement LSP gets flooded like any VLAN A multicast/unknown destination data
packet, so that it will be delivered to all RBridges that are VLAN A forwarders.

One of the VLAN A forwarders sends periodic CSNPs so that if any RBridges miss any of the announcements,
this will be detected and corrected.

Radia