| As someone who as been designing and coding this stuff since before most of our current crop of engineers were born, I'll throw in some practicalities:
1) The thing we call "IS-IS" that has a NLPID of 0x83 (IIRC) can only be changed in an upward-compatible manner. So any proposal to change anything in the existing L3 IS-IS beyond the addition of a new PDU type is a non-starter (and even that is likely to break some dubious implementations, which may or may not be a bad thing).
2) If TRILL ends up as a distinct protocol (by NLPID or some other mechanism) it can do things any which way it pleases. It is best from an implementation perspective to keep it as close to IS-IS as possible so that a single implementation with a few checks here and there can do both. This has the added advantage that foolish implementors will cut-and-paste the code and create themselves maintenance problems and allow Darwinian selection to occur, like back in the NLSP days. ;-) But it is entirely possible to share 99% of the code while maintaining protocol "distinctness." And having it distinct from IS-IS avoids having to be forced to make compromises to avoid breaking IS-IS (at the cost of less common code).
Just my 112 ZMK.
--Dave On Apr 11, 2009, at 10:01 AM, Don Fedyk wrote: Hi Radia Well you are correct that some of the terminology is imprecise. I don't agree with some of the characterization. I would agree we should use more precise terminology. I was actually being very precise my last couple of emails. (I hope people are still reading them.) We are dealing with two worlds here. Sorry it is not a level playing field: - IS-IS design and working system.
- Trill proposals which leverage 1.
In my books 1. current operation takes precedence because it is both problem and solution. It is deployed and working. So we can't just go in and change things and expect it to work with out careful analysis. But accurately describing what it is doing is a good idea. For 2. we have a problem that needs to be described. Let stick to the problem description. Define an "ideal" solution mechanism outside of IS-IS mecjhanisms and describe it with the same accuracy. Only then can we look at 1. and see what portions are applicable if any. Terms we need to agree on: "minimum MTU" or "The too small MTU Problem for IS-IS" "Neighbor Discovery" "IS-IS Adjacency" "RBridge Adjacency" "Number of RBridges that attached on a LAN" <- There is no equivalent for this in IS-IS "IS-IS Hello" "minimum MTU probing" "MTU discovery" <- Should not be used. IP does MTU discovery. IS-IS does not. Unfortunately _is_ the title of this thread! Regards, Don On Sat, Apr 11, 2009 at 1:23 AM, Radia Perlman <Radia.Perlman at sun.com> wrote: Yes, what Donald Eastlake said is right.
I think there are several things confusing people:
a) the subject line of this thread, which is a discussion having little to do with the subject line
b) calling both "neighbor discovery" messages and "MTU probes" "Hellos".
Frankly, "Hello" is not a particularly descriptive name for either thing, and it was probably my fault for
calling it that 30 years ago. I suggest we call neither one of them "Hello"s.
c) discussing both mechanisms (neighbor discovery, and MTU probing) in the same thread.
Layer 3 IS-IS happened to solve both problems (nbr discovery
and MTU discovery) with the same message type, and one
mechanism that somehow did them both. We've established that TRILL can't
get away with that. So we need one protocol for neighbor discovery and one for MTU discovery.
As I said, using the nondescriptive term "Hello" is confusing people, so I suggest we
use the terms "neighbor discovery message" and "MTU probe/ack" for the message names.
Nobody has claimed that unpadded Hellos does not safely and simply accomplish neighbor
discovery. I think we should put "neighbor discovery" to bed at this point, perhaps renaming
the message in the spec from "Hello" to "neighbor discovery message", which would
be bit-wise identical to the thing we were calling an "unpadded Hello" or a "protective Hello".
And start up a new thread for MTU discovery. I suspect people really are not happy with
"ignore the problem" or even "defer the problem". If the chairs think that is not necessarily
true, and the WG might prefer "ignore" or "defer" MTU discovery, I suggest we
have a different thread with a subject line "should we bother doing MTU discovery".
Assuming the WG does want to solve MTU discovery, we should do so.
It will not be technically difficult.
It will involve some simple pinging thing with padded messages. I propose we
not call those messages "padded Hellos", but instead call them "MTU probe".
Radia Donald Eastlake wrote: Hi Don,
The way I would characterize the problem is as follows:
There have to be two different messages. (Actually, it's at least
two, since you can always come up with even more complex schemes.)
Consider the follows two possible pairs of messages:
(1) Use padded Hellos for MTU. Now you have to add a short
message for safety. Unfortunately, this short message has to be a
fairly complex short message with many fields that are the same as a
Hello and has to participate in various Hello mechanisms.
(2) Use unpadded Hellos for safety. Now you have to add a padded
message for MTU but MTU message can be a simple ping like message.
Alternative 1 sure sounds more complex to me.
Donald
On Fri, Apr 10, 2009 at 9:51 PM, Don Fedyk <don.fedyk at gmail.com> wrote:
Hi Radia
b) is a not side issue. Problem b) is characterized by ensuring the
minimum MTU for IS-IS is met or removing the IS-IS adjacency. IS-IS fills
LSP up to the minimum MTU as part of its operation. Initially when there is
not much information to exchange the frame size is small, but as information
gets added the LSPs grows to the minimum MTU size then IS-IS fragments them.
So if you are not sure the minimum MTU limit is supported everywhere and
continuously monitored then the probability increases there will be missing
LSPs. Missing LSPs is a big problem. b) is therefore a problem for proper
operation of Trill too.
In IS-IS where b) is the problem, padding Hellos is the current solution
and it safeguards IS-IS. Missing Hellos take down the adjacency (ie become
unaware of any other IS-IS capable systems on the link) if the minimum MTU
is not supported (cut off the link to save the rest of the network network).
It is also a good thing to have the initial packet you send fail the
minimum MTU check if it is going to fail. It makes little sense to exchange
messages further for IS-IS operation.
Problem a) Is a problem characterized by knowing all RBridges attached to a
common LAN for correct operation of the LAN and the RBridges. IS-IS
between the RBridges on the LAN does not need to be operational in order to
solve this problem.
So to summarize:
* In IS-IS padded hellos is the current solution to b) * And you are
proposing in Trill unpadded hellos is the solution to a)
* Both a) and b) must be solved in Trill
So we have deadlock.
That is why some of us suggested a while ago that another solution to a)
outside using IS-IS Hellos is preferable. I know that makes it
inconvenient because IS-IS has a really easy way to announce itself over a
LAN using Hellos. It is oh so close. It works most of the time. But
re-engineering IS-IS hellos to solve a) means you now need a solution for b)
where you already had one..
To break the deadlock the solution in a) and b) must be decoupled and I have
seen little evidence that IS-IS people are clamoring to change the current
solution for b). So the sooner we agree that a) should be solved outside of
IS-IS Hellos (and I'm not saying how just why), then I think we could make
progress.
Regards,
Don
Radia Perlman wrote:
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
_______________________________________________
Isis-wg mailing list
Isis-wg at ietf.org
https://www.ietf.org/mailman/listinfo/isis-wg
_______________________________________________
Isis-wg mailing list
Isis-wg at ietf.org
https://www.ietf.org/mailman/listinfo/isis-wg
|