Subject: [NSIS] question on 5.3.3

From: "Gary Kenward"<[email-masked]>
Date: Wed, 3 Apr 2002 15:01:38 -0500

Hello:

I have a question regarding one of the requirements:

5.3.3 Possibility for automatic release of resources after failure

   When the QoS Initiator goes down, the resources it requested should
   be released, since they will no longer be necessary.

This does not seem to me to be a protocol requirement nor a framework
requirement, but rather an implementation requirement. 

Does this matter?

Thanks,
Gary

_______________________________________________
nsis mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nsis

---

From: "Gary Kenward"<[email-masked]>
Date: Wed, 3 Apr 2002 15:34:07 -0500

Marco:

  I fully agree that resource allocations need to have the option for
finite life times. 

  However, I am unclear as to how 1) versus 2) would change the semantics 
of the protocol? As opposed to the semantics of resource reservation
algorithms
at a given node?

  To state this in another fashion, if I attached a protocol
analyzer to a link carrying NSIS, what protocol semantics could
I capture that would reflect this resource timing?

Gary

> -----Original Message-----
> From: Schneider, Marco [mailto:[email-masked]]
> Sent: April 3, 2002 15:22
> To: Kenward, Gary [WDLN2:AN10:EXCH]; 'NSIS'
> Subject: RE: [NSIS] question on 5.3.3
> Sensitivity: Confidential
> 
> 
> To me this is part of the semantics of the protocol. My 
> requirement is that
> the protocol support the following two behaviours:
> 
> 1) When the QOS Initiator goes down, the resources it 
> requested will be
> released
> 2) When the QOS Initiator goes down, the resources it 
> requested will not be
> released
> 
> The reason for supporting behaviour #2 is the case where an 
> entity in the
> network proxy signals on behalf of a large number of 
> customers. We want the
> ability for the corresponding connections to stay up should a 
> controller
> fail. For policy reasons we may want to require that behaviour #1 be
> enforced for some customers. Obviously if a customer is paying for a
> connection that would want #1 to be enforced as well. 
> 
> Cheers,
> Marco
> 
> 
> 
> > -----Original Message-----
> > From: Gary Kenward [mailto:[email-masked]]
> > Sent: Wednesday, April 03, 2002 2:02 PM
> > To: 'NSIS'
> > Subject: [NSIS] question on 5.3.3
> > Sensitivity: Confidential
> > 
> > 
> > Hello:
> >

---

From: [email-masked]
Date: Wed, 3 Apr 2002 15:13:37 -0600

Gary,
 
I assume that based based on this requirement, there needs to be a mechanism in the protocol to determine if the QoS Initiator is actually down. So to come back to your original question, I do think that this is actually a protocol requirement and not merely an implementation issue.
 
Marc

-----Original Message-----
From: ext Gary Kenward [mailto:[email-masked]]
Sent: 03 April, 2002 2:34 PM
To: 'Schneider, Marco'; 'NSIS'
Subject: RE: [NSIS] question on 5.3.3

Marco: 

  However, I am unclear as to how 1) versus 2) would change the semantics 
of the protocol? As opposed to the semantics of resource reservation algorithms 
at a given node? 

Gary 

> From: Schneider, Marco [ mailto:[email-masked]] 
> > From: Gary Kenward [ mailto:[email-masked]]

---

From: "Gary Kenward"<[email-masked]>
Date: Wed, 3 Apr 2002 17:06:09 -0500

Marc:
 
Ok, but I think that this is a specific interpretation of the requirement
that is not captured in the wording.
What you are referring to is more along the lines of protocol support for
fault recovery. May be useful
(if the initiator is down, who are the protocol peers? if the initiator is
in the path, how can the protocol 
be used? etc.)
 
Anyway, thanks.
Gary

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: April 3, 2002 16:14
To: Kenward, Gary [WDLN2:AN10:EXCH]; [email-masked]; [email-masked]
Subject: RE: [NSIS] question on 5.3.3
Sensitivity: Confidential

Gary,
 
