Re: Protection object in restoration signaling

[Dimitri.Papadimitriou@alcatel.be]

resend (apparently the mailing list bounced the message back)

---

hi, see in-line

Yoshihiko SUEMURA wrote:
> 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. 

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
> message, and activate the Secondary LSP by the Resv message. 

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)

> 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.

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

> 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.

suggest to first clarify the previous point,

thanks,
- dimitri.

> Best regards,
>
> Yoshihiko
>
> -----------------------------------------------------------------
> Yoshihiko SUEMURA 
>
> NEC Corporation
> E-mail: y-suemura@bp.jp.nec.com

--
Papadimitriou Dimitri
E-mail : dimitri.papadimitriou@alcatel.be
E-mail : dpapadimitriou@psg.com
Webpage: http://psg.com/~dpapadimitriou/
Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium
Phone  : +32 3 240-8491