Subject: RE: Response to FSM input - Comments 1-10

From: "Sivananda Ramnath - CTD, Chennai." <[email-masked]>
Date: Fri, 6 Dec 2002 16:35:16 +0530

Hello,

Revised summary:

Comment 1 - No text change, Potential consensus
Comment 2a - No consensus
Comment 2b - No consensus
Comment 3 - New text suggested, no consensus
Comment 4 - Resolved, text changed. Can we consider this closed ?
Comment 5 - No text change, Potential consensus
Comment 6 - No consensus
Comment 7 - No consensus, comment re-phrased.
Comment 8 - No text change, potential consensus
Comment 9 - Resolved, text changed. Can we consider this closed ?
Comment 10 - Resolved, text changed. Can we consider this closed ?

> 
> Comment 1 - no consensus
> Comment 2a - out of date (No IdleHold Timer exists) 
> Comment 2b - no consensus, can't remove due to OpenSent state
> 		 action.
> 
> Comment 3 - no text proposed, do we want all options
> 		specified in 8.1 (7 options) 
> 		Please review and comment on text 
>  
> Comment 4 - agree
> Comment 5 - no text proposed, no consensus
> Comment 6 - no consensus on the text
> Comment 7 - see comment 3, no consensus
> Comment 8 - question, no text 
> Comment 9 - agree, I supplied text 
> Comment 10 - agree to remove text in option,
> 		 different text for definition.
> 
> 
> Sue Hares
> 
> ==========
> 
> comment 1: 
> 
> 1) removal of peer oscillation damping 
> 
> The reason we should not remove the peer oscillation damping
> from the state machine:
> 
>   1) Deployed implementations support peer oscillation damping 
>   2) Hooks for the additions in the FSM cannot be added later.
> 
> These hooks are optional and do not need to be implemented. 

  I understand. I am not trying to object to peer oscillation
  damping, I think it is a good idea and we have included it in
  our implementation as well. I was suggesting that instead of
  a partial description in this draft, it be completely described
  in the draft on peer oscillation damping.

  However, I do see your point, and unless there are any objections
  from others, I think we have consensus on this issue.

> 
>  
> 2) Idle HoldTimer in draft-18
> 
>   Perhaps this is an old comment.  I don't find IdleHoldTimer
>   in the messages.

    It is listed as Event 8. Perhaps this is what needs to be
    removed ?

> 
> 3) HoldTime and HoldTimer
> 
>    The Hold Time is specified on page 13 of the draft-18 specification
>    as to the value and size.  The text in OpenSent requires
>    both a HoldTime and HoldTimer value.
> ===========
>    OpenSent:
>    
>     In this state BGP waits for an Open Message from its peer.  
 [SNIP]
> ===================

  I understand. However, on this basis, we would also need a Keepalive
  time (since the basis on wihch this is be arrived at can be
  configurable). I don't know whether we do need to make such changes
  to the draft, and I am OK to leaving this portion as it stands.

> The earlier comments on the list indicated we need to collect what
> timers or Timer values were utilized in the FSM.  I believe Alex
> made this comment last January.  (the list archives will have
> this information.)
> 
> So, I don't see any way to

  The DelayBgpOpenTimer is missing from the session attributes list,
  how about including it ?

> 
> Comment 3: optional parameters specified
> 
> Please suggest text.  We have the following optional parameters:
> 
> 1) Delay Open
> 2) Accept unconfigured peers
> 3) automatic start [Event 3] 
> 4) passive TCP establishment (optional)
> 	4 + 5 = Event 5
> 5) BGP_stop_flap (BGP Peer oscillation) [Event 6] 
> 6)automatic stop [Event 7] 
> 7)Collision detect in Established State 
> 
> If you want some of the optional parameters specified, let's
> catch all.  Please suggest text and location.  It could
> go in 8.1.

  My view is this can be split into two categories:

  Optional attributes exist per session, and optional attributes
  for the entire system.

  How about adding the following to section 8 (immediately before 8.1)

%  Optional session attributes that a implementation may support
%  for a session are:
%
%    1) DelayOpen flag
%    2) DelayOpen Timer
%    3) Perform automatic start
%    4) Passive TCP establishment
%    5) Perform automatic stop
%    6) BGP Perform 
%
%
%  Implementations may also support the following optinal attributes
%  that modify the behavior of the state machine
%
%    1) Accept un-configured peers
%    2) Perform collision detect in Established state

    I guess it is possible to have some of these things listed under
    both categories. Am I opening up a can of worms here ?  :-)

