[email protected]
[Top] [All Lists]

Re: node disjoint and SRLG (was: questions on draft-bryant-ipfrr-tunnels

Subject: Re: node disjoint and SRLG was: questions on draft-bryant-ipfrr-tunnels-01.txt
From: Curtis Villamizar
Date: Tue, 23 Nov 2004 10:09:53 -0500
In message <[email protected]>
mike shand writes:
>  
> At 17:35 22/11/2004 -0500, Curtis Villamizar wrote:
>  
> >In message <[email protected]>
> >Alia Atlas writes:
> > >
> > > Curtis,
> > >
> > > I think that Mike's numbers are for the percentage of node failures that
> > > can't be repaired with a single primary tunnel+directed forwarding.
> > >
> > > I.e., it covers the node disjoint case pretty well.
> > >
> > > Alia
> >
> >
> >What he's saying is that in the worst case he looked at 13.77% of the
> >cases were not covered by single hop.  With 2 hop there is 100%
> >coverage but there is still some question about how computationally
> >feasible the 2 hop algoritm is.
>  
> Yes. Although there being some question is not the same as it being
> infeasible.


Yes, I agree.  As worded "still some question about how
computationally feasible ..." simply says that we haven't seen
anything that assures us that it is computationally feasible.


> >I thought the point of this message was to indicate that node disjoint
> >1) is covered by the 2 hop case, but 2) is low probability.
>  
> Yes. 100% of node failures can be covered by using 2 hop, but that is only 
> necessary in a small percentage of cases in most topologies, although there 
> are some pathological cases where the percentage may be higher.
>  
>  
> >My point was that the node disjoint problem is a subset of the SRLG
> >problem.  It is a subset because you can define a SRLG to be all links
> >adjacent to a given node and therefore define the node disjoint case
> >as an SRLG case.  The local SRLG problem is also a subset of the SRLG
> >problem.
>  
> Yes.
>  
>  
> >So far only MPLS/TE fully addresses SRLG and it does so very cleanly.
> >
> >If the general SRLG problem is not addressed, the failure to address
> >the problem should at least be acknowledged in the documents.  If SRLG
> >is not a requirement for IP FRR, that should at least be stated in the
> >framework document, but the limitations should also be acknowledged.
>  
> I don't think we have ever said it is not a requirement. So far we have 
> avoided the complication of discussing it until we get some kind of a 
> handle on the simple cases. It has always been the intention to extend the 
> solutions to cover (known) SRLG. As stewart has said, as far as the tunnel 
> method is concerned, the extension to SRLG is relatively straightforward. 
> The computation of F and G space (aka P & Q space) can be trivially 
> extended to excise any sub-trees that traverse any SRLG member. If that 
> finds a solution then we are done. If not it may be necessary to consider 
> "secondary" repairs, and the techniques for doing that are the same as with 
> node repair. This is not surprising, since as you point out node repair is 
> a case of SRLG.
>  
>  
> >Normally it would be sufficient to list something as future work in
> >the framework but that should be done where algorithms are known and
> >only the protocol bits need to be defined later (and if needed).  In
> >this case there is question about whether feasible algorithms exists
> >so the limitation should be acknowledged and not just dismissed.
>  
> Yes I see your point.
>  
>  
> >I personally think that an important requirement for an IP FRR
> >technique is that feasible algorithms for SRLG be known so the product
> >of the WG isn't a dead end.  So far there doesn't seem to be WG
> >concensus either way.
>  
> I would tend to agree. It would be useful to ave some other opinions.
>  
>          Mike


This is a requirements question so it is time for providers who intend
to use IP FRR to speak up.

Curtis



> >Curtis
> >
> >
> > > At 03:09 PM 11/22/2004, Curtis Villamizar wrote:
> > >
> > > >In message <[email protected]>
> > > >mike shand writes:
> > > > >
> > > > > At 12:39 22/11/2004 -0500, Alia Atlas wrote:
> > > > > >What can you get with a single primary repair?
> > > > >
> > > > >
> > > > > Some examples of the percentage of node repairs which require 
> > secondaries
> > > > > below. This is calculated by taking the number of repairs for node 
> > repair
> > > > > which require a secondary repair divided by the total number of 
> > repairs.
> > > > > Where a repair is a repair to a single neighbor's neighbor.
> > > > >
> > > > > e.g.
> > > > >            V
> > > > >            |
> > > > > S---------E----U
> > > > >            |
> > > > >            T
> > > > >
> > > > > The repairs for node E failing would be
> > > > >
> > > > > SV,SU,ST
> > > > > VS,VT,VU
> > > > > etc.
> > > > >
> > > > >
> > > > > 0.79%
> > > > > 13.77%
> > > > > 3.98%
> > > > > 1.47%
> > > > > 0.50%
> > > > > 4.64%
> > > > > 0.00%
> > > > >
> > > > >
> > > > > (Note that the 13% one is a hub and spoke like network which gives 
> > > > > only
> > > > > about 70% coverage for U-turns (link repair; I haven't simulated 
> > U-turns
> > > > > for node repair).  It is quite a nasty topology for any IPFRR 
> > mechanism)
> > > > >
> > > > >
> > > > >          Mike
> > > >
> > > >
> > > >So what you are saying seems to be that covering the node disjoint
> > > >problem is mostly not needed.  I think some providers would dispute
> > > >that (if providers ever did speak up in IETF and if one does please
> > > >disregard my speculation on what providers might say).
> > > >
> > > >Also this does not address SRLG at all which was another part of this
> > > >thread.  Thats why I changed the subject line.  You could further
> > > >split that into node disjoint and SRLG since they are different
> > > >problems (though the node disjoint problem can be considered a proper
> > > >subset of SRLG).
> > > >
> > > >Curtis


_______________________________________________
Rtgwg mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/rtgwg

<Prev in Thread] Current Thread [Next in Thread>