----------------------
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)
[Martin
Dubuc] OK.
----------------------------
lmpNbrRetransmitInterval
= 10
Wouldn't want this to be the same for link verification, summary
etc.
[Martin Dubuc] The message retransmission
procedure in the latest draft seems to be a generic procedure that is not
specific to the message types (as opposed to earlier versions of the drafts).
This is why I have collapsed it into a single
object.
----------------
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?
[Martin
Dubuc] Same as
above.
--------------------
lmpCcHelloIntervalDefaultMin
BM>
Presumably, this serves as the default value for
lmpCcHelloIntervalMin?
[Martin Dubuc] Yes. I will be more specific in the
MIB.
lmpCcHelloIntervalDefaultMax
BM>
Presumably, this serves as the default value for
lmpCcHelloIntervalMax?
[Martin Dubuc] Same as
above.
lmpCcHelloDeadIntervalDefaultMin
BM>
Presumably, this serves as the default value for lmpCcHelloDeadIntervalMin?
[Martin
Dubuc] Same as
above.
lmpCcHelloDeadIntervalDefaultMax
BM>
Presumably, this serves as the default value for
lmpCcHelloDeadIntervalMax?
[Martin Dubuc] Same as
above.
------------------------
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"
[Martin Dubuc] OK.
-----------------
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!
[Martin
Dubuc] This allows pre-provisioning of control channels. I guess the same
logic could apply to TE links as well. Not sure what to
do.
--------------
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!
[Martin
Dubuc] I could change to read-write and specify in the conformance
statements that it can be
read-only.
-----------------
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"
[Martin
Dubuc] OK.
----------------------
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."
[Martin Dubuc] Yes, but the
draft also allows control channels to be put in a ConfigRcv state, in
which the node is waiting for acceptable configuration from the remote node. I
agree that this is prone to human error, but we have to be able to support
this
mode.
------------------------
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?
[Martin Dubuc] Desired
operational status (see above). As for tying in admin status of CC to admin
status of underlying interface, I do not believe we should tie these
two. It is possible that one wants to disable a control channel, but not
affect any other interfaces/applications sitting on top of the underlying
interface. For instance, one may want to strictly disable
LMP.
---------------------
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.
[Martin
Dubuc] I will update the description. Do you want me to remove the
testing
state?
------------------------------
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?
[Martin
Dubuc] There is no reason why it shouldn't. Can someone give
me a reason why it
shouldn't?
-------------
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 ?
[Martin Dubuc] The info is
actually not in the link bundling MIB, but in the
ifStackTable.
------------------
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
[Martin Dubuc] I will consider this in the next
version.
===========================================