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

["Wojciech Dec (wdec)" <[e-mail]>]

Hi Folks,

Seems like there is alignment on all outstanding issues. If you could
publish a revised draft, we could proceed with the WG last call.

Regards,
Woj.

On 26/03/2013 12:15, "[e-mail]"
<[e-mail]> wrote:

>Hi Stefan,
>
>ok and I assume you add a reference to RFC 6320 in the object description
>to set the conditions for this state.
>
>Regards
>Markus
>
>
>-----Ursprüngliche Nachricht-----
>Von: DE CNODDER, STEFAAN (STEFAAN)
>[mailto:[e-mail]]
>Gesendet: Freitag, 22. März 2013 15:45
>An: Freudenberger, Markus
>Cc: [e-mail]
>Betreff: RE: [ANCP] I-D Action: draft-ietf-ancp-mib-an-10.txt
>
>
>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: [e-mail]
>[mailto:[e-mail]]
>Sent: vrijdag 22 maart 2013 11:47
>To: DE CNODDER, STEFAAN (STEFAAN)
>Cc: [e-mail]
>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:[e-mail]]
>Gesendet: Freitag, 22. März 2013 10:43
>An: Freudenberger, Markus
>Cc: [e-mail]
>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: [e-mail]
>[mailto:[e-mail]]
>Sent: donderdag 21 maart 2013 17:08
>To: DE CNODDER, STEFAAN (STEFAAN)
>Cc: [e-mail]
>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:[e-mail]]
>Gesendet: Donnerstag, 21. März 2013 10:49
>An: Freudenberger, Markus
>Cc: [e-mail]
>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: [e-mail]
>[mailto:[e-mail]]
>Sent: donderdag 21 maart 2013 8:48
>To: DE CNODDER, STEFAAN (STEFAAN)
>Cc: [e-mail]
>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: [e-mail]
>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:[e-mail]]
>Gesendet: Mittwoch, 20. März 2013 15:58
>An: Freudenberger, Markus
>Cc: [e-mail]
>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: [e-mail]
>[mailto:[e-mail]]
>Sent: woensdag 20 maart 2013 11:34
>To: DE CNODDER, STEFAAN (STEFAAN)
>Cc: [e-mail]
>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:[e-mail]]
>Gesendet: Mittwoch, 20. März 2013 10:11
>An: Freudenberger, Markus
>Cc: [e-mail]
>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: [e-mail] [mailto:[e-mail]] On Behalf Of
>[e-mail]
>Sent: dinsdag 19 maart 2013 13:23
>To: [e-mail]; [e-mail]
>Cc: [e-mail]
>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: [e-mail] [mailto:[e-mail]] Im Auftrag von
>[e-mail]
>Gesendet: Dienstag, 29. Januar 2013 09:06
>An: [e-mail]
>Cc: [e-mail]
>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
>[e-mail]
>https://www.ietf.org/mailman/listinfo/ancp
>_______________________________________________
>ANCP mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/ancp
>_______________________________________________
>ANCP mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/ancp