The IP Over NBMA (ION) Archive[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index][Thread Index][Author Index][Subject Index] comments on draft-ietf-iplpdn-frmib-dte-07.txt
Comments edited in below: - Alan K. Bartky Xylan Corporation 6/17/96 14:45 > From owner-ion@nexen.com Mon Jun 17 12:49:48 1996 > X-Sender: fred@stilton.cisco.com > Mime-Version: 1.0 > Content-Type> : > text/plain> ; > charset="us-ascii"> > Date: Mon, 17 Jun 1996 12:22:53 -0700 > To: ion@nexen.com > From: roy.spitzer@adn.alcatel.com (Roy Spitzer) (by way of fred@cisco.com (Fred > Baker)) > Subject: comments on draft-ietf-iplpdn-frmib-dte-07.txt > Sender: owner-ion@nexen.com > X-Info: [Un]Subscribe to ion-request@nexen.com, submissions to ion@nexen.com > X-Info: Hypermail archive at http://netlab.ucs.indiana.edu/hypermail/ion/ > X-Info: FTP archive at ftp://ftp.nexen.com/pub/ion/ > Content-Length: 7114 > > Carolyn, Fred, and Charles, > > I am sorry that these comments are so late. I just found out about this > new iteration of RFC1315 at the last Frame Relay Forum meeting from Andy > Malis. At the same time our offices was moving and I just was able to retrieve > a copy of the proposed MIB for the Montreal IETF June 24, 1996. > > How do I get on the proper distribution list for these discussions. Andy > gave me ion and it did not seem right. Please forward this mail to the > proper distribution list. > This MIB is for all intents and purposes done for now. We at Xylan have a working version of the draft MIB and I see no need for any of the changes you have requested. There will be a lot of changes needed for SVCs and possibly for RFC1490 multiprotocol and other issues in the upcoming MIBs for Frame Relay DTE (USER) and network devices. As far as learning about this "so late" the MIB working group that worked on this is the same one that drafted RFC1315 (iplpdn) and if anyone is doing any MIB work it is very easy to find these working groups. Drafts are kept in the public FTP servers and anyone doing work on any RFC MIB they should go to the FTP servers and do searches for drafts on the RFCs and/or subjects they are working on. The Frame Relay Forum is not where this work is going to draft the MIBs, the IETF is the appropriate body for this work. > Comments: > > 1. We believe that a definition of frTrapState at the interface > basis is more useful for some vendors than for all interfaces. > Some interfaces may be managed by different agents than others. > I would suggest that frDlcmiTrapState be added to the frDlcmiTable. > > 2. The frDlcmiTable does not support bidirectional signalling. Will > this be a problem for the future? Currently, I know of no DTE > vendor that supports bidirectional signalling. > I don't know of any either. That is the point of working in the MIB for consensus. If someone has a dire need for it they can contribute work on the next version. Preferably as an optional table. > 3. frClcmiAddressLen is not adequate. Since the MIB is going to be > changed, I suggest the same definition as frLportAddrDLCILen from > RFC 1604 be used. > The existing draft object is also in RFC1315 and is defined as: frDlcmiAddressLen OBJECT-TYPE SYNTAX INTEGER { two-octets (2), three-octets (3), four-octets (4) } ACCESS read-write STATUS mandatory DESCRIPTION "This variable states which address length in octets. In the case of Q922 format, the length indicates the entire length of the address in- cluding the control portion." The RFC1604 version is: frLportAddrDLCILen OBJECT-TYPE SYNTAX INTEGER { twoOctets10Bits(1), threeOctets10Bits(2), Since this object is in RFC1315 and should not be deprecated (since there are lots of RFC1315 implementations for agents and managers) this object must remain as it is currently defined. > 4. The MIB does not support different quality of service parameter > (CIR, Bc, Be) on a per direction basis. Is this a problem for the > future. > I don't know of any DTE vendor (or switches) that support it in different directions. Again if someone has a need they can express it and contribute to the next version. > 5. The following statistics would be helpful in the frDlcmiTable: > > frDlcmiLinkRelErrors OBJECT-TYPE > SYNTAX Counter32 > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "The number of user-side local in-channel > signaling link reliability errors (i.e., non- > receipt of Status/Status Enquiry messages or > invalid sequence numbers in a Link Integrity > Verification Information Element) for this UNI/NNI > logical port. If the logical port is not > performing user-side procedures, then this value > is equal to noSuchName." > REFERENCE "ITU Q.933 Annex A and ANSI T1.617 Annex D" > ::= { frDlcmiEntry 13 } > > frDlcmiProtErrors OBJECT-TYPE > SYNTAX Counter32 > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "The number of user-side local in-channel > signaling protocol errors (i.e., protocol > discriminator, message type, call reference, and > mandatory information element errors) for this > UNI/NNI logical port. If the logical port is not > performing user-side procedures, then this value > is equal to noSuchName." > REFERENCE "ITU Q.933 Annex A and ANSI T1.617 Annex D" > ::= {frDlcmiEntry 14 } > > frDlcmiChanInactive OBJECT-TYPE > SYNTAX Counter32 > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "The number of times the user-side channel was > declared inactive (i.e., N392 errors in N393 > events) for this UNI/NNI logical port. If the > logical port is not performing user-side > procedures, then this value is equal to > noSuchName." > REFERENCE "ITU Q.933 Annex A and ANSI T1.617 Annex D" > ::= { frDlcmiEntry 15 } > In my opinion all of the above statistics will put an additional burden on the DTE to monitor what the DCE is doing wrong. Maybe usefull for debugging Certification tests, but not very usefull for real world cases. The existing Fault handling in the draft MIB is my opinion adequate and easy to implement. > 6. What is the interrelationship between frCircuitMulticast and > frDlcmiMulticast? Can frCircuitMulticast be set to anything > other than unicast if frDlcmiMulticast is nonBroadcast? Can the > same interface have both unicast and multicast DLCI? If so, > what is the setting of frDlcmiMulticst set? > This one goes back a while. If any DLCI runs multicast, then frDlcmiMulticast is set to true. Yes an interface can have both unicast and multicast. The frDlcmiMulticast is more of an indicator of whether the implementation can support multicast or not, not necessarily whether they have any DLCIs that are multicast or not. > 7. What provisions are being made for SVCs or is it out of the > scope of this MIB modification? > As far as I'm concerned it is beyond the scope as this MIB is going out for last calls. We never saw any contributions on SVCs during the drafting of this MIB that I can recall. I fully support moving forward on SVCs in the next version but not in this version. > 8. The following statistics would be useful either as part of frDlcmiTable > or part of a separate table: > > frErrorUserLinkRelErrors OBJECT-TYPE > SYNTAX Counter32 > MAX-ACCESS read-only > STATUS current > DESCRIPTION -- (from RFC1604 frMgtVCSigUserLinkRelErrors) > "The number of user-side local in-channel > signaling link reliability errors (i.e., non- > receipt of Status/Status Enquiry messages or > invalid sequence numbers in a Link Integrity > Verification Information Element) for this UNI/NNI > logical port. If the logical port is not > performing user-side procedures, then this value > is equal to noSuchName." > REFERENCE "ITU Q.933 Annex A and ANSI T1.617 Annex D" > ::= { frErrorEntry 1 } > > frErrorUserProtErrors OBJECT-TYPE > SYNTAX Counter32 > MAX-ACCESS read-only > STATUS current > DESCRIPTION -- (from RFC1604 frMgtVCSigUserProtErrors ) > "The number of user-side local in-channel > signaling protocol errors (i.e., protocol > discriminator, message type, call reference, and > mandatory information element errors) for this > UNI/NNI logical port. If the logical port is not > performing user-side procedures, then this value > is equal to noSuchName." > REFERENCE "ITU Q.933 Annex A and ANSI T1.617 Annex D" > ::= { frErrorEntry 2 } > > frErrorChanInactive OBJECT-TYPE > SYNTAX Counter32 > MAX-ACCESS read-only > STATUS current > DESCRIPTION -- (from RFC1604 frMgtVCSigUserChanInactive ) > "The number of times the user-side channel was > declared inactive (i.e., N392 errors in N393 > events) for this UNI/NNI logical port. If the > logical port is not performing user-side > procedures, then this value is equal to > noSuchName." > REFERENCE "ITU Q.933 Annex A and ANSI T1.617 Annex D" > ::= { frErrorEntry 3 } > RFC 1604 supports the above statistics. I think that requiring those types of statistics for a DTE does not give enough benefits for the space it requires for code and data on the Frame Relay DTE agent code, let alone what benefit it gives for the Manager as far as debugging problems. The existing ERR table is adequate in my opinion. > frErrorRcvdShort OBJECT-TYPE > SYNTAX Counter32 > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "The number of frames that were to short to be legal > frame relay frames" > ::= { frErrorEntry 4 } > > frErrorRcvdLong OBJECT-TYPE > SYNTAX Counter32 > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "The number of frames that were longer than the length > specified in the ifTable by ifMtu for this interface." > ::= { frErrorEntry 5 } > > The above two statistics look like better candidates to lobby them to be added to the next version of the Interface MIB. Although personally I don't think they are important enough to add. > frErrorRcvdIllegalDLCI OBJECT-TYPE > SYNTAX Counter32 > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "The number of frames received with an illegal Data Link > Connection Identifier (DLCI)." > ::= { frErrorEntry 6 } > > frErrorRcvdUnknownDLCI OBJECT-TYPE > SYNTAX Counter32 > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "The number of frames received with an unknown Data Link > Connection Identifier (DLCI)." > ::= { 6fdnVsFrErrorEntry 7 } > I can't again see the benefit of these ones either. It seems that we are trying to police the DCE errors. > Regards, > Roy Spitzer > > ========================================================================== > > Roy Spitzer Roy.Spitzer@adn.alcatel.com > Alcatel Data Networks (703) 724-2412 > 44983 Knoll Square FAX: (703) 724-2005 > Ashburn, VA 20147 > > > I can see no reason for not pushing forward the current draft "as is" for publishing as an RFC. 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 ********************************************************** |
|