RE: Minimizing misconnections in restoration signaling [Was: (Correct ver.) Avoiding misconnections in restoration signaling]

["Vishal Sharma" <v.sharma@ieee.org>]

Dimitri,

Thanks for your comments. It will be good to have
the various clarifications and expanded text in the document.

I will be happy to contribute to and/or review the new text
(quite a bit of which should be derivable simply from what I
explained in my earlier emails, and also from the notes below).

A couple of important follow-on comments in-line.

-Vishal

PS: Forgot to put Lyndon on the CC list the last time
around. Sorry Lyndon.

> -----Original Message-----
> From: Dimitri.Papadimitriou@alcatel.be
> [mailto:Dimitri.Papadimitriou@alcatel.be]
> Sent: Thursday, March 11, 2004 4:53 AM
> To: Vishal Sharma
> Cc: Yoshihiko SUEMURA; ccamp@ops.ietf.org; Kohei Shiomoto
> Subject: Re: (Correct ver.) Avoiding misconnections in restoration
> signaling [Was: Protection obj. in restoration signaling]
>
>
> vishal, see in-line:
>
> > 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.
>
> it was assumed as inferred here below (from the
> discussion it was clear, otherwise there would have
> been no reason to do this)
>
> note as this was part of the discussion we had w/
> kohei concerning the detailed procedure - but since
> it seems that additional details are in expected in
> this document adding a paragraph along these lines
> will be done
>
> > 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 paragraph along the above lines will be added
>
> > 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.
>
> because it is a trade-off between recovery speed
> (also, nothing says that an operator must use the
> spare capacity) and resource efficiency usage -
> and there no reason to mandate one behaviour or
> another -

Let me see if I can elucidate a bit what you are saying.

-- You are arguing that even if spare capacity is in use (in
the shared mesh recovery case), the carrier/operator may _still_,
for faster recovery speed, choose to trade-off the possibility of
some amount of misconnection for recovery speed.

(Note the operator may choose to do something similar in the ordinary
pre-emption case as well (where recovery is not involved), but this is
something we need to look at when we work on the larger pre-emption
context brought up by Kohei.)

And so, there is no necessity to mandate that in the case where
spare capacity is in use the secondary LSP always be activated
in the upstream direction. It is an operator decision.

Ok, I can see that, and could agree with this line of reasoning.

-- You are also arguing that some resource efficiencies may
also be derived by the carrier, if they operate the network
as described above.

I am not sure I see this quite so clearly, but for the
purpose of this email, I'll take your word for it.

In any case, since in the 1:1/shared mesh case with extra traffic
misconnections can happen (even in the simplest cases), as
Yoshihiko's (and my) examples have illustrated, I think
that it is critical here to specify the behavior that one can
expect, even for an operator. (Kohei is an operator :-).)

What the text needs to do then, is to state what those
"certain circumstances" are under which misconnections can happen, and
specify what an operator could do to limit them (since they
cannot, as my related email
(http://ops.ietf.org/lists/ccamp/ccamp.2004/msg00230.html)
showed, be always eliminated/avoided).

It seems that the circumstances in question are simply "usage of the
spare (secondary LSP) capacity by extra traffic LSPs."

If there are other circumstances, it is probably worth thinking
about them, and listing them also. Or, failing that, at least stating
that "In certain circumstances, such as when the spare
capacity is in use by extra traffic, it MAY be ..."

In addition, some explanatory text should also be put in the document
discussing exactly what we have discussed above.

> cf. our previous discussion where you
> are doing the policing for the operator instead
> of defining the set of tools it can use

Unsure of which prior discussion you are referring to
here. Regardless, I do not think that if the document states
what we discussed above, and adds the corresponding explanatory
text, it would be mandating anything for the operator.

It would simply specify the way in which an operator could
minimize misconnections for the 1:1/Shared Mesh (with usage of
spare capacity) case, and ways in which the operator could
make recovery speed and resource efficiency trade-off decisions.

> now of example of circumstances can be further
> detailed as long as they are not constraining

Not sure I copy this ... Could you explain and/or
rephrase?

> > 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 Secondary LSP?
>
> will clarify,
>
> thanks,
> - dimitri.
>
> > Thanks,
> > -Vishal

<snipped>