Subject: Re: Comments on mib-update-07

From: Don Goodspeed <[email-masked]>
Date: Mon, 24 Nov 2003 15:57:47 -0500

Acee,

Thanks for the reply.

5a. badLsType - I meant to put badPacketType (which means 1
thru 5 apply).  Maybe we should also have a badLsType if we
receive one other than 1-7 or 9-11!

5c. xsumError - Well, we can either overload the meaning of
ospfConfigErrorType, or add a new ospfErrorType to deal with
the non-configuration errors.  However, this might mean adding
a new ospfIfRcvBadPkt notification to handle receipt of these
packets.

5d. badLengths - This is just to indicate receipt of a bad
packet.  Certain packet generators have been known to generate
these as well as packets with checksum errors, and this is
an indicator that such a bad packet was received.  Once again,
if we split off the ospfIfRcvBadPkt as a new notification,
then this would be one of the possible bad packets.

6. see my reply to 5a above.  We might need an additional
ospfLsType attribute.

Thanks,
Don

=======================
Hi Don,

See comments comments below.

Don Goodspeed wrote:

>All,
>
>Did a full re-review of the MIB and here are my comments:
>1. For ospfNbrOptions, should we update the DESCRIPTION clause with
>the current available options?
>2. For ospfAsLsdbAdvertisement, the SYNTAX clause is incorrect.
>Instead of SIZE(36), it needs to be SIZE(1..65535).
>3. For ospfConfigErrorType, instead of moving noError every time
>we add a new enum, just make noError to be zero.
>4. Also for ospfConfigErrorType, in the DESCRIPTION, ospfConfig-
>Error and ospfConfigVirtError need to have "If" in each.
>5. Should we add additional error codes for:
> a. badLsType -- something other than 1 thru 5
>
This would indicate a type other than the types supported by the
receiving router. Current
OSPFv2 types include 1-7 and 9-11.

> b. subnetMismatch -- for bcast links, or do we want to overload
> netMaskMismatch?
> c. xsumError -- when the packet contents do not match the OSPF
> checksum, also when LSA content does not match LSA checksum
>
I wouldn't classify this as a configuration error.

> d. badLengths -- when the advertised length of the OSPF packet
> does not match the actual length of the received packet
>
We don't want to check this since there is a potential extension that
requires that this
isn't checked.

>6. If 5a is adopted, then ospfPacketType needs an additional enum
> for other(7) or unknown(7).
>
But 5 a) refers to LS types - not packet types.

>7. For the NbrStateChange traps, should we add an additional
>varbind for the event that caused the state change? This aids
>when debugging a resetting adjacency to know that an sequence #
>mismatch or a change in the options caused the adjacency to reset.
>
>Thanks,
>Don
>

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

---

From: Acee Lindem <[email-masked]>
Date: Mon, 24 Nov 2003 16:11:57 -0500

Hi Don,

Don Goodspeed wrote:

>thru 5 apply).
Okay.

>Maybe we should also have a badLsType if we
At this point, I prefer the shortest route to WG Last Call so I'd be
more in favor
of overloading the type or doing nothing.

>then this would be one of the possible bad packets.
Just so we don't check that the OSPF length is exactly the IP length. A
valid check might
be that it doesn't exceed the IP length.