Re: new LSA

Naiming Shen <naiming@REDBACK.COM> Thu, 15 August 2002 07:34 UTC

Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA15907 for <ospf-archive@LISTS.IETF.ORG>; Thu, 15 Aug 2002 03:34:09 -0400 (EDT)
Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <2.006D6023@cherry.ease.lsoft.com>; Thu, 15 Aug 2002 3:35:28 -0400
Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 109183 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 15 Aug 2002 03:35:25 -0400
Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Thu, 15 Aug 2002 03:35:25 -0400
Received: from redback.com (yoo-hoo.redback.com [155.53.12.43]) by prattle.redback.com (Postfix) with ESMTP id 50826F2C58; Thu, 15 Aug 2002 00:35:27 -0700 (PDT)
Message-ID: <20020815073527.50826F2C58@prattle.redback.com>
Date: Thu, 15 Aug 2002 00:35:27 -0700
Reply-To: Mailing List <OSPF@DISCUSS.MICROSOFT.COM>
Sender: Mailing List <OSPF@DISCUSS.MICROSOFT.COM>
From: Naiming Shen <naiming@REDBACK.COM>
Subject: Re: new LSA
To: OSPF@DISCUSS.MICROSOFT.COM
In-Reply-To: Mail from Erblichs <erblichs@EARTHLINK.NET> dated Thu, 15 Aug 2002 00:19:46 PDT <3D5B5612.D3F43030@earthlink.net>
Precedence: list

I can think of some ways to use this info. For example, if we know
there is a link down from that new LSA, then we may want to trigger
an immediate calculation for the fast convergence purpose; if we know
there is an interface IP address change, who cares, data usually
are not forwarded to a backbone link anyway, we'll run the spf when
we have spare time; if we know A to B has two ECMP links and one of
them is up/down, there is nothing needs to be done, since even we
re-run the calculation, the results are got to be the same.

Now whether if people want to take such an "active" approach is up to
the implementors. we can argue either ways to the pros and cons.

cheers.

 ] Acee,
 ]
 ]         Then what would / could you do with this information? Could it
 ]         be useful in anyway? Have you ever heard of anyone really
 ]         interested in this type of information?
 ]
 ]         Mitchell Erblich
 ]         ======================
 ]
 ]
 ] Acee Lindem wrote:
 ] >
 ] > Erblichs wrote:
 ] >
 ] > > Acee,
 ] > >
 ] > >         Lets assume that we modify the LSA comparison code sections
 ] > >         and we keep the older LSA versions for a short time assuming
 ] > >         we have the memory available.
 ] >
 ] > Mitchell,
 ] >
 ] > Wasn't the original question whether this could be done without the
 ] > previous LSA?
 ] >
 ] > >
 ] > >         What would you say we can now do with this additional informatio
n?
 ] >
 ] > If you had the previous LSA you could definitely determine what had
 ] > changed between the two versions.
 ] >
 ] > >
 ] > >         Mitchell Erblich
 ] > >         ===================
 ] > >
 ] > >
 ] > > Acee Lindem wrote:
 ] > >
 ] > >>Beatriz Silva wrote:
 ] > >>
 ] > >>
 ] > >>>Hi everybody !
 ] > >>>
 ] > >>>I would like to know if it is possible (in OSPF v2) to identify, just b
y examining the LSA, what is the change the LSA is signaling. I want to identif
y if for example an router LSA was sent because the cost of one of the links wa
s changed, or if it was because one of the links went down .... This, without h
aving the previous LSAs, just by looking at the newly received LSA. Is it possi
ble ? How  ?
 ] > >>>
 ] > >>>
 ] > >>Beatriz,
 ] > >>
 ] > >>AFAIK, there is no way to determine what has changed without a previous
version
 ] > >>of the LSA.
 ] > >>
 ] > >>
 ] > >>>Thank you very much,
 ] > >>>Beatriz
 ] > >>>
 ] > >>>--
 ] > >>>__________________________________________________________
 ] > >>>Sign-up for your own FREE Personalized E-mail at Mail.com
 ] > >>>http://www.mail.com/?sr=signup
 ] > >>>
 ] > >>>
 ] > >>>
 ] > >>--
 ] > >>Acee
 ] > >>
 ] > >
 ] >
 ] > --
 ] > Acee

- Naiming