[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: LMP MIB revision 7
Adrian,
Your interpretation of lmpCcUnderlyingIfIndex and lmpCcIsIf is correct and I
like the clarifications that you are recommending. I can add these to the
upcoming version of the MIB (which I should release shortly).
Martin
----- Original Message -----
From: "Adrian Farrel" <adrian@olddog.co.uk>
To: <dubuc.consulting@rogers.com>; <jplang@ieee.org>
Cc: <ccamp@ops.ietf.org>; "Wijnen, Bert (Bert)" <bwijnen@lucent.com>
Sent: Friday, November 07, 2003 7:08 AM
Subject: 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.
> > >
> >
>
>