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

From: Curtis Villamizar <[email-masked]>
Date: Sun, 28 Mar 2010 23:36:26 -0400

In message <[email-masked]>
Sriganesh Kini writes:
>  
>  
> Facility backup FRR is a widely deployed protection method and it is
> useful to make it efficient in specific cases where it is not. Just to
> re-iterate (again), this draft is applicable to MPLS and is for
> general topologies.
>  
> How PLR determines the round-trip delay to hold off for the switchover
> can be treated as a study topic for the applications that consider
> re-ordering for these miniscule time-scales relevant enough. The
> reason for the tunnel between PLR and MP is that such a bypass exists
> in the current deployment and also avoids a flag-day upgrade
> requirement.
>  
> Regarding observations on too many moving parts to work as
> fast/reliable, it would be useful if you can be specific on which part
> it is about and what the unreliability is. If the observation is from
> the point-of-view of a specific implementation, it would be considered
> out of scope of this draft.
>  
>  
> - Sri

Sri,

In the example

          G --- H --- H --- I
          |                 |
    A --- B --- C -X- D --- E --- F

The FRR protect path is from C to the merge point at E.  The ring
schemes move the protect back to B.  FRR leaves the protection at C.
I think you know that, just confirming.

FRR would normally protect traffic until A as ingress rerouted the
working path.  In the absense of a control plane, the management plane
would do this (maybe).  If there was a further alternate besides the
ring, then a protect path for the new A-F working path would be
brought up.

The question is whether the interim protection from B is valuable.  If
it is much faster than the reroute from ingress then it is valuable
because less capacity is needed to provide protection.  If there is no
reroute from ingress, then it is also valuable.  (That said, my
preference is facilities FRR, but I need to consider customer input -
which for us has not indicated a need for ring protection so far - but
that is only one data point).

I was just pointing out that there are extra reorder events and not
commenting on whether that was a problem or not.  I just said it
should be acknowledged in any ring protection document that proposes
such a mechanism.

Maybe I should ask you who you think is complaining about "too many
moving parts ... etc".  I don't follow the "flag day" issue you
brought up.

Curtis

