[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Isis-wg] [rbridge] Why is MTU discovery important?
Donald,
First of all, you're not characterizing the problem; you're
characterizing possible solution choices to the problem.
And, I don't think you've characterized the choice correctly,
or perhaps it is more accurate to say that you've chosen a specific
characterization that is not necessarily the most appropriate one
in light of the many aspects of the current discussion.
I would characterize the choices as follows:
1) Use padded Hellos for consistency with currently specified IS-IS.
With this choice, you also need to add a short message for loop
(and duplicate delivery) protection. This short message might be
fairly complex (with many fields the same as a hello PDU, and the
need to process this message consistent with hello processing) or
as simple as a message that says "I am a version 1 TRILL Rbridge."
In the latter case, the protocol specification needs to describe
how DRB election takes place if a device is detected that says it
is a version 1 RBridge but no hello messages are received.
2) Use unpadded Hello messages for safety. Now you might add a simple
padded message for MTU, provided that you can do so and still end
up with the protection for control plane message relaying that has
previously been afforded IS-IS via padding of hello PDUs. This
could and up being as complex as re-invention of IS-IS protocol.
In this characterization, it is signficantly less clear that choice 1
is the more complex choice. Yet, if you think it through, you should
realize that this is a more accurate characterization of the choices.
--
Eric
-----Original Message-----
From: rbridge-bounces at postel.org [mailto:rbridge-bounces at postel.org] On Behalf Of Donald Eastlake
Sent: Friday, April 10, 2009 10:43 PM
To: Don Fedyk
Cc: TRILL/RBridge Working Group; Radia Perlman; isis-wg at ietf.org
Subject: Re: [rbridge] [Isis-wg] Why is MTU discovery important?
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
>
--
=============================
Donald E. Eastlake 3rd +1-508-634-2066 (home)
155 Beaver Street
Milford, MA 01757 USA
d3e3e3 at gmail.com
_______________________________________________
rbridge mailing list
rbridge at postel.org
http://mailman.postel.org/mailman/listinfo/rbridge