Subject: RE: [Isis-wg] MTU lowering in IS-IS

From: Jeff Parker <[email-masked]>
Date: Mon, 9 Sep 2002 16:54:04 -0400

> Hello Everyone,
> 
> I have a question regarding how IS-IS should handle MTU 
> changes in the System. If i decrease the MTU size on a 
> interface to a value which will lower the current LSP buffer 
> size, then how should IS-IS handle this case ?
> 
>  Also how do we inform the IS's neighbours that the Buffer 
> Size in the Local IS has been lowered ? Does the padding of 
> the IIH packets help in this case?
> 
> Thanks,
> Sarav

Sarav -
	This is covered in the draft on interoperability.
There is a version of that draft at 
http://ietf.org/internet-drafts/draft-ietf-isis-interoperable-01.txt
Take a look and let me know if that doesn't answer your questions:
it isn't too late to change it.  

	An updated version which splits this into 2 should appear
before long: this issue will be addressed in the pure ISO half.

- jeff parker
_______________________________________________
Isis-wg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/isis-wg

---

From: Saravana Kumar <[email-masked]>
Date: Tue, 10 Sep 2002 19:03:00 +0530

Hi Jeff,

After looking into the draft, i've got one basic question, should'nt
ReceiveLSPBufferSize be less than ( or equal to ) the minimum of the Link
MTUs of all the circuitsin the router ?  Otherwise how will the router
receive LSPs through a circuit whose MTU is smaller than the LSP size.

Thanks,
Sarav

---

From: Mike Truskowski <[email-masked]>
Date: Tue, 10 Sep 2002 06:52:17 -0700 (PDT)

How will it receive the largest MTU size if it's less than or equal
to the smallest?

Are we bit fiddling with  something that works or trying to fix
something that does not work?

Mike

---

From: Les Ginsberg <[email-masked]>
Date: Tue, 17 Sep 2002 01:46:20 -0700

(Coming to the party a little late...)

>receive LSPs through a circuit whose MTU is smaller than the LSP size.

The short answer to this question is "No".

When discussing this issue it is important to understand the functions of 
all the relevant parameters:

1)ReceiveLSPBufferSize - which defines the largest LSP which an 
implementation can expect to receive. This parameter also serves as an 
upper bound on the largest LSP which an implementation can be configured to 
generate. While it is desirable that ReceiveLSPBufferSize be set 
consistently on all routers, it is not required. It is also not a problem 
if ReceiveLSPBufferSize is larger than the MTU of some circuits on which 
LSPs are propagated. The obvious real world example of this is existing 
10589 conformant IS-IS implementations used in SONET networks. In this case 
ReceiveLSPBufferSize is 1492, but LAPD/DCC links have an MTU of 512. This 
is OK so long as originatingLxLSPBufferSize is set to 512 on all routers.

2)originatingLxLSPBufferSize - which defines the largest LSP which an 
implementation is allowed to generate. This parameter is subject to the 
following restrictions:

a)It MUST be >=512 AND <= ReceiveLSPBufferSize
b)It MUST be <= the minimum MTU of any circuit used to propagate LSPs in 
the area/domain
c)It SHOULD be consistent on all routers in the area/domain

While I would not recommend it, there would be no operational problem with 
the following configuration:

Router A:  ReceiveLSPBuffSize = 1492
                 originatingL1LSPBufferSize = 1492

Router B:  ReceiveLSPBuffSize = 4096
                originatingL1LSPBufferSize = 1492

I believe 
http://ietf.org/internet-drafts/draft-ietf-isis-interoperable-01.txt does a 
good job of discussing this, but if people feel that some further 
clarification would be helpful, then perhaps some rewording can be done, 
though that discussion should take place within the isis-update sub-group.

As far as your original question

> > > size, then how should IS-IS handle this case ?

Strictly speaking, something which causes originatingLxLSPBufferSize to 
change in value requires a logical restart of the protocol. This is because 
it would likely require regeneration of all existing local LSPs. This is 
why draft-ietf-isis-wg-mib-09.txt associates 
the   "replaceOnlyWhileDisabled behavior" with this parameter. Existing 
implementations may, as a convenience to the user, allow changes to this 
parameter "on the fly", but that does not alter the fact that what must 
occur internally is equivalent to a protocol restart. This is especially 
true if one remembers that inconsistent settings of 
originatingLxLSPBufferSize in the area/domain can cause interoperability 
problems.

    Les

c)

---

From: Les Ginsberg <[email-masked]>
Date: Tue, 17 Sep 2002 02:56:27 -0700

At 02:37 PM 9/17/02 +0530, Saravana Kumar wrote:

>We should add this restriction for the originatingLxLSPBufferSize in the
>interoperability draft, instead of stating that "for all Lx links in the
>area, originatingLxLSPBufferSize <= MTU"

I do not see any difference in (intended) meaning between the two 
statements. Perhaps it is a matter of clarity of wording. If so, we can 
certainly revise the wording of the draft - but this is not "adding" 
anything other than clarity. This is what we always meant to say.

Jeff P - consider this as a proposed revision to the draft.

     Les