The MPLS WG Archive

Cell Relay Retreat>MPLS WG Archive>month:2001-Jan> msg00261



[Date Prev][Date Next][Thread Prev][Thread Next]  
  [Date Index][Thread Index][Author Index][Subject Index]

MPLS-TE-MIB additions (last call)

  • From: "Thomas D. Nadeau" <tnadeau@cisco.com>
  • Date: Wed, 24 Jan 2001 09:30:45 -0500
  • Cc: cheenu Srinivasan <csrinivasan@tachion.com>, Arun Viswanathan <arun@force10networks.com>, "Cucchiara, Joan" <JCucchiara@Brixnet.com>, "'slakkapr@nortelnetworks.com'" <slakkapr@nortelnetworks.com>, mpls@UU.NET


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