Subject: Again: Fwd: Cross-connect indexing (was Re: A few more atm1ng-03 nitpicks)

From: Kaj Tesink <[email-masked]>
Date: Mon, 27 Apr 1998 22:39:43 -0400

Gary, Mickey,

Here also some minor things. Rationale
similar as in my previous message.

Kaj

>X-Station-Sent-From: joker.bellcore.com
>Date: Thu, 16 Apr 1998 20:37:22 -0700 (PDT)
>From: Gary Hanson <[email-masked]>
>X-Sender: gary@skeeter
>Reply-To: Gary Hanson <[email-masked]>
>To: Kaj Tesink <[email-masked]>
>Cc: [email-masked]
>Subject: Cross-connect indexing (was Re: A few more atm1ng-03 nitpicks)
>
>
>Kaj,
>
>Here is my understanding of how the various cross-connect tables
>are intended to be used (please correct me if I am wrong):
>- For a PVC, the cross-connect between two VPLs is represented
>  in the atmVpCrossConnectTable of the ATM-MIB, indexed by the
>  atmVplCrossConnectIdentifier values for the two VPLs, and
>  the cross-connect between two VCLs is represented in the
>  atmVcCrossConnectTable of the ATM-MIB, indexed by the
>  atmVclCrossConnectIdentifier values for the two VCLs.
>- For an SVC or Soft PVC, the cross-connect between two VPLs is
>  represented in the atmSvcVpCrossConnectTable of the ATM2-MIB,
>  indexed by the atmVplCrossConnectIdentifier values for the two
>  VPLs, and the cross-connect between two VCLs is represented in
>  the atmSvcVcCrossConnectTable of the ATM2-MIB, indexed by the
>  atmVclCrossConnectIdentifier values for the two VCLs.
>
>I think these two bullets would be useful if added as two more
>paragraphs at the end of section 6.5, which discusses the ATM
>Virtual Link and Cross-Connect Groups.

I have done some creative word smithing to avoid the necessity of
the precise reference of ATM2 here. Point is that ATM2 may end up
being published at a somewhat different time than this MIB;
just want to avoid being caught by process at this time.

>
>Here are some object DESCRIPTION modifications that I think would
>adequately clarify the use of the above rules for cross-connects
>within the MIBs themselves:
>
>- For AtmConnKind in ATM-TC-MIB, change:
>                          "The use of call control. The use is as
>                          follows:
>                             pvc(1)
>                                Virtual link of a PVC. Should not be
>                                used in an PVC/SVC (i.e., SPVC)
>                                crossconnect.
>                             svcIncoming(2)
>                                Virtual link established after a
>                                received signaling request to setup
>                                an SVC.
>                             svcOutgoing(3)
>                                Virtual link established after a
>                                transmitted or forwarded signaling
>                                request to setup an SVC.
>                             spvcInitiator(4)
>                                Virtual link at the PVC side of an
>                                SVC/PVC crossconnect, where the
>                                switch is the initiator of the SPVC
>                                setup.
>                             spvcTarget(5)
>                                Virtual link at the PVC side of an
>                                SVC/PVC crossconnect, where the
>                                switch is the target of the SPVC
>                                setup.
>
>                          An spvcInitiator is always cross-connected to
>                          an svcOutgoing, and an spvcTarget is always
>                          cross-connected to an svcIncoming."

