Subject: RE: (FRNETMIB) FR/ATM Interworking MIB Comments

From: "Rehbehn, Kenneth" <[email-masked]>
Date: Tue, 23 May 2000 16:41:54 -0400

I have been on the road and am only now getting to digesting your
suggestions.  I will update the MIB as reflected by my comments below and as
a result of any further discussion on the mail list.

Ken

> -----Original Message-----
> From: Rob Steinberger [mailto:[email-masked]]
> Sent: Thursday, April 27, 2000 11:46 AM
> To: [email-masked]
> Subject: (FRNETMIB) FR/ATM Interworking MIB Comments
> 
> 
> Developers here pointed out that frAtmIwfConnectionTable indexing is
> confusing.  There are 6 indices to the table, but based on the
> description only one appears to be needed.  The wording for
> frAtmIwfConnIndex is:
> 
>      "A unique index to identify this interworking connection"
> 

I will expand the description so it is more reality based.  As you noted,
the current text is really inadequate.

> I realize that it is there to provide the point-to-multipoint
> connectivity, but you need to read section 3.4 to get that information
> out.  Our developers were viewing each row in the table as an
> individual connection in that they display a single cross-connect.
> This problem may be alleviated with a modification to the
> DESCRIPTION clause.  We need to tell the user that this connection
> index is a group of associated cross connections.  We may also have to
> define better what makes a valid group.
>

This information will go in the description.

> However, there is nothing in either the indexing scheme or the text to
> enforce that a "connection" is either point-to-point or
> point-to-multipoint.  In fact, the connection index can simply be an
> index of a group of simple connections.  All that is stated is that
> the MUST use the same connection description.  It appears to be legal
> with this scheme to have every connection in the device use the exact
> same connection index as long as there is only one connection
> description used.  This is not useful.

The 2nd paragraph of the DESCRIPTION for frAtmIwfConnectionEntry does
enforce that a connection is either p-p or p-mp.

Connection descriptors are not unique to a single connection.  Connection
description has a one to many relationship with different connections. For
example, all connections supporting bridging using descriptor 546.  Some
connections may be p-mp and others p-p.

> 
> I view frAtmIwfConnIndex as a group of connections with the same
> connection descriptor as well as a quicker search mechanism for
> relation of DLCIs and VCLs.  We don't want to replace the connection
> index with the connection descriptor because an alternative purpose
> for the connection index is to speed up the relational search from the
> DLCI or VCL to the connection.   This may be solved by making the
> connection descriptor the second index of the table.  Alternatively,
> text can be added to the DESCRIPTION clauses of
> frAtmIwfConnectionDescriptor and frAtmIwfConnRowStatus to state the
> limitations.
> 

frAtmIwfConnIndex is unique for each p-p or p-mp connection.  It could not
be replaced by the connection descriptor because the connection descriptor
is shared by multiple p-p/p-mp connections.

The connection descriptor has no place as an index into the table.  It is
merely a pointer to more information about the connection - information that
is shared by other connections.  The table organization is not driven by
association with a particular type of connection and thus does not benefit
from being indexed by the connection descriptor.

I see no limitations that need to be explained in DESCRIPTION clauses of
frAtmIwfConnectionDescriptor and frAtmIwfConnRowStatus.  Is there something
I am missing?

> Further,  the DESCRIPTION clause of frAtmIwfConnRowStatus is too
> limiting.  There is no need to be operational to configure a cross
> connection.  This limitation prevents the user from configuring the
> cross connection prior to making the network operational and is not
> usable in the field.  Also, there is no need to check the admin status
> on deleting a cross  connection in that deleting it should have no
> effect on the administrative status of the links.
> 

I read the DESCRIPTION clause of frAtmIwfConnRowStatus differently.
Activation requires the existance of a connection descriptor and up(1)
status for each endpoint.  No restriction exists that prevents configuration
of the cross connection when the endpoints are not active.  

That having been said, I notice that the instructions in Section 3.5.1, Step
7 are at odds with the DESCRIPTION clause of frAtmIwfConnRowStatus.  The
current text of the object demands that both segments be up(1) prior to
activation.  Section 3.5.1 permits the agent to trigger the activation of
the segments as a side-effect of processing the SET of up(1).  Likewise, as
you observed with the delete restriction, the inverse is permitted.

I will update the DESCRIPTION clause to match Section 3.5.1 and remove the
limitations.

> I think that all of the problems can be fixed by changes to only
> DESCRIPTION clauses.
>

I agree

> Rob Steinberger
> Paradyne Networks
> 
> X-Info: To unsubscribe, email [email-masked]' with
> X-Info: 'unsubscribe frnetmib' in the body of the message.
> 
X-Info: To unsubscribe, email [email-masked]' with
X-Info: 'unsubscribe frnetmib' in the body of the message.