[email protected]
[Top] [All Lists]

Consolidated threads on node disjoint and SRLG

Subject: Consolidated threads on node disjoint and SRLG
From: Curtis Villamizar
Date: Fri, 26 Nov 2004 22:53:23 -0500
In-reply-to: Your message of "Thu, 25 Nov 2004 00:57:56 EST."
             <[email protected]> 

In message <[email protected]>
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 protected]> 

In message <[email protected]>
Stewart Bryant writes:
>  
>  
> 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.

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 protected]> 

In message <[email protected]>
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 protected]> 

In message <[email protected]>
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 protected]> 

In message <[email protected]>
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 protected]
https://www1.ietf.org/mailman/listinfo/rtgwg

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