>  to:
>                          "The use of call control.  The use is as
>                          follows:
>                             pvc(1)
>                                Virtual link of a PVC.  Should not be
>                                used in a PVC/SVC (i.e., Soft PVC)
>                                cross-connect.
>                             svcIncoming(2)
>                                Virtual link established after a
>                                received signaling request to setup
>                                an SVC.
>                             svcOutgoing(3)
>                                Virtual link established after a
>                                transmitted or forwarded signaling
>                                request to setup an SVC.
>                             spvcInitiator(4)
>                                Virtual link at the PVC side of an
>                                SVC/PVC cross-connect, where the
>                                switch is the initiator of the Soft
>                                PVC setup.
>                             spvcTarget(5)
>                                Virtual link at the PVC side of an
>                                SVC/PVC cross-connect, where the
>                                switch is the target of the Soft PVC
>                                setup.
>
>                          For PVCs, a pvc is always cross-connected
>                          to a pvc, and the cross-connect is always
>                          represented in the atmVpCrossConnectTable
>                          or the atmVcCrossConnectTable of the
>                          ATM-MIB, depending upon whether the links
>                          are VPLs or VCLs, respectively.
>
>                          For SVCs, an svcIncoming is always
>                          cross-connected to an svcOutgoing, and
>                          the cross-connect is always represented in
>                          the atmSvcVpCrossConnectTable or the
>                          atmSvcVcCrossConnectTable of the ATM2-MIB,
>                          depending upon whether the links are VPLs
>                          or VCLs, respectively.
>
>                          For Soft PVCs, an spvcInitiator is always
>                          cross-connected to an svcOutgoing, and an
>                          spvcTarget is always cross-connected to an
>                          svcIncoming.  In either of these cases,
>                          the cross-connect is always represented in
>                          the atmSvcVpCrossConnectTable or the
>                          atmSvcVcCrossConnectTable of the ATM2-MIB,
>                          depending upon whether the links are VPLs
>                          or VCLs, respectively."
>
>  (Note also the change of "SPVC" to "Soft PVC", to follow the
>  terminology used in the various ATM Forum specifications, as well
>  as to help avoid too many acronyms floating around all with the
>  letters "S", "P", "V", and "C" in various combinations.  It would
>  be nice if this were changed in the ATM2-MIB as well....)

>
>- For atmVplConnKind in ATM-MIB, change:
>                     "The use of call control."
>  to:
>                     "The use of call control.  The value of pvc
>                      indicates that any cross-connect involving this
>                      VPL and other VPLs will be represented in the
>                      atmVpCrossConnectTable of this MIB, indexed by
>                      the value of atmVplCrossConnectIdentifier.  For
>                      other atmVplConnKind values, any cross-connect
>                      involving this VPL and other VPLs will be
>                      represented in the atmSvcVpCrossConnectTable of
>                      the ATM2-MIB, again indexed by the value of
>                      atmVplCrossConnectIdentifier.  Note that
>                      entries in the atmVpCrossConnectTable are
>                      created by management action, whereas entries
>                      in the atmSvcVpCrossConnectTable (as well as
>                      the svcIncoming and svcOutgoing VPL entries
>                      themselves) are created as a side-effect of
>                      ATM signalling protocols.  At no time should
>                      a given atmVplCrossConnectIdentifier value
>                      index entries in both of these cross-connect
>                      tables."

I would like to do this differently:
Instead of addressing this issue in the atmConnKind object
it may be better to nail this down in the xconnect tables themselves.
To some extent this is already done through comment statements and
the compliance statements. I suggest the following to fix it further:

atmVpCrossConnectTable OBJECT-TYPE
     SYNTAX         SEQUENCE OF AtmVpCrossConnectEntry
     MAX-ACCESS     not-accessible
     STATUS         current
     DESCRIPTION
      "The ATM VP Cross Connect table for PVCs.  
       A bi-directional VP cross-connect is modeled
       as one entry in this table: 
       - it cross-connects two VPLs
       - each VPL has its atmConnKind set to pvc(1)"
     ::= { atmMIBObjects 9 }

[same for VCxconnect]

i did this already in atm1; if you both agree then mickey
should have corresponding updates in atm2.

and

atmVclTable         OBJECT-TYPE
     SYNTAX         SEQUENCE OF AtmVclEntry
     MAX-ACCESS     not-accessible
     STATUS         current
     DESCRIPTION
      "The Virtual Channel Link (VCL) table.  A 
       bi-directional VCL is modeled as one entry
       in this table. This table can be used for
       PVCs, SVCs and Soft PVCs."
     ::= { atmMIBObjects 7}

[same for VPxconnect]

btw my personal preference is to solve these kind of
applicability statements through the compliance clauses
but since these objects are scattered over two mibs it
may be better to have these clarifications.

