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 96 08:49:01 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: <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
**********************************************************