Subject: RE: [Isis-wg] About MTU?

From: "Ravindra Sunkad" <[email-masked]>
Date: Thu, 25 Apr 2002 09:49:14 -0700

If an implementation brings down IS-IS on interfaces with MTU <
LSP_BUF_SIZE this problem will not arise.
 
-----Original Message-----
From: Jeff Learman [mailto:[email-masked]] 
Sent: Thursday, April 25, 2002 8:13 AM
To: Wang xuepu
Cc: [email-masked]
Subject: Re: [Isis-wg] About MTU?

	ISO 10589:1992 is not clear what should be done in this case --
the
	answer seems to be to purge the PDU.
	
	ISO 10589:2001 clears up what the router should do, but it
doesn't
	solve the problem -- it just makes the problem less severe and
defines
	management events to help indicate the existence of the problem.
	
	It's a configuration error, and the network administrator must
fix it
	by reducing the maximum originate LSP size on all routers in the
	subdomain (area or L2 backbone).
	
	Regards,
	Jeff
	
	At 08:44 AM 4/27/2002, Wang xuepu wrote:

		Suppose there are three routers in the same area,and
they are connected by the ethernet.
		such as:
		 
		 ___        ___         ___    
		| A |______| B |_______| C | 
		|___|e0  e0|___|e1   e0|___|
		       
		Suppose:
		Router A: 
		         the mtu of e0 is 1500.
		Router B:
		         the mtu of e0 is 1500.    
		         the mtu of e1 is 1000.    
		Router C:
		         the mtu of e0 is 1000.    
		Now:
		When Router B receive a Router A's LSP from e0,the size
of this LSP should be 1500,the Router B should flood
		the LSP,but B can not send this LSP throught e1.becase
the mtu is too small.
		Is it correct?
		if it is right,how can we solute this problem?

---

From: Tony Przygienda <[email-masked]>
Date: Thu, 25 Apr 2002 18:05:46 -0700

Ravindra Sunkad wrote:

>  If an implementation brings down IS-IS on interfaces with MTU < LSP_BUF_SIZE this problem
> will not arise.
>
>
> not good enough, the problem is transitive, you may have interface with MTU  4096,
> your LSP_BUF_SIZE is 1024
> and you receive from your neighbor an LSP with size 2048 since his LSP_BUF_SIZE is set to 2048
>
>     -- tony

_______________________________________________
Isis-wg mailing list  -  [email-masked]
http://spider.juniper.net/mailman/listinfo/isis-wg

---

From: "SelvarajR" <[email-masked]>
Date: Fri, 26 Apr 2002 11:23:36 +0530

Hi,
I guess the latest 10589v2 address this by defining new TLV.
But apologies in advance that I'm not well sure about that.
The idea is that all the ISIS process in the domain agreeing upon for the
least MTU in the domain. All  ISIS process should advertise their least
interface MTU(among on which ISIS is enabled, ofcourse) in their LSPs. Then,
each ISIS process shall scan there LSP data base and select the least MTU
among those advertised in the LSP, including its own LSP. This least MTU
shall be used as the LSPBufferSize. If there is any change in the current
LSPBufferSize then the ISIS process shall restart.

For this all the ISIS process should support the new TLV.
This mechanism may have quite few number of ISIS process restart as an
overhead.
No Pain No Gain ;)
I guess this may solve the problem.

Selva.

| -----Original Message-----
| From: [email-masked]
| [mailto:[email-masked]]On Behalf Of Tony Przygienda
| Sent: Friday, 26 April 2002 6:36 AM
| To: Ravindra Sunkad
| Cc: Jeff Learman; Wang xuepu; [email-masked]
| Subject: Re: [Isis-wg] About MTU?
|
|
| Ravindra Sunkad wrote:
|
| >  If an implementation brings down IS-IS on interfaces with
| MTU < LSP_BUF_SIZE this problem
| > will not arise.
| >
| >
| > not good enough, the problem is transitive, you may have
| interface with MTU  4096,
| > your LSP_BUF_SIZE is 1024
| > and you receive from your neighbor an LSP with size 2048
| since his LSP_BUF_SIZE is set to 2048
| >
| >     -- tony
|
| _______________________________________________
| Isis-wg mailing list  -  [email-masked]
| http://spider.juniper.net/mailman/listinfo/isis-wg
|

***************************************************************************
This message is proprietary to Future Software Limited (FSL) 
and is intended solely for the use of the individual to whom it
is addressed. It may contain  privileged or confidential information 
and should not be circulated or used for any purpose other than for 
what it is intended. 

If you have received this message in error, please notify the
originator immediately. If you are not the intended recipient,
you are notified that you are strictly prohibited from using,
copying, altering, or disclosing the contents of this message. 
FSL accepts no responsibility for loss or damage arising from 
the use of the information transmitted by this email including
damage from virus.
***************************************************************************
_______________________________________________
Isis-wg mailing list  -  [email-masked]
http://spider.juniper.net/mailman/listinfo/isis-wg

---

From: Tony Przygienda <[email-masked]>
Date: Thu, 25 Apr 2002 22:19:35 -0700

> I guess this may solve the problem.

yes, there is a proposal hanging, other people are better informed than
me. It was forwarded to this list or it's on my or  maybe jeff's plate to
get it forwarded to this list via a liason if I'm not mistaken.
I better go and check my to-do list ;-)

    - -tony

---

From: mike shand <[email-masked]>
Date: Mon, 29 Apr 2002 09:53:06 +0100

>LSPBufferSize then the ISIS process shall restart.

The problem with "solutions" of this type, (everyone advertises their 
requirements and we select the best one dynamically) is that they are very 
sensitive to problems caused by introduction of new routers (deliberately 
or accidentally), partitioning (so that some demanding router is not seen 
for a while) and then recovery (so that it pops back up again), and area 
merging etc. etc.

Nice though "automatic" configuration may be, I can't help feeling that 
only the network designer/operator really knows what is required, and 
attempts by the protocol to second guess this on the fly, on the basis of 
incomplete information, are ultimately doomed to failure.

Not that I'm a pessimist or anything :-)

         Mike

ps. WARNING about potential misconfiguration is one thing. "Correcting" it 
is another.