The MPLS WG Archive

[Soumen Sarkar <soumen@sasken.com>]

On Wed, 24 Jan 2001, Shobhan Lakkapragada wrote:

> Subject: Re: MPLS-TE-MIB additions (last call)
>
>
> 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
>
  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


>
>
> "Thomas D. Nadeau" wrote:
>
> > > >       In addition to the 4 agreed upon changes from Joan
> > > > 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.
> >
> >          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
>