Re: Use of atmV.lCrossConnectIdentifier for PVCs/SVCs

[Peter Jones <[e-mail]>]

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: [phone]             Main: [phone]
                                      Fax:  [phone]
mailto:[e-mail]        http://www.atmospherenet.com
_______________________________________________________________________