Subject: RE: [Isis-wg] RE: Regarding draft-ietf-isis-wg-mib-06.txt

From: "Manral, Vishwas" <[email-masked]>
Date: Mon, 31 Dec 2001 00:02:12 -0500

Dave,

We have sort of agreed, that not all architectural constants described in
ISIS are "truly architectural constants" and may be configureable also the
fact that making assumptions based on a constant MaxAge/some other
parameters is wrong.

However this brings me to another issue. I have been reading thru the mail
archives and I find a lot of things that are not done in the RFC way in the
current implementations. Wouldn't it be helpful if we had a document that
described the "Best Current Practices"? (I had written to Tony regarding the
same and he felt "yes, we could if we find a volunteer but then again, new
verison of ISIS document is supposed to fix that stuff").

Thanks,
Vishwas

-----Original Message-----
From: Dave Katz [mailto:[email-masked]]
Sent: Monday, December 31, 2001 12:15 AM
To: [email-masked]
Cc: [email-masked]; [email-masked]
Subject: Re: [Isis-wg] RE: Regarding draft-ietf-isis-wg-mib-06.txt

I haven't been paying a lot of attention to this conversation, but that
never stopped me from commenting before.

One of the nice things about ISIS (as compared to OSPF) is that there
are very few things that are truly architectural constants (as in, if
you don't use this value, the protocol won't work.)  Further, there
are less settable parameters that must be coordinated between systems
in order for the network to function.

The LSP lifetime (along with the adjacency holding time) has the very
nice property that everybody can pick different values and the network
Just Works.  This has operationally saved people more times than I can
count.

Any system that makes judgement on the choice of values of these parameters
set by another system is just plain broken.

--Dave

   From: "Manral, Vishwas" <[email-masked]>
   Cc: "[email-masked]'" <[email-masked]>
   Content-Type: text/plain;
	   charset="iso-8859-1"
   Sender: [email-masked]
   X-BeenThere: [email-masked]
   X-Mailman-Version: 2.0rc1
   Precedence: bulk
   List-Help: <mailto:[email-masked]?subject=help>
   List-Post: <mailto:[email-masked]>
   List-Subscribe: <http://external.juniper.net/mailman/listinfo/isis-wg>,
	   <mailto:[email-masked]?subject=subscribe>
   List-Id: IETF IS-IS working group <isis-wg.external.juniper.net>
   List-Unsubscribe: <http://external.juniper.net/mailman/listinfo/isis-wg>,
	   <mailto:[email-masked]?subject=unsubscribe>
   List-Archive: <http://external.juniper.net/pipermail/isis-wg/>
   Date: Fri, 28 Dec 2001 00:37:40 -0500

   Les,

   I get the point you are trying to make. The problem you say would happen
   whenever there is a diff in MaxAge in IS's in the domain(and the LSP's
for
   some reason is not refreshed).

   This is what I am trying to say. The MaxAge would be the value which
would
   be put in a self LSP, as remaining lifetime when we are originating a new
   LSP. If the remaining life time is greater than MaxAge for some other IS,
it
   should treat the stuff as if MaxAge(in the sense it should not drop the
LSP,
   MIB ops on remaining lifetime shld give age as MaxAge(if any), SPF(age
   value) etc), however it should start the purge(MaxAge) timer for that LSP
   with the value of "remaining lifetime" field(So remaining lifetime would
be
   zero after remaining life time period). However this would cause the
MaxAge
   field to be used as in the remaining lifetime and not as configured in
the
   IS itself.(some problems/loopholes/against existing approach with this
   approach??)

   This way all people would purge the LSP at nearly the same time(so the
   problem described would not arise). 

   Thanks,
   Vishwas

   -----Original Message-----
   From: Les Ginsberg [mailto:[email-masked]]
   Sent: Friday, December 28, 2001 10:29 AM
   To: 'Manral, Vishwas'; Les Ginsberg; 'Jeff Parker'
   Cc: IS-IS-WG (E-mail)
   Subject: RE: [Isis-wg] RE: Regarding draft-ietf-isis-wg-mib-06.txt

   Vishwas -

   Makes no difference. From the point of view of the receiver of an LSP, it
   has no way of knowing what the value of LSP lifetime may be on the
   originating IS since the remaining lifetime field gets modified, based on
   elapsed time, prior to flooding. All the receiver can say is that the
   originating IS has a value for LSP lifetime which is >= the original
   received remaining lifetime.

   If an IS arbitrarily decreases the remaining lifetime of an LSP it has
   received, then it is quite possible that the LSP will age out of the
