[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Avoiding misconnections in restoration signaling [Was: Protection obj. in restoration signaling]
Hi Yoshihiko et al,
In your exchange last month, the following text was proposed as
a way of activating the backup path in the 1:1/Shared Mesh case
to avoid misconnections:
< 02/04/04 Dimitri Papadimitriou wrote:>
> 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."
However, after looking at the exchange in detail (and keeping
in mind the hard/soft preemption issue), I believe the
text needs to be somewhat more precise.
The way it is worded at present (even though it satisfied Yoshihiko),
would appear to allow for the possibility of misconnections, just in
reverse,
as I explain below.
The text, as worded, only provides for the activation of the secondary
LSP upon receipt of a Resv message for the secondary LSP (which would
be identified by the inclusion of the PROTECTION obj). However, it
makes an implicit assumption that the state for the extra-LSP, in both
the _control and the data_ plane, is brought down during the transmission
of the Path message for the secondary LSP.
Given the debates on the hard/soft-preemption issue, it is not clear
that the state of the extra-LSP will be brought down upon the receipt
of the Path message for the secondary LSP. If that is not
the case, then a misconnection happens as follows.
A-----------B
\ /
C-------D
/ \
E F
A-B: Primary LSP
A-C-D-B: Secondary LSP
E-C-D-F: Extra (preemptable) LSP
Node D, upon receipt of the Resv for the secondary LSP, brings down state
for the extra-LSP, and activates its cross-connect to switch from C-D ->
D-F to C-D -> D-B. However, since node C may not have done so, one again
has a misconnection with traffic flowing from E to B, instead of A to B.
So, it would be useful to have some text that makes explicit that
an intermediate node along the route of a secondary LSP must remove
the state, in the control and data planes, associated with the extra-LSP
(that uses resources required by the secondary LSP) before forwarding
the Path message for the secondary LSP.
A few more editorial comments:
i) If the text is under 1:1/Shared Mesh, why "under certain circumstances"
Haven't we established that the behavior suggested by Yoshihiko is needed
under _all_ circumstances.
ii) The phrase
> "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.
is unduly long and complicated. It should be broken up into smaller
sentences. Moreover, it is not always clear what
"refresh Resv" and "trigger Resv" refer to. Isn't a "refresh Resv"
a Resv corresponding to the Extra LSP and a "trigger Resv" a
Resv corresponding to the Extra LSP?
Thanks,
-Vishal
> -----Original Message-----
> From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org]On
> Behalf Of Dimitri.Papadimitriou@alcatel.be
> Sent: Wednesday, February 04, 2004 5:03 PM
> To: Yoshihiko SUEMURA; ccamp@ops.ietf.org
> Subject: Re: Protection object in resv message
>
>
> 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