> ________________________________
> From: Greg Mirsky [mailto:[email-masked]]
> Sent: Saturday, March 27, 2010 9:32 PM
> To: [email-masked]
> Cc: Sriganesh Kini; [email-masked]; [email-masked]
> Subject: Re: [mpls-tp] Comments to Efficient FRR using Facility backup in ring topology
>  
> 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
>  
> On Sat, Mar 27, 2010 at 8:17 PM, Curtis Villamizar <[email-masked]<mailto:[email-masked]>> wrote:
>  
> In message <[email-masked]<mailto:[email-masked]>>
> Greg Mirsky writes:
> >
> >
> > 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
>  
>  
> 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
>  
>  
> > On Thu, Mar 25, 2010 at 6:25 PM, Sriganesh Kini <[email-masked]<mailto:[email-masked]>
> > > wrote:
> >
> > >  See inline @ [Sri]
> > >
> > >
> > > - Sri
> > >
> > >
> > >  ------------------------------
> > > *From:* Greg Mirsky [mailto:[email-masked]<mailto:gregimirsky@gm=
> ail.com>]
> > > *Sent:* Thursday, March 25, 2010 6:15 PM
> > > *To:* Sriganesh Kini
> > > *Cc:* Autumn Liu; [email-masked]<mailto:[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 downstrea=
> m
> > > 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 mor=
> e
> > > moving parts in processing a packet in Switchover scenario than process=
> ing
> > > "normal" BFD packet. Latter is very often done completely in HW while f=
> ormer
> > > 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 rig=
> ht
> > > 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 inefficienc=
> y
> > > you're addressing. End-to-end protection, in many cases, is capable to
> > > deliver identical to protected path service guarantees and might not re=
> quire
> > > revertive action. I think that many of deployments have historical rath=
> er
> > > 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]<mailto:[email-masked]>> wrote:
> > >
> > >>  Greg, see inline @ [Sri]
> > >>
> > >>
> > >> - Sri
> > >>
> > >>
> > >>  ------------------------------
> > >> *From:* Greg Mirsky [mailto:[email-masked]<mailto:gregimirsky@g=
> mail.com>]
> > >> *Sent:* Thursday, March 25, 2010 5:23 PM
> > >> *To:* Autumn Liu; Sriganesh Kini; [email-masked]<mailto:[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 alo=
> ng
> > >>    the bypass receives the packet." I believe that there is no guarant=
> ee that
> > >>    each LSR along the bypass tunnel will receive the alert message, ev=
> en if it
> > >>    will be sent three times. As result of this assumption most of conc=
> lusions
> > >>    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 thre=
> e
> > >>    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 shoul=
> d have
> > >>    been visible even before the failure and appropriate rectifying act=
> ions
> > >>    would have occurred.
> > >>    - in is not clear from the Section 4.3 Procedures at PLR whether PL=
> R
> > >>    deploys its bypass tunnel locally as well as sets FLA bit in BFD me=
> ssage 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. P=
> ossible
> > >>    congestion on link L9-L8 might be avoided, but not on link L7-L6. T=
> o 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 y=
> ou
> > >>    haven't read section 5 that clearly states that for traffic protect=
> ion
> > >>    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 protect=
> ed
> > >>    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 concerne=
> d about.
> > >>
> > >> I still don't see value of alerting all LSR along the bypass tunnel th=
> at
> > >> 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 reli=
> able
> > >> method of notifying LER. But I don't see good technical reason to do t=
> hat
> > >> when there are ways to avoid this problem.
> > >> [Sri ] Alerting all LSRs along the bypass helps to do protection switc=
> hing
> > >> for all protected LSPs that are protected by the bypass. End-to-end
> > >> protection is not as scalable. That is why RFC4090 specified the scala=
> ble
> > >> FRR mechanism of facility backup and it is widely deployed. Your
> > >> observations on link-layer OAM, ...etc would have been useful if it ha=
> d
> > >> details. Again note that our draft addresses general physical topologi=
> es
> > >> (not just ring).
> > >>
> > >> Regards,
> > >> Greg
>  
>  
> --_000_5A5E55DF96F73844AF7DFB0F48721F0F52E47A75CCEUSAACMS0703e_
> Content-Type: text/html; charset="us-ascii"
> Content-Transfer-Encoding: quoted-printable
>  
> <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
> <HTML><HEAD>
> <META http-equiv=3DContent-Type content=3D"text/html; charset=3Dus-ascii">
> <META content=3D"MSHTML 6.00.6001.18385" name=3DGENERATOR></HEAD>
> <BODY>
> <DIV dir=3Dltr align=3Dleft><SPAN class=3D129390507-28032010><FONT face=3DA=
> rial=20
> color=3D#0000ff size=3D2>Facility backup FRR is a widely deployed protectio=
> n method=20
> and it is useful to make it efficient in specific cases where it is not. Ju=
> st to=20
> re-iterate (again), this draft is applicable to MPLS and is for general=20
> topologies. </FONT></SPAN></DIV>
> <DIV dir=3Dltr align=3Dleft><SPAN class=3D129390507-28032010><FONT face=3DA=
> rial=20
> color=3D#0000ff size=3D2></FONT></SPAN>&nbsp;</DIV>
> <DIV dir=3Dltr align=3Dleft><SPAN class=3D129390507-28032010><FONT face=3DA=
> rial=20
> color=3D#0000ff size=3D2>How PLR&nbsp;determines the round-trip delay to=20
> hold&nbsp;off for the switchover can be treated as a study topic for the=20
> applications that consider re-ordering for these miniscule time-scales rele=
> vant=20
> enough. The reason for the tunnel between PLR and MP&nbsp;is that such a by=
> pass=20
> exists in the current deployment and also avoids a flag-day upgrade=20
> requirement.</FONT></SPAN></DIV>
> <DIV><FONT face=3DArial color=3D#0000ff size=3D2></FONT>&nbsp;</DIV>
> <DIV><SPAN class=3D129390507-28032010><FONT face=3DArial color=3D#0000ff=20
> size=3D2>Regarding observations on too many moving parts to work as fast/re=
> liable,=20
> it would be useful if you can be specific on which part it is about and wha=
> t the=20
> unreliability is. If the observation is&nbsp;from the point-of-view of&nbsp=
> ;a=20
> specific implementation, it would be considered out of scope of this=20
> draft.</FONT></SPAN></DIV>
> <DIV><SPAN class=3D129390507-28032010><FONT face=3DArial color=3D#0000ff=20
> size=3D2></FONT></SPAN>&nbsp;</DIV><!-- Converted from text/rtf format -->
> <P><SPAN lang=3Den-us><FONT face=3DArial size=3D2>- Sri</FONT></SPAN> </P>
> <DIV><FONT face=3DArial color=3D#0000ff size=3D2></FONT>&nbsp;</DIV><FONT f=
> ace=3DArial=20
> size=3D2></FONT><FONT face=3DArial size=3D2></FONT><FONT face=3DArial=20
> size=3D2></FONT><FONT face=3DArial size=3D2></FONT><BR>
> <BLOCKQUOTE style=3D"MARGIN-RIGHT: 0px">
>   <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr align=3Dleft>
>   <HR tabIndex=3D-1>
>   <FONT face=3DTahoma size=3D2><B>From:</B> Greg Mirsky=20
>   [mailto:[email-masked]] <BR><B>Sent:</B> Saturday, March 27, 2010 =
> 9:32=20
>   PM<BR><B>To:</B> [email-masked]<BR><B>Cc:</B> Sriganesh Kini; mpls@ietf=
> .org;=20
>   [email-masked]<BR><B>Subject:</B> Re: [mpls-tp] Comments to Efficient F=
> RR=20
>   using Facility backup in ring topology<BR></FONT><BR></DIV>
>   <DIV></DIV>Hi Curtis,<BR>if I look at the protection tunnel created betwe=
> en=20
>   PLR-u and MP-d (there's no such definition in the document so I've invent=
> ed it=20
>   myself to avoid convoluted definition of new merge point) I see a TCM tha=
> t is=20
>   terminated at ingress and egress LSRs for the protected LSP(s). We know h=
> ow to=20
>   monitor segments (TCM) and associate segment protection. Why make FRR int=
> o=20
>   what it is not - segment protection?<BR>Besides, how long PLR should hold=
>  off=20
>   its switchover to let PLR-u to switch? Should PLR statistically measure r=
> ound=20
>   trip delay to PLR-u? And if we put all these efforts to switch at PLR-u, =
> what=20
>   is the reason for tunnel between FRR's PLR and MP? I'm really confused by=
> =20
>   motivation of this work. FRR - acknowledged method for local protection a=
> nd, I=20
>   believe, should be used as such. Trying to combine link local fault detec=
> tion,=20
>   fault signaling and switchover at the headend - too many moving parts to =
> work=20
>   as fast and as reliable as when detection and switchover are on the same =
> node,=20
>   be it PLR, LER or headend of TCM. <BR><BR>Regards,<BR>Greg<BR><BR>
>   <DIV class=3Dgmail_quote>On Sat, Mar 27, 2010 at 8:17 PM, Curtis Villamiz=
> ar=20
>   <SPAN dir=3Dltr>&lt;<A=20
>   href=3D"mailto:[email-masked]">[email-masked]</A>&gt;</SPAN> wrote:<B=
> R>
>   <BLOCKQUOTE class=3Dgmail_quote=20
>   style=3D"PADDING-LEFT: 1ex; MARGIN: 0pt 0pt 0pt 0.8ex; BORDER-LEFT: rgb(2=
> 04,204,204) 1px solid"><BR>In=20
>     message &lt;<A=20
>     href=3D"mailto:[email-masked]=
> om">[email-masked]</A>&gt;<BR>
>     <DIV class=3Dim>Greg Mirsky writes:<BR>&gt;<BR>&gt;<BR>&gt; Dear Sri,<B=
> R>&gt;=20
>     thank you for your response. If understand correctly, the proposed<BR>&=
> gt;=20
>     protection mechanism is a two-phase switchover since the switchover fir=
> st=20
>     is<BR>&gt; done on PLR and then, while actual FRR's bypass tunnel is=20
>     deployed, on<BR>&gt; PLR-u. If that is the case, then I have concern wh=
> ether=20
>     this mechanism is<BR>&gt; applicable to MPLS-TP because requirements 24=
>  and=20
>     44 in RFC 5654 state the<BR>&gt; MPLS-TP must avoid or minimize impact =
> on=20
>     transported customer's service<BR>&gt; traffic, including its reorderin=
> g.=20
>     And reordering will happen because of<BR>&gt; two-phase=20
>     switchover.<BR>&gt;<BR>&gt; Regards,<BR>&gt;=20
>     Greg<BR><BR><BR></DIV>Greg,<BR><BR>If the protect path has a longer del=
> ay=20
>     there is a gap in service data<BR>on failure and then reordering occurs=
>  on=20
>     reversion. &nbsp;It isn't<BR>practical to eliminate all reordering (exc=
> ept=20
>     dump traffic for a<BR>predetermined period during any transition).<BR><=
> BR>If=20
>     the PLR swtiches to a PLR-u then there is a reorder event for each<BR>s=
> uch=20
>     switch. &nbsp;Its probably best to defer these swithovers so that<BR>th=
> ere=20
>     is one reordering event involving the PLR-u furthest upstream.<BR>Is th=
> at=20
>     your point? &nbsp;If reordering is reduced to one additional event,<BR>=
> it=20
>     should be sufficient to mention the additional reordering event.<BR><FO=
> NT=20
>     color=3D#888888><BR>Curtis<BR></FONT>
>     <DIV>
>     <DIV></DIV>
>     <DIV class=3Dh5><BR><BR>&gt; On Thu, Mar 25, 2010 at 6:25 PM, Sriganesh=
>  Kini=20
>     &lt;<A=20
>     href=3D"mailto:[email-masked]">[email-masked]=
> </A><BR>&gt;=20
>     &gt; wrote:<BR>&gt;<BR>&gt; &gt; &nbsp;See inline @ [Sri]<BR>&gt;=20
>     &gt;<BR>&gt; &gt;<BR>&gt; &gt; - Sri<BR>&gt; &gt;<BR>&gt; &gt;<BR>&gt; =
> &gt;=20
>     &nbsp;------------------------------<BR>&gt; &gt; *From:* Greg Mirsky=20
>     [mailto:<A=20
>     href=3D"mailto:[email-masked]">[email-masked]</A>]<BR>&gt=
> ; &gt;=20
>     *Sent:* Thursday, March 25, 2010 6:15 PM<BR>&gt; &gt; *To:* Sriganesh=20
>     Kini<BR>&gt; &gt; *Cc:* Autumn Liu; <A=20
>     href=3D"mailto:[email-masked]">[email-masked]</A><BR>&gt; &gt;<BR>&gt; &g=
> t;=20
>     *Subject:* Re: Comments to Efficient FRR using Facility backup in=20
>     ring<BR>&gt; &gt; topology<BR>&gt; &gt;<BR>&gt; &gt; Dear Sri,<BR>&gt; =
> &gt;=20
>     if by reference to how PLR-u selects an end-point for its bypass tunnel=
> =20
>     you<BR>&gt; &gt; meant "The traffic should be protection switched to a=
> =20
>     backup path<BR>&gt; &gt; terminating on a LSR along the protected LSP t=
> hat=20
>     is furthest downstream<BR>&gt; &gt; from the MP and has the protected a=
> nd=20
>     bypass LSPs going in the opposite<BR>&gt; &gt; directions", then I migh=
> t=20
>     offer another formula:<BR>&gt; &gt; "The remote end-point of a bypass L=
> SR=20
>     must be selected at first common,<BR>&gt; &gt; between PLR's bypass tun=
> nel's=20
>     path and the protected LSP, LSR taken in<BR>&gt; &gt; direction of the=
> =20
>     bypass tunnel."<BR>&gt; &gt; [Sri ] That alternate wording has already =
> been=20
>     used in the presentation -<BR>&gt; &gt; see slide 4<BR>&gt; &gt;<BR>&gt=
> ;=20
>     &gt; As for reliability of the alert mechanism, I'd point that there ar=
> e=20
>     more<BR>&gt; &gt; moving parts in processing a packet in Switchover sce=
> nario=20
>     than processing<BR>&gt; &gt; "normal" BFD packet. Latter is very often =
> done=20
>     completely in HW while former<BR>&gt; &gt; in SW. Hence the possible la=
> ck of=20
>     reliability in processing while BFD<BR>&gt; &gt; session deemed Up.<BR>=
> &gt;=20
>     &gt; [Sri ] This is an implementation choice. The folks who implement i=
> t=20
>     right<BR>&gt; &gt; will make it reliable.<BR>&gt; &gt;<BR>&gt; &gt; Not=
> e=20
>     that by deploying FRR you already create congestion on L9-L8 link=20
>     thus<BR>&gt; &gt; reducing reliability of the alert mechanism.<BR>&gt; =
> &gt;=20
>     [Sri ] The alert mechanism is a control-packet and should be handled=20
>     at<BR>&gt; &gt; higher priority/reliability (than a data packet).<BR>&g=
> t;=20
>     &gt;<BR>&gt; &gt; FRR is viewed as temporary solution, in large part,=20
>     because inefficiency<BR>&gt; &gt; you're addressing. End-to-end protect=
> ion,=20
>     in many cases, is capable to<BR>&gt; &gt; deliver identical to protecte=
> d=20
>     path service guarantees and might not require<BR>&gt; &gt; revertive ac=
> tion.=20
>     I think that many of deployments have historical rather<BR>&gt; &gt; th=
> an=20
>     technical explanation in which method been selected.<BR>&gt; &gt; [Sri =
> ]=20
>     With this in-efficiency addressed it should not be the case.<BR>&gt; &g=
> t;=20
>     End-to-end protection is more expensive. Facility backup is a=20
>     scalable<BR>&gt; &gt; widely deployed protection mechanism.<BR>&gt;=20
>     &gt;<BR>&gt; &gt;<BR>&gt; &gt; Regards,<BR>&gt; &gt; Greg<BR>&gt;=20
>     &gt;<BR>&gt; &gt; On Thu, Mar 25, 2010 at 5:53 PM, Sriganesh Kini=20
>     &lt;<BR>&gt; &gt; <A=20
>     href=3D"mailto:[email-masked]">[email-masked]=
> </A>&gt;=20
>     wrote:<BR>&gt; &gt;<BR>&gt; &gt;&gt; &nbsp;Greg, see inline @ [Sri]<BR>=
> &gt;=20
>     &gt;&gt;<BR>&gt; &gt;&gt;<BR>&gt; &gt;&gt; - Sri<BR>&gt; &gt;&gt;<BR>&g=
> t;=20
>     &gt;&gt;<BR>&gt; &gt;&gt; &nbsp;------------------------------<BR>&gt;=
> =20
>     &gt;&gt; *From:* Greg Mirsky [mailto:<A=20
>     href=3D"mailto:[email-masked]">[email-masked]</A>]<BR>&gt=
> ;=20
>     &gt;&gt; *Sent:* Thursday, March 25, 2010 5:23 PM<BR>&gt; &gt;&gt; *To:=
> *=20
>     Autumn Liu; Sriganesh Kini; <A=20
>     href=3D"mailto:[email-masked]">[email-masked]</A><BR>&gt; &gt;&gt; *Subje=
> ct:*=20
>     Re: Comments to Efficient FRR using Facility backup in ring<BR>&gt; &gt=
> ;&gt;=20
>     topology<BR>&gt; &gt;&gt;<BR>&gt; &gt;&gt; &nbsp;Dear Authors,<BR>&gt;=
> =20
>     &gt;&gt; please kindly consider my comments to the document:<BR>&gt;=20
>     &gt;&gt;<BR>&gt; &gt;&gt; &nbsp; &nbsp;- in Section 4.2 following assum=
> ption=20
>     being made "Thus each LSR along<BR>&gt; &gt;&gt; &nbsp; &nbsp;the bypas=
> s=20
>     receives the packet." I believe that there is no guarantee that<BR>&gt;=
> =20
>     &gt;&gt; &nbsp; &nbsp;each LSR along the bypass tunnel will receive the=
> =20
>     alert message, even if it<BR>&gt; &gt;&gt; &nbsp; &nbsp;will be sent th=
> ree=20
>     times. As result of this assumption most of conclusions<BR>&gt; &gt;&gt=
> ;=20
>     &nbsp; &nbsp;regarding proposed solution look unfounded.<BR>&gt; &gt;&g=
> t;=20
>     &nbsp; &nbsp;[Sri ] The three times is immediately on failure. It is=20
>     sent<BR>&gt; &gt;&gt; &nbsp; &nbsp;periodically later. If the very high=
> ly=20
>     unlikely event that all three<BR>&gt; &gt;&gt; &nbsp; &nbsp;messages ar=
> e=20
>     dropped, then it means that there is a problem sending data<BR>&gt; &gt=
> ;&gt;=20
>     &nbsp; &nbsp;packets on the bypass and other means (such as BFD and/or=
> =20
>     signaling) would<BR>&gt; &gt;&gt; &nbsp; &nbsp;indicate the problem. Su=
> ch=20
>     packet drop problems on the bypass should have<BR>&gt; &gt;&gt; &nbsp;=
> =20
>     &nbsp;been visible even before the failure and appropriate rectifying=20
>     actions<BR>&gt; &gt;&gt; &nbsp; &nbsp;would have occurred.<BR>&gt; &gt;=
> &gt;=20
>     &nbsp; &nbsp;- in is not clear from the Section 4.3 Procedures at PLR=20
>     whether PLR<BR>&gt; &gt;&gt; &nbsp; &nbsp;deploys its bypass tunnel loc=
> ally=20
>     as well as sets FLA bit in BFD message or<BR>&gt; &gt;&gt; &nbsp;=20
>     &nbsp;totally relies on actions of PLR-u's<BR>&gt; &gt;&gt; &nbsp;=20
>     &nbsp;[Sri ] PLR deploys the protection switch to bypass and sets FLA=20
>     bit.<BR>&gt; &gt;&gt; &nbsp; &nbsp;- if the Merge Point of bypass tunne=
> ls=20
>     set by PLR-u's is, using Fig.1<BR>&gt; &gt;&gt; &nbsp; &nbsp;and scenar=
> io=20
>     from Section 3, L7, then the solution only solves half of the<BR>&gt;=20
>     &gt;&gt; &nbsp; &nbsp;problem characteristic to Facility protection in =
> a=20
>     ring topology. Possible<BR>&gt; &gt;&gt; &nbsp; &nbsp;congestion on lin=
> k=20
>     L9-L8 might be avoided, but not on link L7-L6. To address<BR>&gt; &gt;&=
> gt;=20
>     &nbsp; &nbsp;this congestion, the MP must be changed when PLR-u sets it=
> s=20
>     bypass.<BR>&gt; &gt;&gt; &nbsp; &nbsp;[Sri ] Seems you haven't understo=
> od=20
>     the text in section 4 that<BR>&gt; &gt;&gt; &nbsp; &nbsp;describes how =
> MP is=20
>     chosen for a bypass from PLR-u. Also it seems you<BR>&gt; &gt;&gt; &nbs=
> p;=20
>     &nbsp;haven't read section 5 that clearly states that for traffic=20
>     protection<BR>&gt; &gt;&gt; &nbsp; &nbsp;switched from PLR-u, the MP is=
>  at=20
>     L6. There is NO congestion on L7-L6.<BR>&gt; &gt;&gt; &nbsp; &nbsp;-=20
>     Introduction of PLR-u for all local protections along the protected<BR>=
> &gt;=20
>     &gt;&gt; &nbsp; &nbsp;LSR might create scaling problem and is not neces=
> sary=20
>     (I'll try to explain<BR>&gt; &gt;&gt; &nbsp; &nbsp;that below).<BR>&gt;=
> =20
>     &gt;&gt; &nbsp; &nbsp;[Sri ] PLR-u is created at nodes along bypass LSP=
> . The=20
>     explanation<BR>&gt; &gt;&gt; &nbsp; &nbsp;below does not clearly state =
> the=20
>     scaling parameter you are concerned about.<BR>&gt; &gt;&gt;<BR>&gt; &gt=
> ;&gt;=20
>     I still don't see value of alerting all LSR along the bypass tunnel=20
>     that<BR>&gt; &gt;&gt; provides local protection as well as all this=20
>     transient LSRs being PLR-u.<BR>&gt; &gt;&gt; What is really needed, in =
> my=20
>     view, is end-to-end or segment protection and a<BR>&gt; &gt;&gt; way fo=
> r=20
>     LER/segment's head-end to learn about the failure along the<BR>&gt; &gt=
> ;&gt;=20
>     protected LSR fast enough. If one decides to run link layer OAM rather=
> =20
>     than<BR>&gt; &gt;&gt; end-to-end or segment/TCM, then LSR, known as PLR=
> ,=20
>     needs fast and reliable<BR>&gt; &gt;&gt; method of notifying LER. But I=
> =20
>     don't see good technical reason to do that<BR>&gt; &gt;&gt; when there =
> are=20
>     ways to avoid this problem.<BR>&gt; &gt;&gt; [Sri ] Alerting all LSRs a=
> long=20
>     the bypass helps to do protection switching<BR>&gt; &gt;&gt; for all=20
>     protected LSPs that are protected by the bypass. End-to-end<BR>&gt; &gt=
> ;&gt;=20
>     protection is not as scalable. That is why RFC4090 specified the=20
>     scalable<BR>&gt; &gt;&gt; FRR mechanism of facility backup and it is wi=
> dely=20
>     deployed. Your<BR>&gt; &gt;&gt; observations on link-layer OAM, ...etc =
> would=20
>     have been useful if it had<BR>&gt; &gt;&gt; details. Again note that ou=
> r=20
>     draft addresses general physical topologies<BR>&gt; &gt;&gt; (not just=
> =20
>     ring).<BR>&gt; &gt;&gt;<BR>&gt; &gt;&gt; Regards,<BR>&gt; &gt;&gt;=20
>     Greg<BR></DIV></DIV></BLOCKQUOTE></DIV><BR>
>   <DIV id=3Davg_ls_inline_popup=20
>   style=3D"DISPLAY: inline; VISIBILITY: hidden"></DIV><FONT face=3DArial=20
>   color=3D#0000ff size=3D2></FONT><FONT face=3DArial color=3D#0000ff=20
> size=3D2></FONT></BLOCKQUOTE>
> <STYLE type=3Dtext/css>#avg_ls_inline_popup {
> 	PADDING-RIGHT: 0px; MARGIN-TOP: 0px; PADDING-LEFT: 0px; FONT-SIZE: 10px; Z=
> -INDEX: 9999; PADDING-BOTTOM: 0px; MARGIN-LEFT: 0px; OVERFLOW: hidden; WIDT=
> H: 240px; COLOR: black; LINE-HEIGHT: 13px; PADDING-TOP: 0px; POSITION: abso=
> lute; TEXT-ALIGN: left; WORD-WRAP: break-word
> }
> </STYLE>
> </BODY></HTML>
>  
> --_000_5A5E55DF96F73844AF7DFB0F48721F0F52E47A75CCEUSAACMS0703e_--

---

From: Sriganesh Kini <[email-masked]>
Date: Mon, 29 Mar 2010 01:57:25 -0400

Hi Curtis, see inline @ [Sri]

- Sri

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Sunday, March 28, 2010 8:36 PM
To: Sriganesh Kini
Cc: Greg Mirsky; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [mpls-tp] Comments to Efficient FRR using Facility backup in ring topology

Sri,

In the example

          G --- H --- H --- I
          |                 |

The FRR protect path is from C to the merge point at E.  The ring schemes move the protect back to B.  FRR leaves the protection at C.
I think you know that, just confirming.

[Sri] Yes. A minor caveat is that if it is a link (C-D) bypass then MP for the FRR bypass from PLR (C) is at D.

FRR would normally protect traffic until A as ingress rerouted the working path.  In the absense of a control plane, the management plane would do this (maybe).  If there was a further alternate besides the ring, then a protect path for the new A-F working path would be brought up.

[Sri] Agree.

The question is whether the interim protection from B is valuable.  If it is much faster than the reroute from ingress then it is valuable because less capacity is needed to provide protection.  If there is no reroute from ingress, then it is also valuable.  (That said, my preference is facilities FRR, but I need to consider customer input - which for us has not indicated a need for ring protection so far - but that is only one data point).

[Sri] Note that protection from PLR-u is also valuable due to it being faster at higher scale. E.g consider the example in the draft where there are a large number of protected LSPs routed via L8->L7. If the backup LSP from PLR-u is setup as a bypass, then all the LSPs entering/exiting the ring through common points (and going through L8-L7) can be protected by a single bypass (for each entry/exit point). A very simple protection switch operation at each PLR-u can protect a large number of LSPs. This should be faster than the ingress re-routing each protected LSP individually.

I was just pointing out that there are extra reorder events and not commenting on whether that was a problem or not.  I just said it should be acknowledged in any ring protection document that proposes such a mechanism.

