Subject: [NSIS] I-D ACTION:draft-vandenbosch-nsis-resilience-00.txt

From: [email-masked]
Date: Thu, 27 Jun 2002 16:24:35 +0200

Hi all,

As a result of discussions at the interim meeting we put together a
separate document on nsis resilience. It tries to list issues brought up at
the interim meeting together with some new ones in a broader general scope.
The document has finally made it through to the IETF repository. Some
people have expressed interest during the interim meeting, so hopefully the
document can help in structuring the discussion.

Best regards,
Sven

---------------------- Forwarded by Sven VAN DEN BOSCH/BE/ALCATEL on
27/06/2002 16:19 ---------------------------

[email-masked]@cnri.reston.va.us on 27/06/2002 12:39:37

Please respond to [email-masked]

Sent by:  [email-masked]

To:   IETF-Announce: ;
cc:
Subject:  I-D ACTION:draft-vandenbosch-nsis-resilience-00.txt

A New Internet-Draft is available from the on-line Internet-Drafts
directories.

     Title          : NSIS resilience analysis
     Author(s) : S. Van den Bosch, M. Buchli
     Filename  : draft-vandenbosch-nsis-resilience-00.txt
     Pages          : 11
     Date      : 26-Jun-02

The Next Steps in Signaling (NSIS) working group is chartered to
develop requirements, architecture and protocols for the next IETF
steps in signaling Quality-of-Service (QoS). Although the NSIS
protocol may eventually be used for other applications in addition
to QoS, it is expected that these, in much the same way as QoS, will
depend on predictable and high-availability service delivery. This
document attempts to identify, list and classify potential
resilience issues for the NSIS protocol.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-vandenbosch-nsis-resilience-00.txt

To remove yourself from the IETF Announcement list, send a message to
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the
username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
     "get draft-vandenbosch-nsis-resilience-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
     [email-masked].
In the body type:
     "FILE /internet-drafts/draft-vandenbosch-nsis-resilience-00.txt".

NOTE:     The mail server at ietf.org can return the document in
     MIME-encoded form by using the "mpack" utility.  To use this
     feature, insert the command "ENCODING mime" before the "FILE"
     command.  To decode the response(s), you will need "munpack" or
     a MIME-compliant mail reader.  Different MIME-compliant mail readers
     exhibit different behavior, especially when dealing with
     "multipart" MIME messages (i.e. documents which have been split
     up into multiple messages), so check your local documentation on
     how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

ftp://ftp.ietf.org/internet-drafts/draft-vandenbosch-nsis-resilience-00.txt

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

---

From: "Georgios Karagiannis (ELN)" <[email-masked]>
Date: Thu, 27 Jun 2002 17:54:58 +0200

Hi Sven 

I will only comment your draft starting from Section 5.
Main comment that I have is related to the fact  that you somehow
emphasise that the per-class states complicate the failure notification
and recovery issues, while I think that failure notification and recovery 
issues are independent of the type of these states. Another comment is related to the fact that 
you use a limted number of solutions, as the NSIS solutions, while these 
solutions might be just examples.

See more comments in line with your text (copied from your draft). 
My comments are given betrween <<>>.

Best regards,
Georgios

------------
      5. Failure description 
                   
               5.1.    Internal data plane failures 
                   
                  Data plane failures can result from the breakdown or 
                  misconfiguration of data path entities such as routers or links. In 
                  case of a router, the failure can be due to a power outage, a 
                  software crash or hardware failure, e.g. interface cards. Link 
                  failures can be due to defective interface cards or to lower layer 
                  failures such as cable cuts. 
                  We make a distinction between data plane failures that are internal 
                  to a QoS domain and failures at the edges of a QoS domain (In case 
                  of a QoS domain consisting of a single router, an internal failure 
                  can occur when a component link in a link bundle attached to the 
                  router fails). Internal data plane failures should be solved locally 
                  and should not involve NSIS signalling when succesful.  

