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

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

Dinesh,

In IS-IS there is a hard limit MTU size, say 1472 or whatever. MTU
discovery through padded Hellos is done to ensure that adjacencies that
can't support that size don't get established.
If M2 is too small, then R2-R3 would not form an adjacency, and
as a result data, LSPs, etc., would not be sent over the link.

So, likewise, in TRILL we'll enforce a minimum link size, and the 
question I was asking was whether
it should be a constant forever (say 1450 types), or whether we can 
allow a TRILL campus to be configured
to require all the links to have some higher-than-1450 link size?

Radia



Dinesh G Dutt wrote:
> Radia,
>
> What I don't understand is how L3 IS-IS solves this problem. Consider 
> a trivial topology where three routers are connected thus:
>             R1 --- R2 --- R3
>
> Let's say the link between R1 and R2 has an MTU, M1, and the link 
> between R2 and R3 has an MTU, M2. Let M1 > M2. Even with padded 
> Hellos, how is the problem of R1 sending an LSP that exceeds M2 (but 
> not M1) handled ?
>
> Dinesh
> Radia Perlman wrote:
> > OK. It's clear we should NOT pad Hellos.
> >
> > It also seems like enough people would feel uncomfortable with not 
> > doing MTU discovery that we should make
> > sure there is a mechanism for that also.
> >
> > So can we focus for a minute on the following question, "whether to 
> > make MTU size a forever constant,
> > or configurable in a campus", as described below.
> >
> > The simplest option is to pick some minimum size, say 1450 bytes, put 
> > that in the spec now, and forever
> > say that TRILL Hellos and LSPs cannot be bigger than that.
> > MTU discovery would be done to ensure that
> > every link can handle 1450 bytes, and not use (not report in LSPs) 
> > links that can't handle that.
> >
> > However, my preference is to have an optional TLV in the LSP that 
> > says "campus-wide MTU size". This TLV
> > would only be relevant if:
> > a) it is larger than 1450, and
> > b) it is in the LSP of the highest priority RBridge in the campus.
> >
> > If we put that in, then we would be enabling TRILL campuses that 
> > support jumbo frames.
> >
> > The rule is that if the highest priority RBridge says MTU size should 
> > be 10000 bytes, then all RBridges would adjust
> > their buffer sizes, and test their adjacencies to ensure they could 
> > handle 10000 bytes, and if they don't
> > then stop reporting those links (just like they would with the 
> > simpler proposal if the links
> > couldn't support 1450).
> >
> >
> >
> >
> > _______________________________________________
> > rbridge mailing list
> > rbridge at postel.org
> > http://mailman.postel.org/mailman/listinfo/rbridge
> >
> >