The IP Over NBMA (ION) Archive

Cell Relay Retreat>ION Archive>month:1996-Jul> msg00078



[Date Prev][Date Next][Thread Prev][Thread Next]  
  [Date Index][Thread Index][Author Index][Subject Index]

comments on MARS draft MIB

  • From: cchung@tieo.saic.com (Chris Chung)
  • Date: Tue, 16 Jul 1996 16:24:43 -0400 (EDT)
  • Cc: greene@nexen.com, ion@nexen.com, donc@fore.com

Hi Ramesh,

>I have few comments on the MARS MIB draft submitted by you.

Thanks for those good comments.

>1. In ipAtmMarsTable  clusterSeqNum and ServerSeqNum are added whose value
>   keeps changing with every message. These objects don't seem to be useful
>   from management point of view.
>
>2. In ipAtmMarsRegClientTable (p.27), ipAtmMarsregClientCsn doesn't seem to be
>   useful from the management point of view.
>   Similarly, ipAtmMarsRegMcsCsn (p.30) in ipAtmMarsRegMcsTable doesn't seem
>   to be useful and I think it should be ipAtmMarsRegMcsSsn.
>

Normally, those objects are not useful except when an active MARS goes down.
The information is used for the construction of a backup server control VC by
any one of the backup MARS.

>3. In ipAtmMarsStatTable (p.30) lot of descriptions don't match the object
>   names. I guess this is due to cut and paste.
>

Yes. But those errors will be cleaned up in the next go ground.

>   In ipAtmMarsStatTable (p.32), ipAtmMarsStatRxSjoin and ipAtmMarsStatRxSleave
>   objects are not relevant since Mars does not receive sjoin and sleave
>   messages.
>
>4. In ipAtmMarsMcsStatTable (p.45), ipAtmMarsMcsStatTxSjoin and
>   ipAtmMarsMcsStatTxSleave objects are not relevant since MCS does not send
>   sjoin and sleave messages. Correct me if I am wrong.
>

3 & 4 go together and you are right in both cases.  Those objects 
will be deleted.

>additions
>---------
>
>1. In MARS MIB, it would be useful to have a table for configuring backup
>   MARS servers for this MARS. This table would contain :
>
>   ipAtmMarsIndex, ipAtmMarsBackupAddr, ipAtmMarsBackupPriority,
>   ipAtmMarsBackupRowStatus

Maybe it would be better to add the following fields in the ipAtmMarsTable
so that the ipMarsServStatus field can also be used.  Since it indicates
the state of a MARS.

    ipAtmMarsType which has following two possible integer values
       primary (1)
       backup (2)

    ipAtmMarsPriority - which applies only to backup MARSs.
>
>2. A table for configuring multi-cast groups to be serverd by a MCS would
>   be useful.  This would contain :
>
>   ipAtmMarsMcsIndex, ipAtmMarsMcsGroupAddr, ipAtmMarsMcsGroupAddrRowStatus
>

The multicast group mapping information is embeded in the MCS VC table, 
where the multicast group information can be also obtained.  So, I'm not sure 
if a separate multicast group table would be useful.  In addition, the group
information a MCS or a MARS client has is coming from the MARS.  However, it 
there is a need to add such table, a similar table would need to be added for 
a MARS client.  Comments?


Regards,

Chris