Subject: RE: <draft-ietf-atommib-atm1ng-04.txt> posting

From: Kaj Tesink <[email-masked]>
Date: Mon, 18 May 1998 11:02:04 -0400

Hi Jason,

You're right and I should have pressed the matter.
It simply appeared to me that there was no
complete consensus on what to put in.
If you think there was enough consensus would
you or someone else mind to formulate a precise 
text for inclusion? I copy this to the list.
I agree with you that it would be worthwhile.

Kaj

At 10:15 AM 5/18/98 -0400, you wrote:
>Kaj,
>
>A short time ago there was some discussion on the atommib
>list concerning which interface, ATM or AAL5, is used as the 
>index for the aal5VccTable. 
>
>I don't know what the resolution was, and I don't see, in the
>latest draft, any additional language to clarify which interface
>should be used. Is it the ATM interface?
>
>Thanks,
>
>Jason
>
>---- begin excerpt ----
>
>             -- AAL5 Virtual Channel Connection Performance Statistics
>               -- Table
>
>               -- This table contains the AAL5
>               -- performance statistics of a VCC at the
>               -- interface associated with an AAL5 entity in an ATM
>               -- host or ATM switch.
>
>
>               aal5VccTable        OBJECT-TYPE
>                    SYNTAX         SEQUENCE OF Aal5VccEntry
>                    MAX-ACCESS     not-accessible
>                    STATUS         current
>                    DESCRIPTION
>                     "This table contains AAL5 VCC performance
>                      parameters."
>                    ::= { atmMIBObjects 12 }
>
>               aal5VccEntry        OBJECT-TYPE
>                    SYNTAX         Aal5VccEntry
>                    MAX-ACCESS     not-accessible
>                    STATUS         current
>                    DESCRIPTION
>                     "This list contains the AAL5 VCC
>                      performance parameters."
>                    INDEX { ifIndex, aal5VccVpi, aal5VccVci }
>                    ::= { aal5VccTable 1 }
>
>---- end excerpt ----
>
>
>> -----Original Message-----
>> From:	Kaj Tesink [SMTP:[email-masked]]
>> Sent:	Friday, May 15, 1998 6:50 PM
>> To:	[email-masked]; [email-masked]
>> Subject:	<draft-ietf-atommib-atm1ng-04.txt> posting
>> 
>> 
> 

_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/
_/                                                                      _/
_/  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 *    _/
_/                                                                      _/
_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/

---

From: Gary Hanson <[email-masked]>
Date: Thu, 21 May 1998 12:28:17 -0700 (PDT)

Kaj,

The new draft looks very good.  Thanks for the updates you made.

Here's a suggestion for wording to remove the ambiguity of which
interface, ATM or AAL5, is to be used as the index for the
aal5VccTable.

I notice that the atmInterfaceConfEntry, atmInterfaceDs3PlcpEntry,
and atmInterfaceTCEntry DESCRIPTIONs all end with the clause "and is
indexed by the ifIndex value of the ATM interface."  I suggest that
this same clause be appended to the end of the DESCRIPTION for the
aal5VccEntry.

This would render the indexing unambiguous, and would satisfy those
who would expect to find the information indexed by ATM interface,
VPI, and VCI, which I believe is the more commonly held indexing
paradigm for this table. It would also logically extend (like the
atmInterfaceConfEntry does) to indexing by an ATM Logical Port
(ifType=80) interface.

A couple of minor nits on the atm1ng-04 draft:
- The new MIB boilerplate (when it stabilizes within the snmpv3 WG)
  should be used.
- Table 1 is split across pages 23..25, with page 24 almost empty.
- The last sentence in the first paragraph of section 10 has several
  spelling/numbering errors:
  - parenticed instead of parenthesized
  - numberss instead of numbers
  - enumeratedg instead of enumerated
  - Section 7.2 instead of Section 6.2

I'll be out of e-shot for the next few weeks starting tomorrow, so
I won't be able to reply to any more discussion on this draft for a
while.

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: Kaj Tesink <[email-masked]>
Date: Thu, 21 May 1998 23:31:51 -0400

