[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
LMP MIB revision 7
Hi,
We're trying to wrap our brains around a couple of objects in the LMP MIB. They are
lmpCcUnderlyingIfIndex and lmpCcIsIf.
On the face of it, they seem to overlap because a zero value of lmpCcUnderlyingIfIndex
surely shows that the control channel is not associated with an interface.
However, I think you are trying to convey two separate concepts:
- control channel is modelled as an interface or not
- control channel is modelled as an interface *and*
control channel is associated with an interface or not
Is this correct?
This would give rise to three possible outcomes
- not modelled as interface
lmpCcIsIf == false
lmpCcUnderlyingIfIndex == 0
- modelled as interface but no interface associated
lmpCcIsIf == true
lmpCcUnderlyingIfIndex == 0
- modelled as interface and interface associated
lmpCcIsIf == true
lmpCcUnderlyingIfIndex != 0
OK so far?
So now I have some questions with putative answers. Perhaps you could confirm?
- Under what circumstances can you model the cc as an
interface but not have one assigned?
Answer:
When one has not yet been configured or discovered (or
assigned by the software - small window?)
- Can LMP operate when the cc is modelled as an interface
but one is not assigned?
Answer:
No. Under these circumstances, no LMP messages can
be sent on the control channel.
- What does it mean to say that the control channel is not
modelled as an interface?
Answer:
This simply means that the control channel does not appear
in the ifTable. It has no other meaning with respect to the
operation of LMP.
- Do we care to distinguish the case of {modelled but not assigned}
from {not modelled}?
Answer:
Yes. With {not modelled} LMP can continue to operate as
usual. With {modelled but not assigned} LMP must wait until
an ifIndex is assigned before it can operate.
In view of this, (and if I am right in all of the above) I wonder if we can clean up the
description of lmpCcUnderlyingIfIndex
From
"This value represents the underlying interface index, i.e.
the interface index of the interface over which the LMP
interface will transmit its traffic. If set to 0, then the
control channel is not associated with any underlying
interface. If the control channel is not associated with an
underlying interface, the control channel's operational
status must not be up(1), nor should the control channel
forward or receive traffic."
To
"If lmpCcIsIf is set to true(1), this object carries the index
into the ifTable of the entry that represents the LMP
interface over which LMP will transmit its traffic.
If this object is set to zero, but lmpCcIsIf is set to true(1),
the control channel is not currently associated with any
underlying interface and the control channel's operational
status must not be up(1), nor should the control channel
forward or receive traffic.
If lmpCcIsIf is set to false(2), this object should be set
to zero and should be ignored."
Similarly, can we change the description of lmpCcIsIf
From
"In implementations where the control channels are modeled
as interfaces, the value of this object is true(1) and
this control channel is represented by an interface in
the interfaces group table. If control channels are not
modeled as interfaces, the value of this object is
false(2) and there are no corresponding interface for
this control channel in the interfaces group table."
To
"In implementations where the control channels are modeled
as interfaces, the value of this object is true(1) and
this control channel is represented by an interface in
the interfaces group table as indicated by the value of
lmpCcUnderlyingIfIndex. If control channels are not
modeled as interfaces, the value of this object is
false(2), there is no corresponding interface for
this control channel in the interfaces group table,
and the value of lmpCcUnderlyingIfIndex should be
ignored."
We could also usefully add text to section 8 (Application of the Interfaces Group to LMP)
to say (right at the end of the section) ...
"Note that it is not a requirement that LMP control channels be modeled as interfaces. It
is acceptable that control channels simply exist as logical connections between adjacent
LMP-capable nodes. In this case, lmpCcIsIf is set to false(2) and no corresponding entry
is made in the ifTable."
Thanks a lot,
Adrian
----- Original Message -----
From: "Wijnen, Bert (Bert)" <bwijnen@lucent.com>
To: "Adrian Farrel" <adrian@olddog.co.uk>
Cc: "'Kireeti Kompella'" <kireeti@juniper.net>; <zinin@psg.com>; "Wijnen, Bert (Bert)"
<bwijnen@lucent.com>
Sent: Thursday, November 06, 2003 3:12 PM
Subject: RE: LMP MIB revision 6/7
> Mmmm... it helps somewhat... Maybe I get confused by:
> > > lmpCcUnderlyingIfIndex OBJECT-TYPE
> > > SYNTAX InterfaceIndexOrZero
> > > MAX-ACCESS read-create
> > > STATUS current
> > > DESCRIPTION
> > > "This value represents the underlying interface index, i.e.
> > > the interface index of the interface over which the LMP
> > > interface will transmit its traffic. If set to 0, then the
> s/interface/control channel/ ??? if so then it starts to be understandbale
> the way you described it.
>
> > > control channel is not associated with any underlying
> > > interface.
>
> But even so:
> > > interface. If the control channel is not associated with an
> > > underlying interface, the control channel's operational
> > > status must not be up(1), nor should the control channel
> > > forward or receive traffic."
>
> So what does that mean? that there can be no trafiic over the control
> channel if the cc is not associated with a underlying iface??
>
> Maybe you can bring up the discussion on the WG mailing list.
> I tried a few times and got nowhere. Maybe with your questioning and
> your proposed inetrpretation below, thing will become clearer and
> will hopefully result in descriptions that are understandable for
> mere mortals like myself?
>
> Thanks,
> Bert
>
> > -----Original Message-----
> > From: Adrian Farrel [mailto:adrian@olddog.co.uk]
> > Sent: woensdag 5 november 2003 18:01
> > To: Wijnen, Bert (Bert)
> > Cc: 'Kireeti Kompella'; zinin@psg.com; Wijnen, Bert (Bert)
> > Subject: Re: LMP MIB revision 6/7
> >
> >
> > My understanding here is (probably wrong as well)-:
> >
> > They are trying to handle two distinct things:
> > - control channel is modelled as an interface or not
> > - control channel is modelled as an interface *and*
> > control channel is associated with an interface or not
> >
> > Thus there are three possible outcomes
> > - not modelled as interface
> > lmpCcIsIf == false
> > lmpCcUnderlyingIfIndex == 0
> > - modelled as interface but no interface associated
> > lmpCcIsIf == true
> > lmpCcUnderlyingIfIndex == 0
> > - modelled as interface and interface associated
> > lmpCcIsIf == true
> > lmpCcUnderlyingIfIndex != 0
> >
> > The reasonable questions are
> > - Under what circumstances can you model the cc as an
> > interface but not have one assigned?
> > Answer: When one has not yet been configured or discovered
> > (or assigned by the software - small window?)
> > - Do we care to distinguish the case of {modelled but not assigned}
> > from {not modelled}?
> > Answer: This is unclear to me, but it might be that an
> > implementation
> > needs a trigger to perform discovery. This trigger would be
> > provided by {lmpCcIsIf == true, lmpCcUnderlyingIfIndex == 0}
> > where the single field would not provide enough information.
> > Similarly, if there is a need for gating user configuration of a cc
> > interface, then this would be achieved by the lmpCcIsIf object, but
> > I consider this more spurious.
> >
> > Does this help?
> >
> > Adrian
> > > lmpCcUnderlyingIfIndex OBJECT-TYPE
> > > SYNTAX InterfaceIndexOrZero
> > > MAX-ACCESS read-create
> > > STATUS current
> > > DESCRIPTION
> > > "This value represents the underlying interface index, i.e.
> > > the interface index of the interface over which the LMP
> > > interface will transmit its traffic. If set to 0, then the
> > > control channel is not associated with any underlying
> > > interface. If the control channel is not associated with an
> > > underlying interface, the control channel's operational
> > > status must not be up(1), nor should the control channel
> > > forward or receive traffic."
> > > ::= { lmpControlChannelEntry 2 }
> > >
> > > lmpCcIsIf OBJECT-TYPE
> > > SYNTAX TruthValue
> > > MAX-ACCESS read-create
> > > STATUS current
> > > DESCRIPTION
> > > "In implementations where the control channels are modeled
> > > as interfaces, the value of this object is true(1) and
> > > this control channel is represented by an interface in
> > > the interfaces group table. If control channels are not
> > > modeled as interfaces, the value of this object is
> > > false(2) and there are no corresponding interface for
> > > this control channel in the interfaces group table."
> > > ::= { lmpControlChannelEntry 3 }
> > >
> > > Do you understand that and does it make sense to you.
> > > To me it seems the two are either overlapping, or conflicting,
> > > or I just do not understand. I suspect it is the latter.
> >
>