RE: Question in draft-ietf-ccamp-lmp-mib-03.txt

["Martin Dubuc" <Martin.Dubuc@meriton.com>]

Bert,

As the description of the notification says, the first object (ifIndex) is the interface index of the TE link. This index is an index to the lmpTeLinkTable. The second object (lmpDataLinkRemoteIfId) is the remote data link (not TE link) interface identifier. It is the index to the lmpDataLinkTable on the remote node.

There is no way to figure out TE link index from the remote data link interface identifier OID and vice-versa.

Martin

-----Original Message-----
From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com]
Sent: Monday, July 22, 2002 3:01 PM
To: Martin Dubuc; Jing Qian
Cc: ccamp@ops.ietf.org
Subject: RE: Question in draft-ietf-ccamp-lmp-mib-03.txt



> -----Original Message-----
> From: Martin Dubuc [mailto:Martin.Dubuc@meriton.com]
> Sent: maandag 22 juli 2002 18:49
> To: Wijnen, Bert (Bert); Jing Qian
> Cc: ccamp@ops.ietf.org
> Subject: RE: Question in draft-ietf-ccamp-lmp-mib-03.txt
> 
> 
> Bert,
> 
> For the lmpDataLinkPropertyMismatch notification, the first 
> object (ifIndex) is the interface index of the TE link and 
> the lmpDataLinkRemoteIfId is the data link remote interface 
> identifier. Both objects are required in this notification.
> 
Is that not the same ifIndex as the one used to index into this
table? If so then it is already part of the OID for 
lmpDataLinkremotedIfId is it not? If not, then you may want to
make that somewhat clearer... (or is it just me who does not
see this right away????)

> For the lmpTeLinkDegraded/lmpTeLinkNotDegraded notifications, 
> I could use the lmpTeLinkOperStatus object instead of 
> ifIndex. For the lmpTeLinkDegraded, ifIndex is good enough, 
> but for lmpTeLinkNotDegraded, the lmpTeLinkOperStatus would 
> bring some value. We probably want to have same object for 
> both notifications. I'll make note of this change for the 
> next version.
> 
Thanks

Bert
> Martin
> 
> -----Original Message-----
> From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com]
> Sent: Monday, July 22, 2002 11:05 AM
> To: Jing Qian
> Cc: Martin Dubuc; ccamp@ops.ietf.org
> Subject: RE: Question in draft-ietf-ccamp-lmp-mib-03.txt
> 
> 
> Inline
> > -----Original Message-----
> > From: Jing Qian [mailto:jing.qian@alcatel.com]
> > Sent: maandag 22 juli 2002 16:21
> > To: Wijnen, Bert (Bert)
> > Cc: martin.dubuc@meriton.com; ccamp@ops.ietf.org
> > Subject: Re: Question in draft-ietf-ccamp-lmp-mib-03.txt
> > 
> > Did you mean OID is automatically as part of the trap 
> message payload?
> 
> the lmpCcId is the INDEX for these objects itself, so that is
> why it comes as part of the OID in the varbind for OperStatus and 
> Adminstatus
> 
> > If in this case, why all the other trap still put the OID in 
> > the OBJECT part?
> > For example, in draft-ietf-ccamp-lmp-mib-03.txt:
> >         lmpDataLinkPropertyMismatch NOTIFICATION-TYPE
> >            OBJECTS       { ifIndex,
> >                                          lmpDataLinkRemoteIfId }
> 
> In the above case, the ifIndex indeed already is part of theOID
> for the lmpDataLinkRemoteIfId, and so it is not needed.
> 
> >         lmpTeLinkDegraded NOTIFICATION-TYPE
> >            OBJECTS       { ifIndex }
> > 
> In this one, at least some object seems to be needed in order
> to indicate to the interface that has a problem. But possibly 
> another object might make more sense.
> 
> Authors/WG... what do you think about this?
> 
> > Also, why need lmpCcOperStatus for lmpControlChannelUp and
> > lmpControlChannelDown? The trap message name already define
> > the lmpCcOperStatus.
> > 
> That is a valid question. I think sending the extra OperStatus
> varbind does not really hurt, but it indeed seems to be
> implied in the name of the NOTIFICATION
> 
> Bert
>