Hi, I agree that having a solution with full coverage is very useful because it removes the need for complicated analysis to determine what is protected versus what is not (and worse, how that changes as the topology change). But the solution has to be simple for it to get deployed.
One approach using MPLS that solves this using extensions to a single protocol (LDP) is given in draft-kini-mpls-frr-ldp. 2011/11/10 András Császár <[email protected]>: > See inline... > >> -----Original Message----- >> From: Stewart Bryant [mailto:[email protected]] >> Sent: 2011. november 10. 2:14 >> To: Gábor Sándor Enyedi >> Cc: András Császár; [email protected] >> Subject: Re: Charter Update (Discussion) >> >> On 09/11/2011 20:54, Gábor Sándor Enyedi wrote: >> > Hi Steward, >> > >> > >> > That's forced first hop won't help; I can always add an extra node >> > against such tricks. :) >> > >> > 4 4 >> > [Src]-----[A]------[B] >> > | | >> > 2| |1 >> > | | >> > [C]-----[D]-----[Dest] >> > 1 3 >> > >> > You cannot solve this without "directed forwarding" (forcing B with >> > some magic to forward packets to A instead of to Dest). >> Think on that >> > phenomenon like this: until you have only P chance to protect a >> > failure, protecting it in both directions will always be >> P*P<P until P<1. :) >> > >> > >> > Gabor >> > >> We would have solved that in the original tunnels draft with >> directed forwarding at B. >> >> However you have not answered my point that practical rings >> (as opposed to ring fragments in mesh topologies) normally >> have equal cost per hop. > > Well, yes, you can of course substitute the above costs with hops, resulting > in a long cycle. > Then of course we can say that such long cycles normally don't exist. > > But then, this brings back to question No 0. :-) Do we need a solution that > works in arbitrary cases? > > One point I tried to have is that the normal coverage metrics used until now > (e.g. for LFA coverage tests) let things show up a little nicer than they > really are. I.e. coverage p vs p^2 as Gabor wrote. > > We gave the operators one tool (LFA) already which they can try to switch on > but with which they cannot be sure if it really works or for which prefixes > it actually work. We say instead, tune your network topology a little bit, > play with your link costs than you might get it to work better but even then > it still might not work without getting close to full-mesh topo :-). > > Do we want to give them yet-another tool with which they can again just hope > for "good luck" for their existing topologies and existing link metrics? (I > know this is a little exaggerated...) > > > Andras > > > >> >> Stewart >> >> >> > -----Original Message----- >> > From: [email protected] >> [mailto:[email protected]] On Behalf >> > Of Stewart Bryant >> > Sent: Wednesday, November 09, 2011 6:56 PM >> > To: András Császár >> > Cc: [email protected] >> > Subject: Re: Charter Update (Discussion) >> > >> > >> > Hi András >> > >> > Yes, it is true that for that topology fragment there is no >> bidirectional LFA solution. >> > >> > However you were talking about rings, and surely it's >> unusual for a ring topology to have non-uniform costs. >> > >> > If we consider tunnel solution with forced first hop the >> solution would work. >> > >> > C tunnels to A with forced first hop (C-Dest), decap and A to Src. >> > Src LFAs to A, A sends to B, B sends to Dest >> > >> > - Stewart >> > >> > On 09/11/2011 10:59, András Császár wrote: >> >> Hi Stewart, this phenomenon occurs with symmetric costs with LFA. >> >> >> >> Trying to sketch an example: >> >> >> >> 2 2 >> >> [Src]-----[A]------[B] >> >> | | >> >> 1| |1 >> >> | | >> >> [C]-------------[Dest] >> >> 2 >> >> >> >> Now for Src->Dest traffic, the link failure of Src-C can >> be remedied with LFA, as Src may pass the packet to A which >> is an LFA. For backwards traffic (e.g. TCP Acks) this link >> failure cannot be solved by C with LFA, so ultimately the >> Src-Dest traffic is screwed. >> >> >> >> >> >> András >> >> >> >> >> >>> -----Original Message----- >> >>> From: [email protected] [mailto:[email protected]] On >> >>> Behalf Of Stewart Bryant >> >>> Sent: 2011. november 8. 18:54 >> >>> To: [email protected] >> >>> Subject: Re: Charter Update (Discussion) >> >>> >> >>> On 08/11/2011 17:20, András Császár wrote: >> >>>> I think we should first see if there is a solution which >> >>> provides full coverage and practical (=reasonable complexity). >> >>>> One problem with non-full-coverage solutions is >> >>> bidirectional coverage. I.e. even if a flow is covered >> for a failure >> >>> in one direction it may not be covered in the reverse direction >> >>> which is, for most applications, equal to not being >> covered at all. >> >>> This property is often neglected in coverage estimates. As an >> >>> example consider the LFA unfirendly sub-topologies like >> >>> longer-than-triangle rings. In those rings it might seem that the >> >>> failures on the opposing side to the exit point are >> covered by the >> >>> LFA. But they are not covered in the reverse direction. >> Might be a >> >>> factor to consider for PQ and co too. >> >>> Can you give me an example here? >> >>> >> >>> I would expect a ring to have symmetric properties except >> when there >> >>> are asymmetric costs, but normally assymetric costs are a >> >>> configuration accident. >> >>> >> >>> Stewart >> >>> _______________________________________________ >> >>> rtgwg mailing list >> >>> [email protected] >> >>> https://www.ietf.org/mailman/listinfo/rtgwg >> >>> >> > >> > -- >> > For corporate legal information go to: >> > >> > http://www.cisco.com/web/about/doing_business/legal/cri/index.html >> > >> > >> > _______________________________________________ >> > rtgwg mailing list >> > [email protected] >> > https://www.ietf.org/mailman/listinfo/rtgwg >> > >> >> >> -- >> For corporate legal information go to: >> >> http://www.cisco.com/web/about/doing_business/legal/cri/index.html >> >> >> > _______________________________________________ > rtgwg mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/rtgwg > -- - Sri _______________________________________________ rtgwg mailing list [email protected] https://www.ietf.org/mailman/listinfo/rtgwg
