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

["Les Ginsberg (ginsberg)" <ginsberg at cisco.com>]

Dinesh -

This problem has been addressed in ISO 10589:2002 - though admittedly
the solution is not commonly implemented. 

The solution involves the advertisement of originatingL1LSPBufferSize/
originatingL2LSPBufferSize in LSP #0. Each system can then compare the
received value to its locally configured value and detect mismatches.

The TLV codepoint for this is: LSPBufferSize 14.

There is a good discussion of the issues about this - as well as hello
padding - RFC 3719 Sections 5 and 6.

   Les


> -----Original Message-----
> From: rbridge-bounces at postel.org [mailto:rbridge-bounces at postel.org]
On
> Behalf Of Dinesh G Dutt (ddutt)
> Sent: Tuesday, April 07, 2009 2:30 PM
> To: Radia Perlman
> Cc: TRILL/RBridge Working Group; isis-wg at ietf.org
> Subject: Re: [rbridge] [Isis-wg] Why is MTU discovery important?
> 
> 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
> >
> >
> 
> --
> We make our world significant by the courage of our questions and by
> the depth of our answers.                               - Carl Sagan
> 
> _______________________________________________
> rbridge mailing list
> rbridge at postel.org
> http://mailman.postel.org/mailman/listinfo/rbridge