[Sri] Accepted

Maybe I should ask you who you think is complaining about "too many moving parts ... etc".  I don't follow the "flag day" issue you brought up.

[Sri] The comment about "too many moving parts" was from Greg. He also commented "And if we put all these efforts to switch at PLR-u, what is the reason for tunnel between FRR's PLR and MP?". There is a simpler reason for that. To protect LSPs across the link (LSP C->D in your example above and a LSP L8->L7 in the example in the draft).

Curtis

> know how to monitor segments (TCM) and associate segment protection.
> Why make FRR into what it is not - segment protection?
>
> In message
> <[email-masked]<mailto:787
> [email-masked]>>
> Greg Mirsky writes:
> >
> >
> > Dear Sri,
> > 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
>
>
> Greg,
>
> > On Thu, Mar 25, 2010 at 6:25 PM, Sriganesh Kini
> > <[email-masked]<mailto:[email-masked]>
> > > wrote:
> >
> > >  See inline @ [Sri]
> > >
> > >
> > > - Sri
> > >
> > >
> > > *From:* Greg Mirsky
> > > [mailto:[email-masked]<mailto:gregimirsky@gm=
> ail.com>]
> > > *Subject:* Re: Comments to Efficient FRR using Facility backup in
> > > ring topology
> > >
> > > Dear Sri,
> > > 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."
> > > in SW. Hence the possible lack of reliability in processing while
> > > BFD session deemed Up.
> > > [Sri ] The alert mechanism is a control-packet and should be
> > > handled at higher priority/reliability (than a data packet).
> > >
> > > you're addressing. End-to-end protection, in many cases, is
> > > capable to deliver identical to protected path service guarantees
> > > and might not re=
> quire
> > > End-to-end protection is more expensive. Facility backup is a
> > > scalable widely deployed protection mechanism.
> > >
> > >
> > > Regards,
> > > Greg
> > >
> > >> *From:* Greg Mirsky
> > >> [mailto:[email-masked]<mailto:gregimirsky@g=
> mail.com>]
> > >> *Subject:* Re: Comments to Efficient FRR using Facility backup in
> > >> ring topology
> > >>
> > >>  Dear Authors,
> > >> 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
> > >> for all protected LSPs that are protected by the bypass.
> > >> End-to-end protection is not as scalable. That is why RFC4090
> > >> specified the scala=
> ble
> <HTML><HEAD> <META http-equiv=3DContent-Type content=3D"text/html;
> charset=3Dus-ascii"> <META content=3D"MSHTML 6.00.6001.18385"
> name=3DGENERATOR></HEAD> <BODY> <DIV dir=3Dltr align=3Dleft><SPAN
> class=3D129390507-28032010><FONT face=3DA= rial=20 color=3D#0000ff
> size=3D2>Facility backup FRR is a widely deployed protectio= n
> method=20 and it is useful to make it efficient in specific cases
> where it is not. Ju= st to=20 re-iterate (again), this draft is
> applicable to MPLS and is for general=20 topologies.
> </FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN
> class=3D129390507-28032010><FONT face=3DA= rial=20 color=3D#0000ff
> size=3D2></FONT></SPAN>&nbsp;</DIV>
> <DIV dir=3Dltr align=3Dleft><SPAN class=3D129390507-28032010><FONT
> face=3DA= rial=20 color=3D#0000ff size=3D2>How PLR&nbsp;determines the
> round-trip delay to=20 hold&nbsp;off for the switchover can be treated
> as a study topic for the=20 applications that consider re-ordering for
> these miniscule time-scales rele= vant=20 enough. The reason for the
> tunnel between PLR and MP&nbsp;is that such a by= pass=20 exists in
> the current deployment and also avoids a flag-day upgrade=20
> requirement.</FONT></SPAN></DIV> <DIV><FONT face=3DArial
> color=3D#0000ff size=3D2></FONT>&nbsp;</DIV> <DIV><SPAN
> class=3D129390507-28032010><FONT face=3DArial color=3D#0000ff=20
> size=3D2>Regarding observations on too many moving parts to work as
> fast/re= liable,=20 it would be useful if you can be specific on which
> part it is about and wha= t the=20 unreliability is. If the
> observation is&nbsp;from the point-of-view of&nbsp= ;a=20 specific
> implementation, it would be considered out of scope of this=20
> draft.</FONT></SPAN></DIV> <DIV><SPAN class=3D129390507-28032010><FONT
> face=3DArial color=3D#0000ff=20
> size=3D2></FONT></SPAN>&nbsp;</DIV><!-- Converted from text/rtf format
> --> <P><SPAN lang=3Den-us><FONT face=3DArial size=3D2>-
> Sri</FONT></SPAN> </P> <DIV><FONT face=3DArial color=3D#0000ff
> size=3D2></FONT>&nbsp;</DIV><FONT f= ace=3DArial=20
> size=3D2></FONT><FONT face=3DArial size=3D2></FONT><FONT
> face=3DArial=20 size=3D2></FONT><FONT face=3DArial
> size=3D2></FONT><BR> <BLOCKQUOTE style=3D"MARGIN-RIGHT: 0px">
>   [mailto:[email-masked]] <BR><B>Sent:</B> Saturday, March 27,
> 2010 = 9:32=20
>   PM<BR><B>To:</B> [email-masked]<BR><B>Cc:</B> Sriganesh Kini;
> mpls@ietf= .org;=20
>   [email-masked]<BR><B>Subject:</B> Re: [mpls-tp] Comments to
> Efficient F= RR=20
>   <DIV></DIV>Hi Curtis,<BR>if I look at the protection tunnel created
> betwe= en=20
>   PLR-u and MP-d (there's no such definition in the document so I've
> invent= ed it=20
>   myself to avoid convoluted definition of new merge point) I see a
> TCM tha= t is=20
> know h= ow to=20
>   monitor segments (TCM) and associate segment protection. Why make
> FRR int= o=20
>   what it is not - segment protection?<BR>Besides, how long PLR should
> hold=  off=20
>   its switchover to let PLR-u to switch? Should PLR statistically
> measure r= ound=20
>   trip delay to PLR-u? And if we put all these efforts to switch at
> PLR-u, = what=20
>   is the reason for tunnel between FRR's PLR and MP? I'm really
> confused by= =20
>   motivation of this work. FRR - acknowledged method for local
> protection a= nd, I=20
> detec= tion,=20
>   fault signaling and switchover at the headend - too many moving
> parts to = work=20
>   as fast and as reliable as when detection and switchover are on the
> same = node,=20
>   <DIV class=3Dgmail_quote>On Sat, Mar 27, 2010 at 8:17 PM, Curtis
> Villamiz= ar=20
>     thank you for your response. If understand correctly, the
> proposed<BR>&= gt;=20
>     protection mechanism is a two-phase switchover since the
> switchover fir= st=20
>     deployed, on<BR>&gt; PLR-u. If that is the case, then I have
> concern wh= ether=20
>     this mechanism is<BR>&gt; applicable to MPLS-TP because
> requirements 24=  and=20
>     44 in RFC 5654 state the<BR>&gt; MPLS-TP must avoid or minimize
> impact = on=20
>     transported customer's service<BR>&gt; traffic, including its
> reorderin= g.=20
>     Greg<BR><BR><BR></DIV>Greg,<BR><BR>If the protect path has a
> longer del= ay=20
>     there is a gap in service data<BR>on failure and then reordering
> occurs=  on=20
>     reversion. &nbsp;It isn't<BR>practical to eliminate all reordering
> (exc= ept=20
>     the PLR swtiches to a PLR-u then there is a reorder event for
> each<BR>s= uch=20
>     switch. &nbsp;Its probably best to defer these swithovers so
> that<BR>th= ere=20
>     is one reordering event involving the PLR-u furthest
> upstream.<BR>Is th= at=20
>     your point? &nbsp;If reordering is reduced to one additional
> event,<BR>= it=20
>     should be sufficient to mention the additional reordering
> event.<BR><FO= NT=20
>     <DIV class=3Dh5><BR><BR>&gt; On Thu, Mar 25, 2010 at 6:25 PM,
> Sriganesh=  Kini=20
>     &lt;<A=20
>
>     &gt;<BR>&gt; &gt;<BR>&gt; &gt; - Sri<BR>&gt; &gt;<BR>&gt;
> &gt;<BR>&gt; = &gt;=20
>     href=3D"mailto:[email-masked]">[email-masked]</A><BR>&gt;
> &gt;<BR>&gt; &g= t;=20
>     ring<BR>&gt; &gt; topology<BR>&gt; &gt;<BR>&gt; &gt; Dear
> Sri,<BR>&gt; = &gt;=20
>     if by reference to how PLR-u selects an end-point for its bypass
> tunnel= =20
>     you<BR>&gt; &gt; meant "The traffic should be protection switched
> to a= =20
>     backup path<BR>&gt; &gt; terminating on a LSR along the protected
> LSP t= hat=20
>     is furthest downstream<BR>&gt; &gt; from the MP and has the
> protected a= nd=20
>     bypass LSPs going in the opposite<BR>&gt; &gt; directions", then I
> migh= t=20
>     offer another formula:<BR>&gt; &gt; "The remote end-point of a
> bypass L= SR=20
>     must be selected at first common,<BR>&gt; &gt; between PLR's
> bypass tun= nel's=20
>     path and the protected LSP, LSR taken in<BR>&gt; &gt; direction of
> the= =20
>     bypass tunnel."<BR>&gt; &gt; [Sri ] That alternate wording has
> already = been=20
>     used in the presentation -<BR>&gt; &gt; see slide 4<BR>&gt;
> &gt;<BR>&gt= ;=20
>     &gt; As for reliability of the alert mechanism, I'd point that
> there ar= e=20
>     more<BR>&gt; &gt; moving parts in processing a packet in
> Switchover sce= nario=20
>     than processing<BR>&gt; &gt; "normal" BFD packet. Latter is very
> often = done=20
>     completely in HW while former<BR>&gt; &gt; in SW. Hence the
> possible la= ck of=20
>     reliability in processing while BFD<BR>&gt; &gt; session deemed
> Up.<BR>= &gt;=20
>     &gt; [Sri ] This is an implementation choice. The folks who
> implement i= t=20
>     right<BR>&gt; &gt; will make it reliable.<BR>&gt; &gt;<BR>&gt;
> &gt; Not= e=20
>     thus<BR>&gt; &gt; reducing reliability of the alert
> mechanism.<BR>&gt; = &gt;=20
>     at<BR>&gt; &gt; higher priority/reliability (than a data
> packet).<BR>&g= t;=20
>     because inefficiency<BR>&gt; &gt; you're addressing. End-to-end
> protect= ion,=20
>     in many cases, is capable to<BR>&gt; &gt; deliver identical to
> protecte= d=20
>     path service guarantees and might not require<BR>&gt; &gt;
> revertive ac= tion.=20
>     I think that many of deployments have historical rather<BR>&gt;
> &gt; th= an=20
>     technical explanation in which method been selected.<BR>&gt; &gt;
> [Sri = ]=20
>     With this in-efficiency addressed it should not be the
> case.<BR>&gt; &g= t;=20
>     wrote:<BR>&gt; &gt;<BR>&gt; &gt;&gt; &nbsp;Greg, see inline @
> [Sri]<BR>= &gt;=20
>     &gt;&gt;<BR>&gt; &gt;&gt;<BR>&gt; &gt;&gt; - Sri<BR>&gt;
> &gt;&gt;<BR>&g= t;=20
>     &gt;&gt;<BR>&gt; &gt;&gt;
> &nbsp;------------------------------<BR>&gt;=
> =20
>     &gt;&gt; *Sent:* Thursday, March 25, 2010 5:23 PM<BR>&gt; &gt;&gt;
> *To:= *=20
>     href=3D"mailto:[email-masked]">[email-masked]</A><BR>&gt; &gt;&gt;
> *Subje= ct:*=20
>     Re: Comments to Efficient FRR using Facility backup in
> ring<BR>&gt; &gt= ;&gt;=20
>     topology<BR>&gt; &gt;&gt;<BR>&gt; &gt;&gt; &nbsp;Dear
> Authors,<BR>&gt;= =20
>     &gt;&gt;<BR>&gt; &gt;&gt; &nbsp; &nbsp;- in Section 4.2 following
> assum= ption=20
>     being made "Thus each LSR along<BR>&gt; &gt;&gt; &nbsp; &nbsp;the
> bypas= s=20
>     receives the packet." I believe that there is no guarantee
> that<BR>&gt;= =20
>     &gt;&gt; &nbsp; &nbsp;each LSR along the bypass tunnel will
> receive the= =20
>     alert message, even if it<BR>&gt; &gt;&gt; &nbsp; &nbsp;will be
> sent th= ree=20
>     times. As result of this assumption most of conclusions<BR>&gt;
> &gt;&gt= ;=20
>     &nbsp; &nbsp;regarding proposed solution look unfounded.<BR>&gt;
> &gt;&g= t;=20
>     sent<BR>&gt; &gt;&gt; &nbsp; &nbsp;periodically later. If the very
> high= ly=20
>     unlikely event that all three<BR>&gt; &gt;&gt; &nbsp;
> &nbsp;messages ar= e=20
>     dropped, then it means that there is a problem sending
> data<BR>&gt; &gt= ;&gt;=20
>     &nbsp; &nbsp;packets on the bypass and other means (such as BFD
> and/or= =20
>     signaling) would<BR>&gt; &gt;&gt; &nbsp; &nbsp;indicate the
> problem. Su= ch=20
>     packet drop problems on the bypass should have<BR>&gt; &gt;&gt;
> &nbsp;= =20
>     actions<BR>&gt; &gt;&gt; &nbsp; &nbsp;would have occurred.<BR>&gt;
> &gt;= &gt;=20
>     whether PLR<BR>&gt; &gt;&gt; &nbsp; &nbsp;deploys its bypass
> tunnel loc= ally=20
>     bit.<BR>&gt; &gt;&gt; &nbsp; &nbsp;- if the Merge Point of bypass
> tunne= ls=20
>     set by PLR-u's is, using Fig.1<BR>&gt; &gt;&gt; &nbsp; &nbsp;and
> scenar= io=20
>     &gt;&gt; &nbsp; &nbsp;problem characteristic to Facility
> protection in = a=20
>     ring topology. Possible<BR>&gt; &gt;&gt; &nbsp; &nbsp;congestion
> on lin= k=20
>     L9-L8 might be avoided, but not on link L7-L6. To address<BR>&gt;
> &gt;&= gt;=20
>     &nbsp; &nbsp;this congestion, the MP must be changed when PLR-u
> sets it= s=20
>     bypass.<BR>&gt; &gt;&gt; &nbsp; &nbsp;[Sri ] Seems you haven't
> understo= od=20
>     the text in section 4 that<BR>&gt; &gt;&gt; &nbsp; &nbsp;describes
> how = MP is=20
>     chosen for a bypass from PLR-u. Also it seems you<BR>&gt; &gt;&gt;
> &nbs= p;=20
>     protection<BR>&gt; &gt;&gt; &nbsp; &nbsp;switched from PLR-u, the
> MP is=  at=20
>     Introduction of PLR-u for all local protections along the
> protected<BR>= &gt;=20
>     &gt;&gt; &nbsp; &nbsp;LSR might create scaling problem and is not
> neces= sary=20
>     (I'll try to explain<BR>&gt; &gt;&gt; &nbsp; &nbsp;that
> below).<BR>&gt;= =20
>     &gt;&gt; &nbsp; &nbsp;[Sri ] PLR-u is created at nodes along
> bypass LSP= . The=20
>     explanation<BR>&gt; &gt;&gt; &nbsp; &nbsp;below does not clearly
> state = the=20
>     scaling parameter you are concerned about.<BR>&gt;
> &gt;&gt;<BR>&gt; &gt= ;&gt;=20
>     transient LSRs being PLR-u.<BR>&gt; &gt;&gt; What is really
> needed, in = my=20
>     view, is end-to-end or segment protection and a<BR>&gt; &gt;&gt;
> way fo= r=20
>     LER/segment's head-end to learn about the failure along
> the<BR>&gt; &gt= ;&gt;=20
>     protected LSR fast enough. If one decides to run link layer OAM
> rather= =20
>     than<BR>&gt; &gt;&gt; end-to-end or segment/TCM, then LSR, known
> as PLR= ,=20
>     needs fast and reliable<BR>&gt; &gt;&gt; method of notifying LER.
> But I= =20
>     don't see good technical reason to do that<BR>&gt; &gt;&gt; when
> there = are=20
>     ways to avoid this problem.<BR>&gt; &gt;&gt; [Sri ] Alerting all
> LSRs a= long=20
>     protected LSPs that are protected by the bypass.
> End-to-end<BR>&gt; &gt= ;&gt;=20
>     scalable<BR>&gt; &gt;&gt; FRR mechanism of facility backup and it
> is wi= dely=20
>     deployed. Your<BR>&gt; &gt;&gt; observations on link-layer OAM,
> ...etc = would=20
>     have been useful if it had<BR>&gt; &gt;&gt; details. Again note
> that ou= r=20
>     draft addresses general physical topologies<BR>&gt; &gt;&gt; (not
> just= =20
>   color=3D#0000ff size=3D2></FONT><FONT face=3DArial
> color=3D#0000ff=20 size=3D2></FONT></BLOCKQUOTE> <STYLE
> type=3Dtext/css>#avg_ls_inline_popup {
> H: 240px; COLOR: black; LINE-HEIGHT: 13px; PADDING-TOP: 0px; POSITION:
> abso= lute; TEXT-ALIGN: left; WORD-WRAP: break-word } </STYLE>
> </BODY></HTML>
>

---

From: Curtis Villamizar <[email-masked]>
Date: Mon, 29 Mar 2010 03:09:00 -0400

In message <[email-masked]>

Sri,

You are missing some important points regarding how FRR works.  It
works from the PLR, not the PLR-u.  There can be more than one
facilities backup LSP with different merge points.  Consider a pair of
rings that overlap.

          G --- H --- I --- J --- K
          |                 |
    A --- B --- C -X- D --- E --- F
          |                 |
	  L --- M --- N --- O --- P

Node B can detect that a failure has occurred downstream but the merge
points would be different for traffic to F, K, and P.  Node B would
have to determine which LSP are affected by knowing where the failure
is so that it didn't route traffic destined to C or anything connected
to C on the protect path through D.

That is not FRR as FRR is defined.  FRR only acts at the PLR.

Did you say how B would know that the failure is at C-D?  If so I
missed that.

Also each PLR which could act as a PLR-u would need to be able to map
any downstream failure to the set of protects that needed to be
activated.  AFAIK no merchant silicon (Ethernet) supports a
sufficiently flexible mapping and no designs to date (again AFAIK).
This would require new hardware or activation in software (slow).  FRR
activation today is done either purely or almost purely in hardware.

Curtis

> [Sri] Note that protection from PLR-u is also valuable due to it being faster at higher scale. E.g consider the example in the draft where there are a large number of protected LSPs routed via L8->…

[CV] That is not what FRR does.

> > > > tunnel=

---

From: Phil Bedard <[email-masked]>
Date: Mon, 29 Mar 2010 11:53:22 -0400

So Curtis basically drove the diagram I was thinking of and I know it is outside the realm of a simple ring topology but this is how our network works today.   My initial reaction to reading the draft was I was wondering how many operators today are in a position where they are oversubscribing their ring capacity, at least for high priority or critical traffic?  In our network, we have an overwhelming amount of low priority data traffic, so using this optimized FRR would probably not interest us.  Losing some amount of low priority traffic for the 500ms-2s or so it takes global path restoration to complete is acceptable.   

Also with interconnected rings of varying complexity, we run the risk of inducing an additional protection switch event.   There is a bit of video/voice traffic where we'd like to minimize the protection events because they induce loss or re-ordering.    

Curtis, maybe I'm misunderstanding the draft but there would be two "backup LSPs" built.  If the path to P was A-B-C-D-E-O-P and the bypass covering C-D was C-B-G-H-I-J-E-D , O would not be a candidate MP for the "backup LSP" for A-P because the bypass does not cross O.   So the PLR-u would use one bypass to cover A-K from A-J and one bypass to cover A-F and A-P using A-E.   The PLR-u would map LSPs to specific optimized bypasses.  Then alerts on the normal FRR bypass trigger a protection switch on the PLR-u.  

I'd consider this a weak point in the draft, there is not much explanation about how the additional bypass from the PLR-u to the "MP-d" is constructed.  I believe the draft just mentions through the use of the new RSVP information (which LSPs use which normal FRR bypass) and the TED, the new bypasses ("backup LSPs") are built.  Perhaps in the future drafts there will be more explanation around building multiple bypasses from the PLR-u to the MPs in a more complex topology like you've shown.    

I can see the motivation in the draft but it seems like a lot of implementation work for not much gain.  

Phil  

On Mar 29, 2010, at 3:09 AM, Curtis Villamizar wrote:

> _______________________________________________
> mpls mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls

---

From: Sriganesh Kini <[email-masked]>
Date: Mon, 29 Mar 2010 12:39:38 -0400

Hi Curtis, see inline

- Sri

> Sent: Monday, March 29, 2010 12:09 AM
> To: Sriganesh Kini
> Cc: [email-masked]; Greg Mirsky; [email-masked]; [email-masked]
> <[email-masked]
.ericsson.se>
> You are missing some important points regarding how FRR
> works.  It works from the PLR, not the PLR-u.  There can be

Not sure why you think something is being missed. My interpretation of your example/fig is that the 'X' is a break in the link C-D and that the FRR you are referring to is the one defined in RFC4090. To protect facility C-D using the facility backup method a bypass can be setup as C-B-G-H-H-I-E-D (in your original example you had 2 nodes named as H) where C is PLR and D is MP. This bypass can protect a LSP such as A-B-C-D when the link C-D goes down. Of course if a bypass is set for node (D) protection it can be setup as C-B-G-H-H-I-E and it can protect a LSP such as A-B-C-D-E when node D goes down (or link C-D goes down). This is the fastest method of protection since the node that detects the fault locally (C) acts as a PLR. Other detection methods would involve monitoring links/nodes that are not directly connected (and would be correspondingly slower). Also note that in this entire interpretation there was no reference to PLR-u, hence no question of any protection working from PLR-u.

> more than one facilities backup LSP with different merge
> points.  Consider a pair of rings that overlap.
>
> Node B can detect that a failure has occurred downstream but
> the merge points would be different for traffic to F, K, and
> P.  Node B would have to determine which LSP are affected by
> knowing where the failure is so that it didn't route traffic
> destined to C or anything connected to C on the protect path
> through D.
>

In this fig you have corrected the duplicate node (H) naming but the connections between B, L and M are messed up (not sure if this is my email client's viewing problem). Similarly for E, O and P. To avoid further confusion it would help if we discuss this after you clarify the topology.

Let me try with this simpler topology to see if this is what you are trying to illustrate.

    +-----D---F
    |    /
A---B---C
    |    \
    +-----E---G

Say several protected LSPs are going along two paths A-B-C-D-F and A-B-C-E-G. Say B-D and B-E are bypasses from B (PLR) for node protection of C. When PLR detects failure of the (directly connected) node C, all LSPs having paths along A-B-C-D-F are protected using bypass B-D and all LSPs having paths along A-B-C-E-G are protected using bypass B-E. The association of how the protection switching should be done is all computed before failure. All protection switching is done at PLR and in hardware (depending on how good the implementation is). Again there is no reference to PLR-u in this example.

If this is not what you are trying to illustrate, then this example can be ignored.

>
> Did you say how B would know that the failure is at C-D?  If
> so I missed that.
>
> Also each PLR which could act as a PLR-u would need to be
> able to map any downstream failure to the set of protects
> that needed to be activated.  AFAIK no merchant silicon
> (Ethernet) supports a sufficiently flexible mapping and no
> designs to date (again AFAIK).
> This would require new hardware or activation in software
> (slow).  FRR activation today is done either purely or almost
> purely in hardware.
>

Let us discuss this after resolving the earlier comments.

> > Subject: Re: [mpls-tp] Comments to Efficient FRR using
> Facility backup
> > in ring topology
> >
> >
> > In message
> >
> <[email-masked]
> > n.se>
> > Sriganesh Kini writes:
> > >
> > >
> > > useful to make it efficient in specific cases where it is
> not. Just
> > > to re-iterate (again), this draft is applicable to MPLS
> and is for
> > > general topologies.
> > >
> > > How PLR determines the round-trip delay to hold off for the
> > > switchover can be treated as a study topic for the
> applications that
> > > consider re-ordering for these miniscule time-scales relevant
> > > enough. The reason for the tunnel between PLR and MP is
> that such a
> > > bypass exists in the current deployment and also avoids a
> flag-day
> > > upgrade requirement.
> > >
> > > fast/reliable, it would be useful if you can be specific on which
> > > part it is about and what the unreliability is. If the
> observation
> > > is from the point-of-view of a specific implementation,
> it would be
> > > considered out of scope of this draft.
> > >
> > >
> > > - Sri
> >
> >
> > Sri,
> >
> > In the example
> >
> >           G --- H --- H --- I
> >           |                 |
> > The FRR protect path is from C to the merge point at E.
> The ring schemes move the protect back to B.  FRR leaves the
> protection at C.
> > [Sri] Yes. A minor caveat is that if it is a link (C-D)
> bypass then MP for the FRR bypass from PLR (C) is at D.
> >
> > FRR would normally protect traffic until A as ingress
> rerouted the working path.  In the absense of a control
> plane, the management plane would do this (maybe).  If there
> was a further alternate besides the ring, then a protect path
> for the new A-F working path would be brought up.
> >
> > [Sri] Agree.
> >
> > The question is whether the interim protection from B is
> valuable.  If it is much faster than the reroute from ingress
> then it is valuable because less capacity is needed to
> provide protection.  If there is no reroute from ingress,
> then it is also valuable.  (That said, my preference is
> facilities FRR, but I need to consider customer input - which
> for us has not indicated a need for ring protection so far -
> but that is only one data point).
> >
> > [Sri] Note that protection from PLR-u is also valuable due
> to it being faster at higher scale. E.g consider the example
> in the draft where there are a large number of protected LSPs
> routed via L8->L7. If the backup LSP from PLR-u is setup as a
> bypass, then all the LSPs entering/exiting the ring through
> common points (and going through L8-L7) can be protected by a
> single bypass (for each entry/exit point). A very simple
> protection switch operation at each PLR-u can protect a large
> number of LSPs. This should be faster than the ingress
> re-routing each protected LSP individually.
>
> > I was just pointing out that there are extra reorder events
> and not commenting on whether that was a problem or not.  I
> just said it should be acknowledged in any ring protection
> document that proposes such a mechanism.
> >
> > [Sri] Accepted
> >
> > Maybe I should ask you who you think is complaining about
> "too many moving parts ... etc".  I don't follow the "flag
> day" issue you brought up.
> >
> > [Sri] The comment about "too many moving parts" was from
> Greg. He also commented "And if we put all these efforts to
> switch at PLR-u, what is the reason for tunnel between FRR's
> PLR and MP?". There is a simpler reason for that. To protect
> LSPs across the link (LSP C->D in your example above and a
> LSP L8->L7 in the example in the draft).
> >
> > Curtis
> >
> >
> > > (there's no such definition in the document so I've invented it
> > > 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.
> > > 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
> > > 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
> > >
> > > On Sat, Mar 27, 2010 at 8:17 PM, Curtis Villamizar
> <[email-masked]<mailto:[email-masked]>> wrote:
> > >
> > > In message
> > >
> <[email-masked]<mailto:7
> > > 87 [email-masked]>>
> > > Greg Mirsky writes:
> > > >
> > > >
> > > > Dear Sri,
> > > > 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
> > > 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
> > > 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
> > >
> > >
> > > > > *Subject:* Re: Comments to Efficient FRR using
> Facility backup
> > > > > in ring topology
> > > > >
> > > > > Dear Sri,
> > > > > meant "The traffic should be protection switched to a backup
> > > > > path terminating on a LSR along the protected LSP that is
> > > > > furthest downstrea=
> > > m
> > > > > common, between PLR's bypass tunnel's path and the protected
> > > > > LSP, LSR taken in direction of the bypass tunnel."
> > > > > As for reliability of the alert mechanism, I'd point
> that there
> > > > > are mor=
> > > e
> > > > > moving parts in processing a packet in Switchover
> scenario than
> > > > > process=
> > > ing
> > > > > "normal" BFD packet. Latter is very often done
> completely in HW
> > > > > while f=
> > > ormer
> > > > > 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 rig=
> > > ht
> > > > > will make it reliable.
> > > > >
> > > > > capable to deliver identical to protected path service
> > > > > guarantees and might not re=
> > > quire
> [email-masked]<mailto:[email-masked]
> >> wrote:
> > > > >
> > > > >>  Greg, see inline @ [Sri]
> > > > >>
> > > > >>
> > > > >> - Sri
> > > > >>
> > > > >>
> > > > >> *Subject:* Re: Comments to Efficient FRR using
> Facility backup
> > > > >> in ring topology
> > > > >>
> > > > >>  Dear Authors,
> > > > >>    - in Section 4.2 following assumption being made
> "Thus each
> > > > >> LSR alo=
> > > ng
> > > > >>    the bypass receives the packet." I believe that
> there is no
> > > > >> guarant=
> > > ee that
> > > > >>    will be sent three times. As result of this
> assumption most
> > > > >> of conc=
> > > lusions
> > > > >>    periodically later. If the very highly unlikely
> event that
> > > > >> all thre=
> > > e
> > > > >>    messages are dropped, then it means that there is
> a problem
> > > > >> sending=
> > >  data
> > > > >>    deploys its bypass tunnel locally as well as sets
> FLA bit in
> > > > >> BFD me=
> > > ssage or
> > > > >>    [Sri ] PLR deploys the protection switch to
> bypass and sets
> > > > >> FLA bit=
> > > .
> > > > >>    congestion on link L9-L8 might be avoided, but
> not on link
> > > > >> L7-L6. T=
> > > o address
> > > > >>    describes how MP is chosen for a bypass from
> PLR-u. Also it
> > > > >> seems y=
> > > ou
> > > > >>    haven't read section 5 that clearly states that
> for traffic
> > > > >> protect=
> > > ion
> > > > >>    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
> > > > >> protect=
> > > ed
> > > > >>    LSR might create scaling problem and is not
> necessary (I'll
> > > > >> try to =
> > > explain
> > > > >>    that below).
> > > > >>    below does not clearly state the scaling
> parameter you are
> > > > >> concerne=
> > > d about.
> > > > >>
> > > > >> end-to-end or segment/TCM, then LSR, known as PLR,
> needs fast
> > > > >> and reli=
> > > able
> > > > >> method of notifying LER. But I don't see good
> technical reason
> > > > >> to do t=
> > > hat
> > > > >> FRR mechanism of facility backup and it is widely deployed.
> > > > >> Your observations on link-layer OAM, ...etc would have been
> > > > >> useful if it ha=
> > > d
> > > > >> details. Again note that our draft addresses general
> physical
> > > > >> topologi=
> > > es
> > > > >> (not just ring).
> > > > >>
> > > > >> Regards,
> > > > >> Greg
> > >
> > >
> > > face=3DA= rial=20 color=3D#0000ff size=3D2>How
> PLR&nbsp;determines
> > > the round-trip delay to=20 hold&nbsp;off for the
> switchover can be
> > > treated as a study topic for the=20 applications that consider
> > > re-ordering for these miniscule time-scales rele= vant=20 enough.
> > > The reason for the tunnel between PLR and MP&nbsp;is that
> such a by=
> > > pass=20 exists in the current deployment and also avoids
> a flag-day
> > > upgrade=20 requirement.</FONT></SPAN></DIV> <DIV><FONT
> face=3DArial
> > > fast/re= liable,=20 it would be useful if you can be specific on
> > > which part it is about and wha= t the=20 unreliability is. If the
> > > draft.</FONT></SPAN></DIV> <DIV><SPAN
> > >   [mailto:[email-masked]] <BR><B>Sent:</B> Saturday, March
> > > 27, 2010 = 9:32=20
> > >   <DIV></DIV>Hi Curtis,<BR>if I look at the protection tunnel
> > > created betwe= en=20
> > >   what it is not - segment protection?<BR>Besides, how long PLR
> > > should hold=  off=20
> > >   believe, should be used as such. Trying to combine link local
> > > fault detec= tion,=20
> > >   as fast and as reliable as when detection and switchover are on
> > > the same = node,=20
> > >   style=3D"PADDING-LEFT: 1ex; MARGIN: 0pt 0pt 0pt 0.8ex;
> BORDER-LEFT:
> > > rgb(2=
> > >     <DIV class=3Dim>Greg Mirsky
> writes:<BR>&gt;<BR>&gt;<BR>&gt; Dear
> > > Sri,<B=
> > > R>&gt;=20
> > >     reversion. &nbsp;It isn't<BR>practical to eliminate all
> > > reordering (exc= ept=20
> href=3D"mailto:[email-masked]">sriganesh.kini@ericsson.
> > > co
> > > m=
> > > </A><BR>&gt;=20
> href=3D"mailto:[email-masked]">[email-masked]</A>]<BR>
> > > &g
> > > t=
> > > ; &gt;=20
> > >     you<BR>&gt; &gt; meant "The traffic should be protection
> > > switched to a= =20
> > >     backup path<BR>&gt; &gt; terminating on a LSR along the
> > > protected LSP t= hat=20
> > >     bypass LSPs going in the opposite<BR>&gt; &gt;
> directions", then
> > > I migh= t=20
> > >     path and the protected LSP, LSR taken in<BR>&gt; &gt;
> direction
> > > of the= =20
> > >     technical explanation in which method been selected.<BR>&gt;
> > > &gt; [Sri = ]=20
> href=3D"mailto:[email-masked]">sriganesh.kini@ericsson.
> > > co
> > > m=
> > > </A>&gt;=20
> href=3D"mailto:[email-masked]">[email-masked]</A>]<BR>
> > > &g
> > > t=
> > > ;=20
> > >     &gt;&gt; *Sent:* Thursday, March 25, 2010 5:23 PM<BR>&gt;
> > > &gt;&gt; *To:= *=20
> > >     &gt;&gt;<BR>&gt; &gt;&gt; &nbsp; &nbsp;- in Section 4.2
> > > following assum= ption=20
> > >     being made "Thus each LSR along<BR>&gt; &gt;&gt; &nbsp;
> > > &nbsp;the bypas= s=20
> > >     sent<BR>&gt; &gt;&gt; &nbsp; &nbsp;periodically later. If the
> > > very high= ly=20
> > >     actions<BR>&gt; &gt;&gt; &nbsp; &nbsp;would have
> > > occurred.<BR>&gt; &gt;= &gt;=20
> > >     bit.<BR>&gt; &gt;&gt; &nbsp; &nbsp;- if the Merge Point of
> > > bypass tunne= ls=20
> > >     L9-L8 might be avoided, but not on link L7-L6. To
> > > address<BR>&gt; &gt;&= gt;=20
> > >     the text in section 4 that<BR>&gt; &gt;&gt; &nbsp;
> > > &nbsp;describes how = MP is=20
> > >     chosen for a bypass from PLR-u. Also it seems you<BR>&gt;
> > > &gt;&gt; &nbs= p;=20
> > >     protection<BR>&gt; &gt;&gt; &nbsp; &nbsp;switched from PLR-u,
> > > the MP is=  at=20
> > >     &gt;&gt; &nbsp; &nbsp;LSR might create scaling problem and is
> > > not neces= sary=20
> > >     scalable<BR>&gt; &gt;&gt; FRR mechanism of facility
> backup and
> > > it is wi= dely=20
> > >     draft addresses general physical topologies<BR>&gt; &gt;&gt;
> > > (not just= =20
> > >       PADDING-RIGHT: 0px; MARGIN-TOP: 0px; PADDING-LEFT:
> 0px; FONT-SIZE:
> > > 10px; Z=

---

From: "Shahram Davari" <[email-masked]>
Date: Mon, 29 Mar 2010 12:44:02 -0700

Hi Sri,

I have a few clarification questions:

1) what is the FLA-bit? I couldn't find it in any BFD draft. Is that the Fast LSP Alert bit from your other draft?
2) What is MBB?
3) What is the difference between backup LSP and Bypass LSP?
4) What is TED?

