Subject: mplsTunnelIn/OutSegementReroute Trap

From: "Thomas D. Nadeau" <[email-masked]>
Date: Mon, 06 Dec 1999 08:44:40 -0500

Hi,

         I would like to propose that a trap be added to the MPLS
TE MIB which alerts the NMS when a tunnel's segment has been
dynamically re-routed.

         --Tom

mplsTunnelInSegmentReroute NOTIFICATION-TYPE
    OBJECTS     { mplsTunnelIndex, mplsTunnelAdminStatus,
                         mplsTunnelOperStatus, mplsXCEntry,
                         mplsInSegmentIndex, mplsInSegmentLastFailReason
                         mplsInSegmentIndex}
    STATUS      current
    DESCRIPTION
        "This    notification is generated when a tunnel's 'out' segment is
          dynamically rerouted due to failure, overloading, etc.. The
           reason why this segment was rerouted is specified, as well
           as the new segment which was chosen to replace it.The first
           instance of the mplsInSegmentIndex object is used to note
           which segment is being re-routed, and the latter specifies which
           segment is being used to replace it."
    ::= { mplsTeNotifications 1 }

mplsTunnelOutSegmentReroute NOTIFICATION-TYPE
    OBJECTS     { mplsTunnelIndex, mplsTunnelAdminStatus,
                         mplsTunnelOperStatus, mplsXCEntry,
                         mplsOutSegmentIndex,
                         mplsOutSegmentLastFailReason,
                         mplsOutSegmentIndex }
    STATUS      current
    DESCRIPTION
        "This notification is generated when a tunnel's 'In' segment is
          dynamically rerouted due to failure, overloading, etc.. The
           reason why this segment was rerouted is specified, as well
           as the new segment which was chosen to replace it. The first
           instance of the mplsOutSegmentIndex object is used to note
           which segment is being re-routed, and the latter specifies which
           segment is being used to replace it."
    ::= { mplsTeNotifications 1 }

         I think that we should also consider adding two additional
objects to these new traps, one of which enumerates a possible
cause (i.e.: segement failure, etc...) of the tunnel's segment being
last re-routed, another other specifying the actual segment which
the segment which is now being used to replace it.

         In the first case, I think that we can simply add a new
attribute to the LSR MIB's XC tableEntry as defined below.
In the second case, we can just add another segment index
to the trap to denote the segment which was switched over
to.

mplsInSegmentLastFailReason OBJECT-TYPE
    SYNTAX        INTEGER {
          failed(1),          -- segment failure
          loadBalance(2),     -- dynamic load balance
          priorityOverride(3) -- higher pri tunnel override
          other(4)            -- some other reason
       }
    MAX-ACCESS    read-only
    STATUS        current
    DESCRIPTION
        ""
    ::= { mplsInSegment 7 }

mplsOutSegmentLastFailReason OBJECT-TYPE
    SYNTAX        INTEGER {
          failed(1),          -- segment failure
          loadBalance(2),     -- dynamic load balance
          priorityOverride(3) -- higher pri tunnel override
          other(4)            -- some other reason
       }
    MAX-ACCESS    read-only
    STATUS        current
    DESCRIPTION
        ""
    ::= { mplsOutSegment 7 }