Subject: [ifmib] lowerLayerDown == down for link trap generation (was RE: [ifmib] about LinkUp/LinkDown traps)

From: "Perreault, Jason" <[email-masked]>
Date: Tue, 30 Oct 2001 16:13:25 -0500

In his reply to snmp2jassi re link traps, Mike says in part:

> This is covered in RFC 2863 Section 3.1.15, "Traps".
> In particular,
>
>    Therefore, this memo defines that LinkUp and linkDown 
>    traps are generated just after ifOperStatus leaves, or 
>    just before it enters, the down state, respectively; 
>    except that LinkUp and linkDown traps are never generated
>    on transitions to/from the notPresent state.  FOR THE 
>    PURPOSE OF DECIDING WHEN THESE TRAPS OCCUR, THE 
>    lowerLayerDown STATE AND THE down STATE ARE CONSIDERED 
>    TO BE EQUIVALENT, i.e., THERE IS NO TRAP ON TRANSITION 
>    FROM lowerLayerDown INTO down, AND THERE IS A TRAP ON
>    TRANSITION FROM ANY OTHER STATE EXCEPT down (and
>    notPresent) INTO lowerLayerDown.

[CAPS added by me for emphasis.]

Does anyone else find this to be in conflict with 1) the 
interpretation of the corresponding section of RFC2233, which 
contains only the first of those two sentences; and 2) the 
DESCRIPTIONs of the linkUp/linkDown notifications themselves, 
which refer to "the" (not "a") down state?

Had Mike not quoted this, I might never have noticed it.
It is not among the changes described in RFC2863 Section 11,
"Changes from RFC 2233".

Because of the reference in that first sentence to "the" 
down state and similar language in the actual definitions 
of the link traps (all of which I took to be deliberate), 
I've always considered lowerLayerDown to be a pseudo-"up" 
state for purposes of link trap generation. 

This makes sense from the perspective of wanting to limit 
link trap generation to the lowest layer directly experiencing 
a fault. Affected higher layer interfaces (i.e. those in the
lowerLayerDown state) could be identified by directed polling 
(e.g. ifInvStackTable).

For what it's worth, the DESCRIPTIONs of ifOperStatus, linkUp,
and linkDown are unchanged from RFC2233. If the behavior 
described in RFC2863 is truly intended, it's unfortunate
the clarification was omitted from the MIB module itself.

Jason Perreault
Unisphere Networks

_______________________________________________
ifmib mailing list
[email-masked]
http://www1.ietf.org/mailman/listinfo/ifmib

---

From: "C. M. Heard" <[email-masked]>
Date: Tue, 30 Oct 2001 14:11:09 -0800 (PST)

> which refer to "the" (not "a") down state?

I think this was intended to be a clarification of RFC 2233.
My guess is that some of the interpretations varied, and this
one was the "rough consensus" of the implementors.

> It is not among the changes described in RFC2863 Section 11,

It certainly should have been listed.

> lowerLayerDown state) could be identified by directed polling 

You have a point ... certainly it is common telecom practice
(demanded, not just requested, by customers) to suppress all but
"root cause" alarms.  Not generating a trap on "lowerLayerDown"
would be in keeping with that.

Often this won't matter anyway -- in most of the MIB modules that
use interface layering it is recommended that linkUpDownTrapEnable
be set to false(2) when there is a lower layer (i.e., when the
lowerLayerDown state applies).

> the clarification was omitted from the MIB module itself.

Well, there will be at least one more review before the IF-MIB
goes to full standard.  This issue should be raised at that time.

Mike