Re: [ANCP] I-D Action: draft-ietf-ancp-mib-an-10.txt

"DE CNODDER, STEFAAN (STEFAAN)" <stefaan.de_cnodder@alcatel-lucent.com> Thu, 21 March 2013 09:48 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 9E43421F8574 for <ancp@ietfa.amsl.com>; Thu, 21 Mar 2013 02:48:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Level:
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 VXhCnjUkIIDM for <ancp@ietfa.amsl.com>; Thu, 21 Mar 2013 02:48:47 -0700 (PDT)
Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by ietfa.amsl.com (Postfix) with ESMTP id B72A621F8556 for <ancp@ietf.org>; Thu, 21 Mar 2013 02:48:47 -0700 (PDT)
Received: from us70tusmtp2.zam.alcatel-lucent.com (h135-5-2-64.lucent.com [135.5.2.64]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id r2L9mjHK027673 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 21 Mar 2013 04:48:46 -0500 (CDT)
Received: from US70TWXCHHUB04.zam.alcatel-lucent.com (us70twxchhub04.zam.alcatel-lucent.com [135.5.2.36]) by us70tusmtp2.zam.alcatel-lucent.com (GMO) with ESMTP id r2L9mgF5018552 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 21 Mar 2013 05:48:45 -0400
Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (135.239.2.74) by US70TWXCHHUB04.zam.alcatel-lucent.com (135.5.2.36) with Microsoft SMTP Server (TLS) id 14.2.247.3; Thu, 21 Mar 2013 05:48:43 -0400
Received: from FR711WXCHMBA06.zeu.alcatel-lucent.com ([169.254.2.68]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.02.0247.003; Thu, 21 Mar 2013 10:48:41 +0100
From: "DE CNODDER, STEFAAN (STEFAAN)" <stefaan.de_cnodder@alcatel-lucent.com>
To: "Markus.Freudenberger@t-systems.com" <Markus.Freudenberger@t-systems.com>
Thread-Topic: [ANCP] I-D Action: draft-ietf-ancp-mib-an-10.txt
Thread-Index: Ac3994ALXxPI3j1iRlCXYKeYEtRCTQmoGIbgACxpGOAAALGXEAALgfwwAAFZLlAAIdldIAAEMolw
Date: Thu, 21 Mar 2013 09:48:41 +0000
Message-ID: <5F657CFC59E51E4B842F0D51C19AC36C0286F9@FR711WXCHMBA06.zeu.alcatel-lucent.com>
References: <20130129080601.7204.88535.idtracker@ietfa.amsl.com> <F51C24472ABFED4AA5FE7C5F7EF98E100C1882765E@HE113484.emea1.cds.t-internal.com> <5F657CFC59E51E4B842F0D51C19AC36C028045@FR711WXCHMBA06.zeu.alcatel-lucent.com> <F51C24472ABFED4AA5FE7C5F7EF98E100C1888E102@HE113484.emea1.cds.t-internal.com> <5F657CFC59E51E4B842F0D51C19AC36C028377@FR711WXCHMBA06.zeu.alcatel-lucent.com> <F51C24472ABFED4AA5FE7C5F7EF98E100C1888E828@HE113484.emea1.cds.t-internal.com>
In-Reply-To: <F51C24472ABFED4AA5FE7C5F7EF98E100C1888E828@HE113484.emea1.cds.t-internal.com>
Accept-Language: nl-BE, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [135.239.27.38]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35
Cc: "ancp@ietf.org" <ancp@ietf.org>
Subject: Re: [ANCP] I-D Action: draft-ietf-ancp-mib-an-10.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: Thu, 21 Mar 2013 09:48:51 -0000

Hi Markus,

Is your question on when the object ancpAnCurrentSessionState has value "other(1)"?  It is when the conditions on the other 3 values (synsent, synrcvd, estab) are not true (as described in the description of the object).  Example: suppose the AN sends a syn (state is synsent), then TCP connection goes down.  Some implementations might keep the synsent state, others might re-initialise and go to other state.  Listing all these cases in dedicated states would probably never be complete, that's why it is "other".

regards,
Stefaan


-----Original Message-----
From: Markus.Freudenberger@t-systems.com [mailto:Markus.Freudenberger@t-systems.com] 
Sent: donderdag 21 maart 2013 8:48
To: DE CNODDER, STEFAAN (STEFAAN)
Cc: ancp@ietf.org
Subject: AW: [ANCP] I-D Action: draft-ietf-ancp-mib-an-10.txt

Hi Stefaan,

regarding issue 1:
I just recognized that ancpAnSessionConfigSessionId is already implicitely contained in the trap as all objects in the trap are indexed by it. So, there was no need to defend the draft :o)

Regards
Markus


-----Ursprüngliche Nachricht-----
Von: Freudenberger, Markus 
Gesendet: Mittwoch, 20. März 2013 16:45
An: 'DE CNODDER, STEFAAN (STEFAAN)'
Cc: ancp@ietf.org
Betreff: AW: [ANCP] I-D Action: draft-ietf-ancp-mib-an-10.txt

Hi Stefaan,

thanks for your comments.
1. 
My prososal is still to add ancpAnSessionConfigSessionId into the trap as this as this is the clear reference to both tables ancpAnSessionConfigTable and ancpAnCurrentSessionTable. The most practical situation in operation is a loss of adjacency and not a deletion of the ancp session.

2. 
I am not confused about your wording. The point ist that the conditions for the state "other" is not clear to me. What does it mean?

Regards
Markus


-----Ursprüngliche Nachricht-----
Von: DE CNODDER, STEFAAN (STEFAAN) [mailto:stefaan.de_cnodder@alcatel-lucent.com]
Gesendet: Mittwoch, 20. März 2013 15:58
An: Freudenberger, Markus
Cc: ancp@ietf.org
Betreff: RE: [ANCP] I-D Action: draft-ietf-ancp-mib-an-10.txt

Hi Markus,

The reason why the SessionDown trap has so many objects in it, is because the row might be deleted, and then all information about the session should be in the trap.  The value of ancpAnSessionConfigSessionId only makes sense if the row is still present in the table.  The value of the other objects in trap still have a meaning even if the row is deleted.

I think you are confused by a bad wording I used below.  One of the conditions of a session being down is that the session is in another state than estab.  The state estab as in ancpAnCurrentSessionState.  This means that when ancpAnCurrentSessionState is equal to other(1), synsent(2), or synrcvd(3), then the session is down.

regards,
Stefaan


-----Original Message-----
From: Markus.Freudenberger@t-systems.com [mailto:Markus.Freudenberger@t-systems.com]
Sent: woensdag 20 maart 2013 11:34
To: DE CNODDER, STEFAAN (STEFAAN)
Cc: ancp@ietf.org
Subject: AW: [ANCP] I-D Action: draft-ietf-ancp-mib-an-10.txt

Hi Stefaan,

see inline.

Regards
Markus


-----Ursprüngliche Nachricht-----
Von: DE CNODDER, STEFAAN (STEFAAN) [mailto:stefaan.de_cnodder@alcatel-lucent.com]
Gesendet: Mittwoch, 20. März 2013 10:11
An: Freudenberger, Markus
Cc: ancp@ietf.org
Betreff: RE: [ANCP] I-D Action: draft-ietf-ancp-mib-an-10.txt

Hi Markus,

Thanks for the feedback.  For issue 1, the trap could be generated because the row is deleted from both tables.  This means that the ancpAnSessionConfigSessionId in the trap has in this case no relevant information, and might point to a wrong or non-existing entry in the table.  So I am not sure if adding this to the trap is good.
MF: Ok but the same would then also happen with the other objects in the trap as they are referenced then also by an non-exisiting table entry. However, the agent implementation in the AN must ensure the information to be delivered in the trap.

For issue 2, the state "down" is actually detailed in the next sentences: it can be down because the session is deleted, or the session is a state other than the estab state.  The estab state you find back in ancpAnCurrentSessionState.
MF: Ok but the status "other(1)" can mean anything. It is not defined that this necessarily only mean that the session is down.

regards,
Stefaan


-----Original Message-----
From: ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] On Behalf Of Markus.Freudenberger@t-systems.com
Sent: dinsdag 19 maart 2013 13:23
To: internet-drafts@ietf.org; i-d-announce@ietf.org
Cc: ancp@ietf.org
Subject: Re: [ANCP] I-D Action: draft-ietf-ancp-mib-an-10.txt