<< [georgios] What do you mean here? Do you mean that Internal data plane features should not 
involve NSIS 'signalling when sucessfull. Some of the NSIS modes of operation 
should be able to apply NSIS signaling for internal data plane failure.>>

               5.2.    External data plane failures 
                   
                  Edge failures can for instance occur when an Autonomous System 
                  Border Router (ASBR) or the link between two ASBRs goes down. 
                  Recovery from this type of failures requires a coordinated action 
                  between two or more QoS domains and will therefore impact NSIS 
                  signalling. 
<<[georgios] probably you can find other terms than Autonomous System.>>

               5.3.    Control plane failures 
                   
                  Two main types of control plane failures are distinguished: 
                  - Failure of an NSIS entity, e.g. a QI, QC or QR failure. If the QI 
                  is located at the end host, the end host is also considered to be 
                  part of the control plane of the NSIS signalling. 
                  - Loss of signalling messages between NSIS entities 

<<  [georgios] Please chnage terminology according to the new [hancock - framework] >>

               5.4.    QoS degradation 
                   
                  A failure does not necessarily have to equal a loss of connectivity. 
                  In a QoS-enabled environment, a degradation of the perceived 
                  performance on the data path can also be categorised as a failure. 
                  It may be important to distinguish these failures from a 'hard' 
                  failure (involving loss of connectivity) in order to support 
                  hierarchical protection. 
                    
         << [georgios]  This is a policing matter! is not a failure>>          
                   
               6. Recovery issues 
                   
               6.1.    Failure detection 
                   
                  In the data plane, node failures can be detected from the absence of 
                  hello messages from the Interior Gateway Protocol (IGP). Link 
                  failure indications can usually be derived from of lower-layer 
                  failure indications (loss of light, loss of signal). In case of 
                  logical links, failure detection can be more problematic and must 
                  either take place via the hello protocol or via a specific OAM 
                  procedure. 

                   << [georgios]  Well other means could be used. Please do not restrict 
it only to this solution. Mention this as an example, please include other references, e.g., [RMD] >>

                  In the control plane, NSIS failure detection involves the following 
                  issues: 
                  - When the QI is different from the end host, QI and end host need 
                  to be aware of each others failures. Two factors can complicate this 
                  problem. First, the QI may keep hard-state related to the end-host 
                  requests because the overhead of refreshes is deemed excessive. In 
                  this case, state refreshes can not be used as a failure detection 
                  mechanism. Second, the end host is not necessarily an NSIS speaker, 
                  which means that the detection mechanism must be supported outside 
                  of NSIS signalling. One potential solution is the use of higher and 
                  or lower layer triggers in the QI. This means that the QI should 
                  have higher/lower layer information available. 
<< [georgios] is this related to out of band? Is this within NSIS scope?>>

                  - When an NSIS entity is protected by a backup entity, a 
                  synchronisation failure between the two entities needs to be 
                  detected prior to the protection switch. Since both entities will be 
                  NSIS speakers, this functionality could be implemented in the NSIS 
                  protocol. 
<< [georgios] Is this within  NSIS scope??>>

                  - In case of hop-by-hop routing of the NSIS signalling messages,  a 
                  failure detection mechanism is required in NSIS, even when the 
                  communication between NSIS entities is done with a reliable 
                  transport mechanism. This is caused by the fact that the transport 
                  signalling is terminated at each NSIS hop. This means that messages 
                  can be lost in an NSIS entity without the transport layer noticing 
                  it. 
                   
               6.2.    Failure notification 
                   
                  Any failure notification needed in the data plane, e.g. from lower 
                  layers, should normally be transparent to NSIS. An issue can arise 
                  for external failures. 
<<[georgios]  I do not understand this??>>

                  - If a failure of an external link or node is detected, a route 
                  change might be required in order to perform the recovery action. In 
                  that case, the failure should be notified to the QI if only per-
                  class state is kept in the QC. 

<<[georgios] do you mean here external to a NSIS domain. If yes, why the failure notification
  is only needed when per-class state is kept?  I think that this is independent of the 
type of reservation state. >>

                  For control plane failures, an issue might arise when only per-class 
                  state is kept. 

<< I do not agree with this, why?>>

                  - When only per-class state is kept, which might for instance occur 
                  in a QC in order to reduce information storage, the QC cannot 
                  reroute the LSP without a message from the QI. 
