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

From: "Manral, Vishwas" <[email-masked]>
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 10:44:51 -0800 (PST)

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,

   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 -

     Les