[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Isis-wg] [rbridge] Why is MTU discovery important?
Radia,
Like I said, we need some state diagrams. ISIS has specific states and actions that move the 'neighbor, adjacency, foo from one state to another. These actions are also quite specific; like receiving a valid hello, missing various messages etc. Is an invalid hello even considered a hello? The states are well defined and inter-connected. Adjacency and neighbor are specific terms and as you point out in this thread we have probably not used them consistently and from some of the comments I expect we might not have used them accurately?
With each new 'packet' / 'mechanism' there may be changes to these mechanisms and states. I think we need to display an understanding of the existing mechanisms, and the condition they leave the router in in each case.
Each change to this system is considered a large change.
MT
________________________________
From: isis-wg-bounces at ietf.org on behalf of Radia Perlman
Sent: Sat 11/04/2009 06:23
To: Donald Eastlake
Cc: TRILL/RBridge Working Group; isis-wg at ietf.org
Subject: Re: [Isis-wg] [rbridge] Why is MTU discovery important?
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