And a few comments:

A) I am not sure it I a good idea to switch packets to backup LSP at two different points (LSR 8 and 9 in your example). My question is why isn't the backup LSP created as following: L9-L1-L2-...-L6?

B) I don't like your FLA-bit, since it breaks MPLS architecture. Is there any alternative to FLA-bit for this to work?

Thx
Shahram

---

From: Sriganesh Kini <[email-masked]>
Date: Mon, 29 Mar 2010 16:21:25 -0400

Hi Shahram, pls see inline

- Sri

> From: Shahram Davari [mailto:[email-masked]] 
> Sent: Monday, March 29, 2010 12:44 PM
> To: Sriganesh Kini
> Cc: [email-masked]; [email-masked]
> Subject: Comments to Efficient FRR using Facility backup in 
> ring topology
> 
> 
>  Hi Sri,
> 
> 1) what is the FLA-bit? I couldn't find it in any BFD draft. 
> Is that the Fast LSP Alert bit from your other draft?

Yes

> 2) What is MBB?

Acronym for Make-Before-Break

> 3) What is the difference between backup LSP and Bypass LSP?

Bypass is a type of backup. See RFC4090 for further details.

> 4) What is TED?

Acronym for Traffic-Engineering-Database

> 
> 
> And a few comments:
> 
> A) I am not sure it I a good idea to switch packets to backup 
> LSP at two different points (LSR 8 and 9 in your example). My 
> question is why isn't the backup LSP created as following: 
> L9-L1-L2-...-L6?

