[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Isis-wg] [rbridge] Why is MTU discovery important?
Eric,
Sorry if my message wasn't clear. See below...
On Sat, Apr 11, 2009 at 3:06 AM, Eric Gray <eric.gray at ericsson.com> wrote:
> Donald,
>
> First of all, you're not characterizing the problem; you're
> characterizing possible solution choices to the problem.
My characterization of the problem was 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.)". I continue to
believe that is a correct, if limited, characterization of 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 said "Consider the follows two possible pairs of messages:" and
discussed two possible pairs. I didn't claim these were the only
choices. Sorry you disagree with my opinions on these messages.
> 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.
No, there is no way a simple message will work. It has to include the
priority and holding time for DRB determination (unless you want to
add one or more additonal kinds of message to the mix which would also
have to be short). It has to include the Designated VLAN for proper
exchange of IS-IS Neighbor TLVs and adjacency formation to occur. It
has to include other fields and flags as I've discussed before in this
thread. It has to be securable, so you have to invent a new security
mechanism or support the IS-IS Security TLV.
As has been pointed out by Jim Carlson, the only person that I know
has running code, a padded Hello plus a small simple ping will fail.
> 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.
I do not believe that adding a padded ping and coupling it to the
adjacency mechanism would be as complex as re-inventing the entire
IS-IS protocol. However, it is possible to oversimplify what would be
involved in a padded ping. For example, it would also need to be
securable...
> 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.
I have thought about and I still think that a padded Hello plus a
simple unpadded ping will fail. You clearly need two messages (or
more) but thinking about it, I'm dubious that either of the two can be
made really simple.
Donald
> 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
>
--
=============================
Donald E. Eastlake 3rd +1-508-634-2066 (home)
155 Beaver Street
Milford, MA 01757 USA
d3e3e3 at gmail.com