Re: Remote LFA

When RTGWG had this same discussion a number of years ago, the consensus was
that we wanted a solution that provided 100% coverage.  At the time, of
course, we were discussing both PQ (of which Remote LFA is a subset) and
U-turn alternates.

Now, we have two options that provide 100% coverage - NotVia, which has
proved too heavy-weight, and MRT, which is being actively investigated.

I don't believe that the requirements and reasons for 100% coverage that
were made a few years ago have changed.

Alia

On Wed, Oct 12, 2011 at 10:38 AM, So, Ning <ning.so@verizon.com> wrote:

> I agree.  Operators have been holding back the deployment of LFA because of
> those reasons Wim stated.   Remote LFA solves those problems.  It should
> help to speed up the LFA deployment in the field.  ****
>
> ** **
>
>  ****
>
> Best regards,****
>
>  ****
>
> Ning So****
>
> Verizon Corporate Technology****
>
> (office) 972-729-7905****
>
> (Cell) 972-955-0914****
>
>  ****
>
> ** **
>
> *From:* Henderickx, Wim (Wim) [mailto:wim.henderickx@alcatel-lucent.com]
> *Sent:* Wednesday, October 12, 2011 12:31 AM
> *To:* Sriganesh Kini
>
> *Cc:* Clarence Filsfils; rtgwg@ietf.org; Stewart Bryant (stbryant); So,
> Ning; imc.shand@googlemail.com
> *Subject:* RE: Remote LFA****
>
> ** **
>
> I still believe remote LFA has more merits for the service providers who
> deploy LFA and want to increase the coverage. It is not about SRLG or not.
> It is about coverage and remote LFA has the benefits that is re-uses
> operational procedures which are in place in service providers networks
> today. So extending them is better than introducing a complete new scheme.
> ****
>
> ** **
>
> *From:* sriganeshkini@gmail.com [mailto:sriganeshkini@gmail.com] *On
> Behalf Of *Sriganesh Kini
> *Sent:* dinsdag 11 oktober 2011 22:21
> *To:* Henderickx, Wim (Wim)
> *Cc:* Clarence Filsfils; rtgwg@ietf.org; Stewart Bryant (stbryant); So,
> Ning; imc.shand@googlemail.com
> *Subject:* Re: Remote LFA****
>
> ** **
>
> About related work -****
>
> ** **
>
> At the last IETF we presented draft-kini-mpls-frr-ldp that
> addresses additional cases where besides using a primary LSP to a remote LSR
> such that traffic does not loop back, it handles SRLG as well.****
>
> ** **
>
> On Tue, Oct 11, 2011 at 9:10 AM, Henderickx, Wim (Wim) <
> wim.henderickx@alcatel-lucent.com> wrote:****
>
> Clarence yes I saw this in the last IETF and i believe this has a lot of
> value****
>
>
> -----Original Message-----
> From: rtgwg-bounces@ietf.org [mailto:rtgwg-bounces@ietf.org] On Behalf Of
> Clarence Filsfils
> Sent: dinsdag 11 oktober 2011 18:09
> To: rtgwg@ietf.org; Stewart Bryant (stbryant); So, Ning;
> imc.shand@googlemail.com
> Subject: Remote LFA
>
> Please find the following submission complementing the LFA technology:
>
> http://www.ietf.org/id/draft-shand-remote-lfa-00.txt
>
> It drastically extends the coverage of LFA while keeping its simplicity.
>
> Cheers,
> Clarence
> _______________________________________________
> rtgwg mailing list
> rtgwg@ietf.org
> https://www.ietf.org/mailman/listinfo/rtgwg
> _______________________________________________
> rtgwg mailing list
> rtgwg@ietf.org
> https://www.ietf.org/mailman/listinfo/rtgwg****
>
>
>
> ****
>
> ** **
>
> --
> - Sri****
>
> _______________________________________________
> rtgwg mailing list
> rtgwg@ietf.org
> https://www.ietf.org/mailman/listinfo/rtgwg
>
>