I assume that based based on this requirement, there needs to be a mechanism
in the protocol to determine if the QoS Initiator is actually down. So to
come back to your original question, I do think that this is actually a
protocol requirement and not merely an implementation issue.
 
Marc

-----Original Message-----
From: ext Gary Kenward [mailto:[email-masked]]
Sent: 03 April, 2002 2:34 PM
To: 'Schneider, Marco'; 'NSIS'
Subject: RE: [NSIS] question on 5.3.3

Marco: 

Gary 

> From: Schneider, Marco [ mailto:[email-masked]
<mailto:[email-masked]> ] 
> > From: Gary Kenward [ mailto:[email-masked]
<mailto:[email-masked]> ] 
> > requirement, but rather an implementation requirement. 
<https://www1.ietf.org/mailman/listinfo/nsis>

---

From: "Schneider, Marco" <[email-masked]>
Date: Wed, 3 Apr 2002 16:39:29 -0600

Gary,
 
To answer your question I must make assumptions about the solution. For
example:
 
1) In the case of a soft-state solution such as RSVP, Case #1 is explicityly
supported. The refresh message acts as a "keep alive". The semantics of the
protocol is that a reservation timeouts in a short duration if not
refreshed. The refreshments are per flow. Behaviour #2 is not supported. If
it were supported exclusively then refresh would not exist.
 
2) In contrast ATM UNI does not do per flow/connection refresh. My best
recollection is as follows. If the signaling channel is detected as having
gone down (via some sort of keep alive mechanism) then all associated
connections are released. Because ATM "refreshes" the signaling channel and
not the flows/connections, for any individual connection the protocol will
reach a steady state in which no additional messages are sent. While this
may be seen as implicit implementation of behaviour #1 from the overall
layered perspective, from the UNI state machine perspective behaviour #2 is
being supported. 
 
Not sure if this fully answers your question....
 
Marco

-----Original Message-----
From: Gary Kenward [mailto:[email-masked]]
Sent: Wednesday, April 03, 2002 2:34 PM
To: Schneider, Marco; 'NSIS'
Subject: RE: [NSIS] question on 5.3.3
Sensitivity: Confidential

Marco: 

Gary

---

From: "Schneider, Marco" <[email-masked]>
Date: Wed, 3 Apr 2002 17:31:47 -0600

>>"Define "down". "

Good question. Please note that I did not define the original requirement
which used the term "down". I took the meaning to be that if the actual box
running the software or the software itself stops working then the QOS
Initiator is "down". A controller would likely detect this indirectly. For
instance a keep alive message is not recieved for a period of time. 

>>"Does a network partition count?"

If a network partition prevents the initiator from sending signaling
messaging to the controller then a network partition does count. 

Marco

> From: Michael Thomas [mailto:[email-masked]]
> Sent: Wednesday, April 03, 2002 2:32 PM
> To: Schneider, Marco
> Cc: 'Gary Kenward'; 'NSIS'
> Schneider, Marco writes:
>    Define "down". Does a network partition count?
> 
> 		  Mike
>

---

From: "Schneider, Marco" <[email-masked]>
Date: Wed, 3 Apr 2002 17:35:26 -0600

Yes that's it, the protocol must support options for fault recovery
including the maintenance and the release of existing flows.
 
Marco

-----Original Message-----
From: Gary Kenward [mailto:[email-masked]]
Sent: Wednesday, April 03, 2002 4:06 PM
To: [email-masked]'; Schneider, Marco; [email-masked]
Subject: RE: [NSIS] question on 5.3.3
Sensitivity: Confidential

Marc:

Anyway, thanks.
Gary

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: April 3, 2002 16:14
To: Kenward, Gary [WDLN2:AN10:EXCH]; [email-masked]; [email-masked]
Subject: RE: [NSIS] question on 5.3.3
Sensitivity: Confidential

Gary,

Marc

-----Original Message-----
From: ext Gary Kenward [mailto:[email-masked]]
Sent: 03 April, 2002 2:34 PM
To: 'Schneider, Marco'; 'NSIS'
Subject: RE: [NSIS] question on 5.3.3

Marco: 

Gary

---

