The MPLS WG Archive

[Soumen Sarkar <soumen@sasken.com>]

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