Hi all,

Issue 1:
there are two objects for identifying an ancp sessions in the access node.    
1. ancpAnSessionConfigSessionId
2. ancpAnCurrentSessionAnInstance
The first one identifies rows in the ancpAnSessionConfigTable and in the ancpAnCurrentSessionTable wehreas the second one is a number from ANCP Adjacency Message itself and is an attribute in the ancpAnCurrentSessionTable.

Proposal:
Add the attribute ancpAnSessionConfigSessionId as a varbind in the ancpSessionUp/ancpSessionDown traps as this is the clear reference to both tables ancpAnSessionConfigTable and ancpAnCurrentSessionTable. 

Issue 2:
The definition of the ancpSessionDown trap says: "This notification is generated whenever an ANCP session goes down." bute the state 'down' is not explicitely defined in the status attribute "ancpAnCurrentSessionState" which triggers the generation of the trap.

Proposal:
Define the state 'down' in the attribute ancpAnCurrentSessionState or make the relation from the different states in the ancpAnCurrentSessionState to the phrase 'down' resp. 'operational down' more clear in the description of the ancpSessionDown trap.

Thanks and regards
Markus


-----Ursprüngliche Nachricht-----
Von: ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] Im Auftrag von internet-drafts@ietf.org
Gesendet: Dienstag, 29. Januar 2013 09:06
An: i-d-announce@ietf.org
Cc: ancp@ietf.org
Betreff: [ANCP] I-D Action: draft-ietf-ancp-mib-an-10.txt


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           : Access Node Control Protocol (ANCP) MIB module for Access Nodes
	Author(s)       : Stefaan De Cnodder
                          Moti Morgenstern
	Filename        : draft-ietf-ancp-mib-an-10.txt
	Pages           : 39
	Date            : 2013-01-29

Abstract:
   This memo defines a portion of the Management Information Base (MIB)
   for use with network management protocols.  In particular it defines
   objects for managing access nodes that are using the Access Node
   Control Protocol (ANCP).


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-ancp-mib-an

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-ancp-mib-an-10

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-ancp-mib-an-10


Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

_______________________________________________
ANCP mailing list
ANCP@ietf.org
https://www.ietf.org/mailman/listinfo/ancp
_______________________________________________
ANCP mailing list
ANCP@ietf.org
https://www.ietf.org/mailman/listinfo/ancp