The MPLS WG Archive

[Shobhan Lakkapragada <slakkapr@nortelnetworks.com>]

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



"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