[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 13:48:12 -0500
In message <[email protected]>
mike shand writes:
> At 11:03 23/11/2004 -0500, Alia Atlas wrote:
> >Mke,
> >At 05:08 AM 11/23/2004, mike shand wrote:
> >>>One issue that I see for the non-source-routed tunnel based approach is 
> >>>that it uses the original next-next-hop as a proxy for a set of 
> >>>destinations.  It is possible that the path from the next-next-hop to a 
> >>>particular destination will not be available because it traverses a link 
> >>>in the same SRLG.
> >>>
> >>>I think that this may make the destination assignment a bit trickier.
> >>
> >>Well, by analogy with the node failure case, one way to deal with this is 
> >>to consider a separate repair to the far side of each SRLG. I'm not sure 
> >>it is always necessary, but I think it is sufficeient.
> >
> >But what is the far side of the SRLG?
> When you run a normal SPF rooted at S, as you traverse each SRLG you will 
> find which is the far side.
> >Trimming the trees after they're computed makes some sense, but then it a 
> >next-next-hop is dependent on the same SRLG to reach a destination, that 
> >destination won't be given an alternate (where there might be one without 
> >the proxying).
> It certainly true that proxying reduces your options. Even in the non-SRLG 
> case it is true that if it were the case that a repair was impossible to a 
> proxy it may still be possible for all destinations except that proxy. 
> However, our view is that if the failure is not 100% repairable then it is 
> irreparable, so rather than giving some destinations poorer service it 
> would probably be better not to attempt repair at all for that link. Not 
> that we have seen any such irreparable links in real networks, but that is 
> the principle behind the proxying.
> In the case of SRLG, this might translate to a case where it was necessary 
> to use secondary repairs because a few destinations could not otherwise be 
> repaired. What this would mean is that we might use a secondary repair for 
> some destinations which (if we had done the whole calculation per 
> destination) could ave been repaired via a single primary repair. This is 
> also true of node failures (which are of course SRLGs in disguse).
> Mike
> >Alia


I don't understand the algorithm(s?) that you two are discussing.

In MPLS/TE you simply remove all links from the topology that share a
common SRLG or for some types of SRLG don't remove the links but
weight those links to encourage avoiding them.  Then run the CSPF.

An interesting problem with IP FRR and SRLG is that an SRLG means that
the links *might* go down concurrently.  It does not indicate that the
links *will* go down concurrently.  If two links share a common
resource they will go down simulaneously if failure of that resource
is the cause of the outage.  If you use the above approach and the
failure is due to some other cause, normal hop by hop forwarding could
cause a loop.

MPLS/TE FRR does not suffer from this problem because tunnels are used
in the backup that terminate at the egress where the path is dictated
by the ingress or the PLR (point of local repair).  Therefore MPLS/TE
FRR can select a path which avoids all links that could potentially
fail without being concerned that a routing loop could form due to an
inconsistent decision.

Alia has addressed the problem of local SRLG and has provided a clear
enough description of how that works.  There is some question whether
the more general SRLG problem can be adequately addressed because of
the above problem.

The algorithm description above doesn't seem complete and therefore
doesn't make sense to me but that might be becuase the description was
sketchy or it might be just because I'm being dense.

For example:

      . . . . X
     .        .
    a --- b   .
    |      \ .
    |       e
    |      /
    c --- d

A is trying to get to e and looking to protect against failure of a-b
but a-b and d-e share a common fiber (a, c, d may be near each other
geographicly and b, e may be near each other).  A needs to use a long
path via X.  I don't see how this "far side of the SRLG" idea fits
into an algorithm that solves this problem.  Note that U-turn doesn't
address this since d-e is not local to A.  The SRLG could also be a-b
and c-d in a slightly different example.

The physical fiber involved in the SRLGs may look more like this
(where the = are two lambdas on the same segment of fiber).

      ..X1..X2..Xn-1..      ..Xn..
     /                \    /     .
    a ----=========----====---b  Xn+1
     \   /         \           \ .
       c             --- d ----- e 

Even more interesting is the case were a-b shares one SRLG with a..x
and a-b shares another SRLG with a-c.  In MPLS TE, the primary path
can be changed to a-c-d-e so that the backup path a..x..e could be
used and the primary and backup paths did not share any SRLG.  This is
generally done only with primary and standby (backup from ingress to
egress) or ingress as a PLR in FRR since the ingress and not
the PLR determines the primary path.  It would be difficult for the
ingress to select a primary path that assures that a feasible backup
is available at any PLR.

For example:

        . . . . X
       .        .
    - a --- b   .
  /   |      \ .
 z    |       e
  \   |      /
    - c --- d

If Z is now the ingress, Z is unlikely to consider whether A has a
viable repair path when selecting the path to E.  Z would likely pick
the path z-a-b-e if the path z-c-d-e was a viable packup for failure
of z-a and then A would have no way to create a viable backup.  A
better example of this is where one SRLG is a-b and a.x and another
SRLG is a-b and a-c and the third is a-b and z-a.  The path z-a-b-e
and z-c-d-e are fully disjoint but A has no backup path.  OTOH if A
picked a primary path of z-c-d-e, Z, C and D all have viable backups
when acting as the PLR.

Note: I'm using . to mean multiple hops and - to mean one hop, but it
only matters in the a.x.e case since there I just want to indicate
higher cost.


Rtgwg mailing list
[email protected]

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