Subject: ATM2-MIB draft questions and comments

From: Gary Hanson <[email-masked]>
Date: Tue, 17 Feb 1998 17:29:43 -0800 (PST)

Mickey and other AToMMIBers,

I have a number of questions and comments regarding the ATM2-MIB in
the "draft-ietf-atommib-atm2-11.txt":

1.  I am not sure I understand the intended usage of the objects
    in the atmVplLogicalPortTable.  I see two sets of facts that
    could lead me to believe that an entry is supposed to exist
    either: (a) for every atmVplEntry, automatically created by the
    agent; or (b) for only those atmVplEntry's for which a manager
    wishes to supply the additional atmVplLogicalPortDef information.

    On one hand, I am led to believe the intention was (a), because:
    - It is a mandatory object in a table which AUGMENTS atmVplEntry,
      with a MAX-ACCESS of read-create and a MIN-ACCESS of read-only.
    - The object atmVplLogicalPortDef can have either the value
      notLogicalIf(1) or isLogicalIf(2).

    On the other hand, I am led to believe the intention might possibly
    have been (b), because:
    - The first sentence in section 6.3.10.2, which says: "The ATM
      Logical Port Interface Table is used only by devices supporting
      VP tunnels."

    Am I correct in assuming case (a)?  If so, shouldn't the above
    quoted sentence be editted to say something like: "The ATM Logical
    Port Interface Table can be used by devices to create VP tunnels."?

2.  Assume a VPL terminates at a switch, and the manager wishes to
    set up 5 VCC cross-connects between VCLs within the VPL and VCLs
    on other interfaces.

    Is the manager required to setup an atmLogical(80) interface for
    the VPL?

    - If so, is the manager required to setup the 5 VCLs using the
      atmLogical(80) interface's ifIndex value as the first INDEX?

      In other words, is the manager NOT allowed to setup the 5 VCLs
      using the atm(37) interface's ifIndex value as the first INDEX?

    - If not, is the manager allowed to create atmVclTable entries
      for the atm(37) interface that share the same VPI value as for
      the encompassing atmVplTable entry?

    I think this issue was discussed several times before, but I am not
    sure what the group's consensus was on it.

3.  If an arbitrary MIB refers to the use of an "ATM Interface", but
    does not explicitly refer to the use of either an atm(37) or an
    atmLogical(80) interface, is it generally assumed valid to allow
    the use of an atmLogical(80) interface (assuming it is meaningful
    to use an interface for which only one VPI is allowed)?

    For example, in the ATM-FORUM-MIB there are a number of tables that
    are indexed by an InterfaceIndex-like value, for which I would
    think it is appropriate to have entries not only for atm(37) but
    also atmLogical(80) interfaces.  These tables include:
    - atmfAtmLayerTable
    - atmfVccTable
    - atmfVccAbrTable
    - atmfPortTable (unless we take the MIB literally to refer ONLY
           to "physical" interfaces, and thus preclude its storing
           atmfPortMyIfName and atmfPortMyIfIdentifier values for
           VP tunnels)

    Ditto for ATM-FORUM-ADDR-REG tables, such as:
    - atmfNetPrefixTable
    - atmfAddressTable
    - atmfAddressRegistrationAdminTable

    Ditto for ATM-FORUM-SRVC-REG table:
    - atmfSrvcRegTable

    Ditto for (unpublished) ATM-FORUM-M4-MIB tables, such as:
    - atmfM4AtmLayerTable
    - atmfM4VcNextVciTable
    - atmfM4CellProtoCurrTable
    - atmfM4CellProtoHistTable
    - atmfM4CellProtoErrorTable
    - atmfM4VpUpcNpcCurrTable
    - atmfM4VpUpcNpcHistTable
    - atmfM4VpTestTable

    My question can be summarized thus:  If a MIB does not specifically
    raise the atm(37) vs. atmLogical(80) issue for a given table that
    is indexed by an "ATM Interface" ifIndex value, should it be assumed
    legal to populate the given table with entries for both types of
    interfaces, unless it is quite clear by context that applicability
    to atmLogical(80) interfaces is not intended?

    Also, is it the responsibility of the ATM2-MIB document to provide
    such a statement of applicability for both interface types?

