Subject: opinions on adoption of draft-shand-remote-lfa as a WG draft

From: Alia Atlas <[email-masked]>
Date: Wed, 30 May 2012 12:58:55 -0400

draft-shand-remote-lfa was presented favorably this last IETF.  There
is known IPR
associated with it on file ( https://datatracker.ietf.org/ipr/1770/ )
 This draft presents
a solution for IP/LDP fast-reroute that does not guarantee 100%
coverage but can substantially
improve coverage over LFAs.

We would like to initiate a WG poll to determine whether to adopt
draft-shand-remote-lfa.
We are, of course, interested in opinions and reasoning rather than
simple yes/no.

Thanks,
Alia

---

From: "Zafar Ali (zali)" <[email-masked]>
Date: Wed, 30 May 2012 12:06:22 -0500

Support, 

Thanks

Regards ... Zafar 

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Alia Atlas
> Sent: Wednesday, May 30, 2012 12:59 PM
> To: [email-masked]
> Subject: opinions on adoption of draft-shand-remote-lfa as a WG draft
> 
> _______________________________________________
> rtgwg mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtgwg

---

From: András Császár <[email-masked]>
Date: Thu, 31 May 2012 09:30:49 +0200

Hi Alia and All,

Instead of saying an explicit yes or no just now, here are the postives I see and the things that bother me.

Positive:

(A) Algorithmic simplicity, straightforward to understand

(B) I suspect that in a redundant network (with no cut-links and no cut-nodes) if link costs are equal (unit), then actually it provides ~100% coverage

(C) It is a node-internal solution, not requiring coop with anything.

What bothers:

(D) Potentially big number of targeted LDP sessions

(E) Inability to provide 100% coverage with arbitrary cost structure

(F) Presented coverage values are not fully convincing due to several reasons (if I was just missing results, then sorry!):

  (F1) Only relatively dense core-like topologies have been investigated, where LFA is mostly good enough anyway. However, IP/MPLS is getting pushed to the aggregation/access, where the topology is far from being that sparse, there ARE rings and there are (sparse) tree-like topologies which are extended with a few links here and there to boost redundancy. How does it work in such relatively sparse topos?

  (F2) Bidirectional coverage was not investigated (i.e. for LFA it was quite likely that in a not-so dense topology, if a failure was covered in one direction, it was not covered in the other one, meaning that for most bidir traffic it's not of too much value)

  (F3) Even if an operator tunes its topo to have high RLFA coverage, a topo change might ruin it (e.g. failures, etc.). So, what would be very useful is to see numbers on various topologies how a high coverage value changes with a small modification of the topology (e.g. one or two failures...)

(G) Have not yet seen papers/guidelines how to tune the network to be more RLFA friendly (which is possible, see e.g. (B))

(H) The draft does not mention SRLGs or multicast. 

I do understand that accepting it as a WG item still leaves the opportunity to answer some of these concerns.

If we adopt it, I think we should give guidelines on the RLFA friendly topologies and cost structures.

And, finally a more administrative question: why does it need to be Standards Track? Neither LFA, nor RLFA do not require any sort of cooperation with any other entity: what needs to be a standard in their cases? Both sound like a node-internal feature or a best practice or something like that.

András

> Sent: 2012. május 30. 18:59
> To: [email-masked]
> draft-shand-remote-lfa was presented favorably this last IETF.  There is
> known IPR associated with it on file (
> https://datatracker.ietf.org/ipr/1770/ )  This draft presents a solution
> for IP/LDP fast-reroute that does not guarantee 100% coverage but can
> substantially improve coverage over LFAs.
> 
> We would like to initiate a WG poll to determine whether to adopt draft-
> shand-remote-lfa.

---

From: <[email-masked]>
Date: Thu, 31 May 2012 09:34:27 +0200

Strong support,

Our simulations show 100% percent coverage using remote LFA : our core network topo are complex and not very LFA friendly but remote LFA works very well !
Solution is quite simple, automatic as LFA is basically ... We are currently working with vendors for implementations (for those who are not already implementing it ...) 

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] De la part de Alia Atlas
Envoyé : mercredi 30 mai 2012 18:59
À : [email-masked]
Objet : opinions on adoption of draft-shand-remote-lfa as a WG draft

draft-shand-remote-lfa was presented favorably this last IETF.  There is known IPR associated with it on file ( https://datatracker.ietf.org/ipr/1770/ )  This draft presents a solution for IP/LDP fast-reroute that does not guarantee 100% coverage but can substantially improve coverage over LFAs.

We would like to initiate a WG poll to determine whether to adopt draft-shand-remote-lfa.
We are, of course, interested in opinions and reasoning rather than simple yes/no.

Thanks,
Alia

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
France Telecom - Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, France Telecom - Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

From: <[email-masked]>
Date: Thu, 31 May 2012 10:33:01 +0200

> (D) Potentially big number of targeted LDP sessions
[SLI] Based on our simulation, only 4 T-LDP sessions at max is needed (for our case), 2 or 1 only in most cases. (now routers are able to handle hundreds of LDP sessions without issue, so adding few is not a big deal)

> (E) Inability to provide 100% coverage with arbitrary cost structure
[SLI] What do you mean exactly ? Do you mean that with some topology, you are unable to have 100% coverage ? Yes, few topologies can't work with rLFA as for LFA ... But is it really an issue ? I'm always trying to see simplicity vs gain ... As you mention rLFA is still an easy mechanism (as LFA is ...), it would provide you strong coverage extension. 
Note that as already mentionned in the draft (and I'm currently writing some more detail stuff on this), it is still possible to achieve 100% coverage but you should add explicit TE tunnel (implementation may be able to propose to establish it dynamically if it becomes a need).

[SLI] It is already planned as far as I know to add new use cases within the doc. I can already say that rLFA works very well with rings. We have plenty variety of rings with different metric patterns, different size of ring, and LFA provides 100% coverage in all of these cases (bidirectional).

[SLI] This is clearly a good point, I think most people are already aware of (I hope :) ), as it concerns already LFA ... If you have a good coverage with your nominal topo, a backup topology may not have a good coverage ... 

[SLI] this point could be addressed easily ...

[SLI] Doable easily and necessary ;) (I already talked about this with Clarence F.)

> is known IPR associated with it on file ( 
> https://datatracker.ietf.org/ipr/1770/ )  This draft presents a 
> solution for IP/LDP fast-reroute that does not guarantee 100% coverage 
> but can substantially improve coverage over LFAs.
> 
> draft- shand-remote-lfa.

---

From: <[email-masked]>
Date: Thu, 31 May 2012 10:24:25 +0000

Alia, Alvaro,

I support adoption.

As requested, below some (quickly written) opinions:

Positive:
++ Incremental deployment with incremental benefits.
(Eventually some focused deployments may be enough to solve the main LFA limitations.)
+ Relatively easy understanding (and possibly control) for the network operator of the path taken by the traffic. Useful for capacity planning, network manageability and respect of design rules (e.g. don't use a PE to backup a P)
+ Relative simplicity
+ Can provide 100% coverage in some real networks. (at least one I am aware of)

Negative:
- "esthetic": some "random" (from human design perspective) mesh of control plane sessions. May have an impact on the management/monitoring. (e.g. how many T-LDP sessions am I supposed on have on node XT6 ? Is one missing?).
- lacks 100% guaranteed coverage. Could eventually be worked on (e.g. studies, addition of (virtual TE) links) but requires work :-)

Positive definitely outweighs the negative.
IMHO will be deployed, with or without the IETF. I would prefer with the IETF review and standardization.

Regards,
Bruno

>From Alia Atlas >Sent: Wednesday, May 30, 2012 6:59 PM

---

From: Stewart Bryant <[email-masked]>
Date: Thu, 31 May 2012 11:36:08 +0100

Andras

I think that you omitted to note that RLFA supports incremental deployment
well, and in particular needs no new protocols. This is in contrast to all
of the alternatives that have been put on the table, which require the
on-repair-path nodes to change.

The approach proposed here is to publish RLFA in order to provide a
solution for those networks that find LFA too limiting, but need a
solution that they can deploy in the short term. Meanwhile we should
take another look at the relative merits of MRT, not-via etc and
understand whether any of them offer the sort of overwhelming
advantage that would justify the deployment of a new approach
that requires routing  domain wide deployment.

On 31/05/2012 09:33, [email-masked] wrote:
> (F3) Even if an operator tunes its topo to have high RLFA coverage, a 
> topo change might ruin it (e.g. failures, etc.). So, what would be 
> very useful is to see numbers on various topologies how a high 
> coverage value changes with a small modification of the topology (e.g. 
> one or two failures...) 
> [SLI] This is clearly a good point, I think most people are already 
> aware of (I hope :) ), as it concerns already LFA ... If you have a 
> good coverage with your nominal topo, a backup topology may not have a 
> good coverage ... 
Let's be careful here, it's not at all clear how the well the various
virtual topology approaches will behave under multiple failures,
since you need to concurrently manage the traffic patterns in
both topologies. In any case I think that we can always construct
pathological repair topologies which whilst they technically work,
have properties that would be unacceptable to an operator.

Rings were mentioned, and RLFA handles rings just fine.

Remember that RLFA is really the viable subset of
draft-bryant-ipfrr-tunnels-03, a draft where we have already explored
a lot of the corner cases. The RLFA draft is a pragmatic approach
that say's lets take the simple bits of the PQ technology, noting that it
can be incrementally deployed, and then we have more time to think
about what to do about the corner cases that LFA + RLFA cannot
address.

Stewart
(as an RLFA author)

---

From: Pierre Francois <[email-masked]>
Date: Thu, 31 May 2012 12:36:35 +0200

Alia, Alvaro,

+1,

I think Bruno is summarizing the situation perfectly.

Pierre.

On 5/31/12 12:24 PM, [email-masked] wrote:
> > From Alia Atlas>Sent: Wednesday, May 30, 2012 6:59 PM

---

From: "Adrian Farrel" <[email-masked]>
Date: Thu, 31 May 2012 15:18:08 +0100

Just a personal (non AD comment).

I would prefer that polls were conducted on extant I-Ds, not ones that have
expired.

Cheers,
Adrian

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Alia Atlas
> Sent: 30 May 2012 17:59
> To: [email-masked]

---

From: John E Drake <[email-masked]>
Date: Thu, 31 May 2012 12:26:39 -0700

Alia,

I support the WG adopting draft-shand-remote-lfa.  It provides a straightforward, low cost, and effective extension to LFAs.

Thanks,

John

Sent from my iPhone

>Sent: Wednesday, May 30, 2012 9:59 AM
>To: [email-masked]