>
>- For atmVclConnKind in ATM-MIB, change:
>                     "The use of call control."
>  to:
>                     "The use of call control.  The value of pvc
>                      indicates that any cross-connect involving this
>                      VCL and other VCLs will be represented in the
>                      atmVcCrossConnectTable of this MIB, indexed by
>                      the value of atmVclCrossConnectIdentifier.  For
>                      other atmVclConnKind values, any cross-connect
>                      involving this VCL and other VCLs will be
>                      represented in the atmSvcVcCrossConnectTable of
>                      the ATM2-MIB, again indexed by the value of
>                      atmVclCrossConnectIdentifier.  Note that
>                      entries in the atmVcCrossConnectTable are
>                      created by management action, whereas entries
>                      in the atmSvcVcCrossConnectTable (as well as
>                      the svcIncoming and svcOutgoing VCL entries
>                      themselves) are created as a side-effect of
>                      ATM signalling protocols.  At no time should
>                      a given atmVclCrossConnectIdentifier value
>                      index entries in both of these cross-connect
>                      tables."

arent we introducing some redundancy?
- we have already patched the TC to say what atmConnKinds mean and
  how they can xconnect
- each xconnect table type (and conformance clause) says which
  virtual circuit type is supported
- following this logic most text above is redundant with the exception
  of the last 2 sentences:
  * the sentence 'Note that entries...' - i like the part for SVCs;
    this should appear in the atmSvcXConnectTables somewhere; i like
    the part for PVCs too but it may be redundant since no other action
    is possible. 
  * the last sentence may be stronger in the definition of the
    atmVclCrossConnectIdentifier; see below
  ps - i'm not trying to have minimal text when i say 'redundant';
  explanations are a good thing. at the same time recurring statements
  have a tendency to cause problems over time, hence my caution

>
>- For atmVplCrossConnectIdentifier in ATM-MIB, change:
>                     "This object is implemented only for a VPL
>                      which is cross-connected to other VPLs
>                      that belong to the same VPC.  All such
>                      associated VPLs have the same value of this
>                      object, and all their cross-connections are
>                      identified by entries in the

>                      atmVpCrossConnectTable for which
>                      atmVpCrossConnectIndex has the same value.
>                      The value of this object is initialized by the
>                      agent after the associated entries in the
>                      atmVpCrossConnectTable have been created."
>  to:
>                     "This object is implemented only for a VPL
>                      which is cross-connected to other VPLs
>                      that belong to the same VPC.  All such
>                      associated VPLs have the same value of this
>                      object, and all their cross-connections are
>                      identified either by entries that are indexed
>                      by the same value of atmVpCrossConnectIndex in
>                      the atmVpCrossConnectTable of this MIB or by
>                      the same value of atmSvcVpCrossConnectIndex in
>                      the atmSvcVpCrossConnectTable of the ATM2-MIB.
>                      Which of these cross-connect tables is used
>                      depends on the atmVplConnKind values of the
>                      cross-connected VPLs.
>
>                      The value of this object is initialized by the
>                      agent after the associated entries in the
>                      appropriate cross-connect table have been
>                      created."

as per logic above my suggestion then is rewording as follows:

                     "This object is instanciated only for a VPL
                      which is cross-connected to other VPLs
                      that belong to the same VPC.  All such
                      associated VPLs have the same value of this
                      object, and all their cross-connections are
                      identified either by entries that are indexed
                      by the same value of atmVpCrossConnectIndex in
                      the atmVpCrossConnectTable of this MIB or by
                      the same value of  the cross-connect index in
                      the cross-connect table for SVCs and Soft PVCs
                      (defined in a separate MIB module). 
                      At no time should entries in these respective
                      cross-connect tables exist simultaneously
                      with the same cross-connect index value.

                      The value of this object is initialized by the
                      agent after the associated entries in the
                      appropriate cross-connect table have been
                      created."
