Re: Proposed changes to Draft Frame Relay MIB for multiprotocol support.

James Watt <james@ca.newbridge.com> Tue, 16 January 1996 02:19 UTC

Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa26713; 15 Jan 96 21:19 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa26706; 15 Jan 96 21:19 EST
Received: from [132.151.1.35] by CNRI.Reston.VA.US id aa16951; 15 Jan 96 21:19 EST
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa26487; 15 Jan 96 21:17 EST
Received: from [132.151.1.1] by IETF.CNRI.Reston.VA.US id aa26483; 15 Jan 96 21:13 EST
Received: from [192.75.23.67] by CNRI.Reston.VA.US id aa15977; 15 Jan 96 21:12 EST
Received: (from adm@localhost) by ns.newbridge.com (8.6.12/8.6.12) id VAA13958; Mon, 15 Jan 1996 21:10:41 -0500
Received: from portero(192.75.23.66) by ns via smap (V1.3) id sma013953; Mon Jan 15 21:10:32 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 VAA11327; Mon, 15 Jan 1996 21:10:31 -0500
Received: from fields.newbridge (fields.ca.newbridge.com [138.120.144.160]) by thor.ca.newbridge.com (8.6.12/8.6.12) with SMTP id VAA19788; Mon, 15 Jan 1996 21:10:30 -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: <199601160210.VAA19788@thor.ca.newbridge.com>
Subject: Re: Proposed changes to Draft Frame Relay MIB for multiprotocol support.
To: Alan Bartky <alan@xylan.com>
Date: Mon, 15 Jan 1996 21:10:29 -0500 (EST)
Cc: james@newbridge.com, cbrown@baynetworks.com, iplpdn@CNRI.Reston.VA.US, alan@xylan.com
In-Reply-To: <9601121649.AA25628@irvine.XYLAN.COM> from "Alan Bartky" at Jan 12, 96 08:49:01 am
X-Mailer: ELM [version 2.4 PL22]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Length: 1340

Alan Bartky writes:
+-----------
|I think we want to be specific.  Maybe rewording would help. How about:
|
| --      ifInUnknownProtos  For implementations that
|                          use RFC 1490 Multiprotocol
|                          over Frame Relay, this counts
|                          the number of frames received
|                          but not delivered to an
|                          upper layer due to unknown
|                          or unsupported protocols.
|                          If RFC 1490 Multiprotocol encapsulation
|                          is not used, then this counter
|                          would be always zero(0).
|
|And of course we'll need a reference to RFC 1490 in the
|reference section.
+--------

One dumb question: what happens if some VCs on an interface are using
RFC 1490 and others aren't ?  I'm not sure this would be a too common
occurrence but I couldn't find anywhere that we said the interface
had to be homogenous in encapsulation within the FR frame ?

Having said that, I think the words cited above will work just fine.

Regards,
-james
____________________________________________________________________________
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