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

From: Sriganesh Kini <[email-masked]>
Date: Sat, 3 Apr 2010 20:08:13 -0400

Hi Phil, pls see inline

- Sri

> -----Original Message-----
> From: Phil Bedard [mailto:[email-masked]]
> Sent: Monday, March 29, 2010 8:53 AM
> To: [email-masked]
> Cc: Sriganesh Kini; [email-masked]; [email-masked]
> Subject: Re: [mpls] [mpls-tp] Comments to Efficient FRR using
> Facility backup in ring topology
>
> 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.

When the traffic is low priority and loss of upto 2s is acceptable, existing mechanisms may suffice. You may not even need FRR and plain old IGP convergence could be enough.
This draft's mechanism gives a way reduce the bandwidth used for protection while giving similar protection guarantees as FRR. The bandwidth savings could be used for traffic that generates additional revenue (higher/lower prio).

>
> 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.

Note that when PLR (C) has to protect against failure of node D then the bypass for a protected LSP A-B-C-D-E-O-P would have to be C-B-G-H-I-J-E (or C-B-L-M-N-O-E or even C-B-L-M-N-O but that is specifically for protected LSPs that go through O). PLR-u (B) makes the protection switch more efficient by setting up an additional backup B-G-H-I-J-E (or B-L-M-N-O) respectively. Correct that the alert on the normal FRR bypass would trigger a protection switch at 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.

Section 4 explains how to route the additional bypass from PLR-u. Additional text/figures can help to explain further. Comment accepted.
We have kept the topology in Fig 1 simple for illustrative clarity. Section 6 does explain how this translates to applicability into general topologies. Note that even in the simple topology in Figure 1 in the draft there will be additional bypasses from PLR-u to each egress on the ring where there is a protected LSP. This can be highlighted as well as additional complex topologies can be included. Comment accepted.

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

The amount of work is influenced by the implementation. It should not be a lot more work when built over a node protection bypass FRR infrastructure.
The gain of course depends on the nature/value of traffic carried on the network.

>
>
> Phil
>
>
>
> On Mar 29, 2010, at 3:09 AM, Curtis Villamizar wrote:
>
> >
> > In message
> >
> <[email-masked]
> > n.se>
> > Sriganesh Kini writes:
> >>
> >> Hi Curtis, see inline @ [Sri]
> >>
> >>
> >> - Sri
> >
> >
> > 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
> >
> >
> >> -----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
> >>
> >>
> >> In message
> >>
> <[email-masked]
> >> on.se>
> >> 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.
> >>
> >> [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.
> >
> > [CV] That is not what FRR does.
> >
> >> 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
> >>
> >>
> >>> ________________________________
> >>> 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:7
> >>> 87 [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].
> >>> c=
> >>>
> 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]">sriganesh.kini@ericsson.
> >>> co
> >>> m=
> >>> </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>
> >>> &g
> >>> t=
> >>> ; &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]">sriganesh.kini@ericsson.
> >>> co
> >>> m=
> >>> </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>
> >>> &g
> >>> t=
> >>> ;=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_--
> >
> > _______________________________________________
> > mpls mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/mpls
>
>