>
>- For atmVclCrossConnectIdentifier in ATM-MIB, change:
>                     "This object is implemented only for a VCL
>                      which is cross-connected to other VCLs
>                      that belong to the same VCC.  All such
>                      associated VCLs have the same value of this
>                      object, and all their cross-connections are
>                      identified by entries in the
>                      atmVcCrossConnectTable for which
>                      atmVcCrossConnectIndex has the same value.
>                      The value of this object is initialized by the
>                      agent after the associated entries in the
>                      atmVcCrossConnectTable have been created."
>  to:
>                     "This object is implemented only for a VCL
>                      which is cross-connected to other VCLs
>                      that belong to the same VCC.  All such
>                      associated VCLs have the same value of this
>                      object, and all their cross-connections are
>                      identified either by entries that are indexed
>                      by the same value of atmVcCrossConnectIndex in
>                      the atmVcCrossConnectTable of this MIB or by
>                      the same value of atmSvcVcCrossConnectIndex in
>                      the atmSvcVcCrossConnectTable of the ATM2-MIB.
>                      Which of these cross-connect tables is used
>                      depends on the atmVclConnKind values of the
>                      cross-connected VCLs.
>
>                      The value of this object is initialized by the
>                      agent after the associated entries in the

>                      appropriate cross-connect table have been
>                      created."
>
>- For atmVpCrossConnectIndex in ATM-MIB, change:
>                     "A unique value to identify this VP cross-connect."
>  to:
>                     "A unique value to identify this VP cross-connect.
>                      For each VPL associated with this cross-connect,
>                      the agent reports this cross-connect index value
>                      in the atmVplCrossConnectIdentifier attribute of
>                      the corresponding atmVplTable entries."
>
>- For atmVcCrossConnectIndex in ATM-MIB, change:
>                     "A unique value to identify this VC cross-connect."
>  to:
>                     "A unique value to identify this VC cross-connect.
>                      For each VCL associated with this cross-connect,
>                      the agent reports this cross-connect index value
>                      in the atmVclCrossConnectIdentifier attribute of
>                      the corresponding atmVclTable entries."
>
>- For atmSvcVpCrossConnectIndex in ATM2-MIB, change:
>                     "A unique value to identify this SVPC
>                     cross-connect."
>
>  to:
>                     "A unique value to identify this SVPC
>                     cross-connect.  For each VPL associated with
>                     this cross-connect, the agent reports this
>                     cross-connect index value in the
>                     atmVplCrossConnectIdentifier attribute of
>                     the corresponding atmVplTable entries in the
>                     ATM-MIB."
>                       
>- For atmSvcVcCrossConnectIndex in ATM2-MIB, change:
>                     "A unique value to identify this SVCC
>                     cross-connect."
>  to:
>                     "A unique value to identify this SVCC
>                     cross-connect.  For each VCL associated with
>                     this cross-connect, the agent reports this
>                     cross-connect index value in the
>                     atmVclCrossConnectIdentifier attribute of
>                     the corresponding atmVclTable entries in the
>                     ATM-MIB."
>
>I hope these DESCRIPTIONs don't seem too painfully wordy, but that
>they instead help make it clearer how these objects cross-reference
>each other between the various MIBs.
>
>Regards,
>Gary
>
>
>On Fri, 10 Apr 1998, Kaj Tesink wrote:
>
>> Gary, thanks for tyhe detailed comments!
>> some annotations below.
>> 
>> kaj
>> 
>> At 04:28 PM 4/9/98 -0700, Gary Hanson wrote:
>> >
>> >Kaj,
>> >
>> >As long as you are working on atm1ng-03, I thought I might send
>> >a few more items your way.
>> >
>> >1.  No explicit statements exist to when or how the PVC or SVC
>> >    cross-connect tables are to be used for Soft PVCs or SVCs.
>> >
>> >    The DESCRIPTIONs for the atmVplConnKind and atmVclConnKind
>> >    objects shed no light on this, nor does the AtmConnKind
>> >    DESCRIPTION.  The latter DOES say that "an spvcInitiator is
>> >    always cross-connected to an svcOutgoing, and an spvcTarget
>> >    is always cross-connected to an svcIncoming", but it does