<< What do you mean with reroute! Is this within NSIS scope?>>

                  This means that this 
                  situation is only feasible in combination with soft-state. In that 
                  case, the QC needs to notify the QI about the failure in response to 
                 the next refresh message, that therefore needs to contain an 
                  identification of the QI. 
                  - The failing reservation may be part of a service consisting of 
                  multiple such flows. An obvious example is a bi-directional service. 
                  It would seem appropriate for each flow to be protected separately 
                  and for the service not to be impacted when the protection action is 
                  successful. However, it would make little sense to keep one 
                  direction up when the other goes down. This would imply notification 
                  of the QI/QR of the flows making up the service in case of 
                  unsuccessful protection. 

               6.3.    Recovery action 
                   
                  The definition of a recovery strategy typically involves a decision 
                  on: 
                  - the scope of the protection action: this can be end-to-end path 
                  protection or local segment protection. We have already seen that 
                  the use of per-class state in the QC will prevent the application of 
                  local segment protection for external failures. 

<<[georgios] I do not understand this statement reagrding per class states>>

                  - the timing of the protection action: protection paths can be pre-
                  computed and pre-established in which case only a switch from 
                  primary to protection path is needed when a failure occurs. If the 
                  computation and/or establishment of the protection path is started 
                  after failure detection (rerouting), an additional recovery delay is 
                  introduced.

<<[georgios] is routing also included in the NSIS scope?>> 

                  - resource allocation on the protection paths: resource reservation 
                  on protection paths prior to failure is very inefficient and leads 
                  to excessive usage of network capacity for protection purposes. This 
                  can be avoided by not reserving capacity on the protection path. In 
                  this case, however, the availability of the protection path can not 
                  be guaranteed when a failure occurs. Alternatively, protection 
                  capacity can be shared between protection paths that are unlikely to 
                  fail simultaneously. For this, a limited number of failure scenarios 
                  (e.g. single node or single link failures) is assumed. Sharing 
                  protection capacity is highly complicated by the interdomain scope 
                  of the NSIS signalling because of the lack of detailed information 
                  on the failure states and the primary path. 
<< [georgios] Is this the only solution?>>

                  Recovery on the control plane may involve any of the following 
                  issues: 
                  - If a failure can only be solved by means of a change of the 
                  interdomain path of the flow, the QC might be required to force a 
                  route change from the QI. 
<< [georgios] Should this be done by NSIS; It is out of scope of NSIS >>

Note that this can occur without any data 
                  plane failure when the QC of a QoS domain fails and the QCs of 
                  neighbouring domains want to bring up peering relations with QCs 
                  that are not realted to the next hop on the data path. 
                  - When only per-class state is kept in a QC and a setup message is 
                  lost, retransmission of the setup message may cause duplicate 
                  reservations in QoS domains upstream of the point where the loss 
                  occurred. In case of soft-state, this situation will last for 
                  several refresh intervals. Note that the impact of this type of 
                  failure can be restricted by the use of reliable transport between 
                  NSIS entities. 
<<[georgios] It can be solved by using explicit release messages, see RMD frmaework>>

                  - In case of a QI or QR failure, the QC immediately following or 
                  preceding the failing entity may need to take up some proxy 
                  functionality for the failing entity. This functionality is optional 
                  for sending out teardown messages when soft-state is used, but 
                  mandatory for hard-state. It is also mandatory for replying to 
                  teardown messages, e.g. originating from the QI. 
                  - If the QoS Initiator does not receive a response on a signaling 
                  message within a certain time interval it will consider it as lost. 
                  It may decide to retransmit the signaling message. Therefore, the 
                  QoS Initiator must be able to make sure that the received ACK is not 
                  a delayed ACK from the previous transmitted signaling message. The 
                  signaling messages should therefore include a sequence number in 
                  order to associate a request (NEW, TEAR, REFRESH) with a response 
                  (ACK, NACK). 
