Subject: Re: [mpls-tp] Comments to Efficient FRR using Facility backup in ring topology

From: Greg Mirsky <[email-masked]>
Date: Fri, 26 Mar 2010 00:20:14 -0700

Dear Sri,
thank you for your response. If understand correctly, the proposed
protection mechanism is a two-phase switchover since the switchover first is
done on PLR and then, while actual FRR's bypass tunnel is deployed, on
PLR-u. If that is the case, then I have concern whether this mechanism is
applicable to MPLS-TP because requirements 24 and 44 in RFC 5654 state the
MPLS-TP must avoid or minimize impact on transported customer's service
traffic, including its reordering. And reordering will happen because of
two-phase switchover.

Regards,
Greg

On Thu, Mar 25, 2010 at 6:25 PM, Sriganesh Kini <[email-masked]
> wrote:

>  See inline @ [Sri]
>
>
> - Sri
>
>
>  ------------------------------
> *From:* Greg Mirsky [mailto:[email-masked]]
> *Sent:* Thursday, March 25, 2010 6:15 PM
> *To:* Sriganesh Kini
> *Cc:* Autumn Liu; [email-masked]
>
> *Subject:* Re: Comments to Efficient FRR using Facility backup in ring
> topology
>
> Dear Sri,
> if by reference to how PLR-u selects an end-point for its bypass tunnel you
> meant "The traffic should be protection switched to a backup path
> terminating on a LSR along the protected LSP that is furthest downstream
> from the MP and has the protected and bypass LSPs going in the opposite
> directions", then I might offer another formula:
> "The remote end-point of a bypass LSR must be selected at first common,
> between PLR's bypass tunnel's path and the protected LSP, LSR taken in
> direction of the bypass tunnel."
> [Sri ] That alternate wording has already been used in the presentation -
> see slide 4
>
> As for reliability of the alert mechanism, I'd point that there are more
> moving parts in processing a packet in Switchover scenario than processing
> "normal" BFD packet. Latter is very often done completely in HW while former
> in SW. Hence the possible lack of reliability in processing while BFD
> session deemed Up.
> [Sri ] This is an implementation choice. The folks who implement it right
> will make it reliable.
>
> Note that by deploying FRR you already create congestion on L9-L8 link thus
> reducing reliability of the alert mechanism.
> [Sri ] The alert mechanism is a control-packet and should be handled at
> higher priority/reliability (than a data packet).
>
> FRR is viewed as temporary solution, in large part, because inefficiency
> you're addressing. End-to-end protection, in many cases, is capable to
> deliver identical to protected path service guarantees and might not require
> revertive action. I think that many of deployments have historical rather
> than technical explanation in which method been selected.
> [Sri ] With this in-efficiency addressed it should not be the case.
> End-to-end protection is more expensive. Facility backup is a scalable
> widely deployed protection mechanism.
>
>
> Regards,
> Greg
>
>
> On Thu, Mar 25, 2010 at 5:53 PM, Sriganesh Kini <
> [email-masked]> wrote:
>
>>  Greg, see inline @ [Sri]
>>
>>
>> - Sri
>>
>>
>>  ------------------------------
>> *From:* Greg Mirsky [mailto:[email-masked]]
>> *Sent:* Thursday, March 25, 2010 5:23 PM
>> *To:* Autumn Liu; Sriganesh Kini; [email-masked]
>> *Subject:* Re: Comments to Efficient FRR using Facility backup in ring
>> topology
>>
>>  Dear Authors,
>> please kindly consider my comments to the document:
>>
>>    - in Section 4.2 following assumption being made "Thus each LSR along
>>    the bypass receives the packet." I believe that there is no guarantee that
>>    each LSR along the bypass tunnel will receive the alert message, even if it
>>    will be sent three times. As result of this assumption most of conclusions
>>    regarding proposed solution look unfounded.
>>    [Sri ] The three times is immediately on failure. It is sent
>>    periodically later. If the very highly unlikely event that all three
>>    messages are dropped, then it means that there is a problem sending data
>>    packets on the bypass and other means (such as BFD and/or signaling) would
>>    indicate the problem. Such packet drop problems on the bypass should have
>>    been visible even before the failure and appropriate rectifying actions
>>    would have occurred.
>>    - in is not clear from the Section 4.3 Procedures at PLR whether PLR
>>    deploys its bypass tunnel locally as well as sets FLA bit in BFD message or
>>    totally relies on actions of PLR-u's
>>    [Sri ] PLR deploys the protection switch to bypass and sets FLA bit.
>>    - if the Merge Point of bypass tunnels set by PLR-u's is, using Fig.1
>>    and scenario from Section 3, L7, then the solution only solves half of the
>>    problem characteristic to Facility protection in a ring topology. Possible
>>    congestion on link L9-L8 might be avoided, but not on link L7-L6. To address
>>    this congestion, the MP must be changed when PLR-u sets its bypass.
>>    [Sri ] Seems you haven't understood the text in section 4 that
>>    describes how MP is chosen for a bypass from PLR-u. Also it seems you
>>    haven't read section 5 that clearly states that for traffic protection
>>    switched from PLR-u, the MP is at L6. There is NO congestion on L7-L6.
>>    - Introduction of PLR-u for all local protections along the protected
>>    LSR might create scaling problem and is not necessary (I'll try to explain
>>    that below).
>>    [Sri ] PLR-u is created at nodes along bypass LSP. The explanation
>>    below does not clearly state the scaling parameter you are concerned about.
>>
>> I still don't see value of alerting all LSR along the bypass tunnel that
>> provides local protection as well as all this transient LSRs being PLR-u.
>> What is really needed, in my view, is end-to-end or segment protection and a
>> way for LER/segment's head-end to learn about the failure along the
>> protected LSR fast enough. If one decides to run link layer OAM rather than
>> end-to-end or segment/TCM, then LSR, known as PLR, needs fast and reliable
>> method of notifying LER. But I don't see good technical reason to do that
>> when there are ways to avoid this problem.
>> [Sri ] Alerting all LSRs along the bypass helps to do protection switching
>> for all protected LSPs that are protected by the bypass. End-to-end
>> protection is not as scalable. That is why RFC4090 specified the scalable
>> FRR mechanism of facility backup and it is widely deployed. Your
>> observations on link-layer OAM, ...etc would have been useful if it had
>> details. Again note that our draft addresses general physical topologies
>> (not just ring).
>>
>> Regards,
>> Greg
>>
>>
>