>> >    NOT say how to make use of the PVC and SVC tables to actually
>> >    accomplish this.  I am left unsure whether to use just the
>> >    PVC table, just the SVC table, or both.  Also, no explicit
>> >    statement is made about using the SVC cross-connect tables
>> >    between svcIncoming and svcOutgoing virtual links.
>> >
>> >    The DESCRIPTIONs for the atmVplCrossConnectIdentifier and
>> >    atmVclCrossConnectIdentifier objects make NO mention at all
>> >    of the possibility that their values identify entries in the
>> >    atmSvcVpCrossConnectTable or the atmSvcVcCrossConnectTable,
>> >    and yet specifically mention that their values ARE to be used
>> >    to identify entries in the atmVpCrossConnectTable or the
>> >    atmVcCrossConnectTable.
>> >
>> >    This leaves the whole matter of how and when entries in these
>> >    sets of tables are to be used COMPLETELY UNDEFINED between
>> >    the ATM-MIB, the ATM2-MIB, and the ATM-TC-MIB, which I happen
>> >    to think is a serious problem.  I had asked about this on the
>> >    atommib WG list a while back, but have not heard any feedback.
>> >
>> >    Since we have been assuming that it is legal to evolve the
>> >    use of the atmV.lCrossConnectIdentifier objects to refer to
>> >    either the PVC or SVC cross-connect tables, I think it is
>> >    important to follow through and do the following:
>> >    - fully describe the manner by which the atmV.lConnKind objects
>> >      indicate to which tables the atmV.lCrossConnectIdentifier
>> >      objects actually refer, and
>> >    - supplement the atmV.lCrossConnectIdentifier DESCRIPTIONs to
>> >      indicate the possibility that the index refers to different
>> >      tables, depending upon the corresponding atmV.lConnKind
>> >      value.
>> >
>> >    Do you want proposed wording for this, or is it fairly obvious
>> >    what needs to be done?
>> 
>> Proposed wording to this list would be much appreciated to allow everyone to see;
>> i'm trying to edit the hopefully last version of this before Last Call.
>> 
>> >
>> >2.  The atmVplAdminStatus and atmVplLastChange objects were left
>> >    out of the atmVplCrossConnectGroup and should be added.
>> 
>> i thought atmVplAdminStatus is not implemented for crossconnects?
>
>Oops....good point.  I forgot that.
>
>> atmVplLastChange seems indeed missing
>> 
>> >
>> >3.  The atmVclAdminStatus and atmVclLastChange objects were left
>> >    out of the atmVclCrossConnectGroup and should be added.
>> 
>> as above
>
>Ditto.
>
>> [...]
>> >
>> >Regards,
>> >Gary
>> > 
>> 
>> _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/
>> _/                                                                      _/
>> _/  Kaj Tesink                                                          _/
>> _/  Bellcore                                                            _/
>> _/  Business Internet Professional Services  vmail (732) 758-5254       _/
>> _/  331 Newman Springs Rd.                   email [email-masked]  _/
>> _/  Red Bank, NJ 07701                     faxmail (732) 758-2269       _/
>> _/                                                                      _/

>> _/  * NOTE AREA CODE CHANGE (908) --> (732) EFFECTIVE JUNE 1, 1997 *    _/
>> _/                                                                      _/
>> _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/
>> 
>> 
> 

_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/
_/                                                                      _/
_/  Kaj Tesink                                                          _/
_/  Bellcore                                                            _/
_/  Business Internet Professional Services  vmail (732) 758-5254       _/
_/  331 Newman Springs Rd.                   email [email-masked]  _/
_/  Red Bank, NJ 07701                     faxmail (732) 758-2269       _/
_/                                                                      _/
_/  * NOTE AREA CODE CHANGE (908) --> (732) EFFECTIVE JUNE 1, 1997 *    _/
_/                                                                      _/
_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/

_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/
_/                                                                      _/
_/  Kaj Tesink                                                          _/
_/  Bellcore                                vmail (732) 758-5254        _/
_/    331 Newman Springs Rd.                email [email-masked]   _/
_/    Red Bank, NJ 07701                  faxmail (732) 758-2269        _/
_/                                                                      _/
_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/