<<[georgios] When soft state refresh is used, the TEAr messages do not neet to be authenticated>>
                   
               7. Reversion issues 
                   
               7.1.    Repair detection 
                   
                  No issues are identified for the data plane. 
                   
                  For the control plane, repair detection will most likely occur by 
                  means of discovery messages initiated by the repaired NSIS entity. 
                  It is proposed that this discovery process could be a preliminary 
                  phase prior to the NSIS protocol and can therefore remain out of its 
                  scope. It is nevertheless crucial that such a discovery protocol is 
                  standardised in order to allow NSIS entities from different vendors 
                  to discover each other. 
<<[georgios] I think that is out of scope of NSIS>>
                   
               7.2.    Repair notification 
                   
                  Repair notification will normally take place by means of the IGP in 
                  the data plane. 
                   
                  In the control plane, repair notification may be needed when a QC 
                  has taken up some proxy functionality for the QI or QC. However, no 
                  special action should be needed for this since this information can 
                  be inferred from the repair detection. 
<<[georgios]  If repair detection is out of scope will this also be out of NSIS scope>>
                   
               7.3.    Reversion action 
                   
                  On the data plane, reversion is unavoidable when in-band signaling 
                  is used because the signaling messages will follow the new data 
                  plane route. This might cause issues because resources are typically 
                  not reserved on the new route, which might cause (temporary) QoS 
                  degradation on the new route. 

<<[georgios] What is the reversion action about? Is this related to the severe 
congestion problem  explained in the NSIS requirements draft?>>

                  In case of out-of-band signaling 
                  reversion may be avoided by means of route pinning. However, it will 
                  usually be advantageous to move to a more favourable route when one 
                  becomes available, both from a performance and resource utilisation 
                  point of view. In that case, the separation of data plane and 
                  control plane might help delaying the route change until sufficient 
                  resources are reserved on the new path. 
                   
                  From a control plane perspective, reversion makes little sense when 
                  backup NSIS entities are used. In that case, the reversion action 
                   will be limited to a synchronisation with the currently active NSIS 
                  entity. The repaired entity will then become the backup. 
<<[georgios] Is out of band out of NSIS scope?

--------------------------------------------------------------------------------------------------

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]
Sent: Thursday, June 27, 2002 4:25 PM
To: [email-masked]
Subject: [NSIS] I-D ACTION:draft-vandenbosch-nsis-resilience-00.txt

Hi all,

Best regards,
Sven

To:   IETF-Announce: ;
cc:

Send a message to:
     [email-masked].
In the body type:

---

From: [email-masked]
Date: Fri, 28 Jun 2002 16:57:54 +0200

Hi Georgios,

Thanks a lot for your comments. I have some replies inline.

Cheers,
Sven.

"Georgios Karagiannis (ELN)" <[email-masked]> on
27/06/2002 17:54:58

To:   Sven VAN DEN BOSCH/BE/ALCATEL@ALCATEL, [email-masked]
cc:
Subject:  RE: [NSIS] I-D ACTION:draft-vandenbosch-nsis-resilience-00.txt

Hi Sven

issues are independent of the type of these states.

[sven] In general, per-class state has the effect of losing the link
between a certain initiator and its associated reservation. As such, it
causes an issues for failure notification because of the absence of state
information on where to send the notification.

Another comment is related to the fact that
you use a limted number of solutions, as the NSIS solutions, while these
solutions might be just examples.

[sven] That is true. Please feel free to propose other examples that you
feel might raise the same or other issues regarding resilience in nsis.

Best regards,
Georgios

------------
      5. Failure description

                  Data plane failures can result from the breakdown or
                  misconfiguration of data path entities such as routers or
links. In
                  case of a router, the failure can be due to a power
outage, a
                  software crash or hardware failure, e.g. interface cards.
Link
                  failures can be due to defective interface cards or to
lower layer
                  failures such as cable cuts.
                  We make a distinction between data plane failures that
are internal
                  to a QoS domain and failures at the edges of a QoS domain
(In case
                  of a QoS domain consisting of a single router, an
internal failure
                  can occur when a component link in a link bundle attached
to the
                  router fails). Internal data plane failures should be
solved locally
                  and should not involve NSIS signalling when succesful.

