Subject: RE: Proposed LSR MIB Modifications for Edge/Core If/SegmentDesign ation

From: [email-masked]
Date: Tue, 23 Nov 1999 09:28:54 +0100

Hi Thomas,
Reading this discussion, I get the impression that what you are really
looking for is not an indication about edge or core, but an
administrator-configurable "trap priority".
Why not go directly for that? It would simplify the
description/implementation and be more flexible, for no additional cost.

Cheers,
Juerg

-----Original Message-----
From: Thomas D. Nadeau [mailto:[email-masked]]
Sent: Montag, 22. November 1999 20:17
To: [email-masked]
Cc: Arun Viswanathan; [email-masked]; [email-masked]; [email-masked]
Subject: Re: Proposed LSR MIB Modifications for Edge/Core
If/SegmentDesignation

>         I'm not a MIB expert,

         Neither am I, but I try. *)

>but I think that interfaces may also be both or either.
>That seems incompatible with a
>boolean data type unless one or the other value is treated
>as inclusive.

         Point taken; see my last posting to the list.

>This is especially true when applied to a
>physical interface and it is not at all clear to me what an
>'edge' MPLS logical interface is - i.e. it seems to me that
>an edge logical interface is not an MPLS interface at all...

         What I am referring to as "edge interfaces" or "edge
segments" are the MPLS interfaces which are at the edge of
one's network -- either ingress or egress, and I am trying to
distinguish those from the rest of the interfaces in the network.
I am making the assumption that those point into the core if they
are not at the edge, and are still MPLS interfaces. This was my
motivation for the boolean type. However, I think that it is quite
reasonable to not mandate this, and so I changed the value to an
enumerated INTEGER. As I pointed out in my original message,
I think that it would be quite useful to be able to mark certain
interfaces from a network management perspective, as residing
at the "edge" of my network, or in the "core" of my MPLS network.

         Does that make any more sense, or have I just confused
things further? ;)

         --Tom

