Subject: Some comments on draft-ietf-ospf-ospfv3-mib-08.txt

From: Nic Neate <[email-masked]>
Date: Fri, 15 Oct 2004 16:42:30 +0100

Hi,

I have a handful of comments on and suggestions for
draft-ietf-ospf-ospfv3-mib-08.  Please have a look through and let me
know whether you agree or if I'm misunderstanding anything.

Interface instance IDs
----------------------

As previously agreed on this list, the ospfv3IfTable should be indexed
by both ospfv3IfIndex and ospfv3InstId, and correspondingly the
ospfv3NbrTable, ospfv3NbmaNbrTable and ospfv3LinkLsdbTable also need new
interface instance index fields.

It was also recently noted that the instance ID on virtual interfaces
will not always be 0, and therefore needs to be configurable.  I
therefore suggest we also add an ospfv3VirtIfInstId field to the
ospfv3VirtIfTable.

Designated Router identification
--------------------------------

The ospfv3IfDesignatedRouter and ospfv3IfBackupDesignatedRouter fields have
been carried over from the OSPFv2 MIB, with their descriptions updated to
note that these refer to Router IDs rather than IP addresses.

I think it would be helpful to add further fields providing the
Interface IDs of the designated and backup designated routers to the
network (say, ospfv3IfDesignatedRouterIfId and
ospfv3IfBackupDesignatedRouterIfId).  My reasoning is that while in
OSPFv2, the DR's IP address (as provided in the MIB) uniquely identified
a network, in OSPFv3, both the DR's Router ID and its Interface ID to
the link are required.

The ospfv3NbmaNbrTable
----------------------

This table is described as follows.

    -- The OSPFv3 NBMA Neighbor Table describes all configured
    -- NBMA neighbors and neighbors dynamically discovered by
    -- lower-level protocols such as Inverse Neighbor Discovery.

I thought that Point-to-Multipoint links also require explicit neighbor
configuration (or discovery by lower-level protocols) in the same way as
NBMA links.  If this is the case, I think it would be clearer if the
name of the table was changed to something less specific such as
ospfv3ConfiguredNbrTable and the comment updated accordingly.

Other nits
----------

 - There are various references to type-5 and type-7 LSAs thoughout.  It
would be more consistent with RFC2740 (and clearer) to refer to these as
AS-External-LSAs and NSSA-LSAs respectively.

 - There are two references to site-local IPv6 addresses.  I believe
these have been retired from IPv6.

 - In the descriptions of ospfv3IfRtrDeadInterval and
ospfv3VirtIfRtrDeadInterval, "it's" should be replaced with "its".

 - In the descriptions of ospfv3NbrRtrId and ospfv3NbmaNbrRtrId, I'm not
clear what "represented as type IpAddress" means (given that these take
syntax RouterID).

Thanks,

Nic

---

From: Daniel Joyal <[email-masked]>
Date: Mon, 18 Oct 2004 09:38:46 -0400

Nic,

Thanks for your comments. See mine below.

Regards,
-Dan

> -----Original Message-----
> From: Nic Neate [mailto:[email-masked]]
> Sent: Friday, October 15, 2004 11:43 AM
> To: [email-masked]'; Joyal, Daniel
> [BL60:NP31:EXCH]; [email-masked]'
> Subject: Some comments on draft-ietf-ospf-ospfv3-mib-08.txt
>
>
> Hi,
>
> draft-ietf-ospf-ospfv3-mib-08.  Please have a look through
> and let me know whether you agree or if I'm misunderstanding anything.
>
> Interface instance IDs
> ----------------------
>
> As previously agreed on this list, the ospfv3IfTable should
> be indexed by both ospfv3IfIndex and ospfv3InstId, and
> correspondingly the ospfv3NbrTable, ospfv3NbmaNbrTable and
> ospfv3LinkLsdbTable also need new interface instance index fields.
>

I believe that this is still under discussion.

> It was also recently noted that the instance ID on virtual
> interfaces will not always be 0, and therefore needs to be
> configurable.  I therefore suggest we also add an
> ospfv3VirtIfInstId field to the ospfv3VirtIfTable.

OK.

> The ospfv3IfDesignatedRouter and
> ospfv3IfBackupDesignatedRouter fields have been carried over
> from the OSPFv2 MIB, with their descriptions updated to note
> that these refer to Router IDs rather than IP addresses.
>
> I think it would be helpful to add further fields providing
> the Interface IDs of the designated and backup designated
> routers to the network (say, ospfv3IfDesignatedRouterIfId and
> ospfv3IfBackupDesignatedRouterIfId).  My reasoning is that
> while in OSPFv2, the DR's IP address (as provided in the MIB)
> uniquely identified a network, in OSPFv3, both the DR's
> Router ID and its Interface ID to the link are required.
>

The local and remote interface IDs are available in the neighbor
table. Do we want to replicate that information here?

> I thought that Point-to-Multipoint links also require
> explicit neighbor configuration (or discovery by lower-level
> protocols) in the same way as NBMA links.  If this is the
> case, I think it would be clearer if the name of the table
> was changed to something less specific such as

Yes. This table is meant to contain configured neighbors for use
on NBMA and P2MP interfaces. The name can be changed if it is
confusing.

>
> Other nits
> ----------
>
>  - There are various references to type-5 and type-7 LSAs
> thoughout.  It would be more consistent with RFC2740 (and
> clearer) to refer to these as AS-External-LSAs and NSSA-LSAs
> respectively.

OK.

>
>  - There are two references to site-local IPv6 addresses.  I
> believe these have been retired from IPv6.
>

OK.

> ospfv3VirtIfRtrDeadInterval, "it's" should be replaced with "its".
OK.

>  - In the descriptions of ospfv3NbrRtrId and
> ospfv3NbmaNbrRtrId, I'm not clear what "represented as type
> IpAddress" means (given that these take syntax RouterID).

Per Keith McCloghrie's earlier comments, a new TC for RouterId will be
created to replace the ipAddress syntax. The description above will
be appropriately modified.