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

[Radia Perlman <Radia.Perlman at sun.com>]

Another reason I think people are getting confused is the use of the 
term "use vanilla IS-IS".
"Vanilla IS-IS",
where MTU discovery is all interlinked with choosing DRs, and where the 
result can be
multiple DRs, will not work, as has been said many times on this thread, 
and people don't
know what "just use vanilla IS-IS" means.

So, do not use the phrase "use vanilla IS-IS" as a shorthand for
any part of the solution. It only confuses people. Certainly
*I* have no idea what anyone means when they use that phrase, especially 
since
it's clear that we can't "just use vanilla IS-IS".

Now, to try to get us back on track:

There are three problems TRILL needs to solve, (given that
it's pretty clear people don't want to defer or ignore the MTU issue),
and the discussion should
be around how to solve each problem.

The three problems that must be solved:

a) on a link, choosing one and only one DRB, who will be assigning 
designated
forwarders, dictating which VLAN is the designated VLAN, naming the 
pseudonode, etc.

b) having all RBridges agree on what the campus-wide MTU size should be, 
say S.

c) having all RBridges test, for each link and each neighbor, which ones 
can handle
size S, and removing those that don't from the topology, so routes are
not calculated through links that can't handle size S.

The solution to a) is what is in the TRILL spec today. It uses unpadded 
IS-IS Hellos,
and has a lot of explanation of what VLANs to send unpadded Hellos on, and
unlike IS-IS, has slightly different logic to ensure there are not 
multiple DRBs
in the face of one-way connectivity, MTU mismatches, etc.

The solution to b) is with adding a TLV into the LSP, where not 
including the
TLV is the same as specifying "1450", and the TLV, if specified must 
have S > 1450.
There are only three plausible ways of using this TLV, I think:
1) look through all the LSPs in your database, and choose the largest 
size S any RBridge specifies, as the
campus-wide S
2) choose the smallest size S any RBridge specifies as the campus-wide S
3) look at the LSP of the highest priority RBridge in the campus, and 
use the S specified in its LSP as
the campus-wide S. (by the way, I prefer this one -- seems simplest and 
most stable)

The solution to c) (testing MTU size), has to be done with padded 
packets of some sort.
It could certainly be done using the same format as padded IS-IS Hellos, 
though
I'd prefer some clear distinction between the MTU-testing packets and 
the DRB election/
VLAN specifying, etc., packets so that the logic of solving problems a) 
and c) don't
get intermingled.

The MTU-testing packet should include a TLV specifying "S", the size 
being tested, and should
be padded to S. We could have unicast acks to this padded packet, or do 
the same sort
of IS-IS-like two-way connectivity announcements, by having R2, in its 
S-padded packet,
list all RBridge neighbors on the link from which it has (recently 
enough) received packets of at least
size S. It would be nice to have some careful thoughtful discussion on 
the mailing list about
what the best way to solve this would be. (e.g., optional, mandatory, 
periodic, once and
assume things won't change, unicast acks vs listing "I heard size S from 
this list"). But
whatever it is would have nothing to do with choosing a DRB, naming the 
pseudonode,
or any mechanisms usually associated with "Hellos".

Radia