Subject: Consolidated threads on node disjoint and SRLG

From: Curtis Villamizar <[email-masked]>
Date: Fri, 26 Nov 2004 22:53:23 -0500

In-reply-to: Your message of "Thu, 25 Nov 2004 00:57:56 EST."
             <[email-masked]> 

In message <[email-masked]>
Alia Atlas writes:
>  
> At 03:17 AM 11/24/2004, mike shand wrote:
> >But this does raise an interesting question. So far we (well at least I) 
> >have been thinking of SRLG in terms of a set of links failing. But we know 
> >already that we need to consider node failure as an SRLG consisting of all 
> >the links from a neighboring node, so if we see the link to our neighbor 
> >go down we must assume that the node itself has gone down. So does this 
> >mean that if we have a neighbor E, and SE is an SRLG with links XY and ST, 
> >the ACTUAL SRLG we have to consider is node E failure and links ST and XY 
> >failure?
>  
> I think that the ideal is to have an alternate that provides link, node and 
> SRLG protection.  Each protection set is a different check.  If such an 
> alternate doesn't exist, then it's just a question of prioritization.  We 
> have the same problem between link and node protection.
>  
> Alia

At least on MPLS FRR implementation provides a cost assigned per SRLG
and something called a bias which is another number space.  A non-zero
bias in the path means that the backup is considered inadequate (the
local-protect-available bit is not set).  Setting costs on the SRLGs
allows the operator to specify which SRLG are most in need of
avoiding, where node-disjoint may be specified as an SRLG, therefore
giving among ranking SRLG to the probability that the node goes down.

Being able to support the same in IP FRR might be nice.

Curtis

============================================================

In-reply-to: Your message of "Fri, 26 Nov 2004 11:44:01 GMT."
             <[email-masked]> 

In message <[email-masked]>
Stewart Bryant writes:
>  
>  
> Curtis Villamizar wrote:
>  
> > In message <[email-masked]>
> > 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.

The MPLS RSVP/TE tunnel is a source specified path from ingress to
egress.  The backup from any given PLR is a PLR specified path from
ingress to egress that happens to merge with the primary as close as
it is safe and efficient to do so.  If the PLR is put into action and
a link along the backup path fails, the traffic by definition goes
into the bit bucket until the ingress determines a new path and
reroutes the primary.  No loop on unknown SRLG.

Typically there is also a holddown on the primary tunnel so that
traffic is forced into the tunnel even though it is known/thought to
be down.  If the old primary repairs its forwarding (SONET repair,
whatever, PFM?) before the reroute completes, then traffic won't
blackhole but the primary will continue the reroute.  This prevents
immediately falling back to IP and sending traffic into an IP loop.

> 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.
>  
> - Stewart

That would only work if you tunnel always went all the way to the exit
point for the IGP which would mean that you couldn't use IP
forwarding.  At that point you might as well use MPLS FRR.

Curtis

============================================================

In-reply-to: Your message of "Fri, 26 Nov 2004 11:35:53 EST."
             <[email-masked]> 

In message <[email-masked]>
Alia Atlas writes:
>  
> At 06:44 AM 11/26/2004, Stewart Bryant wrote:
> >>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.
>  
> I think that if the point where a repaired packet re-joins the SPT is 
> always a downstream path, then we could have the same 
> property.  Unfortunately that does limit coverage a bit.
>  
> Alia

You seem to be missing the point.  If there is an unknown SRLG the hop
that you thought was downstream isn't really downstream anymore.  That
is the basis for loop formation with unknown SRLG.

Curtis

============================================================

In-reply-to: Your message of "Fri, 26 Nov 2004 17:30:08 GMT."
             <[email-masked]> 

