Re: Use of atmV.lCrossConnectIdentifier for PVCs/SVCs

Peter Jones <peter@atmospherenet.com> Thu, 26 March 1998 04:37 UTC

Delivery-Date: Wed, 25 Mar 1998 23:37:21 -0500
Return-Path: aileen@thumper.bellcore.com
Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id XAA20786 for <ietf-archive@ietf.org>; Wed, 25 Mar 1998 23:37:20 -0500 (EST)
Received: from thumper.bellcore.com (thumper.bellcore.com [128.96.41.1]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id XAA14190 for <ietf-archive@cnri.reston.va.us>; Wed, 25 Mar 1998 23:39:51 -0500 (EST)
Received: from aus.atmospherenet.com (gus.aus.atmospherenet.com [203.38.28.9]) by thumper.bellcore.com (8.8.8/8.8.8) with SMTP id VAA07722 for <atommib@thumper.bellcore.com>; Wed, 25 Mar 1998 21:51:31 -0500 (EST)
Received: from atmospherenet.com by aus.atmospherenet.com (SMI-8.6/SMI-SVR4) id KAA02423; Thu, 26 Mar 1998 10:50:49 +0800
Sender: peter@atmospherenet.com
Message-ID: <3519C286.63A210@atmospherenet.com>
Date: Thu, 26 Mar 1998 10:50:46 +0800
From: Peter Jones <peter@atmospherenet.com>
Reply-To: peter@aus.atmospherenet.com
Organization: Atmosphere Networks
X-Mailer: Mozilla 4.04 [en] (X11; I; SunOS 5.5.1 sun4u)
MIME-Version: 1.0
To: Gary Hanson <gary@kentrox.com>
CC: Mickey Spiegel <mspiegel@cisco.com>, Kaj Tesink <kaj@cc.bellcore.com>, atommib@thumper.bellcore.com, John Neil <jn@aus.atmospherenet.com>
Subject: Re: Use of atmV.lCrossConnectIdentifier for PVCs/SVCs
References: <Pine.SUN.3.96.980320145743.18024N-100000@skeeter>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hi Gary,

Gary Hanson wrote:
> 
> Mickey, Kaj, (and other atommib-ers),
> 
> I have been trying to dig through the atommib WG archives to find
> the final consensus on how the atmVplCrossConnectIdentifier and
> the atmVclCrossConnectIdentifier objects should be used to refer to
> the various PVC- and SVC-related cross-connect tables.  Since the
> current internet-drafts are essentially silent on this point, I
> thought I would throw the question open to other implementors on
> the mailing list to see what they had done (or intended to do).
> 
> To refresh people memories, the following table entries are all
> defined to be partially indexed by a cross-connect index in the
> range 0..2147483647):
> - From ATM-MIB:
>   - atmVpCrossConnectEntry    (1st INDEX: atmVpCrossConnectIndex)
>   - atmVcCrossConnectEntry    (1st INDEX: atmVcCrossConnectIndex)
> - From ATM2-MIB:
>   - atmSvcVpCrossConnectEntry (1st INDEX: atmSvcVpCrossConnectIndex)
>   - atmSvcVcCrossConnectEntry (1st INDEX: atmSvcVcCrossConnectIndex)
> 
> The cross-connect index values used as INDEXes into these tables
> are all apparently derived from the following objects from ATM-MIB:
>   - atmVplCrossConnectIdentifier (from atmVplEntry)
>   - atmVclCrossConnectIdentifier (from atmVclEntry)
> 
> As far as I can tell, neither the ATM-MIB draft nor the ATM2-MIB
> draft clarify how the atmV.lCrossConnectIdentifier objects from
> the atmV.lEntry rows are to be used to identify the ATM2-MIB's
> atmSvcV.CrossConnectEntry rows.  In fact, the ATM-MIB draft simply
> says that these objects only identify the atmV.CrossConnectEntry
> rows in the ATM-MIB.
> 
> Was it the intention of the WG that a particular cross-connect
> identifier value be used to identify a row in one table or the
> other, but NEVER both?  For example, if an atmVpCrossConnectEntry
> exists with atmVpCrossConnectIndex X, should the agent take pains
> to ensure that no atmSvcVpCrossConnectEntry also exists with
> atmSvcVpCrossConnectIndex X, and vice versa?  This would make
> sense to me, but as the documents do not explicitly say this, I
> was left somewhat unsure.
> 
> I assume that the WG has abandoned the idea of splitting the
> cross-connect identifier values into two disjoint ranges, since
> there had been a lot of negative discussion about that, and since
> the tables do in fact now share the same indexing range.  So am I
> correct in assuming that the tables share the same range of index
> values, but NEVER share entries indexed by the same cross-connect
> index value?
> 
> If so, what does the WG think about adding explicit documentation
> to this effect in both documents.  The ATM-MIB document deserves
> to have this mentioned, since that is where the cross-connect
> identifier is defined, and the ATM2-MIB document also deserves to
> have this mentioned, since there is otherwise no explicit mention
> of where the values for atmSvcV.CrossConnectIndex come from.  I
> am sure other implementors will come along with the same confusion
> as myself.
> 
> Regards,
> Gary

>From our point of view, both the SVC's and the PVC's share a 
common pool for cross connect indexes.

This is particularly critical which you consider the case of a soft PVC
at the edge switch. In this case (according to our interpretation)  
one link of the connecton is a PVC link which is then cross connected 
to an SVC link.

I guess this does beg the question as to why we need two lots of cross 
connect tables?

regards
peter

-- 
______________________________________________________________________
Peter Jones                           Atmosphere Networks
Manager of Software Development       4th Floor, Balcroft Building
                                      Garden Office Park
                                      345 Harborne Street
                                      Osborne Park WA 6017, Australia
Direct: +61 (8) 9443 0105             Main: +61 (8) 9443 0100
                                      Fax:  +61 (8) 9443 6610
mailto:peter@atmospherenet.com        http://www.atmospherenet.com
_______________________________________________________________________