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

"DE CNODDER, STEFAAN (STEFAAN)" <stefaan.de_cnodder@alcatel-lucent.com> Fri, 22 March 2013 14:45 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 ACA7121F8BA1 for <ancp@ietfa.amsl.com>; Fri, 22 Mar 2013 07:45:13 -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 Q24LiUvjzFTX for <ancp@ietfa.amsl.com>; Fri, 22 Mar 2013 07:45:12 -0700 (PDT)
Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id 8ED8F21F8B9C for <ancp@ietf.org>; Fri, 22 Mar 2013 07:45:12 -0700 (PDT)
Received: from us70tusmtp2.zam.alcatel-lucent.com (h135-5-2-64.lucent.com [135.5.2.64]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id r2MEj9hj015355 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 22 Mar 2013 09:45:10 -0500 (CDT)
Received: from US70UWXCHHUB02.zam.alcatel-lucent.com (us70uwxchhub02.zam.alcatel-lucent.com [135.5.2.49]) by us70tusmtp2.zam.alcatel-lucent.com (GMO) with ESMTP id r2MEixou030011 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 22 Mar 2013 10:45:09 -0400
Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (135.239.2.74) by US70UWXCHHUB02.zam.alcatel-lucent.com (135.5.2.49) with Microsoft SMTP Server (TLS) id 14.2.247.3; Fri, 22 Mar 2013 10:45:06 -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; Fri, 22 Mar 2013 15:44:45 +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: Ac3994ALXxPI3j1iRlCXYKeYEtRCTQmoGIbgACxpGOAAALGXEAALgfwwAAFZLlAAIdldIAAEMolwAA0AuuAAJSCgAAACS1pAAAhi9vA=
Date: Fri, 22 Mar 2013 14:44:45 +0000
Message-ID: <5F657CFC59E51E4B842F0D51C19AC36C02903F@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> <5F657CFC59E51E4B842F0D51C19AC36C0286F9@FR711WXCHMBA06.zeu.alcatel-lucent.com> <F51C24472ABFED4AA5FE7C5F7EF98E100C1891B250@HE113484.emea1.cds.t-internal.com> <5F657CFC59E51E4B842F0D51C19AC36C028D2A@FR711WXCHMBA06.zeu.alcatel-lucent.com> <F51C24472ABFED4AA5FE7C5F7EF98E100C1891B7BD@HE113484.emea1.cds.t-internal.com>
In-Reply-To: <F51C24472ABFED4AA5FE7C5F7EF98E100C1891B7BD@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.40]
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.33
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: Fri, 22 Mar 2013 14:45:13 -0000

Hi Markus,

Yes, it looks we are in agreement.  So this object:

ancpAnCurrentSessionState OBJECT-TYPE
       SYNTAX     INTEGER {
                      other(1),
                      synsent(2),
                      synrcvd(3),
                      estab(4)
                  }

becomes

ancpAnCurrentSessionState OBJECT-TYPE
       SYNTAX     INTEGER {
                      other(1),
                      synsent(2),
                      synrcvd(3),
                      estab(4),
                      loss_sync(5)
                  }

regards,
Stefaan


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

Hi Stefaan,

this might be one scenario. Antoher one might be:
 
1) ancpAnCurrentSessionState = estab
2) One of the conditions in 3.5.2.7 happens => ancpAnCurrentSessionState = loss sync (+send RSTACK)
3) SYN message not received because at the peer because the phyical connection betweeen both peers is broken for one hour => ancpAnCurrentSessionState = los sync for one hour.
4) Connection is back again after one hour
5) SYN message received => ancpAnCurrentSessionState = synrcvd
6) rest of adjacency negotiation 
7) ancpAnCurrentSessionState = estab

Here, the loss of sync state is not a short transient state, right?

Regards
Markus



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

Hi Markus,

Do you propose to have an extra value for ancpAnCurrentSessionState to indicate when there is loss of synchronization?

So we could have following scenario:

1) ancpAnCurrentSessionState = estab
2) one of the conditions in 3.5.2.7 happens => ancpAnCurrentSessionState = loss sync (+send RSTACK)
3) SYN message received => ancpAnCurrentSessionState = synrcvd
4) rest of adjacency negotiation

The loss sync state will be a short transient state, but it makes sense to me, if at least this is what you propose.  Also the above scenario will generate the ancpAnSessionDown.

regards,
Stefaan



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

Hi Stefaan,

even the state change from estab to synsent resp. synrcvd as a trigger for the SessionDown trap seems for me to be wrong. 
One summarized status like e. g. down in the MIB, following the definition in RFC 6320 chapter 3.5.2.7, may be more appropriate.

Regards
Markus


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

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