> --------------------------------
> Comment 4
> 
> Old Text: 
>   Event 1: Manual Start
>       Definition: Administrator manually starts peer connection.
> 
>  ... 
>   Event 2: Manual Stop 
> 	 Definition: Local system administrator manually stops the 
> 		       peer connection. 
> New Text: 
>   Event1: Manual start
>        Definition: Local system administrator manually starts the
> 		       bgp connection.
> 
>   ... 
>   Event 2: Manual stop:
> 	  Definition: Local system administrator manually stops the 
> 			  bgp connection.
> 
> agree? 

  Agreed.

> ---------------
> Comment 5: 
> 
> 5) Event3, Event5, Event6 and Event7
> 
> 5a) 
> =========
>   Event 3/6/7 - cisco indicated the automatic stop, see the NANOG
> 		  archives for a discussion of the Bad Route
> 
>     http://www.merit.edu/mail.archives/nanog/2001-06/msg00805.html
> 
>   The "event" sequences are new with this version of the FSM
>   to identify particular events by number. 

    I am unclear on what this issue is!

> 5b
> ======
> 
>   Can we give examples of these events, as implemneted by curent
>   implementations ? This will be of help to new implementaions.
> 
>   An example of Auto Stop is already present in the Update event
>   handling section, and we can move that to this place as well.
> 
> I believe that examples are outside the scope of this specification.
> If you have text clarifying the event descriptions, please send it in.

  Well, the current text in the established state already gives an example
  for an automatic start event. I was suggesting that such examples be
  moved to the event description section.

  I also think adding text to clarify the intent behind optional events,
  and giving examples would help, especially for new implementors. However,
  if you feel this is outside the scope of the RFC, we can leave things
  as is.

> 
> 
> =======================================================
> 
> 6) Event 4,5 Definition
> 
> >	   Definition: Administrator manually start the peer
> >                       Connection, but has the passive flag=20
> >                       enabled.  The passive flag indicates=20
> >                       that the peer will listen prior to=20
> >                       establishing the connection.
> 
> 
> >	  Definition:  Local system automatically starts the
> >                       BGP session with the passive flag=20
> >                       enabled.  The passive flag indicates=20
> >                       that the peer will listen prior to=20
> >                       establishing a connection.
> 
> 
> >My understanding is this is used to indicate a peer configuration
> >where we start the state machine, and wait for an incoming connection
> >request from the configured peer. Can we re-phrase this section to
> >indicate this.
> 
> >How about something like:
> >
> >% The passive flag indicates that the state machine will wait for
> >% specified peer to initiate a connection with the local system. If
> >% this does not happen within a specific time (hold time), the local
> >% system will then also attempt to initiate connection with the
> >% specified peer.
> 
> The text in 8.2.1.1 indicates the definition of the passive flag. 

   Yes. 
> 
> 6a) 
> ==========
> My understanding of your text is that you want to replace in both
> sets of text: 
> 
> "The passive flag indicates the peer will listen prior to 
>  establishing a connection".  
> 
> with: 
> 
> "The passive flag indicates that the state machine will wait for the
> specified peer to initiate a connection with a local system.
> 
> The problem with this sentence is that in the "unconfigured" case
> the phrase "specified" peer is confusing.  I think the original text
> is clearer. 

  I am ok to leave the text as is, based on text in 8.2.1.1. However,
  I do not quite understand your point. In the case of an un-configured
  peer, the local system cannot 'establish a connection', so is the
  unconfigured peer case still valid in this context ?

> 6b)
> ==========
> If this does not happen within a specific time (hold time), the local
> system will then also attempt to initiate (a) connection with the
> specified peer.
> 
> My comments: Again, the "specified peer" term is confusing.  Also,
> the 2nd half of the statement mixes the actions of the state machine
> with the events.  I believe this muddies the text instead of
> clarifying it.

  Please refer to my comments for 6a.

  I think a reason for this is the requirement (in 8.2.1) that a FSM be
  established a-priori for "accepting each incoming TCP connection for
  which the peer has not beet identified".

  Is the intent to establish a FSM session for accepting TCP connections
  from un-configured peers ? If so, I am of the opinion that this is
  purely an implementation issue, and need not be a requirement in the spec.

