[rbridge] Proposed details for announcing endnodes

[Radia Perlman]

Yeah. Moving endnodes is always an issue. Even with bridges. The problem 
with having R1 (the one announcing that endnode E is
attached to R1) having a very short learning cache is that makes R1's 
endnode announcement LSP information annoyingly volatile. The problem
with the learning
cache timer being long is that R1 can be a black hole, sucking traffic 
away from where E really is.

There are some layer 2 protocols, I believe, with explicit registration 
and keep-alives. (anyone care to chime in about which protocols
these are?). Endnodes learned that way are good candidates for 
explicitly advertising.

For attached IP endnodes, R1 could do something like, if it seems 
someone else advertise E, R1 could do an ARP to see if E is
still there. And there might be similar purely layer 2 "pings". (are there?)

Also, if R1 is the only one advertising E, it doesn't really matter if E 
isn't there, so long as nobody is trying to send traffic to E.
So R1 could delay attempting to see if E is there until someone tries to 
talk to it.

Radia



Anoop Ghanwani wrote:
> 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
>>
>>