Subject: Remote LFA

From: Clarence Filsfils <[email-masked]>
Date: Tue, 11 Oct 2011 18:08:39 +0200

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

---

From: "Henderickx, Wim (Wim)" <[email-masked]>
Date: Tue, 11 Oct 2011 18:10:44 +0200

Clarence yes I saw this in the last IETF and i believe this has a lot of value 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Clarence Filsfils
Sent: dinsdag 11 oktober 2011 18:09
To: [email-masked]; Stewart Bryant (stbryant); So, Ning; [email-masked]
Subject: Remote LFA

Cheers,
Clarence
_______________________________________________
rtgwg mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/rtgwg

---

From: Gábor Sándor Enyedi <[email-masked]>
Date: Tue, 11 Oct 2011 18:25:06 +0200

Wow... I will read it as soon as I can, I'm curious what is the difference between this and http://tools.ietf.org/html/draft-hokelek-rlfap-01 - first I thought that you're speaking about this one, since the title is very similar. At the last IETF we proposed this http://tools.ietf.org/html/draft-csaszar-ipfrr-fn-01, but it seemed that everybody was strongly against giving up local protection (like it was a religious dogma). It's good to see that I'm not alone anymore!
BR,

Gabor

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Clarence Filsfils
Sent: Tuesday, October 11, 2011 6:09 PM
To: [email-masked]; Stewart Bryant (stbryant); So, Ning; [email-masked]
Subject: Remote LFA

Cheers,
Clarence

---

From: Clarence Filsfils <[email-masked]>
Date: Tue, 11 Oct 2011 18:35:17 +0200

Gabor,

It is independent. See the draft:

"
6.  Historical Note

    The basic concepts behind Remote LFA were invented in 2002 and were
    later included in draft-bryant-ipfrr-tunnels, submitted in 2004.

    draft-bryant-ipfrr-tunnels targetted a 100% protection coverage and
    hence included additional mechanims on top of the Remote LFA concept.
    The addition of these mechanisms made the proposal very complex and
    computationally intensive and it was therefore not pursued as a
    working group item.

    As explained in [I-D.filsfils-rtgwg-lfa-applicability], the purpose
    of the LFA FRR technology is not to provide coverage at any cost.  A
    solution for this already exists with MPLS TE FRR.  MPLS TE FRR is a
    mature technology which is able to provide protection in any topology
    thanks to the explicit routing capability of MPLS TE.

    The purpose of LFA FRR technology is to provide for a simple FRR
    solution when such a solution is possible.  The first step along this
    simplicity approach was "local" LFA [RFC5286].  We propose "Remote
    LFA" as a natural second step.  The following section motivates its
    benefits in terms of simplicity, incremental deployment and
    significant coverage increase.
"

Cheers,
Clarence

---

From: "Sucec, John M" <[email-masked]>
Date: Tue, 11 Oct 2011 13:07:35 -0400

Gabor, thank you for recalling the http://tools.ietf.org/html/draft-hokelek-rlfap-01 Internet Draft that Telcordia submitted earlier.

All: While that earlier Internet Draft did not gain much traction within the Routing Area WG at the time of its submission, we continued to experiment with its methods and have published some proof-of-concept results.

I am glad to see that there is renewed interest in the general topic of expanding/formalizing protection against link failures beyond the basic LFA path mechanism (RFC 5286).

I will review the latest drafts on LFA technologies and look forward to collaborating where possible.

Thanks.

John
________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Gábor Sándor Enyedi [[email-masked]]
Sent: Tuesday, October 11, 2011 12:25 PM
To: Clarence Filsfils; [email-masked]; Stewart Bryant (stbryant); So, Ning; [email-masked]
Subject: RE: Remote LFA

Gabor

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Clarence Filsfils
Sent: Tuesday, October 11, 2011 6:09 PM
To: [email-masked]; Stewart Bryant (stbryant); So, Ning; [email-masked]
Subject: Remote LFA

Cheers,
Clarence

---

From: Sriganesh Kini <[email-masked]>
Date: Tue, 11 Oct 2011 13:21:02 -0700

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.

-- 
- Sri

---

From: "Henderickx, Wim (Wim)" <[email-masked]>
Date: Wed, 12 Oct 2011 07:30:44 +0200

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: [email-masked] [mailto:[email-masked]] On Behalf Of Sriganesh Kini
Sent: dinsdag 11 oktober 2011 22:21
To: Henderickx, Wim (Wim)
Cc: Clarence Filsfils; [email-masked]; Stewart Bryant (stbryant); So, Ning; [email-masked]
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) <[email-masked]<mailto:[email-masked]>> wrote:
Clarence yes I saw this in the last IETF and i believe this has a lot of value

-----Original Message-----
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Clarence Filsfils
Sent: dinsdag 11 oktober 2011 18:09
To: [email-masked]<mailto:[email-masked]>; Stewart Bryant (stbryant); So, Ning; [email-masked]<mailto:[email-masked]>
Subject: Remote LFA

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

--
- Sri

---

From: Sriganesh Kini <[email-masked]>
Date: Tue, 11 Oct 2011 22:51:53 -0700

Of course when such a LSP exists that can function as backup it should be
used. The point was that sometimes such an LSP may not exist especially with
SRLG failures thereby reducing coverage. The technique can be extended to
handle such cases as well thus further increasing coverage.

On Tue, Oct 11, 2011 at 10:30 PM, Henderickx, Wim (Wim) <
[email-masked]> wrote:

