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

["Don Fedyk" <dwfedyk at nortel.com>]

+1

Don 

> -----Original Message-----
> From: isis-wg-bounces at ietf.org 
> [mailto:isis-wg-bounces at ietf.org] On Behalf Of mike shand
> Sent: Tuesday, April 07, 2009 5:31 AM
> To: Tony Li
> Cc: Radia Perlman; isis-wg at ietf.org
> Subject: Re: [Isis-wg] Why is MTU discovery important?
> 
> Radia,
>     In IS-IS the primary reason for the padding it to ensure 
> that LSPs 
> get through. Any data MTU determination is more or less incidental, 
> since there are other ways that layer 3 can attempt to handle this.
> 
>     Obviously, since LSPs cannot be fragmented, it is 
> essential that all 
> routers can receive maximum sized LSPs, and hence that all 
> links support 
> that MTU. (arguably not ALL links have to in order to ensure 
> that there 
> is a wide enough path to every router, but that can lead to 
> very messy 
> failure scenarios).
> 
>     So we mandate that all links must support that MTU. But 
> that is not 
> enough. Despite the mandate, there may be links which for whatever 
> reason (badly configured, bad hardware, in the old days 
> 10/100 bridges 
> as Tony said, etc. ) If an adjacency came up irrespective of MTU 
> capability we could have a situation where everything appeared to be 
> working just fine, until some time later (perhaps weeks 
> later) when some 
> LSPs grow to be bigger than can be sent over the restricted link(s). 
> Then we would start loosing LSPs and potentially getting 
> routing loops.
> 
>     As Tony said, it is far better to have it break obviously 
> (i.e. an 
> adjacency does come up at all), that have it limp along in 
> some strange 
> failure mode.
> 
>     The padding is NOT primarily meant to allow networks which don't 
> support the minimum MTU requirements to operate, but rather to ensure 
> that in the rare event that a link doesn't have the required MTU it 
> won't get used. (and in the case of a bridged network, that a 
> reconfiguration of the spanning tree doesn't suddenly cause the 
> available MTU to change.)
> 
>     Note that lowering the maximum LSP size (in the hope that 
> this would 
> increase the probability of all links supporting that MTU), is not 
> really an option. Firstly it probably wouldn't help, and 
> secondly, there 
> are already concerns about the amount of information which 
> needs to be 
> transmitted in hellos and LSPs, and reducing the MTU size 
> would further 
> exacerbate this.
> 
>  
>     But it is not JUST the padding which needs to be changed to make 
> TRILL work. The rules for the election of DIS/DRB have to be 
> changed. In 
> IS-IS the DIS is elected from among the routers on a LAN 
> which have two 
> way connectivity (as evidenced by the IIHs reporting each other). In 
> TRILL the DRB must be elected from among the neighbors, even if they 
> DON't report each other. Also, IS-IS doesn't elect a DIS if 
> there are no 
> adjacencies on the LAN, whereas (as I understand it ) TRILL 
> has to elect 
> a DRB even when it is the only Rbridge on the LAN.
> 
> I'm nervous about making all these changes to the adjacency formation 
> and DIS election rules, and we haven't even thought about the 
> interaction with BFD etc.. My preference would be to keep all 
> this the 
> same, and then use different minimal TRILL hellos to elect 
> the DRB with 
> the required TRILL semantics. That is what was proposed in 
> version 12 of 
> the TRILL draft.
> 
>     Mike
> 
> 
> Tony Li wrote:
> >
> >> Obviously ignoring the MTU issue, and just making sure Hellos get 
> >> through by not padding Hellos, is a nice simple proposal.
> >>
> >> What would we be giving up if we ignored MTU discovery entirely?
> >
> >
> > Hi Radia,
> >
> > I'm a big fan of MTU discovery mechanisms.  This is because finding 
> > and fixing MTU issues in the field is a Giant Pain In The Neck (or 
> > somewhat lower ;-).
> >
> > I can't tell you the number of times when I've had a 
> customer come up 
> > with a problem that was basically "I can ping and start 
> doing things, 
> > but then everything Just Stops."
> >
> > This is diagnosable on a routed network, _if_ you anticipate the 
> > answer: you traceroute, and then you traceroute at the max MTU size 
> > with DF set.  However, on a L2 network (classical case: FDDI 
> > "translational" bridges) this is simply a disaster.  Which node 
> > dropped your packet? And what path is your packet taking, anyway?  
> > Hours of tedious bridge table studies later, you will find it.
> >
> > I'm also a big fan of simple, plug and play networks that break in 
> > blindingly obvious ways.  This is something that I learned 
> from you, 
> > among others.  ;-)  Having no good way of ensuring that a 
> network work 
> > except having a super-human network administrator is not a 
> recipe that 
> > appeals.  Thus, I'd definitely vote for keeping the capability in.
> >
> > Anyways, that's my $.03.
> >
> > Regards,
> > Tony
> >
> >
> >
> > _______________________________________________
> > 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
>