Subject: MPLS-TE-MIB Report 1/3: Ambiguities

From: "Zhu, Rupert" <[email-masked]>
Date: Mon, 11 Nov 2002 12:31:58 -0600

Tom and MIB Authors:

I joined the MPLS mailing list only 5 months ago, so I missed the
opportunity to provide my input at early stage of MPLS-TE-MIB.
Given this, I can only make "best effort" contribution to the group.
In this and next two Emails, I would submit my comments on MIB details.

As we all would agree, a well-designed MIB should demonstrate
Consistency, Accuracy and Clarity.  Often, the easiest approach
for clarity is "speak by structure".  Instead of wordy descriptions
for every table field, let the structure speak for itself.

If the authors choose to mix "Tunnel" and "Tunnel Instance" in a single
MIB table, then it becomes a burden on the authors to ensure Accuracy.
Use clear, unambiguous terminology to indicate which fields are
Tunnel's property and which fields are Tunnel Instance's property.

A (logical) tunnel consists of a group of tunnel instances.
When having these two entity classes in the same table, each row
represents a unique tunnel instance while a set of rows, collectively,
represent the (logical) tunnel.  This distinction is very important.

If a field is a property of tunnel, its value has to be copied
across all rows that constitute the tunnel.  These duplications
are undesirable, not only because it's a waste of storage but also
because it poses a burden on maintaining data integrity.

(When adding or modifying a row, software must remember
to propagate the changes to ALL other rows belonging to
the same tunnel. Otherwise, system integrity would be lost.)

On the other hand, if a field is a property of tunnel instance,
then each row is allowed to have its own value for this field.
A change on one row does not need to propagate to other rows.

Looking at the most recent draft (draft-ietf-mpls-te-mib-09.txt),
I found that the ambiguities still remain.  Among the 37 fields
in mplsTunnelTable, only 5 fields clearly indicated
tunnel instance-specific nature.  Most of other fields simply
mentions "tunnel", leaving readers to guess in the dark.

CASE 1: Explicit Indication of Tunnel Instance Property (5 fields)

      INSTANCE: mplsTunnelInstance
      INSTANCE: mplsTunnelInstancePriority
      INSTANCE: mplsTunnelStateTransitions
      INSTANCE: mplsTunnelRole
      INSTANCE: mplsTunnelInstanceUpTime

CASE 2: No Indication of Tunnel-vs-Tunnel Instance (5 fields)

      NONE: mplsTunnelIndexIndex
      NONE: mplsTunnelEgressLSRId
      NONE: mplsTunnelIncludeAnyAffinity
      NONE: mplsTunnelIncludeAllAffinity
      NONE: mplsTunnelExcludeAllAffinity

CASE 3: Explicit Indication of Tunnel Property (26 fields)

      TUNNEL: mplsTunnelIngressLSRId
      TUNNEL: mplsTunnelName
      TUNNEL: mplsTunnelDescr
      TUNNEL: mplsTunnelIsIf
      TUNNEL: mplsTunnelIfIndex
      TUNNEL: mplsTunnelXCPointer
      TUNNEL: mplsTunnelSignallingProto
      TUNNEL: mplsTunnelSetupPrio
      TUNNEL: mplsTunnelHoldingPrio
      TUNNEL: mplsTunnelSessionAttributes
      TUNNEL: mplsTunnelOwner
      TUNNEL: mplsTunnelLocalProtectInUse
      TUNNEL: mplsTunnelResourcePointer
      TUNNEL: mplsTunnelHopTableIndex
      TUNNEL: mplsTunnelARHopTableIndex
      TUNNEL: mplsTunnelCHopTableIndex
      TUNNEL: mplsTunnelPathChanges
      TUNNEL: mplsTunnelLastPathChange
      TUNNEL: mplsTunnelPathInUse
      TUNNEL: mplsTunnelAdminStatus
      TUNNEL: mplsTunnelOperStatus
      TUNNEL: mplsTunnelStorageType
      TUNNEL: mplsTunnelPrimaryInstance
      TUNNEL: mplsTunnelPrimaryTimeUp
      TUNNEL: mplsTunnelCreationTime
      TUNNEL: mplsTunnelTotalUpTime

What bothers me is the 26 fields in Case 3.

Are All of These Fields Properties of Tunnel?

   If the answer is Yes, then we have a huge data duplication issue
   because the value of these 26 fields must be copied across all rows
   belonging to the same (logical) tunnel.

