Curtis Villamizar wrote:
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.
How is this achieved? Presumably by excluding from the set of packets
that can be repaired and packet with a label that indicates that it is
part of a repair tunnel.
If we were to always tunnel to the other side of the failure we
could do the same sort of thing in IPFRR, but prefer to sent
the packets native. We could however mark the packet as being
repaired somehow (TOS bit perhaps) and then refuse to re-repair it.
Rtgwg mailing list