>  
> =================
> Comment 7 -
> 
> Event 6 - (not specified, please confirm) 
> 
> >  Won't a variant of this with bgp_stop_flap option set be requried ?
> >  We can also achieve the same by using the bgp_stop-Flap option as a
> >  flag that is provided as an input to the state machine.
> 
> see comment number 3.  bgp_stop_flap is an option.  
> 
> This state machine description has many events to describe the
> mixture of options and actions.  I believe it has a better clarity
> than testing lots of flags within a state. 
> 
> A proof in case, is that many people are making comments about
> specific transitions. 

   I tink I should have phrased my question much better.

   We already have 
   Event 3 - Automatic Start
   Event 5 - Automatic start with bgp_stop_flap option set

   To make things consistent, shouldn't we either

   a) Add 3 new events : 1) Manual start with bgp_stop flap option set
                         2) Manual start with passive TCP establishment
                            and bgp_stop_flap option set
                         3) Automatic start with passive TCP establishment
                            and bgp_stop_flap option set

   or

   b) Remove Event 6, and rely on a flag to tell us wether peer flap damping
      is to be performed for the session or not.

> 
> ============
> Comment 8 - 
> 
> 
> 8) Event 5 Definition
> 
> >	  Definition:  Local system automatically starts the
> >                       BGP session with the passive flag=20
> >                       enabled.  The passive flag indicates=20
> >                       that the peer will listen prior to=20
> >                       establishing a connection.
> 
> > Is it correct that this event will occur only when we want 
> to restart
> > a connection (after it had been terminated due to some reason beside
> > administrative action) that we had accepted from an 
> unconfigured peer ?
> 
> The automatic start function is an implementation specific mechanism.
> This text does not seek to restrict it in any fashion.

  Well, for new implementors, such clarifications will help undertsand
  how to generate and make use of this event. Again, I am OK with
  leaving text as is.

> 
> ================
> 9) Timer Events Definition
> 
> > Event8:  idle Hold timer expires=20
> >
> >           Definition: Idle Hold timer expires.  The Idle=20
> >
> > Event9: connect retry timer expires
> >
> >           Definition: An event triggered by the expiration of=20
> > Event10: hold time expires
> >
> >	   Definition: An event generated when the HoldTimer=20
> 
> We can use any one of these terms (trigerred by/generated 
> when) for all
> timer event definitions to make it look more consistent.
> 
> agree: Will use "generate" 
> 
> Event 8: An event generated when the Idle Hold timer expires.
> Event 9: An event generated when the ConnectRetry timer expires.
> Event 10: An event generated when the Hold timer expires.  
> Event 11: An event generated when the Keepalive timer expires
> Event 12: An event generated when the Delay BGP Open timer expires.
> 
> Please confirm that this change to the definitions is agreeable to
> you.

  Agreed.
  I think we have consensus on this issue, unless anyone else
  has any comments on this.

> 
> ================
> 10) Event 8 Definition
> 
> > Event8:  idle Hold timer expires=20
> >
> >           Definition: Idle Hold timer expires.  The Idle=20
> >                       Hold Timer is only used when persistent =20
> >                       BGP oscillation damping functions are=20
> >                       enabled. =20
> >
> >           Status: 	Optional.  Used when persistent
> >			BGP peer oscillation damping functions
> >			are enabled.=20
> 
> 
> The status repeats the senetnce in the definition. Can we remove the
> sentence from the Status, or replace with a different definition.
> 
> Do you think the defenition below would fit ?
> 
> % An event trigerred by the expiry of the Idle Hold timer, indicating
> % that the session has completed waiting for a back-off period to
> % prevent flap, and may now proceed to take any further systemm
> % initiated action for this session. 
> 
> text change suggestion for 1st sentence that I'll agree to.
> 
>  An event trigerred by the expiry of the Idle Hold timer, indicating
>  that the session has completed waiting for a back-off period to
>  prevent bgp peer oscillation.
> 
> Please confirm that you will agree to this.

  Agreed.
  I think we have consensus on this issue, unless anyone else
  has any comments on this.

Siva
([email-masked])> 

Original text of comments 1-10 follow:

