The MPLS WG Archive

[Jim Boyle <jboyle@Level3.net>]

That sounds good to me.

On Wed, 24 Jan 2001, Soumen Sarkar wrote:

> 
> 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
> 
> 
> On Wed, 24 Jan 2001, Thomas D. Nadeau wrote:
> 
> >
> >
> >          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
> >
> >
>