Subject: Re: simple questions

From: [email-masked] (Christian E. Hopps)
Date: 09 Apr 1999 04:42:20 -0400

Naiming Shen <[email-masked]> writes:

> i heard you can also have 255 lsp fragments for each router, which should
> be enough room to put lots of adjacencies there.

Right, but unless I'm mistaken, you also need to include them in
your hellos which aren't fragmentable.

Chris.

---

From: DAUVERGNE Emmanuel CNET/DSE/ISS <[email-masked]>
Date: Fri, 9 Apr 1999 11:12:48 +0200

Hello,
these 2 questions lead me to another one...
Is it relevant to reduce the clns MTU (and not the IP MTU) of WAN interface,
in order to lower the bandwidth used by IIH PDU?
If yes, is the potential fragmentation of LSP the only risk we take with
this method?

Thanks
Manu

> ----------
> De : 	Tony Li[SMTP:[email-masked]]
> Date :	vendredi 9 avril 1999 09:58
> A :	[email-masked]
> Cc :	[email-masked]
> Objet :	Re: simple questions
> 
> 
> |          1) What is dataLinkBlockSize?
> |                  (hypothesis: MTU of interface)
> 
> 
> Correct.
> 
> 
> |          2) Does the protocol allow for sending PDU's larger than
> |          the MTU of the interface?
> 
> 
> Nope.  And there's no need, either.
> 
> Tony
>

---

From: Jeff Parker <[email-masked]>
Date: Fri, 9 Apr 1999 17:17:28 -0400

My mistake.  

- jparker
- nexabit.com
- If things get any worse, I'll have to ask you to stop helping me.

> -----Original Message-----
> From:	Tony Li [SMTP:[email-masked]]
> Sent:	Friday, April 09, 1999 4:26 PM
> To:	[email-masked]
> Cc:	[email-masked]; [email-masked]
> Subject:	Re: simple questions
> 
> 
> |  If you lower the MTU on one interface, you need to lower
> |  it everywhere: the same (unfragmented) Link State packets 
> |  have to be able to traverse each link.  
> 
> 
> Actually, the requirement is that the MTU be at least
> ReceiveLSPBufferSize.  They need not be consistent across a network.
> 
> Yes, this can reduce the bandwidth overhead of an IIH.  However, this
> is
> generally not enough overhead to be interesting anyhow.
> 
> 
> |  As far as the need to send PDUs larger than the MTU, I
> |  thought this was one motivation for the ISIS over IP draft.
> 
> 
> The primary motivation of the draft (from my perspective, at least) is
> the
> ability to use ATM VCMUXing instead of having to use SNAP
> encapsulation.
> This would make ATM much more efficient.

---

From: DAUVERGNE Emmanuel CNET/DSE/ISS <[email-masked]>
Date: Mon, 12 Apr 1999 10:54:28 +0200

Thanks very much and especially for this detailed answer.

Manu

> ----------
> De : 	Lester Ginsberg[SMTP:[email-masked]]
> Date :	samedi 10 avril 1999 01:19
> A :	Tony Li
> Cc :	[email-masked]; [email-masked];
> [email-masked]
> Actually, the requirement is that the MTU size on all subnetworks
> throughout the area/domain which are used to propagate ISIS
> PDUs must be >= to originatingL1LSPBufferSize
> (and/or originatingL2LSPBufferSize).
> 
> originatingLxLSPBufferSize is allowed to
> take on values in the range of 512-1492 and these values must be
> provisioned consistently throughout the area/domain or it
> may not be possible to fully propagate ISIS PDUs -
> though the protocol currently has no way of enforcing/detecting
> misprovisioning.
> 
> The misconception that MTU must be >= ReceiveLSPBufferSize
> derives from the fact that in most modern networks it is seen as
> undesirable to set originatingLxLSPBufferSize to anything
> other than 1492 (= ReceiveLSPBufferSize). However, in the case
> where some subnetworks in the area/domain are constrained to
> a smaller MTU size, then a smaller value for originatingLxLSPBufferSize
> must be chosen. This restriction occurs in SONET
> networks where Bellcore specifications currently mandate an MTU
> size of 512 on the DCC.
> 
> The SONET Interoperability Forum Architecture Work Group has
> submitted defect reports against the current version of ISO 10589
> defining ways to detect and report inconsistent provisioning of
> originatingLxLSPBufferSize. These defect reports are available at:
> 
>    ftp://ftp.juniper.net/pub/isis/lspsize.PDF
> 
> (BTW, the DRs are equally applicable to the second edition
> draft, though the section references will change.)
> 
>   Les
> 
> 
> 
> Tony Li writes:
>  >