local
   database before the originating router regenerates that LSP. The protocol
   will eventually recover, but in order to do so the LSP will first be
purged,
   causing an SPF to be run on all routers (or many of them anyway) with
this
   LSP absent, and then the originating router will, on seeing the purged
   version, regenerate that LSP, flood it, and a second SPF will be run on
   every router. Reachability advertised in this LSP will temporarily
disappear
   from the forwarding databases throughout the area/domain and then be
   restored. This is highly undesirable.

     Les

   > 
   > 
   > Les,
   > 
   > I meant "remaining lifetime" field in the LSP and not age(wrong use of
   > terminology on my part).
   > 
   > So this is what I meant:-
   > 
   > 1. If the remaining Lifetime is > MaxAge value in the router, 
   > treat the
   > remaining lifetime as if it was MaxAge.
   > 2. MaxLSPGenInt should be less than min value of MaxAge for 
   > all routers in
   > the domain.
   > 3. The difference(as pointed out) should be at least enough 
   > so that the LSP
   > is propagated thruout the domain(so that no one purges the 
   > LSP before the
   > new version reaches it).
   > 
   > Thanks,
   > Vishwas
   > 
   > -----Original Message-----
   > From: Les Ginsberg [mailto:[email-masked]]
   > Sent: Friday, December 28, 2001 2:31 AM
   > To: 'Manral, Vishwas'; 'Jeff Parker'
   > Cc: IS-IS-WG (E-mail)
   > Subject: RE: [Isis-wg] RE: Regarding draft-ietf-isis-wg-mib-06.txt
   > 
   > 
   > > 
   > > Treating any LSP with age above Maxage could be done as if 
   > > age was MaxAge.
   > > May be we need to recommend that all routers in a domain 
   > have the same
   > > Maxage(and the value of MaxLSPGenInt should be less than the 
   > > value of the
   > > smallest value of MaxAge in any router in the domain)value 
   > > for things to
   > > work ok(and then we can treat all LSP's with age greater than 
   > > MaxAge as
   > > MaxAge), we could raise a trap on getting an LSP with age 
   > greater than
   > > MaxAge.
   > >  
   > 
   > The change from an architectural constant to a configurable value was
   > presumably made based on customer demand. To require, or even 
   > suggest, that
   > an implementation treat an LSP received with a lifetime > the 
   > architectural
   > constant MAXAGE as if it were set to MAXAGE is a VERY BAD thing to do.
   > Routers which did this could end up purging an LSP from their database
   > before the originating router's MaxLSPGenInt timer fired, 
   > which would cause
   > unnecessary flapping. If you want to argue that the current "de facto
   > standard" of making LSP lifetime configurable should be made 
   > invalid you
   > will at least be addressing the issue directly - though I 
   > suspect you will
   > get little support. Circumventing the issue by pretending the 
   > value is not
   > configurable is unwise.
   > 
   > It is also worth noting that, as you suggest, there is a necessary
   > relationship between LSP lifetime and MaxLSPGenInt, namely:
   > 
   > 1)MaxLSPGenInt must be less than LSPlifetime
   > 2)(LSPlifetime - MaxLSPGenInt) should be large enough to 
   > allow propagation
   > of the LSP throughout the area/domain before the old LSP ages out
   > 
   > If LSP lifetime is modified from the "default" value of 1200 
   > seconds, it
   > makes sense to change MaxLSPGenInt in a like manner.
   > 
   >    Les
 
_______________________________________________
Isis-wg mailing list  -  [email-masked]
http://external.juniper.net/mailman/listinfo/isis-wg

---

From: Dave Katz <[email-masked]>
Date: Sun, 30 Dec 2001 22:00:21 -0800 (PST)

X-JNPR-Received-From: outside
   From: "Manral, Vishwas" <[email-masked]>
   Cc: [email-masked], [email-masked]
   Date: Mon, 31 Dec 2001 00:02:12 -0500
   Content-Type: text/plain
   X-OriginalArrivalTime: 31 Dec 2001 05:02:01.0453 (UTC) FILETIME=[483509D0:01C191B8]

   Dave,

I think the number of things that are done in practical conflict with
the spec is vanishingly small, where "practical conflict" is
interpreted as "a reasonable implementation would notice."
Excessively pedantic boxes have a way of fixing themselves one way or
another.

Most of these things are pretty obvious to anyone reasonably versed in
the art, though the potentially sticky ones (like not bothering with
ISHs) should probably be documented.

--Dave