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
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
- Proposed changes to Draft Frame Relay MIB for mul… Alan Bartky
- Re: Proposed changes to Draft Frame Relay MIB for… James Watt
- Re: Proposed changes to Draft Frame Relay MIB for… Andrew G. Malis
- Re: Proposed changes to Draft Frame Relay MIB for… Alan Bartky
- Re: Proposed changes to Draft Frame Relay MIB for… Alan Bartky
- Re: Proposed changes to Draft Frame Relay MIB for… James Watt