Subject: MPLS-TE-MIB additions (last call)

From: "Thomas D. Nadeau" <[email-masked]>
Date: Tue, 23 Jan 2001 13:10:38 -0500

Hi,

	In addition to the 4 agreed upon changes from Joan
and Shobhan, the co-authors of the MPLS-TE-MIB have three
objects that we would like added/modified in the existing
MPLS-TE-MIB and thought that we would post them to
the mailing list prior to adding them. I understand
that last call was finished last Friday, but I
was too busy to send these out, so I apologize.

	HopTable:

	Add an object called mplsTunnelHopExcludeAddr whose
purpose it is to denote whether or not this hop specifies
an 'included' or 'excluded' hop. The default is 'include',
so the DEFVAL is false(2).

mplsTunnelHopIncludeExclude  OBJECT-TYPE
    SYNTAX        TruthValue
    MAX-ACCESS    read-create
    STATUS        current
    DESCRIPTION
           "If this value is set to true(1), then this indicates that this 
hop MUST be included in the tunnel's path. If this value is set to 
false(2), then this hop MUST be avoided when calculating the path for this 
tunnel. The default value of this object is true(1), so that by default all 
indicated hops are included in the CSPF path computation."
    ::= { mplsTunnelHopEntry xxx }

mplsTunnelPathOptionName  OBJECT-TYPE
    SYNTAX        DisplayString
    MAX-ACCESS    read-create
    STATUS        current
    DESCRIPTION
           "The description of this series of hops as they relate to the 
specified path option."
    ::= { mplsTunnelHopEntry xxx }

	I think that we incorrectly put this bit in the
mplsTunnelSessionAttributes:

           isComputed This flag indicates whether the tunnel
            path is computed using a constraint-based routing
            algorithm based on the mplsTunnelHopTable entries.

	This bit should go on the HopEntry, and should be removed
from the mplsTunnelSessionAttributes. If you leave the bit
where it is, it means that *every* path in the hop table
for a particular tunnel is either explicitly specified
or dynamically computed. This is incorrect as you
may want a mixture of the two.

	I suggest that we add an object to the tunnelHopEntry
called tunnelHopEntryPathComputation and make it an enumeration
like:

	INTEGER { dynamic(1),     -- CSPF computed
                  explicit(2) }   -- strict hop

        DESCRIPTION "If this value is set to dynamic, then the
			user should only specify the source and
			destination of the path and expect that
			the CSPF will calculate the remainder of
			the path. If this value is set to explicit,
			the user should specify the entire path
			for the tunnel to take. This path may contain
			strict or loose hops."

	--Tom

---

From: Soumen Sarkar <[email-masked]>
Date: Wed, 24 Jan 2001 10:51:03 +0530 (IST)

>     ::= { mplsTunnelHopEntry xxx }
 Tom, I think the name mplsTunnelHopIncludeExclude is creating
 confusion since its type is TruthValue. Since the default value
 would be true(1), I suggest the name to be : mplsTunnelHopInclude
 It will be aligned with its semantic.
-regards,
Soumen

---

From: Jim Boyle <[email-masked]>
Date: Tue, 23 Jan 2001 22:54:00 -0700 (MST)

> and Shobhan, the co-authors of the MPLS-TE-MIB have three

I counted 3 folks that agreed and 0 that objected, not a preponderance of
support, but I suppose it'll do.

I'll just note publically that I feel that inclusion of CR-LDP
specific attributes such as the "ancillary" bw characteristics are out
of place in your generic mib.  Making them "mandatory" (but only when
certain combinations of configuration and protocol use are present!)
is also objectionable.

3 to 1, hmm.. I suppose you'll keep it in there.  

All the same, I suppose.

Jim

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Wed, 24 Jan 2001 08:48:25 -0500

>  It will be aligned with its semantic.

         Actually we rethought this after I sent out the email for
that very same reason. It is now defined as follows:

         mplsTunnelHopIncludeExclude  OBJECT-TYPE
         SYNTAX                  INTEGER { include(1), exclude(2) }

         Does that seem more appropriate to you?

         --Tom

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Wed, 24 Jan 2001 09:30:45 -0500

>support, but I suppose it'll do.

         Jim,

         I think that the consensus was 6 in favor and no
