Subject: (ION) ipoaConfigPvcRowStatus

From: Paul Koning <[email-masked]>
Date: Wed, 4 Mar 1998 14:55:27 -0500

The behavior of row status for the ConfigPvc entries is somewhat
confusing because of the way the "not in service" value is used.

Normally (as I read RFC 1903) notInService is an administratively set
state, used to keep the entry from being used.  When the network
manager wants it to be used, he sets the row status object to "active"
and the value of row status then indeed becomes "active" (see matrix
of old and new values in RFC 1903).

In the case here, "not in service" has two quite different meanings:

1. The network manager has asked for "not in service" status by
setting row status to notInService or createAndWait.

2. The network manager wants the entry to be active but the InARP
protocol hasn't finished yet.

In the latter case, the InARP protocol is running and upon completion
the entry transitions to active state; in the former case InARP is
(presumably) NOT running and the state will remain as it is.

More confusingly, if the entry is in notInService (2) state, and the
network manager sets the row status to notInService, it (presumably)
transitions to notInService (1) state.

I was going to propose that notInService (2) be represented by
notReady instead, but RFC 1903 says that's not right either.  So while 
I don't see a good solution to this issue I'm not exactly thrilled
with it.

I'd appreciate other views and/or suggestions on how to avoid this
problem.

	paul

-- 
!-----------------------------------------------------------------------
! Paul Koning, NI1D, C-24183
! Xedia Corporation, 119 Russell Street, Littleton, MA 01460, USA
! phone: +1 978 952 6000 ext 115, fax: +1 978 952 6090
! email: [email-masked]
! Pgp:   27 81 A9 73 A6 0B B3 BE 18 A3 BF DD 1A 59 51 75
!-----------------------------------------------------------------------
! "The only purpose for which power can be rightfully exercised over 
!  any member of a civilized community, against his will, is to prevent
!  harm to others.  His own good, either physical or moral, is not
!  a sufficient warrant."    -- John Stuart Mill, "On Liberty" 1859
X-Info: To unsubscribe, email [email-masked]' with
X-Info: 'unsubscribe ion' in the body of the message.

---

From: Gary Hanson <[email-masked]>
Date: Wed, 4 Mar 1998 13:17:53 -0800 (PST)

Paul,

My take on this object was that protocol state on the VC would not
have any effect on the ipoaConfigPvcRowStatus value.  This RowStatus
value would remain just as the manager last left it, either as
'active', 'notInService', or destroyed.  The RowStatus of 'notReady'
would not apply here, since all other read-create objects in the same
row have a DEFVAL.

The existence of the ipNetToMediaEntry and ipoaVcEntry would, however,
depend upon the protocol state of the VC.  Are you sure you were not
reading ipoaConfigPvcRowStatus for ipoaVcEntry/ipoaVcTable in the
DESCRIPTION of ipoaConfigPvcRowStatus?

Otherwise, I am not sure I see the problem you are referring to.

Regards,
Gary

 ______
| ///  |       TM   Gary Hanson                [email-masked]
|   ADC|Kentrox     14375 NW Science Park Dr.  503-641-3321 (FAX)
|______|            Portland, Oregon  97229    800-733-5511 x6333

---

From: Paul Koning <[email-masked]>
Date: Wed, 4 Mar 1998 16:38:02 -0500

>>>>> "Gary" == Gary Hanson <[email-masked]> writes:

 Gary> Paul,

 Gary> My take on this object was that protocol state on the VC would
 Gary> not have any effect on the ipoaConfigPvcRowStatus value.  This
 Gary> RowStatus value would remain just as the manager last left it,
 Gary> either as 'active', 'notInService', or destroyed.  The
 Gary> RowStatus of 'notReady' would not apply here, since all other
 Gary> read-create objects in the same row have a DEFVAL.

 Gary> The existence of the ipNetToMediaEntry and ipoaVcEntry would,
 Gary> however, depend upon the protocol state of the VC.  Are you
 Gary> sure you were not reading ipoaConfigPvcRowStatus for
 Gary> ipoaVcEntry/ipoaVcTable in the DESCRIPTION of
 Gary> ipoaConfigPvcRowStatus?

Positive.  I quote from draft-ietf-ion-mib-07.txt:

  The object ipoaConfigPvcRowStatus doesn't get a value of active(1)
  until the InATMARP reply is received.  If the row was complete it
  would have a value of notInService(2) as defined by RFC 1903 as
  opposed to notReady(3). ...

Note that the ipoaVcEntry doesn't have a row status at all.  If the
InARP hasn't finished yet, the ipoaVcEntry doesn't exist.

	paul

---

From: Gary Hanson <[email-masked]>
Date: Wed, 4 Mar 1998 14:04:14 -0800 (PST)

Paul,

You're right.  (I keep forgetting that MIBs have introductory text as
well, some of which can be inconsistent with the MIB's semantics.)

I think the 2nd paragraph of section 3.1.5 does describe a bogus misuse
of RowStatus, in terms of ipoaConfigPvcRowStatus's values, its ability
to be used "to determine if the PVC is available for use or not.", and
the requirement that it "SHOULD be set to notInService(2) and the
correspondign ARP Cache entry deleted whehever a PVC becomes unusable."

I would recommend that implementors ignore the 2nd paragraph of section
3.1.5, and instead assume normal RFC 1903 semantics.

Presence/absence of an entry in the ipoaVcTable could be used to
determine if the PVC is available for use or not.  However, since the
VPI and VCI values follow the IP address value in the INDEX, it is not
easy to simply "check" for this entry.  Perhaps the only solution to
the problem (for next time) would be to add a read-only object to the
existing ipoaConfigPvcTable that provides the IP address of the remote
host.  If the value is 0 (i.e., IP address 0.0.0.0) that would indicate
that the PVC is unusable (i.e., that InATMARP has not resolved the IP
address of the PVC).  Alternatively, a pair of objects could be added,
one for the remote IP address, and one for the PVC's protocol status.

In the meantime, assuming the offending paragraph is to be ignored,
the only thing to do is walk either ipoaVcNegotiatedEncapsType.ifIndex
or ipoaVcNegotiatedMtu.ifIndex looking for the VPI and VCI as the 3rd
and 4th instance components.  If found, the IP address would of course
be the 2nd instance component.  Messy and time-consuming, but doable.

Regards,
Gary

---

From: Keith McCloghrie <[email-masked]>
Date: Wed, 4 Mar 1998 14:24:18 -0800 (PST)

Paul,

I agree that this is a problem, and a misuse/overloading of the
semantics of RowStatus.  Other examples of problems are: 1903 says
that rows get aged out of the notInService state, which I doubt is
what is intended here; there is confusion about whether the NMS or
agent is setting certain states, e.g., does this sentence:

  The value of an ipoaConfigPvcRowStatus object SHOULD be set to
  notInService(2) and the corresponding ARP Cache entry deleted
  whenever a PVC becomes unusable.

refer to the NMS setting the value or to the agent setting the value?

It seems to me that these problems could be solved by having additional
columnar object(s) in the ipoaConfigPvcTable, probably an "OperStatus"
and an "AdminStatus".

Keith.