> 
> ------- Message 4
> 
> Date:    Fri, 29 Nov 2002 19:46:06 +0530
> From:    "Sivananda Ramnath - CTD, Chennai." <[email-masked]>
> To:      [email-masked], Yakov Rekhter <[email-masked]>
> cc:      [email-masked]
> Subject: Comments on draft 18
> 
> This message is in MIME format. Since your mail reader does 
> not understand
> this format, some or all of this message may not be legible.
> 
> - ------_=_NextPart_000_01C297B1.DB0F1700
> Content-Type: text/plain;
> 	charset="iso-8859-1"
> 
> Hello,
> 
>     Attached are some comments that I have on draft-ietf-idr-bgp4-18.
> 
>     Please have a look at these and tell me if the same can 
> be raised to the
> mailing list as well.
> 
> Thanks,
> Siva
> ([email-masked])
>   
> 
> 
> - ------_=_NextPart_000_01C297B1.DB0F1700
> Content-Type: text/plain;
> 	name="BGP_Issues.txt"
> Content-Transfer-Encoding: quoted-printable
> Content-Disposition: attachment;
> 	filename="BGP_Issues.txt"
> 
> All quoted sections of the original document have been 
> prefixed by a '> =
> '
> All lines of proposed text have been prefixed by a '% '
> 
> 
> 1) Performing of peer oscillation damping:
> 
> Since this feature is going to be added in a new draft, and its
> addition will change the operation of the state machine, can we remove
> all mention of it in the state machine ? As part of this removal, can
> we also remove the IdleHold Timer from the FSM since it is not useful
> in the absence of peer oscillation damping ?
> 
> The draft that describes this procedure can then describe the change
> in the state machine required to do this.
> 
> 
> 2) Session Attributes:
> 
> > Session Attributes required for each connection are;=20
> 
> >   1) state
> >   2) Connect Retry timer
> >   3) Hold timer
> >   4) Hold time
> >   5) Keepalive timer
> 
> Why have a Hold Timer and a Hold Time ? Can we replace this with just
> Hold timer ?
> 
> Can we also add the following session attributes:
> 
> a) DelayBgpOpenTimer
> b) IdleHold Timer (in case we choose not to remove this from the bas =
> FSM)
> 
> Can we also add the following flag to the session attributes:
> a) DelayOpen Flag
> 
> 
> 3) All sessions attributes:
> 
>   There are some attributes that are common to all sessions of the =
> system.
>   Can we call these out as well:
> 
>   * Accept Connections from unconfigured peers (Enabled/Disabled)
>   * Peer Oscillation Dampening (Enabled/Disabled) (In case we choose
>     not to remove it from base spec)
> 
> 
> 4) Description for Event1/Event2
> 
> > Event1: Manual start=20
> >
> >	   Definition: Administrator manually starts peer
> >                       connection
> 
> > Event2: Manual stop
> 
> >	   Definition: Local system administrator manually=20
> >                       stops the peer connection.
> 
> We can make these look consistent by using the Term Administrator or
> Local System administrator in both cases.
> 
> 
> 5) Event3, Event5, Event6 and Event7
> 
>   Can we give examples of these events, as implemneted by curent
>   implementations ? This will be of help to new implementaions.
> 
>   An example of Auto Stop is already present in the Update event
>   handling section, and we can move that to this place as well.
> 
> 
> 6) Event 4,5 Definition
> 
> >	   Definition: Administrator manually start the peer
> >                       Connection, but has the passive flag=20
> >                       enabled.  The passive flag indicates=20
> >                       that the peer will listen prior to=20
> >                       establishing the connection.
> 
> 
> >	  Definition:  Local system automatically starts the
> >                       BGP session with the passive flag=20
> >                       enabled.  The passive flag indicates=20
> >                       that the peer will listen prior to=20
> >                       establishing a connection.
> 
> 
> My understanding is this is used to indicate a peer configuration
> where we start the state machine, and wait for an incoming connection
> request from the configured peer. Can we re-phrase this section to
> indicate this.
> 
> How about something like:
> 
> % The passive flag indicates that the state machine will wait for
> % specified peer to initiate a connection with the local system. If
> % this does not happen within a specific time (hold time), the local
> % system will then also attempt to initiate connection with the
> % specified peer.
> 
> 
> 7) Event 4,5
> 
>   Won't a variant of this with bgp_stop_flap option set be requried ?
>   We can also achieve the same by using the bgp_stop-Flap option as a
>   flag that is provided as an input to the state machine.
> 
> 
> 8) Event 5 Definition
> 
> >	  Definition:  Local system automatically starts the
> >                       BGP session with the passive flag=20
> >                       enabled.  The passive flag indicates=20
> >                       that the peer will listen prior to=20
> >                       establishing a connection.
> 
> Is it correct that this event will occur only when we want to restart
> a connection (after it had been terminated due to some reason beside
> administrative action) that we had accepted from an 
> unconfigured peer ?
> 
> 
> 9) Timer Events Definition
> 
> > Event8:  idle Hold timer expires=20
> >
> >           Definition: Idle Hold timer expires.  The Idle=20
> >
> > Event9: connect retry timer expires
> >
> >           Definition: An event triggered by the expiration of=20
> > Event10: hold time expires
> >
> >	   Definition: An event generated when the HoldTimer=20
> 
> We can use any one of these terms (trigerred by/generated 
> when) for all
> timer event definitions to make it look more consistent.
> 
> 
> 
> 10) Event 8 Definition
> 
> > Event8:  idle Hold timer expires=20
> >
> >           Definition: Idle Hold timer expires.  The Idle=20
> >                       Hold Timer is only used when persistent =20
> >                       BGP oscillation damping functions are=20
> >                       enabled. =20
> >
> >           Status: 	Optional.  Used when persistent
> >			BGP peer oscillation damping functions
> >			are enabled.=20
> 
> 
> The status repeats the senetnce in the definition. Can we remove the
> sentence from the Status, or replace with a different definition.
> 
> Do you think the defenition below would fit ?
> 
> % An event trigerred by the expiry of the Idle Hold timer, indicating
> % that the session has completed waiting for a back-off period to
> % prevent flap, and may now proceed to take any further systemm
> % initiated action for this session.
> 
> 
> --