<< [georgios] What do you mean here? Do you mean that Internal data plane
features should not
involve NSIS 'signalling when sucessfull. Some of the NSIS modes of
operation
should be able to apply NSIS signaling for internal data plane failure.>>

[sven] The idea here is that an NE 'manages' somehow a set of 'resources'.
If an error occurs and a solution can be provided by the same entity then
it is proposed that nsis signalling is not affected. If the error is such
that the NE cannot handle it alone then nsis resilience should kick in. The
rationale is to avoid unnecessary failure notifications.

                  Edge failures can for instance occur when an Autonomous
System
                  Border Router (ASBR) or the link between two ASBRs goes
down.
                  Recovery from this type of failures requires a
coordinated action
                  between two or more QoS domains and will therefore impact
NSIS
                  signalling.
<<[georgios] probably you can find other terms than Autonomous System.>>

[sven] resource domain? I gues QoS domain is not even valid anymore. I
agree by the way that I should update terminology according to the
framework draft. They were developed in parallel, so it was difficult to do
that in this version.

                  Two main types of control plane failures are
distinguished:
                  - Failure of an NSIS entity, e.g. a QI, QC or QR failure.
If the QI
                  is located at the end host, the end host is also
considered to be
                  part of the control plane of the NSIS signalling.
                  - Loss of signalling messages between NSIS entities

<<  [georgios] Please chnage terminology according to the new [hancock -
framework] >>

[sven] see above.

               5.4.    QoS degradation

                  A failure does not necessarily have to equal a loss of
connectivity.
                  In a QoS-enabled environment, a degradation of the
perceived
                  performance on the data path can also be categorised as a
failure.
                  It may be important to distinguish these failures from a
'hard'
                  failure (involving loss of connectivity) in order to
support
                  hierarchical protection.

[sven] Not necessarily I think. Suppose you have a bundled link of which
one component link fails. In that case the BW on that link is reduced and
the QoS of flows on it might be affected. So you might need to move traffic
away from it. However, when a cable cut occurs on this new path, you might
be tempted to move the traffic back, because connectivity with degraded QoS
might be preferable to no connectivity at all.

               6. Recovery issues

               6.1.    Failure detection

                  In the data plane, node failures can be detected from the
absence of
                  hello messages from the Interior Gateway Protocol (IGP).
Link
                  failure indications can usually be derived from of
lower-layer
                  failure indications (loss of light, loss of signal). In
case of
                  logical links, failure detection can be more problematic
and must
                  either take place via the hello protocol or via a
specific OAM
                  procedure.

                   << [georgios]  Well other means could be used. Please do
not restrict
it only to this solution. Mention this as an example, please include other
references, e.g., [RMD] >>

[sven] OK, I will do that. Can you provide a pointer to the section in the
doc you mention?

                  In the control plane, NSIS failure detection involves the
following
                  issues:
                  - When the QI is different from the end host, QI and end
host need
                  to be aware of each others failures. Two factors can
complicate this
                  problem. First, the QI may keep hard-state related to the
end-host
                  requests because the overhead of refreshes is deemed
excessive. In
                  this case, state refreshes can not be used as a failure
detection
                  mechanism. Second, the end host is not necessarily an
NSIS speaker,
                  which means that the detection mechanism must be
supported outside
                  of NSIS signalling. One potential solution is the use of
higher and
                  or lower layer triggers in the QI. This means that the QI
should
                  have higher/lower layer information available.
<< [georgios] is this related to out of band? Is this within NSIS scope?>>

[sven] The point-of-view of the draft is the same as that of the framework:
we will not work on solutions for out-of-band but document issues for the
complete problem space.

                  - When an NSIS entity is protected by a backup entity, a
                  synchronisation failure between the two entities needs to
be
                  detected prior to the protection switch. Since both
entities will be
                  NSIS speakers, this functionality could be implemented in
the NSIS
                  protocol.
<< [georgios] Is this within  NSIS scope??>>
[sven] I think so. The NE can be in-band.

                  - In case of hop-by-hop routing of the NSIS signalling
messages,  a
                  failure detection mechanism is required in NSIS, even
when the
                  communication between NSIS entities is done with a
