The MPLS WG Archive

["Thomas D. Nadeau" <tnadeau@cisco.com>]

         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

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