[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: LMP MIB revision 6
So below you give me a lot of explanation what kind of
notifications can get generated and how many would be generated
under which conditions. I think that is exactly the type of
information that we would like to see somewhere (best uis probably
in DESCRITPION clauses so that it stays with the MIB module when
it gets extracted). You might also add some warnings that people
should be carefull NOT to configure too short verification times
and at least take the potential notification rate into consideration
when doing so.
The question then becomes: should there be an object to throttle
the max rate?
Thanks,
Bert
> -----Original Message-----
> From: Martin Dubuc [mailto:m.dubuc@rogers.com]
> Sent: zondag 28 september 2003 3:31
> To: Wijnen, Bert (Bert)
> Cc: Ccamp-wg (E-mail)
> Subject: Re: LMP MIB revision 6
>
>
> Bert,
>
> I am almost done updating the LMP MIB to address your
> comments. However, I
> am stuck on comment 16 (notifications). You would like to
> know what rate per
> second we should fear in the worst conditions. It is very difficult to
> answer this one. I have thought a lot about this, and I don't
> think I can
> come up with a number. The notification rate distribution
> depends too much
> on the type of network, the size of network, the network
> configuration, the
> type of the links, the reliability of the network, etc.
>
> I can add some text in some of the notifications to explain
> some of the
> expected limits (for instance, there are some notifications
> that can only
> happen once per link verification interval), but to give one
> number for the
> worst case is next to impossible.
>
> In general, I think the LMP MIB is not resource hungry when
> it comes to
> notifications because all of the transitions are state driven
> (meaning the
> notification are only sent when the system changes state),
> cover some very
> specific error conditions (like configuration errors) and are mainly
> associated with entities that are limited in numbers (TE
> links and control
> channels). The only notifications that might have caused a
> problem are the
> ones associated with data links (because of the potential
> high number of
> data links) but since the data links can happen only once per
> data link per
> link verification interval, the notification rate should be
> sustainable if
> one chooses an appropriate link verification interval and
> engineers the
> network properly. For instance, a network of 100 nodes with 5
> links of 128
> wavelengths each and a link verification of 1 minute with say
> 10% of the
> links failed at any given time would have 1 notification per
> second sent
> from each node (100 notifications per second for the whole
> network). The
> rest of the notifications are negligeable compared to this number.
>
> Martin
>
> ----- Original Message -----
> From: "Wijnen, Bert (Bert)" <bwijnen@lucent.com>
> To: "'Martin Dubuc'" <m.dubuc@rogers.com>
> Cc: "Ccamp-wg (E-mail)" <ccamp@ops.ietf.org>
> Sent: Monday, September 01, 2003 4:42 PM
> Subject: RE: LMP MIB revision 6
>
>
> > Well well...
> >
> > SMICng says:
> > W: f(lmp.mi2), (2251,20) Variable "ifIndex" in notification
> > "lmpDataLinkPropertyMismatch" is an index for a table
> > W: f(lmp.mi2), (2306,20) Variable "ifIndex" in notification
> > "lmpTeLinkDegraded" is an index for a table
> > W: f(lmp.mi2), (2316,20) Variable "ifIndex" in notification
> > "lmpTeLinkNotDegraded" is an index for a table
> > W: f(lmp.mi2), (2329,20) Variable "ifIndex" in notification
> > "lmpDataLinkVerificationFailure" is an index for a table
> > W: f(lmp.mi2), (2641,19) MIN-ACCESS value identical to access
> > specified for "lmpCcOperStatus"
> > W: f(lmp.mi2), (2693,19) MIN-ACCESS value identical to access
> > specified for "lmpTeLinkOperStatus"
> > W: f(lmp.mi2), (2761,19) MIN-ACCESS value identical to access
> > specified for "lmpDataLinkActiveOperStatus"
> > W: f(lmp.mi2), (2768,19) MIN-ACCESS value identical to access
> > specified for "lmpDataLinkPassiveOperStatus"
> >
> > smilint says:
> > .\LMP-MIB:2425: [2] {subtype-enumeration-illegal} named number
> > `degraded(4)' illegal in sub-type
> > .\LMP-MIB:2439: [2] {subtype-enumeration-illegal} named number
> > `up(1)' illegal in sub-type
> > .\LMP-MIB:2439: [2] {subtype-enumeration-illegal} named number
> > `down(2)' illegal in sub-type
> > .\LMP-MIB:2439: [2] {subtype-enumeration-illegal} named number
> > `degraded(4)' illegal in sub-type
> > .\LMP-MIB:2444: [2] {subtype-enumeration-illegal} named number
> > `up(1)' illegal in sub-type
> > .\LMP-MIB:2444: [2] {subtype-enumeration-illegal} named number
> > `down(2)' illegal in sub-type
> > .\LMP-MIB:2444: [2] {subtype-enumeration-illegal} named number
> > `degraded(4)' illegal in sub-type
> > .\LMP-MIB:2694: [2] {subtype-enumeration-illegal} named number
> > `degraded(4)' illegal in sub-type
> > .\LMP-MIB:2763: [2] {subtype-enumeration-illegal} named number
> > `up(1)' illegal in sub-type
> > .\LMP-MIB:2763: [2] {subtype-enumeration-illegal} named number
> > `down(2)' illegal in sub-type
> > .\LMP-MIB:2763: [2] {subtype-enumeration-illegal} named number
> > `degraded(4)' illegal in sub-type
> > .\LMP-MIB:2769: [2] {subtype-enumeration-illegal} named number
> > `up(1)' illegal in sub-type
> > .\LMP-MIB:2769: [2] {subtype-enumeration-illegal} named number
> > `down(2)' illegal in sub-type
> > .\LMP-MIB:2769: [2] {subtype-enumeration-illegal} named number
> > `degraded(4)' illegal in sub-type
> > .\LMP-MIB:138: [5] {inetaddress-inetaddresstype} warning:
> > `InetAddress' object should have an accompanied preceding
> > `InetAdressType' object
> > .\LMP-MIB:386: [5] {inetaddress-inetaddresstype} warning:
> > `InetAddress' object should have an accompanied preceding
> > `InetAdressType' object
> > .\LMP-MIB:1213: [5] {inetaddress-inetaddresstype} warning:
> > `InetAddress' objectshould have an accompanied preceding
> > `InetAdressType' object
> >
> > Some details:
> > 1. lmpNbrNodeId OBJECT-TYPE
> > SYNTAX InetAddress (SIZE(4))
> > MAX-ACCESS not-accessible
> > STATUS current
> > DESCRIPTION
> > "This is a unique index for an entry in the LmpNbrTable.
> > This value represents the remote Node ID. The Node ID
> > address type must be IPv4."
> > ::= { lmpNbrEntry 1 }
> > You do know that MIB modules need to be IPv6 friendly, no?
> > Is LMP itself such that it only works with IPv4? I doubt that
> > IESG will approve new protocols that do not support IPv6.
> > 2. For these 2 objects:
> > lmpNbrRetransmitInterval LmpRetransmitInterval,
> > lmpNbrRetryLimit Unsigned32,
> > You may want to add some text as to howyou intend to deal with
> > congestion (RFC 2914). This over UDP if I remember well?
> > I think it would be good to point explicitly to the text in lmp
> > document (sect 10).
> > 3. lmpNbrRowStatus OBJECT-TYPE
> > SYNTAX RowStatus
> > MAX-ACCESS read-create
> > STATUS current
> > DESCRIPTION
> > "This variable is used to create, modify, and/or
> > delete a row in this table. All read-create objects
> > can only be changed when lmpNbrRowStatus is active."
> > That sounds strange. The notInService status was specifically
> > created to allow changes for cases where changes were not allowed
> > while row was active. Here you say it MUST be active in order
> > to make changes? Or did you mean "can not be changed"?
> > This occurs in more (maybe all) RowStatus objects in this doc.
> > 4. You have some objedts that are not part of a table, yet are
> > read-write. For example
> > lmpAdminStatus
> > lmpCcHelloIntervalDefault
> > lmpCcHelloIntervalDefaultMin
> > ... and more ...
> > What is the persistency behaviour of these objects?
> > In other words: is the value preserved over a reboot?
> > 5. Is lmpCcIsIf not redundant? The way I read it, then if the
> > lmpCcUnderlyingIfIndex has a value of zero, then it is NOT
> > an interface, no?
> > 6. lmpRemoteCcAddressType and lmpRemoteCcAddress
> > In the telink MIB you have done things correctly and as
> presscribe
> > by RFC3291. Here you have not. Why ?
> > Even in this doc you have done it correctly in some places.
> > 7. Mmmmmm??? 52 counters to "measure the performance" of
> the LMP channels?
> > Sounds overwhelming to me.
> > 8. Formally, every Counterxx object needs to include in its
> descritpion
> > clause which object indicates a potential discontinuity.
> I understand
> > that they all are covered by lmpCcCounterDiscontinuityTime in the
> > same row. Maybe write something about that in the
> ...Entry description
> > clause as well if you do not want to add text to every Counter
> > 9. lmpTeLinkTable
> > DESCRIPTION
> > "This table contains a collection of TE link."
> > Means what??
> > 10. lmpLinkVerificationInterval
> > What does a value of zero mean?
> > Any comments regarding possible congestiuon if the
> value is set to
> > a very small number of msecs?
> > 11. lmpLinkVerificationTable
> > Or is it better namep lmpTeLinkLinkVerificationTable
> > and then rename objects as well? If is correct name,
> > Then maybe rename
> > lmpTeLinkBitRate to lmpLinkVerificationTeLinkBitRate
> > lmpTeLinkWavelength to
> lmpLinkVerificationTeLinkWavelength
> > 12. lmpVerifyTransportMechanism
> > There are a few TBDs in there. Better decide before you
> submit to AD
> > 13. lmpTeLinkBitRate
> > DESCRIPTION
> > "This is the bit rate at which the Test messages will be
> > transmitted and is expressed in bytes per second."
> > A BIT rate that gest expressed in BYTES per second?
> > Possible of course but strange, no? Why not call it ByteRate?
> > 14. Another 40 or so counters for lmpTeLinkPerfTable ???
> > 15. lmpDataLinkPropertyMismatch NOTIFICATION-TYPE
> > OBJECTS { ifIndex,
> > lmpDataLinkRemoteIfId }
> > The second object already (implicitly) also contains the value
> > of the first object (it is the index part of the OID).
> > 16. I see quite a few NOTIFICATION-TYPES. You can enable or disable
> > them. But when they are enabled, what kind of rates per second
> > should we fear for in a worst case conidition?
> > Pls think about both an agent (i.e. an LMP node) generating
> > them, but also think about a SNMP management station receiving
> > them from potentially 100s or 1000s of LMP nodes.
> > 17. On page 7 I see:
> > lmpDataLinkAddressType = unnumbered(1),
> > Mm... that is not a valid value for an InetAddressType
> >
> > 18. Security COnsiderations
> > You are not following the guidelines to describe first the
> > SET (read-write, read-create) issues/concerns/vulnerabilities
> > and then the read-only sensistivities. So I would not be
> > surprised to see push back from the Security front.
> >
> > I have done a pretty serious review... but not exhaustive.
> >
> > Thanks,
> >
> > Bert
> > -----Original Message-----
> > From: Wijnen, Bert (Bert)
> > Sent: maandag 1 september 2003 20:14
> > To: 'Martin Dubuc'; Wijnen, Bert (Bert)
> > Subject: RE: LMP MIB
> >
> >
> > I have it on my todo-list. I am currently checking te-link mib.
> >
> >
> > Thanks,
> > Bert
> > -----Original Message-----
> > From: Martin Dubuc [mailto:m.dubuc@rogers.com]
> > Sent: maandag 1 september 2003 19:55
> > To: Bert Wijnen
> > Subject: LMP MIB
> >
> >
> > Bert,
> >
> > I know you have been quite busy with all the MPLS drafts. I
> just wanted to
> know if you had time review the LMP MIB draft and if not,
> when you think
> you'll get around reviewing it.
> >
> > Regards,
> >
> > Martin
>