Multicast in draft version 5 comments

Alan Bartky <alan@xylan.com> Tue, 02 January 1996 15:32 UTC

Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09569; 2 Jan 96 10:32 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa09565; 2 Jan 96 10:32 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa17589; 2 Jan 96 10:32 EST
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09515; 2 Jan 96 10:32 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa09511; 2 Jan 96 10:30 EST
Received: from xylan.XYLAN.COM by CNRI.Reston.VA.US id aa17544; 2 Jan 96 10:29 EST
Received: from omni.xylan.com by xylan.com (4.1/SMI-4.1 (xylan-mgw 1.0)) id AA06587; Tue, 2 Jan 96 07:29:49 PST
Received: from canary.UUCP by omni.xylan.com (4.1/SMI-4.1 (omni 1.1)) id AA15781; Tue, 2 Jan 96 07:29:49 PST
Received: from robin.xidc by irvine.XYLAN.COM (4.1/SMI-4.1) id AA03378; Tue, 2 Jan 96 06:44:36 PST
Date: Tue, 2 Jan 96 06:44:35 PST
X-Orig-Sender: iplpdn-request@IETF.CNRI.Reston.VA.US
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Alan Bartky <alan@xylan.com>
Message-Id: <9601021444.AA03378@irvine.XYLAN.COM>
To: iplpdn@CNRI.Reston.VA.US
Subject: Multicast in draft version 5 comments
Cc: alan@xylan.com

Fellow Frame Relay Mibbers and Mibbettes -

I have a comment concerning draft version 5 of the Frame Relay
DTE MIB concerning the multicast object for a virtual circuit.
It is currently defined in the draft as:


     frCircuitMulticast OBJECT-TYPE
         SYNTAX   INTEGER    {
                     unicast   (1),
                     multicast (2)
                     }
         MAX-ACCESS   read-only
         STATUS   current
         DESCRIPTION
            "This indicates whether this VC is used as a multicast
            VC or a single destination"
         ::= { frCircuitEntry 15 }

The first problem (major) is that this is a read-only object.
It should be read-write.  This object doesn't do much good if
you can't manipulate it via an SNMP manager.

The second comment is that this object only has a simple yes/no
function concerning multicast.  The Frame Relay Forum Multicast
Service and Protocol Description Implementation Agreement
(FRF.7 October 21, 1994), defines a Multicast service as being
One-Way, Two-Way or N-Way.

I therefore propose the object to be changed as follows:


     frCircuitMulticast OBJECT-TYPE
         SYNTAX   INTEGER    {
                     unicast   (1),
                     oneWay    (2),
                     twoWay    (3),
                     nWay      (4)
                     }
         MAX-ACCESS   read-write
         STATUS   current
         DESCRIPTION
            "This indicates whether this VC is used as a unicast
            VC (i.e. not multicast) or the type of multicast
            service subscribed to"
         REFERENCE
            "Frame Relay PVC Multicast Service and Protocol
             Description Implementation: FRF.7
             Frame Relay Forum Technical Committe
             October 21, 1994"
         DEFVAL {1}  -- the default value of frCircuitMulticast is
                     -- "unicast" (not a multicast VC).
         ::= { frCircuitEntry 15 }

Also since multicast is optional we should allow an
implementation to only allow a write of unicast(1) as
a value and to allow other values to be optional.

Regards,

Alan

**********************************************************
Alan K. Bartky                       Email:alan@xylan.com
Principal Software Engineer
XYLAN Corporation                    Voice:(714) 597-8042
15707 ROCKFIELD BLVD STE 155F        FAX:  (714) 597-8342
IRVINE CA 92718-2830
**********************************************************

P.S. Excellent work on the draft so far!  We have compiled
the draft MIB and it seems to meet of all of current needs.