[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: LMP MIB revision 7
Thanks. Before you submit, pls wait for me to completely
review the document. It may have to wait till after IETF
cause I am pretty busy this week (as I am sure you undestand).
Thanks,
Bert
> -----Original Message-----
> From: Martin Dubuc [mailto:dubuc.consulting@rogers.com]
> Sent: zaterdag 8 november 2003 16:59
> To: Adrian Farrel; jplang@ieee.org
> Cc: ccamp@ops.ietf.org; Wijnen, Bert (Bert)
> Subject: 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.
> > > >
> > >
> >
> >
>