The IP Over NBMA (ION) Archive

[Gary Hanson <gary@kentrox.com>]

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


On Wed, 4 Mar 1998, Paul Koning wrote:

> >>>>> "Gary" == Gary Hanson <gary@kentrox.com> 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
> 

X-Info: To unsubscribe, email 'majordomo@sunroof.eng.sun.com' with
X-Info: 'unsubscribe ion' in the body of the message.