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

From: András Császár <[email-masked]>
Date: Fri, 1 Jun 2012 09:33:52 +0200

Hi Stewart,

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

[András] I didn’t omit it, just didn’t give it a list letter. ☺ I perfectly agree with you, and I had the following question about this: 

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

It not only needs no new protocols, it needs no new forms of cooperation with any other entity. Other nodes need to support IP encaps/decaps, LDP and TLDP, but these are other RFCs.

András

---

From: Gábor Sándor Enyedi <[email-masked]>
Date: Fri, 1 Jun 2012 10:34:38 +0200

I conditionally support it. I think we need several further studies; e.g. what are the RLFA friendly topologies, how can I improve my network to keep up full coverage (and what extra cost that has), what is the bidirectional coverage of RLFA (if path cannot be protected in either directions, the route is not protected), how many targeted LDP sessions are needed when the network is not the one operated by Stephane Litkowski, what is the coverage when there was a failure in our network previously and so on.

Gabor

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Alia Atlas
Sent: Wednesday, May 30, 2012 6:59 PM
To: [email-masked]
Subject: 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
_______________________________________________
rtgwg mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/rtgwg

---

From: Stewart Bryant <[email-masked]>
Date: Fri, 01 Jun 2012 09:50:37 +0100

> It not only needs no new protocols, it needs no new forms of cooperation with any other entity. Other nodes need to support IP encaps/decaps, LDP and TLDP, but these are other RFCs.

Hi Andras

I think we are in sync here.

As to what track to put this on, that is not obvious and is something 
that we should discuss with Adrian (who is the AD responsible for the 
draft)

Stewart

Note BTW that WRT this draft I am recused and speak only as an author.

---

From: Gabor Retvari <[email-masked]>
Date: Fri, 1 Jun 2012 11:32:51 +0200

On Friday, June 01, 2012 10:34:38 Gábor Sándor Enyedi wrote:
> I conditionally support it. I think we need several further studies; e.g.
> what are the RLFA friendly topologies, how can I improve my network to
> keep up full coverage (and what extra cost that has), what is the
> bidirectional coverage of RLFA (if path cannot be protected in either
> directions, the route is not protected)

Just coincidentally, we have been doing some research on precisely these
questions for some time now. So far, we only have had preliminary results,
valid only for graphs with unit-costs. 

Interestingly, we found that if the graph of the network (disregarding LANs,
SRLGs, etc. for now) is symmetric, 2-edge-connected, and each link is
set to the same administrative cost, then RLFA provides full coverage against
single link failures.

The argument goes on as follows:

- if some router 's' has an RLFA to the next-hop 'n' towards some destination
  prefix 'd', then 's' has an RLFA to 'd' (with respect to the failure of
  link '(s,n)');

- if a graph is 2-edge-connected, every edge is contained in at least one
  ring, so '(s,n)' is also contained in a ring;

- consider the shortest ring amongst the rings that contain '(s,n)' and
  suppose that the ring consists of even number of nodes: then, the same
  reasoning as in the RLFA draft (draft-shand-remote-lfa-00, see Fig. 1) will
  show that the intersection of the extended P-space of 's' and the Q-space
  of 'n' is not empty;

- so 's' has an RLFA to the next-hop 'n', and so, by the first point, it has
  an RLFA to any 'd' reachable through 'n';

- the same applies to the case when the shortest ring that contains '(s,n)'
  is an odd-ring;

- since the above holds for any 's-d' pair, we conclude that we have full
  RLFA coverage.

Our initial numerical studies seem to support the above claims, but please,
don't hesitate to correct me if I'm wrong.

The rest of our investigations are concerned with "unextended RLFA" (i.e.,
the one without the extended P-space option) to see whether we really need
this complexity in RLFA.  We found that in 2-node-connected networks
"unextended RLFA" coverage can go down to 50%, and in the 2-edge-connected
case this can be as low as 33%, so the "extended" option is indeed important.

