Re: [irs-discuss] IRS comments

Thomas Nadeau <tnadeau@juniper.net> Fri, 31 August 2012 22:58 UTC

Return-Path: <tnadeau@juniper.net>
X-Original-To: irs-discuss@ietfa.amsl.com
Delivered-To: irs-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3116921F8517 for <irs-discuss@ietfa.amsl.com>; Fri, 31 Aug 2012 15:58:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.406
X-Spam-Level:
X-Spam-Status: No, score=-6.406 tagged_above=-999 required=5 tests=[AWL=0.193, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jjki21qRhtzq for <irs-discuss@ietfa.amsl.com>; Fri, 31 Aug 2012 15:58:47 -0700 (PDT)
Received: from exprod7og117.obsmtp.com (exprod7og117.obsmtp.com [64.18.2.6]) by ietfa.amsl.com (Postfix) with ESMTP id 16B7721F8505 for <irs-discuss@ietf.org>; Fri, 31 Aug 2012 15:58:47 -0700 (PDT)
Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob117.postini.com ([64.18.6.12]) with SMTP ID DSNKUEFBoJ5gi6gbklnWGdPXc61DxaA6ez8F@postini.com; Fri, 31 Aug 2012 15:58:47 PDT
Received: from P-CLDFE02-HQ.jnpr.net (172.24.192.60) by P-EMHUB03-HQ.jnpr.net (172.24.192.37) with Microsoft SMTP Server (TLS) id 8.3.213.0; Fri, 31 Aug 2012 15:57:03 -0700
Received: from p-emfe02-wf.jnpr.net (172.28.145.25) by p-cldfe02-hq.jnpr.net (172.24.192.60) with Microsoft SMTP Server (TLS) id 14.1.355.2; Fri, 31 Aug 2012 15:57:00 -0700
Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe02-wf.jnpr.net ([fe80::c126:c633:d2dc:8090%11]) with mapi; Fri, 31 Aug 2012 18:56:59 -0400
From: Thomas Nadeau <tnadeau@juniper.net>
To: Alia Atlas <akatlas@gmail.com>, Edward Crabbe <edc@google.com>
Date: Fri, 31 Aug 2012 18:56:58 -0400
Thread-Topic: [irs-discuss] IRS comments
Thread-Index: Ac2Hy+zGjsFF516pSKeW2E2ZQafJ5g==
Message-ID: <CC666CFE.5A3C%tnadeau@juniper.net>
In-Reply-To: <CAG4d1rfXG5DeRkf=Fw6W0pXLdec5yX5sE8Pq0QMY+0OWUv0R_g@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.2.3.120616
acceptlanguage: en-US
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: David Meyer <dmm@1-4-5.net>, "UTTARO, JAMES" <ju1738@att.com>, "Dutta, Pranjal K \(Pranjal\)" <pranjal.dutta@alcatel-lucent.com>, "Shah, Himanshu" <hshah@ciena.com>, "irs-discuss@ietf.org" <irs-discuss@ietf.org>
Subject: Re: [irs-discuss] IRS comments
X-BeenThere: irs-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Interface to The Internet Routing System \(IRS\)" <irs-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/irs-discuss>, <mailto:irs-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/irs-discuss>
List-Post: <mailto:irs-discuss@ietf.org>
List-Help: <mailto:irs-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/irs-discuss>, <mailto:irs-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 31 Aug 2012 22:58:48 -0000

On 8/30/12 8:43 PM, "Alia Atlas" <akatlas@gmail.com> 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 <edc@google.com> 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)
>> <pranjal.dutta@alcatel-lucent.com> 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:edc@google.com]
>>> Sent: Thursday, August 30, 2012 5:34 PM
>>>
>>>
>>> To: Dutta, Pranjal K (Pranjal)
>>> Cc: Alia Atlas; UTTARO, JAMES; Shah, Himanshu; irs-discuss@ietf.org
>>> 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)
>>> <pranjal.dutta@alcatel-lucent.com> wrote:
>>>
>>> That doesn¹t talk about centralized SPF, does it ?
>>>
>>>
>>>
>>> ________________________________
>>>
>>> From: Edward Crabbe [mailto:edc@google.com]
>>> Sent: Thursday, August 30, 2012 4:12 PM
>>>
>>>
>>> To: Dutta, Pranjal K (Pranjal)
>>> Cc: Alia Atlas; UTTARO, JAMES; Shah, Himanshu; irs-discuss@ietf.org
>>> 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)
>>> <pranjal.dutta@alcatel-lucent.com> wrote:
>>>
>>> Œoperational model¹ = IETF draft that describes the use case.
>>>
>>> Œlarge¹ = 40K LSAs, 500 IGP nodes.
>>>
>>>
>>>
>>> ________________________________
>>>
>>> From: Edward Crabbe [mailto:edc@google.com]
>>> Sent: Thursday, August 30, 2012 2:44 PM
>>>
>>>
>>> To: Dutta, Pranjal K (Pranjal)
>>>
>>> Cc: Alia Atlas; UTTARO, JAMES; Shah, Himanshu; irs-discuss@ietf.org
>>>
>>>
>>> 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)
>>> <pranjal.dutta@alcatel-lucent.com> 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:edc@google.com]
>>> Sent: Thursday, August 30, 2012 11:59 AM
>>> To: Alia Atlas
>>> Cc: Dutta, Pranjal K (Pranjal); UTTARO, JAMES; Shah, Himanshu;
>>> irs-discuss@ietf.org
>>>
>>>
>>> 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 <akatlas@gmail.com> 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)
>>> <pranjal.dutta@alcatel-lucent.com> 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
>>> irs-discuss@ietf.org
>>> https://www.ietf.org/mailman/listinfo/irs-discuss
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>
>>
>_______________________________________________
>irs-discuss mailing list
>irs-discuss@ietf.org
>https://www.ietf.org/mailman/listinfo/irs-discuss