objections to add these objects. That seems to be a consensus
to add these objects to the MIB. What is unclear is whether
or not we should make these objects optional if the
mplsTunnelSignallingProto variable is not set to
crldp(3) (or the agent does not support CR-LDP altogether)
for a particular tunnel entry. Let me outline the two options
for this and the associated pros and cons.

         1:      Add the objects as optional iff CR-LDP is not implemented.

                 The advantage here is that if the implementation
                 does not support CR-LDP, it can save itself some memory
                 and effort. The advantage to the operator is that
                 when it scans the table, the agent will
                 simply not return these objects. The operator can also find
                 this out through an agent capabilities statement.
                 The disadvantage as Jim points out, is that it makes
                 these 4 objects optional on a signaling protocol basis, so
                 some rows in the table may support these 4 columns, and others
                 may not.

         2:      Add the options, but make them mandatory for all 
implementations.

                 This is certainly possible, but when an implementation does
                 not support CR-LDP, the agent MUST ignore these values
                 during SET operations, and MUST return 0 for the values
                 at all times. One of the variables can under normal 
circumstances,
                 contain the value of 0, which can be confusing unless we state
                 that clearly in the fine print. In my opinion, this is more
                 confusing for the operator, since there are now variables 
which
                 return values when queried, yet are meaningless if CR-LDP is
                 not implemented. The operator may not know this until 
after they
                 have read over the documentation (or the agent capabilities
                 statement), whereas in the first case, they will simply not
                 be returned upon a query.

         My personal opinion is to use option 1, but I will leave it up
to the list to decide this one.

         --Tom

---

From: "Manohar Ellanti" <[email-masked]>
Date: Wed, 24 Jan 2001 19:07:26 -0800

Tom,

How does this relate to the Traffic Engineering architecture document where
a distinction is made between include/exclude and
explicitInclude/explicitExclude.

An explicitInclude hop list can be used to prune the graph and then run
CSPF.I think explicitExclude probably should be possible to specify using
the table you described. But I think it is not the case explicitInclude.

I think we should have -
    option of suggested include
    option of explicit include (sub graph formed with include hops)
    option to exclude some hops

-Manohar

----- Original Message -----
From: "Thomas D. Nadeau" <[email-masked]>
To: "cheenu Srinivasan" <[email-masked]>; "Arun Viswanathan"
<[email-masked]>; <[email-masked]>
Sent: Tuesday, January 23, 2001 10:10 AM
Subject: MPLS-TE-MIB additions (last call)

---

From: Soumen Sarkar <[email-masked]>
Date: Wed, 24 Jan 2001 20:41:54 +0530 (IST)

Tom, I do agree with you that 1st option is more advisable
than the 2nd one and if no more idea comes off from the
list, I guess 1st option will have more takers. Just for the
sake of it, would you think creating a separate table (only
for these four objects ) could be an option ? The advantage
is, when CR-LDP is not supported whole table will vanish and
the operator will readily understand this on first attept.
  This also would avoid the problem you mentioned in your
first option.
-regards,
Soumen

---

From: Jim Boyle <[email-masked]>
Date: Wed, 24 Jan 2001 08:33:34 -0700 (MST)

That sounds good to me.

---

From: Shobhan Lakkapragada <[email-masked]>
Date: Wed, 24 Jan 2001 11:50:24 -0500

Tom,

I agree that Option 1 below is a good way of adding them.

But I feel it is more appropriate to keep the new objects in the
same table. Reason being that CR-LDP implementations would
use the already existing objects  Max Rate, Mean Rate and
Max Burst Rate for configuring CR-LDP parameters Peak Date rate,
Committed rate and Peak Burst size.

If the new objects are in separate table, then the required
CR-LDP TE parameters will be spread across two different
tables. I guess there is nothing wrong with it, but it just looks
cleaner if they are all in same table.

- shobhan

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Wed, 24 Jan 2001 14:36:37 -0500

Is anyone actually implementing the "suggested"
types you note below?  The MIB currently supports
all of the cases you outlined below except the
"suggested" ones.

         --Tom

---

From: Soumen Sarkar <[email-masked]>
Date: Thu, 25 Jan 2001 09:51:17 +0530 (IST)

On Wed, 24 Jan 2001, Shobhan Lakkapragada wrote:

> Subject: Re: MPLS-TE-MIB additions (last call)
>
>
> Tom,
>
  Tom and Shobhan,
	We have quite a lot of instances where a second table
	is introduced as an extension of first table. As a matter
	of fact this only makes the organisation neater.
 -regards,
 Soumen