Subject: Text Version: Need a Structural Change in MPLS-TE-MIB

From: "Zhu, Rupert" <[email-masked]>
Date: Mon, 10 Jun 2002 11:59:27 -0500

OK, here is the plain text version of the proposal.
---------------------------------------------------

            A Structural Change in MPLS-TE-MIB

Contents
---------------------------
o  Background
o  The Issue in MPLS-TE-MIB
o  The Issue in MPLS-FTN-MIB
o  Recommendation
---------------------------

-- Abstract

   This short memo analyzes issues in MPLS-TE-MIB and MPLS-FTN-MIB design
   and recommends a structural modification.

-- Background

   The concept of "traffic trunk" and "path" (LSP) are discussed
   extensively in a number of IETF RFC documents.  In particular,
   the following excerpt is from RSVP-TE spec [RFC3209].

      "The LSPs created with RSVP can be used to carry the "Traffic
      Trunks" described in [RFC2702].  The LSP which carries a
      traffic trunk and a traffic trunk are distinct though closely
      related concepts."

      "For example, two LSPs between the same source and destination
      could be load shared to carry a single traffic trunk."

      "Conversely several traffic trunks could be carried in the same
      LSP if, for instance, the LSP were capable of carrying several
      service classes.  The applicability of these extensions is
      discussed further in [RFC3210]."

   Combining the discussions in RFC2702 (MPLS TE), RFC3209 and RFC3210
   (RSVP-TE), we can see that "traffic trunk" and "path" (LSP) are
   two distinct concepts.  The former is an abstract logical entity
   while the latter is the underlying concrete entity.  A single
   "traffic trunk" may correspond to a group of "paths" via
   load sharing, backup protection or other schemes.

   The distinction of "traffic trunk" from the underlying
   path(s) represents a level of indirection.

-- The Issue in MPLS-TE-MIB

   The discussion is based on the most recent internet drafts

      draft-ietf-mpls-ftn-mib-04.txt       MPLS-FTN-MIB
      draft-ietf-mpls-te-mib-08.txt        MPLS-TE-MIB

   In MPLS-TE-MIB, the logical entity "traffic trunk" is modeled
   as "logical tunnel" while the underlying "path" entity is modeled
   as "tunnel instance".  This makes good distinction.

   Unfortunately, these two distinct entity classes are intertwined
   into a single MIB table (mplsTunnelTable).  This causes following
   problems.

   -- Ambiguity of Properties

      The mplsTunnelTable has as many as 37 columns.  Some of them
      represent properties of "logical tunnel" entity while others
      are properties of underlying "tunnel instance" entity.
      There is no clear distinction of these two categories
      when intermixing them in the same table.

   -- Duplication of Information

      A "logical tunnel" corresponds to a group of "tunnel instances".
      For all "tunnel instances" in one "tunnel instance group",
      their "logical tunnel" attributes (i.e., table fields) must have
      identical value.  For example,

         mplsTunnelIndex
         mplsTunnelIngressLSRId
         mplsTunnelEgressLSRId
         mplsTunnelIsIf
         mplsTunnelIfIndex
         mplsTunnelPrimaryInstance
         mplsTunnelRole

      Therefore, these fields must be duplicated across all rows
      belonging to the same "tunnel instance group".
      (A violation of relational data model principles.)
      Furthermore, if network administrator accidentally put different
      values to two rows belonging to the same instance group,
      MIB integrity would be compromised.

-- The Issue in MPLS-FTN-MIB

   -- FTN Mapping Should Be Based on "Logical Tunnel"

      In MPLS-FTN-MIB, the FEC is currently mapped to a "tunnel instance"
      instead of "logical tunnel", effectively nailing an FEC to an
      individual "tunnel instance".  This defeats the whole concept
      of "logical tunnel" or "traffic trunk".

      -----------------------------------------------------------
      (EXCERPT FROM CURRENT MPLS-FTN-MIB)
      mplsFTNActionPointer OBJECT-TYPE
         SYNTAX             RowPointer
         DESCRIPTION
             "If mplsFTNActionType is redirectLsp(2), then this
              object indicates the instance of mplsXCEntry for the
              LSP to redirect matching packets to. If
              mplsFTNActionType is redirectTunnel(3), then this
              object indicates the instance of mplsTunnelEntry for
              the MPLS tunnel to redirect matching packets to.
      -----------------------------------------------------------

      As mentioned earlier, a "logical tunnel" is an abstraction of a
      group of tunnel instances.  Taking advantage of this level of
      indirection, we should have FEC-to-NHLFE mapping established in
      the logical layer (based on "logical tunnels").  Load sharing,
      path selection and fail-over schemes should be hidden in the
      underlying path layer (based on "tunnel instances").
      Such schemes should be transparent to FTN mapping.

      Given that currently "logical tunnel" entity class and "tunnel
      instance" entity class are intertwined in the same MIB table,
      there is no way to make FEC map to "logical tunnel".  (This
      might explain why "FTNActionPointer" is made to point to
      a "tunnel instance" in current MIB definition.)

-- Recommendation

   The issues in MPLS-TE-MIB and MPLS-FTN-MIB are really due to a
   structural problem of mplsTunnelTable.  We can resolve these issues
   by spliting the big, monolithic "mplsTunnelTable" into two
   smaller tables, each modeling exactly one entity class.

         mplsLogicalTunnelTable
         mplsTunnelInstanceTable

   Then modify mplsFTNActionPointer definition to make it pointing
   to a row in the first table.  Note that a row in the first table
   may correspond to multiple rows in the second table.

Rupert Zhu

System Engineering
Santera Systems Inc.
972-461-6383 (TX, USA)