We have a rudimentary draft paper ready. If the need arises, we're happily
disclose it.

Gabor

-- 
Gábor Rétvári, Ph.D.
Research Fellow, BME-TMIT
Phone: +36-1-463-1060
Fax: +36-1-463-1763

---

From: Gábor Sándor Enyedi <[email-masked]>
Date: Fri, 1 Jun 2012 11:50:33 +0200

Actually, I'm not really surprised about the 100% coverage. But that is true only for link failures and uniform link costs, right? Isn't that possible to extend this reasoning to non-uniform link costs to find out what rings are not useable in that case? Moreover, can't we extend the same reasoning for node failures? There is simmilar cycle for s and its next-next-hop, when the network is 2-connected...

Gabor

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Gabor Retvari
Sent: Friday, June 01, 2012 11:33 AM
To: [email-masked]; Alia Atlas
Cc: Levente Csikor
Subject: Re: opinions on adoption of draft-shand-remote-lfa as a WG draft

> directions, the route is not protected)

Just coincidentally, we have been doing some research on precisely these questions for some time now. So far, we only have had preliminary results, valid only for graphs with unit-costs. 

Interestingly, we found that if the graph of the network (disregarding LANs, SRLGs, etc. for now) is symmetric, 2-edge-connected, and each link is set to the same administrative cost, then RLFA provides full coverage against single link failures.

Our initial numerical studies seem to support the above claims, but please, don't hesitate to correct me if I'm wrong.

The rest of our investigations are concerned with "unextended RLFA" (i.e., the one without the extended P-space option) to see whether we really need this complexity in RLFA.  We found that in 2-node-connected networks "unextended RLFA" coverage can go down to 50%, and in the 2-edge-connected case this can be as low as 33%, so the "extended" option is indeed important.

We have a rudimentary draft paper ready. If the need arises, we're happily disclose it.

Gabor

---

From: Pierre Francois <[email-masked]>
Date: Fri, 01 Jun 2012 12:26:41 +0200

Gabor,

Your analysis is right. It is a strong assumption to consider that all 
links have the same metric, though.

You can get rid of that assumption if you consider PQ with directed 
forwarding.
I had proved that in my thesis when I was young ;-)

biblio.info.ucl.ac.be/2007/457147.pdf  (page 59)

Pierre.

---

From: Stewart Bryant <[email-masked]>
Date: Fri, 01 Jun 2012 11:35:23 +0100

Gabor

Those are very reasonable questions, however it is quite a difficult
problem to address since we need real topologies and these
are only available under non-disclosure from network operators.
This has historically been a particular problem for the academic
IPFRR researchers.

Section 7.3 of the draft is a survey of a number of operational
networks that we have analyzed.

Stewart
(as author)

-- 
For corporate legal information go to:

http://www.cisco.com/web/about/doing_business/legal/cri/index.html

---

From: Gábor Sándor Enyedi <[email-masked]>
Date: Fri, 1 Jun 2012 12:47:24 +0200

Yes, I know that, we have the same problem. However, considering your results in section 7.3, I'm not sure what coverage is presented there. Is that the coverage of link or node protection? If that is only link protection, can you please add the same for node protection? Did you take into consideration that we almost always need bidirectional connection? That would be nice to add this information to the draft.

Gabor

-----Original Message-----
From: Stewart Bryant [mailto:[email-masked]] 
Sent: Friday, June 01, 2012 12:35 PM
To: Gábor Sándor Enyedi
Cc: Alia Atlas; [email-masked]
Subject: Re: opinions on adoption of draft-shand-remote-lfa as a WG draft

Gabor

Those are very reasonable questions, however it is quite a difficult problem to address since we need real topologies and these are only available under non-disclosure from network operators.
This has historically been a particular problem for the academic IPFRR researchers.

Section 7.3 of the draft is a survey of a number of operational networks that we have analyzed.

