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 > -----Original Message----- > From: [email protected] > [mailto:[email protected]] > Sent: 2012. május 31. 10:33 > To: András Császár; Alia Atlas; [email protected] > Subject: RE: opinions on adoption of draft-shand-remote-lfa as a WG > draft > > 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.) > > > > > > > > > -----Original Message----- > > From: [email protected] [mailto:[email protected]] On Behalf > > Of Alia Atlas > > Sent: 2012. május 30. 18:59 > > To: [email protected] > > 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 protected] > > https://www.ietf.org/mailman/listinfo/rtgwg > _______________________________________________ > rtgwg mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/rtgwg > > ________________________________________________________________________ > _________________________________________________ > > 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. _______________________________________________ rtgwg mailing list [email protected] https://www.ietf.org/mailman/listinfo/rtgwg