>this same clause be appended to the end of the DESCRIPTION for the

works for me. any objections out there?

>- The new MIB boilerplate (when it stabilizes within the snmpv3 WG)

yep; learned about that recently

>  - Section 7.2 instead of Section 6.2

thanks

---

From: "Michael H. Grobelch" <[email-masked]>
Date: Thu, 21 May 1998 20:52:43 -0700

Kaj,

Just so I'm clear:

- this isn't intended to address (for the
  switch case) whether the aal5VccTable is on the
  interface at which AAL5 SAR takes place? Rather,
  it just says it should be on the ATM ifIndex.

If so, that's ok with me.

As I mentioned before, I'm for modeling the AAL5 stuff
at the interface at which SAR takes place.

Mike

 >Message-Id: <9805220336.AA29034@joker>
 >X-Sender: [email-masked]
 >X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0
 >Date: Thu, 21 May 1998 23:31:51 -0400
 >To: Jason Perreault <[email-masked]>, [email-masked],
 >        Gary Hanson <[email-masked]>
 >From: Kaj Tesink <[email-masked]>
 >Subject: RE: <draft-ietf-atommib-atm1ng-04.txt> posting
 >Cc: [email-masked]
 >In-Reply-To: <Pine.SUN.3.96.980521121711.2928C-100000@skeeter>
 >References: <9805181502.AA24066@joker>
 >Mime-Version: 1.0
 >Content-Type: text/plain; charset="us-ascii"
 >Content-Length: 5966
 >

---

From: Rajesh Abbi <[email-masked]>
Date: Fri, 22 May 1998 17:16:48 -0400

Hi Mike and Kaj,

I have following issues regarding the modeling of AAL5 VCCs as defined
in 
the current 'draft-ietf-atommib-atm1ng-04.txt' :

o VCCs that terminate in an NE are expected to be terminated by the VCL
on
  the ATM NI (UNI/NNI/ANI / ...).

o If there is a need to model internal AAL Entities that are shared by
one or more 
  ATM NIs, then the general model should reflect that.  I do not see why
the "Switch
  Model" and the "Host Model" should be different for this purpose.  The
Host model is
  just a special case of the Switch model.  Having different models
introduces undue
  complexity in the MIB.

o Why is the generic 'propVirtual(53)' interface used as an 'atm'
interface in the VCL
  Table ?  I believe that VCLs should ONLY be created on ATM Interfaces,
and that 
  atmVclTable & atmVcCrossConnectTable should only use interfaces with
ifType = 'atm'
  (or 'atmLogical(80)').

Two models are possible that may be used for both Switches as well as
Hosts, and which
are consistent in the way the interface types are used :

  A) The same AAL5 Interface appears above each ATM Interface at the ATM
NI in the 
     ifStackTable.
     ie: [phy1/atm1/aal5] [phy2/atm2/aal5] ... [phyN/atmN/aal5]

  B) The 'propVirtual' interface is treated as an internal 'physical'
interface with
     an ATM Interface on top of that followed by the AAL5 Interface.  
     ie: [phy1/atm1] [phy2/atm2] ... [phyN/atmN]  + [virtual/atm/aal5]

Association of VCLs at the ATM NI with the internal termination points
at the AAL5 could 
be made as follows:
For Model A) Extend the atmVclTable with an "VclTerminationId" object
which is ONLY
             present for terminating VCLs.  This object identifies the
internal termination
             point in the NE, and may be specified when the VCL is
created on the ATM NI.

For Model B) In this case the internal termination point at the AAL5
could be modeled as
             VCLs on the ATM Interface above the Prop Virtual Interface
used for terminating
             AAL5 VCCs.  Now the 'atmVcCrossConnectTable' could be used
normally to cross-
             connect the VCL on the ATM NI to the VCL on the internal
ATM Interface.

I would prefer the use of Model (A) since it represents the situation
more closely.  Moreover,
The AAL5 VCC is clearly shown to be terminated at the ATM NI, and is
referenced by the
VPI/VCI values at the ATM NI.