Stewart
(as author)

---

From: "Eric Osborne (eosborne)" <[email-masked]>
Date: Fri, 1 Jun 2012 06:37:31 -0500

Support

eric

> From: [email-masked] [mailto:[email-masked]] On Behalf
Of
> Alia Atlas
> Sent: Wednesday, May 30, 2012 12:59 PM
> 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.
>

---

From: Russ White <[email-masked]>
Date: Fri, 01 Jun 2012 08:51:22 -0400

Support.

Russ

On 5/31/2012 6:24 AM, [email-masked] wrote:
> 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
> _________________________________________________________________________________________________________________________
> 
> 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.
> 

-- 
<><
[email-masked]
[email-masked]

---

From: Gabor Retvari <[email-masked]>
Date: Fri, 1 Jun 2012 15:42:46 +0200

> valid only for graphs with unit-costs.

[...]

> We have a rudimentary draft paper ready. If the need arises, we're happily

Dear all,

Some people have asked the draft privately, so we made it available online:

http://qosip.tmit.bme.hu/~retvari/publications/rndm_2012.pdf

Please, keep it private as much as possible. 

We are open to any comments, corrections, etc.

Best regards,
Gabor

---

From: Stewart Bryant <[email-masked]>
Date: Fri, 01 Jun 2012 14:44:29 +0100

I have refreshed the draft.

A couple of minor changes, that will not impact the review:

1) Fixed Mike's affiliation and email address
2) Fixed Ning's email address (need to fix his affiliation when I know 
what to put in)
3) Fixed a formatting error (section 8 was not shown as a proper section)

Any other changes are an error caused in the process of recovering the 
correct XML.

Stewart
(as duty editor)

On 31/05/2012 15:18, Adrian Farrel wrote:
> Just a personal (non AD comment).
>
> I would prefer that polls were conducted on extant I-Ds, not ones that have
> expired.
>
> Cheers,
> Adrian
>
>> Sent: 30 May 2012 17:59

---

From: Jeff Tantsura <[email-masked]>
Date: Fri, 1 Jun 2012 17:29:39 -0400

Hi Alia,

Support for exactly these reasons.

Regards,
Jeff
-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of John E Drake
Sent: Thursday, May 31, 2012 12:27 PM
To: Alia Atlas; [email-masked]
Subject: RE: opinions on adoption of draft-shand-remote-lfa as a WG draft

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

>Of Alia Atlas
>Sent: Wednesday, May 30, 2012 9:59 AM
>To: [email-masked]
>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: András Császár <[email-masked]>
Date: Sat, 2 Jun 2012 17:36:49 +0200

Hi Stephane and Alia,

I agree that these concerns can be remedied, even during WG doc phase, and there are results and sources to make it possible.

Also, as someone said already, the KISS beauty :-) of the solution anyway outweighs the concerns, so

I support the doc to become a WG doc and eventually an RFC.

We should consider probably what track, but that's another question.

András

> From: [email-masked]
> [mailto:[email-masked]]
> Sent: 2012. május 31. 10:33
> To: András Császár; Alia Atlas; [email-masked]
> Some feedback :
> > (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).
> 
> (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?
> 
> [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).
> 
> 
>   (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 ...
> 
> (G) Have not yet seen papers/guidelines how to tune the network to be
> more RLFA friendly (which is possible, see e.g. (B))
> 
> [SLI] this point could be addressed easily ...
> 
> 
> 
> 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.
> 
> [SLI] Doable easily and necessary ;) (I already talked about this with
> Clarence F.)
> 
> 
> 
> 
> 
> 
> 
> > Sent: 2012. május 30. 18:59
> > To: [email-masked]
> ________________________________________________________________________
> _________________________________________________
> 
> 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.
> As emails may be altered, France Telecom - Orange is not liable for
> messages that have been modified, changed or falsified.
> Thank you.