Re: [irs-discuss] IRS comments

[Edward Crabbe <[e-mail]>]

W/r/t liveness monitoring, neighbor discovery etc: yep, of course.   ^_^
As someone who runs centralized te, I can tell you that in some
environments / for some deployment types centralized spf works just fine.


On Thu, Aug 30, 2012 at 12:10 PM, Alia Atlas <[e-mail]> wrote:

> Ed,
>
> Sure - it provides the ability for centralized route computation -
> whether SPF or other.
> But that isn't all an IGP does - and the topological information may
> still rely on link-state information from an IGP.   It also doesn't
> address convergence concerns.
>
> I think there is more to be considered than just whether a central box
> can run an SPF and install the associated routes.
>
> Alia
>
>
> On Thu, Aug 30, 2012 at 2:58 PM, Edward Crabbe <[e-mail]> wrote:
> > Alia;
> >
> > If there is
> >
> > a) a mechanism for installing routes, pbr or otherwise, which recurse to
> > directly connected nexthops
> > b) a mechanism for gathering topological information
> >
> > then you've inherently enabled centralized spf.
> >
> > On Thu, Aug 16, 2012 at 9:34 AM, Alia Atlas <[e-mail]> wrote:
> >>
> >> I haven't seen a good description of what is intended or desired by
> >> moving the SPF functionality to a centralized location.  Clearly such
> >> centralization can have a very bad impact on convergence - which is a
> >> strong motivator for simultaneously computing fast-reroute
> >> alternatives (with guaranteed coverage ala MRT) and installing both.
> >>
> >> I don't see IRS as having a way of "turning off" the SPF computation
> >> in the IGP; a different lobotomized IGP protocol/process would be
> >> needed.
> >>
> >> Alia
> >>
> >> On Thu, Aug 16, 2012 at 12:14 PM, Dutta, Pranjal K (Pranjal)
> >> <[e-mail]> wrote:
> >> > "LSDB (I saw an email which talks about reducing IGP to link
> >> >> distribution protocol and running SPF in centralized network
> >> >> controller)"
> >> >
> >> > I have seen discussions in the past on this and in fact I didn't get
> >> > precisely what is meant. If anybody in the list could brief very
> >> > precisely that would help a lot.
> >> >
> >> > Here is my understanding - the routers would do LSA/LSP flooding for
> >> > OSPF/ISIS as it is done today. So routers would build neighboring
> >> > relationship/adjacencies to participate in flooding and each router
> builds
> >> > its LSDB.
> >> >
> >> > Then the IRS "application" would track LSDB changes and pull up the
> >> > "diffs" from each router (thru "controller") whenever there is a
> change. The
> >> > application would compute SPF on behalf of each router (LSDB). The
> result of
> >> > the compute would be pushed by application to each Router (thru
> controller)
> >> > and inject entries into RIB.
> >> >
> >> > Is that correct? How different this going to be from PCE?
> >> >
> >> > If this is correct then perhaps we would like to ask what are the
> >> > scalability numbers in LSDB we are talking about?
> >> >
> >> > The "application" would be running in a high performance server and so
> >> > SPF compute there is not an issue and perhaps it is good way to
> synchronize
> >> > FIB update (to a certain extent) to avoid u-loops etc.
> >> >
> >> > But when we are managing all routers in the purview of the
> application,
> >> > the computing power in each router is not uniform. To be realistic, I
> have
> >> > some concerns on how much "real-timeness" we could achieve between
> >> > application and controllers on such proposals, esp. when scaling
> numbers are
> >> > high. This leads to higher time lag on inconsistency between
> application SPF
> >> > compute and FIB update. It's almost like the classic "slow peering"
> issues
> >> > with TCP like protocols - the high performance peer is slowed down by
> low
> >> > performance peer.
> >> >
> >> > Static route interface is good thing because it is a state that
> persists
> >> > longer.
> >> >
> >> > IGPs may be deployed in very dynamic environments where tight coupling
> >> > is desirable between SPF compute and FIB update. In scaled
> environments the
> >> > issue is less about SPF compute time and is more about synchronizing
> the
> >> > FIB.
> >> >
> >> > Running on-demand CSPF by IRS application may be fine because of
> >> > persistency of RSVP-TE tunnels in dynamic environments.
> >> >
> >> > I apologize if I misunderstood the intent.
> >> >
> >> > Thanks,
> >> > Pranjal
> >>
> >> ---snip---
> >> _______________________________________________
> >> irs-discuss mailing list
> >> [e-mail]
> >> https://www.ietf.org/mailman/listinfo/irs-discuss
> >
> >
>