Subject: Protection object in restoration signaling

From: Yoshihiko SUEMURA <[email-masked]>
Date: Sun, 01 Feb 2004 16:50:22 +0900

P&R Design Team,

In the 1:1/Shared Mesh Restoration described in
draft-lang-ccamp-gmpls-recovery-e2e-signaling-02, activation of a
secondary LSP is done only by a Path message. The Protection object is
carried only in a Path message.
However, I think a Resv message should also carry the Protection object.

Consider the following case.

   A-----------B
    \         /
     C-------D
    /         \
   E           F

A-B:     Primary LSP
A-C-D-B: Secondary LSP
E-C-D-F: Extra (preemptable) LSP

Activating the Secondary LSP using only a Path message may cause
unintended connection (A-C-D-F) between the Secondary LSP and the Extra
LSP. This can be prevented by applying a two-way activation scheme using
both Path and Resv messages. You can delete the Extra LSP by the Path
message, and activate the Secondary LSP by the Resv message. 
However, if the Resv message for activation does not carry the
Protection object, it cannot be distinguished from a refresh Resv
message. This still causes unintended connection in the following case.

(1) At node C, a crossconnect for the Extra LSP is deleted when
receiving a Path message.
  
(2) Then, if node C receives a refresh Resv message from D, it sets up a
crossconnect for the Secondary LSP because it cannot distinguish the
refresh Resv message from a Resv message for activation.
    
If (2) occurs before D deletes a crossconnect for the Extra LSP, it
causes unintended connection between the Secondary LSP and the Extra LSP.

As a solution for the above problem, I propose to add the Protection
object to a Resv message. The unintended connection can be prevented
because you can distinguish a Resv message for activation from a refresh
Resv message by watching the S bit.

Best regards,

Yoshihiko

-----------------------------------------------------------------
Yoshihiko SUEMURA 

NEC Corporation
E-mail: [email-masked]

---

From: [email-masked]
Date: Sun, 01 Feb 2004 22:41:11 +0100

resend (apparently the mailing list bounced the message back)

---

hi, see in-line

Yoshihiko SUEMURA wrote:
> LSP. 

here i would agree that there is a condition on the next_hop
to delete the extra_lsp state before activating the xc for
the secondary lsp and in order to guarantee this commit of
the resources activation may be done upon Resv reception

also the use of hard preemption before performing this
operation decreases (if not completely elevates) if used
to commit action when received from D in this example,
the time occurrence of this transient state:

- PathErr with PAth_State_Removed flag towards E and a PathTear
   to the destination F
- or a PathErr with Path_State_Removed flag towards F and a
   PathTear towards E

therefore there are other faster triggers for this purpose
the issue being at the end to either perform this operation
as fast as possible when reaching the last common node,
or simply delete in downstream direction and commit along
the upstream direction as said above (there are more complex
cases where this might be at the end more easy to process)

> This can be prevented by applying a two-way activation scheme using
> both Path and Resv messages. 

nothing prevent this from the above (the paragraph that
describes this doesn't say commit at the data plane this
is left out to the implementation) some clarification in
the document are certainly needed here

> You can delete the Extra LSP by the Path

you may want to apply this activation scheme, in such a case
all the nodes would have their extra-traffic lsp deleted
through the downstream path message (thanks for pointing
this)

> refresh Resv message from a Resv message for activation.

referring to 2961 p12/13, don't see how see this could
happen, would you clarify in order to address this point
in case, also the resv is considered implicitly here as
trigger message

> Resv message by watching the S bit.

suggest to first clarify the previous point,

thanks,
- dimitri.

-- 
Papadimitriou Dimitri
E-mail : [email-masked]
E-mail : [email-masked]
Webpage: http://psg.com/~dpapadimitriou/
Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium
Phone  : +32 3 240-8491

---

From: Yoshihiko SUEMURA <[email-masked]>
Date: Mon, 02 Feb 2004 23:10:18 +0900

Hi Dimitri,

Please see inline.

On Sun, 01 Feb 2004 15:39:33 +0100,
[email-masked] wrote:

> the resources activation may be done upon resv reception
> 
> also the use of hard preemption before committing this
> operation decreases (if not completely elevates if used
> to commit action when received from D in this example)
> through the downstream path message

Yes. This is what I want to apply. I want to delete all the
extra-traffic LSPs through the downstream Path message, and then,
activate the secondary LSP through the upstream Resv message.

> referring to 2961 p12/13 don't see how see this could happen,
> would you clarify, in order to address this point in case, also
> the resv is considered implicitly here as trigger message

After (1), node C waits for the upstream Resv message for activating the
secondary LSP. However, it may receive a refresh Resv message (refresh
for a Resv message for PROVISIONING the secondary LSP) from D before
receiving the Resv for activation. Currently, C cannot distinguish it
from the Resv for activation because there is no difference between
their formats. This may trigger C to activate the secondary LSP
unintentionally before the downstream nodes delete their extra-traffic
LSPs.

Thank you,

Yoshihiko

NEC Corporation

---

From: [email-masked]
Date: Thu, 05 Feb 2004 02:02:30 +0100

hi, see in-line

> unintentionally before the downstream nodes delete their extra-traffic

by re-reading it was also my understanding when performing the xc
on the resv we got here a transient issue that may appear to be
problematic as the length of the path in terms of number of hops
increases (since the latency increases, the probability to be
impacted by this also increases), so would the following text
address your concern:

"In certain circumstances, it MAY be desirable to perform the
activation of the secondary LSP in the upstream direction (Resv
trigger message) instead of using the default downstream method.
In this case, and in order to avoid any mis-ordering and any mis-
interpretation between a refresh Resv and a trigger Resv message
at intermediate nodes along the secondary LSP, upon reception of
the Path message, the egress node MAY include the PROTECTION
object in the Resv message. The latter is then processed on a hop
by hop basis to activate the secondary LSP until reaching the
ingress node. The PROTECTION object included in the Path message
MUST be set as specified in Section 8.3 and Section 9.3. The
upstream activation behavior SHOULD be configurable on a local
basis."

hope this addresses the concern,
thanks,
- dimitri.

---

From: Yoshihiko SUEMURA <[email-masked]>
Date: Mon, 09 Feb 2004 17:29:46 +0900

Hi Dimitri,

Yes. The text below addresses my concern.

Thank you,

Yoshihiko

NEC Corporation