reliable
                  transport mechanism. This is caused by the fact that the
transport
                  signalling is terminated at each NSIS hop. This means
that messages
                  can be lost in an NSIS entity without the transport layer
noticing
                  it.

                  Any failure notification needed in the data plane, e.g.
from lower
                  layers, should normally be transparent to NSIS. An issue
can arise
                  for external failures.
<<[georgios]  I do not understand this??>>

[sven] This refers to the case where you e.g. detect a IP link failure
based on physical layer notification.

                  - If a failure of an external link or node is detected, a
route
                  change might be required in order to perform the recovery
action. In
                  that case, the failure should be notified to the QI if
only per-
                  class state is kept in the QC.

<<[georgios] do you mean here external to a NSIS domain. If yes, why the
failure notification
  is only needed when per-class state is kept?  I think that this is
independent of the
type of reservation state. >>

[sven] well, if per-flow state is kept, the node that detects the failure
can take action itself and doesn't need to notify the QI. Otherwise, it has
to wait for the next refresh, which has to come from the QI, notify and let
the QI take action.

                  For control plane failures, an issue might arise when
only per-class
                  state is kept.

                  - When only per-class state is kept, which might for
instance occur
                  in a QC in order to reduce information storage, the QC
cannot
                  reroute the LSP without a message from the QI.
<< What do you mean with reroute! Is this within NSIS scope?>>

[sven] it cannot link the failure to the affected flows.

                  This means that this
                  situation is only feasible in combination with
soft-state. In that
                  case, the QC needs to notify the QI about the failure in
response to
                 the next refresh message, that therefore needs to contain
an
                  identification of the QI.
                  - The failing reservation may be part of a service
consisting of
                  multiple such flows. An obvious example is a
bi-directional service.
                  It would seem appropriate for each flow to be protected
separately
                  and for the service not to be impacted when the
protection action is
                  successful. However, it would make little sense to keep
one
                  direction up when the other goes down. This would imply
notification
                  of the QI/QR of the flows making up the service in case
of
                  unsuccessful protection.

               6.3.    Recovery action

                  The definition of a recovery strategy typically involves
a decision
                  on:
                  - the scope of the protection action: this can be
end-to-end path
                  protection or local segment protection. We have already
seen that
                  the use of per-class state in the QC will prevent the
application of
                  local segment protection for external failures.

<<[georgios] I do not understand this statement reagrding per class
states>>

[sven] I need to think about this one. We can probably discuss more in
Japan but I will try to come back on this one on the list before that.

                  - the timing of the protection action: protection paths
can be pre-
                  computed and pre-established in which case only a switch
from
                  primary to protection path is needed when a failure
occurs. If the
                  computation and/or establishment of the protection path
is started
                  after failure detection (rerouting), an additional
recovery delay is
                  introduced.

<<[georgios] is routing also included in the NSIS scope?>

                  - resource allocation on the protection paths: resource
reservation
                  on protection paths prior to failure is very inefficient
and leads
                  to excessive usage of network capacity for protection
purposes. This
                  can be avoided by not reserving capacity on the
protection path. In
                  this case, however, the availability of the protection
path can not
                  be guaranteed when a failure occurs. Alternatively,
protection
                  capacity can be shared between protection paths that are
unlikely to
                  fail simultaneously. For this, a limited number of
failure scenarios
                  (e.g. single node or single link failures) is assumed.
Sharing
                  protection capacity is highly complicated by the
interdomain scope
                  of the NSIS signalling because of the lack of detailed
information
                  on the failure states and the primary path.
<< [georgios] Is this the only solution?>>

[sven] Probably not. Can you rpovide me with pointers to other solutions?

                  Recovery on the control plane may involve any of the
following
                  issues:
                  - If a failure can only be solved by means of a change of
the
                  interdomain path of the flow, the QC might be required to
force a
                  route change from the QI.
<< [georgios] Should this be done by NSIS; It is out of scope of NSIS >>

[sven] If it is a required action of the QC, it is in the scope of nsis.

Note that this can occur without any data
                  plane failure when the QC of a QoS domain fails and the
QCs of
                  neighbouring domains want to bring up peering relations