From: [email-masked]
Date: Thu, 4 Apr 2002 09:25:29 +0200

Hi Marco, all,

I think this touches on the resiliency issue we discussed in Minneapolis.
When the data plane and control plane are separate then it is a question of
fate sharing. Should or shouldn't the data path be torn down when a control
plane entity fails. I certainly wouldn't limit this to the QI only, it is
also important for the QC. Also, we may need to consider different types of
failures with different reactions. Personally, I think that the behaviour
under failure conditions is a framework issue. For the moment I think that
in terms of requirements, the suggestion that both maintenance and release
of existing flows should be supported is a good starting point. I thought,
however, that we were going to put all the failure behaviour under open
issues for the requirements.

Sven.

"Schneider, Marco" <[email-masked]> on 04/04/2002 01:35:26

  To:          "'Gary Kenward'"                               
               <[email-masked]>,                 
               "[email-masked]'"                       
               <[email-masked]>, [email-masked]          
                                                              
  cc:          (bcc: Sven VAN DEN BOSCH/BE/ALCATEL)           

  Subject      RE: [NSIS] question on 5.3.3                   
  :                                                           

Marco

-----Original Message-----
From: Gary Kenward [mailto:[email-masked]]
Sent: Wednesday, April 03, 2002 4:06 PM
To: [email-masked]'; Schneider, Marco; [email-masked]
Subject: RE: [NSIS] question on 5.3.3
Sensitivity: Confidential

Marc:

Anyway, thanks.
Gary

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: April 3, 2002 16:14
To: Kenward, Gary [WDLN2:AN10:EXCH]; [email-masked]; [email-masked]
Subject: RE: [NSIS] question on 5.3.3
Sensitivity: Confidential

Gary,

I assume that based based on this requirement, there needs to be a
mechanism
in the protocol to determine if the QoS Initiator is actually down. So to
come back to your original question, I do think that this is actually a
protocol requirement and not merely an implementation issue.

Marc

-----Original Message-----
From: ext Gary Kenward [mailto:[email-masked]]
Sent: 03 April, 2002 2:34 PM
To: 'Schneider, Marco'; 'NSIS'
Subject: RE: [NSIS] question on 5.3.3

Marco:

Gary

(See attached file: att1.htm)

---

From: "Gary Kenward"<[email-masked]>
Date: Thu, 4 Apr 2002 12:01:30 -0500

Marco:
 
Understood. I suspect that the IETF (i.e. the wg perhaps, and likely at
least the IESG) 
will not be in favour of 2), and will support 1).
 
The bottom line, at this point is that the requirement needs to be
clarified, I think.
 
Thanks,
Gary

-----Original Message-----
From: Schneider, Marco [mailto:[email-masked]]
Sent: April 3, 2002 17:39
To: Kenward, Gary [WDLN2:AN10:EXCH]; 'NSIS'
Subject: RE: [NSIS] question on 5.3.3
Sensitivity: Confidential

Gary,

 

Marco

-----Original Message-----
From: Gary Kenward [mailto:[email-masked]]
Sent: Wednesday, April 03, 2002 2:34 PM
To: Schneider, Marco; 'NSIS'
Subject: RE: [NSIS] question on 5.3.3
Sensitivity: Confidential

Marco: 

Gary

---

From: "Gary Kenward"<[email-masked]>
Date: Thu, 4 Apr 2002 12:30:00 -0500

The other, perhaps more significant question, is whether the
fail over mechanism is NSIS protocol driven, as Marco is suggestion,
or locally driven, as in a self-healing network, as in Internet routing.

Pros and cons for both, and perhaps both are needed. Let's be careful about
all the assumptions the lay behind a signalling approach to fault
management.

More to the original point, I believe the requirement needs to be clarified.
There is a possibility that there are actually two requirements (based upon
two different interpretations of the current requirement that have been 
expressed).

Gary

> From: [email-masked]
> [mailto:[email-masked]]
> Sent: April 4, 2002 02:25
> To: Schneider, Marco
> Cc: Kenward, Gary [WDLN2:AN10:EXCH]; [email-masked]';
> [email-masked]