---

From: Gary Hanson <[email-masked]>
Date: Tue, 28 Apr 1998 21:10:11 -0700 (PDT)

Kaj and Mickey,

I still question the need to avoid having ATM-MIB or ATM-TC-MIB
refer directly to the ATM2-MIB.  If the former two MIBs were ready
to be published tomorrow and the ATM2-MIB were still on hold for 6
more months, the only thing I see to be gained is the updating of
the traffic management objects and textual conventions and the
addition of the AtmConnCastType objects to support p-mp connections.

Everything else that has been added to the ATM-MIB (and ATM-TC-MIB)
is there to accommodate the needs of the ATM2-MIB, such as the
AtmConnKind objects, splitting of compliance groups, etc.

It would seem that more could be gained by publishing the ATM2-MIB
at the same time as the ATM-MIB and ATM-TC-MIB, especially since
there are so many interrelationships now between the objects of
the two MIBs, to the point that the ATM-MIB would be incomplete
without the ATM2-MIB.  I would rather add MORE clarifications to
show how the ATM-MIB and ATM2-MIB relate than to try to minimize
such clarifications in an effort to make the ATM-MIB cosmetically
unrelated to the ATM2-MIB and therefore publishable without the
latter.

If the gains of releasing the ATM-MIB and ATM-TC-MIB outweigh the
problems associated with not having an ATM2-MIB to go along with
it, that's one thing, but then the SVC and Soft PVC related objects
should not be put into the ATM-MIB in the first place.  Since two
of those objects are the atmVplCrossConnectIdentifier and the
atmVclCrossConnectIdentifier, which now take on an expanded meaning
than before, I don't see how that can be done, other than by
sleight of hand.

Anyway, that's my two cents on the subject.

More comments below....

Regards,
Gary

> it may be better to nail this down in the xconnect tables themselves.

The xconnect tables certainly MUST be clarified.  Otherwise, there is
nothing in the MIBs that documents that the xconnect index values are
actually represented in the atmVplCrossConnectIdentifier and the
atmVclCrossConnectIdentifier objects.  However, the latter two objects
also MUST be clarified, otherwise they will be incorrect as soon as an
agent references from them any xconnects in the ATM2-MIB instead of
xconnects in the ATM-MIB.

I think that specifying what relationship the AtmConnKind objects have
to their corresponding CrossConnectIdentifier objects would help
increase the self-documenting nature of the ATM-MIB.  While it is not
100% essential, it might help steer us implementors towards doing the
same thing consistently.  Ditto for the AtmConnKind textual convention
cross-references to the ATM2-MIB.

>        - each VPL has its atmConnKind set to pvc(1)"

I think those are good changes in addition to the others.

However, I was not sure why you use a colon and two bullets;
was there supposed to be an "if" before the colon and an "and"
between the two bullets?

Also, can't  MORE than two VPLs can be cross-connected?

>        PVCs, SVCs and Soft PVCs."

Looks good to me.

> may be better to have these clarifications.

I would agree.  Both the compliance clauses and the object
clarifications would be helpful.

>     atmVclCrossConnectIdentifier; see below

Yes, I think there is redundancy here, but it is the helpful kind,
the kind that makes you feel that it confirms your understanding,
since when it says something in one place it also reaffirms that
same thing in the other places that you would expect it to.

>   have a tendency to cause problems over time, hence my caution

In this case, I would think that the explanatory benefits are
likely to outweigh problems due to future evolutions, especially
since such explanations are likely to increase interoperability in
the near term, a helpful prerequisite for furthering standardization
beyond the immediate horizon.

>                      "This object is instanciated only for a VPL

                    ... should be ... "instantiated"

>                       (defined in a separate MIB module). 

Well, that IS kind of beating around the bush, but it gives a
strong implication of what is intended, without coming right out
and saying it.  All in all, a good wordsmithing job, I'd agree....

But, is it really necessary to NOT reference the ATM2-MIB?

> >                      appropriate cross-connect table have been

Were you planning to make the remaining changes as well?