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

From: mike shand <[email-masked]>
Date: Fri, 04 Jan 2002 12:23:53 +0000

Let me just reinforce what Dave is saying here (as if that were needed :-)

The ONLY thing that matters is that the LSP gen interval for any particular 
LSP is less than the value which the originating router sets in the 
remaining lifetime field when it is generated. i.e. we need to ensure that 
the originator will refresh the LSP before its remaining lifetime value has 
been exhausted. Provided that constraint is met (with a reasonable amount 
of slop to take care of timing differences etc.) not only can different 
routers use different values for "MaxAge", but a router could (if it was 
bloody minded enough) use different values for different LSPs (provided it 
could remember when to refresh them)!

There is ABSOLUTELY no need for any other router to police the value of 
MaxAge, and as has been pointed out, to do so would be wrong.

Just as a historical note here, the original DECnet PhaseV specification 
(where maxAGE was truely an architectural constant) did require that an LSP 
with a remaining lifetime greater than Maxage (20 minutes) be treated as 
being corrupt. This was propagated into 10589 (see 7.3.16.3), where it says 
that

"If the value of Remaining Lifetime is greater than MaxAge the LSP shall be 
processed as if there were a checksum error."

This is reasonable if MaxAge really is fixed.

But I think most implementations (and certainly those which allow MaxAge to 
be varied) quitely ignore this requirement (as indeed they must). If 
anything needs documenting, it should simply be the deletion of this sentence.

         Mike

At 10:44 30/12/2001 -0800, Dave Katz wrote:
>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
>
>_______________________________________________
>Isis-wg mailing list  -  [email-masked]
>http://external.juniper.net/mailman/listinfo/isis-wg

_______________________________________________
Isis-wg mailing list  -  [email-masked]
http://external.juniper.net/mailman/listinfo/isis-wg

---

From: Dave Katz <[email-masked]>
Date: Fri, 4 Jan 2002 09:49:39 -0800 (PST)

Cool, another sentence in the spec that I missed.  ;-)

   X-JNPR-Received-From: outside
   X-Sender: [email-masked]
   Date: Fri, 04 Jan 2002 12:23:53 +0000
   From: mike shand <[email-masked]>
   Cc: [email-masked], [email-masked], [email-masked]
   Content-Type: text/plain; charset="us-ascii"; format=flowed
   X-OriginalArrivalTime: 04 Jan 2002 12:23:27.0640 (UTC) FILETIME=[9CDB7180:01C1951A]

	    Mike