4.  Some more material may need to be added to section 6.3.10.2 "How
    to create an ATM logical interface" to describe the use of the
    atmInterfaceExtTable values.

    For example, the value to be reported for some objects in this table
    is obviously different for atmLogical(80) interfaces than for atm(37)
    interfaces.  The following objects seem fairly obvious to me, but are
    still worth mentioning explicitly, to avoid various interpretations:
    - atmInterfaceConfMaxSvpcVpi - VPI of the VP tunnel, although VPCs
                                   cannot be setup on a VP tunnel.
    - atmInterfaceCurrentMaxSvpcVpi - VPI of the VP tunnel, although VPCs
                                      cannot be setup on a VP tunnel.
    - atmInterfaceConfMaxSvccVpi - VPI of the VP tunnel.
    - atmInterfaceCurrentMaxSvccVpi - VPI of the VP tunnel.

    I am not sure about the following objects, and am interested in
    knowing what others in the WG think:
    - atmIntfPvcFailures - Should this include or NOT include the
                           failure of the VPL itself, since its failure
                           would be covered by the counter for the
                           encompassing atm(37) interface?
    - atmIntfCurrentlyFailingPVpls - Should this include or NOT include
                                     the VPL itself, if it is failing?
    - atmIntfPvcFailuresTrapEnable - Should atmIntfPvcFailuresTrap be
                                     sent for the failure of the VPL
                                     using the atm(37) interface or the
                                     atmLogical(80) interface?

5.  The DESCRIPTION for atmSigDescrParamIndex still refers to the
    atmVclExtTable.  I would suggest changing the DESCRIPTION to read:
    "The value of this object is used by the atmVclGenSigDescrIndex
    object in the atmVclGenTable to identify a row in this table."

6.  From where are the atmVp/VcCrossConnectProviderName provider name
    values supposed to be derived?  Since these objects are read-only,
    they cannot be set directly.  Was there some intended standard
    object from some other MIB that was supposed to be used, or was
    this intended to be an implementation-specific issue?  (There is
    no explanatory text describing the atmVp/VcCrossConnectXTables to
    clarify this question.)

7.  Two objects are defined using the unknown macro "OBJECT-IDENTIFIER",
    which should be changed to "OBJECT IDENTIFIER".  These objects
    include:
    - atmPvcTraps
    - atmPvcTrapsPrefix

8.  Several objects were never added to the various OBJECT-GROUP
    sequences of OBJECTS.

    The following objects belong in the atmSwitchServcGroup:
    - atmSwitchAddressAddress
    - atmSwitchAddressRowStatus

    The following objects belong in the atmSwitchServcHostGroup:
    - atmCurrentlyFailingPVplTimeStamp
    - atmCurrentlyFailingPVclTimeStamp

9.  The three Trap Control objects are still included in the
    atmSwitchServcHostGroup OBJECT-GROUP sequence of OBJECTS, even
    though they were removed in draft-ietf-atommib-atm2-10.txt.
    They include:
    - atmPvplTrapControl
    - atmPvclTrapControl
    - atmTrapThreshold

By the way, I am not sure whether the various atommib WG drafts have
all actually expired or are merely in the IESG's in box / out box.
Does someone know which MIBs have yet to have a last call, and whether
any of the other MIBs have actually been approved by the IESG but are
still in limbo waiting for the removal of some other obstacle to their
publication?

Regards,
Gary

 ______
| ///  |       TM   Gary Hanson                [email-masked]
|   ADC|Kentrox     14375 NW Science Park Dr.  503-641-3321 (FAX)
|______|            Portland, Oregon  97229    800-733-5511 x6333

---

From: "Michael H. Grobelch" <[email-masked]>
Date: Tue, 17 Feb 1998 19:35:03 -0800

Gary,

IMO:

 >From [email-masked] Tue Feb 17 17:43:29 1998
 >Date: Tue, 17 Feb 1998 17:29:43 -0800 (PST)
 >From: Gary Hanson <[email-masked]>
 >X-Sender: gary@skeeter
 >Reply-To: Gary Hanson <[email-masked]>
 >To: Mickey Spiegel <[email-masked]>
 >Cc: [email-masked]
 >Subject: ATM2-MIB draft questions and comments
 >
 >

The intent is that when a VPL entry is created, the associated
atmVplLogicalPortTable entry would also be created.

On a system that supports VP tunnels, one can specify
the value of atmVplLogicalPortDef as isLogicalIf prior to 
activation of the VPL entry, to indicate that the VPL is to be a 
tunnel interface. By default, the VPL would not be a tunnel.

