[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: LMP MIB revision 6
Bert,
I have submitted a new version of LMP MIB. See in-line to understand how I
addressed your concerns.
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"
>
Fixed. There were several issues with the conformance section. I have
fixed them.
> 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
>
Fixed.
> 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.
As mentioned in a previous message, I have created a textual convention
defined as a 4 octet octetstring. I have also added a reference to LMP
draft.
> 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).
I have added some text and a reference to section 10 of LMP
document for both objects.
> 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.
You are correct, it is the other way around (row must not be active
for change to be allowed). Fixed all RowStatus objects in MIB.
> 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?
Have added text to state that these objects should be
persistent in all read-write objects.
> 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?
Not redundant, as discussed in an earlier message. Have
added text to clarify.
> 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.
I have changed object to follow what was done in TE link MIB.
> 7. Mmmmmm??? 52 counters to "measure the performance" of the LMP channels?
> Sounds overwhelming to me.
There are a lot of counters. In the beginning, I had just a few, but then,
I was asked by WG to add more. It is very difficult to just pick
and choose. There are several functional blocks for which counters
are interesting. I would rather see them all in the MIB. But if WG feels
different I can cut down (but I will need direction).
> 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
I have added a sentence to this effect to the Entry description of
both tables.
> 9. lmpTeLinkTable
> DESCRIPTION
> "This table contains a collection of TE link."
> Means what??
I have clarified.
> 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?
Value 0 means no verification. I have added a sentence on consequence of
choosing a value too small.
> 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
I have changed the object name to better reflect the purpose of these
objects.
> 12. lmpVerifyTransportMechanism
> There are a few TBDs in there. Better decide before you submit to AD
I updated the list to the latest draft which had the effect of resolving the
issue with TBD entries.
> 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?
This object is now lmpTeLinkTransmissionRate and is expressed
in bytes per second.
> 14. Another 40 or so counters for lmpTeLinkPerfTable ???
Same as previous count table. Difficult to decide which to support
or not support since we are covered several functional areas.
> 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).
It is not so straightforward, because the ifIndex present in
lmpDataLinkRemoteIfId is the ifIndex on the other side
of the link. I still need the local ifIndex. I have used an
arbitrary object to recover this ifIndex. I hate to do this,
but if it is forbidden to use a not-accessible index,
then I have no choice. I have also done something similar
with lmpTeLinkDegraded, lmpTeLinkNotDegraded and
lmpDataLinkVerificationFailure notification.
> 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.
I have added a paragraph in the MIB at start of notification block to
discuss this issue. I have also added a lmpNotificationMaxRate object
that can be used to implement a throttling mechanism.
> 17. On page 7 I see:
> lmpDataLinkAddressType = unnumbered(1),
> Mm... that is not a valid value for an InetAddressType
>
Right. Fixed.
> 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 added the read-only object discussion.
> I have done a pretty serious review... but not exhaustive.
>
Will you need to review further before we can submit it to IESG?
> 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