[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
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.
Right, this is why I think adding an object that is
similar to the ones added to the LSR/TE MIBs that lets
the manager configure the desired rate limit is appropriate.
>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.
Even still, if the implementation supports rate limiting,
and the manager can configure the number, that seems
like a reasonable thing to do. Anything more seems like
we will go down a rat hole.
--Tom
>
>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
>
>