Re: [irs-discuss] IRS comments

[Thomas Nadeau <[e-mail]>]

On 8/30/12 8:43 PM, "Alia Atlas" <[e-mail]> wrote:

>On the encap/decap, I certainly view encap as simply a different type
>of next-hop that a route to the RIB can have.  Similarly, one can view
>decap as treating a particular label/prefix - though that may require
>more complexity.

	As well as also recursing to look into another table. For example, l3
vrfs connected to VPLS.

>Negotiation is another area to think about too.  Clearly, there will
>be some capability negotiation needed as part of IRS - as well as the
>ability to query for what capabilities are supported by the routing
>element.

	I would rather do capability advertisement rather than negotiation. That
is, agents should be able to understand what sorts of bits, knobs and
buttons they can fiddle with, but I do not think it is important to have a
full negotiation between the IRS agent and client about the diffs.  Lets
keep things as simple as possible.

	--Tom


>Incidentally, if you are interested in writing down your thoughts
>around different architectures for where parts of the routing system
>might live and how they should/would interact with IRS, I'd encourage
>you to do so and to chat with Dave Meyer, who has agreed to take on
>looking at such pieces.
>
>While I do think that migrating the entire routing system except for
>RIB off of a routing element would be for rather specialized
>environments, I am also concerned that we consider the different
>architectural possibilities when defining IRS so that we don't end up
>going down an insufficient path.
>
>Alia
>
>On Thu, Aug 30, 2012 at 9:16 PM, Edward Crabbe <[e-mail]> wrote:
>> Yep;  not having to run an IGP on the box, which is great for those
>>people
>> not wanting / needing core internet protocols on their devices.  The
>> standard set of 'SDN' talking appoints applies here in terms of
>>development
>> speed, performance improvements resulting from use of modern commodity
>> compute, friendliness of development environment, potential for
>>decreased
>> bug count* etc etc.
>>
>> It's a specialized use case, but it exists.
>>
>> However, my fundamental point is that with IRS as defined currently (ie
>>PBR
>> with extensible match fields on on RIB recursion + additional
>>monitoring and
>> data collection hooks) you can do hypothetically do away with IGPs.
>>Indeed,
>> assuming that the encaps is applied at some other device (since IRS as
>> currently described doesn't account for encap/decap application or
>> negotiation functionality)  you can effectively replace a significant
>>number
>> of protocols (including stateful PCE) should you want to.   :P
>>
>> <can of worms>
>>
>> *The benefits in terms of decreased bug counts above is really varies
>>with
>> how complex we make IRS of course.
>>
>> On Thu, Aug 30, 2012 at 6:01 PM, Dutta, Pranjal K (Pranjal)
>> <[e-mail]> wrote:
>>>
>>> Yep, the context of our original discussion was never PCE as we
>>>understand
>>> its CSPF or some form like that. Our concern was ­ is there a strong
>>>use
>>>
>>> case for non-constrained SPF?
>>>
>>>
>>>
>>> ________________________________
>>>
>>> From: Edward Crabbe [mailto:[e-mail]]
>>> Sent: Thursday, August 30, 2012 5:34 PM
>>>
>>>
>>> To: Dutta, Pranjal K (Pranjal)
>>> Cc: Alia Atlas; UTTARO, JAMES; Shah, Himanshu; [e-mail]
>>> Subject: Re: [irs-discuss] IRS comments
>>>
>>>
>>>
>>> Nope, not specifically, but it strongly implies that there is some
>>>form of
>>> SPF running given the use of constraints in the draft.
>>>
>>> On Thu, Aug 30, 2012 at 4:16 PM, Dutta, Pranjal K (Pranjal)
>>> <[e-mail]> wrote:
>>>
>>> That doesn¹t talk about centralized SPF, does it ?
>>>
>>>
>>>
>>> ________________________________
>>>
>>> From: Edward Crabbe [mailto:[e-mail]]
>>> Sent: Thursday, August 30, 2012 4:12 PM
>>>
>>>
>>> To: Dutta, Pranjal K (Pranjal)
>>> Cc: Alia Atlas; UTTARO, JAMES; Shah, Himanshu; [e-mail]
>>> Subject: Re: [irs-discuss] IRS comments
>>>
>>>
>>>
>>> http://tools.ietf.org/html/draft-ietf-pce-stateful-pce-01
>>>
>>> On Thu, Aug 30, 2012 at 4:09 PM, Dutta, Pranjal K (Pranjal)
>>> <[e-mail]> wrote:
>>>
>>> Œoperational model¹ = IETF draft that describes the use case.
>>>
>>> Œlarge¹ = 40K LSAs, 500 IGP nodes.
>>>
>>>
>>>
>>> ________________________________
>>>
>>> From: Edward Crabbe [mailto:[e-mail]]
>>> Sent: Thursday, August 30, 2012 2:44 PM
>>>
>>>
>>> To: Dutta, Pranjal K (Pranjal)
>>>
>>> Cc: Alia Atlas; UTTARO, JAMES; Shah, Himanshu; [e-mail]
>>>
>>>
>>> Subject: Re: [irs-discuss] IRS comments
>>>
>>>
>>>
>>> please define 'operational model' ( and 'large' :) .
>>>
>>> On Thu, Aug 30, 2012 at 1:40 PM, Dutta, Pranjal K (Pranjal)
>>> <[e-mail]> wrote:
>>>
>>> Hi,
>>>
>>>          I believe that¹s 10% of what overall work that router does
>>>today
>>> w.r.t routing. I would like to see an operational model how such
>>>centralized
>>> SPF can
>>>
>>> provide end-to-end convergence of large number of flows efficiently.
>>>
>>>
>>>
>>> Thanks,
>>>
>>> Pranjal
>>>
>>>
>>>
>>> ________________________________
>>>
>>> From: Edward Crabbe [mailto:[e-mail]]
>>> Sent: Thursday, August 30, 2012 11:59 AM
>>> To: Alia Atlas
>>> Cc: Dutta, Pranjal K (Pranjal); UTTARO, JAMES; Shah, Himanshu;
>>> [e-mail]
>>>
>>>
>>> Subject: Re: [irs-discuss] IRS comments
>>>
>>>
>>>
>>> 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
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>
>>
>_______________________________________________
>irs-discuss mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/irs-discuss