Re: Multicast in draft version 5 comments

James Watt <james@ca.newbridge.com> Wed, 03 January 1996 17:20 UTC

Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa15518; 3 Jan 96 12:20 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa15514; 3 Jan 96 12:20 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa24869; 3 Jan 96 12:20 EST
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa15490; 3 Jan 96 12:20 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa15486; 3 Jan 96 12:19 EST
Received: from ns.newbridge.com by CNRI.Reston.VA.US id aa24605; 3 Jan 96 12:19 EST
Received: (from adm@localhost) by ns.newbridge.com (8.6.12/8.6.12) id MAA17684; Wed, 3 Jan 1996 12:19:39 -0500
Received: from portero(192.75.23.66) by ns via smap (V1.3) id sma017680; Wed Jan 3 12:19:37 1996
Received: from thor.ca.newbridge.com (thor121.ca.newbridge.com [138.120.121.43]) by kanmaster.ca.newbridge.com (8.6.12/8.6.12) with ESMTP id MAA25898; Wed, 3 Jan 1996 12:19:37 -0500
Received: from fields.newbridge ([138.120.144.160]) by thor.ca.newbridge.com (8.6.12/8.6.12) with SMTP id MAA25717; Wed, 3 Jan 1996 12:19:35 -0500
X-Orig-Sender: iplpdn-request@IETF.CNRI.Reston.VA.US
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: James Watt <james@ca.newbridge.com>
Message-Id: <199601031719.MAA25717@thor.ca.newbridge.com>
Subject: Re: Multicast in draft version 5 comments
To: Alan Bartky <alan@xylan.com>
Date: Wed, 3 Jan 1996 12:19:30 -0500 (EST)
Cc: omni!baynetworks.com!cbrown@xylan.com, iplpdn@CNRI.Reston.VA.US, alan@xylan.com
In-Reply-To: <9601022238.AA04443@irvine.XYLAN.COM> from "Alan Bartky" at Jan 2, 96 02:38:03 pm
X-Mailer: ELM [version 2.4 PL22]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Length: 1389

Folks:
  Dlcmi looks too much like Dlci for my over-rested eyes. Now that I'm
unconfused:

1) frDlcmiMulticast was in RFC 1315 (and was read-write there) and
   doesn't need any changes.  It basically tells you whether the 
   attached network can be assumed to be able to do non-unicast VCs.

2) frCircuitMulticast was added this time round and is a per-VC
   object that tells you what the _particular_ VC will do with a frame.

   Alan's proposal is to make this new object match reality, viz:
	a) have values for unicast, p2mp and mp2mp (did I forget one ?) and
        b) have a MAX-ACCESS of read-write.

   As Fred pointed out, if a given DTE doesn't want to use anything but
   unicast, it can use the WRITE-SYNTAX clause to shrink the valid range.

   I suppose we should add a refeference clause pointing to the appropriate
   section of the document that defines the FR multicast support so other
   folks can figure out why this got done.

Did I miss anything ?  If not, this sounds like a reasonable change.

Regards,
-james

ps I seem to have misplaced Alan's message with the updated object
   definition ready for Caralyn to cut and paste...
____________________________________________________________________________
James W. Watt,     james@newbridge.com                   Ph: +1 613 591-3600
Newbridge Networks 600 March Rd Kanata ON Canada K2K 2E6 FAX:+1 613 591-3680