The MPLS WG Archive

Cell Relay Retreat>MPLS WG Archive>month:2001-Jan> msg00262



[Date Prev][Date Next][Thread Prev][Thread Next]  
  [Date Index][Thread Index][Author Index][Subject Index]

MPLS-TE-MIB additions (last call)

  • From: "Manohar Ellanti" <ellanti@home.com>
  • Date: Wed, 24 Jan 2001 19:07:26 -0800
  • Organization: @home

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" <tnadeau@cisco.com>
To: "cheenu Srinivasan" <csrinivasan@tachion.com>; "Arun Viswanathan"
<arun@force10networks.com>; <mpls@UU.NET>
Sent: Tuesday, January 23, 2001 10:10 AM
Subject: MPLS-TE-MIB additions (last call)


>
> 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
>