In message <[email protected]>
Stewart Bryant writes:
> OK, we will describe how to handle SRLG in the next version.
> However unknown SRLGs will affect all solutions, so if
> SRLG is a MUST, then all solutions need text describing
> their behavior under conditions of unknown SRLG. In
> particular unknown SRLG can result in mutually looping
> repairs (which could even be cyclic) and the solution
> must describe how to detect and break these loops.
MPLS RSVP/TE FRR is loop free in the presense of unknown SRLG. At
worst the fast restoration fails and a new LSP is needed from ingress
to egress. So the worst case is a slow restoration but not a loop.
If you meant all IP FRR can be subject to transient looping due to
unknown SRLG, then you are correct. That is a consequence of
hop-by-hop forwarding. IP itself is subject to transient looping due
to correlated failures even without IP FRR. We seemed to have lived
with it so far.
With the greater empahsis on reliability and fast restoration of
service in todays commercial backbones, providers need to be vigilant
in maintaining their SRLG database. Its easy to swap circuits and not
update the database, etc. I've seen two carriers handle this, one
very well and one not very well. Many providers who have leased
"disjoint circuits" from a carrier whether internally or external
lease (and paid a premium for that) have had them both go down due to
failure of a common resource that the carrier failed to consider or
had the circuits swapped in a maintenance or circuit grooming such
that they were no longer disjoint. This is less a problem the higher
up you go on the food chain because the SRLG database is more
Providers that don't care about fast restoration need not keep an up
to date SRLG database, or keep one at all. If so, they are kidding
themselves if the run any form of FRR. Just my opinion.
I don't know that the WG has decided that SRLG is a MUST. It should
be obvious from what I've written that I think its important.
> Curtis Villamizar wrote:
> > In message <[email protected]>
> > Stewart Bryant writes:
> >>We also have concerns about the relative frequency of known SRLGs
> >>members vs unknown SRLG members. Clearly if the proportion of
> >>unknown SRLG members is significant, then the usefulness of SRLG
> >>aware repairs is questionable. We decided that we really needed
> >>some answer to this question before pursuing this additional
> >>complication to the solution.
> > If unknown SRLG is a problem and not supporting SRLG makes all SRLG
> > behave like unknown SRLG, then an approach which does not support SRLG
> > is more problematic than an approach which does support SRLG. The
> > only case where the two are equal (approaches that do and don't
> > support SRLG) is where SRLG do not exist which we know is not the case
> > in any real network.
> > Therefore I think any argument opposing the support of SRLG due to the
> > possibility (or certainty) that unknown SRLG will exist is quite flawed.
> > For example, WDM introduces SRLG that have to be considered for a fast
> > restoration approach to be at all viable. Logical links that traverse
> > hundreds of miles on the same fiber are going to have a high
> > percentage of correlated failure.
> > Curtis
> > ps - we not return you to our regularly scheduled arguments about why
> > SRLG are a hard problem for some approaches.
> If tunnels were to perform a per prefix search for a two hop
> solution the results would be identical to that of U-turn.
> Therefore tunnels are a true superset of the U-turn approach.
> For simplicity we did not describe this per-prefix search,
> because we achieved complete coverage without it in all the
> networks we examined.
> However give that tunnels are a superset of U-turns, then
> any SRLG issue applies equally to both.
> - Stewart
Could you please explain how a two hop per prefix search addresses
SRLG and perhaps address the time complexity of the algorithm. It is
not at all clear what sort of algorithm you have in mind from the
description above. I'm assuming that this was supposed to be just a
quick explanation and you are not suggesting that this would be an
adequate entry in the draft to address SRLG.
Rtgwg mailing list