[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Protection object in restoration signaling
Hi Dimitri,
Please see inline.
On Sun, 01 Feb 2004 15:39:33 +0100,
Dimitri.Papadimitriou@alcatel.be wrote:
> 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 committing 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
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.
>
> > 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
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
>
> > 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
>
-----------------------------------------------------------------
Yoshihiko SUEMURA
NEC Corporation
E-mail: y-suemura@bp.jp.nec.com