Subject: Proposed LSR MIB Modifications for Edge/Core If/Segment Designation

From: "Thomas D. Nadeau" <[email-masked]>
Date: Mon, 22 Nov 1999 10:30:49 -0500

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 }

---

From: Eric Gray <[email-masked]>
Date: Mon, 22 Nov 1999 12:20:11 -0500

Thomas,

	I'm not a MIB expert, 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.  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...

You wrote:
> object which denotes whether or not this interfaces is an “edge”
> interface or an “core/internal” interface. I would also like this
> additional
> simply allow the trap’s receiver to prioritize the trap conveniently.
>         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."
>         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."
>         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."

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Mon, 22 Nov 1999 14:05:41 -0500

Points taken. Let me alter my proposed objects to enumerated
INTEGERS instead. Please note that I have changed slightly the
names of the objects to reflect their new, non-boolean types.

mplsInterfaceConnectDir OBJECT-TYPE
    SYNTAX      INTEGER {
                          edge(1),
                          core(2),
                          both(3),
                          neither(4)
                      }

    MAX-ACCESS    read-create
    STATUS        current
    DESCRIPTION
        "Denotes the direction in which this interface 'points'.
         That is, does the operator define this interface as
         connecting into the core of the network, to the edge
         of the network, to both, or perhaps to neither. The
         default value is to consider interfaces as interfacing
         to neither type.
    DEFVAL {neither}
    ::= { MplsInterfaceConfEntry 7 }

mplsInSegmentConnectDir OBJECT-TYPE

    MAX-ACCESS    read-create
    STATUS        current
    DESCRIPTION
        "Denotes the direction in which this segment 'points'.
         That is, does the operator define this interface as
         connecting into the core of the network, to the edge
         of the network, to both, or perhaps to neither. The
         default value is to consider interfaces as interfacing
         to neither type.
    DEFVAL {neither}
    ::= { mplsInSegmentEntry 9 }

mplsOutSegmentConnectDir OBJECT-TYPE

    MAX-ACCESS    read-create
    STATUS        current
    DESCRIPTION
        "Denotes the direction in which this segment 'points'.
         That is, does the operator define this interface as
         connecting into the core of the network, to the edge
         of the network, to both, or perhaps to neither. The
         default value is to consider interfaces as interfacing
         to neither type.
    ::= { mplsInSegmentEntry 9 }

>Any interface can be both an ingress and egress and a midpoint, so
>edge vs internal would have to allow an interface to be both.
>
>Curtis

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Mon, 22 Nov 1999 14:17:14 -0500

>         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
>as inclusive.

         Point taken; see my last posting to the list.

>This is especially true when applied to a

         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

---

From: "PHILIP MATTHEWS" <[email-masked]>
Date: Tue, 23 Nov 1999 07:27:23 -0500

I feel that most operators will find it very difficult to choose the type
of a router interface except in a few obvious cases.

If the purpose of this feature is to prioritize interfaces for trap
handling, why don't you simply assign a (trap-handling) priority to an interface?
Make the range 0..10 with a default of 5.

I believe that this will make the purpose of this feature much more obvious
to those who implement the MIB at a later date.

- Philip Matthews
Newbridge Networks Corporation

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Tue, 23 Nov 1999 12:15:52 -0500

Hi,

         I have received several responses to my original proposal
of an additional interface/segment attribute denoting a "core" or
"edge" designation. Most folks do not think that such an
attribute is necessary in the form which was proposed. However,
many people including myself, believe that some sort of
prioritized parameter would be a useful addition to both MPLS
interfaces and segments in the LSR MIB. Please note that my
choice of (5) as the default value was completely arbitrary. I
am totally open to changing this value to something else if
there are good reasons for doing so. Furthermore, the range I
chose was also arbitrary. I thought that 10 levels of priority
would suffice. Let me make the following proposal.

mplsInterfacePriority OBJECT-TYPE
    SYNTAX      INTEGER {1..10}
    MAX-ACCESS    read-create
    STATUS        current
    DESCRIPTION
        "Denotes the priority of the interface as designated
         by the operator, (10) being the highest, and (1)
         being the lowest. This priority will be used later
         as a means of filtering and prioritizing traps issued
         on this interface. The default priority is (5)."
    DEFVAL {5}
    ::= { MplsInterfaceConfEntry 7 }

mplsInSegmentPriority OBJECT-TYPE
    SYNTAX      INTEGER {1..10}
    MAX-ACCESS    read-create
    STATUS        current
    DESCRIPTION
        "Denotes the priority of the segment as designated
         by the operator, (10) being the highest, and (1)
         being the lowest. This priority will be used later
         as a means of filtering and prioritizing traps issued
         on this segment. The default priority is (5)."
    DEFVAL {5}
    ::= { mplsInSegmentEntry 9 }

mplsOutSegmentPriority OBJECT-TYPE
    SYNTAX      INTEGER {1..10}
    MAX-ACCESS    read-create
    STATUS        current
    DESCRIPTION
         "Denotes the priority of the segment as designated
         by the operator, (10) being the highest, and (1)
         being the lowest. This priority will be used later
         as a means of filtering and prioritizing traps issued
         on this segment. The default priority is (5)."
    DEFAL {5}
    ::= { mplsInSegmentEntry 9 }

         These should all be added to the corresponding traps as well.

         --Tom

---

From: "PHILIP MATTHEWS" <[email-masked]>
Date: Wed, 24 Nov 1999 07:28:36 -0500

A couple of minor points:
(1) Could the description of "mplsInSegmentPriority" and "mplsOutSegmentPriority"
be expanded to explain the difference between these two objects?
(2) There are a couple of typos in the definition of "mplsOutSegmentPriority"
    (on the last couple of lines).

- Philip Matthews
Newbridge Networks Corp

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Wed, 24 Nov 1999 07:40:41 -0500

Good morning,

>be expanded to explain the difference between these two objects?

         Would the MIB authors like the jump in here?