Subject: Re: OSPFv2 MIB update

From: Don Goodspeed <[email-masked]>
Date: Wed, 29 Oct 2003 13:59:55 -0500

Also, duplicateRouterId was added to the ospfConfigErrorType
enumeration list.  -don
=================================================
Revision -07 of draft-ietf-ospf-mib-update has
been posted. It includes the following changes
from revision -06.

- added object ospfDiscontinuityTime in order for a management entity
  to detect counter discontinuity events
- updated REVISION DESCRIPTION clauses with description of major MIB
  modifications
- updated MIB contact info
- moved all relevant MIB comments to objects' DESCRIPTION clauses
- added reason for object deprecation in DESCRIPTION clause
- added persistence information for read-write, read-create objects
- described conditions when columns can be modified in RowStatus
  managed rows as required by RFC 2579
- defined 'OspfAuthType' TC and modified authentication type objects
  to use the new type
- Removed InterfaceIndex TC because it conflicts with TC in IF-MIB
- made index objects of new tables not-accessible ( index objects
  of old tables remain read-only )
- added the UNITS clause to several objects
- added ospfIfDesignatedRouterId and ospfIfBackupDesignatedRouterId
  to the OspfIfEntry
- added the area LSA counter table - ospfAreaLsaCountTable
- Removed ospfTrafficEngineeringSupport general group object. WG
  consensus was that a separate OSPF TE MIB should be defined.
- restored MAX-ACCESS value of ospfHostAreaID to read-only (RFC 1850).
  MIB rules do not allow MAX-ACCESS to be changed on an object.
- added new Host Table object ospfHostCfgAreaID to allow configuration
  of AreaID.
- added Intellectual Property Rights section
- added latest MIB boilerplate sections
- updated WG e-mail list
- indicate in abstract that the MIB is specific to IPv4
- changed references from "hitless" restart to "graceful" restart
- added section 1.5 describing reference for implementing
  MIB views on multiple OSPF instances
- new page number format in footer

Piotr and Dan

_______________________________________________
Join Excite! - http://www.excite.com
The most personalized portal on the Web!

---

From: Subratm <[email-masked]>
Date: Thu, 30 Oct 2003 17:00:55 +0530

Pl. look at the following scenario.

        10.0.0.0       20.0.0.0      30.0.0.0
     R1------------R2-------------R3----------

R1,R2 are ASBRs.

Router id of R1 is 10.0.0.4
Router id of R2 is 10.0.0.3
Router id of R2 is 30.0.0.3

R1 and R2 have static route to the network 11.0.0.0/8. So both R1 and R2
originate ASExt LSA for the network 11.0.0.0/8. Because R1 has the higher
router id, R2 flushes out the ASExt LSA for the network 11.0.0.0/8
originated by itself. Now all three routers (R1,R2,R3) have the ASExt LSA
for the network 11.0.0.0/8 originated by R1. Therefore they have the route
to 11.0.0.0/8 in the ip routing table.

Now R1 goes down. R2 and R3 delete the route to 11.0.0.0/8 from the ip
routing table. But R2  is not able to originate the ASExt LSA as the
existing ASExtLSA for 11.0.0.0/8 has the higher router id (R1's router id).
So R3 does not have the route to 11.0.0.0/8. R2 and R3 has the ASExt LSA for
11.0.0.0/8 originated by R1.

Ideally how should R2 behave so that R3 will have the route to 11.0.0.0/8 in
it's IP routing table.

Regards Subrat

***************************************************************************
This message is proprietary to Future Software Limited (FSL)
and is intended solely for the use of the individual to whom it
is addressed. It may contain  privileged or confidential information
and should not be circulated or used for any purpose other than for
what it is intended.

If you have received this message in error, please notify the
originator immediately. If you are not the intended recipient,
you are notified that you are strictly prohibited from using,
copying, altering, or disclosing the contents of this message.
FSL accepts no responsibility for loss or damage arising from
the use of the information transmitted by this email including
damage from virus.
***************************************************************************

---

From: Lakshmips <[email-masked]>
Date: Thu, 30 Oct 2003 17:36:30 +0530

In my opinion, functionally equivalent lsas handling by a router (R2) should
consider the following scenarios:

1. check whether it needs to originate an external lsa (if functionally
equivalent lsa already exist,based on router id)
2. check whether it has to purge its own lsa when a functionally equivalent
one is originated by a different router of higher router id
3. Also be able to decide and originate a functinally equivalent lsa when
one from a neighbor is deleted.

your problem lies in point 3. At any instance the implementation should take
care such that, R2 is able to originate an ext lsa (considering if any other
functionally equivalent lsa of higher router id exists), once  it deletes
the type 5 lsa of R1.

Lakshmi Priya.S

-----Original Message-----
From: Mailing List [mailto:[email-masked]]On Behalf Of
Subratm
Sent: Thursday, 30 October 2003 5:01 PM
To: [email-masked]
Subject: Regarding functionally equivalent LSA.

R1,R2 are ASBRs.

Regards Subrat