On a system that doesn't support VP tunnels, the object
would be read-only, fixed as notLogicalIf.

 >    Am I correct in assuming case (a)?  

^^ Yes.

 > If so, shouldn't the above

^^ Perhaps one could say: 
"On devices supporting VP tunnels, the ATM Logical
 Port Interface Table can be used to create VP tunnels."

 >    Is the manager required to setup an atmLogical(80) interface for

^^ Assuming that you wish to define the VPL at the switch, yes.

 >      atmLogical(80) interface's ifIndex value as the first INDEX?

^^ Yes. This is mentioned in  6.3.10.2:
"- Set the object atmVplLogicalPortDef to isLogicalIf.
   A new row in the ifTable is then created by the agent,
   with ifIndex=y, to represent the ATM Logical Port interface.

	...

 - VCLs defined on the VP tunnel are indexed by
   ifIndex=y,VPI=a,VCI."

 >      using the atm(37) interface's ifIndex value as the first INDEX?

^^ Assuming the tunnel VPL is defined on the switch, yes.

 >                           encompassing atm(37) interface?

^^I think not, handle the VPL on atm(37).

 >                                     the VPL itself, if it is failing?

^^I think this would be handled on atm(37).

 >                                     atmLogical(80) interface?

^^You can have two traps sent, one for the VPL on atm(37),
  the other for any VCLs on atmLogical(80).

Mike

 >|______|            Portland, Oregon  97229    800-733-5511 x6333

------- End of Forwarded Message

---

From: Gary Hanson <[email-masked]>
Date: Wed, 18 Feb 1998 08:42:58 -0800 (PST)

Mike,

Thanks for clarifying the points about VP tunnels.  However, I still am
not sure I understand a few things.

> would be read-only, fixed as notLogicalIf.

Given all that, I would think it makes sense to redefine the SYNTAX
of atmVplLogicalPortIndex from InterfaceIndex to InterfaceIndexOrZero,
to allow the value 0 to be used to indicate that there is NO ifTable
index assigned by the agent for the VPL.

I would suggest replacing the second sentence of the DESCRIPTION with
the following:  "The distinguished value of zero indicates that the
agent has not (yet) assigned such an ifTable index.  The zero value
must be assigned by the agent if the value of atmVplLogicalPortDef is
set to notLogicalIf, or if the VPL row is not active." 

>  Port Interface Table can be used to create VP tunnels."

Yes.  I think that wording would be even better.

> ^^ Assuming that you wish to define the VPL at the switch, yes.

Hmmm.  I'm not sure I understand this answer.  Maybe I should ask this
question:  When would a manager WANT to use the notLogicalIf value?

>  [...]
>  [...]

Gary

---

From: "Michael H. Grobelch" <[email-masked]>
Date: Wed, 18 Feb 1998 09:50:02 -0800

Gary,

 >Date: Wed, 18 Feb 1998 08:42:58 -0800 (PST)
 >To: "Michael H. Grobelch" <[email-masked]>
 >Cc: [email-masked], [email-masked]
 >Subject: Re: VP tunnels (was ATM2-MIB draft questions and comments)
 >
 >
 >Mike,
 >

^^ We could do this. What's the sentiment of the list?
      The current statement that the object isn't valid if the VPL isn't
      active or atmVplLogicalPortDef is set to notLogicalIf is OK
      to me.  

 >question:  When would a manager WANT to use the notLogicalIf value?

I wouldn't want to do so particularly myself, but I was just trying to
make clear the dependancy. 

Mike

---

From: Keith McCloghrie <[email-masked]>
Date: Wed, 18 Feb 1998 10:25:40 -0800 (PST)

>       active or atmVplLogicalPortDef is set to notLogicalIf is OK

Either is OK, but Gary's suggestion is better (InterfaceIndexOrZero is
defined in RFC 2233).

Keith.

---

From: Mickey Spiegel <[email-masked]>
Date: Fri, 06 Mar 1998 21:37:39 -0800

Gary,

<snip>

>     though they were removed in draft-ietf-atommib-atm2-10.txt.

I seem to have mismanaged my files the last time around.  I found a
source file dated one day later than the version I posted, with all
these fixes incorporated.  I guess I compiled and fixed things, then
posted the wrong version.

I will try to put out the next version by Wednesday.

Mickey