Re: [irs-discuss] IRS comments

[Alia Atlas <[e-mail]>]

Not surprised to hear that :-)

The question for IRS is both what is needed to support different
models/architectures for the routing system where parts may be
centralized - and will the data-models to be defined work for those
centralized parts as well.

Alia

On Thu, Aug 30, 2012 at 3:32 PM, Edward Crabbe <[e-mail]> wrote:
> 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
>> >
>> >
>
>