Re: Proposed changes to Draft Frame Relay MIB for multiprotocol support.
Alan Bartky <alan@xylan.com> Fri, 12 January 1996 17:12 UTC
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11904; 12 Jan 96 12:12 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa11900; 12 Jan 96 12:12 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa08926; 12 Jan 96 12:12 EST
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11868; 12 Jan 96 12:12 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id ab11864; 12 Jan 96 12:10 EST
Received: from xylan.XYLAN.COM by CNRI.Reston.VA.US id aa08893; 12 Jan 96 12:10 EST
Received: from omni.xylan.com by xylan.com (4.1/SMI-4.1 (xylan-mgw 1.0)) id AA14818; Fri, 12 Jan 96 09:10:30 PST
Received: from canary.UUCP by omni.xylan.com (4.1/SMI-4.1 (omni 1.1)) id AA25352; Fri, 12 Jan 96 09:10:23 PST
Received: from robin.xidc by irvine.XYLAN.COM (4.1/SMI-4.1) id AA25628; Fri, 12 Jan 96 08:49:01 PST
Date: Fri, 12 Jan 1996 08:49:01 -0800
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: <9601121649.AA25628@irvine.XYLAN.COM>
To: james@newbridge.com, cbrown@baynetworks.com
Subject: Re: Proposed changes to Draft Frame Relay MIB for multiprotocol support.
Cc: iplpdn@CNRI.Reston.VA.US, alan@xylan.com
Caralyn - My comments are edited in below: > I was just fixing up a portion of the mib and really looked at this > definition: > > -- ifInUnknownProtos Number of unknown or unsupported > upper layer protocol frames received > and discarded. If only a single > upper layer protocol is present > (i.e. multiprotocol formatting is > not used) then this counter > would be always zero(0). > > > At first this made sense to me, but now I'm having second thoughts. If > there is only a single upper layer on the side doing the counter, but the > other side is sending other stuff, this could be non-zero. My main objective for this counter was for implementations that support frame relay RFC 1490 encapsulations, whether they are single or multi-protocol. If you have an RFC 1490 implementation you must discard and not process any messages that you do not support or understand. Since this MIB is for Frame Relay DTEs, I am assuming that most of the implementations that are not proprietary will support RFC1490 encapsulation, but there is no MIB for the Protocol multiplexing/demultiplexing function for multi-protocol. > Let's say > for example that I'm supporting 1490 encaps and I have IP and AppleTalk > supported. What if the other side sends me an IPX frame. Would that > increase the counter? Yes. > What if I support only IP with no encaps and the > other side sends me a 1490 encapsulated frame? I might not be able to > identify this situation. That was my intent of saying (multiprotocol formatting is not used) in the comment. In that situation there is no protocol multiplexing/demultiplexing function at the "frame relay" layer. In that case the counter would always be 0. > I'm not entirely sure how to nail down the use of > this object using this definition. > > If we stop after the first sentence it leaves a lot of room for interpretation. > Is this a good thing or a bad thing? > 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. > c > > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > Caralyn Brown Voice: 508-436-3835 > Bay Networks Internet: cbrown@baynetworks.com > 2 Federal Street > Billerica, MA 01821 > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > 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 **********************************************************
- 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