> 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:* [email-masked] [mailto:[email-masked]] *On
> Behalf Of *Sriganesh Kini
> *Sent:* dinsdag 11 oktober 2011 22:21
> *To:* Henderickx, Wim (Wim)
> *Cc:* Clarence Filsfils; [email-masked]; Stewart Bryant (stbryant); So,
> Ning; [email-masked]
> *Subject:* Re: Remote LFA****
>
> ** **
>
> About related work -****
>
> ** **
>
> such that traffic does not loop back, it handles SRLG as well.****
>
> ** **
>
> [email-masked]> wrote:****
>
> Clarence yes I saw this in the last IETF and i believe this has a lot of
> value****
>
>
> https://www.ietf.org/mailman/listinfo/rtgwg****
>
>
>
> ****
>
> ** **
>
> --
> - Sri****
>

-- 
- Sri

---

From: András Császár <[email-masked]>
Date: Wed, 12 Oct 2011 15:53:46 +0200

Hi John!

http://tools.ietf.org/html/draft-csaszar-ipfrr-fn-01 also follows the principles of RLFAPs, but adds the dataplane notification protocol that we think was needed to make it real quick.

We are planning to show performance results from our IPFRR-FN prototype at the RTGWG meeting in Taiwan. Are you coming? Maybe we should combine the results if you have related experimentation results.

Thanks,
András

> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of Sucec, John M
> Sent: 2011. október 11. 19:08
> To: Gábor Sándor Enyedi; Clarence Filsfils; [email-masked]; 
> Stewart Bryant (stbryant); So, Ning; [email-masked]
> Subject: RE: Remote LFA
> 
> Gabor, thank you for recalling the 
> http://tools.ietf.org/html/draft-hokelek-rlfap-01 Internet 
> Draft that Telcordia submitted earlier.
> 
> All: While that earlier Internet Draft did not gain much 
> traction within the Routing Area WG at the time of its 
> submission, we continued to experiment with its methods and 
> have published some proof-of-concept results.
> 
> I am glad to see that there is renewed interest in the 
> general topic of expanding/formalizing protection against 
> link failures beyond the basic LFA path mechanism (RFC 5286).
> 
> From: [email-masked] [[email-masked]] On 
> Behalf Of Gábor Sándor Enyedi [[email-masked]]
> To: Clarence Filsfils; [email-masked]; Stewart Bryant 
> (stbryant); So, Ning; [email-masked]
> Subject: RE: Remote LFA
> 
> Wow... I will read it as soon as I can, I'm curious what is 
> the difference between this and 
> http://tools.ietf.org/html/draft-hokelek-rlfap-01 - first I 
> thought that you're speaking about this one, since the title 
> is very similar. At the last IETF we proposed this 
> http://tools.ietf.org/html/draft-csaszar-ipfrr-fn-01, but it 
> seemed that everybody was strongly against giving up local 
> protection (like it was a religious dogma). It's good to see 
> that I'm not alone anymore!
> BR,
> 
> Gabor
>

---

From: "So, Ning" <[email-masked]>
Date: Wed, 12 Oct 2011 10:38:39 -0400

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:[email-masked]]
Sent: Wednesday, October 12, 2011 12:31 AM
To: Sriganesh Kini
Cc: Clarence Filsfils; [email-masked]; Stewart Bryant (stbryant); So, Ning; [email-masked]
Subject: RE: Remote LFA

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]<mailto:[mailto:[email-masked]]> On Behalf Of Sriganesh Kini
Sent: dinsdag 11 oktober 2011 22:21
To: Henderickx, Wim (Wim)
Cc: Clarence Filsfils; [email-masked]<mailto:[email-masked]>; Stewart Bryant (stbryant); So, Ning; [email-masked]<mailto:[email-masked]>
Subject: Re: Remote LFA

About related work -

-----Original Message-----
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Clarence Filsfils
Sent: dinsdag 11 oktober 2011 18:09
To: [email-masked]<mailto:[email-masked]>; Stewart Bryant (stbryant); So, Ning; [email-masked]<mailto:[email-masked]>
Subject: Remote LFA

Cheers,
Clarence

--
- Sri

---

From: Alia Atlas <[email-masked]>
Date: Wed, 12 Oct 2011 10:54:08 -0400

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 <[email-masked]> 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:[email-masked]]
> *Sent:* Wednesday, October 12, 2011 12:31 AM
> *To:* Sriganesh Kini
>
> *Subject:* RE: Remote LFA****
>
> ** **
>

---

From: András Császár <[email-masked]>
Date: Wed, 12 Oct 2011 17:10:57 +0200

Please don't forget IPFRR-FN which is actively being investigated, too. :-)

If one is not aiming for 100% coverage, then there is LFA the coverage of which can be improved significantly with network tweaking (e.g. cost optimisation).

András

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of Alia Atlas
Sent: 2011. október 12. 16:54
To: So, Ning
Cc: [email-masked]; Stewart Bryant (stbryant); [email-masked]; Sriganesh Kini
Subject: 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 <[email-masked]<mailto:[email-masked]>> 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<tel:972-729-7905>
(Cell) 972-955-0914<tel:972-955-0914>

From: Henderickx, Wim (Wim) [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Wednesday, October 12, 2011 12:31 AM
To: Sriganesh Kini

About related work -

-----Original Message-----
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Clarence Filsfils
Sent: dinsdag 11 oktober 2011 18:09
To: [email-masked]<mailto:[email-masked]>; Stewart Bryant (stbryant); So, Ning; [email-masked]<mailto:[email-masked]>
Subject: Remote LFA

Cheers,
Clarence

--
- Sri