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

[Suresh Boddapati <sboddapa at yahoo.com>]

--- On Fri, 4/10/09, Radia Perlman <Radia.Perlman at sun.com> wrote:

> 
> Not padding hellos does not "break IS-IS". 

I am not completely sure. Please correct me if I am wrong.
Let me see if I can construct an example.
    
     1
 A--------B
 \       /
1 \     / 5
   \ C /

The numbers are the respective cost on the links.

Now suppose A has a smaller MTU such that it can see B's and C's hellos and form adjacencies with them. Now B's LSP that describes the link to A happens to be larger than the MTU that A uses on its links. This LSP does not get through to A from either B or C. Consider that the LSP that B uses to describe the link to C is within the MTU limits and does get through.
Since A does not see B's LSP describing the link to A, it will compute a path to B through C.

C sees both A's and B's LSPs and determines that the shortest path to B is through A (note A and B have both advertised their link in their respective LSPs, so the bidirectionality check would pass, it's just that A does not have B's LSP, so it cannot compute the path correctly). You have basically prevented A from being able to get to all destinations that can be reached through B and you have a loop of a different kind. This loop will not go away. The fix in IS-IS for this is to use padded hellos. If you pad, adjacencies wont form between A and B and everything will be fine. 

In TRILL, if you eliminate the padding, you have a TRILL forwarding loop and every frame sent by A to B or anything reachable through B will die in this loop once the hop count reaches zero. I recognize the fact that this is not as bad as the case when RBridges do not see each other, but is this the "weirdness" you say we could live with? IMO, we should make every effort to not have this situation. Debugging this could be real fun. And this is just one example of things going wrong. CSNPs may not get through. Or it is possible they do get through, but the LSPs dont, resulting in constant flooding of those LSPs on those links.

> So, repeating for the nth time....
> Keeping the Hello mechanism exactly as it is in IS-IS today
> will not 
> work for TRILL.
> That should be the end of discussion. Not padding the
> Hellos obviously
> works for robustly finding neighbors, and is a trivial
> change. The
> only thing that gets lost is MTU discovery.
> 
> The only feasible choices at this point are:
> a) only do unpadded Hellos, and live with weirdnesses due
> to not
> testing MTU size, deferring MTU discovery to the future
> b) do unpadded Hellos, and come up with a mechanism for MTU
> discovery now.
> It would be easy to do so.
> 
I would prefer to go with an option that ensures that no LSPs get lost silently due to MTU issues. 

Thanks,

Suresh