This discussion on rings and costs is worthless: first, you cannot force a customer to use uniform link costs, so there will be such rings; second, András only showed you an example, but the phenomenon is not bounded to rings, you can find it in other networks as well.
Gabor -----Original Message----- From: Stewart Bryant [mailto:[email protected]] Sent: Thursday, November 10, 2011 2:14 AM 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. 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