Read section 6. The backup LSP is L9-L10-L1-...-L6
If you can elaborate on what problem you see in switching packets at L8,L9 it will be useful.
Protection switch at L8 (PLR) is FRR according to RFC4090. It is local protection and is fastest.
Protection switch at L9 (PLR-u) according to the draft ensures that FRR is efficient.

> 
> B) I don't like your FLA-bit, since it breaks MPLS 
> architecture. Is there any alternative to FLA-bit for this to work?

As explained in an earlier thread http://www.ietf.org/mail-archive/web/mpls/current/msg04183.html it does not break MPLS. Alternatives (so far) are either complex, slow, cumbersome, in-efficient, incomplete or all of the above.

---

From: "Shahram Davari" <[email-masked]>
Date: Mon, 29 Mar 2010 13:41:33 -0700

Hi Sri,

Pls see inline.

Thx
SD 

-----Original Message-----
From: Sriganesh Kini [mailto:[email-masked]] 
Sent: Monday, March 29, 2010 1:21 PM
To: Shahram Davari
Cc: [email-masked]; [email-masked]
Subject: RE: Comments to Efficient FRR using Facility backup in ring topology

- Sri

Yes

SD> Please clarify this in a terminology section.

SD> Please clarify this in a terminology section.

SD> I can't understand this. If the backup LSP starts from L9 then why does BFD start from L8 and why does L9 need to intercept the BFD?

SD> I disagree. I think it breaks MPLS Arch, since you are forwarding based on a label that was terminated due to TTL expiry.

---

From: Greg Mirsky <[email-masked]>
Date: Mon, 29 Mar 2010 13:44:24 -0700

DearSri,
you wrote:
Alternatives (so far) are either complex, slow, cumbersome, in-efficient,
incomplete or all of the above.

Could you please list requirements matrix and ring protection methods you've
compared with proposed in the document modification of FRR (which I view as
dynamic merge of Facility FRR + TCM). Is your conclusion related to specific
implementations or methods in general?

Regards,
Greg

On Mon, Mar 29, 2010 at 1:21 PM, Sriganesh Kini <[email-masked]

> As explained in an earlier thread
> http://www.ietf.org/mail-archive/web/mpls/current/msg04183.html it does
> not break MPLS. Alternatives (so far) are either complex, slow, cumbersome,
> in-efficient, incomplete or all of the above.
>
> >
> > Thx
> > Shahram
> >
> >
> >
> mpls-tp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls-tp
>

---

From: Greg Mirsky <[email-masked]>
Date: Mon, 29 Mar 2010 13:53:55 -0700

Dear Shahram,
it was suggested to me that described handling of LSP's TTL can be
re-defined while preserving functionality. Consider that an LSR, upon
receiving OAM packet with the FLA bit set, generates a new ACH-encapsulated
packet with LSP TTL == 1 and GAL's TTL is decremented and copied. Formally
that, as I think about it, is compliant with the  RFC 3443. Is that feasible
to work efficiently? Would providers be interested to deploy knowing that
this 2-step protection will cause some additional transient reordering?

Regards,
Greg

On Mon, Mar 29, 2010 at 1:41 PM, Shahram Davari <[email-masked]> wrote:

> SD> I can't understand this. If the backup LSP starts from L9 then why does
> BFD start from L8 and why does L9 need to intercept the BFD?
>
> >
> SD> I disagree. I think it breaks MPLS Arch, since you are forwarding based
> on a label that was terminated due to TTL expiry.
>
> >
> > Thx
> > Shahram
> >
> >
> >
>

---

From: Sriganesh Kini <[email-masked]>
Date: Mon, 29 Mar 2010 17:02:36 -0400

Greg, as stated earlier this draft is not restricted to ring topologies. Read section 6 for applicability. RFC4090 is the standardized protection method.

- Sri

________________________________
From: Greg Mirsky [mailto:[email-masked]]
Sent: Monday, March 29, 2010 1:44 PM
To: Sriganesh Kini
Cc: Shahram Davari; [email-masked]; [email-masked]
Subject: Re: [mpls-tp] Comments to Efficient FRR using Facility backup in ring topology

DearSri,
you wrote:
Alternatives (so far) are either complex, slow, cumbersome, in-efficient, incomplete or all of the above.

Could you please list requirements matrix and ring protection methods you've compared with proposed in the document modification of FRR (which I view as dynamic merge of Facility FRR + TCM). Is your conclusion related to specific implementations or methods in general?

Regards,
Greg

On Mon, Mar 29, 2010 at 1:21 PM, Sriganesh Kini <[email-masked]<mailto:[email-masked]>> wrote:
Hi Shahram, pls see inline

- Sri

> From: Shahram Davari [mailto:[email-masked]<mailto:[email-masked]>]
> Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>

Yes

_______________________________________________
mpls-tp mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/mpls-tp

---

From: Greg Mirsky <[email-masked]>
Date: Mon, 29 Mar 2010 14:11:15 -0700

Dear Sri,
I think that I understand and that is not what I've asked.
You've made a statement and I'm asking if would kindly share facts that
support such statement. When several methods, technologies being compared,
usually that is done with some metrics, list or matrix of parameters ordered
based on their relative significance. Such comparative researches of
protection mechanisms are of great interest to me and I wonder if you are
willing to share facts that lead to your statement.

Regards,
Greg

On Mon, Mar 29, 2010 at 2:02 PM, Sriganesh Kini <[email-masked]

