[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Protection object in resv message
Hi Dimitri,
Yes. The text below addresses my concern.
Thank you,
Yoshihiko
On Thu, 05 Feb 2004 02:02:30 +0100,
Dimitri.Papadimitriou@alcatel.be wrote:
> hi, see in-line
>
> Yoshihiko SUEMURA wrote:
>
> > 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.
>
> 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.
> > 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
> >
>
> --
> 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