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