From stefaan.de_cnodder@alcatel-lucent.com Wed Jul 4 00:31:08 2012 Return-Path: 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 ; 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 ; 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 ; 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)" To: Tom Taylor , "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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 thi= nk 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 re= stack, and 4 for sending syn, synack, ack, rstack. A failure could for ins= tance also be that not nothing is received back from the NAS which can be d= erived from an increasing sent-syn counter but a recieved-synack counter re= maining at zero. For other failures like in the ANCP request messages (Result field =3D 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 rec= eiver of the response that should take action (section 3.6.1.3), so these c= ounters 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 te= st, the result of that test should also be visible on the NAS and not on th= e AN. The same for the content of the Port Up messages. For line informat= ion, the AN has other MIBs (like XDSL MIBs) that shows the state of the lin= es. 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 cap= ability. An alternative could be augmenting the current table with a new o= bject 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=20 experience, it looks pretty good. I did wonder whether aggregate counts=20 of failure responses should be broken out for debugging purposes, the=20 idea being that a rising aggregate failure count might be a trigger for=20 further investigation. Is there already a MIB to track per-line results? How do additional capabilities (e.g., the languishing-in-limbo=20 multiplexing capabilities) get added? Tom Taylor _______________________________________________ ANCP mailing list ANCP@ietf.org https://www.ietf.org/mailman/listinfo/ancp From Internet-Drafts@ietf.org Mon Jul 16 16:53:29 2012 Return-Path: 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 A24D411E80BD; Mon, 16 Jul 2012 16:53:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.525 X-Spam-Level: X-Spam-Status: No, score=-102.525 tagged_above=-999 required=5 tests=[AWL=0.074, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 fTNxszuj0DKK; Mon, 16 Jul 2012 16:53:29 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C49311E82E6; Mon, 16 Jul 2012 16:53:29 -0700 (PDT) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.30p3 Message-ID: <20120716235329.13526.38690.idtracker@ietfa.amsl.com> Date: Mon, 16 Jul 2012 16:53:29 -0700 Cc: ancp@ietf.org Subject: [ANCP] I-D ACTION:draft-ietf-ancp-pon-03.txt X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jul 2012 23:53:29 -0000 --NextPart A new Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Access Node Control Protocol Working Group of the IETF. Title : Applicability of Access Node Control Mechanism to PON based Broadband Networks Author(s) : N. Bitar, et al Filename : draft-ietf-ancp-pon Pages : 42 Date : July 16, 2012 The purpose of this document is to provide applicability of the Access Node Control mechanism to PON-based broadband access. The need for an Access Node Control mechanism between a Network Access Server (NAS) and an Access Node Complex (a combination of Optical Line Termination (OLT) and Optical Network Termination (ONT) elements) is described in a multi-service reference architecture in order to perform QoS-related, service-related and Subscriber-related operations. The Access Node Control mechanism is also extended for interaction between components of the Access Node Complex (OLT and ONT). The Access Node Control mechanism will ensure that the transmission of information between the NAS and Access Node Complex (ANX) and between the OLT and ONT within an ANX does not need to go through distinct element managers but rather uses a direct device-to-device communication and stays on net. This allows for performing access link related operations within those network elements to meet performance objectives. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ancp-pon-03.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-ancp-pon"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2012-07-16165329.I-D@ietf.org> --NextPart--