Re: [Isis-wg] [rbridge] Why is MTU discovery important?

["Eric Gray" <eric.gray at ericsson.com>]

Radia,

No, what Donald Eastlake said is not "right"; it is one possible 
view of the choices for dealing with the problem, but that does 
not make it necessarily the "right" view.

--
Eric 

-----Original Message-----
From: rbridge-bounces at postel.org [mailto:rbridge-bounces at postel.org] On
Behalf Of Radia Perlman
Sent: Saturday, April 11, 2009 1:23 AM
To: Donald Eastlake
Cc: TRILL/RBridge Working Group; isis-wg at ietf.org
Subject: Re: [rbridge] [Isis-wg] 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
>>
>>     
>
>
>
>   

_______________________________________________
rbridge mailing list
rbridge at postel.org
http://mailman.postel.org/mailman/listinfo/rbridge