I think some of these fields actually are properties of tunnel instance.
For example, "mplsTunnelSignallingProto" should be a property of tunnel
instance instead of tunnel.  For a given (logical) tunnel, some of its
tunnel instances may be established by RSVP-TE, some by CR-LDP, yet some
others by management commands (e.g., SNMP).  The rows belonging to
the same tunnel do not have to share the same value.

Although domain experts may be able to guess the nature of these
fields, a more accurate and unambiguous description is preferred.

Better yet, if we had chosen a modular MIB structure,
these ambiguities wouldn't come into the scene at all.

A Structure Is Worth A Thousand Words.  :-)

-- Rupert

Rupert Zhu
System Engineering
Santera Systems Inc
3605 E. Plano Parkway
Plano, TX 75074
Phone: 972-461-6383

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Mon, 11 Nov 2002 13:52:58 -0500

Hi,

         Thanks for your additional comments.

>for every table field, let the structure speak for itself.

         I think that we would also agree that a MIB designed purely
for "Consistency, Accuracy and Clarity" sounds good in theory,
but sometimes in practice the MIB that is best might not be
the best given these three things.  Just take a look around at
other MIBs that are available. I will assert that although not pretty,
they work pretty well in practice.

>Tunnel's property and which fields are Tunnel Instance's property.

         Agreed. If you see descriptions that need improvement, please
by all means provide text to correct the situation.

>A (logical) tunnel consists of a group of tunnel instances.

         Only if tunnel instances are signaled successfully given
the parameters configured on the tunnel and the state of the network.

>represent the (logical) tunnel.  This distinction is very important.

         Correct.

>across all rows that constitute the tunnel.

         That makes perfect sense given the fact that many
configuration options are copied to the LSP in order to
signal it.

>These duplications

         There is no redundant storage in a real implementation.
Real implementations copy the configured parameters to the
active ones in the signaling protocol. This is just how things
work.  There are however, some cases where the configured
parameters may not be reflected in the signaled/active
instance of the tunnel. Take the tunnel hops for instance.
The configured hop list might vary in several ways on the
active tunnel. Leaving the same objects to access on both
makes things easier for both the agent and the manager, IMHO.

>the same tunnel. Otherwise, system integrity would be lost.)

         It depends on what you mean by "the software". If you
mean the agent software, then yes, the agent must keep things
consistent. This is not out of the realm of reality. Just look at
how the CLI on most boxes is used to configure tunnels.
The same model applies there.  Furthermore, since the parameters
being modified are in general, all within the same software
subsystem (i.e.: RSVP-TE), this is not such a burden as an
advantage.

>A change on one row does not need to propagate to other rows.

         A change in one row must result in a change in the other
rows if the instance is part of the main tunnel table or not.
If I configure a tunnel head (mplsTunnelTable instance .0),
and then signal an LSP for that tunnel, some of the signaled
LSP's state information (i.e.: total tunnel uptime ) needs to be
"copied" to the head instance as well.   Another example would
be the hop table configuration in the head for the signaled
LSP. In this case the signaled LSP needs to reflect the hop
table as the list of hops it was passed. There are BTW, ways
to re-use the same entries in the HOP and resource tables
between tunnels and their instances. This is spelled out in
the descriptions.

>mentions "tunnel", leaving readers to guess in the dark.

         So please suggest some text to add to the draft.

         --Tom

>A Structure Is Worth A Thousand Words.  :-)

Success is relative; the more success, the more relatives. -Anonymous

---

From: "Brian Hassink" <[email-masked]>
Date: Mon, 11 Nov 2002 13:43:32 -0500

Don't know that it counts for anything, but I just wanted to add my support for Rupert's comments regarding the existing mplsTunnelTable.

In implementing support for this table I have found it poorly structured with its merging of "tunnel" and "tunnel instance" attributes.

Cheers,
Brian
---
[email-masked]

-----Original Message-----
From: Zhu, Rupert [mailto:[email-masked]]
Sent: Monday, November 11, 2002 1:32 PM
To: [email-masked]
Subject: MPLS-TE-MIB Report 1/3: Ambiguities

Tom and MIB Authors:

-- Rupert

Rupert Zhu
System Engineering
Santera Systems Inc
3605 E. Plano Parkway
Plano, TX 75074
Phone: 972-461-6383