---

From: "Susan Hares" <[email-masked]>
Date: Mon, 9 Dec 2002 16:45:02 -0500

Siva:

Thanks for such a quick turn around.

So.. our summary is

1 - consensus, no text change
2 - no consensus, see text change 
3 - mostly consensus,
	Policy in implementations may dictate some options
      per peer and some options per implementation. I 
	suggest we specify the list you came up with plus
	Idle Hold Timer in 8.0.

4 - consensus, text change [done]  
5 - no consensus, see comment below
	5a - answer question [no text intended]
	5b.1 - text proposed 
	5b.2 - your text or mine?

6 - consensus on text, answer given below
7 - no consensus, text proposal below

	2 of the 3 events could be considered infeasible.
	The 3rd event all add.  Please review the text.

8 - consensus, no text change  
9 - consensus, text change [done] 
10 - consensus, text changed [done] 

	Note 9 + 10 are taken together 

Comments to resolve: 2,3, 5, 7, 

Thanks for the quick response.

Sue Hares

=====================

Comment 2 -

    Event8: Idle hold timer expires 
   
           Definition: An Event generated when the Idle Hold Timer
		           expires.  The Idle Hold Timer is only used
                       when the persistent peer oscillation
                       damping function is enabled.
%
%			     Implementations not implemented persistent
% 			     peer oscillations damping functions may not
%  			     have the Idle Hold Timer. 

Is this approach ok? 
============

Comment 3

The following will be added to 8.0

Optional parameters that may be supported either per
connection or per implementation: 

1) Delay Open flag 
2) Delay Open Timer
3) Perform automatic start flag 
4) Passive TCP establishment flag 
5) BGP stop_peer_flag flag 
%6) Idle Hold timer 
7) Perform automatic stop flag  
8) Perform Collision detect in Establish mode flag 

=====================
Comment 4: consensus, change made to Event 1 and 2

===============
Comment 5:

5a:
Automatic stop and stop are implemented by cisco's policy
engine.  The origination of the damping peer oscillation was
in result to a bug that was listed in comment 5.

5b:

 1.) Example of "automatic disconnect" in Established state

  Is the text you wanted moved: 
    An example automatic stop event is exceeding the number of 
    prefixes for a given peer and the local system 
    automatically disconnecting the peer.
   
  If so, I can move this to the automatic stop event

 2.) Text describing the optional parameters.

	We can add text for the optional parameters to 
	describe their function.  Can you propose some text?