>  Greg, as stated earlier this draft is not restricted to ring topologies.
> Read section 6 for applicability. RFC4090 is the standardized protection
> method.
>
>
> - Sri
>
>
> *From:* Greg Mirsky [mailto:[email-masked]]
> *Sent:* Monday, March 29, 2010 1:44 PM
> *To:* Sriganesh Kini
> *Cc:* Shahram Davari; [email-masked]; [email-masked]
> *Subject:* Re: [mpls-tp] Comments to Efficient FRR using Facility backup
> in ring topology
>
> DearSri,
> you wrote:
> Could you please list requirements matrix and ring protection methods
> you've compared with proposed in the document modification of FRR (which I
> view as dynamic merge of Facility FRR + TCM). Is your conclusion related to
> specific implementations or methods in general?
>
> Regards,
> Greg
>
> On Mon, Mar 29, 2010 at 1:21 PM, Sriganesh Kini <
> [email-masked]> wrote:
>

---

From: Sriganesh Kini <[email-masked]>
Date: Mon, 29 Mar 2010 17:33:43 -0400

Shahram, pls see inline.

- Sri

> Sent: Monday, March 29, 2010 1:42 PM
> To: Sriganesh Kini
> > Subject: Comments to Efficient FRR using Facility backup in ring 
> > topology
> > 
> > 
> >  Hi Sri,
> > 

Accepted

> SD> Please clarify this in a terminology section.

Accepted

> 
> 
> > 
> > 
> > And a few comments:
> > 
> > A) I am not sure it I a good idea to switch packets to 
> backup LSP at 
> > two different points (LSR 8 and 9 in your example). My 
> question is why 
> > isn't the backup LSP created as following:
> > L9-L1-L2-...-L6?
> 
> Read section 6. The backup LSP is L9-L10-L1-...-L6 If you can 
> elaborate on what problem you see in switching packets at 
> L8,L9 it will be useful.
> SD> I can't understand this. If the backup LSP starts from L9 
> then why does BFD start from L8 and why does L9 need to 
> intercept the BFD?

The BFD is running on the bypass LSP (starting from L8). L8 will generate the alert fastest since the failure is local to it. L9 uses the alert to do the protection switch.
If there is another protected LSP L10-L9-L8-L7 it will be protection switched by L10 (PLR-u) by acting on the same alert along the bypass LSP.
Similarly a LSP L1-L10-L9-L8-L7 will be protection switched by L1 (PLR-u) again by acting on the same alert.

> 
> > 
> > B) I don't like your FLA-bit, since it breaks MPLS architecture. Is 
> > there any alternative to FLA-bit for this to work?
> 
> http://www.ietf.org/mail-archive/web/mpls/current/msg04183.htm
l it does not break MPLS. Alternatives (so far) are either > complex, slow, cumbersome, in-efficient, incomplete or all of 
> the above.
> 
> 
> SD> I disagree. I think it breaks MPLS Arch, since you are 
> forwarding based on a label that was terminated due to TTL expiry.

The TTL is not expiring due to a packet looping. This TTL expiry is best viewed as the purposeful TTL expiry (and response) of traceroute. At the same time none of the TTL expiry procedures (required for forwarding) are lost since GAL TTL is used for that purpose. It is also backward compatible since older LSRs would simply treat this as a packet with TTL expired. Also, TTL expiry capabilities of current hardware is re-usable. The spirit of RFC3031,3032,3443 is intact. It does not break MPLS architecture.

---

From: "Shahram Davari" <[email-masked]>
Date: Mon, 29 Mar 2010 14:32:47 -0700

Hi Greg,

This means a path to CPU is needed. If that is the intention then is fine but delay is to be expected. However what I can't understand is the backup LSP starts in a different router than the BFD session for that LSP. Did you understand this part?

Thanks,
Shahram

________________________________
From: Greg Mirsky [mailto:[email-masked]]
Sent: Monday, March 29, 2010 1:54 PM
To: Shahram Davari
Cc: Sriganesh Kini; [email-masked]; [email-masked]
Subject: Re: [mpls] Comments to Efficient FRR using Facility backup in ring topology

Dear Shahram,
it was suggested to me that described handling of LSP's TTL can be re-defined while preserving functionality. Consider that an LSR, upon receiving OAM packet with the FLA bit set, generates a new ACH-encapsulated packet with LSP TTL == 1 and GAL's TTL is decremented and copied. Formally that, as I think about it, is compliant with the  RFC 3443. Is that feasible to work efficiently? Would providers be interested to deploy knowing that this 2-step protection will cause some additional transient reordering?

Regards,
Greg

On Mon, Mar 29, 2010 at 1:41 PM, Shahram Davari <[email-masked]<mailto:[email-masked]>> wrote:
Hi Sri,

Pls see inline.

Thx
SD

-----Original Message-----
From: Sriganesh Kini [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Monday, March 29, 2010 1:21 PM
To: Shahram Davari
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: RE: Comments to Efficient FRR using Facility backup in ring topology

- Sri

Yes

_______________________________________________
mpls mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/mpls

---

From: Greg Mirsky <[email-masked]>
Date: Mon, 29 Mar 2010 14:41:19 -0700

Dear Shahram,
the way I understand this proposal, what is very likely not what authors
intended, is that the bypass tunnel between PLR-u and MP-d (there's no such
abbreviation in the draft) is TCM between ingress and egress LSRs. Very
early on this thread I've presented my view and asked why running link local
fault/failure/defect detection and then signaling it to PLR-u is
better/more efficient/.. then running TCM OAM. The only explanation so far
was that, no argument here, FRR is widely deployed. But, in my view, the
proposed solution is not just incremental improvement to the Facility
protection and should be compared with other Segment protection schemes
without regard to FRR deployment.

Regards,
Greg

On Mon, Mar 29, 2010 at 2:32 PM, Shahram Davari <[email-masked]> wrote:

>  Hi Greg,
>
> This means a path to CPU is needed. If that is the intention then is fine
> but delay is to be expected. However what I can't understand is the backup
> LSP starts in a different router than the BFD session for that LSP. Did you
> understand this part?
>
> Thanks,
> Shahram
>
> *Sent:* Monday, March 29, 2010 1:54 PM
> *To:* Shahram Davari
>
> *Cc:* Sriganesh Kini; [email-masked]; [email-masked]
> *Subject:* Re: [mpls] Comments to Efficient FRR using Facility backup in
> ring topology
>
> Dear Shahram,
> On Mon, Mar 29, 2010 at 1:41 PM, Shahram Davari <[email-masked]>wrote:
>
>> Hi Sri,
>>
>> Pls see inline.
>>
>> Thx
>> SD
>>
>> SD> I can't understand this. If the backup LSP starts from L9 then why
>> does BFD start from L8 and why does L9 need to intercept the BFD?
>>
>> >
>> SD> I disagree. I think it breaks MPLS Arch, since you are forwarding
>> based on a label that was terminated due to TTL expiry.
>>
>> >
>> > Thx
>> > Shahram
>> >
>> >
>> >
>>

---

From: Sriganesh Kini <[email-masked]>
Date: Mon, 29 Mar 2010 17:41:44 -0400

Greg,

Comparative researches of protection mechanisms are of great interest to a lot of people and they will be shared at appropriate forums. This mailing list is not the forum for publishing research topics.

- Sri

Sent: Monday, March 29, 2010 2:11 PM

Dear Sri,
I think that I understand and that is not what I've asked.
You've made a statement and I'm asking if would kindly share facts that support such statement. When several methods, technologies being compared, usually that is done with some metrics, list or matrix of parameters ordered based on their relative significance. Such comparative researches of protection mechanisms are of great interest to me and I wonder if you are willing to share facts that lead to your statement.

Regards,
Greg

On Mon, Mar 29, 2010 at 2:02 PM, Sriganesh Kini <[email-masked]<mailto:[email-masked]>> wrote:
Greg, as stated earlier this draft is not restricted to ring topologies. Read section 6 for applicability. RFC4090 is the standardized protection method.

- Sri

________________________________
From: Greg Mirsky [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Monday, March 29, 2010 1:44 PM
To: Sriganesh Kini
Cc: Shahram Davari; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [mpls-tp] Comments to Efficient FRR using Facility backup in ring topology

DearSri,
you wrote:

Regards,
Greg

- Sri

Yes

---

From: "Shahram Davari" <[email-masked]>
Date: Mon, 29 Mar 2010 14:45:24 -0700

hi Sri,

I think Greg is simply asking about the justification for you statement in earlier email to me in which you claimed:

"Alternatives (so far) are either complex, slow, cumbersome, in-efficient, incomplete or all of the above"

Which I don't agree with you.

Regards,
Shahram

________________________________
From: Sriganesh Kini [mailto:[email-masked]]
Sent: Monday, March 29, 2010 2:42 PM
To: Greg Mirsky
Cc: Shahram Davari; [email-masked]; [email-masked]
Subject: RE: [mpls-tp] Comments to Efficient FRR using Facility backup in ring topology

Greg,

- Sri

Dear Sri,

Regards,
Greg

- Sri

DearSri,
you wrote:

Regards,
Greg

- Sri

Yes

---

From: Sriganesh Kini <[email-masked]>
Date: Mon, 29 Mar 2010 17:56:13 -0400

Hi Shahram,

As Greg himself admitted it is a research topic. You can refer to some earlier threads where comparison was done by email wherever possible (refer to discussion on p2mp alternative approach).

As stated earlier a research oriented taxonomy for protection mechanisms will be presented at appropriate forums.

- Sri

________________________________
From: Shahram Davari [mailto:[email-masked]]
Sent: Monday, March 29, 2010 2:45 PM
To: Sriganesh Kini; Greg Mirsky
Cc: [email-masked]; [email-masked]
Subject: RE: [mpls-tp] Comments to Efficient FRR using Facility backup in ring topology

hi Sri,

Regards,
Shahram

Greg,

- Sri

Dear Sri,

Regards,
Greg

- Sri

DearSri,
you wrote:

Regards,
Greg

- Sri

Yes

---

From: "Shahram Davari" <[email-masked]>
Date: Mon, 29 Mar 2010 15:01:09 -0700

Hi Sri,

I think we have a disconnect here. I think it has to do with the terminology used. You are saying backup LSP starts from L9 but Bypass LSP starts from L8. I thought these are the same? can you explain this? What is backup LSP and Bypass LSP and which LSRs do they cover and what is the relationship between them?

Thx
SD

-----Original Message-----
From: Sriganesh Kini [mailto:[email-masked]] 
Sent: Monday, March 29, 2010 2:34 PM
To: Shahram Davari
Cc: [email-masked]; [email-masked]
Subject: RE: Comments to Efficient FRR using Facility backup in ring topology

Shahram, pls see inline.

- Sri

Accepted

Accepted

---

From: Phil Bedard <[email-masked]>
Date: Mon, 29 Mar 2010 19:34:33 -0400

I think the naming conventions are a bit confusing in the draft.  I would not call the LSP from PLR-u to the new MP the "backup LSP" I would call it the "Optimized Bypass" or something similar.   

The draft is using the semantics and path information of a wrapped FRR bypass to setup a new steered bypass using BFD to alert the steering node of a failure. I think it would be clearer if the draft just stated this.   

Phil

---

From: Sriganesh Kini <[email-masked]>
Date: Mon, 29 Mar 2010 20:26:47 -0400

Hi Shahram.

The terminology used is from RFC4090, except what may be confusing is the origination of the backup LSP from PLR-u.

The bypass with PLR(L8) and MP(L7) is different from the backup LSP from PLR-u(L9) to its MP(L6).

Note that the backup LSP from PLR-u can be setup similar to a bypass (in which case it will protect all LSPs from L9 to L6 going via L8-L7) or similar to a detour (in which case a detour will have to be setup for each protected LSP that goes from L9 to L6 via L8-L7). The draft supports both methods.

Thanks

- Sri

> Sent: Monday, March 29, 2010 3:01 PM
> To: Sriganesh Kini
> I think we have a disconnect here. I think it has to do with 
> the terminology used. You are saying backup LSP starts from 
> L9 but Bypass LSP starts from L8. I thought these are the 
> same? can you explain this? What is backup LSP and Bypass LSP 
> and which LSRs do they cover and what is the relationship 
> between them?
> 
> Thx
> SD
> 
> > Subject: RE: Comments to Efficient FRR using Facility 
> backup in ring 
> > topology
> > 
> > Hi Sri,
> > 
> > Pls see inline.
> > 
> > Thx
> > SD
> > 
> > Subject: RE: Comments to Efficient FRR using Facility 
> backup in ring 
> > topology
> > 
> > Protection switch at L8 (PLR) is FRR according to RFC4090. 
> It is local 
> > protection and is fastest.
> intercept the 
> > BFD?
> The BFD is running on the bypass LSP (starting from L8). L8 
> will generate the alert fastest since the failure is local to 
> it. L9 uses the alert to do the protection switch.
> If there is another protected LSP L10-L9-L8-L7 it will be 
> protection switched by L10 (PLR-u) by acting on the same 
> alert along the bypass LSP.
> Similarly a LSP L1-L10-L9-L8-L7 will be protection switched 
> by L1 (PLR-u) again by acting on the same alert.
> 
> > 
> > > 
> architecture. Is 
> l it does not break MPLS. Alternatives (so far) are either > 
> complex, slow, cumbersome, in-efficient, incomplete or all of 
> > the above.
> > 
> > 
> The TTL is not expiring due to a packet looping. This TTL 
> expiry is best viewed as the purposeful TTL expiry (and 
> response) of traceroute. At the same time none of the TTL 
> expiry procedures (required for forwarding) are lost since 
> GAL TTL is used for that purpose. It is also backward 
> compatible since older LSRs would simply treat this as a 
> packet with TTL expired. Also, TTL expiry capabilities of 
> current hardware is re-usable. The spirit of 
> RFC3031,3032,3443 is intact. It does not break MPLS architecture.
> 
> > 
> > > 
> > > Thx
> > > Shahram
> > > 
> > > 
> > > 
> > 
> > 
> 
>

---

From: Sriganesh Kini <[email-masked]>
Date: Mon, 29 Mar 2010 20:32:34 -0400

Phil, pls see inline

- Sri

> From: Phil Bedard [mailto:[email-masked]] 
> Sent: Monday, March 29, 2010 4:35 PM
> To: Shahram Davari
> Facility backup in ring topology
> 
> I think the naming conventions are a bit confusing in the 
> draft.  I would not call the LSP from PLR-u to the new MP the 
> "backup LSP" I would call it the "Optimized Bypass" or 
> something similar.

Accepted. We wouldn't call it "Optimized Bypass" since it can be setup similar to a detour but a term such as "Optimized backup" explaining the two possibilities (bypass & detour) should help to avoid the confusion. Will update in next rev.
   
> 
> The draft is using the semantics and path information of a 
> wrapped FRR bypass to setup a new steered bypass using BFD to 
> alert the steering node of a failure. I think it would be 
> clearer if the draft just stated this.   

This terminology is not in the standard RFC4090 and is really unnecessary for this draft. Especially considering that the draft is applicable to general topologies (not just ring), introducing this terminology may introduce more confusion.

> > I think we have a disconnect here. I think it has to do 
> with the terminology used. You are saying backup LSP starts 
> from L9 but Bypass LSP starts from L8. I thought these are 
> the same? can you explain this? What is backup LSP and Bypass 
> LSP and which LSRs do they cover and what is the relationship 
> between them?
> > 
> > Thx
> > SD
> > 
> >> Protection switch at L9 (PLR-u) according to the draft 
> ensures that 
> >> FRR is efficient.
> >> 
> >> 
> > l it does not break MPLS. Alternatives (so far) are either 
> > complex, 
> > slow, cumbersome, in-efficient, incomplete or all of
> >> the above.
> >> 
> >>

---

From: "Shahram Davari" <[email-masked]>
Date: Tue, 30 Mar 2010 14:56:38 -0700

Hi Sri,

I am still confused. RFC 4090 defines the two tunnels/LSPs as following:

- Bypass Tunnel: An LSP that is used to protect a set of LSPs passing over a common facility.
- Backup Tunnel: The LSP that is used to backup up one of the many LSPs in many-to-one backup.

Your draft says that the LSP B1: L8-L9-L10-L1-..-L7 is the Bypass tunnel and the LSP B3: L9-L10-L1-...-L6 is the backup LSP. Does this mean that B3 is transported inside B1? If so then how can B3 be switched and encapsulated inside B1 in the middle of B2(since B1 starts at L8)? Are you assuming a merge point on L9? Also how does L9 know it should encapsulate B3 inside B1?

By the way since MPLS-TP does not support merging your method is not applicable to MPLS-TP. While any MPLS-TP method should be applicable to MPLS. So my question to the group is whether they like to see 2 different methods, one for MPLS-TP and one for MPLS?

Thanks,
Shahram 

-----Original Message-----
From: Sriganesh Kini [mailto:[email-masked]] 
Sent: Monday, March 29, 2010 5:27 PM
To: Shahram Davari
Cc: [email-masked]; [email-masked]
Subject: RE: Comments to Efficient FRR using Facility backup in ring topology

Hi Shahram.

Thanks

- Sri

---

From: "Shahram Davari" <[email-masked]>
Date: Tue, 30 Mar 2010 15:00:57 -0700

Sri,

Editorial: Please replace B2 in my email with B1.

Thanks,
Shahram 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Shahram Davari
Sent: Tuesday, March 30, 2010 2:57 PM
To: Sriganesh Kini
Cc: [email-masked]; [email-masked]
Subject: Re: [mpls] Comments to Efficient FRR using Facility backup in ring topology

Hi Sri,

Thanks,
Shahram 

-----Original Message-----
From: Sriganesh Kini [mailto:[email-masked]] 
Sent: Monday, March 29, 2010 5:27 PM
To: Shahram Davari
Cc: [email-masked]; [email-masked]
Subject: RE: Comments to Efficient FRR using Facility backup in ring topology

Hi Shahram.

Thanks

- Sri

---

From: Sriganesh Kini <[email-masked]>
Date: Tue, 30 Mar 2010 18:25:37 -0400

- Sri

> many LSPs in many-to-one backup.

This is a terminology issue. The two LSPs defined in RFC4090 are - detour and bypass.
The methods defined in RFC4090 are 'one-to-one backup' and 'facility backup'. The detour LSP is used by the method 'one-to-one backup' and the bypass LSP is used by the 'facility backup' method. See abstract of RFC 4090.

> 
> Your draft says that the LSP B1: L8-L9-L10-L1-..-L7 is the 
> Bypass tunnel and the LSP B3: L9-L10-L1-...-L6 is the backup 
> LSP. Does this mean that B3 is transported inside B1? If so 
> then how can B3 be switched and encapsulated inside B1 in the 
> middle of B2(since B1 starts at L8)? Are you assuming a merge 
> point on L9? Also how does L9 know it should encapsulate B3 inside B1?

[Have accounted for your typo by replacing B2 by B1]

B3 is not transported inside B1.

> 
> By the way since MPLS-TP does not support merging your method 
> is not applicable to MPLS-TP. While any MPLS-TP method should 
> be applicable to MPLS. So my question to the group is whether 
> they like to see 2 different methods, one for MPLS-TP and one 
> for MPLS?

We need to be careful when we use the term merging. The merging used by LDP is different from the merging in FRR. Even though label operations on MP indicate 'merge', since PLR puts traffic on either the protected or the backup (but never both), traffic is not being 'merged' on MP in the same sense as in LDP.

> The terminology used is from RFC4090, except what may be 
> confusing is the origination of the backup LSP from PLR-u.
> 
> Note that the backup LSP from PLR-u can be setup similar to a 
> bypass (in which case it will protect all LSPs from L9 to L6 
> going via L8-L7) or similar to a detour (in which case a 
> detour will have to be setup for each protected LSP that goes 
> from L9 to L6 via L8-L7). The draft supports both methods.
> 
> Thanks
> 
> - Sri
>  
> 
> > I think we have a disconnect here. I think it has to do with the 
> > terminology used. You are saying backup LSP starts from
> > L9 but Bypass LSP starts from L8. I thought these are the same? can 
> > you explain this? What is backup LSP and Bypass LSP and 
> which LSRs do 
> > they cover and what is the relationship between them?
> > 
> > Thx
> > SD
> > 
> > The BFD is running on the bypass LSP (starting from L8). L8 will 
> > generate the alert fastest since the failure is local to 
> it. L9 uses 
> protection 
> > switched by L10 (PLR-u) by acting on the same alert along 
> the bypass 
> > LSP.
> > Similarly a LSP L1-L10-L9-L8-L7 will be protection switched by L1 
> > (PLR-u) again by acting on the same alert.
> > 
> > > 
> > > > 
> > The TTL is not expiring due to a packet looping. This TTL expiry is 
> > best viewed as the purposeful TTL expiry (and
> > response) of traceroute. At the same time none of the TTL expiry 
> > procedures (required for forwarding) are lost since GAL TTL is used 
> > for that purpose. It is also backward compatible since older LSRs 
> > would simply treat this as a packet with TTL expired. Also, 
> TTL expiry 
> > capabilities of current hardware is re-usable. The spirit of

---

From: "Shahram Davari" <[email-masked]>
Date: Tue, 30 Mar 2010 15:34:47 -0700

Hi Sri,

Pls see inline.

SD 

-----Original Message-----
From: Sriganesh Kini [mailto:[email-masked]] 
Sent: Tuesday, March 30, 2010 3:26 PM
To: Shahram Davari
Cc: [email-masked]; [email-masked]
Subject: RE: Comments to Efficient FRR using Facility backup in ring topology

- Sri

SD> Yes, but in the facility backup the tunnel (top label) that carries multiple LSPs is the Bypass tunnel and each LSP inside that tunnel is Backup LSP.  

SD> If B3 is not carried inside B1 then are you saying that B3 is using the detour mechanism? In other words you are using both detour (at L9) and facility backup (at L8)?

SD> That is not important. MPLS-TP does not allow any type of merging at all, whether you send traffic on the backup path or not.

---

From: Autumn Liu <[email-masked]>
Date: Tue, 30 Mar 2010 18:42:32 -0400

Shahram,

The bypass LSP B1 (L8-L9-L10-L1..-L6-L7) and the optimized bypass LSP (L9-L10-L1..-L6) are established independently. There is no tarffic transport of optimized bypass LSP inside bypass LSP B1 or vice versa. Hence there is no new encapsulation or merge introduced with this draft. The setup of the bypass LSP B1 and the optimized bypass LSP and PLR/MP behavior should be the same as RFC 4090 specifies.

There are two changes introduced by this draft.
1) the FRR trigger to the optimized bypass LSP. Since the PLR-u is not aware of the failure on link L7-L8, we proposed the fast alert LSP draft. 
2) the information about which bypass LSP is protecting, this is carried on the RRO object for the protected LSP and can be used for PLR-u to decide which protected LSP needs FRR switch over.

