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
_______________________________________________
Isis-wg mailing list
Isis-wg at ietf.org
https://www.ietf.org/mailman/listinfo/isis-wg