In message <[email-masked]>
Stewart Bryant writes:
>  
>  
>  
> Alia Atlas wrote:
>  
> > At 06:44 AM 11/26/2004, Stewart Bryant wrote:
> > 
> >>> 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.
> > 
> > 
> > I think that if the point where a repaired packet re-joins the SPT is 
> > always a downstream path, then we could have the same property.  
> > Unfortunately that does limit coverage a bit.
> > 
>  
> The assertion was that MPLS RSVP/TE FRR is unconditionally LF against
> unexpeceted SRLG.
>  
> +---------------------------------+
> |                                 |
> A-----B--------C---------E--------F
>                 |
>                 D
>  
> AB breaks and unexpectedly FE breaks. What stops the loop?
>  
> Stewart

I'm assuming that traffic is from A to D?

Anyway, if the backup was A-F-E-C-D, then there is an MPLS label on F
that points to interface E.  That label is different from the label
for the tunnel the originates at F and has the path F-E-C-D, and the
label for A-F-E-C-D has no backup.  It blackholes traffic rather than
loop.  MPLS does not rip off the MPLS encapsulation and try to forward
the packet via IP when a failure occurs midway across a tunnel and put
it into another tunnel in doing so.

MPLS/TE does not do destination based forwarding of labeled packets,
therefore if both the primary and the backup path breaks traffic
blackholes rather than loops.

Curtis

============================================================

In-reply-to: Your message of "Fri, 26 Nov 2004 17:54:10 GMT."
             <[email-masked]> 

In message <[email-masked]>
Stewart Bryant writes:
>  
>  
> >> That is a desire, although I have some personal doubts at the validity 
> >> of that constraint. Remember that when we designed link state
> >> protocols we were using CPUs that were three orders of magnitude 
> >> slower than those that we use today.
> > 
> > 
> > Which means we can do a handful of SPFs, not 100s or 1000s.
>  
> Sorry I don't follow. When LS protocols were introduced (say 1990)
> we had processors that could do 1 mip doing everything. As I recall
> speed doubles every 18mths, which I think is 2^(14*2/3) which is
> over 500. So why can't we run order 500 SPFs? Where did all the 
> performance go?
>  
> Stewart

Stewart,

What certain providers called the "Macintosh based routers" (68030
based, not really a Mac) started to fall apart at a few hundred nodes.

Processors in those days were in the 30-100 MHz range.  Today that are
a few GHz so at best 100 times faster but DRAM clock rates have not
gone up at the same rate (not even a factor of 10) and that is the
limiting factor for all but problems with good memory localization
that fit into a small amount of memory (into the on-chip or SRAM
cache).  If anything better code has given us more than faster CPU
(those old Mac routers had some pretty awful code from what I could
tell).

SPFs in the 1000 node range (just going from 100 to 1000 nodes
requires almost 15 times more processor power - CPF is NlogN at best)
seem to be running in the 50 msec range so 100s of them following an
IGP change wouldn't seem to be a very good idea (5 sec solid CPU time
for 100, which btw has to be shared with such things as BGP) and 1000s
seems like a real bad idea.

Curtis

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

---

From: Alia Atlas <[email-masked]>
Date: Sun, 28 Nov 2004 13:42:50 -0500

>Being able to support the same in IP FRR might be nice.

The mechanisms would need to be different.  There are 2 parts to the 
problem - the first part is controllable (to some extent) like TE FRR and 
the second part isn't, b/c it is just the SPT.

One can track the SRLGs and neighbors visited and make decisions based upon 
that.  Those decisions could be made based on weighting of the SRLGs.

It's not clear to me that it is necessary to go to this level of 
complication.  It also makes it difficult for any distributed decisions 
where X needs to be able to determine what Y picked as an alternate or 
whether Y picked anything.

>is the basis for loop formation with unknown SRLG.

Curtis, think about this as a 2 stage problem.  The first stage is do the 
alternates cause a loop.  The second stage is does the convergence to the 
new topology cause a loop.  We are working on mechanisms to handle the 
second; for instance the path-locking with safe neighbors doesn't care 
about whether the set of failures were expected.

For the first stage of do the alternates cause a loop, that can be handled 
by requiring that the alternate rejoin the SPT at a point downstream of 
where it left.   This is very similar to TE FRR, where the backup rejoins 
the primary always downstream of the failure.

Alia