---

From: Curtis Villamizar <[email-masked]>
Date: Sat, 27 Mar 2010 23:17:55 -0400

> traffic, including its reordering. And reordering will happen because of

Greg,

If the protect path has a longer delay there is a gap in service data
on failure and then reordering occurs on reversion.  It isn't
practical to eliminate all reordering (except dump traffic for a
predetermined period during any transition).

If the PLR swtiches to a PLR-u then there is a reorder event for each
such switch.  Its probably best to defer these swithovers so that
there is one reordering event involving the PLR-u furthest upstream.
Is that your point?  If reordering is reduced to one additional event,
it should be sufficient to mention the additional reordering event.

Curtis

---

From: Greg Mirsky <[email-masked]>
Date: Sat, 27 Mar 2010 21:32:18 -0700

Hi Curtis,
if I look at the protection tunnel created between PLR-u and MP-d (there's
no such definition in the document so I've invented it myself to avoid
convoluted definition of new merge point) I see a TCM that is terminated at
ingress and egress LSRs for the protected LSP(s). We know how to monitor
segments (TCM) and associate segment protection. Why make FRR into what it
is not - segment protection?
Besides, how long PLR should hold off its switchover to let PLR-u to switch?
Should PLR statistically measure round trip delay to PLR-u? And if we put
all these efforts to switch at PLR-u, what is the reason for tunnel between
FRR's PLR and MP? I'm really confused by motivation of this work. FRR -
acknowledged method for local protection and, I believe, should be used as
such. Trying to combine link local fault detection, fault signaling and
switchover at the headend - too many moving parts to work as fast and as
reliable as when detection and switchover are on the same node, be it PLR,
LER or headend of TCM.

Regards,
Greg