Autumn

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Shahram Davari
Sent: Tuesday, March 30, 2010 3:35 PM
To: Sriganesh Kini
Cc: [email-masked]; [email-masked]
Subject: Re: [mpls-tp] Comments to Efficient FRR using Facility backup in ring topology

Hi Sri,

Pls see inline.

SD 

-----Original Message-----
From: Sriganesh Kini [mailto:[email-masked]]
Sent: Tuesday, March 30, 2010 3:26 PM
To: Shahram Davari
Cc: [email-masked]; [email-masked]
Subject: RE: Comments to Efficient FRR using Facility backup in ring topology

- Sri

> 
> Your draft says that the LSP B1: L8-L9-L10-L1-..-L7 is the Bypass 
> tunnel and the LSP B3: L9-L10-L1-...-L6 is the backup LSP. Does this 
> mean that B3 is transported inside B1? If so then how can B3 be 
> switched and encapsulated inside B1 in the middle of B2(since B1 
> starts at L8)? Are you assuming a merge point on L9? Also how does L9 
> know it should encapsulate B3 inside B1?

> 
> By the way since MPLS-TP does not support merging your method is not 
> applicable to MPLS-TP. While any MPLS-TP method should be applicable 
> to MPLS. So my question to the group is whether they like to see 2 
> different methods, one for MPLS-TP and one for MPLS?

> The terminology used is from RFC4090, except what may be confusing is 
> the origination of the backup LSP from PLR-u.
> 
> Note that the backup LSP from PLR-u can be setup similar to a bypass 
> (in which case it will protect all LSPs from L9 to L6 going via L8-L7) 
> or similar to a detour (in which case a detour will have to be setup 
> for each protected LSP that goes from L9 to L6 via L8-L7). The draft 
> supports both methods.
> 
> Thanks
> 
> - Sri
>  
> 
> > l it does not break MPLS. Alternatives (so far) are either complex,

---

From: "Shahram Davari" <[email-masked]>
Date: Tue, 30 Mar 2010 15:50:41 -0700

Hi Autumn,

But the draft calls the B3 LSP (L9-L10-L1..-L6) a backup LSP and not a bypass LSP:

"Using the RROs of B1, P1 and the TED,it deduces that a backup path L9-L10-L1-L2-L3-L4-L5-L6 can be
 used to protect P1. Say this LSP is called B3"

So are you saying that B3 is a bypass LSP and not a backup LSP? Are you then saying that an LSR-u intercepts the BFD of a bypass tunnel (B1) to decide on protection switching traffic to another bypass tunnel (B3)? This is weird.

Also I didn't say you have introduced new merging. I said FRR in principle uses label merging at MP which can't be applied to MPLS-TP.

Regards,
Shahram

-----Original Message-----
From: Autumn Liu [mailto:[email-masked]] 
Sent: Tuesday, March 30, 2010 3:43 PM
To: Shahram Davari; Sriganesh Kini
Cc: [email-masked]; [email-masked]
Subject: RE: Comments to Efficient FRR using Facility backup in ring topology

Shahram,

Autumn

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Shahram Davari
Sent: Tuesday, March 30, 2010 3:35 PM
To: Sriganesh Kini
Cc: [email-masked]; [email-masked]
Subject: Re: [mpls-tp] Comments to Efficient FRR using Facility backup in ring topology

Hi Sri,

Pls see inline.

SD 

-----Original Message-----
From: Sriganesh Kini [mailto:[email-masked]]
Sent: Tuesday, March 30, 2010 3:26 PM
To: Shahram Davari
Cc: [email-masked]; [email-masked]
Subject: RE: Comments to Efficient FRR using Facility backup in ring topology

- Sri

---

From: Greg Mirsky <[email-masked]>
Date: Tue, 30 Mar 2010 15:51:10 -0700

Dear Shahram,
I believe that we, as a group, are still discussing which types of merging
LSPs are excluded from the MPLS-TP. The bypass tunnel of the FRR's Facility
protection is, in my view, hierarchical LSP, and hierarchical LSPs are part
of MPLS-TP.
As I've mentioned before, the proposal has other issues that concerns me in
regard to its applicability to the MPLS-TP. (Yes, it could be still
applicable to MPLS).

Regards,
Greg

On Tue, Mar 30, 2010 at 3:34 PM, Shahram Davari <[email-masked]> wrote:

> The methods defined in RFC4090 are 'one-to-one backup' and 'facility
> backup'. The detour LSP is used by the method 'one-to-one backup' and the
> bypass LSP is used by the 'facility backup' method. See abstract of RFC
> 4090.
>
> SD> Yes, but in the facility backup the tunnel (top label) that carries
> multiple LSPs is the Bypass tunnel and each LSP inside that tunnel is Backup
> LSP.
>
> >
> SD> If B3 is not carried inside B1 then are you saying that B3 is using the
> detour mechanism? In other words you are using both detour (at L9) and
> facility backup (at L8)?
>
> >
> We need to be careful when we use the term merging. The merging used by LDP
> is different from the merging in FRR. Even though label operations on MP
> indicate 'merge', since PLR puts traffic on either the protected or the
> backup (but never both), traffic is not being 'merged' on MP in the same
> sense as in LDP.
>
> SD> That is not important. MPLS-TP does not allow any type of merging at
> all, whether you send traffic on the backup path or not.
>
> >
> > Thanks,
> > Shahram
> >
> >

---

From: "Shahram Davari" <[email-masked]>
Date: Tue, 30 Mar 2010 15:58:08 -0700

Hi Greg,

I don't think the hierarchical part of Facility backup in FRR is a problem. The problem is when the bypass LSP terminates (at MP) and the backup LSP traffic is merged with original protected LSP traffic. Such merging in my opinion is not allowed in MPLS-TP.

Thanks,
Shahram

Sent: Tuesday, March 30, 2010 3:51 PM

Dear Shahram,
I believe that we, as a group, are still discussing which types of merging LSPs are excluded from the MPLS-TP. The bypass tunnel of the FRR's Facility protection is, in my view, hierarchical LSP, and hierarchical LSPs are part of MPLS-TP.
As I've mentioned before, the proposal has other issues that concerns me in regard to its applicability to the MPLS-TP. (Yes, it could be still applicable to MPLS).

Regards,
Greg

On Tue, Mar 30, 2010 at 3:34 PM, Shahram Davari <[email-masked]<mailto:[email-masked]>> wrote:
Hi Sri,

Pls see inline.