> >         Hello,
> >
> > I would like to propose that the following modifications be made to
> > the
> > draft-ietf-mpls-lsr-mib-00 Label Switch Router MIB.
> >
> > First, I would like to add a new object attributes to the
> > mplsInterface
> > object which denotes whether or not this interfaces is an "edge"
> > interface or an "core/internal" interface. I would also like this
> > additional
> > attribute to be added to the mplsInterfaceUp and mplsInterfaceDown
> > traps.
> > The advantage of differentiating interfaces according to whether or n
> > ot they are connected to the core or edge of the MPLS network is to
> > simply allow the trap's receiver to prioritize the trap conveniently.
> > That is, if one considers the number of MPLS interfaces which may
> > issue traps at any one point in time, it might be preferred by some
> > ISP to handle traps on edge interfaces at a higher priority over
> > those which are on the inside or core of the network. The reasoning
> > here is that a customer will probably loose all connectivity if an
> > edge interface goes down, whereas there will probably (hopefully!)
> > be an alternate path through the network if an mplsInterface
> > connecting one LSR to another inside the core of the network goes
> > down.
> >
> > My changes for MPLS interfaces are detailed here:
> >
> > mplsInterfaceIsEdge OBJECT-TYPE
> >    SYNTAX        TruthValue
> >    MAX-ACCESS    read-create
> >    STATUS        current
> >    DESCRIPTION
> >        "Denotes whether or not this MPLS interface connects to
> >         what the operator deems the 'edge' of their network, or
> >         the 'core' of their network. The default value is to
> >         consider interfaces as interfacing the 'core' of the
> >         network."
> >    ::= { MplsInterfaceConfEntry 7 }
> >
> > mplsInterfaceUp NOTIFICATION-TYPE
> >    OBJECTS     { mplsInterfaceConfIndex,
> >                 mplsInterfaceAdminStatus, mplsInterfaceOperStatus,
> >                 mplsInterfaceIsEdge }
> >    STATUS      current
> >    DESCRIPTION
> >        "This    notification    is    generated    when    a
> >         mplsInterfaceOperStatus  object  for  one   of   the
> >         entries in mplsInterfaceConfTable is about to  leave
> >         the  down state and transition into some other state
> >         (but  not  into the notPresent state).   This  other
> >         state   is  indicated  by  the  included  value   of
> >         mplsInterfaceOperStatus."
> >    ::= { mplsLsrNotifications 1 }
> >
> > mplsInterfaceDown NOTIFICATION-TYPE
> >    OBJECTS     { mplsInterfaceConfIndex,
> >                 mplsInterfaceAdminStatus, mplsInterfaceOperStatus,
> >                 mplsInterfaceIsEdge }
> >    STATUS      current
> >    DESCRIPTION
> >        "This    notification    is    generated    when    a
> >         mplsInterfaceOperStatus  object  for  one   of   the
> >         entries in mplsInterfaceConfTable is about to  enter
> >         the  down state from some other state (but not  from
> >         the   notPresent  state).   This  other   state   is
> >         indicated     by    the    included     value     of
> >         mplsInterfaceOperStatus."
> >    ::= { mplsLsrNotifications 2 }
> >
> > Using the same motivation I gave above for mplsInterfaces,
> > I would also like to add the above changes to the LSR segment
> > table in the form of a new attribute called mplsInSegmentIsEdge
> > and mplsOutSegmentIsEdge. Likewise, I would also like these
> > attributes correspondingly to be added to the
> > mplsInSegmentUp, mplsInSegmentDown, mplsOutSegmentUp and
> > mplsOutSegmentDown Traps. My changes for MPLS segments are
> > detailed below:
> >
> > mplsInSegmentIsEdge OBJECT-TYPE
> >    SYNTAX        TruthValue
> >    MAX-ACCESS    read-create
> >    STATUS        current
> >    DESCRIPTION
> >        "Denotes whether or not this segment connects to
> >         what the operator deems the 'edge' of their network, or
> >         the 'core' of their network. The default value is to
> >         consider interfaces as interfacing the 'core' of the
> >         network."
> >    ::= { mplsInSegmentEntry 9 }
> >
> > mplsOutSegmentIsEdge OBJECT-TYPE
> >    SYNTAX        TruthValue
> >    MAX-ACCESS    read-create
> >    STATUS        current
> >    DESCRIPTION
> >        "Denotes whether or not this segment connects to
> >         what the operator deems the 'edge' of their network, or
> >         the 'core' of their network. The default value is to
> >         consider interfaces as interfacing the 'core' of the
> >         network."
> >    ::= { mplsInSegmentEntry 9 }
> >
> > mplsInSegmentUp NOTIFICATION-TYPE
> >    OBJECTS     { mplsInSegmentIfIndex, mplsInSegmentLabel,
> >                 mplsInSegmentAdminStatus, mplsInSegmentOperStatus,
> >                 mplsInSegmentIsEdge }
> >    STATUS      current
> >    DESCRIPTION
> >        "This    notification    is    generated    when    a
> >         mplsInSegmentOperStatus  object  for  one   of   the
> >         configured  in-segments is about to leave  the  down
> >         state and transition into some other state (but  not
> >         into  the  notPresent state).  This other  state  is
> >         indicated     by    the    included     value     of
> >         mplsInSegmentOperStatus."
> >    ::= { mplsLsrNotifications 3 }
> >
> > mplsInSegmentDown NOTIFICATION-TYPE
> > OBJECTS     { mplsInSegmentIfIndex, mplsInSegmentLabel,
> >                 mplsInSegmentAdminStatus, mplsInSegmentOperStatus,
> >                 mplsInSegmentIsEdge }
> >    STATUS      current
> >    DESCRIPTION
> >        "This    notification    is    generated    when    a
> >         mplsInSegmentOperStatus  object  for  one   of   the
> >         configured  in-segments is about to enter  the  down
> >         state  from  some  other state  (but  not  from  the
> >         notPresent state).  This other state is indicated by
> >         the included value of mplsInSegmentOperStatus."
> >    ::= { mplsLsrNotifications 4 }
> >
> > -- Out-segment.
> >
> > mplsOutSegmentUp NOTIFICATION-TYPE
> >    OBJECTS     { mplsOutSegmentIndex, mplsInSegmentAdminStatus,
> >                 MplsInSegmentOperStatus, mplsOutSegmentIsEdge }
> >    STATUS      current
> >    DESCRIPTION
> >        "This    notification    is    generated    when    a
> >         mplsOutSegmentOperStatus  object  for  one  of   the
> >         configured out-segments is about to leave  the  down
> >         state and transition into some other state (but  not
> >         into  the  notPresent state).  This other  state  is
> >         indicated     by    the    included     value     of
> >         mplsOutSegmentOperStatus."
> >    ::= { mplsLsrNotifications 5 }
> >
> > mplsOutSegmentDown NOTIFICATION-TYPE
> >    OBJECTS     { mplsOutSegmentIndex, mplsInSegmentAdminStatus,
> >                 MplsInSegmentOperStatus, mplsOutSegmentIsEdge }
> >    STATUS      current
> >    DESCRIPTION
> >        "This    notification    is    generated    when    a
> >         mplsOutSegmentOperStatus  object  for  one  of   the
> >         configured out-segments is about to enter  the  down
> >         state  from  some  other state  (but  not  from  the
> >         notPresent state).  This other state is indicated by
> >         the included value of mplsOutSegmentOperStatus."
> >    ::= { mplsLsrNotifications 6 }