======================
Comment 6

>  unconfigured peer case still valid in this context ?

Unconfigured + passive TCP connection + Delay Open is valid.

============================================
Comment 7

>                            and bgp_stop_flap option set

I like option A, it is clearer.   

The Manual start or stop terminates the bgp peer oscillation damping. 
The theory is the operator "did" something, therefore the events need to
chagne.  Since these events do not have valid implementation in the
peer flap damping, I did not include them.   

#3 is something I missed.  I will add that event.  Is that resolution OK, or
I can put all 3 new events in. 

=========================

-----Original Message-----
From: Sivananda Ramnath - CTD, Chennai. [mailto:[email-masked]]
Sent: Friday, December 06, 2002 6:05 AM
To: Susan Hares; Yakov Rekhter; Jeffrey Haas
Cc: [email-masked]; Sivananda Ramnath (E-mail); Venu Kumar G - CTD,
Chennai.
Subject: RE: Response to FSM input - Comments 1-10

Hello,

Revised summary:

 [SNIP]

  Agreed.

   Yes. 

   We already have 

   or

  Agreed.

  Agreed.

Siva
([email-masked])>

---

From: "Tom Petch" <[email-masked]>
Date: Fri, 13 Dec 2002 21:49:56 -0000

Sue, Siva

Please can we stay with the terms

Open Delay timer
peer oscillation damping

in any new text (as previously agreed on the list).

There are some new variations confusing their way into the text you
are suggesting below.

Tom Petch
[email-masked]

-----Original Message-----
From: Susan Hares <[email-masked]>
To: Sivananda Ramnath - CTD, Chennai. <[email-masked]>; Yakov
Rekhter <[email-masked]>; Jeffrey Haas <[email-masked]>
Cc: [email-masked] <[email-masked]>; Venu Kumar G - CTD, Chennai.
<[email-masked]>
Date: 09 December 2002 21:46
Subject: RE: Response to FSM input - Comments 1-10

Siva:

So.. our summary is

Sue Hares

=====================

Comment 2 -

Is this approach ok?
============

Comment 3

1) Delay Open flag
2) Delay Open Timer

=====================

===============
Comment 5:

5a:

5b:

The Manual start or stop terminates the bgp peer oscillation damping.
The theory is the operator "did" something, therefore the events need
to
chagne.  Since these events do not have valid implementation in the
peer flap damping, I did not include them.

#3 is something I missed.  I will add that event.  Is that resolution
OK, or
I can put all 3 new events in.

-----Original Message-----
From: Sivananda Ramnath - CTD, Chennai. [mailto:[email-masked]]
Sent: Friday, December 06, 2002 6:05 AM
To: Susan Hares; Yakov Rekhter; Jeffrey Haas
Cc: [email-masked]; Sivananda Ramnath (E-mail); Venu Kumar G - CTD,
Chennai.

Hello,

Revised summary:

[SNIP]

  Agreed.

> If you have text clarifying the event descriptions, please send it
in.

  Well, the current text in the established state already gives an
example
  for an automatic start event. I was suggesting that such examples be
  moved to the event description section.

  I also think adding text to clarify the intent behind optional
events,
  and giving examples would help, especially for new implementors.
However,
  if you feel this is outside the scope of the RFC, we can leave
things
  as is.

   Yes.

  I am ok to leave the text as is, based on text in 8.2.1.1. However,
  I do not quite understand your point. In the case of an
un-configured
  peer, the local system cannot 'establish a connection', so is the
  unconfigured peer case still valid in this context ?

  I think a reason for this is the requirement (in 8.2.1) that a FSM
be
  established a-priori for "accepting each incoming TCP connection for
  which the peer has not beet identified".

  Is the intent to establish a FSM session for accepting TCP
connections
  from un-configured peers ? If so, I am of the opinion that this is
  purely an implementation issue, and need not be a requirement in the
spec.

   We already have

   a) Add 3 new events : 1) Manual start with bgp_stop flap option set
                         2) Manual start with passive TCP
establishment
                            and bgp_stop_flap option set
                         3) Automatic start with passive TCP
establishment
                            and bgp_stop_flap option set

   or

   b) Remove Event 6, and rely on a flag to tell us wether peer flap
damping
      is to be performed for the session or not.

  Agreed.

  Agreed.

Siva
([email-masked])>