Re: [Isis-wg] [rbridge] Why is MTU discovery important?

[Don Fedyk <don.fedyk at gmail.com>]

Hi Kris

 

I think you have enumerated a number of options but in general we could summarize most of the them all as:

 

Separating Neighbor discovery out from IS-IS and running vanilla IS-IS.

 

What I would recommend is:

Run a protocol that does Neighbor Discovery and handshake (Might look like IS-IS Short Hello frames, and minimum handshake logic but it is not IS-IS)  Call it the Trill discovery protocol.

If Trill Neighbor discovery aspect only works in one direction for some obscure reason the handshake won't complete but at least it should prevent multiple RBridges assuming they are the DRB.

If the handshake completes then this protocol is happy and all it does is trigger vanilla IS-IS (which may use a different NLPID or whatever) and Trill discovery continues in the background.

 

If IS-IS ever restarts, breaks down or looses adjacency the Trill discovery would be there as a safety net continuing the neighbor discovery at a minimum. 

 

In this design of a solution: Clear separation of  function from IS-IS would satisfy the requirements and allow IS-IS to remain in tact.

 

Yes there is a little duplication of Neighbor discovery and handshaking functions but I think the separation is worth the cost of reusing the IS-IS logic in tact. 

 

Cheers,

Don (The best I can do in the spirit of the Easter egg hunt  )

 

 

On Sun, Apr 12, 2009 at 12:08 AM, Kris Price <trill at punk.co.nz> wrote:

OK. Defining the problem and the general courses of action, and then the eliminating them.



In normal layer-3 operation, the failure of IS-IS to discover a neighbouring router is of minor consequence.

For TRILL the failure of IS-IS to discover a neighbouring RBridge is a problem. TRILL defines a special RBridge role, known as the designated forwarder, and uses IS-IS to elect which RBridge on each link will perform this role.

When an RBridge does not recieve the IS-IS Hellos of its neighbours it will assume it is alone on the link, and therefore elect itself the designated forwarder.

The designated forwarder role elevates an RBridge from merely forwarding TRILL data frames between the TRILL speakers in a TRILL cloud, to encapsulating and decapsulating Ethernet frames onto and off of LANs.

This is where the danger arises. When more than one RBridge performs this role, a loop forms. There is no bad news in regards to forwarding TRILL data frames.

So the *split* comes at this elevation of "bridging" between the TRILL data frames and the Ethernet frames. In elevating a router from being a forwarder of Layer 2.5+ frames, to being an encapsulator/decapsulator from the routed layer into the LAN layer.

You could leave IS-IS as is if an RBridge had some other mechanism to know if it should elevate itself into this position.


Option 0:

Use some kind of involvement in the STP to trick it into breaking loops. But this has been completely rejected by the WG several times, and will never (by the looks) be given a lifeline. So it's not worth considering.


Option 1:

Could you use a repurposed configuration BPDU or similar to announce your presense as an RBridge onto a link? You wait for a period of X seconds, and if you do not see any announcements, proceed as normal, elevating yourself (or someone else) into the designated forwarder role.

Maybe you could have some new TRILL OUI that RBridges map their nicknames and priority into for the Bridge IDs, and then they transmit these. Perhaps it can even carry more useful info in some MST like way.

How this is achieved is beyond my current level of STP knowledge, so someone more educated on STP would need to explore that avenue if they found it interesting.


Option 2:

If you cannot use STP in some way like this, you need a new protocol, but it will not be simple because it becomes constrained by the VLAN topology. It does not see a physical bridged LAN as one link, like a BPDU does, it sees it as many links.

So you have solve those problems and to do something similar to what TRILL does with the IS-IS hellos, protection hellos, etc. In that case you might as well move all that protection hellos etc. into this new protocol, and leave IS-IS as untouched as possible.

So I think this option is about leave IS-IS as is and create an all new "TRILL Discovery and Election Protocol for All Link Types(tm)," and running the two protocols together.

Pros: TRILL doesn't have to modify IS-IS and become responsible for porting IS-IS enhancements, etc.


Option 3:

Modify IS-IS for TRILL's needs but call it something different, maybe "RB-RB". RB-RB would share 99% of the code with IS-IS, but is customised for TRILL's specific needs. Solve the problems in an appropriate way, as has been suggested, or maybe a variation of.

Pros: Already undergone some customisation for TRILL's needs. It seems to be what you would naturally come up with if IS-IS didn't exist, one protocol to rule them all, rather than multiple.



Moving forward:

1. Someone who knows STP and BPDUs would need to come up with a working suggestion for Option 1, or it's out the window. Put a timer on it, say a week.

2. It looks like people are split between Option 2 and Option 3. So would the WG even accept moving some existing customisation into an external protocol as per Option 2?

3. If not, those opposed to Option 3 should ask themselves if it is worth pursuing, given it would end up as a split between half of Option 2 and half Option 3.

4. If so, we're still stuck at coming up with two competing protocols, but perhaps, given how key it is, it is worth developing and comparing two proposals in that case. (So long as the effort isn't wasted, see 1, 2, and 3 above.)



For me Option 1 is slightly preferable. Otherwise I can go either way on Option 2 or 3. But I wouldn't like to see a split between half an Option 2 and half an Option 3.



Hope you all found your chocolate eggs.

Cheers
Kris