SD

-----Original Message-----
From: Sriganesh Kini [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Tuesday, March 30, 2010 3:26 PM
To: Shahram Davari
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: RE: Comments to Efficient FRR using Facility backup in ring topology

- Sri

---

From: Sriganesh Kini <[email-masked]>
Date: Tue, 30 Mar 2010 19:23:11 -0400

Shahram, see inline

- Sri

> > - Bypass Tunnel: An LSP that is used to protect a set of 
> LSPs passing 
> > over a common facility.
> The methods defined in RFC4090 are 'one-to-one backup' and 
> 'facility backup'. The detour LSP is used by the method 
> 'one-to-one backup' and the bypass LSP is used by the 
> 'facility backup' method. See abstract of RFC 4090.
> 
> SD> Yes, but in the facility backup the tunnel (top label) 
> that carries multiple LSPs is the Bypass tunnel and each LSP 
> inside that tunnel is Backup LSP.  

Each LSP inside is the protected LSP.

> SD> If B3 is not carried inside B1 then are you saying that 
> B3 is using the detour mechanism? In other words you are 
> using both detour (at L9) and facility backup (at L8)?

B3 can be setup either as a detour or a bypass (not both).
Correct that B3 is setup from L9 (either as detour or byupass) and there is facility backup from L8.

> We need to be careful when we use the term merging. The 
> merging used by LDP is different from the merging in FRR. 
> Even though label operations on MP indicate 'merge', since 
> PLR puts traffic on either the protected or the backup (but 
> never both), traffic is not being 'merged' on MP in the same 
> sense as in LDP.
> 
> SD> That is not important. MPLS-TP does not allow any type of 
> merging at all, whether you send traffic on the backup path or not.

This should merely be an applicability issue. Can you justify the reason for that. 

> confusing is 
> same? can 
> expiry is

---

From: Sriganesh Kini <[email-masked]>
Date: Tue, 30 Mar 2010 19:30:45 -0400

Shahram, see inline.

- Sri

> To: Autumn Liu; Sriganesh Kini
> "Using the RROs of B1, P1 and the TED,it deduces that a 
> backup path L9-L10-L1-L2-L3-L4-L5-L6 can be  used to protect 
> P1. Say this LSP is called B3"
> 
> 
> So are you saying that B3 is a bypass LSP and not a backup 
> LSP? Are you then saying that an LSR-u intercepts the BFD of 

As stated earlier B3 is a backup LSP that can be setup either as a bypass or a detour.
When setup as a bypass (from L9) it can protect all LSPs that go via the facility that is being protected by the bypass (from L8) and have the same ingress and egress into the ring. In fact for failure of any facility/node between (but not including) L9 and L6 (via L8-L7) the same bypass (from L9) can be used for all protected LSPs that go through L9 and L6 (via L8-L7).

> a bypass tunnel (B1) to decide on protection switching 
> traffic to another bypass tunnel (B3)? This is weird.

This would be true for anything one wouldn't understand.

> 
> 
> Also I didn't say you have introduced new merging. I said FRR 
> in principle uses label merging at MP which can't be applied 
> to MPLS-TP.

This is merely for applicability. Can you justify it?

> The bypass LSP B1 (L8-L9-L10-L1..-L6-L7) and the optimized 
> bypass LSP (L9-L10-L1..-L6) are established independently. 
> There is no tarffic transport of optimized bypass LSP inside 
> bypass LSP B1 or vice versa. Hence there is no new 
> encapsulation or merge introduced with this draft. The setup 
> of the bypass LSP B1 and the optimized bypass LSP and PLR/MP 
> behavior should be the same as RFC 4090 specifies.
> 
> 1) the FRR trigger to the optimized bypass LSP. Since the 
> PLR-u is not aware of the failure on link L7-L8, we proposed 
> the fast alert LSP draft. 
> 2) the information about which bypass LSP is protecting, this 
> is carried on the RRO object for the protected LSP and can be 
> used for PLR-u to decide which protected LSP needs FRR switch over.
> 
> Autumn
> 
> 
> 
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Shahram Davari

---

From: Greg Mirsky <[email-masked]>
Date: Tue, 30 Mar 2010 16:31:30 -0700

Hi Shahram,
I agree that terminology has to be worked out before we can reach an
agreement ;)
Let's call the tunnel between PLR and MP - "FRR bypass tunnel".
Let's call the tunnel between PLR-u and MP-d - "PST bypass tunnel".

The FRR bypass tunnel will be deployed first and the PST bypass tunnel will
be deployed later. Because both tunnels are hierarchical LSPs I don't think
we have LSP merge case here. What we do have, and that is very strongly
discouraged in MPLS-TP requirements, is packet reordering within the LSP.
That is because both PLR and MP and further away from the ingress and egress
nodes of protected LSP segment (in fact, these are PLR-u and MP-d).
As I understand the document, there's no LSP merging, but termination of
hierarchical LSP. The tunnel label is popped on either MP or MP-d (perhaps
MP, in the case of facilityy protection is not the best term to use).

Regards,
Greg

On Tue, Mar 30, 2010 at 3:58 PM, Shahram Davari <[email-masked]> wrote:

>  Hi Greg,
>
> I don't think the hierarchical part of Facility backup in FRR is a problem.
> The problem is when the bypass LSP terminates (at MP) and the backup LSP
> traffic is merged with original protected LSP traffic. Such merging in my
> opinion is not allowed in MPLS-TP.
>
> Thanks,
> Shahram
>
> *Sent:* Tuesday, March 30, 2010 3:51 PM
> *To:* Shahram Davari
>
> On Tue, Mar 30, 2010 at 3:34 PM, Shahram Davari <[email-masked]>wrote:
>
>> Hi Sri,
>>
>> Pls see inline.
>>
>> SD
>>
>> SD> If B3 is not carried inside B1 then are you saying that B3 is using
>> the detour mechanism? In other words you are using both detour (at L9) and
>> facility backup (at L8)?
>>
>> >
>> We need to be careful when we use the term merging. The merging used by
>> LDP is different from the merging in FRR. Even though label operations on MP

---

From: "Shahram Davari" <[email-masked]>
Date: Tue, 30 Mar 2010 16:32:40 -0700

Hi Sri,

Pls see inline.

-Shahram 

-----Original Message-----
From: Sriganesh Kini [mailto:[email-masked]] 
Sent: Tuesday, March 30, 2010 4:23 PM
To: Shahram Davari
Cc: [email-masked]; [email-masked]
Subject: RE: Comments to Efficient FRR using Facility backup in ring topology

Shahram, see inline

- Sri

SD> I am sorry, but please re-read RFC4090. according to RFC4090 the original LSP that needs protection is called protection LSP and the LSP that goes inside Bypass tunnel is called backup LSP. Here is the definition:

"Protected LSP: An LSP is said to be protected at a given hop if it has one or multiple associated backup tunnels originating at that hop."

SD> this is not clear from text. In fact you are not using proper terminology. The way it is described at the moment only covers detour. 

SD> Correct it is related to applicability and all I am asking is since your method does not apply to MPLS-TP, then we need to define another method for MPLS-TP as well, which doesn't seem reasonable to me.

---

From: "Shahram Davari" <[email-masked]>
Date: Tue, 30 Mar 2010 16:35:56 -0700

Hi Greg,

I think the name MP (Merge Point) speaks to itself that it is a merging point between protected LSP and backup LSP. Basically there is a bridge function and not a selector function at MP. and MPLS-TP does not allow any LSP merging.

Regards,
Shahram

Sent: Tuesday, March 30, 2010 4:31 PM

Hi Shahram,
I agree that terminology has to be worked out before we can reach an agreement ;)
Let's call the tunnel between PLR and MP - "FRR bypass tunnel".
Let's call the tunnel between PLR-u and MP-d - "PST bypass tunnel".

The FRR bypass tunnel will be deployed first and the PST bypass tunnel will be deployed later. Because both tunnels are hierarchical LSPs I don't think we have LSP merge case here. What we do have, and that is very strongly discouraged in MPLS-TP requirements, is packet reordering within the LSP. That is because both PLR and MP and further away from the ingress and egress nodes of protected LSP segment (in fact, these are PLR-u and MP-d).
As I understand the document, there's no LSP merging, but termination of hierarchical LSP. The tunnel label is popped on either MP or MP-d (perhaps MP, in the case of facilityy protection is not the best term to use).

Regards,
Greg

On Tue, Mar 30, 2010 at 3:58 PM, Shahram Davari <[email-masked]<mailto:[email-masked]>> wrote:
Hi Greg,

Thanks,
Shahram

Cc: Sriganesh Kini; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [mpls-tp] Comments to Efficient FRR using Facility backup in ring topology

Dear Shahram,

Regards,
Greg

Pls see inline.

SD

-----Original Message-----
From: Sriganesh Kini [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Tuesday, March 30, 2010 3:26 PM
To: Shahram Davari
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: RE: Comments to Efficient FRR using Facility backup in ring topology

- Sri

---

From: "Shahram Davari" <[email-masked]>
Date: Tue, 30 Mar 2010 16:43:23 -0700

Sri,

> This would be true for anything one wouldn't understand.

It could also be true for something that one understands very well but finds it weird since it breaks architectural principles.

-Shahram

---

From: Sriganesh Kini <[email-masked]>
Date: Tue, 30 Mar 2010 19:52:15 -0400

See inline.

- Sri

> Sent: Tuesday, March 30, 2010 4:33 PM
> To: Sriganesh Kini
> > > - Backup Tunnel: The LSP that is used to backup up one of 
> the many 
> > > LSPs in many-to-one backup.
> > 
> 'facility 
> > backup'. The detour LSP is used by the method 'one-to-one 
> backup' and 
> > the bypass LSP is used by the 'facility backup' method. See 
> abstract 
> > of RFC 4090.
> > 
> > that carries multiple LSPs is the Bypass tunnel and each LSP inside 
> > that tunnel is Backup LSP.
> 
> SD> I am sorry, but please re-read RFC4090. according to 
> RFC4090 the original LSP that needs protection is called 
> protection LSP and the LSP that goes inside Bypass tunnel is 
> called backup LSP. Here is the definition:
> 
> "Protected LSP: An LSP is said to be protected at a given hop 
> if it has one or multiple associated backup tunnels 
> originating at that hop."

Non sequitur. That is only talking of association. However it is not important. If you have understood that protected LSP can be encapsulated inside the bypass (from L9) that should be enough.

As an aside since the protected LSP is encapsulated inside the bypass LSP, none of the LSRs along the backup path switch based on the protected LSP label. They switch on the bypass LSP label. These nodes are not even aware of the protected LSP.

> > B3 is using the detour mechanism? In other words you are using both 
> > detour (at L9) and facility backup (at L8)?
> 
> Correct that B3 is setup from L9 (either as detour or 
> byupass) and there is facility backup from L8.
> 
> SD> this is not clear from text. In fact you are not using 
> proper terminology. The way it is described at the moment 
> only covers detour. 

Again pls refer to the abstract of RFC4090. The draft covers both detour and bypass. We can state it more explicitly in the next rev. So in that sense your comment is accepted. Also earlier thread to Phil where this was clarified.

> merging used 
> > by LDP is different from the merging in FRR.
> > Even though label operations on MP indicate 'merge', since PLR puts 
> > traffic on either the protected or the backup (but never both), 
> > traffic is not being 'merged' on MP in the same sense as in LDP.
> > 
> SD> Correct it is related to applicability and all I am 
> asking is since your method does not apply to MPLS-TP, then 
> we need to define another method for MPLS-TP as well, which 
> doesn't seem reasonable to me.

Can you explicitly point to text that states that RFC4090 is not applicable to MPLS-TP?

> > > The bypass with PLR(L8) and MP(L7) is different from the 
> backup LSP 
> > > from PLR-u(L9) to its MP(L6).
> > > 
> with the

---

From: "Shahram Davari" <[email-masked]>
Date: Tue, 30 Mar 2010 16:56:18 -0700

Hi Authors,

I think I got all the information I needed regarding your draft. 

For the following reasons I don't support this draft to become a WG document:

1) It breaks multiple architectural principles such as snooping neighboring LSP BFD flows to decided to perform protection switching on another LSP.
2) Due to merging at MP (merge point), it does not apply to MPLS-TP and therefore we still need another method for MPLS-TP
3) The Alert mechanism that it requires is not practical and breaks MPLS TTL forwarding and doing it in CPU will slow down the BFD flow.

Regards,
Shahram

---

From: Sriganesh Kini <[email-masked]>
Date: Tue, 30 Mar 2010 19:58:42 -0400

I am merely asking for specifics on what and how you consider is broken.

There is no reason why PLR-u should not protection switch to a bypass from L9(B3).

- Sri

> Sent: Tuesday, March 30, 2010 4:43 PM
> To: Sriganesh Kini; Autumn Liu
> > a bypass tunnel (B1) to decide on protection switching traffic to 
> > another bypass tunnel (B3)? This is weird.
> 
> It could also be true for something that one understands very 
> well but finds it weird since it breaks architectural principles.
> 
> -Shahram
>

---

From: Sriganesh Kini <[email-masked]>
Date: Tue, 30 Mar 2010 20:12:00 -0400

inline

- Sri

> Sent: Tuesday, March 30, 2010 4:56 PM
> To: Shahram Davari; Sriganesh Kini; Autumn Liu
> 1) It breaks multiple architectural principles such as 
> snooping neighboring LSP BFD flows to decided to perform 
> protection switching on another LSP.

There is a relation between the LSPs. Technically the word 'Snooping' should be used only if the packet is being examined at a inner layer even though there is no indication in the packet to do so. The LSP label TTL and the FLA-bit ensure that the packet is being looked into purposefully. So this is technically not snooping. There is no architectural restriction on how a trigger is conveyed to do the protection switch. So there is NO architectural principle that is broken.

> 2) Due to merging at MP (merge point), it does not apply to 
> MPLS-TP and therefore we still need another method for MPLS-TP

This is merely for applicability. That too only if there is clear text that indicates that RFC4090 is not applicable to MPLS-TP. 

> 3) The Alert mechanism that it requires is not practical and 
> breaks MPLS TTL forwarding and doing it in CPU will slow down 
> the BFD flow.

Not practical seems to be an implementation specific statement. It has been explained in this mailing list earlier why all the elements to do this in hardware/firmware should already be covered by current MPLS packet processing elements. It has also been explained how the spirit of RFC 3031, 3032, 3443 are intact. Even if the worst case where a rare implementation does this in CPU this is only for packets that are sent during the failure and with a large periodic timer at other times. It should not result in slowing down any BFD flow.