RE: Question on RowStatus

["Thomas D. Nadeau" <tnadeau@cisco.com>]

> -----Original Message-----
> From: Harrie Hazewinkel [mailto:harrie@lisanza.net] 
> Sent: Friday, May 16, 2003 10:08 AM
> To: Wijnen, Bert (Bert)
> Cc: Harrie Hazewinkel; Mreview (E-mail); Tom Nadeau (E-mail)
> Subject: Re: Question on RowStatus
> 
> 
> HI,
> 
> Not having looked at the MPLS-MIB yet, but some things I noticed.
> 
> On Friday, May 16, 2003, at 03:38 PM, Wijnen, Bert (Bert) wrote:
> 
> > In the MPLS LSR mib, I see:
> >
> > mplsInSegmentStorageType OBJECT-TYPE
> >    SYNTAX        StorageType
> >    MAX-ACCESS    read-only
> >    STATUS        current
> >    DESCRIPTION
> >        "This variable indicates the storage type for this
> >         object.
> 
> 'this object' I wonder if this is ment. I suggest
> fixing the wording into 'this entry' if it applies to the 
> complete entry. Object could be ambiguous.
> 
> >  If this object is set to readOnly(5), and the
> >         corresponding LFIB entry is removed, then the agent
> >         MUST remove this row shortly thereafter [RFC2579].
> >         The agent MUST ensure that this object's value
> >         remains consistent with the associated mplsXCEntry.
> >         The default value is volatile(2)."
> >    DEFVAL { volatile }
> >    ::= { mplsInSegmentEntry 11 }
> >
> > My questions:
> > - I think that it is OK that an agent can remove such readOnly rows
> >   when the underlying data ceases to exist. If anyone thinks that
> >   is not correct, pls holler.
> 
> I would agree.
> 
> > - The sentence about an agent needing to keep the object consistent
> >   with one or more stoargeTypes in other tables worries me.
> >   I guess it is OK. Maybe what I want them to do is to add text aka:
> >         If a SET request tries to set a vlue that is inconsistent
> >         with that associated mplsXCentry, then a inconcistentValue
> >         error should be returned.
> 
> I agree on the extra text, but since the mplsXEntry is 
> extending this one (I presume) 

	The XC entry does not extend the in-segment entry;
it joins it to possibly others as well as other
out-segment entries:

	in-segment(s) -> XC <- out-segment(s)

> it would be more logical the 
> other way around. The mplsXEntry needs to be consistent with 
> this one. Also I am not sure how both 'StorageTypes' would 
> relate, since it looks to me that both values should always 
> be equal. If so the question arises is the second StorageType needed.

	Consistency between the associated in-segment, out-segment
and XC entries is why we added this.  Bert recommended that
these all be kept together during the last review. He was
correct in that there are possible cases where one segment's
value is set to 'permanent' while the associated outsegment
or XC might be set to 'volatile'. The practical example
would be a static configuration of an incoming label, but
not of an outgoing one.  When the box reboots you could have
a problem.

	--Tom