Once again, I reiterate that AAL5 VCC should be referenced by the VCL
(VPI/VCI) on the
ATM NI, which is what the user is most familiar with.

Rajesh

---

From: "Michael H. Grobelch" <[email-masked]>
Date: Fri, 22 May 1998 15:21:28 -0700

Rajesh,

 >Date: Fri, 22 May 1998 17:16:48 -0400
 >From: Rajesh Abbi <[email-masked]>
 >To: "Michael H. Grobelch" <[email-masked]>,
 >        Kaj Tesink <[email-masked]>
 >CC: [email-masked]
 >Subject: Re: <draft-ietf-atommib-atm1ng-04.txt> posting
 >
 >Hi Mike and Kaj,
 >

The MIB does attempt to allow for the more complex case (switch), and
at the same time support a host. I think it is important to distinguish
between the two.

I believe that the AAL on one end of a VCC is present on a single interface,
rather than being shared among interfaces.

 >  atmVclTable & atmVcCrossConnectTable should only use interfaces with

I believe it was thought that, while an internal interface might be 
true ATM, leeway was left for a proprietary solution. For example,
no physical layer, or a non-standard cell size (say 56-bytes rather than
53).  So the internal interface could be ATM, or propVirtual.

 >     ie: [phy1/atm1] [phy2/atm2] ... [phyN/atmN]  + [virtual/atm/aal5]

The number and placement of aal5 ifEntries depends on the switch 
architecture, and I believe indexing of the AAL5 Table should depend 
on where SAR takes place. 

Some possibilities:
- All terminated VCCs are cross-connected through the switch
   fabric to a single internal interface connected to a CPU. 
   AAL5 SAR takes place at the internal interface (and therefore 
   aal5 ifIndex is there also). There is no aal5 ifEntry on an external
   interface (as there is no SAR taking place there, the only
   known VCC statistics are in cells).

- Most terminated VCCs are cross-connected through the switch 
   fabric to a single  internal interface connected to a CPU. 
   AAL5 SAR takes place at the internal interface (and therefore 
   aal5 ifIndex is there also). The AAL5 Table entries for these VCCs 
   have the ifIndex of the internal interface.

   A "smart" interface card selectively terminates some VCCs, while
   passing through other VCCs. A signalling VCC could be terminated, 
   while transit VCCs (or VCCs terminated on a switch-internal 
   interface) pass through.  AAL5 SAR takes place at the external interface, 
   and so an aal5 ifEntry is present there. The AAL5 Table entries for
   these VCCs have the ifIndex of the external interface.
  
I believe the current scheme  has sufficient richness to model the
various architectures, and reflect them for use in network management.

Mike

---

From: Keith McCloghrie <[email-masked]>
Date: Sat, 23 May 1998 14:34:27 -0700 (PDT)

To add to Mike's comments, I suggest that AAL5 connections setup to a
particular ATM address should be modelled as being on an AAL5 ifIndex
which is "stacked" above (only) the ATM ifIndex which has that ATM

>>     ie: [phy1/atm1/aal5] [phy2/atm2/aal5] ... [phyN/atmN/aal5]

does not have this characteristic.
 
Keith.

---

From: Rajesh Abbi <[email-masked]>
Date: Tue, 26 May 1998 15:42:38 -0400

Keith,

I do not understand why the below model does not meet your criteria.

The example below describes the 'Switch Model' where multiple ATM
Interfaces share the same AAL5 Entity.  In fact the current 'Switch
Model' is as follows:
   [phy1/atm1] [phy2/atm2] ... [virtualInternal/AAL5]

This would fail your criteria as well.

In fact the VCLs in the above model are on the virtualInternal
interface,
and NOT on the AAL5 interface.

Rajesh

---- deleted ----

---

From: Rajesh Abbi <[email-masked]>
Date: Tue, 26 May 1998 16:23:51 -0400

Hi Mike,

Thanks for your explanation, but I'm still not convinced.

