Subject: RE: simple questions

From: Jeff Parker <[email-masked]>
Date: Fri, 9 Apr 1999 09:14:12 -0400

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.  

As far as the need to send PDUs larger than the MTU, I
thought this was one motivation for the ISIS over IP draft.

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

> -----Original Message-----
> From:	DAUVERGNE Emmanuel CNET/DSE/ISS
> [SMTP:[email-masked]]
> Sent:	Friday, April 09, 1999 5:13 AM
> To:	[email-masked]
> Subject:	RE: simple questions
> 
> 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: Tony Li <[email-masked]>
Date: Fri, 9 Apr 1999 13:25:38 -0700 (PDT)

|  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: "Lester Ginsberg" <[email-masked]>
Date: Fri, 9 Apr 1999 16:19:51 -0700 (PDT)

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