The MPLS WG Archive

["Cucchiara, Joan" <JCucchiara@Brixnet.com>]

Option 1 sounds good to me also.  
A separate table is probably also beneficially
as Soumen points out.

 -Joan

> -----Original Message-----
> From: Jim Boyle [mailto:jboyle@Level3.net]
> Sent: Wednesday, January 24, 2001 10:34 AM
> To: Soumen Sarkar
> Cc: Thomas D. Nadeau; cheenu Srinivasan; Arun Viswanathan; Cucchiara,
> Joan; 'slakkapr@nortelnetworks.com'; mpls@UU.NET
> Subject: Re: MPLS-TE-MIB additions (last call)
> 
> 
> 
> 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
> > >
> > >
> > 
>