with QCs
                  that are not realted to the next hop on the data path.
                  - When only per-class state is kept in a QC and a setup
message is
                  lost, retransmission of the setup message may cause
duplicate
                  reservations in QoS domains upstream of the point where
the loss
                  occurred. In case of soft-state, this situation will last
for
                  several refresh intervals. Note that the impact of this
type of
                  failure can be restricted by the use of reliable
transport between
                  NSIS entities.
<<[georgios] It can be solved by using explicit release messages, see RMD
frmaework>>

[sven] I know about explicit release but that is when you are aware of the
double reservation. This is an example where you are not, and hence will
not react to it.

                  - In case of a QI or QR failure, the QC immediately
following or
                  preceding the failing entity may need to take up some
proxy
                  functionality for the failing entity. This functionality
is optional
                  for sending out teardown messages when soft-state is
used, but
                  mandatory for hard-state. It is also mandatory for
replying to
                  teardown messages, e.g. originating from the QI.
                  - If the QoS Initiator does not receive a response on a
signaling
                  message within a certain time interval it will consider
it as lost.
                  It may decide to retransmit the signaling message.
Therefore, the
                  QoS Initiator must be able to make sure that the received
ACK is not
                  a delayed ACK from the previous transmitted signaling
message. The
                  signaling messages should therefore include a sequence
number in
                  order to associate a request (NEW, TEAR, REFRESH) with a
response
                  (ACK, NACK).
<<[georgios] When soft state refresh is used, the TEAr messages do not neet
to be authenticated>>

[sven] You mean not acknowledged, because they time out anyhow. That is
true.

               7. Reversion issues

               7.1.    Repair detection

                  For the control plane, repair detection will most likely
occur by
                  means of discovery messages initiated by the repaired
NSIS entity.
                  It is proposed that this discovery process could be a
preliminary
                  phase prior to the NSIS protocol and can therefore remain
out of its
                  scope. It is nevertheless crucial that such a discovery
protocol is
                  standardised in order to allow NSIS entities from
different vendors
                  to discover each other.
<<[georgios] I think that is out of scope of NSIS>>

               7.2.    Repair notification

                  Repair notification will normally take place by means of
the IGP in
                  the data plane.

                  In the control plane, repair notification may be needed
when a QC
                  has taken up some proxy functionality for the QI or QC.
However, no
                  special action should be needed for this since this
information can
                  be inferred from the repair detection.
<<[georgios]  If repair detection is out of scope will this also be out of
NSIS scope>>

               7.3.    Reversion action

                  On the data plane, reversion is unavoidable when in-band
signaling
                  is used because the signaling messages will follow the
new data
                  plane route. This might cause issues because resources
are typically
                  not reserved on the new route, which might cause
(temporary) QoS
                  degradation on the new route.

<<[georgios] What is the reversion action about? Is this related to the
severe
congestion problem  explained in the NSIS requirements draft?>>

[sven] Reversion refers to what happens when something that failed comes up
again.

                  In case of out-of-band signaling
                  reversion may be avoided by means of route pinning.
However, it will
                  usually be advantageous to move to a more favourable
route when one
                  becomes available, both from a performance and resource
utilisation
                  point of view. In that case, the separation of data plane
and
                  control plane might help delaying the route change until
sufficient
                  resources are reserved on the new path.

                  From a control plane perspective, reversion makes little
sense when
                  backup NSIS entities are used. In that case, the
reversion action
                   will be limited to a synchronisation with the currently
active NSIS
                  entity. The repaired entity will then become the backup.
<<[georgios] Is out of band out of NSIS scope?

[sven] As I said, nsis will not work on out-of-band solutions for now. It
was the agreement that we should document these issues.

-----Original Message-----

Hi all,

Best regards,
Sven

To:   IETF-Announce: ;
cc:

Send a message to:
     [email-masked].
In the body type:

---

From: [email-masked]
Date: Fri, 28 Jun 2002 19:19:23 +0300

Hi Sven,

> framework draft. They were developed in parallel, so it was 
> difficult to do that in this version.

I think for now, we could call it an NSIS domain.  

John