Please see my comments below ...

Rajesh

> rather than being shared among interfaces.

If the general model allows 'sharing' of an AAL entity, then the 'Host'
model
is the limiting case of only a single ATM Interface available for AAL5. 
Now
the same MIB model may be used for a Switch/Host.  I believe adding the
'shared'
model to a Host is less complex than maintaining two different schemes.

> 53).  So the internal interface could be ATM, or propVirtual.

I agree that there could be a need to manage some 'proprietary' internal
interface(s).  However, I do not believe the standard ATM MIB should be
used to model these.  The ATM Management model as well as the standard
MIB 
MUST be generic so that different vendors could interoperate. 
Introducing
proprietary implementations in the MIB will make things very difficult.

Moreover, the behavior of the 'internal' interfaces is likely to be
different
from the external ATM Interfaces.  Intermixing the two in the same
tables will
lead to unnecessary confusion.

> on where SAR takes place.

Not necessarily.  The user should NOT have to be aware of the internal
complexity of the switch unless absolutely necessary.  I can see a
potential need to use internal interfaces for Configuration, but for
Performance Monitoring of external entities like AAL5 VCCs, only the
standard ATM Interfaces (and the associated VPI/VCI) should be used.

>    known VCC statistics are in cells).

The MIB is only a 'logical' model.  The fact that SAR is performed using
some internal interface should not imply that a 'logical' AAL5
termination
of certain VCLs on the external interface may not be modeled wherever
possible.

---

From: "Michael H. Grobelch" <[email-masked]>
Date: Tue, 26 May 1998 16:28:16 -0700

Hi Rajesh,

see below:

 >Date: Tue, 26 May 1998 16:23:51 -0400
 >To: "Michael H. Grobelch" <[email-masked]>
 >CC: [email-masked], [email-masked],
 >        Keith McCloghrie <[email-masked]>

We currently have a MIB that  accomodates AAL5 in Switches 
and Hosts.  And it seems to me to be a simple scheme.  An 
aal5VccEntry is associated with a VPI/VCI on an interface. It 
isn't shared across interfaces. It is sited on a particular interface, 
whether on a Switch or a Host.

A Host may have more than one interface, but the AAL5 entry
is indexed at a particular interface, VPI, and VCI.

Indexing the table at the interface at which SAR is performed conveys
information to the NMS, and the model we have allows for different 
architectures,  doing SAR at various points in a switch.

 >proprietary implementations in the MIB will make things very difficult.

The proprietary interface is inside the switch, and need not affect
interoperation. 

I think it is justified. Typically the switch internal interface is different in 
a number of ways (some of which I indicated above). It can be used if
desired, if the interface is not ATM-compliant.

This was done already in RFC1695.  It is not unique in allowing
for proprietary interface types. 

 >standard ATM Interfaces (and the associated VPI/VCI) should be used.

- The NM model should be able to reveal what is taking place
   in the switch. Whether it is revealed to a "user" is up to the
   the designers of the Network Management System. Details
   revealed at the user interface (GUI, etc)  can  hide some details, 
   if desired. 

- It is specifically important in monitoring performance of the
   switch that the real processes taking place can be reflected
   in the management model. It seems to me that having multiple copies 
   of AAL5 counters, or AAL5 counters indexed where no SAR 
   takes place  can mislead/confuse the Network Management system.
   For example, none of the cells received at an external interface
   may reach the internal interface. 

 >of certain VCLs on the external interface may not be modeled wherever

I believe it is much more important that the MIB be able to convey 
this important architectural information, than that the OID of AAL5 
counters are, in some way, easy to determine. 

Perhaps we could leave the text of the indexing of 
aal5VccTable/atmAal5VclStatTable open, if the sentiment
of the list indicates that is the correct way to go. But I support the
options of the other emails (1st- indexed by the aal5 ifEntry, 2nd -
the entry below aal5 ifEntry; with appropriate wording).
 
Mike

 >> various architectures, and reflect them for use in network management.

------- End of Forwarded Message