[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Comments on LMP MIB
Hello,
My feedback
comments are prefixed "BM>"
/Baktha
======================================================
7.5. lmpLinkVerificationTable
This table represents the link verification parameters
associated
with the TE links.
BM> Add "Augments lmpTeLinkTable"
----------
7.7. lmpDataBearingLinkPerfTable
This table contains the objects to measure the LMP
performance of
data-bearing links and is an AUGMENT to the
lmpDataBearingLinkTable.
BM> Add "Augments lmpDataBearingLinkTable"
------------
8. Example of LMP Control Channel Setup
In this section we provide a brief example of using the
MIB
objects described in section 11 to set up an LMP control
channel.
While this example is not meant to illustrate every nuance
of the
MIB, it is intended as an aid to understanding some of the
key
concepts. It is meant to be read after going through the MIB
itself.
BM> Should read "objects desribed in section 10"
----------------
lmpAdminStatus OBJECT-TYPE
SYNTAX INTEGER {
up(1), down(2) }
MAX-ACCESS read-write
STATUS
current
DESCRIPTION
"The desired operational status
of LMP on the node."
DEFVAL { up
}
::= { lmpObjects 1 }
BM> Do we mean administrative state?
----------------------
lmpNbrTable OBJECT-TYPE
SYNTAX SEQUENCE OF
LmpNbrEntry
MAX-ACCESS not-accessible
STATUS
current
DESCRIPTION
"This table specifies the
neighbor node to which control channels
may be
established."
::= { lmpObjects 2 }
BM> neighbor node(s)
----------------------------
lmpNbrRetransmitInterval
= 10
Wouldn't want this to be the same for link verification, summary
etc.
----------------
lmpNbrAdminStatus OBJECT-TYPE
SYNTAX INTEGER {
up(1), down(2) }
MAX-ACCESS read-create
STATUS
current
DESCRIPTION
"The desired operational status
of LMP to this remote node."
::= { lmpNbrEntry 3 }
BM> Do we mean desired admin. state?
--------------------
lmpCcHelloIntervalDefaultMin
BM> Presumably, this serves as the default value for
lmpCcHelloIntervalMin?
lmpCcHelloIntervalDefaultMax
BM> Presumably, this serves as the default value for
lmpCcHelloIntervalMax?
lmpCcHelloDeadIntervalDefaultMin
BM> Presumably, this serves as the default value for
lmpCcHelloDeadIntervalMin?
lmpCcHelloDeadIntervalDefaultMax
BM> Presumably, this serves as the default value for
lmpCcHelloDeadIntervalMax?
------------------------
lmpCcHelloDeadIntervalDefault OBJECT-TYPE
SYNTAX
LmpInterval
MAX-ACCESS read-write
STATUS
current
DESCRIPTION
"This object specifies the
default HelloDeadInterval parameter to
use in the Hello protocol
keep-alive phase. It indicates how long
a device should wait before
declaring the control channel dead.
The HelloDeadInterval
parameter must be greater than the
HelloInterval parameter and
should be at least three times the
value of
HelloInterval."
BM> Remove the part "must be greated than the HelloInterval
parameter and"
-----------------
lmpCcIsIf OBJECT-TYPE
SYNTAX
TruthValue
MAX-ACCESS read-create
STATUS
current
DESCRIPTION
"Denotes whether or not this
control channel corresponds to
an interface represented in
the interfaces group table."
::= { lmpControlChannelEntry 3 }
BM> Why this additional object?. Why not require that there be a
valid
BM> lmpCcUnderlyingIfIndex for CC's rowstatsus to go into
"active" state
BM> and that in the absence of a valid underlying interface, the
CC
BM> will be in the "notReady" state?
BM>
BM> In the TE LInk case, we require that an entry of type "TE
Link" exist
BM> BEFORE the corresponding teLinkEntry is created... Why not do the
same
BM> with CC?. After all, the CC is not usable until a real
underlying
BM> interface is defined!
----------------
lmpCcNbrNodeId OBJECT-TYPE
SYNTAX
NodeID
MAX-ACCESS read-only
STATUS
current
DESCRIPTION
"This is the Node ID of the
control channel remote node.
This value gets created by the
node when a Config message
is received or when an
outgoing Config message is acknowledged
by the remote
node."
::= { lmpControlChannelEntry 4 }
BM> Should NOT be a read-only. Neighbor needs to be specified.
Consider
BM> an out-of-band Control channel over a shared ethernet LAN
interface-
BM> If neighbor is not specified, how will hello config be transmitted
to
BM> a neighbor?
BM> Only in the in-band (and with point to point link) case can the
neighbor
BM> IP address can be learnt!
-----------------
lmpRemoteCcId OBJECT-TYPE
SYNTAX
Unsigned32
MAX-ACCESS read-only
STATUS
current
DESCRIPTION
"This value represents the
remote control channel identifier. It is
determined during the
negotiation phase. A value
of zero means that the remote
control channel identifier has not
yet been assigned."
::= { lmpControlChannelEntry 5 }
BM> Should read "A value of zero means that the remote CC ID has
not yet been learnt"
----------------------
lmpCcSetupRole OBJECT-TYPE
SYNTAX INTEGER {
active(1), passive(2) }
MAX-ACCESS read-create
STATUS
current
DESCRIPTION
"The role that this node should
take during establishment of this
control channel. An active
node will initiate establishment. A
passive node will wait for the
remote node to initiate. A pair
of nodes that both take the
passive role will never establish
communications."
DEFVAL { active
}
Well, this is not consistent with the LMP draft, which defines automatic
contention
resolution mechanism based on node ID. Besides, this is prone to
human(operator)-error.
The LMP draft reads:
"To avoid ambiguities, the node with the higher Node Id wins
the contention; the node with the lower Node Id MUST stop
transmitting the Config message and respond to the Config
message it
received."
------------------------
lmpCcAdminStatus OBJECT-TYPE
SYNTAX INTEGER {
up(1), down(2) }
MAX-ACCESS read-create
STATUS
current
DESCRIPTION
"The desired operational status
of this control channel."
::= { lmpControlChannelEntry 17 }
BM> Should read "desired admin state"
BM> Why is the Admin Status of CC not tied to admin status of
the
BM> underlying interface?
---------------------
lmpTeLinkOperStatus OBJECT-TYPE
SYNTAX INTEGER {
up(1), down(2), testing(3), degraded(4) }
MAX-ACCESS read-only
STATUS
current
DESCRIPTION
"The actual operational status
of this TE link. The status
is set to testing when the TE
link is performing link
verification. A degraded
status indicates that the TE link
cannot provide the provisioned
protection level, but yet,
there is no disruption of
service. For instance, if the
protection type is 1+1 and one
link is down, the TE link
still carries the requested
amount of data traffic, but
this traffic is not protected
anymore."
::= { lmpTeLinkEntry 5 }
BM> This should reflect the Finite state machine states, defined in
the LMP draft,
BM> for TE Links.
------------------------------
lmpDataBearingLinkEntry OBJECT-TYPE
SYNTAX
LmpDataBearingLinkEntry
MAX-ACCESS not-accessible
STATUS
current
DESCRIPTION
"An entry in this table exists
for each ifEntry that represents
a data-bearing link. An
ifEntry with an ifIndex must exist
before the corresponding
lmpDataBearingLinkEntry is created.
If an entry representing the
data-bearing link is destroyed in
the ifTable, then so is the
corresponding entry in the
lmpDataBearingLinkTable. The
administrative status value is
controlled from the ifEntry.
The index to this table also
used to get information in the
dataBearingChannelTable
[BUNDLE-MIB]."
INDEX {
ifIndex }
BM> Why is this not an "AUGMENT" to ifEntry?
-------------
BM> From an LMP perspective, the "member data links" of a TE
Links need
BM> to be known.. I realize that this information is available from
the
BM> bundling MIB.. It may be handy to add an object to the data
bearing
BM> link table to store the TE Link ?
------------------
BM> Along the lines of TE Link and CC up/down traps, perhaps we should
have
BM> a trap to notify user when a data bearing link is transitioned to
"down"
BM> state due to link verification failure. Note that this information
is not
BM> obtainable from link up/down trap of underlying interface
===========================================