[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: mike shand
Date: Tue, 23 Nov 2004 10:01:40 +0000
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.


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



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>