[email protected]
[Top] [All Lists]

Re: questions on draft-bryant-ipfrr-tunnels-01.txt

Subject: Re: questions on draft-bryant-ipfrr-tunnels-01.txt
From: Curtis Villamizar
Date: Mon, 22 Nov 2004 14:52:45 -0500
In message <[email protected]>
Alia Atlas writes:
> At 10:16 AM 11/19/2004, Curtis Villamizar 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.
> This is true, but only for the length of the TE tunnel.  TE gets this 
> benefit only because it is an overlay approach; the issue occurs where ever 
> the overlay ends.  If one is doing 1 or 2-hop tunnels, then looping is also 
> possible.

There is still no possibility of routing loops in multiarea TE.

Actually it is a benefit of source specified forwarding.  So something
like NIMROD would have the same benefit even though it is
significantly different from MPLS RSVP/TE.  NIMROD is not an overlay.

> >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.
> Part of the question is how often do uncorrelated failures happen as 
> compared to single failures (which could also be a known SRLG)?  If 
> uncorrelated failures are relatively rare in comparison, then the trade-off 
> of saving the traffic via an IPFRR alternate for the single failures in 
> exchange for potentially looping saved traffic for an uncorrelated failure 
> seems reasonable to me.

Again - terminology.  Uncorrelated failures would be ones that don't
happen at the sake time.  I still got what you said.

Yes the tradeoff is probably worth it.  The point that I was trying to
make is you *can't* loop with MPLS/TE and you *can* loop with IP even
without IP FRR.  Looping is really bad since you affect other triaffic
if you congest links going around long enough for TTL to expire.

> >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.
> I also think that SRLGs are important.  We do need to have the basic 
> mechanisms understood before trying to add the additional complexity of 
> SRLG handling.  I certainly think that the ability to handle SRLGs is an 
> important criterion in considering different approaches.
> Alia

Its nice to be in agreement.  A real good question for providers
though is given the widespread use of TDM or switched services in low
speed, and WDM in high speed networking, is IPFRR useful without SRLG.


Rtgwg mailing list
[email protected]

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