[email protected]
[Top] [All Lists]

Re: composite link - candidate for respin, maybe

Subject: Re: composite link - candidate for respin, maybe
From: Curtis Villamizar
Date: Thu, 01 Apr 2010 01:13:20 -0400
In message <C7D6F49C.9249%[email protected]>
Tony Li writes:
>  
>  
> Hi Curtis,
>  
> > Its not just about whether it fits into the available set of LSPDU.
> > Every time a new LSP is signaled reservable bandwidth changes and it
> > could potentially mean another advertisedment of a bloated LSPDU
> > fragment (or a much smaller but still bloated opaque LSA).
>  
> ? 1200 bytes is hardly bloated.  And I think we've established that the
> frequency of churn is more important than the size.
>  
> And we've have the issue about LSPDU updates since we started the TE work.
> I believe that we've demonstrated that it can be successfully resolved
> without causing undue hardship.


If there is a lot of churn, a lot of information is sent rather than a
summarization then there is a lot of processing.  The less individual
entities to manange in the TE-LSDB the better.


> > This can be a big problem after a fault has occurred, particularly a
> > fault involving more than one SRLG where protection also failed.
>  
> Not sure I see this as a "big problem".  Yes, there will be a spike in
> processing, but we get that anytime there's a topological change.  Doesn't
> seem like an insurmountable issue.


I'd have to say that if you don't see a big problem you are just
oblivious to the problem.

There have been numerous presentations in NANOG on order of LSA/LSPDU
processing, fixed origination holdoffs vs variable origination
holdoffs vs immendiate origination, readvertise before SPF, SPC
holdoffs, CSPF timer reductions, incremental SPF and CSPF, CSPF
results caching, achieving real-world sub-second IGP convergence,
achieving faster real world reroute times (for mutliple fault
situations when protection also fails), etc.  These presentation have
come from both vendors and providers with providers mostly reiterating
requirements or reporting on experiences.

A lot happens when a multiple fault occurs.  Some alternate paths fill
and the feedback doesn't reach some ingress before they initiate
signaling attempting to use the no longer available resource.  The
feedback is important but never instantaneous and there is a tradeoff
between advertising every small change and loading CPUs and getting
infornation out fast.

If this doesn't all go smoothly and convergence is over the SLA
threshhold then it is clearly a big deal and it carries a big
financial penalty.


> Tony

Curtis
_______________________________________________
rtgwg mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/rtgwg

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