[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

Suresh,

I agree that it would be good to solve both problems:

a) ensure that RBridges see each other (unpadded Hellos is the the solution
that has been proposed), and
b) some mechanism to assure there is agreement about what the campus-wide MTU size should be, and assure that the paths computed only include links that meet that MTU size.
It would not be difficult (technically) to solve b) but a) is more important, so I can live with 
deferring b) and shipping the spec.

If people would like solve b) now, then fine, I'm sure we can come up with
a mechanism to do that. But we have to ensure that that mechanism does not interfere in 
any way with a).
The problem is that discussing both problems at the same time seems to be confusing people.
I think we should agree on this thread that we need to do unpadded Hellos to solve problem a), and start a second thread about what to do about problem b), e.g., "ignore it", "defer it until 
later", or "here's a candidate solution".

Radia







Suresh Boddapati wrote:

--- 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