Re: [ANCP] Review of draft-ietf-ancp-mib-an-09.txt
"DE CNODDER, STEFAAN (STEFAAN)" <stefaan.de_cnodder@alcatel-lucent.com> Wed, 04 July 2012 07:31 UTC
Return-Path: <stefaan.de_cnodder@alcatel-lucent.com>
X-Original-To: ancp@ietfa.amsl.com
Delivered-To: ancp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix)
with ESMTP id 7A20F21F8746 for <ancp@ietfa.amsl.com>;
Wed, 4 Jul 2012 00:31:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.249
X-Spam-Level:
X-Spam-Status: No, score=-10.249 tagged_above=-999 required=5
tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com
[127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YmaU1-8gPFMZ for
<ancp@ietfa.amsl.com>; Wed, 4 Jul 2012 00:31:07 -0700 (PDT)
Received: from smail2.alcatel.fr (smail2.alcatel.fr [64.208.49.57]) by
ietfa.amsl.com (Postfix) with ESMTP id A070A21F872D for <ancp@ietf.org>;
Wed, 4 Jul 2012 00:31:07 -0700 (PDT)
Received: from FRMRSSXCHHUB03.dc-m.alcatel-lucent.com
(FRMRSSXCHHUB03.dc-m.alcatel-lucent.com [135.120.45.63]) by smail2.alcatel.fr
(8.14.3/8.14.3/ICT) with ESMTP id q647SwnW025509 (version=TLSv1/SSLv3
cipher=RC4-MD5 bits=128 verify=NOT); Wed, 4 Jul 2012 09:31:15 +0200
Received: from FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com ([135.120.45.41]) by
FRMRSSXCHHUB03.dc-m.alcatel-lucent.com ([135.120.45.63]) with mapi;
Wed, 4 Jul 2012 09:31:14 +0200
From: "DE CNODDER, STEFAAN (STEFAAN)" <stefaan.de_cnodder@alcatel-lucent.com>
To: Tom Taylor <tom.taylor.stds@gmail.com>, "ancp@ietf.org" <ancp@ietf.org>
Date: Wed, 4 Jul 2012 09:31:13 +0200
Thread-Topic: [ANCP] Review of draft-ietf-ancp-mib-an-09.txt
Thread-Index: Ac1WMyvrdsuSGTF4QWq19Z+5kB4yuADg8k5g
Message-ID: <05B6A5C4AE3BDA4EB276DB70EB548BA30362F5A6B0@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com>
References: <4FEE0B95.3090401@gmail.com>
In-Reply-To: <4FEE0B95.3090401@gmail.com>
Accept-Language: nl-NL, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: nl-NL, en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Scanned-By: MIMEDefang 2.69 on 155.132.188.80
Subject: Re: [ANCP] Review of draft-ietf-ancp-mib-an-09.txt
X-BeenThere: ancp@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Access Node Control Protocol working group mailing list
<ancp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ancp>,
<mailto:ancp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ancp>
List-Post: <mailto:ancp@ietf.org>
List-Help: <mailto:ancp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ancp>,
<mailto:ancp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 04 Jul 2012 07:31:08 -0000
Tom, It looks to me indeed worthwile to have some more detailed counters. I think adding 4 statistics for the adjacency messages (syn, synack, ack, rstack) is useful. For the AN, this means 8 counters: 4 for receiving syn, synack, ack, and restack, and 4 for sending syn, synack, ack, rstack. A failure could for instance also be that not nothing is received back from the NAS which can be derived from an increasing sent-syn counter but a recieved-synack counter remaining at zero. For other failures like in the ANCP request messages (Result field = 0x4), this looks more like more useful information on the NAS and not on the AN. It is the NAS that receives the response and RFC 6320 says it is the receiver of the response that should take action (section 3.6.1.3), so these counters should be on the NAS and not on the AN. Per-line results is also something on the NAS. If the NAS starts an OAM test, the result of that test should also be visible on the NAS and not on the AN. The same for the content of the Port Up messages. For line information, the AN has other MIBs (like XDSL MIBs) that shows the state of the lines. Capabilities can be added by other MIB documents. For instance, if someone writes a MIB module on multicast, a new object can be define with this capability. An alternative could be augmenting the current table with a new object that obsoletes the current object that sets the capability. regards, Stefaan -----Original Message----- From: ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] On Behalf Of Tom Taylor Sent: vrijdag 29 juni 2012 22:10 To: ancp@ietf.org Subject: [ANCP] Review of draft-ietf-ancp-mib-an-09.txt I reviewed this document. With the qualification that I have little MIB experience, it looks pretty good. I did wonder whether aggregate counts of failure responses should be broken out for debugging purposes, the idea being that a rising aggregate failure count might be a trigger for further investigation. Is there already a MIB to track per-line results? How do additional capabilities (e.g., the languishing-in-limbo multiplexing capabilities) get added? Tom Taylor _______________________________________________ ANCP mailing list ANCP@ietf.org https://www.ietf.org/mailman/listinfo/ancp
- [ANCP] Review of draft-ietf-ancp-mib-an-09.txt Tom Taylor
- Re: [ANCP] Review of draft-ietf-ancp-mib-an-09.txt DE CNODDER, STEFAAN (STEFAAN)