[rbridge] Proposed details for announcing endnodes

[Anoop Ghanwani]

Although I don't think I would be interested
in implementing this aspect of the protocol, I think
this is a reasonable proposal.

There is one concern - how do we deal
with moves?  A move would mean that there are
2 forwarders that think they own the address so
how would they resolve the conflict?

Anoop

> -----Original Message-----
> From: rbridge-bounces at postel.org 
> [mailto:rbridge-bounces at postel.org] On Behalf Of Radia.Perlman at sun.com
> Sent: Friday, April 25, 2008 4:57 PM
> To: rbridge at postel.org
> Subject: [rbridge] Proposed details for announcing endnodes
> 
> 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
> 
> 
> 
> 
> 
> _______________________________________________
> rbridge mailing list
> rbridge at postel.org
> http://mailman.postel.org/mailman/listinfo/rbridge
>