Return-Path: 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 ; 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 ; 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 ; 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 To: Alia Atlas , Edward Crabbe Date: Fri, 31 Aug 2012 18:56:58 -0400 Thread-Topic: [irs-discuss] IRS comments Thread-Index: Ac2Hy+zGjsFF516pSKeW2E2ZQafJ5g== Message-ID: In-Reply-To: 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 , "UTTARO, JAMES" , "Dutta, Pranjal K \(Pranjal\)" , "Shah, Himanshu" , "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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Aug 2012 22:58:48 -0000 On 8/30/12 8:43 PM, "Alia Atlas" 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 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 >> >> >> >> *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) >> wrote: >>> >>> Yep, the context of our original discussion was never PCE as we >>>understand >>> its CSPF or some form like that. Our concern was =AD 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) >>> wrote: >>> >>> That doesn=B9t 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) >>> wrote: >>> >>> =8Coperational model=B9 =3D IETF draft that describes the use case. >>> >>> =8Clarge=B9 =3D 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) >>> wrote: >>> >>> Hi, >>> >>> I believe that=B9s 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 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) >>> 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 Return-Path: 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 84B9611E80EA for ; Thu, 30 Aug 2012 20:43:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.458 X-Spam-Level: X-Spam-Status: No, score=-3.458 tagged_above=-999 required=5 tests=[AWL=0.141, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 ACs36CaLBTz7 for ; Thu, 30 Aug 2012 20:43:22 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id D0E0411E80DE for ; Thu, 30 Aug 2012 20:43:21 -0700 (PDT) Received: by iabz21 with SMTP id z21so4876389iab.31 for ; Thu, 30 Aug 2012 20:43:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=2+NYi3OBVfu1F+9OXAB9p5KtKQVOKwcqwsl0rNlE3d0=; b=LvKwxIL9z4mDimp37LQHMQvygM/JX6kp0cdVpwDujdsbtVrJS6I5Lde17BfrYQ2dcF 1GLnnyr0vyGIfRf/SOS43aWZatUA2OF34ed4g50ofuPKO2MlNJueBZYT34HUbt2FVX5Z OYyKtAcKZZ07PPKImfQ+xt/NH3AlRwpu0I9RczL8hTsTSE/TB0QzY5A9hli699gYm4YF rX82VZPz+JcWzainqgo+T3ujYhpuOw+X7sljQe7PY3wBjuHmPgBnm2N/ze0SIbrxZhYJ KD4ba94VGNHPlcunqJkxfI1YoSItBS7wtw6lNOg0DPpEOx0DZ1MO96jk2zlVao7rc1Yl wmxg== MIME-Version: 1.0 Received: by 10.50.36.195 with SMTP id s3mr629367igj.63.1346384601091; Thu, 30 Aug 2012 20:43:21 -0700 (PDT) Received: by 10.50.91.135 with HTTP; Thu, 30 Aug 2012 20:43:21 -0700 (PDT) In-Reply-To: References: Date: Thu, 30 Aug 2012 23:43:21 -0400 Message-ID: From: Alia Atlas To: Edward Crabbe Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: David Meyer , "UTTARO, JAMES" , "Dutta, Pranjal K \(Pranjal\)" , "Shah, Himanshu" , "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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Aug 2012 03:43:23 -0000 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. 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. 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 wrote: > Yep; not having to run an IGP on the box, which is great for those peopl= e > not wanting / needing core internet protocols on their devices. The > standard set of 'SDN' talking appoints applies here in terms of developme= nt > 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 P= BR > with extensible match fields on on RIB recursion + additional monitoring = and > data collection hooks) you can do hypothetically do away with IGPs. Inde= ed, > 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 num= ber > of protocols (including stateful PCE) should you want to. :P > > > > *The benefits in terms of decreased bug counts above is really varies wit= h > how complex we make IRS of course. > > On Thu, Aug 30, 2012 at 6:01 PM, Dutta, Pranjal K (Pranjal) > wrote: >> >> Yep, the context of our original discussion was never PCE as we understa= nd >> its CSPF or some form like that. Our concern was =96 is there a strong u= se >> >> 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) >> wrote: >> >> That doesn=92t 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) >> wrote: >> >> =91operational model=92 =3D IETF draft that describes the use case. >> >> =91large=92 =3D 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) >> wrote: >> >> Hi, >> >> I believe that=92s 10% of what overall work that router does to= day >> w.r.t routing. I would like to see an operational model how such central= ized >> 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 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) >> 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 bu= ilds >> > its LSDB. >> > >> > Then the IRS "application" would track LSDB changes and pull up the >> > "diffs" from each router (thru "controller") whenever there is a chang= e. The >> > application would compute SPF on behalf of each router (LSDB). The res= ult of >> > the compute would be pushed by application to each Router (thru contro= ller) >> > 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 synchr= onize >> > 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 numbe= rs are >> > high. This leads to higher time lag on inconsistency between applicati= on SPF >> > compute and FIB update. It's almost like the classic "slow peering" is= sues >> > 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 persis= ts >> > longer. >> > >> > IGPs may be deployed in very dynamic environments where tight coupling >> > is desirable between SPF compute and FIB update. In scaled environment= s the >> > issue is less about SPF compute time and is more about synchronizing t= he >> > 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 >> >> >> >> >> >> >> >> > > Return-Path: 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 56C1A11E80DE for ; Thu, 30 Aug 2012 20:03:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.424 X-Spam-Level: X-Spam-Status: No, score=-9.424 tagged_above=-999 required=5 tests=[AWL=1.174, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] 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 DJxhHxTk0YjC for ; Thu, 30 Aug 2012 20:03:40 -0700 (PDT) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by ietfa.amsl.com (Postfix) with ESMTP id 5321F21F8437 for ; Thu, 30 Aug 2012 20:03:40 -0700 (PDT) Received: from inbansmailrelay1.in.alcatel-lucent.com (h135-250-11-31.lucent.com [135.250.11.31]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id q7V33V23014709 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 30 Aug 2012 22:03:34 -0500 (CDT) Received: from INBANSXCHHUB03.in.alcatel-lucent.com (inbansxchhub03.in.alcatel-lucent.com [135.250.12.80]) by inbansmailrelay1.in.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id q7V33Tek032235 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 31 Aug 2012 08:33:29 +0530 Received: from INBANSXCHMBSA3.in.alcatel-lucent.com ([135.250.12.53]) by INBANSXCHHUB03.in.alcatel-lucent.com ([135.250.12.80]) with mapi; Fri, 31 Aug 2012 08:33:29 +0530 From: "Dutta, Pranjal K (Pranjal)" To: Edward Crabbe Date: Fri, 31 Aug 2012 08:33:25 +0530 Thread-Topic: [irs-discuss] IRS comments Thread-Index: Ac2HFlCnCfzbgxASS5aVj7nq08yZ3gADkuDA Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C584046466ED224CA92C1BC3313B963E13F0B8C8B2INBANSXCHMBSA_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 Cc: "irs-discuss@ietf.org" , "UTTARO, JAMES" , "Shah, Himanshu" , Alia Atlas 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Aug 2012 03:03:46 -0000 --_000_C584046466ED224CA92C1BC3313B963E13F0B8C8B2INBANSXCHMBSA_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I can understand about very specialized use cases in closed environments bu= t IMO, too much emphasis has been given on power of central compute but still has to deal with "unfriendly" routers= for FIB convergence and synchronization..on theory, yes there is absolutely no problem for real-time applications :). ________________________________ From: Edward Crabbe [mailto:edc@google.com] Sent: Thursday, August 30, 2012 6:16 PM To: Dutta, Pranjal K (Pranjal) Cc: Alia Atlas; UTTARO, JAMES; Shah, Himanshu; irs-discuss@ietf.org Subject: Re: [irs-discuss] IRS comments 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 standa= rd 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 a= nd data collection hooks) you can do hypothetically do away with IGPs. Ind= eed, assuming that the encaps is applied at some other device (since IRS as= currently described doesn't account for encap/decap application or negotia= tion functionality) you can effectively replace a significant number of pr= otocols (including stateful PCE) should you want to. :P *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) > 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) > 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) > wrote: 'operational model' =3D IETF draft that describes the use case. 'large' =3D 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) > 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 di= rectly 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 > 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) >= 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 prec= isely 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 "diff= s" from each router (thru "controller") whenever there is a change. The app= lication would compute SPF on behalf of each router (LSDB). The result of t= he 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 scalabi= lity numbers in LSDB we are talking about? > > The "application" would be running in a high performance server and so SP= F compute there is not an issue and perhaps it is good way to synchronize F= IB update (to a certain extent) to avoid u-loops etc. > > But when we are managing all routers in the purview of the application, t= he computing power in each router is not uniform. To be realistic, I have s= ome concerns on how much "real-timeness" we could achieve between applicati= on and controllers on such proposals, esp. when scaling numbers are high. T= his leads to higher time lag on inconsistency between application SPF compu= te 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 perfor= mance 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 i= ssue 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 persiste= ncy 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 --_000_C584046466ED224CA92C1BC3313B963E13F0B8C8B2INBANSXCHMBSA_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I can understand about very specialize= d use cases in closed environments but IMO, too much emphasis has been given =

on power of central compute but still = has to deal with “unfriendly” routers for FIB convergence and synch= ronization..on

theory, yes there is absolutely no pro= blem for real-time applications J.

 

From: Edward C= rabbe [mailto:edc@google.com]
Sent: Thursday, August 30, 2= 012 6:16 PM
To: Dutta, Pranjal K (Pranjal)
Cc: Alia Atlas; UTTARO, JAME= S; Shah, Himanshu; ir= s-discuss@ietf.org
Subject: Re: [irs-discuss] I= RS comments

 

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, poten= tial 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 acco= unt for encap/decap application or negotiation functionality)  you can effectively replace a significant number of protocols (including stateful P= CE) should you want to.   :P

 

<can of worms> 

 

*The benefits in terms of decreased bug counts above is really vari= es 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 ther= e a strong use

case for non-constrained SPF?  

 

From: Edward Crabbe [mailto:edc@google.com]
Sent: Thursday, August 30, 2= 012 5:34 PM


To: Dutta, Pranjal K (Pranjal)
Cc: Alia Atlas; UTTARO, JAME= S; Shah, Himanshu; irs-discuss@ietf.org
Subject: Re: [irs-discuss] I= RS comments

 

Nope, no= t specifically, but it strongly implies that there is some form of SPF runnin= g 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, 2= 012 4:12 PM

=
To: Dutta, Pranjal K (Pranjal)
Cc: Alia Atlas; UTTARO, JAME= S; Shah, Himanshu; irs-discuss@ietf.org
Subject: Re: [irs-discuss] I= RS 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’ =3D IETF draft that describes t= he use case.

‘large’ =3D 40K LSAs, 500 IGP nodes.<= o:p>

 

From: Edward Crabbe [mailto:edc@google.com]
Sent: Thursday, August 30, 2= 012 2:44 PM

=
To: Dutta, Pranjal K (Pranjal)

Cc: Alia Atlas; UTTARO, JAMES; Shah, Himanshu; irs-discuss@ietf.= org

=
Subject: Re: [irs-discuss] I= RS comments

 

please d= efine '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 efficie= ntly.

 

Thanks,

Pranjal

 

From: Edward Crabbe [mailto:edc@google.com]
Sent: Thursday, August 30, 2= 012 11:59 AM
To: Alia Atlas
Cc: Dutta, Pranjal K (Pranjal); UTTARO, JAMES; Shah, Himanshu; irs-discuss@ietf.org

=
Subject: Re: [irs-discuss] I= RS comments

 

Alia;

 

If there= is 

 

a) a mec= hanism for installing routes, pbr or otherwise, which recurse to directly connected nexthops

b) a mec= hanism 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<= br> 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 computat= ion
in the IGP; a different lobotomized IGP protocol/process would be
needed.

Alia


On Thu, Aug 16, 2012 at 12:14 PM, Dutta, Pranja= l K (Pranjal)
<p= ranjal.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") whenev= er there is a change. The application would compute SPF on behalf of each rout= er (LSDB). The result of the compute would be pushed by application to each Ro= uter (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 ser= ver 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 ar= e high. This leads to higher time lag on inconsistency between application SP= F compute and FIB update. It's almost like the classic "slow peering&quo= t; issues with TCP like protocols - the high performance peer is slowed down b= y low performance peer.
>
> Static route interface is good thing because it is a state that persis= ts longer.
>
> IGPs may be deployed in very dynamic environments where tight coupling= is desirable between SPF compute and FIB update. In scaled environments the is= sue 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

 

 

 

 

 

--_000_C584046466ED224CA92C1BC3313B963E13F0B8C8B2INBANSXCHMBSA_-- Return-Path: 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 7FB8821F84F9 for ; Thu, 30 Aug 2012 18:16:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.782 X-Spam-Level: X-Spam-Status: No, score=-102.782 tagged_above=-999 required=5 tests=[AWL=0.194, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] 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 da5V+-U28SwA for ; Thu, 30 Aug 2012 18:16:53 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id C233E21F84DA for ; Thu, 30 Aug 2012 18:16:52 -0700 (PDT) Received: by iabz21 with SMTP id z21so4695355iab.31 for ; Thu, 30 Aug 2012 18:16:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=UAOf87CgnvWqCdMnRuKcJZfPwfjP3lDH31dMEpEl5LI=; b=VmDHlRwsrr61Y5urOIrH58GotVQqXEptB1VAgiiI52oqR8BkCfzEnTWppLn6lVV2y+ fIB+K6RA9vTQVb6/UyQhPt0oGGWsmBjO+SxinIr5vDekMZCf8DgnbgPrIfKTIO16hbn0 3KMPQZiEj5EERkTa80z8xmW1ooBRMH5s9IOYqhwJ2qMdh2P7u5OH/xDDEAdz4ZO28vrf T62FmvkA7bXPP+DzF7ReCWNYXCFLlhUeZBG+b+ZaKohmvOhNALrGkudV6pfVoKnaquXe W4hiJsj5tsHaq2o/ub85hMrrNRyr0lXLcUqfftQqb5pGOa8eYyjIM+4RO82Ch3GAm5K9 SRJQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=UAOf87CgnvWqCdMnRuKcJZfPwfjP3lDH31dMEpEl5LI=; b=isXs5W4U06jOOvKNIY4hvaclw9MHdQsM6buLopEzG9FIYRyRXZ2BENz+gl0BRVifuZ 3Ct0AVNSuSvjF9Rm/54l6BxERDRd54r9OXXcsTJIHaCYVGd6JEIsSSdpspDw0HvLcR97 wi3rJSxhg9gOM2b1hAJBQNM121hqmqmhNJJwxAit7TROhrJouR3+1Itu5a1TojB9RV7F gdf7eTqG/Dr+CYE40bXSFnm5q6hjSPC85ggCYRBvCXUuLW6x+hVk9O3HOfWm5A27z+fe iEWfAXD4sLvxLPzM0fTiqtV9yGk/wj1Tj+Fc1uUO7c7/59LQloMhttmnxS/ArxtxTRkZ HzvQ== Received: by 10.43.45.200 with SMTP id ul8mr6725995icb.36.1346375812234; Thu, 30 Aug 2012 18:16:52 -0700 (PDT) Received: by 10.43.45.200 with SMTP id ul8mr6725976icb.36.1346375811901; Thu, 30 Aug 2012 18:16:51 -0700 (PDT) MIME-Version: 1.0 Received: by 10.50.237.67 with HTTP; Thu, 30 Aug 2012 18:16:11 -0700 (PDT) In-Reply-To: References: From: Edward Crabbe Date: Thu, 30 Aug 2012 18:16:11 -0700 Message-ID: To: "Dutta, Pranjal K (Pranjal)" Content-Type: multipart/alternative; boundary=bcaec529972f00a79204c8858c20 X-System-Of-Record: true X-Gm-Message-State: ALoCoQmnYLnvTUXtlB8xnhaaT+xj1qO8P5fC96VqHU9FRckc4ob4Y2fY3lGzXHOW+AxqMaq2PPv3TA6LnISf3Pj0yWtpIQsC2w7fvQj9Q3XgWE8QVYCKtPgOPYKSso7juE5JjkpBhFRZH0e7HoTHl8d7PI5S+tahAB8jEwq9hKQqnc42KBsrzWD+NLzythR3QFPp58u95Npj Cc: "irs-discuss@ietf.org" , "UTTARO, JAMES" , "Shah, Himanshu" , Alia Atlas 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Aug 2012 01:16:54 -0000 --bcaec529972f00a79204c8858c20 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable 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 *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 understan= d > its CSPF or some form like that. Our concern was =96 is there a strong us= e** > ** > > 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 o= f > 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=92t 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:**** > > =91operational model=92 =3D IETF draft that describes the use case.**** > > =91large=92 =3D 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=92s 10% of what overall work that router does tod= ay > 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 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) > 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 build= s > 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 synchroni= ze > 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 hav= e > 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 "slo= w > 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 persist= s > longer. > > > > IGPs may be deployed in very dynamic environments where tight coupling > is desirable between SPF compute and FIB update. In scaled environments t= he > 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**** > > **** > > **** > > **** > > ** ** > --bcaec529972f00a79204c8858c20 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Yep; =A0not having to run an IGP on the box, which is great for those peopl= e not wanting / needing core internet protocols on their devices. =A0The st= andard set of 'SDN' talking appoints applies here in terms of devel= opment speed, performance improvements resulting from use of modern commodi= ty compute,=A0friendliness=A0of development environment, potential for decr= eased bug count* etc etc. =A0

It's a specialized use case, but it exists.=A0

<= /div>
However, my fundamental point is that with IRS as defined=A0curre= ntly=A0(ie PBR with extensible match fields on on RIB recursion + additiona= l monitoring and data collection hooks) you can do hypothetically do away w= ith IGPs. =A0Indeed, assuming that the encaps is applied at some other devi= ce (since IRS as currently described doesn't account for encap/decap ap= plication or negotiation functionality) =A0you can effectively replace a si= gnificant number of protocols (including stateful PCE) should you want to. = =A0 :P

<can of worms>=A0

*= The benefits in terms of decreased bug counts above is really varies with h= ow complex we make IRS of course. =A0=A0

On Thu, Aug 30, 2012 at 6:01 PM, Dutta, Pranjal K (Pranjal) <pranjal.dutta@alcatel-lucent.com> wrote:

Yep, the context of our origi= nal discussion was never PCE as we understand its CSPF or some form like that. = Our concern was =96 is there a strong use

case for non-constrained SPF?= =A0

=A0

=A0

Nope, not specificall= y, but it strongly implies that there is some form of SPF running given the us= e of constraints in the draft. =A0=A0

On Thu, Aug 30, 2012 at 4:16 PM, Dutta, Pranjal K (Pranjal) <pranjal.dutta@alcatel-lucent.com> wrote:

That doesn=92t talk about cen= tralized SPF, does it ?

=A0

From: Edward Cra= bbe [mailto:edc@google.= com]
Sent: Thursday, August 30, 2= 012 4:12 PM


To: Dutta, Pranjal K (Pranjal)
Cc: Alia Atlas; UTTARO, JAME= S; Shah, Himanshu; irs-discuss@ietf.org
Subject: Re: [irs-discuss] I= RS comments

=A0

http://t= ools.ietf.org/html/draft-ietf-pce-stateful-pce-01<= /font>

On Thu, Aug 30, 2012 at 4:09 PM, Dutta, Pranjal K (Pranjal) <pranjal.dutta@alcatel-lucent.com> wrote:

=91operational model=92 =3D I= ETF draft that describes the use case.

=91large=92 =3D 40K LSAs, 500= IGP nodes.

=A0

From: Edward Cra= bbe [mailto:edc@google.= com]
Sent: Thursday, August 30, 2= 012 2:44 PM


To: Dutta, Pranjal K (Pranjal)

Cc:<= font face=3D"Tahoma"> Alia Atlas; UTTARO, JAMES; Shah, Himanshu; irs-discuss@ietf.= org


Subject: Re: [irs-discuss] I= RS comments

=A0

please define 'operational model' ( and 'large' :) . =A0

On Thu, Aug 30, 2012 at 1:40 PM, Dutta, Pranjal K (Pranjal) <pranjal.dutta@alcatel-lucent.com> wrote:

Hi,

=A0=A0=A0=A0=A0=A0=A0=A0 I be= lieve that=92s 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 convergenc= e of large number of flows efficiently.

=A0

Thanks,<= u>

Pranjal<= u>

=A0

From: Edward Cra= bbe [mailto:edc@google.= com]
Sent: Thursday, August 30, 2= 012 11:59 AM
To: Alia Atlas
Cc: Dutta, Pranjal K (Pranjal); UTTARO, JAMES; Shah, Himanshu; irs-discuss@ietf.org


Subject: Re: [irs-discuss] I= RS comments

=A0

Alia;

=A0

If there is=A0

=A0

a) a mechanism for installing routes, pbr or otherwise, which recurse to directly connected nexthops

b) a mechanism for gathering topological information

=A0

then you've inherently enabled centralized spf.=A0

=A0

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. =A0Clearly 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 comp= utation
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)
<p= ranjal.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 g= et 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") whenev= er there is a change. The application would compute SPF on behalf of each rout= er (LSDB). The result of the compute would be pushed by application to each Ro= uter (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 ser= ver 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 ar= e high. This leads to higher time lag on inconsistency between application SP= F compute and FIB update. It's almost like the classic "slow peering= " issues with TCP like protocols - the high performance peer is slowed down b= y low performance peer.
>
> Static route interface is good thing because it is a state that persis= ts longer.
>
> IGPs may be deployed in very dynamic environments where tight coupling= is desirable between SPF compute and FIB update. In scaled environments the is= sue 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

=A0

=A0

=A0

=A0


--bcaec529972f00a79204c8858c20-- Return-Path: 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 37A3B11E80E1 for ; Thu, 30 Aug 2012 18:01:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.45 X-Spam-Level: X-Spam-Status: No, score=-7.45 tagged_above=-999 required=5 tests=[AWL=-0.852, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 Yf2AYx5H-ae2 for ; Thu, 30 Aug 2012 18:01:32 -0700 (PDT) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by ietfa.amsl.com (Postfix) with ESMTP id 5BEE211E80DE for ; Thu, 30 Aug 2012 18:01:32 -0700 (PDT) Received: from inbansmailrelay2.in.alcatel-lucent.com (h135-250-11-33.lucent.com [135.250.11.33]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id q7V11Lu0021455 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 30 Aug 2012 20:01:23 -0500 (CDT) Received: from INBANSXCHHUB03.in.alcatel-lucent.com (inbansxchhub03.in.alcatel-lucent.com [135.250.12.80]) by inbansmailrelay2.in.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id q7V11Ir3008191 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 31 Aug 2012 06:31:18 +0530 Received: from INBANSXCHMBSA3.in.alcatel-lucent.com ([135.250.12.53]) by INBANSXCHHUB03.in.alcatel-lucent.com ([135.250.12.80]) with mapi; Fri, 31 Aug 2012 06:31:18 +0530 From: "Dutta, Pranjal K (Pranjal)" To: Edward Crabbe Date: Fri, 31 Aug 2012 06:31:15 +0530 Thread-Topic: [irs-discuss] IRS comments Thread-Index: Ac2HEGOXv9CngsPeRhq6DZFdPJrq/wAA2ziA Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C584046466ED224CA92C1BC3313B963E13F0B8C8ADINBANSXCHMBSA_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 Cc: "irs-discuss@ietf.org" , "UTTARO, JAMES" , "Shah, Himanshu" , Alia Atlas 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Aug 2012 01:01:35 -0000 --_000_C584046466ED224CA92C1BC3313B963E13F0B8C8ADINBANSXCHMBSA_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 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) > 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) > wrote: 'operational model' =3D IETF draft that describes the use case. 'large' =3D 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) > 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 di= rectly 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 > 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) >= 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 prec= isely 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 "diff= s" from each router (thru "controller") whenever there is a change. The app= lication would compute SPF on behalf of each router (LSDB). The result of t= he 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 scalabi= lity numbers in LSDB we are talking about? > > The "application" would be running in a high performance server and so SP= F compute there is not an issue and perhaps it is good way to synchronize F= IB update (to a certain extent) to avoid u-loops etc. > > But when we are managing all routers in the purview of the application, t= he computing power in each router is not uniform. To be realistic, I have s= ome concerns on how much "real-timeness" we could achieve between applicati= on and controllers on such proposals, esp. when scaling numbers are high. T= his leads to higher time lag on inconsistency between application SPF compu= te 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 perfor= mance 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 i= ssue 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 persiste= ncy 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 --_000_C584046466ED224CA92C1BC3313B963E13F0B8C8ADINBANSXCHMBSA_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

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 C= rabbe [mailto:edc@google.com]
Sent: Thursday, August 30, 2= 012 5:34 PM
To: Dutta, Pranjal K (Pranjal)
Cc: Alia Atlas; UTTARO, JAME= S; Shah, Himanshu; ir= s-discuss@ietf.org
Subject: Re: [irs-discuss] I= RS comments

 

Nope, not specifi= cally, but it strongly implies that there is some form of SPF running given the us= e 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, 2= 012 4:12 PM


To: Dutta, Pranjal K (Pranjal)
Cc: Alia Atlas; UTTARO, JAME= S; Shah, Himanshu; irs-discuss@ietf.org
Subject: Re: [irs-discuss] I= RS 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’ =3D IETF draft that describes t= he use case.

‘large’ =3D 40K LSAs, 500 IGP nodes.<= o:p>

 

From: Edward Crabbe [mailto:edc@google.com]
Sent: Thursday, August 30, 2= 012 2:44 PM

=
To: Dutta, Pranjal K (Pranjal)

Cc: Alia Atlas; UTTARO, JAMES; Shah, Himanshu; irs-discuss@ietf.= org

=
Subject: Re: [irs-discuss] I= RS comments

 

please d= efine '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, 2= 012 11:59 AM
To: Alia Atlas
Cc: Dutta, Pranjal K (Pranjal); UTTARO, JAMES; Shah, Himanshu; irs-discuss@ietf.org

=
Subject: Re: [irs-discuss] I= RS comments

 

Alia;

 

If there= is 

 

a) a mec= hanism for installing routes, pbr or otherwise, which recurse to directly connected nexthops

b) a mec= hanism 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<= br> 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 computat= ion
in the IGP; a different lobotomized IGP protocol/process would be
needed.

Alia


On Thu, Aug 16, 2012 at 12:14 PM, Dutta, Pranja= l K (Pranjal)
<p= ranjal.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") whenev= er there is a change. The application would compute SPF on behalf of each rout= er (LSDB). The result of the compute would be pushed by application to each Ro= uter (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 ser= ver 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 ar= e high. This leads to higher time lag on inconsistency between application SP= F compute and FIB update. It's almost like the classic "slow peering&quo= t; issues with TCP like protocols - the high performance peer is slowed down b= y low performance peer.
>
> Static route interface is good thing because it is a state that persis= ts longer.
>
> IGPs may be deployed in very dynamic environments where tight coupling= is desirable between SPF compute and FIB update. In scaled environments the is= sue 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

 

 

 

 

--_000_C584046466ED224CA92C1BC3313B963E13F0B8C8ADINBANSXCHMBSA_-- Return-Path: 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 0C3BB21F84EC for ; Thu, 30 Aug 2012 17:34:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.309 X-Spam-Level: X-Spam-Status: No, score=-102.309 tagged_above=-999 required=5 tests=[AWL=-0.333, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] 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 F5AQ9kc8GZUs for ; Thu, 30 Aug 2012 17:34:29 -0700 (PDT) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id D9D7D21F84EA for ; Thu, 30 Aug 2012 17:34:28 -0700 (PDT) Received: by ieak13 with SMTP id k13so1436925iea.31 for ; Thu, 30 Aug 2012 17:34:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=htXmvrS2BBvz0tthUwo9TfC0aPgF4RJ+pTrNUPU4VtU=; b=WukxZv7aBNhYvBKbx+aij8lJzJmUbRUGyXpUKrLV5lx3R26jgfkol1NTSS5gT5e2pV RhoxdGm1A6ys/zKh/4lNOIfbW0vgsGixdzB57OZBlRyOmpOMvCsBRCj6HUFPcVmjibRp +oYBZruSWgiepwcluNbz3v62YoGuKc6YnNw91oQ14XEwXc9+6n/bFgMoCVinNHUmDvX4 XUT5gn1RX3w1tFil6g0WiKdmgU5FWTE2Kli0x9cPmRQQlpwVNigS5eaa5Shdv8Kb2W0S IV89OnJde6SoCyw1n6k6S5e0WmFhzQG/liCWvaPlYkfAwo6IodROPG7h12y5l1oqZkxq ED8A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=htXmvrS2BBvz0tthUwo9TfC0aPgF4RJ+pTrNUPU4VtU=; b=JC8NQe9FxS+4ML2QGuAb5+bjEY+DdZEelv+W8v0KdAtaPUUViX6iiEdjnLmQdzpQK3 jzPBg/gEn3iryvc38PRRPn6xyTJKiJslLHPT6956fNUsNlJ2aYMu9VGJmxE9ZWx7R0DE xjIzhi+X8McR91SK44LHBRaz9PdsWAxpsdKMAinmka/J9hR9hgQFpTVsV9SW/OlAehw1 1kg3cEG9eCOm4XE59CXCVOcQpH1sh24sannOAyHMoKhereMZYFILtsq191oqkv9TYucz mt2UArjSwew+JNS/yHp4+O9ae5iJMBLy8exzbyvJk1PDSAZGCeTyrWG+H1x35GXUEFg1 XXhQ== Received: by 10.50.214.1 with SMTP id nw1mr303714igc.2.1346373268319; Thu, 30 Aug 2012 17:34:28 -0700 (PDT) Received: by 10.50.214.1 with SMTP id nw1mr303697igc.2.1346373268043; Thu, 30 Aug 2012 17:34:28 -0700 (PDT) MIME-Version: 1.0 Received: by 10.50.237.67 with HTTP; Thu, 30 Aug 2012 17:33:46 -0700 (PDT) In-Reply-To: References: <812700A304640D4292205D5E83FC59E1061C211D@p-embx01-eq.jnpr.net> <3512BB31280C39448A9880F61DD54CEB09C07E@xmb-aln-x09.cisco.com> From: Edward Crabbe Date: Thu, 30 Aug 2012 17:33:46 -0700 Message-ID: To: "Dutta, Pranjal K (Pranjal)" Content-Type: multipart/alternative; boundary=14dae9340d076077ec04c884f457 X-System-Of-Record: true X-Gm-Message-State: ALoCoQmFTWOth7prKf4yULvuQKuYgNd5E817sNM7Prb79Iv6Ca7Xjq8/MSaSdSbamKffznlSGtTpLVxGqR6XA4rfbw7Ujq4AfTKFlWWQqMkLaK51W0Cf4HpcAeSNLM7HCqkBdxa/5ElfX6cLBFWubXWDaI3e7VddSebudJBhdh6HkE4tTt5+ioLp2b70er646klu3g4UyDFj Cc: "irs-discuss@ietf.org" , "UTTARO, JAMES" , "Shah, Himanshu" , Alia Atlas 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Aug 2012 00:34:30 -0000 --14dae9340d076077ec04c884f457 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable 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=92t 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:**** > > =91operational model=92 =3D IETF draft that describes the use case.**** > > =91large=92 =3D 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=92s 10% of what overall work that router does tod= ay > 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 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) > 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 build= s > 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 synchroni= ze > 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 hav= e > 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 "slo= w > 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 persist= s > longer. > > > > IGPs may be deployed in very dynamic environments where tight coupling > is desirable between SPF compute and FIB update. In scaled environments t= he > 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**** > > **** > > **** > > ** ** > --14dae9340d076077ec04c884f457 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Nope, not specifically, but it strongly implies that there is some form of = SPF running given the use of constraints in the draft. =A0=A0


--14dae9340d076077ec04c884f457-- Return-Path: 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 364FD11E8091 for ; Thu, 30 Aug 2012 16:16:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.413 X-Spam-Level: X-Spam-Status: No, score=-9.413 tagged_above=-999 required=5 tests=[AWL=1.185, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] 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 pRSqYadM6pbH for ; Thu, 30 Aug 2012 16:16:27 -0700 (PDT) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id A219121F84FE for ; Thu, 30 Aug 2012 16:16:27 -0700 (PDT) Received: from inbansmailrelay1.in.alcatel-lucent.com (h135-250-11-31.lucent.com [135.250.11.31]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id q7UNGJfN009278 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 30 Aug 2012 18:16:21 -0500 (CDT) Received: from INBANSXCHHUB03.in.alcatel-lucent.com (inbansxchhub03.in.alcatel-lucent.com [135.250.12.80]) by inbansmailrelay1.in.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id q7UNGH0p025164 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 31 Aug 2012 04:46:17 +0530 Received: from INBANSXCHMBSA3.in.alcatel-lucent.com ([135.250.12.53]) by INBANSXCHHUB03.in.alcatel-lucent.com ([135.250.12.80]) with mapi; Fri, 31 Aug 2012 04:46:17 +0530 From: "Dutta, Pranjal K (Pranjal)" To: Edward Crabbe Date: Fri, 31 Aug 2012 04:46:15 +0530 Thread-Topic: [irs-discuss] IRS comments Thread-Index: Ac2HBQzy9LMHJ0ZeS6aD1yTGTXKaPgAAF55w Message-ID: References: <812700A304640D4292205D5E83FC59E1061C211D@p-embx01-eq.jnpr.net> <3512BB31280C39448A9880F61DD54CEB09C07E@xmb-aln-x09.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C584046466ED224CA92C1BC3313B963E13F0B8C89FINBANSXCHMBSA_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 Cc: "irs-discuss@ietf.org" , "UTTARO, JAMES" , "Shah, Himanshu" , Alia Atlas 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Aug 2012 23:16:30 -0000 --_000_C584046466ED224CA92C1BC3313B963E13F0B8C89FINBANSXCHMBSA_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 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) > wrote: 'operational model' =3D IETF draft that describes the use case. 'large' =3D 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) > 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 di= rectly 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 > 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) >= 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 prec= isely 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 "diff= s" from each router (thru "controller") whenever there is a change. The app= lication would compute SPF on behalf of each router (LSDB). The result of t= he 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 scalabi= lity numbers in LSDB we are talking about? > > The "application" would be running in a high performance server and so SP= F compute there is not an issue and perhaps it is good way to synchronize F= IB update (to a certain extent) to avoid u-loops etc. > > But when we are managing all routers in the purview of the application, t= he computing power in each router is not uniform. To be realistic, I have s= ome concerns on how much "real-timeness" we could achieve between applicati= on and controllers on such proposals, esp. when scaling numbers are high. T= his leads to higher time lag on inconsistency between application SPF compu= te 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 perfor= mance 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 i= ssue 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 persiste= ncy 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 --_000_C584046466ED224CA92C1BC3313B963E13F0B8C89FINBANSXCHMBSA_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

That doesn’t talk about centrali= zed SPF, does it ?

 

From: Edward C= rabbe [mailto:edc@google.com]
Sent: Thursday, August 30, 2= 012 4:12 PM
To: Dutta, Pranjal K (Pranjal)
Cc: Alia Atlas; UTTARO, JAME= S; Shah, Himanshu; ir= s-discuss@ietf.org
Subject: Re: [irs-discuss] I= RS comments

 

http://t= ools.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’ =3D IETF draft that describes t= he use case.

‘large’ =3D 40K LSAs, 500 IGP nodes.<= o:p>

 

From: Edward Crabbe [mailto:edc@google.com]
Sent: Thursday, August 30, 2= 012 2:44 PM


To: Dutta, Pranjal K (Pranjal)

Cc: Alia Atlas; UTTARO, JAMES; Shah, Himanshu; irs-discuss@ietf.org


Subject: Re: [irs-discuss] I= RS comments

 

please d= efine '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, 2= 012 11:59 AM
To: Alia Atlas
Cc: Dutta, Pranjal K (Pranjal); UTTARO, JAMES; Shah, Himanshu; irs-discuss@ietf.org

=
Subject: Re: [irs-discuss] I= RS comments

 

Alia;

 

If there= is 

 

a) a mec= hanism for installing routes, pbr or otherwise, which recurse to directly connected nexthops

b) a mec= hanism 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<= br> 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 computat= ion
in the IGP; a different lobotomized IGP protocol/process would be
needed.

Alia


On Thu, Aug 16, 2012 at 12:14 PM, Dutta, Pranja= l K (Pranjal)
<p= ranjal.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") whenev= er there is a change. The application would compute SPF on behalf of each rout= er (LSDB). The result of the compute would be pushed by application to each Ro= uter (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 ser= ver 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 ar= e high. This leads to higher time lag on inconsistency between application SP= F compute and FIB update. It's almost like the classic "slow peering&quo= t; issues with TCP like protocols - the high performance peer is slowed down b= y low performance peer.
>
> Static route interface is good thing because it is a state that persis= ts longer.
>
> IGPs may be deployed in very dynamic environments where tight coupling= is desirable between SPF compute and FIB update. In scaled environments the is= sue 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

 

 

 

--_000_C584046466ED224CA92C1BC3313B963E13F0B8C89FINBANSXCHMBSA_-- Return-Path: 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 79E8921F846B for ; Thu, 30 Aug 2012 16:13:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.793 X-Spam-Level: X-Spam-Status: No, score=-102.793 tagged_above=-999 required=5 tests=[AWL=0.183, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] 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 5OXJ3na6FxX9 for ; Thu, 30 Aug 2012 16:13:18 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 3731B21F8505 for ; Thu, 30 Aug 2012 16:13:18 -0700 (PDT) Received: by iabz21 with SMTP id z21so4547466iab.31 for ; Thu, 30 Aug 2012 16:13:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=qBXn6oy1azz4RaH+HPOYc3Xk0dpcDM0/lVnP/uA2ojk=; b=l0WSOZ4fpxeHPol4O/SEEr39B/AzgZLbEMieEBmM5KzDneclu31NgaWYW3uJcblgt7 gqffh44AnC7JBGWd1XBm8FNjDEWDZtm0vVqWYUTRqj6Lv/82pV3UnnIGKc1wM+cZs6zS oBOLtAhEfCLouXY7GZqndEQw1PibZIpyqctCet58zbL6PyHecF4FT7ySo16Ye9tcJjOI 2oeqdRt4PGKlhClaGXvsuDBw1s+08gTaQwv9pLNvb5NWqApc1qix3x01JRDR4nndZcd5 9Va+coVLrryTsZSTPluxVWmN1GelNwbJnH77rscuOrWy91vfySKDmAJhLdr6fiCRRReb fK3g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=qBXn6oy1azz4RaH+HPOYc3Xk0dpcDM0/lVnP/uA2ojk=; b=Ahq2Bmu1yLG+IpuO5miSaqrREHD/0SmGZt/OESkJYKQV185EtKnOBr5fbKsBhGfOZC leMWAYud/x2CNRUtRz/7PZ2gft+dmtacf8qcUgspyrmJQF+XjBMZR3f0qLmyVBMPuQRY DvYemMqSjl3F66GmS9m37ycCPsAUfH1vEehj0XsioV/DrVLypHTqkgsg7wLAbW6pTejX HEnZdQCCQyNnhL3mqSUb/HjmwagVw+gkMZOIxrtjZ3Qi0pgXuvbtdZ2N14noY0zg7bzi p2ac/MybHBYAQbXWLhX4oyNr1tHGn1eLb87ZqyS/G5vM8X8bk7qutAIsevBweCAJbTUg bW6Q== Received: by 10.50.94.138 with SMTP id dc10mr81279igb.39.1346368397835; Thu, 30 Aug 2012 16:13:17 -0700 (PDT) Received: by 10.50.94.138 with SMTP id dc10mr81263igb.39.1346368397663; Thu, 30 Aug 2012 16:13:17 -0700 (PDT) MIME-Version: 1.0 Received: by 10.50.237.67 with HTTP; Thu, 30 Aug 2012 16:12:29 -0700 (PDT) In-Reply-To: References: <812700A304640D4292205D5E83FC59E1061C211D@p-embx01-eq.jnpr.net> <3512BB31280C39448A9880F61DD54CEB09C07E@xmb-aln-x09.cisco.com> From: Edward Crabbe Date: Thu, 30 Aug 2012 16:12:29 -0700 Message-ID: To: "Dutta, Pranjal K (Pranjal)" Content-Type: multipart/alternative; boundary=e89a8f234c3f145d0d04c883d208 X-System-Of-Record: true X-Gm-Message-State: ALoCoQnLPWg8NG0xBIfSmoeNpJ58na46348/koLPZusFBL/289Fx7N6wcbczuAsFlTuIz+HPoQ2Yzm0Uy86CIT16TkY+7KLf3vBIAXmz4xuxBOfAgQQTYBc5DepZ9eP3ODjRKf5rgKE5ziVzprkZRsvfuP8pVIuhtymYMQNYXPNHqNowABlawKKbZA76IR80oL/0fxDqNdK/ Cc: "irs-discuss@ietf.org" , "UTTARO, JAMES" , "Shah, Himanshu" , Alia Atlas 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Aug 2012 23:13:19 -0000 --e89a8f234c3f145d0d04c883d208 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable 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: > ** > > =91operational model=92 =3D IETF draft that describes the use case.**** > > =91large=92 =3D 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=92s 10% of what overall work that router does tod= ay > 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 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) > 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 build= s > 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 synchroni= ze > 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 hav= e > 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 "slo= w > 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 persist= s > longer. > > > > IGPs may be deployed in very dynamic environments where tight coupling > is desirable between SPF compute and FIB update. In scaled environments t= he > 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**** > > **** > > ** ** > --e89a8f234c3f145d0d04c883d208 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable 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:

=91operational model=92 =3D I= ETF draft that describes the use case.

=91large=92 =3D 40K LSAs, 500= IGP nodes.

=A0

=A0

please define 'operational model' ( and 'large' :) . =A0

On Thu, Aug 30, 2012 at 1:40 PM, Dutta, Pranjal K (Pranjal) <pranjal.dutta@alcatel-lucent.com> wrote:

Hi,

=A0=A0=A0=A0=A0=A0=A0=A0 I be= lieve that=92s 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 convergenc= e of large number of flows efficiently.

=A0

Thanks,<= u>

Pranjal<= u>

=A0

From: Edward Cra= bbe [mailto:edc@google.= com]
Sent: Thursday, August 30, 2= 012 11:59 AM
To: Alia Atlas
Cc: Dutta, Pranjal K (Pranjal); UTTARO, JAMES; Shah, Himanshu; irs-discuss@ietf.org


Subject: Re: [irs-discuss] I= RS comments

=A0

Alia;

=A0

If there is=A0

=A0

a) a mechanism for installing routes, pbr or otherwise, which recurse to directly connected nexthops

b) a mechanism for gathering topological information

=A0

then you've inherently enabled centralized spf.=A0

=A0

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. =A0Clearly 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 comp= utation
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)
<p= ranjal.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 g= et 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") whenev= er there is a change. The application would compute SPF on behalf of each rout= er (LSDB). The result of the compute would be pushed by application to each Ro= uter (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 ser= ver 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 ar= e high. This leads to higher time lag on inconsistency between application SP= F compute and FIB update. It's almost like the classic "slow peering= " issues with TCP like protocols - the high performance peer is slowed down b= y low performance peer.
>
> Static route interface is good thing because it is a state that persis= ts longer.
>
> IGPs may be deployed in very dynamic environments where tight coupling= is desirable between SPF compute and FIB update. In scaled environments the is= sue 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

=A0

=A0


--e89a8f234c3f145d0d04c883d208-- Return-Path: 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 0AEFE21F84FE for ; Thu, 30 Aug 2012 16:10:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.373 X-Spam-Level: X-Spam-Status: No, score=-9.373 tagged_above=-999 required=5 tests=[AWL=1.225, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] 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 1rk9e664pRp2 for ; Thu, 30 Aug 2012 16:10:11 -0700 (PDT) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by ietfa.amsl.com (Postfix) with ESMTP id D85DB21F84FD for ; Thu, 30 Aug 2012 16:10:10 -0700 (PDT) Received: from inbansmailrelay2.in.alcatel-lucent.com (h135-250-11-33.lucent.com [135.250.11.33]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id q7UNA0p2003416 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 30 Aug 2012 18:10:02 -0500 (CDT) Received: from INBANSXCHHUB01.in.alcatel-lucent.com (inbansxchhub01.in.alcatel-lucent.com [135.250.12.32]) by inbansmailrelay2.in.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id q7UN9vnh005658 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 31 Aug 2012 04:39:57 +0530 Received: from INBANSXCHMBSA3.in.alcatel-lucent.com ([135.250.12.53]) by INBANSXCHHUB01.in.alcatel-lucent.com ([135.250.12.32]) with mapi; Fri, 31 Aug 2012 04:39:57 +0530 From: "Dutta, Pranjal K (Pranjal)" To: Edward Crabbe Date: Fri, 31 Aug 2012 04:39:55 +0530 Thread-Topic: [irs-discuss] IRS comments Thread-Index: Ac2G+K76AaZB3gZLR+CsXkVbcTETTAAC7cBQ Message-ID: References: <812700A304640D4292205D5E83FC59E1061C211D@p-embx01-eq.jnpr.net> <3512BB31280C39448A9880F61DD54CEB09C07E@xmb-aln-x09.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C584046466ED224CA92C1BC3313B963E13F0B8C89BINBANSXCHMBSA_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 Cc: "irs-discuss@ietf.org" , "UTTARO, JAMES" , "Shah, Himanshu" , Alia Atlas 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Aug 2012 23:10:13 -0000 --_000_C584046466ED224CA92C1BC3313B963E13F0B8C89BINBANSXCHMBSA_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 'operational model' =3D IETF draft that describes the use case. 'large' =3D 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) > 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 di= rectly 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 > 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) >= 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 prec= isely 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 "diff= s" from each router (thru "controller") whenever there is a change. The app= lication would compute SPF on behalf of each router (LSDB). The result of t= he 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 scalabi= lity numbers in LSDB we are talking about? > > The "application" would be running in a high performance server and so SP= F compute there is not an issue and perhaps it is good way to synchronize F= IB update (to a certain extent) to avoid u-loops etc. > > But when we are managing all routers in the purview of the application, t= he computing power in each router is not uniform. To be realistic, I have s= ome concerns on how much "real-timeness" we could achieve between applicati= on and controllers on such proposals, esp. when scaling numbers are high. T= his leads to higher time lag on inconsistency between application SPF compu= te 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 perfor= mance 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 i= ssue 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 persiste= ncy 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 --_000_C584046466ED224CA92C1BC3313B963E13F0B8C89BINBANSXCHMBSA_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

‘operational model’ =3D IE= TF draft that describes the use case.

‘large’ =3D 40K LSAs, 500 = IGP nodes.

 

From: Edward C= rabbe [mailto:edc@google.com]
Sent: Thursday, August 30, 2= 012 2:44 PM
To: Dutta, Pranjal K (Pranjal)
Cc: Alia Atlas; UTTARO, JAME= S; Shah, Himanshu; ir= s-discuss@ietf.org
Subject: Re: [irs-discuss] I= RS 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, 2= 012 11:59 AM
To: Alia Atlas
Cc: Dutta, Pranjal K (Pranjal); UTTARO, JAMES; Shah, Himanshu; irs-discuss@ietf.org


Subject: Re: [irs-discuss] I= RS comments

 

Alia;

 

If there= is 

 

a) a mec= hanism for installing routes, pbr or otherwise, which recurse to directly connected nexthops

b) a mec= hanism 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<= br> 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 computat= ion
in the IGP; a different lobotomized IGP protocol/process would be
needed.

Alia


On Thu, Aug 16, 2012 at 12:14 PM, Dutta, Pranja= l K (Pranjal)
<p= ranjal.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") whenev= er there is a change. The application would compute SPF on behalf of each rout= er (LSDB). The result of the compute would be pushed by application to each Ro= uter (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 ser= ver 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 ar= e high. This leads to higher time lag on inconsistency between application SP= F compute and FIB update. It's almost like the classic "slow peering&quo= t; issues with TCP like protocols - the high performance peer is slowed down b= y low performance peer.
>
> Static route interface is good thing because it is a state that persis= ts longer.
>
> IGPs may be deployed in very dynamic environments where tight coupling= is desirable between SPF compute and FIB update. In scaled environments the is= sue 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

 

 

--_000_C584046466ED224CA92C1BC3313B963E13F0B8C89BINBANSXCHMBSA_-- Return-Path: 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 7F5E011E808E for ; Thu, 30 Aug 2012 14:44:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.328 X-Spam-Level: X-Spam-Status: No, score=-102.328 tagged_above=-999 required=5 tests=[AWL=-0.352, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] 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 0Dvp5+fdHUvg for ; Thu, 30 Aug 2012 14:44:43 -0700 (PDT) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7ECB511E808D for ; Thu, 30 Aug 2012 14:44:43 -0700 (PDT) Received: by ieak13 with SMTP id k13so1334154iea.31 for ; Thu, 30 Aug 2012 14:44:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=7R0xm6uG2MzF7/Jr+50VLItg/xN/qdraaU16/fUVN+U=; b=f7keZ77D6qonM3kN8uehSOZPMVb3MpKYE9S5Hvf3yJ0hGjsWbN8hbH8ccqGHZBRL1G hALZ9qNiuzTazcooDdFDtjFfQFBJrEp4lFISomwqIAb6+KowB9bcRr+llNvB/0x8ZgTn 1YUm0rAftISDytV6+LnK2SOl4UslidsRSJL5QO9Akge8DfoBuU5IV+4qDN6A+lwOZgbA OOa6wC2jaKMvcuF+u39K22YsZ9iiLFME7Zbjz1u0lkzej0V2NITP5jY7CZ1zBszi8Riq 5NnizqZ9w7/FfRsIBHg+g+gSJX2WsTLHSGVOFwOWSGo+dW5Eoi5cmMZsJbwqpjvyKfCE 7afw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=7R0xm6uG2MzF7/Jr+50VLItg/xN/qdraaU16/fUVN+U=; b=eV1ASS9pttk567L5FPEoFBWwdIlAjwB2PpnaEMFQPkPf1T3iAQ8rHDbylr1mqtut6n Fuu8ueoCUMXSPvRBPnk3eYQg7itxDDQnay59+KZW3AxDVnONS4cCzxMxGJRHFLjoCjNU 1JWgthQivcXS43fsDOx5sUvleBV7xL7NhamuzJwlMhJqXFMow8AfBrGJc3r3Fjqrh+uX SJgOOGW6P4erc2elzGuavBYaiGmsDOuH20d6e4WmHNTOedr4bSN4aABS8ZiWDHLQ45p/ QEN4UfzK60avNHwGaquu1bncYUwuTwMPrifWBY9eMOCbInoUCxSnqaMbQYBO8akQsKSn ccqA== Received: by 10.50.193.201 with SMTP id hq9mr2407155igc.48.1346363082714; Thu, 30 Aug 2012 14:44:42 -0700 (PDT) Received: by 10.50.193.201 with SMTP id hq9mr2407130igc.48.1346363082352; Thu, 30 Aug 2012 14:44:42 -0700 (PDT) MIME-Version: 1.0 Received: by 10.50.237.67 with HTTP; Thu, 30 Aug 2012 14:44:02 -0700 (PDT) In-Reply-To: References: <812700A304640D4292205D5E83FC59E1061C211D@p-embx01-eq.jnpr.net> <3512BB31280C39448A9880F61DD54CEB09C07E@xmb-aln-x09.cisco.com> From: Edward Crabbe Date: Thu, 30 Aug 2012 14:44:02 -0700 Message-ID: To: "Dutta, Pranjal K (Pranjal)" Content-Type: multipart/alternative; boundary=14dae9340f374328f004c8829526 X-System-Of-Record: true X-Gm-Message-State: ALoCoQl8WJRnLZq6NX07zVdOdl2sc2jVz7MfB7LK7lxDYP473kUSwxua/F+4so4NbkHJuFBbgMhyaWxVYmAXH94QR2czR09DAQPERLOcSRiHBVkUNyp0h8keKdUhdyaKLQ7dxmKyfAOQYjA3zxU3tFhhLu+BBQhNAbA0xxg5khlRl9K2a+0f7M0dd0BjObz90IK3LNwz/BBg Cc: "irs-discuss@ietf.org" , "UTTARO, JAMES" , "Shah, Himanshu" , Alia Atlas 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Aug 2012 21:44:44 -0000 --14dae9340f374328f004c8829526 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable 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=92s 10% of what overall work that router does tod= ay > 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 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) > 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 build= s > 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 synchroni= ze > 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 hav= e > 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 "slo= w > 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 persist= s > longer. > > > > IGPs may be deployed in very dynamic environments where tight coupling > is desirable between SPF compute and FIB update. In scaled environments t= he > 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**** > > ** ** > --14dae9340f374328f004c8829526 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable please define 'operational model' ( and 'large' :) . =A0
On Thu, Aug 30, 2012 at 1:40 PM, Dutta, Pra= njal K (Pranjal) <pranjal.dutta@alcatel-lucent.com><= /span> wrote:

Hi,

=A0=A0=A0=A0=A0=A0=A0=A0 I be= lieve that=92s 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 convergenc= e of large number of flows efficiently.

=A0

Thanks,<= /font>

Pranjal<= /font>

=A0

=A0

Alia;

=A0

If there is=A0

=A0

a) a mechanism for installing routes, pbr or otherwi= se, which recurse to directly connected nexthops

b) a mechanism for gathering topological information=

=A0

then you've inherently enabled centralized spf.= =A0

=A0

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 int= ended or desired by
moving the SPF functionality to a centralized location. =A0Clearly 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 comp= utation
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)
<p= ranjal.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 g= et 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") whenev= er there is a change. The application would compute SPF on behalf of each rout= er (LSDB). The result of the compute would be pushed by application to each Ro= uter (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 ser= ver 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 ar= e high. This leads to higher time lag on inconsistency between application SP= F compute and FIB update. It's almost like the classic "slow peering= " issues with TCP like protocols - the high performance peer is slowed down b= y low performance peer.
>
> Static route interface is good thing because it is a state that persis= ts longer.
>
> IGPs may be deployed in very dynamic environments where tight coupling= is desirable between SPF compute and FIB update. In scaled environments the is= sue 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

=A0


--14dae9340f374328f004c8829526-- Return-Path: 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 0DB2421F85AA for ; Thu, 30 Aug 2012 13:41:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.4 X-Spam-Level: X-Spam-Status: No, score=-7.4 tagged_above=-999 required=5 tests=[AWL=-0.802, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 23w8StzmtaRW for ; Thu, 30 Aug 2012 13:41:13 -0700 (PDT) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id 0054421F85A7 for ; Thu, 30 Aug 2012 13:41:12 -0700 (PDT) Received: from inbansmailrelay1.in.alcatel-lucent.com (h135-250-11-31.lucent.com [135.250.11.31]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id q7UKf5oH014515 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 30 Aug 2012 15:41:07 -0500 (CDT) Received: from INBANSXCHHUB02.in.alcatel-lucent.com (inbansxchhub02.in.alcatel-lucent.com [135.250.12.35]) by inbansmailrelay1.in.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id q7UKf1i4020582 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 31 Aug 2012 02:11:02 +0530 Received: from INBANSXCHMBSA3.in.alcatel-lucent.com ([135.250.12.53]) by INBANSXCHHUB02.in.alcatel-lucent.com ([135.250.12.35]) with mapi; Fri, 31 Aug 2012 02:11:01 +0530 From: "Dutta, Pranjal K (Pranjal)" To: Edward Crabbe , Alia Atlas Date: Fri, 31 Aug 2012 02:10:59 +0530 Thread-Topic: [irs-discuss] IRS comments Thread-Index: Ac2G4ZvqJ0Jo5IAaSs2Ri0esYrpMZwADbBRg Message-ID: References: <812700A304640D4292205D5E83FC59E1061C211D@p-embx01-eq.jnpr.net> <3512BB31280C39448A9880F61DD54CEB09C07E@xmb-aln-x09.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C584046466ED224CA92C1BC3313B963E13F0B8C87FINBANSXCHMBSA_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 Cc: "UTTARO, JAMES" , "Shah, Himanshu" , "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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Aug 2012 20:41:15 -0000 --_000_C584046466ED224CA92C1BC3313B963E13F0B8C87FINBANSXCHMBSA_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 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 di= rectly 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 > 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) >= 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 prec= isely 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 "diff= s" from each router (thru "controller") whenever there is a change. The app= lication would compute SPF on behalf of each router (LSDB). The result of t= he 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 scalabi= lity numbers in LSDB we are talking about? > > The "application" would be running in a high performance server and so SP= F compute there is not an issue and perhaps it is good way to synchronize F= IB update (to a certain extent) to avoid u-loops etc. > > But when we are managing all routers in the purview of the application, t= he computing power in each router is not uniform. To be realistic, I have s= ome concerns on how much "real-timeness" we could achieve between applicati= on and controllers on such proposals, esp. when scaling numbers are high. T= his leads to higher time lag on inconsistency between application SPF compu= te 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 perfor= mance 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 i= ssue 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 persiste= ncy 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 --_000_C584046466ED224CA92C1BC3313B963E13F0B8C87FINBANSXCHMBSA_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

      &n= bsp;  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 larg= e number of flows efficiently.

 

Thanks,

Pranjal

 

From: Edward C= rabbe [mailto:edc@google.com]
Sent: Thursday, August 30, 2= 012 11:59 AM
To: Alia Atlas
Cc: Dutta, Pranjal K (Pranjal); UTTARO, JAMES; Shah, Himanshu; irs-discuss@ietf.or= g
Subject: Re: [irs-discuss] I= RS comments

 

Alia;

 

If there is 

 

a) a mechanism for installing routes, pbr or otherwise, which recur= se 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&g= t; 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<= br> 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 computat= ion
in the IGP; a different lobotomized IGP protocol/process would be
needed.

Alia


On Thu, Aug 16, 2012 at 12:14 PM, Dutta, Pranja= l K (Pranjal)
<pranjal.dutta@alcat= el-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") whenev= er there is a change. The application would compute SPF on behalf of each rout= er (LSDB). The result of the compute would be pushed by application to each Ro= uter (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 ser= ver 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 ar= e high. This leads to higher time lag on inconsistency between application SP= F compute and FIB update. It's almost like the classic "slow peering&quo= t; issues with TCP like protocols - the high performance peer is slowed down b= y low performance peer.
>
> Static route interface is good thing because it is a state that persis= ts longer.
>
> IGPs may be deployed in very dynamic environments where tight coupling= is desirable between SPF compute and FIB update. In scaled environments the is= sue 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

 

--_000_C584046466ED224CA92C1BC3313B963E13F0B8C87FINBANSXCHMBSA_-- Return-Path: 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 491DA21F8611 for ; Thu, 30 Aug 2012 12:52:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.456 X-Spam-Level: X-Spam-Status: No, score=-3.456 tagged_above=-999 required=5 tests=[AWL=0.143, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 n0v6OWXNoWr6 for ; Thu, 30 Aug 2012 12:52:16 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 71D3221F860E for ; Thu, 30 Aug 2012 12:52:16 -0700 (PDT) Received: by iabz21 with SMTP id z21so4239513iab.31 for ; Thu, 30 Aug 2012 12:52:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ezGtdU608XQFkrBWPavwIzK+1CoWqOsu8/6nkUPyNZc=; b=RTDJBUUJ/VEE01JAqaRzmODz5rC8d3iqr7KvE1VCtvuPT81pCwuLTEc/Q/k6+Rgs2N QhPqoy1Q9r066NlhMPMreoXFhCMb5jX5VfOrvqq6l0JkeO5xnyalY5CV7pl6Y1eFiBmA 8nF92qqF5GurB94xNh6FbzOs10ySfELQEhjgOSqRJEDH6BBp5eZ/1ZR/uiva1MtBzyks kNPRBpimXy5dcN1+FLz0QRviEOcxgG9wgoLQQ9s9EHrjzkmMaovtaqJSb+33AEtcokyP lRYOZ7igKvXcmfDYpQStRjMmvNprrbiswM/1QHLF+hLa8N9llL+q0iihwLSXnDFmSlc8 3e0w== MIME-Version: 1.0 Received: by 10.50.149.202 with SMTP id uc10mr2266615igb.2.1346356335827; Thu, 30 Aug 2012 12:52:15 -0700 (PDT) Received: by 10.50.91.135 with HTTP; Thu, 30 Aug 2012 12:52:15 -0700 (PDT) In-Reply-To: References: <812700A304640D4292205D5E83FC59E1061C211D@p-embx01-eq.jnpr.net> <3512BB31280C39448A9880F61DD54CEB09C07E@xmb-aln-x09.cisco.com> Date: Thu, 30 Aug 2012 15:52:15 -0400 Message-ID: From: Alia Atlas To: Edward Crabbe Content-Type: text/plain; charset=ISO-8859-1 Cc: "UTTARO, JAMES" , "Dutta, Pranjal K \(Pranjal\)" , "Shah, Himanshu" , "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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Aug 2012 19:52:17 -0000 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 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 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 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 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) >> >> 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 >> > >> > > > Return-Path: 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 47AD821F8466 for ; Thu, 30 Aug 2012 12:33:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.809 X-Spam-Level: X-Spam-Status: No, score=-102.809 tagged_above=-999 required=5 tests=[AWL=0.167, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] 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 cm14pNz30Vs5 for ; Thu, 30 Aug 2012 12:33:05 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 29F1A21F848F for ; Thu, 30 Aug 2012 12:33:05 -0700 (PDT) Received: by iabz21 with SMTP id z21so4204884iab.31 for ; Thu, 30 Aug 2012 12:33:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=vmMIoiHPQkFtKJHzlC87D8BHlkCZIejnTYerDh3dwg0=; b=SYhfnoihq9feVkqVXFyzaVVfIyIJnolotKkYjWLN3ODW/j31F6O/9BviWHzd7HBT3N heOYScIjasMuwjLkawQxBkjYLECDSYM/PN5ZEEof2pdcnYBaZaqffhaeKvpPeoY3cAOk MzVG0dYQxwTescTo8BbBiltTipXuxGQbd0KVcBqWM8lHY61lB924Vkq1Bxr/Xn6t+bs2 DwBdkyMO9ur/V1qUqqVJfxxvW4GfYVx6og3c5XgKbNMPNSuT0cMrlboYG4alxRv/uO/r WRT8yZaLCCEkbjT6pY+KvDLpkw1hNcQVUelCY4o5+Yv8N8jQM3gdB8yUFuPJ5hVkiW8L FbZw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=vmMIoiHPQkFtKJHzlC87D8BHlkCZIejnTYerDh3dwg0=; b=UfhKNCAwzQEhVPtEwQebrlNl8hkSv/kztAhRe6VfHPZF62bv+E427zF2b7D2KmA7/K VCaXF/fkLULdiqYIFs1OmdEti0Oa4Y9nqHsooIe3OgJOJut6GJNoxYtNepKO8OgAlkU/ Q97DR+OIAKqxzBgK/xTa94UZH/V2z/4ktB66kJeEK6txJY0ELd7ij0mFNtCMBZQ1XRAI RyRpkv8KSy6BbdqlVhJjG12Yhe+bZw1MslW/vQ6f31uT+7sbJ5tiXXspRdCEs2vtdVgW rHQ9SSeE4RbjwOsQqnlcDZ0JB5Rpht2cPh5ZEqiTsSQrKB5yBpZvPnLdj2uo2GKQWCg4 PuEw== Received: by 10.50.193.201 with SMTP id hq9mr2023936igc.48.1346355181414; Thu, 30 Aug 2012 12:33:01 -0700 (PDT) Received: by 10.50.193.201 with SMTP id hq9mr2023916igc.48.1346355181193; Thu, 30 Aug 2012 12:33:01 -0700 (PDT) MIME-Version: 1.0 Received: by 10.50.237.67 with HTTP; Thu, 30 Aug 2012 12:32:20 -0700 (PDT) In-Reply-To: References: <812700A304640D4292205D5E83FC59E1061C211D@p-embx01-eq.jnpr.net> <3512BB31280C39448A9880F61DD54CEB09C07E@xmb-aln-x09.cisco.com> From: Edward Crabbe Date: Thu, 30 Aug 2012 12:32:20 -0700 Message-ID: To: Alia Atlas Content-Type: multipart/alternative; boundary=14dae9340f3751084a04c880beba X-System-Of-Record: true X-Gm-Message-State: ALoCoQmNoz0tQpAqmE/nOVmS0hfKgXM8Cu+RLDDThjCZbUhsDTTT+8qh6/x1fq8TXpXjbDlNK6KPLP8y1OWFMlknWOWeG9M9YoMhct5jWO6FjS+TxNdvgRn5AEo5old29R57bfLC9NdtUge2wUkmUGY1OqIBnzAKzh8wZbjnnKLIPlkjFVgArGT8PoxvTiTOsHkrHtFEMZze Cc: "UTTARO, JAMES" , "Dutta, Pranjal K \(Pranjal\)" , "Shah, Himanshu" , "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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Aug 2012 19:33:06 -0000 --14dae9340f3751084a04c880beba Content-Type: text/plain; charset=ISO-8859-1 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 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 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 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) > >> 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 > > > > > --14dae9340f3751084a04c880beba Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable W/r/t liveness monitoring, neighbor discovery etc: yep, of course. =A0=A0^_= ^ =A0
As someone who runs centralized te, I can tell you that in some e= nvironments / for some deployment types centralized spf works just fine. = =A0 =A0

On Thu, Aug 30, 2012 at 12:1= 0 PM, Alia Atlas <akatlas@gmail.com> 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. =A0 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 <edc@google.com> 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 <akatlas@gmail.com> wrote:
>>
>> I haven't seen a good description of what is intended or desir= ed by
>> moving the SPF functionality to a centralized location. =A0Clearly= such
>> centralization can have a very bad impact on convergence - which i= s a
>> strong motivator for simultaneously computing fast-reroute
>> alternatives (with guaranteed coverage ala MRT) and installing bot= h.
>>
>> 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<= br> >> needed.
>>
>> Alia
>>
>> On Thu, Aug 16, 2012 at 12:14 PM, Dutta, Pranjal K (Pranjal)
>> <pranjal.du= tta@alcatel-lucent.com> wrote:
>> > "LSDB (I saw an email which talks about reducing IGP to = link
>> >> distribution protocol and running SPF in centralized netw= ork
>> >> controller)"
>> >
>> > I have seen discussions in the past on this and in fact I did= n't get
>> > precisely what is meant. If anybody in the list could brief v= ery
>> > precisely that would help a lot.
>> >
>> > Here is my understanding - the routers would do LSA/LSP flood= ing for
>> > OSPF/ISIS as it is done today. So routers would build neighbo= ring
>> > 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&quo= t;) 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 (th= ru 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 perfor= mance 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 ap= plication,
>> > the computing power in each router is not uniform. To be real= istic, I have
>> > some concerns on how much "real-timeness" we could = achieve between
>> > application and controllers on such proposals, esp. when scal= ing numbers are
>> > high. This leads to higher time lag on inconsistency between = application SPF
>> > compute and FIB update. It's almost like the classic &quo= t;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 th= at persists
>> > longer.
>> >
>> > IGPs may be deployed in very dynamic environments where tight= coupling
>> > is desirable between SPF compute and FIB update. In scaled en= vironments the
>> > issue is less about SPF compute time and is more about synchr= onizing 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
>
>

--14dae9340f3751084a04c880beba-- Return-Path: 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 80C4821F8598 for ; Thu, 30 Aug 2012 12:10:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.961 X-Spam-Level: X-Spam-Status: No, score=-2.961 tagged_above=-999 required=5 tests=[AWL=-0.362, BAYES_00=-2.599] 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 XXLyvTmD3gSi for ; Thu, 30 Aug 2012 12:10:31 -0700 (PDT) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id 88B5521F84B5 for ; Thu, 30 Aug 2012 12:10:31 -0700 (PDT) Received: by ieak13 with SMTP id k13so1205792iea.31 for ; Thu, 30 Aug 2012 12:10:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=iAEyGPzBqeFedgIIGzoTIRbmTULWyjkq9c416p5BqNY=; b=Mpid8F26IDH4vWUQnBNZu1d+SMuHxBimle9KY3e1g88qhcvcCio1looDGtzJkSKa8U Eg0FKpTgirA3OBXMDJWFyCTh4olQ1cBA+rkKAl/KZSVCbGYCKKv8ICVrNvW/CFCOCmoY 74NVfdAgzC5frU7Sban8Sg0I1+8FTLO2cDLdRe58nAmy3cTylatUPAdFhl2xak8sIULa kWuJmxvT8dMJOY/hPUFwmcSkiOxkMT05hIJlwfG9+YP22ITV0UzG7f3QOgXZIgEzCwwd JrnZkt3dlByNraCj+PVI9TiuJDXJzN9O0dSt5FV8uI6HNkWIo7AO+9GdWR4fN+FqEeQc 0Pyg== MIME-Version: 1.0 Received: by 10.50.213.106 with SMTP id nr10mr1863778igc.58.1346353831143; Thu, 30 Aug 2012 12:10:31 -0700 (PDT) Received: by 10.50.91.135 with HTTP; Thu, 30 Aug 2012 12:10:31 -0700 (PDT) In-Reply-To: References: <812700A304640D4292205D5E83FC59E1061C211D@p-embx01-eq.jnpr.net> <3512BB31280C39448A9880F61DD54CEB09C07E@xmb-aln-x09.cisco.com> Date: Thu, 30 Aug 2012 15:10:31 -0400 Message-ID: From: Alia Atlas To: Edward Crabbe Content-Type: text/plain; charset=ISO-8859-1 Cc: "UTTARO, JAMES" , "Dutta, Pranjal K \(Pranjal\)" , "Shah, Himanshu" , "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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Aug 2012 19:10:32 -0000 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 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 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) >> 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 > > Return-Path: 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 925FD21F8534 for ; Thu, 30 Aug 2012 11:59:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.357 X-Spam-Level: X-Spam-Status: No, score=-102.357 tagged_above=-999 required=5 tests=[AWL=-0.381, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] 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 kKN3dGetHT4d for ; Thu, 30 Aug 2012 11:59:35 -0700 (PDT) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id B67AB21F8532 for ; Thu, 30 Aug 2012 11:59:35 -0700 (PDT) Received: by ieak13 with SMTP id k13so1195720iea.31 for ; Thu, 30 Aug 2012 11:59:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=cLFlryD0kGoP3DGKiF9hJwnZsIq1ehdcKKI0jltqyPs=; b=IGchjmqCRLOWCCTp5Iji8lAZQSrMrepa5+/IgYBwtdbzMbkqYKuDPZQzC8eRRMhQIh Ipvfxr4E1Nc1+1S3hNzSlMEzo314QXC8Syj1x7sdEeG7V2KVziWguBL7mubeMC3ZfXh+ 42H1eNd3YnFVkoe5CAmymn+wP2F39P6XOhEwwyBBy2vjmAhSS3DyFe/iORDBm47af+gy PgDx1GZAQAn7XZxSS0EEXjhoS4KfGk4ZzZmmZP7akeZKprFZfv+z9rmmkvWGkj3dnRcj 1qtaf7/tpWCTAHlMsgykSqiQ4zOsHw6XXmajOY4X0C0z1/cgTDUnj9z/pXuFxVfxOLZ8 p3OA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=cLFlryD0kGoP3DGKiF9hJwnZsIq1ehdcKKI0jltqyPs=; b=hlbtzny+5tenPZWjvB1iLErc8MwaDPSTaJ2dmIsz2XoLe/ju4/BhGodGzQEU7MJVBM bUX77hY50IJSsdwdZQLebQnif1WaClvPOS1ugO1JiBDOV3uMs3Z+z/rroCpIu4iaWj6D 38umrjufn2ZoK4SnH3GbzDBKyI9LIIVzbzNgNhG+ROGOybA7t58EEWP1GSCyNi9YAAGO m7y58q+58NME/HsgEQwEFEZJmbHDDPhzUzYE/z2mA7TQpT7Jo2WBy6I+mLUla3IfFZO0 AWyBBFxpveV/Ato08Fgm34Z7rwXw7Ad4DFeg1KGq8SxL7uDHSv76v53tJx254Z/Vel6G /EQQ== Received: by 10.50.13.200 with SMTP id j8mr1875559igc.48.1346353175170; Thu, 30 Aug 2012 11:59:35 -0700 (PDT) Received: by 10.50.13.200 with SMTP id j8mr1875534igc.48.1346353174986; Thu, 30 Aug 2012 11:59:34 -0700 (PDT) MIME-Version: 1.0 Received: by 10.50.237.67 with HTTP; Thu, 30 Aug 2012 11:58:54 -0700 (PDT) In-Reply-To: References: <812700A304640D4292205D5E83FC59E1061C211D@p-embx01-eq.jnpr.net> <3512BB31280C39448A9880F61DD54CEB09C07E@xmb-aln-x09.cisco.com> From: Edward Crabbe Date: Thu, 30 Aug 2012 11:58:54 -0700 Message-ID: To: Alia Atlas Content-Type: multipart/alternative; boundary=f46d04462d6cbcc14604c88046b0 X-System-Of-Record: true X-Gm-Message-State: ALoCoQnJdg6nAzR2tnJYFzy1S6FhbkxSIsIg65SZKnR0L6i/+hBSMnFiiACPtN7d+FXaE+SYouuidoo8jHc9zB4Pe5dhYoxL+oJE/f/J95pUc/5wQXs9HG5XfgQJCZlJegm5/ROprKOHe0WwivGV6bME64xdU3rFkdhsvqj/nWYMJ+oQ8HtOKL6Rgl8wt48vYJ4LQNdUp2Od Cc: "UTTARO, JAMES" , "Dutta, Pranjal K \(Pranjal\)" , "Shah, Himanshu" , "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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Aug 2012 18:59:36 -0000 --f46d04462d6cbcc14604c88046b0 Content-Type: text/plain; charset=ISO-8859-1 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 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) > 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 > --f46d04462d6cbcc14604c88046b0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Alia;

If there is=A0

a) a mecha= nism for installing routes, pbr or otherwise, which recurse to directly con= nected nexthops
b) a mechanism for gathering topological informatio= n

then you've inherently enabled centralized spf.=A0<= /div>

On Thu, Aug 16, 2012 at= 9:34 AM, Alia Atlas <akatlas@gmail.com> wrote:
I haven't seen a good description of wha= t is intended or desired by
moving the SPF functionality to a centralized location. =A0Clearly 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 comp= utation
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@alcat= el-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 g= et 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 O= SPF/ISIS as it is done today. So routers would build neighboring relationsh= ip/adjacencies to participate in flooding and each router builds its LSDB.<= br> >
> Then the IRS "application" would track LSDB changes and pull= up the "diffs" from each router (thru "controller") wh= enever there is a change. The application would compute SPF on behalf of ea= ch 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 scal= ability numbers in LSDB we are talking about?
>
> The "application" would be running in a high performance ser= ver 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 hav= e some concerns on how much "real-timeness" we could achieve betw= een application and controllers on such proposals, esp. when scaling number= s are high. This leads to higher time lag on inconsistency between applicat= ion SPF compute and FIB update. It's almost like the classic "slow= peering" issues with TCP like protocols - the high performance peer i= s slowed down by low performance peer.
>
> Static route interface is good thing because it is a state that persis= ts longer.
>
> IGPs may be deployed in very dynamic environments where tight coupling= is desirable between SPF compute and FIB update. In scaled environments th= e 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 persi= stency 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

--f46d04462d6cbcc14604c88046b0-- Return-Path: 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 5484221F84F9; Wed, 29 Aug 2012 12:46:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.46 X-Spam-Level: X-Spam-Status: No, score=-7.46 tagged_above=-999 required=5 tests=[AWL=-0.861, 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 EKgk4b2HJ3px; Wed, 29 Aug 2012 12:46:54 -0700 (PDT) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id B08C621F84F2; Wed, 29 Aug 2012 12:46:54 -0700 (PDT) Received: from inbansmailrelay1.in.alcatel-lucent.com (h135-250-11-31.lucent.com [135.250.11.31]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id q7TJko81019480 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 29 Aug 2012 14:46:52 -0500 (CDT) Received: from INBANSXCHHUB03.in.alcatel-lucent.com (inbansxchhub03.in.alcatel-lucent.com [135.250.12.80]) by inbansmailrelay1.in.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id q7TJkm7W031877 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 30 Aug 2012 01:16:48 +0530 Received: from INBANSXCHMBSA3.in.alcatel-lucent.com ([135.250.12.53]) by INBANSXCHHUB03.in.alcatel-lucent.com ([135.250.12.80]) with mapi; Thu, 30 Aug 2012 01:16:47 +0530 From: "Dutta, Pranjal K (Pranjal)" To: Stephane Bortzmeyer , "forces@ietf.org" Date: Thu, 30 Aug 2012 01:16:45 +0530 Thread-Topic: [irs-discuss] New Non-WG Mailing List: irs-discuss -- Interface to The Internet Routing System (IRS) Thread-Index: Ac2EdvQovMF6DegBTteBe7s7RqbWJwBpq4qQ Message-ID: References: <20120727004529.5739.53836.idtracker@ietfa.amsl.com> <20120824160539.GA2134@laperouse.bortzmeyer.org> In-Reply-To: <20120824160539.GA2134@laperouse.bortzmeyer.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 Cc: "tnadeau@juniper.net" , "wardd@cisco.com" , "akatlas@juniper.net" , "irs-discuss@ietf.org" Subject: Re: [irs-discuss] New Non-WG Mailing List: irs-discuss -- Interface to The Internet Routing System (IRS) X-BeenThere: irs-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Aug 2012 19:46:55 -0000 I am not quite sure about this. We find the problem statement of IRS as fol= lows: <> In order to enable applications to have access to and control over information in the Internet's routing system, we need a publically documented interface specification. The interface needs to support real-time, transaction-based interactions using efficient data models and encodings. Furthermore, the interface must support a variety of use cases including those where verified control feed-back loops are needed. The way I understand, it's about building flexible/programmable=20 abstractions into Routing Systems - It's not necessary that entire control = plane is taken away. So I don't see the framework as complete separation=20 of control plane and data plane. The IRS frame work further highlights Bidirectional Interfaces to the Routi= ng System. Thanks, Pranjal -----Original Message----- From: irs-discuss-bounces@ietf.org [mailto:irs-discuss-bounces@ietf.org] On= Behalf Of Stephane Bortzmeyer Sent: Friday, August 24, 2012 9:06 AM To: forces@ietf.org Cc: tnadeau@juniper.net; irs-discuss@ietf.org; akatlas@juniper.net; wardd@c= isco.com Subject: Re: [irs-discuss] New Non-WG Mailing List: irs-discuss -- Interfac= e to The Internet Routing System (IRS) On Thu, Jul 26, 2012 at 05:45:29PM -0700, IETF Secretariat wrote=20 a message of 34 lines which said: > A new IETF non-working group email list has been created. >=20 > List address: irs-discuss@ietf.org > Archive: http://www.ietf.org/mail-archive/web/irs-discuss/ > To subscribe: https://www.ietf.org/mailman/listinfo/irs-discuss It really looks like very close from what the Forces working group have been doing. Can anyone explain why we need to start a new project? _______________________________________________ irs-discuss mailing list irs-discuss@ietf.org https://www.ietf.org/mailman/listinfo/irs-discuss Return-Path: 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 B730F21F861A for ; Mon, 27 Aug 2012 05:39:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.895 X-Spam-Level: X-Spam-Status: No, score=-102.895 tagged_above=-999 required=5 tests=[AWL=0.082, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] 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 Rm1w5UOGIAnM for ; Mon, 27 Aug 2012 05:39:49 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 361B821F8616 for ; Mon, 27 Aug 2012 05:39:49 -0700 (PDT) Received: by obbwc20 with SMTP id wc20so9128506obb.31 for ; Mon, 27 Aug 2012 05:39:48 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=E55zgiJEoYjDjM2oimSkdjAOZnq8gfkTTNi+LTRLWKw=; b=QdM6tt29UyBBJIZ21keYlW81lU6/mZPs88fpgANzH+xI2qdEE5YYUWMYmQ/8Wmhnvc 0E4ORyTTqXIa/gFAbOC7O30cB3VzJrxrajl7vKnaU4g/6PwRPjS6yGWI4zxCCAj6RXaz M3uWDc+kFS8Eu2crYkF6ET2InihaFe3ChY5S1ILwlZQKq8YUzSPa5kxrBlB+JUNEiZqF hd71as3oy/FtNjDRjoUhlP3TkBsc9p2aK3i36+y1NGkNkczrqWLzvslOP5b46SbH8Lz2 dXdYM8lR3aBEZarfpcKxvHYh5qTVx4NZpWwpwl/vwO2VmSp9BIyqsgIZi0xqJrKl6jpe QZDw== Received: by 10.182.78.161 with SMTP id c1mr9769015obx.88.1346071188657; Mon, 27 Aug 2012 05:39:48 -0700 (PDT) MIME-Version: 1.0 Received: by 10.60.97.71 with HTTP; Mon, 27 Aug 2012 05:39:28 -0700 (PDT) In-Reply-To: <001301cd844b$82678b50$8736a1f0$@ndzh.com> References: <20120727004529.5739.53836.idtracker@ietfa.amsl.com> <20120824160539.GA2134@laperouse.bortzmeyer.org> <5037AAAC.7090907@queuefull.net> <728F9B956B2C48439CA9294B1723B1462376A586@dfweml509-mbx.china.huawei.com> <001301cd844b$82678b50$8736a1f0$@ndzh.com> From: Jamal Hadi Salim Date: Mon, 27 Aug 2012 08:39:28 -0400 Message-ID: To: Susan Hares Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQmEWsyOfpYmMRsAPCcsXX23h3p6JgC77AnqPXEiB3BIE9GoVPWE4osFUSqgoje3aR+r+hom Cc: Benson Schliesser , irs-discuss@ietf.org, Susan Hares , Stephane Bortzmeyer , tnadeau@juniper.net, akatlas@juniper.net, wardd@cisco.com, forces@ietf.org Subject: Re: [irs-discuss] [forces] New Non-WG Mailing List: irs-discuss -- Interface to The Internet Routing System (IRS) X-BeenThere: irs-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Aug 2012 12:39:49 -0000 Hi Sue, On Mon, Aug 27, 2012 at 8:00 AM, Susan Hares wrote: > Jamal: > > Can you give an example of how IRS and Forces might interact via this route > socket? > Due to the wide background on the lists (irs & forces) , it would be good to > give an example within a switch or router as context. Just the example i posted from the RFC which demonstrates access to a FIB and nexthop tables. All of that can be delivered with ForCES (given netlink was an input in ForCES design). The semantics to a RIB as opposed to a FIB are different. Example, the credentials are weaker on the FIB aspects (the "protocol" field in the route message). But all that is a model issue i.e ForCES is agnostic of the description. I know you are a guru in this area - so hoping to get some wisdom. Sorry for dragging this discussion into this direction. cheers, jamal Return-Path: 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 E3EA121F8581; Mon, 27 Aug 2012 05:00:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 BbzxF6n2BCw5; Mon, 27 Aug 2012 05:00:20 -0700 (PDT) Received: from hickoryhill-consulting.com (hhc-web.hickoryhill-consulting.com [64.9.205.140]) by ietfa.amsl.com (Postfix) with ESMTP id 2BD6821F853B; Mon, 27 Aug 2012 05:00:19 -0700 (PDT) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=109.166.152.69; Received: from SKH2012HPLT (unverified [109.166.152.69]) by hickoryhill-consulting.com (SurgeMail 5.2a) with ESMTP id 3555818-1945496 for multiple; Mon, 27 Aug 2012 08:00:10 -0400 From: "Susan Hares" To: "'Jamal Hadi Salim'" , "'Susan Hares'" References: <20120727004529.5739.53836.idtracker@ietfa.amsl.com> <20120824160539.GA2134@laperouse.bortzmeyer.org> <5037AAAC.7090907@queuefull.net> <728F9B956B2C48439CA9294B1723B1462376A586@dfweml509-mbx.china.huawei.com> In-Reply-To: Date: Mon, 27 Aug 2012 08:00:08 -0400 Message-ID: <001301cd844b$82678b50$8736a1f0$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHGi/MzPmFUwrwIwNdekcMmC1GPoAK/DDf9AsGrIXUCxWx7uAGHRPGcly0TLGA= Content-Language: en-us X-Authenticated-User: skh@ndzh.com Cc: 'Benson Schliesser' , irs-discuss@ietf.org, 'Stephane Bortzmeyer' , tnadeau@juniper.net, akatlas@juniper.net, wardd@cisco.com, forces@ietf.org Subject: Re: [irs-discuss] [forces] New Non-WG Mailing List: irs-discuss -- Interface to The Internet Routing System (IRS) X-BeenThere: irs-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Aug 2012 12:00:21 -0000 Jamal: Can you give an example of how IRS and Forces might interact via this route socket? Due to the wide background on the lists (irs & forces) , it would be good to give an example within a switch or router as context. Sue -----Original Message----- From: irs-discuss-bounces@ietf.org [mailto:irs-discuss-bounces@ietf.org] On Behalf Of Jamal Hadi Salim Sent: Monday, August 27, 2012 7:42 AM To: Susan Hares Cc: Benson Schliesser; irs-discuss@ietf.org; Stephane Bortzmeyer; tnadeau@juniper.net; akatlas@juniper.net; wardd@cisco.com; forces@ietf.org Subject: Re: [irs-discuss] [forces] New Non-WG Mailing List: irs-discuss -- Interface to The Internet Routing System (IRS) With apologies to Alia, I feel obligated to feed this discussion ;-> On Mon, Aug 27, 2012 at 7:22 AM, Susan Hares wrote: > Benson: > > Forces is looking between the control plane and the data forwarding plane. >The IRS work is focused on contacting between a control program and the routing process on the routing >control plane. > In my view: IRS may provide an API or abstraction that looks like a routing sockets or netlink_route (refer to section 3.1 and 3.2 of RFC 3549), underneath the implementation maybe indeed ForCES. cheers, jamal _______________________________________________ irs-discuss mailing list irs-discuss@ietf.org https://www.ietf.org/mailman/listinfo/irs-discuss Return-Path: 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 F010921F8459 for ; Mon, 27 Aug 2012 04:42:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.89 X-Spam-Level: X-Spam-Status: No, score=-102.89 tagged_above=-999 required=5 tests=[AWL=0.087, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] 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 X-gtGw3yt1xQ for ; Mon, 27 Aug 2012 04:42:54 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id B823A21F8615 for ; Mon, 27 Aug 2012 04:42:49 -0700 (PDT) Received: by obbwc20 with SMTP id wc20so9015180obb.31 for ; Mon, 27 Aug 2012 04:42:49 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=yMC3S+KOgDahPEhjiQl5nRHMCAK9B4fT3A+uxILOk4M=; b=SWAo8z2dN4HCg2gKMy3rAojTA+cBKui1O/K6d/jIFdWBNykHRLXAj9pU3DyvVb033H 8LKSJw0JPEpbhETk3j/0XbptMSQ1ZyMaA9qQe4ShI44C9wQrfrDkFIQ/l+jhq26wjmbX fkivcHEBypXD7j5W2QZReG/UPv/jdfn/5Ip4HA0fAs+fj9EY/gmGAeBmOqhycqh+H11h A8sD/iRquU+9+fKA3wjwyuhRxThZztSuXfm81Ur5q/Qp4UaAOLqA+a7SP9ZSjpzdEuiK 7eOrkV9xTx4oLT2GanA0Qb3AnjhyfYE+qZ/qNy+u/04gHAVigNQCWv1IYuzOQWYdd6A4 PvGA== Received: by 10.182.78.161 with SMTP id c1mr9659456obx.88.1346067769248; Mon, 27 Aug 2012 04:42:49 -0700 (PDT) MIME-Version: 1.0 Received: by 10.60.97.71 with HTTP; Mon, 27 Aug 2012 04:42:28 -0700 (PDT) In-Reply-To: <728F9B956B2C48439CA9294B1723B1462376A586@dfweml509-mbx.china.huawei.com> References: <20120727004529.5739.53836.idtracker@ietfa.amsl.com> <20120824160539.GA2134@laperouse.bortzmeyer.org> <5037AAAC.7090907@queuefull.net> <728F9B956B2C48439CA9294B1723B1462376A586@dfweml509-mbx.china.huawei.com> From: Jamal Hadi Salim Date: Mon, 27 Aug 2012 07:42:28 -0400 Message-ID: To: Susan Hares Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQn3JuN2qQQjHOqgf6Xsw3hvHtfHT1FWQb17QyMRQwNy0uG+PXasj9OWgAHoHiomdTFBxJ8I Cc: Benson Schliesser , "irs-discuss@ietf.org" , Stephane Bortzmeyer , "tnadeau@juniper.net" , "akatlas@juniper.net" , "wardd@cisco.com" , "forces@ietf.org" Subject: Re: [irs-discuss] [forces] New Non-WG Mailing List: irs-discuss -- Interface to The Internet Routing System (IRS) X-BeenThere: irs-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Aug 2012 11:42:55 -0000 With apologies to Alia, I feel obligated to feed this discussion ;-> On Mon, Aug 27, 2012 at 7:22 AM, Susan Hares wrote: > Benson: > > Forces is looking between the control plane and the data forwarding plane. >The IRS work is focused on contacting between a control program and the routing process on the routing >control plane. > In my view: IRS may provide an API or abstraction that looks like a routing sockets or netlink_route (refer to section 3.1 and 3.2 of RFC 3549), underneath the implementation maybe indeed ForCES. cheers, jamal Return-Path: 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 9D55021F8624; Mon, 27 Aug 2012 04:24:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.499 X-Spam-Level: X-Spam-Status: No, score=-5.499 tagged_above=-999 required=5 tests=[AWL=1.100, 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 QNkj4BhsfiUw; Mon, 27 Aug 2012 04:24:50 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id B6B4D21F8581; Mon, 27 Aug 2012 04:24:23 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml202-edg.china.huawei.com) ([172.18.9.243]) by dfwrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath) with ESMTP id APO00627; Mon, 27 Aug 2012 03:24:21 -0800 (PST) Received: from DFWEML405-HUB.china.huawei.com (10.193.5.102) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 27 Aug 2012 04:22:53 -0700 Received: from DFWEML509-MBX.china.huawei.com ([169.254.11.11]) by dfweml405-hub.china.huawei.com ([10.193.5.102]) with mapi id 14.01.0323.003; Mon, 27 Aug 2012 04:22:49 -0700 From: Susan Hares To: Benson Schliesser , Stephane Bortzmeyer Thread-Topic: [irs-discuss] [forces] New Non-WG Mailing List: irs-discuss -- Interface to The Internet Routing System (IRS) Thread-Index: AQHNghTy7lJH0qzQwkS3zfGREDf7b5dthq1A Date: Mon, 27 Aug 2012 11:22:48 +0000 Message-ID: <728F9B956B2C48439CA9294B1723B1462376A586@dfweml509-mbx.china.huawei.com> References: <20120727004529.5739.53836.idtracker@ietfa.amsl.com> <20120824160539.GA2134@laperouse.bortzmeyer.org> <5037AAAC.7090907@queuefull.net> In-Reply-To: <5037AAAC.7090907@queuefull.net> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.212.244.73] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "tnadeau@juniper.net" , "forces@ietf.org" , "akatlas@juniper.net" , "irs-discuss@ietf.org" , "wardd@cisco.com" Subject: Re: [irs-discuss] [forces] New Non-WG Mailing List: irs-discuss -- Interface to The Internet Routing System (IRS) X-BeenThere: irs-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Aug 2012 11:24:50 -0000 Benson: Forces is looking between the control plane and the data forwarding plane. = The IRS work is focused on contacting between a control program and the rou= ting process on the routing control plane. X central controller=20 (IRS Commissioner)=20 |=20 IRS client (Control Plane (CP) - routing process)=20 [routing processes] CP -=20 ---- Forces CE=20 | Forces FE =20 Sue Hares=20 -----Original Message----- From: irs-discuss-bounces@ietf.org [mailto:irs-discuss-bounces@ietf.org] On= Behalf Of Benson Schliesser Sent: Friday, August 24, 2012 9:24 AM To: Stephane Bortzmeyer Cc: tnadeau@juniper.net; wardd@cisco.com; forces@ietf.org; akatlas@juniper.= net; irs-discuss@ietf.org Subject: Re: [irs-discuss] [forces] New Non-WG Mailing List: irs-discuss --= Interface to The Internet Routing System (IRS) Hi, Stephane. On 8/24/12 11:05 AM, Stephane Bortzmeyer wrote: >> A new IETF non-working group email list has been created. >> >> List address: irs-discuss@ietf.org >> Archive: http://www.ietf.org/mail-archive/web/irs-discuss/ >> To subscribe: https://www.ietf.org/mailman/listinfo/irs-discuss > It really looks like very close from what the Forces working group > have been doing. Can anyone explain why we need to start a new > project? At a high level, I think there is a different assumption about where the=20 control-plane resides. In IRS the forwarding and control planes might be=20 co-resident in the router (i.e. not "separated"), and the IRS protocol=20 would be a way of extending limited control over routing state to=20 external applications. If I understand ForCES correctly (which is possibly not the case) then I=20 imagine it could be used in a similar architecture and/or as a protocol=20 layer for IRS. But the first step in the context of IRS is to make a=20 problem statement, understand requirements, etc. Others might have more intelligent comments, which I welcome. :) But=20 please let me know if this perspective helps clarify things, and/or if=20 I'm missing some ideas that I should understand better, etc. Cheers, -Benson _______________________________________________ irs-discuss mailing list irs-discuss@ietf.org https://www.ietf.org/mailman/listinfo/irs-discuss Return-Path: 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 9B01E21F8615 for ; Mon, 27 Aug 2012 04:23:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.882 X-Spam-Level: X-Spam-Status: No, score=-102.882 tagged_above=-999 required=5 tests=[AWL=0.095, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] 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 TNxDznRmTTlB for ; Mon, 27 Aug 2012 04:23:46 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 1B67D21F8581 for ; Mon, 27 Aug 2012 04:23:46 -0700 (PDT) Received: by obbwc20 with SMTP id wc20so8985567obb.31 for ; Mon, 27 Aug 2012 04:23:45 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=xuVV5HOF2w+ayaGmOHkl2f5EkwdlMcDp+23or+dRaZc=; b=Q90129I3s+U/XVsGcjBYn7ZnpqvASoEx2mLYxsQO5ELgzuAWoHTzYQzwFd/FjYDmYk UBm8DPAX+laJviDD4JuYfshX6QM0etKU+gqt4F9JCwN7Od2E1saW8cmx6af/XeUiPT6X TZZBitdkNDFpf76FIcFl8h+MMxcZVun21fCVheNeNY5HmHkeuRDQPJ6QL0pdeYfHm1fm GroVbk2USJc+ENYp/Ou0qZzqdkSRYpB+2js5rZtKeRiJ0JN7EcvzMikWrRumzRR6yN/M 99MEXBO845Q77kcxJfXXjcf8IjnzTZMIWJPM75h65QZaNCVZITzQhO1yD76MuwlYFpuh wSUQ== Received: by 10.182.52.42 with SMTP id q10mr9772846obo.46.1346066625732; Mon, 27 Aug 2012 04:23:45 -0700 (PDT) MIME-Version: 1.0 Received: by 10.60.97.71 with HTTP; Mon, 27 Aug 2012 04:23:25 -0700 (PDT) In-Reply-To: <5037AAAC.7090907@queuefull.net> References: <20120727004529.5739.53836.idtracker@ietfa.amsl.com> <20120824160539.GA2134@laperouse.bortzmeyer.org> <5037AAAC.7090907@queuefull.net> From: Jamal Hadi Salim Date: Mon, 27 Aug 2012 07:23:25 -0400 Message-ID: To: Benson Schliesser Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQnOUackOl19eVtGrhKiTFykmo3NTn2nZe6zeZ6npStmoZkxIc1Yh40qhew+/xSqLTglCyXv Cc: irs-discuss@ietf.org, Stephane Bortzmeyer , tnadeau@juniper.net, akatlas@juniper.net, wardd@cisco.com, forces@ietf.org Subject: Re: [irs-discuss] [forces] New Non-WG Mailing List: irs-discuss -- Interface to The Internet Routing System (IRS) X-BeenThere: irs-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Aug 2012 11:23:46 -0000 On Fri, Aug 24, 2012 at 12:24 PM, Benson Schliesser wrote: > At a high level, I think there is a different assumption about where the > control-plane resides. Clarification on the generic statement above below. >In IRS the forwarding and control planes might be > co-resident in the router (i.e. not "separated"), and the IRS protocol would > be a way of extending limited control over routing state to external > applications. > > If I understand ForCES correctly (which is possibly not the case) then I > imagine it could be used in a similar architecture and/or as a protocol > layer for IRS. But the first step in the context of IRS is to make a problem > statement, understand requirements, etc. > Indeed. Once clarity sets in on the requirements, ForCES may or may not be a good choice. Where i feel obligated to respond is to the comment on your first part. It boxes ForCES into only being useful in a southbound control-datapath separation. We've used it to control a bunch of ethernet switches which have co-resident control/data plane from the vendor. We've used it to configure things that are not packet processing entities - consider this presentation https://www.ietf.org/proceedings/84/slides/slides-84-forces-2.pdf which illustrates how we model a configuration file (nothing to do with a datapath functional block) into an LFB and then proceed to query/set from the CE. cheers, jamal Return-Path: 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 C4A3D21F8517 for ; Sun, 26 Aug 2012 06:18:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.496 X-Spam-Level: X-Spam-Status: No, score=-3.496 tagged_above=-999 required=5 tests=[AWL=0.103, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 lUiycXTgn7qn for ; Sun, 26 Aug 2012 06:18:20 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 38CD921F849C for ; Sun, 26 Aug 2012 06:18:20 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so3933370vbb.31 for ; Sun, 26 Aug 2012 06:18:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=DLx+RoT8/KVrldOYxfaueiYYtfsAG3UplQcFSrEZ1ws=; b=RYnSMxveAV/OCCFNNmD9VehNpNGfaeBGD92M/X92jS8ypcZsN4stoWUQN+Xg4VFsp9 w6gfZUVecn8iowJTNGU8/UcqktIKlVWIVo/+UrRUXeeTRDJo/Tr6xw9rk3GKLFMRq7Xu u+IzLbNhjk4CQpq/XpDYNNcHoSvOXYh6db5LVWX0NocWEeq8I7O9A80hqCl8+o5YA8vj tx3rHnCs/EGf1edcA/fGb5gdvZW38zKBBTjzxsJE31ast7EbzTn+lKuWZDNdOknGcmeV NLQ0V/TTT4DK4Wns0TKBGhfBJcidMJqbetXMuHCQxhdWuY+mLeUDJ/srg6uuvArJZC4T gwKA== MIME-Version: 1.0 Received: by 10.52.20.42 with SMTP id k10mr1880157vde.55.1345987099459; Sun, 26 Aug 2012 06:18:19 -0700 (PDT) Received: by 10.220.55.9 with HTTP; Sun, 26 Aug 2012 06:18:19 -0700 (PDT) Date: Sun, 26 Aug 2012 15:18:19 +0200 Message-ID: From: Abdussalam Baryun To: irs-discuss@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Cc: akatlas@gmail.com Subject: [irs-discuss] draft-ward-irs-framework-00 X-BeenThere: irs-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Aug 2012 13:18:20 -0000 Hi Alia, Reading through to find the definition of IRS within I got confused not sure its relationship with the network interfaces, please advise, Regards Abdussalam Return-Path: 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 9AB5421F8683 for ; Fri, 24 Aug 2012 09:24:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.699 X-Spam-Level: X-Spam-Status: No, score=-3.699 tagged_above=-999 required=5 tests=[AWL=-0.100, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 i7ECFa8FGiNH for ; Fri, 24 Aug 2012 09:24:15 -0700 (PDT) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id 4BAC421F85C3 for ; Fri, 24 Aug 2012 09:24:15 -0700 (PDT) Received: by dadf8 with SMTP id f8so1027452dad.31 for ; Fri, 24 Aug 2012 09:24:15 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding :x-gm-message-state; bh=pr0Aa+VVhR2Uo9/bkCQIrmDgmLoDS9I+14wAmvdADBQ=; b=gAX3zC1eQ0MrHwaet3RLIXQrh/YiNTbcdko0N+o07ngSwa7s6fojIsgOTGD+Fj03Y+ KQUrpNUD7/o5pGi9XU0ObSTst2Ufjn7heDtc2DDGE2q6hf6ZJfTVQgPR28pbpND92TMr mXBkwJEO2YfaaXUfwt6CjFc+8jUQRKciAlTIRRdFhbl5nKL7oN5tgT5REpevU+BuBtgK w17e6bU2u1+AktCgc+H9LEhO21jRHRju1zl8ZIqal4fnUQHDBdh8hfwBpf/5SlY34Jug 7wDiN4YVqCMhMgXqqQ9YKsn0Ihl3JdmNRVa7Gs0Vi1BetJGoXWAPJGaFuz2VMyg/IYpv UKXg== Received: by 10.68.238.74 with SMTP id vi10mr14085439pbc.48.1345825455075; Fri, 24 Aug 2012 09:24:15 -0700 (PDT) Received: from wasteland.local (natint3.juniper.net. [66.129.224.36]) by mx.google.com with ESMTPS id gf3sm8573158pbc.74.2012.08.24.09.24.12 (version=SSLv3 cipher=OTHER); Fri, 24 Aug 2012 09:24:13 -0700 (PDT) Message-ID: <5037AAAC.7090907@queuefull.net> Date: Fri, 24 Aug 2012 11:24:12 -0500 From: Benson Schliesser User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: Stephane Bortzmeyer References: <20120727004529.5739.53836.idtracker@ietfa.amsl.com> <20120824160539.GA2134@laperouse.bortzmeyer.org> In-Reply-To: <20120824160539.GA2134@laperouse.bortzmeyer.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQm2amaa+jXRJLx9TnWdS0Zk9qnXbkYTo+Q3H/0V5Fz0LX/rWenDPPCtPMJFKum5K0xXkUXh Cc: tnadeau@juniper.net, wardd@cisco.com, forces@ietf.org, akatlas@juniper.net, irs-discuss@ietf.org Subject: Re: [irs-discuss] [forces] New Non-WG Mailing List: irs-discuss -- Interface to The Internet Routing System (IRS) X-BeenThere: irs-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Aug 2012 16:24:16 -0000 Hi, Stephane. On 8/24/12 11:05 AM, Stephane Bortzmeyer wrote: >> A new IETF non-working group email list has been created. >> >> List address: irs-discuss@ietf.org >> Archive: http://www.ietf.org/mail-archive/web/irs-discuss/ >> To subscribe: https://www.ietf.org/mailman/listinfo/irs-discuss > It really looks like very close from what the Forces working group > have been doing. Can anyone explain why we need to start a new > project? At a high level, I think there is a different assumption about where the control-plane resides. In IRS the forwarding and control planes might be co-resident in the router (i.e. not "separated"), and the IRS protocol would be a way of extending limited control over routing state to external applications. If I understand ForCES correctly (which is possibly not the case) then I imagine it could be used in a similar architecture and/or as a protocol layer for IRS. But the first step in the context of IRS is to make a problem statement, understand requirements, etc. Others might have more intelligent comments, which I welcome. :) But please let me know if this perspective helps clarify things, and/or if I'm missing some ideas that I should understand better, etc. Cheers, -Benson Return-Path: 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 98DFE21F86B2; Fri, 24 Aug 2012 09:12:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.446 X-Spam-Level: X-Spam-Status: No, score=-101.446 tagged_above=-999 required=5 tests=[AWL=1.154, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] 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 kkIOPkkKdZnz; Fri, 24 Aug 2012 09:12:20 -0700 (PDT) Received: from mail.bortzmeyer.org (aetius.bortzmeyer.org [IPv6:2001:4b98:dc0:41:216:3eff:fece:1902]) by ietfa.amsl.com (Postfix) with ESMTP id C53B921F8686; Fri, 24 Aug 2012 09:12:19 -0700 (PDT) Received: by mail.bortzmeyer.org (Postfix, from userid 10) id 4D8F63BDD2; Fri, 24 Aug 2012 16:12:18 +0000 (UTC) Received: by tyrion (Postfix, from userid 1000) id 1A199F0066A; Fri, 24 Aug 2012 18:05:40 +0200 (CEST) Date: Fri, 24 Aug 2012 18:05:40 +0200 From: Stephane Bortzmeyer To: forces@ietf.org Message-ID: <20120824160539.GA2134@laperouse.bortzmeyer.org> References: <20120727004529.5739.53836.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20120727004529.5739.53836.idtracker@ietfa.amsl.com> X-Transport: UUCP rules X-Operating-System: Ubuntu 12.04 (precise) User-Agent: Mutt/1.5.21 (2010-09-15) X-Mailman-Approved-At: Mon, 27 Aug 2012 10:10:54 -0700 Cc: tnadeau@juniper.net, irs-discuss@ietf.org, akatlas@juniper.net, wardd@cisco.com Subject: Re: [irs-discuss] New Non-WG Mailing List: irs-discuss -- Interface to The Internet Routing System (IRS) X-BeenThere: irs-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Aug 2012 16:12:20 -0000 On Thu, Jul 26, 2012 at 05:45:29PM -0700, IETF Secretariat wrote a message of 34 lines which said: > A new IETF non-working group email list has been created. > > List address: irs-discuss@ietf.org > Archive: http://www.ietf.org/mail-archive/web/irs-discuss/ > To subscribe: https://www.ietf.org/mailman/listinfo/irs-discuss It really looks like very close from what the Forces working group have been doing. Can anyone explain why we need to start a new project? Return-Path: 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 A3DBC21F8522 for ; Sat, 18 Aug 2012 04:12:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.751 X-Spam-Level: X-Spam-Status: No, score=-0.751 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, MIME_QP_LONG_LINE=1.396, SARE_SUB_ENC_UTF8=0.152] 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 KQAf5OaEBAlM for ; Sat, 18 Aug 2012 04:12:30 -0700 (PDT) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id B8ABD21F8498 for ; Sat, 18 Aug 2012 04:12:26 -0700 (PDT) Received: from [192.168.1.59] (static-72-71-250-38.cncdnh.fast04.myfairpoint.net [72.71.250.38]) by lucidvision.com (Postfix) with ESMTP id 290292256693; Sat, 18 Aug 2012 07:12:25 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1485\)) From: Thomas Nadeau In-Reply-To: <000501cd7cad$9073ff80$b15bfe80$@ndzh.com> Date: Sat, 18 Aug 2012 07:12:24 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <812700A304640D4292205D5E83FC59E1061C211D@p-embx01-eq.jnpr.net> <3512BB31280C39448A9880F61DD54CEB09C07E@xmb-aln-x09.cisco.com> <1E6B6081-2A02-4486-BE7D-3A0E92E0B7B4@lucidvision.com> <000501cd7cad$9073 ff80$b15bfe80$@ndzh.com> To: "Susan Hares" X-Mailer: Apple Mail (2.1485) Cc: 'Mach Chen' , irs-discuss@ietf.org, "'Shah, Himanshu'" , 'Alia Atlas' , "'UTTARO, JAMES'" , "'Dutta, Pranjal K \(Pranjal\)'" Subject: Re: [irs-discuss] =?utf-8?b?562U5aSNOiDnrZTlpI06ICBJUlMgY29tbWVudHM=?= X-BeenThere: irs-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Aug 2012 11:12:30 -0000 On Aug 17, 2012:3:21 PM, at 3:21 PM, "Susan Hares" = wrote: > Tom and Mach:=20 >=20 > IMHO - both cases are seen in today's internet.=20 >=20 > +1 to Tom - Current cases such as VPNs (monitoring & interface adding) = - is a current case where direct interaction may be nice >=20 > +1 to Mach - Operational cases exist where Applications orchestrate = (Applications choose DC with open VM systems) and then talk to the IRS = Client who commissions individual node IRS agents to perform tasks. >=20 > IMHO the IRS system is a good tool to get interact with routing = system. Unlike the generic SNMP hammer, it may be a Swiss army knife = tool with multiple interface methods into the system.=20 That is precisely one of its big (potential) advantages.=20 --Tom >=20 > What do you think? > Sue =20 >=20 > -----Original Message----- > From: irs-discuss-bounces@ietf.org = [mailto:irs-discuss-bounces@ietf.org] On Behalf Of Thomas Nadeau > Sent: Friday, August 17, 2012 10:09 AM > To: Mach Chen > Cc: irs-discuss@ietf.org; UTTARO, JAMES; Dutta, Pranjal K (Pranjal); = Shah, Himanshu; Alia Atlas > Subject: Re: [irs-discuss] =E7=AD=94=E5=A4=8D: =E7=AD=94=E5=A4=8D: IRS = comments >=20 >=20 > On Aug 16, 2012, at 10:38 PM, Mach Chen wrote: >=20 >> Hi Alia, >>=20 >> It's great to define uniform interfaces to the applications, but I am = not sure whether the IRS interfaces could be directly used by the = applications, in the IRS framework, the applications talk to the IRS = agents, IMHO, the IRS agent (it may be the controller or orchestrator = role from the SDN point of view, and the IRS interfaces are the = southbound interfaces ) should shield the variety of the IRS interfaces. = =20 >=20 > The idea is definitely to allow direct use of the interface of that is = operationally desired. >=20 > Tom=20 >=20 >> And I agree that we should currently focus on the use cases and then = define a clear scope. Here is a rough SDN related use case draft = (http://tools.ietf.org/html/draft-mm-sdn-vc-vn-on-demand-use-case-01), I = am not sure this is related to IRS.=20 >>=20 >> Best regards, >> Mach >>=20 >>> -----=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB=B6----- >>> =E5=8F=91=E4=BB=B6=E4=BA=BA: Alia Atlas [mailto:akatlas@gmail.com] >>> =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2012=E5=B9=B48=E6=9C=8817=E6=97=A5= 10:13 >>> =E6=94=B6=E4=BB=B6=E4=BA=BA: Mach Chen >>> =E6=8A=84=E9=80=81: Shah, Himanshu; UTTARO, JAMES; Dutta, Pranjal K = (Pranjal);=20 >>> irs-discuss@ietf.org >>> =E4=B8=BB=E9=A2=98: Re: =E7=AD=94=E5=A4=8D: [irs-discuss] IRS = comments >>>=20 >>> Hi Mach, >>>=20 >>> Right - that is one reason why I'm not sure that a CSPF computation=20= >>> piece is needed for the RSVP sub-interface. On the other side,=20 >>> there's benefit to not requiring an application to understand too=20 >>> many different protocols. >>>=20 >>> We need to discuss what scope makes sense for the sub-interfaces. I=20= >>> think the use-cases will drive this. >>>=20 >>> Alia >>>=20 >>> On Thu, Aug 16, 2012 at 10:06 PM, Mach Chen >>> wrote: >>>> Hi Alia, >>>>=20 >>>> I am a little confused, the said RSVP sub-interface (on-demand CSPF=20= >>>> interface) >>> seems what exactly PCEP does today. My understanding of IRS is that=20= >>> it may be complementary on topology discovery. >>>>=20 >>>> Best regards, >>>> Mach >>>>=20 >>>>> -----=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB=B6----- >>>>> =E5=8F=91=E4=BB=B6=E4=BA=BA: irs-discuss-bounces@ietf.org=20 >>>>> [mailto:irs-discuss-bounces@ietf.org] >>> =E4=BB=A3 >>>>> =E8=A1=A8 Alia Atlas >>>>> =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2012=E5=B9=B48=E6=9C=8817=E6=97= =A5 9:45 >>>>> =E6=94=B6=E4=BB=B6=E4=BA=BA: Shah, Himanshu >>>>> =E6=8A=84=E9=80=81: UTTARO, JAMES; Dutta, Pranjal K (Pranjal); = irs-discuss@ietf.org >>>>> =E4=B8=BB=E9=A2=98: Re: [irs-discuss] IRS comments >>>>>=20 >>>>> I'm not entirely clear on the model or question you are asking. = An=20 >>>>> application could learn topology via IRS to the appropriate IRS=20 >>>>> agents, do CSPF computations, and support a signaling/CSPF-like=20 >>>>> sub-interface (if we define such for IRS) as an IRS agent. = Another=20 >>>>> application could query the first for the CSPF results and then = use=20 >>>>> IRS to trigger signaling on the appropriate device. >>>>>=20 >>>>> I'm not sure if it makes sense to have an IRS sub-interface that=20= >>>>> requests CSPF computation, but it might come as part of an RSVP=20 >>>>> sub-interface to trigger signaling. We'll have to see about=20 >>>>> use-cases. >>>>>=20 >>>>> I don't see a strong motivation to duplicate existing work. >>>>>=20 >>>>> Alia >>>>>=20 >>>>> On Thu, Aug 16, 2012 at 2:46 PM, Shah, Himanshu >>> wrote: >>>>>> I was wondering if PCE and IRS could have overlapping = functionality. >>>>>>=20 >>>>>> Meaning, can an IRS interface user at both ends (node and=20 >>>>>> controller) be a >>>>> non-PCE entity and perform >>>>>> the same service as what PCE does? >>>>>>=20 >>>>>> It seems like you are saying that could work co-operatively... >>>>>>=20 >>>>>> Thanks, >>>>>> himanshu >>>>>=20 >>>>> =3D=3Dsnip=3D=3D=3D >>>>> _______________________________________________ >>>>> 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 > _______________________________________________ > irs-discuss mailing list > irs-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/irs-discuss >=20 >=20 Return-Path: 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 2ABA111E80E1 for ; Fri, 17 Aug 2012 12:52:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.443 X-Spam-Level: X-Spam-Status: No, score=-1.443 tagged_above=-999 required=5 tests=[AWL=-0.704, BAYES_20=-0.74, HTML_MESSAGE=0.001] 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 rdyoV2nY160q for ; Fri, 17 Aug 2012 12:52:26 -0700 (PDT) Received: from hickoryhill-consulting.com (hhc-web.hickoryhill-consulting.com [64.9.205.140]) by ietfa.amsl.com (Postfix) with ESMTP id A610811E80D1 for ; Fri, 17 Aug 2012 12:52:25 -0700 (PDT) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=96.237.177.132; Received: from SKH2012HPLT (unverified [96.237.177.132]) by hickoryhill-consulting.com (SurgeMail 5.2a) with ESMTP id 3535893-1945496 for multiple; Fri, 17 Aug 2012 15:52:23 -0400 From: "Susan Hares" To: Date: Fri, 17 Aug 2012 15:52:24 -0400 Message-ID: <001801cd7cb1$d29e7cb0$77db7610$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0019_01CD7C90.4B8F4DB0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac18rgo0jCk8d1pIRXyyTa7sm/2qSg== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Cc: Thomas Nadeau , Alia Atlas , irs-discuss@ietf.org Subject: Re: [irs-discuss] "Interface to The Internet Routing System \(IRS\)" X-BeenThere: irs-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Aug 2012 19:52:27 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0019_01CD7C90.4B8F4DB0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Gert: You've hit on many good points. a. +1 - You are right. NM has become a non-specific term. In history, ISO defined NM as specific features (configuration, fault, performance, and others). b. +1 - roll-forward/roll-back is what is necessary. IRS protocol, DB and policy must allow. c. Sorry - I see from your 2nd message that I misunderstood your point. Sue -------- Susan, Q1: Which NM are you implying here? A: traditionally a functional view on the subject has been used. Think about it. Does the fact that a piece of Software monitors a device justify to name it 'Network Management '? Is CLI a Network Management? Q2: Configuration included download plus transactional (roll forward/roll-back). A: that's what's required to keep two persistent databases aligned. A3: Your description does not match the current status of the IGPs or BGP implementations. Q3: what let you to that conclusion? Those are CP protocols. Q4: Where do you place the Graceful-Restart or Hitless Restart or High availability work? Do you place this in a PCE or a stateful PCE? A4: IETF work is always placed between 2 or more entities because we deal with protocols. ------=_NextPart_000_0019_01CD7C90.4B8F4DB0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 
Gert:
 
You’ve hit on many good points. =

 
a.  +1 =
– You are right. NM has become a non-specific term. In history, =
ISO defined NM as specific features (configuration, fault, performance, =
and others). 
b.  +1 =
– roll-forward/roll-back is what is necessary.  IRS protocol, =
DB and policy must allow.
c.  =
Sorry – I see from your 2nd =
message that I misunderstood your point. =

 
 
=

Sue
 
--------
Susan,
 
Q1=
: Which NM are you implying here? 
A: traditionally =
a functional view on the subject has been used. Think about it. Does the =
fact that a piece of Software monitors a device justify to name it 'Network Management'? Is CLI a Network =
Management?
 
Q2: =
Configuration included download plus transactional (roll =
forward/roll-back). 
A: that's what's required to =
keep two persistent databases =
aligned.
 
A3: Your =
description does not match the current status of the IGPs or BGP =
implementations. 
Q3: what let you to that =
conclusion?
Those are CP =
protocols.
 
Q4: Where do =
you place the Graceful-Restart or Hitless Restart or High availability work? Do you place this =
in a PCE or a stateful PCE? 
A4: =
IETF work is always placed between 2 or more entities because we deal =
with protocols.
------=_NextPart_000_0019_01CD7C90.4B8F4DB0-- Return-Path: 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 9A4C421F8523 for ; Fri, 17 Aug 2012 12:22:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.147 X-Spam-Level: X-Spam-Status: No, score=-2.147 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, SARE_SUB_ENC_UTF8=0.152] 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 wNZMAZe+gZYB for ; Fri, 17 Aug 2012 12:22:06 -0700 (PDT) Received: from hickoryhill-consulting.com (hhc-web.hickoryhill-consulting.com [64.9.205.140]) by ietfa.amsl.com (Postfix) with ESMTP id C2BAF21F84FA for ; Fri, 17 Aug 2012 12:22:05 -0700 (PDT) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=96.237.177.132; Received: from SKH2012HPLT (unverified [96.237.177.132]) by hickoryhill-consulting.com (SurgeMail 5.2a) with ESMTP id 3535793-1945496 for multiple; Fri, 17 Aug 2012 15:21:54 -0400 From: "Susan Hares" To: "'Thomas Nadeau'" , "'Mach Chen'" References: <812700A304640D4292205D5E83FC59E1061C211D@p-embx01-eq.jnpr.net> <3512BB31280C39448A9880F61DD54CEB09C07E@xmb-aln-x09.cisco.com> <1E6B6081-2A02-4486-BE7D-3A0E92E0B7B4@lucidvision.com> In-Reply-To: <1E6B6081-2A02-4486-BE7D-3A0E92E0B7B4@lucidvision.com> Date: Fri, 17 Aug 2012 15:21:55 -0400 Message-ID: <000501cd7cad$9073ff80$b15bfe80$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGOoLWWEVfGTftSwCkpK4QqzsiakgE4EkiaATU1YakA7fGK9gMVQSc9Ajan2cECXEGcqgEo1UMVAhLBp1cCQP8w0QHCeVnGAqEO4ZACzDtuAAHMMcQkAc+OP4gBmcCZAwH/VLsmAkTzyG4Btb1+cAJhsJDMAbQ/n8kBSVBUVAHQr5rSAfVtKoQCvmYwgQEzL9rXAx5kUhMCWCgc2JYwsW2g Content-Language: en-us X-Authenticated-User: skh@ndzh.com Cc: 'Alia Atlas' , "'UTTARO, JAMES'" , "'Dutta, Pranjal K \(Pranjal\)'" , "'Shah, Himanshu'" , irs-discuss@ietf.org Subject: Re: [irs-discuss] =?utf-8?b?562U5aSNOiDnrZTlpI06ICBJUlMgY29tbWVudHM=?= X-BeenThere: irs-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Aug 2012 19:22:06 -0000 Tom and Mach:=20 IMHO - both cases are seen in today's internet.=20 +1 to Tom - Current cases such as VPNs (monitoring & interface adding) - = is a current case where direct interaction may be nice +1 to Mach - Operational cases exist where Applications orchestrate = (Applications choose DC with open VM systems) and then talk to the IRS = Client who commissions individual node IRS agents to perform tasks. IMHO the IRS system is a good tool to get interact with routing system. = Unlike the generic SNMP hammer, it may be a Swiss army knife tool with = multiple interface methods into the system.=20 What do you think? Sue =20 -----Original Message----- From: irs-discuss-bounces@ietf.org [mailto:irs-discuss-bounces@ietf.org] = On Behalf Of Thomas Nadeau Sent: Friday, August 17, 2012 10:09 AM To: Mach Chen Cc: irs-discuss@ietf.org; UTTARO, JAMES; Dutta, Pranjal K (Pranjal); = Shah, Himanshu; Alia Atlas Subject: Re: [irs-discuss] =E7=AD=94=E5=A4=8D: =E7=AD=94=E5=A4=8D: IRS = comments On Aug 16, 2012, at 10:38 PM, Mach Chen wrote: > Hi Alia, >=20 > It's great to define uniform interfaces to the applications, but I am = not sure whether the IRS interfaces could be directly used by the = applications, in the IRS framework, the applications talk to the IRS = agents, IMHO, the IRS agent (it may be the controller or orchestrator = role from the SDN point of view, and the IRS interfaces are the = southbound interfaces ) should shield the variety of the IRS interfaces. = =20 The idea is definitely to allow direct use of the interface of that is = operationally desired. Tom=20 > And I agree that we should currently focus on the use cases and then = define a clear scope. Here is a rough SDN related use case draft = (http://tools.ietf.org/html/draft-mm-sdn-vc-vn-on-demand-use-case-01), I = am not sure this is related to IRS.=20 >=20 > Best regards, > Mach >=20 >> -----=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB=B6----- >> =E5=8F=91=E4=BB=B6=E4=BA=BA: Alia Atlas [mailto:akatlas@gmail.com] >> =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: = 2012=E5=B9=B48=E6=9C=8817=E6=97=A5 10:13 >> =E6=94=B6=E4=BB=B6=E4=BA=BA: Mach Chen >> =E6=8A=84=E9=80=81: Shah, Himanshu; UTTARO, JAMES; Dutta, Pranjal K = (Pranjal);=20 >> irs-discuss@ietf.org >> =E4=B8=BB=E9=A2=98: Re: =E7=AD=94=E5=A4=8D: [irs-discuss] IRS = comments >>=20 >> Hi Mach, >>=20 >> Right - that is one reason why I'm not sure that a CSPF computation=20 >> piece is needed for the RSVP sub-interface. On the other side,=20 >> there's benefit to not requiring an application to understand too=20 >> many different protocols. >>=20 >> We need to discuss what scope makes sense for the sub-interfaces. I=20 >> think the use-cases will drive this. >>=20 >> Alia >>=20 >> On Thu, Aug 16, 2012 at 10:06 PM, Mach Chen >> wrote: >>> Hi Alia, >>>=20 >>> I am a little confused, the said RSVP sub-interface (on-demand CSPF=20 >>> interface) >> seems what exactly PCEP does today. My understanding of IRS is that=20 >> it may be complementary on topology discovery. >>>=20 >>> Best regards, >>> Mach >>>=20 >>>> -----=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB=B6----- >>>> =E5=8F=91=E4=BB=B6=E4=BA=BA: irs-discuss-bounces@ietf.org=20 >>>> [mailto:irs-discuss-bounces@ietf.org] >> =E4=BB=A3 >>>> =E8=A1=A8 Alia Atlas >>>> =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: = 2012=E5=B9=B48=E6=9C=8817=E6=97=A5 9:45 >>>> =E6=94=B6=E4=BB=B6=E4=BA=BA: Shah, Himanshu >>>> =E6=8A=84=E9=80=81: UTTARO, JAMES; Dutta, Pranjal K (Pranjal); = irs-discuss@ietf.org >>>> =E4=B8=BB=E9=A2=98: Re: [irs-discuss] IRS comments >>>>=20 >>>> I'm not entirely clear on the model or question you are asking. An = >>>> application could learn topology via IRS to the appropriate IRS=20 >>>> agents, do CSPF computations, and support a signaling/CSPF-like=20 >>>> sub-interface (if we define such for IRS) as an IRS agent. Another = >>>> application could query the first for the CSPF results and then use = >>>> IRS to trigger signaling on the appropriate device. >>>>=20 >>>> I'm not sure if it makes sense to have an IRS sub-interface that=20 >>>> requests CSPF computation, but it might come as part of an RSVP=20 >>>> sub-interface to trigger signaling. We'll have to see about=20 >>>> use-cases. >>>>=20 >>>> I don't see a strong motivation to duplicate existing work. >>>>=20 >>>> Alia >>>>=20 >>>> On Thu, Aug 16, 2012 at 2:46 PM, Shah, Himanshu >> wrote: >>>>> I was wondering if PCE and IRS could have overlapping = functionality. >>>>>=20 >>>>> Meaning, can an IRS interface user at both ends (node and=20 >>>>> controller) be a >>>> non-PCE entity and perform >>>>> the same service as what PCE does? >>>>>=20 >>>>> It seems like you are saying that could work co-operatively... >>>>>=20 >>>>> Thanks, >>>>> himanshu >>>>=20 >>>> =3D=3Dsnip=3D=3D=3D >>>> _______________________________________________ >>>> 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 _______________________________________________ irs-discuss mailing list irs-discuss@ietf.org https://www.ietf.org/mailman/listinfo/irs-discuss Return-Path: 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 3655311E80D5 for ; Fri, 17 Aug 2012 09:30:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.537 X-Spam-Level: X-Spam-Status: No, score=-6.537 tagged_above=-999 required=5 tests=[AWL=0.062, 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 2JxYPuBG8G1T for ; Fri, 17 Aug 2012 09:30:41 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id 6CD3811E80A5 for ; Fri, 17 Aug 2012 09:30:41 -0700 (PDT) Received: from eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id q7HGTU1F026622; Fri, 17 Aug 2012 11:31:12 -0500 Received: from EUSAACMS0702.eamcs.ericsson.se ([169.254.1.190]) by eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) with mapi; Fri, 17 Aug 2012 12:30:19 -0400 From: Acee Lindem To: Alia Atlas Date: Fri, 17 Aug 2012 12:30:17 -0400 Thread-Topic: [irs-discuss] IRS comments Thread-Index: Ac18lZdFnyPgkv6JSu6onZ34W/oIRQ== Message-ID: <72DD6F70-9432-41BF-820B-AA207279AB93@ericsson.com> References: <812700A304640D4292205D5E83FC59E1061C211D@p-embx01-eq.jnpr.net> <3512BB31280C39448A9880F61DD54CEB09C07E@xmb-aln-x09.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/signed; boundary="Apple-Mail-27--305886237"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 Cc: "Shah, Himanshu" , "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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Aug 2012 16:30:42 -0000 --Apple-Mail-27--305886237 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Aug 16, 2012, at 12:23 PM, Alia Atlas wrote: > ACLs as in for BGP policy I would hope IRS will provision BGP policy in 2012 with a constructs = more powerful than ACLs. Perhaps, Routing Policy Specification Language = (RFC 2622) or something similar. Acee=20 > or as in policy-based-routing/firewalls? > Both would be likely needed. >=20 > ifMIB info? I'm not sure what aspects you are poking at. In terms of > reading information for the topology export, yes... In terms of > writing state, I don't think so... >=20 > Alia >=20 > On Thu, Aug 16, 2012 at 10:42 AM, Shah, Himanshu = wrote: >> This is precisely the answer I was looking for. >> It's a domain issue. This is how IRS distinguishes itself from = OpenFlow/ForCES/GSMP etc etc >>=20 >> Understand the reasoning but was hoping that IRS would provide one = uniform interface - top to bottom, >> so implementers do not have to deal with supporting multiple = utilities. >>=20 >> What about ACL (Access Control List), ifMIB specific info etc. = (trying to get sense on the lowest layer that IRS will cover) >>=20 >> Thanks, >> himanshu >>=20 >>=20 >> -----Original Message----- >> From: Alia Atlas [mailto:akatlas@gmail.com] >> Sent: Wednesday, August 15, 2012 10:57 PM >> To: Shah, Himanshu >> Cc: UTTARO, JAMES; irs-discuss@ietf.org >> Subject: Re: [irs-discuss] IRS comments >>=20 >> What is the benefit of allowing access to the FIB vs. the associated = complexity? >> If something wants to inject state directly into the forwarding = plane, isn't that what ForCES or OpenFlow is for? >>=20 >> Why get into low-level assembly when we've got a C-equiv? (Still not = a higher level language that apps might speak with associated = abstractions, but closer). >>=20 >> Alia >=20 > ---snip--- > _______________________________________________ > irs-discuss mailing list > irs-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/irs-discuss --Apple-Mail-27--305886237 Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIM8jCCBDQw ggMcoAMCAQICECFWwVQHDV12M/Sr0yNv0sYwDQYJKoZIhvcNAQEFBQAwOTERMA8GA1UECgwIRXJp Y3Nzb24xJDAiBgNVBAMMG0VyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EwMTAeFw0xMDEwMDEyMDA0 NTlaFw0xMzEwMDEyMDA0NDhaMG8xETAPBgNVBAoMCEVyaWNzc29uMR8wHQYDVQQDDBZBY2VlIExp bmRlbSBMaW5kZW0gSUlJMRAwDgYDVQQFEwdlYWxmbGluMScwJQYJKoZIhvcNAQkBFhhhY2VlLmxp bmRlbUBlcmljc3Nvbi5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAI/Dc9ALiZuBMyuv bsc3eBxjXZpMi45Z0vzsUQZTJGTBeY7p9JsdzXC9J1uMisBxYVi39R3KJo6I4hXVp9wrA1rxh4AE bnP1+Gxfpj33uWEFYbBnVAJkIWYWF7CYTn8Zm/yd13vPXtuGA6ESeLnnJafwC9Y0YwUQ+4HX7PNv uauVAgMBAAGjggGEMIIBgDCBwAYDVR0fBIG4MIG1MIGyoIGvoIGshjdodHRwOi8vY3JsLnRydXN0 LnRlbGlhLmNvbS9Fcmljc3Nvbk5MSW5kaXZpZHVhbENBMDEuY3JshnFsZGFwOi8vbGRhcC50cnVz dC50ZWxpYS5jb20vY249RXJpY3Nzb24lMjBOTCUyMEluZGl2aWR1YWwlMjBDQTAxLG89RXJpY3Nz b24/Y2VydGlmaWNhdGVyZXZvY2F0aW9ubGlzdDtiaW5hcnk/YmFzZTAjBgNVHREEHDAagRhhY2Vl LmxpbmRlbUBlcmljc3Nvbi5jb20wRgYDVR0gBD8wPTA7BgYqhXBrAQEwMTAvBggrBgEFBQcCARYj aHR0cDovL3d3dy5lcmljc3Nvbi5jb20vbGVnYWwuc2h0bWwwHQYDVR0OBBYEFAgOzAPuplmPr7C1 BTqV94OyqUdhMB8GA1UdIwQYMBaAFJYnw7jepV9dRD45UuVFsXZfYzCbMA4GA1UdDwEB/wQEAwIF oDANBgkqhkiG9w0BAQUFAAOCAQEAE1gyNW6c2t/YsLxW5sm67+gVGK0Lnge4ub+k8dgGrK7Mj7em nkOIFkjdv/tqdJ/SoUy/WEkBXba2TfpZ+lfluMgLYux1vSvqBUxYBsUHeNth2Q/Y6A9sCaDTBPlK vZ2jLz814NavrVfgTCLdxX6zNtGdwzhviz+FyqyxYF43Q86RP8Gd/Npaz1W8pmYAHm0+lezuTx5k F3Av3+SaZ/MR6s+RWuXEIdED36ajeQz+OG8Mh3nplofzdrOeoWGDz53YlfRhgj+TXo+H1lclZAvD WVaMMXPdb27h9Hngsq87dkCW9uAyv8DI993rdhqzlEgUyQIL32icAXfTmTYgoGPOwjCCBEUwggMt oAMCAQICEBPJ6v/eJq2p3KTKI4GDR+MwDQYJKoZIhvcNAQEFBQAwRDEaMBgGA1UECgwRVGVsaWFT b25lcmEgR3JvdXAxJjAkBgNVBAMMHVRlbGlhU29uZXJhIFB1YmxpYyBSb290IENBIHYxMB4XDTA2 MTAwNjEwMDA1M1oXDTE2MTAwMjA1MDQxN1owOTERMA8GA1UECgwIRXJpY3Nzb24xJDAiBgNVBAMM G0VyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EwMTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC ggEBALYQd+Q1HuuHxDyNGFlEPzCxuPPFO5W2xyr+nqCVnNJ4QYFe1HACqavqNLwUGIqIEyHv1rLn fub9LBc7dQpRHjl/dggin0ONOFJ36nbGEbfHjLJz2BzOWvwl84Sc+Fx09IrDU/SZSWFSfhqTu3TT 39h79brHdRkdPBUgBYgsiFKriHI0TjP5G8628H27BDzqUpzGLSYWgt6/tpwuOH5lcfNfHWMcCYXR lobv0Klu8lxG5amWqAnqrH6ECOyYJTRbHTsaTIZOHy9Qw/0eXPujKT7tU5xxSI2SdceJqzUbAz2o FRQ6Px7/GydpM/Rl+qYoGPcauHUL1aSeVJZqDFqcIF0CAwEAAaOCATwwggE4MBIGA1UdEwEB/wQI MAYBAf8CAQAwRgYDVR0gBD8wPTA7BgcqhXAjAgEBMDAwLgYIKwYBBQUHAgEWImh0dHBzOi8vcmVw b3NpdG9yeS50cnVzdC50ZWxpYS5jb20wgYkGA1UdHwSBgTB/MH2ge6B5hndsZGFwOi8vbGRhcC50 cnVzdC50ZWxpYS5jb20vY249VGVsaWFTb25lcmElMjBQdWJsaWMlMjBSb290JTIwQ0ElMjB2MSxv PVRlbGlhU29uZXJhJTIwR3JvdXA/YXV0aG9yaXR5cmV2b2NhdGlvbmxpc3Q/YmFzZTAOBgNVHQ8B Af8EBAMCAQYwHQYDVR0OBBYEFJYnw7jepV9dRD45UuVFsXZfYzCbMB8GA1UdIwQYMBaAFEXb8I+4 GmKhqCMbY4g4o9vgGmLxMA0GCSqGSIb3DQEBBQUAA4IBAQB2AEoqQz+M3Ra9alkpn/YnwhXIv6tP jhUvSuNs00Nhd0T9XhlIU3a65CaB/UKSqnayE0t7Q0Qq3r+x/GK3in/mik8i/PK2/q8HutzYFSzz 6Npztpo2JG7AEKOJPVaeebjng45m6vNC7RIfzU9sG2LBR/hewS8s6dFFn70w795xUwJBWZ67OzIK XrIVVvHTOYpbWA+MESKAXwFhnVONrOTWlVwrMUi4HbiPWpOk+xQbgehCEi7mu3cXsaU1Xq3kMXui NuC7VKoob8mFO9o9RT+dlirD2uRXwNpvCu3but6Kyhu0+nvy2iXGKjdlxlWTsdDyulXYz+OYCMZ9 lFWRzMIPMIIEbTCCA1WgAwIBAgIRAJywjASay5cieGNithuGWj0wDQYJKoZIhvcNAQEFBQAwOjEZ MBcGA1UEChMQUlNBIFNlY3VyaXR5IEluYzEdMBsGA1UECxMUUlNBIFNlY3VyaXR5IDIwNDggVjMw HhcNMDYxMDMxMjA0MjI3WhcNMTYxMTAxMTU0MjI1WjBEMRowGAYDVQQKDBFUZWxpYVNvbmVyYSBH cm91cDEmMCQGA1UEAwwdVGVsaWFTb25lcmEgUHVibGljIFJvb3QgQ0EgdjEwggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDKTxADapCAq3mplX4R4gNt+WZe5QKGnaVEQSyY7lICKF5DuVdW PMLHDjzhw5IzDd860ZZx/0VrhGB3DmP4SDIWCKo2PxvY5NckdBWPWp/T2uaQdOAwgqHpN0pe1X7/ jel59WsWYXKGg/81Wth73ZK/geE7Gz9Pvj1LU6N4YhLMgooxKnCS+ZjB5icWAg+Qd1QpQhF46H1i bp6LsBWDp56MPpg8F5X6y7MGVcKYLdnLOPs84uxRW9qs1kBopzQBj6s5SyVh8A+j5liDBjghXYpw /+paGEdqHPeSFYxZKeJatmjEKLYlxcZWRKf436KvQA9jBhMEmytMNbGicR1mRH6tAgMBAAGjggFi MIIBXjAfBgNVHSMEGDAWgBQHw1EwpKrpRa41JPr/JCwz0LGdjDAdBgNVHQ4EFgQURdvwj7gaYqGo IxtjiDij2+AaYvEwEgYDVR0TAQH/BAgwBgEB/wIBBDCBhQYDVR0gBH4wfDA9BgkqhkiG9w0FBgEw MDAuBggrBgEFBQcCARYiaHR0cHM6Ly9yZXBvc2l0b3J5LnRydXN0LnRlbGlhLmNvbTA7BgcqhXAj AgEBMDAwLgYIKwYBBQUHAgEWImh0dHBzOi8vcmVwb3NpdG9yeS50cnVzdC50ZWxpYS5jb20wcAYD VR0fBGkwZzBloGOgYYZfaHR0cDovL3d3dy5yc2FzZWN1cml0eS5jb20vcHJvZHVjdHMva2Vvbi9y ZXBvc2l0b3J5L2NlcnRpZmljYXRlX3N0YXR1cy9SU0FfU2VjdXJpdHlfMjA0OF92My5DUkwwDgYD VR0PAQH/BAQDAgEGMA0GCSqGSIb3DQEBBQUAA4IBAQAEXpos2CnIm7/872ytSrEHWZgvhOUEkUm2 5PWf/XkWko41TaL9vIS1S6AdWChNqWmnYiS7GfaIiDM9s1D6K7hidWBDOm46bNdM3ZwhMyDCfkDJ SgeJ0w+7YmjvChu7gWqDZCsbtZ5gA1ixCTdDnuZB67JGSPGW6r73coraDP8diOpiQouMvM6bKuTP BH/1poLccsUxsKgrQ23JC9LWCRb8cYHkZjXFH1K44TsIl5Lne2oT0JI3pwdA2v6jO4p/OLHntP+n pjwPbedMPUZkDYCkd3LSxj8c3JTxtA8SlPCtIHE1hh65xihg1JRIliSphrqr9kbfwHdeVxPdOI5G tDYPMYICEjCCAg4CAQEwTTA5MREwDwYDVQQKDAhFcmljc3NvbjEkMCIGA1UEAwwbRXJpY3Nzb24g TkwgSW5kaXZpZHVhbCBDQTAxAhAhVsFUBw1ddjP0q9Mjb9LGMAkGBSsOAwIaBQCgggEbMBgGCSqG SIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDgxNzE2MzAxN1owIwYJKoZI hvcNAQkEMRYEFPYfE7/dtWLJg/P48dc9H3XKIKeCMFwGCSsGAQQBgjcQBDFPME0wOTERMA8GA1UE CgwIRXJpY3Nzb24xJDAiBgNVBAMMG0VyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EwMQIQIVbBVAcN XXYz9KvTI2/SxjBeBgsqhkiG9w0BCRACCzFPoE0wOTERMA8GA1UECgwIRXJpY3Nzb24xJDAiBgNV BAMMG0VyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EwMQIQIVbBVAcNXXYz9KvTI2/SxjANBgkqhkiG 9w0BAQEFAASBgFQv3aYyJ09HzshilJ64RCt0ymCbEkCnKuRTby5WRW/QJ2anMxCYC2T4/2esOFtI NLoFjXB1ykYvawNcD0ie7TrqzOTtNdIicdw3Qdeort9E1DKQI9xsP62tbe5ELN7C5tPC4FR5kf/u 1MUaRrMiUyHCyroXBWMxvN1pqYYwllCJAAAAAAAA --Apple-Mail-27--305886237-- Return-Path: 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 3309A21F85A8 for ; Fri, 17 Aug 2012 07:09:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.977 X-Spam-Level: X-Spam-Status: No, score=-0.977 tagged_above=-999 required=5 tests=[AWL=-0.226, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, MIME_QP_LONG_LINE=1.396, SARE_SUB_ENC_UTF8=0.152] 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 OfwQnJMWZzhP for ; Fri, 17 Aug 2012 07:09:23 -0700 (PDT) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id 6416A21F858A for ; Fri, 17 Aug 2012 07:09:23 -0700 (PDT) Received: from [10.45.126.22] (mobile-198-228-205-027.mycingular.net [198.228.205.27]) by lucidvision.com (Postfix) with ESMTP id C5B1622555B1; Fri, 17 Aug 2012 10:09:21 -0400 (EDT) References: <812700A304640D4292205D5E83FC59E1061C211D@p-embx01-eq.jnpr.net> <3512BB31280C39448A9880F61DD54CEB09C07E@xmb-aln-x09.cisco.com> In-Reply-To: Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Message-Id: <1E6B6081-2A02-4486-BE7D-3A0E92E0B7B4@lucidvision.com> X-Mailer: iPhone Mail (9B206) From: Thomas Nadeau Date: Fri, 17 Aug 2012 10:09:17 -0400 To: Mach Chen Cc: "irs-discuss@ietf.org" , "UTTARO, JAMES" , "Dutta, Pranjal K \(Pranjal\)" , "Shah, Himanshu" , Alia Atlas Subject: Re: [irs-discuss] =?utf-8?b?562U5aSNOiDnrZTlpI06ICBJUlMgY29tbWVudHM=?= X-BeenThere: irs-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Aug 2012 14:09:24 -0000 On Aug 16, 2012, at 10:38 PM, Mach Chen wrote: > Hi Alia, >=20 > It's great to define uniform interfaces to the applications, but I am not s= ure whether the IRS interfaces could be directly used by the applications, i= n the IRS framework, the applications talk to the IRS agents, IMHO, the IRS a= gent (it may be the controller or orchestrator role from the SDN point of vi= ew, and the IRS interfaces are the southbound interfaces ) should shield the= variety of the IRS interfaces. =20 The idea is definitely to allow direct use of the interface of that is opera= tionally desired. Tom=20 > And I agree that we should currently focus on the use cases and then defin= e a clear scope. Here is a rough SDN related use case draft (http://tools.ie= tf.org/html/draft-mm-sdn-vc-vn-on-demand-use-case-01), I am not sure this is= related to IRS.=20 >=20 > Best regards, > Mach >=20 >> -----=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB=B6----- >> =E5=8F=91=E4=BB=B6=E4=BA=BA: Alia Atlas [mailto:akatlas@gmail.com] >> =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2012=E5=B9=B48=E6=9C=8817=E6=97=A5 1= 0:13 >> =E6=94=B6=E4=BB=B6=E4=BA=BA: Mach Chen >> =E6=8A=84=E9=80=81: Shah, Himanshu; UTTARO, JAMES; Dutta, Pranjal K (Pran= jal); >> irs-discuss@ietf.org >> =E4=B8=BB=E9=A2=98: Re: =E7=AD=94=E5=A4=8D: [irs-discuss] IRS comments >>=20 >> Hi Mach, >>=20 >> Right - that is one reason why I'm not sure that a CSPF computation >> piece is needed for the RSVP sub-interface. On the other side, >> there's benefit to not requiring an application to understand too many >> different protocols. >>=20 >> We need to discuss what scope makes sense for the sub-interfaces. I >> think the use-cases will drive this. >>=20 >> Alia >>=20 >> On Thu, Aug 16, 2012 at 10:06 PM, Mach Chen >> wrote: >>> Hi Alia, >>>=20 >>> I am a little confused, the said RSVP sub-interface (on-demand CSPF inte= rface) >> seems what exactly PCEP does today. My understanding of IRS is that it ma= y be >> complementary on topology discovery. >>>=20 >>> Best regards, >>> Mach >>>=20 >>>> -----=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB=B6----- >>>> =E5=8F=91=E4=BB=B6=E4=BA=BA: irs-discuss-bounces@ietf.org [mailto:irs-d= iscuss-bounces@ietf.org] >> =E4=BB=A3 >>>> =E8=A1=A8 Alia Atlas >>>> =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2012=E5=B9=B48=E6=9C=8817=E6=97=A5= 9:45 >>>> =E6=94=B6=E4=BB=B6=E4=BA=BA: Shah, Himanshu >>>> =E6=8A=84=E9=80=81: UTTARO, JAMES; Dutta, Pranjal K (Pranjal); irs-disc= uss@ietf.org >>>> =E4=B8=BB=E9=A2=98: Re: [irs-discuss] IRS comments >>>>=20 >>>> I'm not entirely clear on the model or question you are asking. An >>>> application could learn topology via IRS to the appropriate IRS >>>> agents, do CSPF computations, and support a signaling/CSPF-like >>>> sub-interface (if we define such for IRS) as an IRS agent. Another >>>> application could query the first for the CSPF results and then use >>>> IRS to trigger signaling on the appropriate device. >>>>=20 >>>> I'm not sure if it makes sense to have an IRS sub-interface that >>>> requests CSPF computation, but it might come as part of an RSVP >>>> sub-interface to trigger signaling. We'll have to see about >>>> use-cases. >>>>=20 >>>> I don't see a strong motivation to duplicate existing work. >>>>=20 >>>> Alia >>>>=20 >>>> On Thu, Aug 16, 2012 at 2:46 PM, Shah, Himanshu >> wrote: >>>>> I was wondering if PCE and IRS could have overlapping functionality. >>>>>=20 >>>>> Meaning, can an IRS interface user at both ends (node and controller) b= e a >>>> non-PCE entity and perform >>>>> the same service as what PCE does? >>>>>=20 >>>>> It seems like you are saying that could work co-operatively... >>>>>=20 >>>>> Thanks, >>>>> himanshu >>>>=20 >>>> =3D=3Dsnip=3D=3D=3D >>>> _______________________________________________ >>>> 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 Return-Path: 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 E7EE221F845A for ; Thu, 16 Aug 2012 20:15:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.417 X-Spam-Level: X-Spam-Status: No, score=-7.417 tagged_above=-999 required=5 tests=[AWL=-0.818, 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 fsmVcW6vEaBk for ; Thu, 16 Aug 2012 20:15:12 -0700 (PDT) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id 8EDC121F8456 for ; Thu, 16 Aug 2012 20:15:12 -0700 (PDT) Received: from inbansmailrelay2.in.alcatel-lucent.com (h135-250-11-33.lucent.com [135.250.11.33]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id q7H3F53r026153 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 16 Aug 2012 22:15:08 -0500 (CDT) Received: from INBANSXCHHUB02.in.alcatel-lucent.com (inbansxchhub02.in.alcatel-lucent.com [135.250.12.35]) by inbansmailrelay2.in.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id q7H3F4HA003689 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 17 Aug 2012 08:45:04 +0530 Received: from INBANSXCHMBSA3.in.alcatel-lucent.com ([135.250.12.50]) by INBANSXCHHUB02.in.alcatel-lucent.com ([135.250.12.35]) with mapi; Fri, 17 Aug 2012 08:45:04 +0530 From: "Dutta, Pranjal K (Pranjal)" To: Alia Atlas Date: Fri, 17 Aug 2012 08:45:01 +0530 Thread-Topic: [irs-discuss] IRS comments Thread-Index: Ac18InzfYy1rA2g8TYGglF1xo3zZngAA7Tvg Message-ID: References: <812700A304640D4292205D5E83FC59E1061C211D@p-embx01-eq.jnpr.net> <502D2692.2030105@cttc.es> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 Cc: Ramon Casellas , "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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Aug 2012 03:15:14 -0000 Hi Alia, =20 "Whether centralized SPF compute is a good idea probably depends greatly on= the use-case and details of the architecture. I haven't seen ones that co= nvince me yet, but I haven't been hunting them either." Yes, this is the point. I am not convinced either. Unless we see strong rea= listic use case we probably shouldn't discuss this further. Thanks, Pranjal -----Original Message----- From: Alia Atlas [mailto:akatlas@gmail.com]=20 Sent: Thursday, August 16, 2012 7:46 PM To: Dutta, Pranjal K (Pranjal) Cc: Ramon Casellas; irs-discuss@ietf.org Subject: Re: [irs-discuss] IRS comments Pranjal, Sure - IRS is to provide an Interface to the Routing System. If part of the routing system isn't co-located on the forwarding device, then it'd be good for the IRS data-models and such to work with it. That's hard when it is a moving target. My point about LFA/MRT/IP-FRR is simply that if the SPF compute is remote, then that will impact the convergence time. At that point for an architecture, there are basically two choices - deal with longer periods of traffic loss or pre-compute and install alternates to use in the case of a local failure. The longer FIB convergence time could thus be mitigated. Whether centralized SPF compute is a good idea probably depends greatly on the use-case and details of the architecture. I haven't seen ones that convince me yet, but I haven't been hunting them either. Alia On Thu, Aug 16, 2012 at 10:19 PM, Dutta, Pranjal K (Pranjal) wrote: > I believe if IRS needs to address centralized SPF compute then it needs t= o be a generic approach, irrespective of whether a topology offers LFA/MRT.= Thus I see a limited scope since FIB convergence would be a major concern = in general, although this is a too early statement to make. As I mentioned = I would be very cautious on such approach. > > Thanks, > Pranjal > > -----Original Message----- > From: Alia Atlas [mailto:akatlas@gmail.com] > Sent: Thursday, August 16, 2012 7:11 PM > To: Dutta, Pranjal K (Pranjal) > Cc: Ramon Casellas; irs-discuss@ietf.org > Subject: Re: [irs-discuss] IRS comments > > If there are always IP-FRR alternates that can be used and only a > single covered failure has happened, then the slow path reconvergence > needn't impact traffic (ignoring the issue of u-loops which we do > understand how to handle). As for MRT, the advantage is that it > guarantees there'll always be an alternate, unlike LFA. Some method > has to be used to get that level of coverage - depending on how bad > the FIB convergence times would be. > > Alia > > On Thu, Aug 16, 2012 at 10:06 PM, Dutta, Pranjal K (Pranjal) > wrote: >> >> IP-FRR/LFA can mitigate one aspect of the problem but most of FIB conver= gence issues in FRR based solutions arise rather during slow >> path convergence after a fast failover. When SPF recompute after >> the FRR switch requires touching the flows again (e.g SPF recompute >> chose a new primary next-hop) then tricks in FIB convergence matters. >> So I would be a bit cautious...MRT etc may not be available in all >> topologies. >> >> Thanks, >> Pranjal >> >> -----Original Message----- >> From: Alia Atlas [mailto:akatlas@gmail.com] >> Sent: Thursday, August 16, 2012 6:50 PM >> To: Dutta, Pranjal K (Pranjal) >> Cc: Ramon Casellas; irs-discuss@ietf.org >> Subject: Re: [irs-discuss] IRS comments >> >> On Thu, Aug 16, 2012 at 7:41 PM, Dutta, Pranjal K (Pranjal) >> wrote: >>> Thanks for detailed explanation. My question on LSA flooding was not in= the context of PCE or CSPF/TE-DB but on the issue of "regular/unconstraine= d" SPF computation in IGPs. The dynamics between a) CSPF on TE-DB and b) re= gular SPF on each link state change in a network are much different. My con= cern was primarily on b) - I don't see what it achieves and in fact may deg= rade FIB convergence performance abysmally. >> >> [Alia] What it could accomplish is allowing other types of algorithms >> than simple SPF for computing routes. As for FIB convergence, this >> is certainly a concern. I do think that fast-reroute technology could >> be used to mitigate the problem - but only really for single failures. >> >>> As Alia has clarified, we haven't heard of any clear, realistic use cas= e of b). I agree with you that missing pieces in PCE may be addressed thru = IRS. >>> >>> Thanks, >>> Pranjal >>> >>> >>> >>> -----Original Message----- >>> From: Ramon Casellas [mailto:ramon.casellas@cttc.es] >>> Sent: Thursday, August 16, 2012 9:58 AM >>> To: Dutta, Pranjal K (Pranjal) >>> Cc: Alia Atlas; irs-discuss@ietf.org >>> Subject: Re: [irs-discuss] IRS comments >>> >>> On 08/16/2012 06:14 PM, Dutta, Pranjal K (Pranjal) 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 p= recisely 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 O= SPF/ISIS as it is done today. So routers would build neighboring relationsh= ip/adjacencies to participate in flooding and each router builds its LSDB. >>>> >>>> Then the IRS "application" would track LSDB changes and pull up the "d= iffs" from each router (thru "controller") whenever there is a change. The = application would compute SPF on behalf of each router (LSDB). The result o= f the compute would be pushed by application to each Router (thru controlle= r) and inject entries into RIB. >>>> >>>> Is that correct? How different this going to be from PCE? >>>> >>> >>> >>> Pranjal, all, >>> >>> My two cents. Apologies if this is well known, I am not sure I fully >>> grasped your question... >>> >>> IMHO, the idea of separating LSA flooding from CSPF computation has >>> indeed been a current topic for a while, and when it is tied to the ide= a >>> of offloading the CSPF computation to a dedicated centralized server >>> (for example a PCE), I would guess/say that this is usually scoped and >>> applies to the case when one formally decouples the control plane from >>> the data plane (thus constructing a LSDB and establishing adjacencies i= n >>> the control plane network and also constructing a separated Traffic >>> Engineering Database or TED, which is described via opaque LSAs). >>> >>> In this particular scenario, the CSPF refers to /applies to the >>> dataplane only (as is done in GMPLS/PCE), and one still needs SPF for >>> the addresses in the DCN. In other words, OSPF-TE is used to disseminat= e >>> data plane (TE) link/node attribute changes (in addition to what OSFPv2 >>> already does) and for this establishes routing adjacencies and the PCE >>> performs CSPF on the TED, which can be a completely different topology. >>> >>> However, regarding your question "how different from a PCE", I would sa= y >>> these are complementary : first a) the PCE architecture does not specif= y >>> how it obtains the Traffic Engineering Database (TED) to construct the >>> directed graph on which it operates (i.e., performs CSPF, usually upon >>> request); the PCE does not usually care much about the control plane >>> topology and, b) what you refer to "push to each router" and "inject >>> entries into the RIB" is completely orthogonal to a PCE. >>> >>> For a), and as stated previously in the list, a common way is to be a >>> passive listener or to sniff LSAs with opaque (MPLS TE, area-wide) or t= o >>> contact a topology server or NMS that has the current topology (TED). >>> In other words, a PCE is a decoupled functional component and the >>> protocol (PCEP) only specifies the interface to request path >>> computations. Even if one uses a PCE and a lightweight LSA flooding >>> protocol, SPF still needs to be executed by nodes to "forward" control >>> packets, usually using the uncontrained shortest IP route. For b) note >>> that, as of now, there is no standard way by which a PCE can configure >>> the dataplane by itself. By "configure the dataplane" one can mean to >>> "trigger" the establishment of LSPs via RSVP-TE signaling, or configure >>> the cross-connects via OpenFlow or to set up state in the datapath >>> (could even be configuring the RIB), somehow. >>> >>> Recently, Ed has started work in stateful PCE, and it is possible that >>> in the future it will have the capability to "command" the establishmen= t >>> of connections. >>> >>> In summary, I see the (generic) relationship between PCE and IRS in two >>> main ways: >>> >>> * As a means to communicate / obtain the TED, typically constructed via >>> OSPF-TE opaque LSAs. This would be an alternative to existing methods / >>> current practice. Another main driver for this is the Hierarchical PCE >>> (H-PCE) in case a parent PCE needs to know about an (aggregated) >>> topology within a (child) domain, since parent / child PCEs may not be >>> in the same IGP area. >>> In this sense, and as stated in the list, for this, other considered >>> solutions are BGPLS / north bound interfaces or to use notify (PCNtf) >>> messages wrapping TE LSAs for this. >>> >>> * As a means to define data plane state (much like OpenFlow) once a Pat= h >>> has been computed. >>> >>> Imho these are two areas which the PCE architecture and protocol do not >>> currently cover and in which an architecture such as IRS could be helpf= ul. >>> >>> Hope this helps (a little!) >>> >>> Best regards >>> >>> Ramon >>> >>> -- >>> Ramon Casellas, Ph.D. >>> Research Associate - Optical Networking Area --http://wikiona.cttc.es >>> CTTC - Centre Tecnol=F2gic de Telecomunicacions de Catalunya, PMT Ed B4 >>> Av. Carl Friedrich Gauss, 7 - 08860 Castelldefels (Barcelona) - Spain >>> Tel.: +34 93 645 29 00 -- Fax. +34 93 645 29 01 >>> >>> >>> Return-Path: 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 A5CB711E80B8 for ; Thu, 16 Aug 2012 19:55:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.867 X-Spam-Level: X-Spam-Status: No, score=0.867 tagged_above=-999 required=5 tests=[AWL=-1.921, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, CN_BODY_35=0.339, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4, SARE_SUB_ENC_GB2312=1.345] 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 8Ytajo5Z7LW2 for ; Thu, 16 Aug 2012 19:55:01 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id E47BE11E80A2 for ; Thu, 16 Aug 2012 19:55:00 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml201-edg.china.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath) with ESMTP id AJM12159; Thu, 16 Aug 2012 18:55:00 -0800 (PST) Received: from DFWEML404-HUB.china.huawei.com (10.193.5.203) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 16 Aug 2012 19:54:40 -0700 Received: from SZXEML437-HUB.china.huawei.com (10.72.61.72) by dfweml404-hub.china.huawei.com (10.193.5.203) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 16 Aug 2012 19:54:44 -0700 Received: from SZXEML511-MBS.china.huawei.com ([169.254.4.86]) by szxeml437-hub.china.huawei.com ([10.72.61.72]) with mapi id 14.01.0323.003; Fri, 17 Aug 2012 10:54:40 +0800 From: Mach Chen To: Alia Atlas Thread-Topic: =?gb2312?B?tPC4tDogtPC4tDogW2lycy1kaXNjdXNzXSBJUlMgY29tbWVudHM=?= Thread-Index: Ac1utoJXMLn1Fv5cTmO9ZkEBmEbA7gABwUJeAhOezIAAAeHBAAABnwCAAHz4WAAAYnx4AAADAtaAAAFAFIAAAWTiAAACsjgAAABFcQAAA0u0AAAADucAAAA1foAAAckFAAAHy5EAAAHV1YAAAdkdAAAEme+AAAUvGYAAFVTUAAADbfoAAAUkXwAADptygAARQljg//994gD//3mk8IAAkQCA//95ZGA= Date: Fri, 17 Aug 2012 02:54:39 +0000 Message-ID: References: <812700A304640D4292205D5E83FC59E1061C211D@p-embx01-eq.jnpr.net> <3512BB31280C39448A9880F61DD54CEB09C07E@xmb-aln-x09.cisco.com> In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.96.190] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "UTTARO, JAMES" , "Dutta, Pranjal K \(Pranjal\)" , "Shah, Himanshu" , "irs-discuss@ietf.org" Subject: [irs-discuss] =?gb2312?b?tPC4tDogtPC4tDogtPC4tDogIElSUyBjb21tZW50?= =?gb2312?b?cw==?= X-BeenThere: irs-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Aug 2012 02:55:01 -0000 SGkgQWxpYSwNCg0KSSBvcmlnaW5hbGx5IG1lYW4gdGhlIElSUyBjbGllbnQsIHNvcnJ5IGFib3V0 IHRoZSB0eXBvOi0pDQoNCkJlc3QgcmVnYXJkcywNCk1hY2gNCg0KPiAtLS0tLdPKvP7Urbz+LS0t LS0NCj4gt6K8/sjLOiBBbGlhIEF0bGFzIFttYWlsdG86YWthdGxhc0BnbWFpbC5jb21dDQo+ILei y83KsbzkOiAyMDEyxOo41MIxN8jVIDEwOjUxDQo+IMrVvP7IyzogTWFjaCBDaGVuDQo+ILOty806 IFNoYWgsIEhpbWFuc2h1OyBVVFRBUk8sIEpBTUVTOyBEdXR0YSwgUHJhbmphbCBLIChQcmFuamFs KTsNCj4gaXJzLWRpc2N1c3NAaWV0Zi5vcmcNCj4g1vfM4jogUmU6ILTwuLQ6ILTwuLQ6IFtpcnMt ZGlzY3Vzc10gSVJTIGNvbW1lbnRzDQo+IA0KPiBIaSBNYWNoLA0KPiANCj4gVGhlIElSUyBhZ2Vu dCBpcyBjby1sb2NhdGVkIHdpdGggdGhlIHBvcnRpb24gb2YgdGhlIHJvdXRpbmcgc3lzdGVtDQo+ IHRoYXQgaXQgcHJvdmlkZXMgYW4gaW50ZXJmYWNlIHRvby4gIEkgdGhpbmsgeW91IG1pZ2h0IGJl IGNvbmZ1c2VkDQo+IGFib3V0IHRoYXQgLSBzaW5jZSB0aGUgSVJTIGFnZW50IGlzbid0IHBhcnQg b2YgdGhlIGNvbnRyb2xsZXIgb3INCj4gb3JjaGVzdHJhdG9yIHVubGVzcyB0aGF0IGlzIG9mZmVy aW5nIHBhcnQgb2YgdGhlIHJvdXRpbmcgc3lzdGVtLg0KPiBTbyAtIEkgZGlzYWdyZWUgYWJvdXQg dGhlIGltcGFjdCBvZiBtdWx0aXBsZSBwcm90b2NvbHMuDQo+IA0KPiBSYXRoZXIgdGhhbiBsb29r IGF0IHRoZSB2YXJpb3VzIGdlbmVyYWwgU0ROIHVzZS1jYXNlcywgaXQgaXMgbXVjaCBtb3JlDQo+ IGludGVyZXN0aW5nIHRvIGxvb2sgYXQgdXNlLWNhc2VzIGZvciBJUlMuICBJZiB5b3UgY2FyZSB0 byBsb29rIGF0IHRoYXQNCj4gZHJhZnQgYW5kIGZpbmQgc29tZXRoaW5nIG9mIHJlbGV2YW5jZSBm b3IgSVJTLCBwbGVhc2UgZG8gbGV0IHRoZSBsaXN0DQo+IGtub3cuDQo+IA0KPiBBbGlhDQo+IA0K PiANCj4gT24gVGh1LCBBdWcgMTYsIDIwMTIgYXQgMTA6MzggUE0sIE1hY2ggQ2hlbiA8bWFjaC5j aGVuQGh1YXdlaS5jb20+DQo+IHdyb3RlOg0KPiA+IEhpIEFsaWEsDQo+ID4NCj4gPiBJdCdzIGdy ZWF0IHRvIGRlZmluZSB1bmlmb3JtIGludGVyZmFjZXMgdG8gdGhlIGFwcGxpY2F0aW9ucywgYnV0 IEkgYW0gbm90IHN1cmUNCj4gd2hldGhlciB0aGUgSVJTIGludGVyZmFjZXMgY291bGQgYmUgZGly ZWN0bHkgdXNlZCBieSB0aGUgYXBwbGljYXRpb25zLCBpbiB0aGUgSVJTDQo+IGZyYW1ld29yaywg dGhlIGFwcGxpY2F0aW9ucyB0YWxrIHRvIHRoZSBJUlMgYWdlbnRzLCBJTUhPLCB0aGUgSVJTIGFn ZW50IChpdCBtYXkNCj4gYmUgdGhlIGNvbnRyb2xsZXIgb3Igb3JjaGVzdHJhdG9yIHJvbGUgZnJv bSB0aGUgU0ROIHBvaW50IG9mIHZpZXcsIGFuZCB0aGUgSVJTDQo+IGludGVyZmFjZXMgYXJlIHRo ZSBzb3V0aGJvdW5kIGludGVyZmFjZXMgKSBzaG91bGQgc2hpZWxkIHRoZSB2YXJpZXR5IG9mIHRo ZSBJUlMNCj4gaW50ZXJmYWNlcy4NCj4gPg0KPiA+IEFuZCBJIGFncmVlIHRoYXQgd2Ugc2hvdWxk IGN1cnJlbnRseSBmb2N1cyBvbiB0aGUgdXNlIGNhc2VzIGFuZCB0aGVuIGRlZmluZSBhDQo+IGNs ZWFyIHNjb3BlLiBIZXJlIGlzIGEgcm91Z2ggU0ROIHJlbGF0ZWQgdXNlIGNhc2UgZHJhZnQNCj4g KGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LW1tLXNkbi12Yy12bi1vbi1kZW1hbmQt dXNlLWNhc2UtMDEpLCBJIGFtDQo+IG5vdCBzdXJlIHRoaXMgaXMgcmVsYXRlZCB0byBJUlMuDQo+ ID4NCj4gPiBCZXN0IHJlZ2FyZHMsDQo+ID4gTWFjaA0KPiA+DQo+ID4+IC0tLS0t08q8/tStvP4t LS0tLQ0KPiA+PiC3orz+yMs6IEFsaWEgQXRsYXMgW21haWx0bzpha2F0bGFzQGdtYWlsLmNvbV0N Cj4gPj4gt6LLzcqxvOQ6IDIwMTLE6jjUwjE3yNUgMTA6MTMNCj4gPj4gytW8/sjLOiBNYWNoIENo ZW4NCj4gPj4gs63LzTogU2hhaCwgSGltYW5zaHU7IFVUVEFSTywgSkFNRVM7IER1dHRhLCBQcmFu amFsIEsgKFByYW5qYWwpOw0KPiA+PiBpcnMtZGlzY3Vzc0BpZXRmLm9yZw0KPiA+PiDW98ziOiBS ZTogtPC4tDogW2lycy1kaXNjdXNzXSBJUlMgY29tbWVudHMNCj4gPj4NCj4gPj4gSGkgTWFjaCwN Cj4gPj4NCj4gPj4gUmlnaHQgLSB0aGF0IGlzIG9uZSByZWFzb24gd2h5IEknbSBub3Qgc3VyZSB0 aGF0IGEgQ1NQRiBjb21wdXRhdGlvbg0KPiA+PiBwaWVjZSBpcyBuZWVkZWQgZm9yIHRoZSBSU1ZQ IHN1Yi1pbnRlcmZhY2UuICBPbiB0aGUgb3RoZXIgc2lkZSwNCj4gPj4gdGhlcmUncyBiZW5lZml0 IHRvIG5vdCByZXF1aXJpbmcgYW4gYXBwbGljYXRpb24gdG8gdW5kZXJzdGFuZCB0b28gbWFueQ0K PiA+PiBkaWZmZXJlbnQgcHJvdG9jb2xzLg0KPiA+Pg0KPiA+PiBXZSBuZWVkIHRvIGRpc2N1c3Mg d2hhdCBzY29wZSBtYWtlcyBzZW5zZSBmb3IgdGhlIHN1Yi1pbnRlcmZhY2VzLiAgSQ0KPiA+PiB0 aGluayB0aGUgdXNlLWNhc2VzIHdpbGwgZHJpdmUgdGhpcy4NCj4gPj4NCj4gPj4gQWxpYQ0KPiA+ Pg0KPiA+PiBPbiBUaHUsIEF1ZyAxNiwgMjAxMiBhdCAxMDowNiBQTSwgTWFjaCBDaGVuIDxtYWNo LmNoZW5AaHVhd2VpLmNvbT4NCj4gPj4gd3JvdGU6DQo+ID4+ID4gSGkgQWxpYSwNCj4gPj4gPg0K PiA+PiA+IEkgYW0gYSBsaXR0bGUgY29uZnVzZWQsIHRoZSBzYWlkIFJTVlAgc3ViLWludGVyZmFj ZSAob24tZGVtYW5kIENTUEYNCj4gaW50ZXJmYWNlKQ0KPiA+PiBzZWVtcyB3aGF0IGV4YWN0bHkg UENFUCBkb2VzIHRvZGF5LiBNeSB1bmRlcnN0YW5kaW5nIG9mIElSUyBpcyB0aGF0IGl0IG1heQ0K PiBiZQ0KPiA+PiBjb21wbGVtZW50YXJ5IG9uIHRvcG9sb2d5IGRpc2NvdmVyeS4NCj4gPj4gPg0K PiA+PiA+IEJlc3QgcmVnYXJkcywNCj4gPj4gPiBNYWNoDQo+ID4+ID4NCj4gPj4gPj4gLS0tLS3T yrz+1K28/i0tLS0tDQo+ID4+ID4+ILeivP7IyzogaXJzLWRpc2N1c3MtYm91bmNlc0BpZXRmLm9y Zw0KPiBbbWFpbHRvOmlycy1kaXNjdXNzLWJvdW5jZXNAaWV0Zi5vcmddDQo+ID4+ILT6DQo+ID4+ ID4+ILHtIEFsaWEgQXRsYXMNCj4gPj4gPj4gt6LLzcqxvOQ6IDIwMTLE6jjUwjE3yNUgOTo0NQ0K PiA+PiA+PiDK1bz+yMs6IFNoYWgsIEhpbWFuc2h1DQo+ID4+ID4+ILOty806IFVUVEFSTywgSkFN RVM7IER1dHRhLCBQcmFuamFsIEsgKFByYW5qYWwpOyBpcnMtZGlzY3Vzc0BpZXRmLm9yZw0KPiA+ PiA+PiDW98ziOiBSZTogW2lycy1kaXNjdXNzXSBJUlMgY29tbWVudHMNCj4gPj4gPj4NCj4gPj4g Pj4gSSdtIG5vdCBlbnRpcmVseSBjbGVhciBvbiB0aGUgbW9kZWwgb3IgcXVlc3Rpb24geW91IGFy ZSBhc2tpbmcuICBBbg0KPiA+PiA+PiBhcHBsaWNhdGlvbiBjb3VsZCBsZWFybiB0b3BvbG9neSB2 aWEgSVJTIHRvIHRoZSBhcHByb3ByaWF0ZSBJUlMNCj4gPj4gPj4gYWdlbnRzLCBkbyBDU1BGIGNv bXB1dGF0aW9ucywgYW5kIHN1cHBvcnQgYSBzaWduYWxpbmcvQ1NQRi1saWtlDQo+ID4+ID4+IHN1 Yi1pbnRlcmZhY2UgKGlmIHdlIGRlZmluZSBzdWNoIGZvciBJUlMpIGFzIGFuIElSUyBhZ2VudC4g IEFub3RoZXINCj4gPj4gPj4gYXBwbGljYXRpb24gY291bGQgcXVlcnkgdGhlIGZpcnN0IGZvciB0 aGUgQ1NQRiByZXN1bHRzIGFuZCB0aGVuIHVzZQ0KPiA+PiA+PiBJUlMgdG8gdHJpZ2dlciBzaWdu YWxpbmcgb24gdGhlIGFwcHJvcHJpYXRlIGRldmljZS4NCj4gPj4gPj4NCj4gPj4gPj4gSSdtIG5v dCBzdXJlIGlmIGl0IG1ha2VzIHNlbnNlIHRvIGhhdmUgYW4gSVJTIHN1Yi1pbnRlcmZhY2UgdGhh dA0KPiA+PiA+PiByZXF1ZXN0cyBDU1BGIGNvbXB1dGF0aW9uLCBidXQgaXQgbWlnaHQgY29tZSBh cyBwYXJ0IG9mIGFuIFJTVlANCj4gPj4gPj4gc3ViLWludGVyZmFjZSB0byB0cmlnZ2VyIHNpZ25h bGluZy4gIFdlJ2xsIGhhdmUgdG8gc2VlIGFib3V0DQo+ID4+ID4+IHVzZS1jYXNlcy4NCj4gPj4g Pj4NCj4gPj4gPj4gSSBkb24ndCBzZWUgYSBzdHJvbmcgbW90aXZhdGlvbiB0byBkdXBsaWNhdGUg ZXhpc3Rpbmcgd29yay4NCj4gPj4gPj4NCj4gPj4gPj4gQWxpYQ0KPiA+PiA+Pg0KPiA+PiA+PiBP biBUaHUsIEF1ZyAxNiwgMjAxMiBhdCAyOjQ2IFBNLCBTaGFoLCBIaW1hbnNodSA8aHNoYWhAY2ll bmEuY29tPg0KPiA+PiB3cm90ZToNCj4gPj4gPj4gPiBJIHdhcyB3b25kZXJpbmcgaWYgUENFIGFu ZCBJUlMgY291bGQgaGF2ZSBvdmVybGFwcGluZyBmdW5jdGlvbmFsaXR5Lg0KPiA+PiA+PiA+DQo+ ID4+ID4+ID4gTWVhbmluZywgY2FuIGFuIElSUyBpbnRlcmZhY2UgdXNlciBhdCBib3RoIGVuZHMg KG5vZGUgYW5kIGNvbnRyb2xsZXIpDQo+IGJlIGENCj4gPj4gPj4gbm9uLVBDRSBlbnRpdHkgYW5k IHBlcmZvcm0NCj4gPj4gPj4gPiB0aGUgc2FtZSBzZXJ2aWNlIGFzIHdoYXQgUENFIGRvZXM/DQo+ ID4+ID4+ID4NCj4gPj4gPj4gPiBJdCBzZWVtcyBsaWtlIHlvdSBhcmUgc2F5aW5nIHRoYXQgY291 bGQgd29yayBjby1vcGVyYXRpdmVseS4uLg0KPiA+PiA+PiA+DQo+ID4+ID4+ID4gVGhhbmtzLA0K PiA+PiA+PiA+IGhpbWFuc2h1DQo+ID4+ID4+DQo+ID4+ID4+ID09c25pcD09PQ0KPiA+PiA+PiBf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+PiA+PiBp cnMtZGlzY3VzcyBtYWlsaW5nIGxpc3QNCj4gPj4gPj4gaXJzLWRpc2N1c3NAaWV0Zi5vcmcNCj4g Pj4gPj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pcnMtZGlzY3Vzcw0K Return-Path: 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 825B411E80A2 for ; Thu, 16 Aug 2012 19:51:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.301 X-Spam-Level: X-Spam-Status: No, score=0.301 tagged_above=-999 required=5 tests=[AWL=-3.734, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, CN_BODY_35=0.339, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_ENC_GB2312=1.345] 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 nC+0ULRs+zI2 for ; Thu, 16 Aug 2012 19:51:23 -0700 (PDT) Received: from mail-gg0-f172.google.com (mail-gg0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id CEB2E11E808D for ; Thu, 16 Aug 2012 19:51:22 -0700 (PDT) Received: by ggnh4 with SMTP id h4so3972302ggn.31 for ; Thu, 16 Aug 2012 19:51:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=/nrOSWLFrM+tl6nt9LW1lO3A4HIluI8jlt2tiAZ+ls8=; b=kniy51/yUdejRijITmO/hY4ubdrkjTscDY5EgdDmGvmzSw8n3Xeamo1NWHJRN8iQHH SzrjzTSHDgAG2ARj7U5C4zeZWQJPROEhQ7B2kPhTKDL1HRK0suwDR089rh54Eu9LgpZn 2knXL1FxMuUW68WgHCetUn+B62jabd/4+2RYMR8df4yi2e2TPxuW7cGEzt6QwC7pBfcU ACMQ5tIKpJm4vXWlbDH8mKe4mEspmyN2kjm9TDia1p7HWwGz353OCmQ9VZtt1cVMR507 Z5w4rPYNuk+eBfJj5PZxKErf3g/m3iwG+cbferohaTt+FC+H+H9BVnwAsaEwI6ni1Xkh XEZw== MIME-Version: 1.0 Received: by 10.50.209.8 with SMTP id mi8mr279354igc.63.1345171882044; Thu, 16 Aug 2012 19:51:22 -0700 (PDT) Received: by 10.50.91.135 with HTTP; Thu, 16 Aug 2012 19:51:21 -0700 (PDT) In-Reply-To: References: <812700A304640D4292205D5E83FC59E1061C211D@p-embx01-eq.jnpr.net> <3512BB31280C39448A9880F61DD54CEB09C07E@xmb-aln-x09.cisco.com> Date: Thu, 16 Aug 2012 22:51:21 -0400 Message-ID: From: Alia Atlas To: Mach Chen Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: quoted-printable Cc: "UTTARO, JAMES" , "Dutta, Pranjal K \(Pranjal\)" , "Shah, Himanshu" , "irs-discuss@ietf.org" Subject: Re: [irs-discuss] =?gb2312?b?tPC4tDogtPC4tDogIElSUyBjb21tZW50cw==?= X-BeenThere: irs-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Aug 2012 02:51:23 -0000 Hi Mach, The IRS agent is co-located with the portion of the routing system that it provides an interface too. I think you might be confused about that - since the IRS agent isn't part of the controller or orchestrator unless that is offering part of the routing system. So - I disagree about the impact of multiple protocols. Rather than look at the various general SDN use-cases, it is much more interesting to look at use-cases for IRS. If you care to look at that draft and find something of relevance for IRS, please do let the list know. Alia On Thu, Aug 16, 2012 at 10:38 PM, Mach Chen wrote: > Hi Alia, > > It's great to define uniform interfaces to the applications, but I am not= sure whether the IRS interfaces could be directly used by the applications= , in the IRS framework, the applications talk to the IRS agents, IMHO, the = IRS agent (it may be the controller or orchestrator role from the SDN point= of view, and the IRS interfaces are the southbound interfaces ) should shi= eld the variety of the IRS interfaces. > > And I agree that we should currently focus on the use cases and then defi= ne a clear scope. Here is a rough SDN related use case draft (http://tools.= ietf.org/html/draft-mm-sdn-vc-vn-on-demand-use-case-01), I am not sure this= is related to IRS. > > Best regards, > Mach > >> -----=D3=CA=BC=FE=D4=AD=BC=FE----- >> =B7=A2=BC=FE=C8=CB: Alia Atlas [mailto:akatlas@gmail.com] >> =B7=A2=CB=CD=CA=B1=BC=E4: 2012=C4=EA8=D4=C217=C8=D5 10:13 >> =CA=D5=BC=FE=C8=CB: Mach Chen >> =B3=AD=CB=CD: Shah, Himanshu; UTTARO, JAMES; Dutta, Pranjal K (Pranjal); >> irs-discuss@ietf.org >> =D6=F7=CC=E2: Re: =B4=F0=B8=B4: [irs-discuss] IRS comments >> >> Hi Mach, >> >> Right - that is one reason why I'm not sure that a CSPF computation >> piece is needed for the RSVP sub-interface. On the other side, >> there's benefit to not requiring an application to understand too many >> different protocols. >> >> We need to discuss what scope makes sense for the sub-interfaces. I >> think the use-cases will drive this. >> >> Alia >> >> On Thu, Aug 16, 2012 at 10:06 PM, Mach Chen >> wrote: >> > Hi Alia, >> > >> > I am a little confused, the said RSVP sub-interface (on-demand CSPF in= terface) >> seems what exactly PCEP does today. My understanding of IRS is that it m= ay be >> complementary on topology discovery. >> > >> > Best regards, >> > Mach >> > >> >> -----=D3=CA=BC=FE=D4=AD=BC=FE----- >> >> =B7=A2=BC=FE=C8=CB: irs-discuss-bounces@ietf.org [mailto:irs-discuss-= bounces@ietf.org] >> =B4=FA >> >> =B1=ED Alia Atlas >> >> =B7=A2=CB=CD=CA=B1=BC=E4: 2012=C4=EA8=D4=C217=C8=D5 9:45 >> >> =CA=D5=BC=FE=C8=CB: Shah, Himanshu >> >> =B3=AD=CB=CD: UTTARO, JAMES; Dutta, Pranjal K (Pranjal); irs-discuss@= ietf.org >> >> =D6=F7=CC=E2: Re: [irs-discuss] IRS comments >> >> >> >> I'm not entirely clear on the model or question you are asking. An >> >> application could learn topology via IRS to the appropriate IRS >> >> agents, do CSPF computations, and support a signaling/CSPF-like >> >> sub-interface (if we define such for IRS) as an IRS agent. Another >> >> application could query the first for the CSPF results and then use >> >> IRS to trigger signaling on the appropriate device. >> >> >> >> I'm not sure if it makes sense to have an IRS sub-interface that >> >> requests CSPF computation, but it might come as part of an RSVP >> >> sub-interface to trigger signaling. We'll have to see about >> >> use-cases. >> >> >> >> I don't see a strong motivation to duplicate existing work. >> >> >> >> Alia >> >> >> >> On Thu, Aug 16, 2012 at 2:46 PM, Shah, Himanshu >> wrote: >> >> > I was wondering if PCE and IRS could have overlapping functionality= . >> >> > >> >> > Meaning, can an IRS interface user at both ends (node and controlle= r) be a >> >> non-PCE entity and perform >> >> > the same service as what PCE does? >> >> > >> >> > It seems like you are saying that could work co-operatively... >> >> > >> >> > Thanks, >> >> > himanshu >> >> >> >> =3D=3Dsnip=3D=3D=3D >> >> _______________________________________________ >> >> irs-discuss mailing list >> >> irs-discuss@ietf.org >> >> https://www.ietf.org/mailman/listinfo/irs-discuss Return-Path: 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 3294511E80A2 for ; Thu, 16 Aug 2012 19:46:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.515 X-Spam-Level: X-Spam-Status: No, score=-3.515 tagged_above=-999 required=5 tests=[AWL=0.084, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 MfD92UTzGPyo for ; Thu, 16 Aug 2012 19:46:19 -0700 (PDT) Received: from mail-gh0-f172.google.com (mail-gh0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id B7A8E11E808D for ; Thu, 16 Aug 2012 19:46:18 -0700 (PDT) Received: by ghbg16 with SMTP id g16so3964528ghb.31 for ; Thu, 16 Aug 2012 19:46:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=RBixjnJp19WcDk8lxwt4meUYnDeCc3fshY8KaD41ozo=; b=T33yLTDuvD4UtnIqkNp1RwsYE2mTiU796f9Dnhg5kO21Ctw4Y2RL3Jj6DFVIo1PZJU Soa4QXqwjdCYb5ASLRtEB5WnqsD3VkMG5ZjG8++AY4mdfm+k+KBjT60Ze6s4jxtOqj4j zehPx8UHYF4Y1MLwSpmmhfGvCqZK/OGcbbw3kSf7dFlZlxTj0wzZugJwjOUxOhhtQw30 hSokz1cz2L78aoW00BXH7yieod7rOeKYSgvGiIwW1SLc99qGTbf75gbsjKWMWfb7YQeZ zmxKB3Hh522itrVnaFJh5fJWlfCWy/f+SEr68kZSi0y6MY5LBbm45exPKdk7fNDyi4AT 8eQg== MIME-Version: 1.0 Received: by 10.50.213.106 with SMTP id nr10mr269478igc.58.1345171577942; Thu, 16 Aug 2012 19:46:17 -0700 (PDT) Received: by 10.50.91.135 with HTTP; Thu, 16 Aug 2012 19:46:17 -0700 (PDT) In-Reply-To: References: <812700A304640D4292205D5E83FC59E1061C211D@p-embx01-eq.jnpr.net> <502D2692.2030105@cttc.es> Date: Thu, 16 Aug 2012 22:46:17 -0400 Message-ID: From: Alia Atlas To: "Dutta, Pranjal K (Pranjal)" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Ramon Casellas , "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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Aug 2012 02:46:26 -0000 Pranjal, Sure - IRS is to provide an Interface to the Routing System. If part of the routing system isn't co-located on the forwarding device, then it'd be good for the IRS data-models and such to work with it. That's hard when it is a moving target. My point about LFA/MRT/IP-FRR is simply that if the SPF compute is remote, then that will impact the convergence time. At that point for an architecture, there are basically two choices - deal with longer periods of traffic loss or pre-compute and install alternates to use in the case of a local failure. The longer FIB convergence time could thus be mitigated. Whether centralized SPF compute is a good idea probably depends greatly on the use-case and details of the architecture. I haven't seen ones that convince me yet, but I haven't been hunting them either. Alia On Thu, Aug 16, 2012 at 10:19 PM, Dutta, Pranjal K (Pranjal) wrote: > I believe if IRS needs to address centralized SPF compute then it needs t= o be a generic approach, irrespective of whether a topology offers LFA/MRT.= Thus I see a limited scope since FIB convergence would be a major concern = in general, although this is a too early statement to make. As I mentioned = I would be very cautious on such approach. > > Thanks, > Pranjal > > -----Original Message----- > From: Alia Atlas [mailto:akatlas@gmail.com] > Sent: Thursday, August 16, 2012 7:11 PM > To: Dutta, Pranjal K (Pranjal) > Cc: Ramon Casellas; irs-discuss@ietf.org > Subject: Re: [irs-discuss] IRS comments > > If there are always IP-FRR alternates that can be used and only a > single covered failure has happened, then the slow path reconvergence > needn't impact traffic (ignoring the issue of u-loops which we do > understand how to handle). As for MRT, the advantage is that it > guarantees there'll always be an alternate, unlike LFA. Some method > has to be used to get that level of coverage - depending on how bad > the FIB convergence times would be. > > Alia > > On Thu, Aug 16, 2012 at 10:06 PM, Dutta, Pranjal K (Pranjal) > wrote: >> >> IP-FRR/LFA can mitigate one aspect of the problem but most of FIB conver= gence issues in FRR based solutions arise rather during slow >> path convergence after a fast failover. When SPF recompute after >> the FRR switch requires touching the flows again (e.g SPF recompute >> chose a new primary next-hop) then tricks in FIB convergence matters. >> So I would be a bit cautious...MRT etc may not be available in all >> topologies. >> >> Thanks, >> Pranjal >> >> -----Original Message----- >> From: Alia Atlas [mailto:akatlas@gmail.com] >> Sent: Thursday, August 16, 2012 6:50 PM >> To: Dutta, Pranjal K (Pranjal) >> Cc: Ramon Casellas; irs-discuss@ietf.org >> Subject: Re: [irs-discuss] IRS comments >> >> On Thu, Aug 16, 2012 at 7:41 PM, Dutta, Pranjal K (Pranjal) >> wrote: >>> Thanks for detailed explanation. My question on LSA flooding was not in= the context of PCE or CSPF/TE-DB but on the issue of "regular/unconstraine= d" SPF computation in IGPs. The dynamics between a) CSPF on TE-DB and b) re= gular SPF on each link state change in a network are much different. My con= cern was primarily on b) - I don't see what it achieves and in fact may deg= rade FIB convergence performance abysmally. >> >> [Alia] What it could accomplish is allowing other types of algorithms >> than simple SPF for computing routes. As for FIB convergence, this >> is certainly a concern. I do think that fast-reroute technology could >> be used to mitigate the problem - but only really for single failures. >> >>> As Alia has clarified, we haven't heard of any clear, realistic use cas= e of b). I agree with you that missing pieces in PCE may be addressed thru = IRS. >>> >>> Thanks, >>> Pranjal >>> >>> >>> >>> -----Original Message----- >>> From: Ramon Casellas [mailto:ramon.casellas@cttc.es] >>> Sent: Thursday, August 16, 2012 9:58 AM >>> To: Dutta, Pranjal K (Pranjal) >>> Cc: Alia Atlas; irs-discuss@ietf.org >>> Subject: Re: [irs-discuss] IRS comments >>> >>> On 08/16/2012 06:14 PM, Dutta, Pranjal K (Pranjal) 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 p= recisely 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 O= SPF/ISIS as it is done today. So routers would build neighboring relationsh= ip/adjacencies to participate in flooding and each router builds its LSDB. >>>> >>>> Then the IRS "application" would track LSDB changes and pull up the "d= iffs" from each router (thru "controller") whenever there is a change. The = application would compute SPF on behalf of each router (LSDB). The result o= f the compute would be pushed by application to each Router (thru controlle= r) and inject entries into RIB. >>>> >>>> Is that correct? How different this going to be from PCE? >>>> >>> >>> >>> Pranjal, all, >>> >>> My two cents. Apologies if this is well known, I am not sure I fully >>> grasped your question... >>> >>> IMHO, the idea of separating LSA flooding from CSPF computation has >>> indeed been a current topic for a while, and when it is tied to the ide= a >>> of offloading the CSPF computation to a dedicated centralized server >>> (for example a PCE), I would guess/say that this is usually scoped and >>> applies to the case when one formally decouples the control plane from >>> the data plane (thus constructing a LSDB and establishing adjacencies i= n >>> the control plane network and also constructing a separated Traffic >>> Engineering Database or TED, which is described via opaque LSAs). >>> >>> In this particular scenario, the CSPF refers to /applies to the >>> dataplane only (as is done in GMPLS/PCE), and one still needs SPF for >>> the addresses in the DCN. In other words, OSPF-TE is used to disseminat= e >>> data plane (TE) link/node attribute changes (in addition to what OSFPv2 >>> already does) and for this establishes routing adjacencies and the PCE >>> performs CSPF on the TED, which can be a completely different topology. >>> >>> However, regarding your question "how different from a PCE", I would sa= y >>> these are complementary : first a) the PCE architecture does not specif= y >>> how it obtains the Traffic Engineering Database (TED) to construct the >>> directed graph on which it operates (i.e., performs CSPF, usually upon >>> request); the PCE does not usually care much about the control plane >>> topology and, b) what you refer to "push to each router" and "inject >>> entries into the RIB" is completely orthogonal to a PCE. >>> >>> For a), and as stated previously in the list, a common way is to be a >>> passive listener or to sniff LSAs with opaque (MPLS TE, area-wide) or t= o >>> contact a topology server or NMS that has the current topology (TED). >>> In other words, a PCE is a decoupled functional component and the >>> protocol (PCEP) only specifies the interface to request path >>> computations. Even if one uses a PCE and a lightweight LSA flooding >>> protocol, SPF still needs to be executed by nodes to "forward" control >>> packets, usually using the uncontrained shortest IP route. For b) note >>> that, as of now, there is no standard way by which a PCE can configure >>> the dataplane by itself. By "configure the dataplane" one can mean to >>> "trigger" the establishment of LSPs via RSVP-TE signaling, or configure >>> the cross-connects via OpenFlow or to set up state in the datapath >>> (could even be configuring the RIB), somehow. >>> >>> Recently, Ed has started work in stateful PCE, and it is possible that >>> in the future it will have the capability to "command" the establishmen= t >>> of connections. >>> >>> In summary, I see the (generic) relationship between PCE and IRS in two >>> main ways: >>> >>> * As a means to communicate / obtain the TED, typically constructed via >>> OSPF-TE opaque LSAs. This would be an alternative to existing methods / >>> current practice. Another main driver for this is the Hierarchical PCE >>> (H-PCE) in case a parent PCE needs to know about an (aggregated) >>> topology within a (child) domain, since parent / child PCEs may not be >>> in the same IGP area. >>> In this sense, and as stated in the list, for this, other considered >>> solutions are BGPLS / north bound interfaces or to use notify (PCNtf) >>> messages wrapping TE LSAs for this. >>> >>> * As a means to define data plane state (much like OpenFlow) once a Pat= h >>> has been computed. >>> >>> Imho these are two areas which the PCE architecture and protocol do not >>> currently cover and in which an architecture such as IRS could be helpf= ul. >>> >>> Hope this helps (a little!) >>> >>> Best regards >>> >>> Ramon >>> >>> -- >>> Ramon Casellas, Ph.D. >>> Research Associate - Optical Networking Area --http://wikiona.cttc.es >>> CTTC - Centre Tecnol=F2gic de Telecomunicacions de Catalunya, PMT Ed B4 >>> Av. Carl Friedrich Gauss, 7 - 08860 Castelldefels (Barcelona) - Spain >>> Tel.: +34 93 645 29 00 -- Fax. +34 93 645 29 01 >>> >>> >>> Return-Path: 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 E0AF221F84D1 for ; Thu, 16 Aug 2012 19:39:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.771 X-Spam-Level: X-Spam-Status: No, score=0.771 tagged_above=-999 required=5 tests=[AWL=-2.017, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, CN_BODY_35=0.339, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4, SARE_SUB_ENC_GB2312=1.345] 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 1yNOt16GpCvL for ; Thu, 16 Aug 2012 19:39:46 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 5EED521F84B6 for ; Thu, 16 Aug 2012 19:39:37 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml201-edg.china.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath) with ESMTP id AJM11439; Thu, 16 Aug 2012 18:39:36 -0800 (PST) Received: from DFWEML406-HUB.china.huawei.com (10.193.5.131) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 16 Aug 2012 19:38:00 -0700 Received: from SZXEML420-HUB.china.huawei.com (10.82.67.159) by dfweml406-hub.china.huawei.com (10.193.5.131) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 16 Aug 2012 19:38:06 -0700 Received: from SZXEML511-MBS.china.huawei.com ([169.254.4.86]) by szxeml420-hub.china.huawei.com ([10.82.67.159]) with mapi id 14.01.0323.003; Fri, 17 Aug 2012 10:38:03 +0800 From: Mach Chen To: Alia Atlas Thread-Topic: =?gb2312?B?tPC4tDogW2lycy1kaXNjdXNzXSBJUlMgY29tbWVudHM=?= Thread-Index: Ac1utoJXMLn1Fv5cTmO9ZkEBmEbA7gABwUJeAhOezIAAAeHBAAABnwCAAHz4WAAAYnx4AAADAtaAAAFAFIAAAWTiAAACsjgAAABFcQAAA0u0AAAADucAAAA1foAAAckFAAAHy5EAAAHV1YAAAdkdAAAEme+AAAUvGYAAFVTUAAADbfoAAAUkXwAADptygAARQljg//994gD//3mk8A== Date: Fri, 17 Aug 2012 02:38:02 +0000 Message-ID: References: <812700A304640D4292205D5E83FC59E1061C211D@p-embx01-eq.jnpr.net> <3512BB31280C39448A9880F61DD54CEB09C07E@xmb-aln-x09.cisco.com> In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.96.190] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "UTTARO, JAMES" , "Dutta, Pranjal K \(Pranjal\)" , "Shah, Himanshu" , "irs-discuss@ietf.org" Subject: [irs-discuss] =?gb2312?b?tPC4tDogtPC4tDogIElSUyBjb21tZW50cw==?= X-BeenThere: irs-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Aug 2012 02:39:47 -0000 SGkgQWxpYSwNCg0KSXQncyBncmVhdCB0byBkZWZpbmUgdW5pZm9ybSBpbnRlcmZhY2VzIHRvIHRo ZSBhcHBsaWNhdGlvbnMsIGJ1dCBJIGFtIG5vdCBzdXJlIHdoZXRoZXIgdGhlIElSUyBpbnRlcmZh Y2VzIGNvdWxkIGJlIGRpcmVjdGx5IHVzZWQgYnkgdGhlIGFwcGxpY2F0aW9ucywgaW4gdGhlIElS UyBmcmFtZXdvcmssIHRoZSBhcHBsaWNhdGlvbnMgdGFsayB0byB0aGUgSVJTIGFnZW50cywgSU1I TywgdGhlIElSUyBhZ2VudCAoaXQgbWF5IGJlIHRoZSBjb250cm9sbGVyIG9yIG9yY2hlc3RyYXRv ciByb2xlIGZyb20gdGhlIFNETiBwb2ludCBvZiB2aWV3LCBhbmQgdGhlIElSUyBpbnRlcmZhY2Vz IGFyZSB0aGUgc291dGhib3VuZCBpbnRlcmZhY2VzICkgc2hvdWxkIHNoaWVsZCB0aGUgdmFyaWV0 eSBvZiB0aGUgSVJTIGludGVyZmFjZXMuICANCg0KQW5kIEkgYWdyZWUgdGhhdCB3ZSBzaG91bGQg Y3VycmVudGx5IGZvY3VzIG9uIHRoZSB1c2UgY2FzZXMgYW5kIHRoZW4gZGVmaW5lIGEgY2xlYXIg c2NvcGUuIEhlcmUgaXMgYSByb3VnaCBTRE4gcmVsYXRlZCB1c2UgY2FzZSBkcmFmdCAoaHR0cDov L3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtbW0tc2RuLXZjLXZuLW9uLWRlbWFuZC11c2UtY2Fz ZS0wMSksIEkgYW0gbm90IHN1cmUgdGhpcyBpcyByZWxhdGVkIHRvIElSUy4gDQoNCkJlc3QgcmVn YXJkcywNCk1hY2gNCg0KPiAtLS0tLdPKvP7Urbz+LS0tLS0NCj4gt6K8/sjLOiBBbGlhIEF0bGFz IFttYWlsdG86YWthdGxhc0BnbWFpbC5jb21dDQo+ILeiy83KsbzkOiAyMDEyxOo41MIxN8jVIDEw OjEzDQo+IMrVvP7IyzogTWFjaCBDaGVuDQo+ILOty806IFNoYWgsIEhpbWFuc2h1OyBVVFRBUk8s IEpBTUVTOyBEdXR0YSwgUHJhbmphbCBLIChQcmFuamFsKTsNCj4gaXJzLWRpc2N1c3NAaWV0Zi5v cmcNCj4g1vfM4jogUmU6ILTwuLQ6IFtpcnMtZGlzY3Vzc10gSVJTIGNvbW1lbnRzDQo+IA0KPiBI aSBNYWNoLA0KPiANCj4gUmlnaHQgLSB0aGF0IGlzIG9uZSByZWFzb24gd2h5IEknbSBub3Qgc3Vy ZSB0aGF0IGEgQ1NQRiBjb21wdXRhdGlvbg0KPiBwaWVjZSBpcyBuZWVkZWQgZm9yIHRoZSBSU1ZQ IHN1Yi1pbnRlcmZhY2UuICBPbiB0aGUgb3RoZXIgc2lkZSwNCj4gdGhlcmUncyBiZW5lZml0IHRv IG5vdCByZXF1aXJpbmcgYW4gYXBwbGljYXRpb24gdG8gdW5kZXJzdGFuZCB0b28gbWFueQ0KPiBk aWZmZXJlbnQgcHJvdG9jb2xzLg0KPiANCj4gV2UgbmVlZCB0byBkaXNjdXNzIHdoYXQgc2NvcGUg bWFrZXMgc2Vuc2UgZm9yIHRoZSBzdWItaW50ZXJmYWNlcy4gIEkNCj4gdGhpbmsgdGhlIHVzZS1j YXNlcyB3aWxsIGRyaXZlIHRoaXMuDQo+IA0KPiBBbGlhDQo+IA0KPiBPbiBUaHUsIEF1ZyAxNiwg MjAxMiBhdCAxMDowNiBQTSwgTWFjaCBDaGVuIDxtYWNoLmNoZW5AaHVhd2VpLmNvbT4NCj4gd3Jv dGU6DQo+ID4gSGkgQWxpYSwNCj4gPg0KPiA+IEkgYW0gYSBsaXR0bGUgY29uZnVzZWQsIHRoZSBz YWlkIFJTVlAgc3ViLWludGVyZmFjZSAob24tZGVtYW5kIENTUEYgaW50ZXJmYWNlKQ0KPiBzZWVt cyB3aGF0IGV4YWN0bHkgUENFUCBkb2VzIHRvZGF5LiBNeSB1bmRlcnN0YW5kaW5nIG9mIElSUyBp cyB0aGF0IGl0IG1heSBiZQ0KPiBjb21wbGVtZW50YXJ5IG9uIHRvcG9sb2d5IGRpc2NvdmVyeS4N Cj4gPg0KPiA+IEJlc3QgcmVnYXJkcywNCj4gPiBNYWNoDQo+ID4NCj4gPj4gLS0tLS3Tyrz+1K28 /i0tLS0tDQo+ID4+ILeivP7IyzogaXJzLWRpc2N1c3MtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRv Omlycy1kaXNjdXNzLWJvdW5jZXNAaWV0Zi5vcmddDQo+ILT6DQo+ID4+ILHtIEFsaWEgQXRsYXMN Cj4gPj4gt6LLzcqxvOQ6IDIwMTLE6jjUwjE3yNUgOTo0NQ0KPiA+PiDK1bz+yMs6IFNoYWgsIEhp bWFuc2h1DQo+ID4+ILOty806IFVUVEFSTywgSkFNRVM7IER1dHRhLCBQcmFuamFsIEsgKFByYW5q YWwpOyBpcnMtZGlzY3Vzc0BpZXRmLm9yZw0KPiA+PiDW98ziOiBSZTogW2lycy1kaXNjdXNzXSBJ UlMgY29tbWVudHMNCj4gPj4NCj4gPj4gSSdtIG5vdCBlbnRpcmVseSBjbGVhciBvbiB0aGUgbW9k ZWwgb3IgcXVlc3Rpb24geW91IGFyZSBhc2tpbmcuICBBbg0KPiA+PiBhcHBsaWNhdGlvbiBjb3Vs ZCBsZWFybiB0b3BvbG9neSB2aWEgSVJTIHRvIHRoZSBhcHByb3ByaWF0ZSBJUlMNCj4gPj4gYWdl bnRzLCBkbyBDU1BGIGNvbXB1dGF0aW9ucywgYW5kIHN1cHBvcnQgYSBzaWduYWxpbmcvQ1NQRi1s aWtlDQo+ID4+IHN1Yi1pbnRlcmZhY2UgKGlmIHdlIGRlZmluZSBzdWNoIGZvciBJUlMpIGFzIGFu IElSUyBhZ2VudC4gIEFub3RoZXINCj4gPj4gYXBwbGljYXRpb24gY291bGQgcXVlcnkgdGhlIGZp cnN0IGZvciB0aGUgQ1NQRiByZXN1bHRzIGFuZCB0aGVuIHVzZQ0KPiA+PiBJUlMgdG8gdHJpZ2dl ciBzaWduYWxpbmcgb24gdGhlIGFwcHJvcHJpYXRlIGRldmljZS4NCj4gPj4NCj4gPj4gSSdtIG5v dCBzdXJlIGlmIGl0IG1ha2VzIHNlbnNlIHRvIGhhdmUgYW4gSVJTIHN1Yi1pbnRlcmZhY2UgdGhh dA0KPiA+PiByZXF1ZXN0cyBDU1BGIGNvbXB1dGF0aW9uLCBidXQgaXQgbWlnaHQgY29tZSBhcyBw YXJ0IG9mIGFuIFJTVlANCj4gPj4gc3ViLWludGVyZmFjZSB0byB0cmlnZ2VyIHNpZ25hbGluZy4g IFdlJ2xsIGhhdmUgdG8gc2VlIGFib3V0DQo+ID4+IHVzZS1jYXNlcy4NCj4gPj4NCj4gPj4gSSBk b24ndCBzZWUgYSBzdHJvbmcgbW90aXZhdGlvbiB0byBkdXBsaWNhdGUgZXhpc3Rpbmcgd29yay4N Cj4gPj4NCj4gPj4gQWxpYQ0KPiA+Pg0KPiA+PiBPbiBUaHUsIEF1ZyAxNiwgMjAxMiBhdCAyOjQ2 IFBNLCBTaGFoLCBIaW1hbnNodSA8aHNoYWhAY2llbmEuY29tPg0KPiB3cm90ZToNCj4gPj4gPiBJ IHdhcyB3b25kZXJpbmcgaWYgUENFIGFuZCBJUlMgY291bGQgaGF2ZSBvdmVybGFwcGluZyBmdW5j dGlvbmFsaXR5Lg0KPiA+PiA+DQo+ID4+ID4gTWVhbmluZywgY2FuIGFuIElSUyBpbnRlcmZhY2Ug dXNlciBhdCBib3RoIGVuZHMgKG5vZGUgYW5kIGNvbnRyb2xsZXIpIGJlIGENCj4gPj4gbm9uLVBD RSBlbnRpdHkgYW5kIHBlcmZvcm0NCj4gPj4gPiB0aGUgc2FtZSBzZXJ2aWNlIGFzIHdoYXQgUENF IGRvZXM/DQo+ID4+ID4NCj4gPj4gPiBJdCBzZWVtcyBsaWtlIHlvdSBhcmUgc2F5aW5nIHRoYXQg Y291bGQgd29yayBjby1vcGVyYXRpdmVseS4uLg0KPiA+PiA+DQo+ID4+ID4gVGhhbmtzLA0KPiA+ PiA+IGhpbWFuc2h1DQo+ID4+DQo+ID4+ID09c25pcD09PQ0KPiA+PiBfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+PiBpcnMtZGlzY3VzcyBtYWlsaW5n IGxpc3QNCj4gPj4gaXJzLWRpc2N1c3NAaWV0Zi5vcmcNCj4gPj4gaHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9pcnMtZGlzY3Vzcw0K Return-Path: 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 0DE5821F8570 for ; Thu, 16 Aug 2012 19:19:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.361 X-Spam-Level: X-Spam-Status: No, score=-9.361 tagged_above=-999 required=5 tests=[AWL=1.238, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 7Gtm97RvF5lj for ; Thu, 16 Aug 2012 19:19:17 -0700 (PDT) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id 5C8A021F856F for ; Thu, 16 Aug 2012 19:19:17 -0700 (PDT) Received: from inbansmailrelay1.in.alcatel-lucent.com (h135-250-11-31.lucent.com [135.250.11.31]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id q7H2JAu4013971 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 16 Aug 2012 21:19:13 -0500 (CDT) Received: from INBANSXCHHUB02.in.alcatel-lucent.com (inbansxchhub02.in.alcatel-lucent.com [135.250.12.35]) by inbansmailrelay1.in.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id q7H2JA10005365 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 17 Aug 2012 07:49:10 +0530 Received: from INBANSXCHMBSA3.in.alcatel-lucent.com ([135.250.12.50]) by INBANSXCHHUB02.in.alcatel-lucent.com ([135.250.12.35]) with mapi; Fri, 17 Aug 2012 07:49:09 +0530 From: "Dutta, Pranjal K (Pranjal)" To: Alia Atlas Date: Fri, 17 Aug 2012 07:49:07 +0530 Thread-Topic: [irs-discuss] IRS comments Thread-Index: Ac18HZ9JnoL4ZA9oSFW4yLTyQwH1bAAAHraA Message-ID: References: <812700A304640D4292205D5E83FC59E1061C211D@p-embx01-eq.jnpr.net> <502D2692.2030105@cttc.es> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 Cc: Ramon Casellas , "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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Aug 2012 02:19:19 -0000 I believe if IRS needs to address centralized SPF compute then it needs to = be a generic approach, irrespective of whether a topology offers LFA/MRT. T= hus I see a limited scope since FIB convergence would be a major concern in= general, although this is a too early statement to make. As I mentioned I = would be very cautious on such approach. Thanks, Pranjal=20 -----Original Message----- From: Alia Atlas [mailto:akatlas@gmail.com]=20 Sent: Thursday, August 16, 2012 7:11 PM To: Dutta, Pranjal K (Pranjal) Cc: Ramon Casellas; irs-discuss@ietf.org Subject: Re: [irs-discuss] IRS comments If there are always IP-FRR alternates that can be used and only a single covered failure has happened, then the slow path reconvergence needn't impact traffic (ignoring the issue of u-loops which we do understand how to handle). As for MRT, the advantage is that it guarantees there'll always be an alternate, unlike LFA. Some method has to be used to get that level of coverage - depending on how bad the FIB convergence times would be. Alia On Thu, Aug 16, 2012 at 10:06 PM, Dutta, Pranjal K (Pranjal) wrote: > > IP-FRR/LFA can mitigate one aspect of the problem but most of FIB converg= ence issues in FRR based solutions arise rather during slow > path convergence after a fast failover. When SPF recompute after > the FRR switch requires touching the flows again (e.g SPF recompute > chose a new primary next-hop) then tricks in FIB convergence matters. > So I would be a bit cautious...MRT etc may not be available in all > topologies. > > Thanks, > Pranjal > > -----Original Message----- > From: Alia Atlas [mailto:akatlas@gmail.com] > Sent: Thursday, August 16, 2012 6:50 PM > To: Dutta, Pranjal K (Pranjal) > Cc: Ramon Casellas; irs-discuss@ietf.org > Subject: Re: [irs-discuss] IRS comments > > On Thu, Aug 16, 2012 at 7:41 PM, Dutta, Pranjal K (Pranjal) > wrote: >> Thanks for detailed explanation. My question on LSA flooding was not in = the context of PCE or CSPF/TE-DB but on the issue of "regular/unconstrained= " SPF computation in IGPs. The dynamics between a) CSPF on TE-DB and b) reg= ular SPF on each link state change in a network are much different. My conc= ern was primarily on b) - I don't see what it achieves and in fact may degr= ade FIB convergence performance abysmally. > > [Alia] What it could accomplish is allowing other types of algorithms > than simple SPF for computing routes. As for FIB convergence, this > is certainly a concern. I do think that fast-reroute technology could > be used to mitigate the problem - but only really for single failures. > >> As Alia has clarified, we haven't heard of any clear, realistic use case= of b). I agree with you that missing pieces in PCE may be addressed thru I= RS. >> >> Thanks, >> Pranjal >> >> >> >> -----Original Message----- >> From: Ramon Casellas [mailto:ramon.casellas@cttc.es] >> Sent: Thursday, August 16, 2012 9:58 AM >> To: Dutta, Pranjal K (Pranjal) >> Cc: Alia Atlas; irs-discuss@ietf.org >> Subject: Re: [irs-discuss] IRS comments >> >> On 08/16/2012 06:14 PM, Dutta, Pranjal K (Pranjal) 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 pr= ecisely 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 OS= PF/ISIS as it is done today. So routers would build neighboring relationshi= p/adjacencies to participate in flooding and each router builds its LSDB. >>> >>> Then the IRS "application" would track LSDB changes and pull up the "di= ffs" from each router (thru "controller") whenever there is a change. The a= pplication 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? >>> >> >> >> Pranjal, all, >> >> My two cents. Apologies if this is well known, I am not sure I fully >> grasped your question... >> >> IMHO, the idea of separating LSA flooding from CSPF computation has >> indeed been a current topic for a while, and when it is tied to the idea >> of offloading the CSPF computation to a dedicated centralized server >> (for example a PCE), I would guess/say that this is usually scoped and >> applies to the case when one formally decouples the control plane from >> the data plane (thus constructing a LSDB and establishing adjacencies in >> the control plane network and also constructing a separated Traffic >> Engineering Database or TED, which is described via opaque LSAs). >> >> In this particular scenario, the CSPF refers to /applies to the >> dataplane only (as is done in GMPLS/PCE), and one still needs SPF for >> the addresses in the DCN. In other words, OSPF-TE is used to disseminate >> data plane (TE) link/node attribute changes (in addition to what OSFPv2 >> already does) and for this establishes routing adjacencies and the PCE >> performs CSPF on the TED, which can be a completely different topology. >> >> However, regarding your question "how different from a PCE", I would say >> these are complementary : first a) the PCE architecture does not specify >> how it obtains the Traffic Engineering Database (TED) to construct the >> directed graph on which it operates (i.e., performs CSPF, usually upon >> request); the PCE does not usually care much about the control plane >> topology and, b) what you refer to "push to each router" and "inject >> entries into the RIB" is completely orthogonal to a PCE. >> >> For a), and as stated previously in the list, a common way is to be a >> passive listener or to sniff LSAs with opaque (MPLS TE, area-wide) or to >> contact a topology server or NMS that has the current topology (TED). >> In other words, a PCE is a decoupled functional component and the >> protocol (PCEP) only specifies the interface to request path >> computations. Even if one uses a PCE and a lightweight LSA flooding >> protocol, SPF still needs to be executed by nodes to "forward" control >> packets, usually using the uncontrained shortest IP route. For b) note >> that, as of now, there is no standard way by which a PCE can configure >> the dataplane by itself. By "configure the dataplane" one can mean to >> "trigger" the establishment of LSPs via RSVP-TE signaling, or configure >> the cross-connects via OpenFlow or to set up state in the datapath >> (could even be configuring the RIB), somehow. >> >> Recently, Ed has started work in stateful PCE, and it is possible that >> in the future it will have the capability to "command" the establishment >> of connections. >> >> In summary, I see the (generic) relationship between PCE and IRS in two >> main ways: >> >> * As a means to communicate / obtain the TED, typically constructed via >> OSPF-TE opaque LSAs. This would be an alternative to existing methods / >> current practice. Another main driver for this is the Hierarchical PCE >> (H-PCE) in case a parent PCE needs to know about an (aggregated) >> topology within a (child) domain, since parent / child PCEs may not be >> in the same IGP area. >> In this sense, and as stated in the list, for this, other considered >> solutions are BGPLS / north bound interfaces or to use notify (PCNtf) >> messages wrapping TE LSAs for this. >> >> * As a means to define data plane state (much like OpenFlow) once a Path >> has been computed. >> >> Imho these are two areas which the PCE architecture and protocol do not >> currently cover and in which an architecture such as IRS could be helpfu= l. >> >> Hope this helps (a little!) >> >> Best regards >> >> Ramon >> >> -- >> Ramon Casellas, Ph.D. >> Research Associate - Optical Networking Area --http://wikiona.cttc.es >> CTTC - Centre Tecnol=F2gic de Telecomunicacions de Catalunya, PMT Ed B4 >> Av. Carl Friedrich Gauss, 7 - 08860 Castelldefels (Barcelona) - Spain >> Tel.: +34 93 645 29 00 -- Fax. +34 93 645 29 01 >> >> >> Return-Path: 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 8008D21F853A for ; Thu, 16 Aug 2012 19:13:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.249 X-Spam-Level: X-Spam-Status: No, score=0.249 tagged_above=-999 required=5 tests=[AWL=-3.786, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, CN_BODY_35=0.339, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_ENC_GB2312=1.345] 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 Kbh680sgYYw6 for ; Thu, 16 Aug 2012 19:13:18 -0700 (PDT) Received: from mail-gh0-f172.google.com (mail-gh0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id D50E821F8535 for ; Thu, 16 Aug 2012 19:13:17 -0700 (PDT) Received: by ghbg16 with SMTP id g16so3946377ghb.31 for ; Thu, 16 Aug 2012 19:13:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=NptiIEc3drt6pZarT0nSl03+RPBDnmt+dqiZB94H0KM=; b=N4X++l6VCYIsyJLfibnCu8kNuCmT18u4ZQ4gAxBKeNE2lvnOdt7h9HUsA1rvueYnWz Y9An8QADTSCdUOBHg0qlVEoIdDOcbGrJneRXMEEklfqPXQ2mPXvQrNiDiOQdQfxxopbk BHdSWs5nJeFRaBfFGOGg1kfWYAiKGRp9pyKgXLNieaTUi70/vfF5AhQTPbth5MwJwW54 1PU5sCjr/hS3pV8VFSrAUt+q/ADYzrXkEnz771sfmq5Ab4d+1/GrW7+RKIQM83MJHFbS JdR+jYmaCkKNWDDK5rshePwhIZYuQtLYYjwL8bYmWmuaYSosZ/hwrni3B5Olo9ZJvByG ZGjA== MIME-Version: 1.0 Received: by 10.50.149.202 with SMTP id uc10mr294693igb.2.1345169597006; Thu, 16 Aug 2012 19:13:17 -0700 (PDT) Received: by 10.50.91.135 with HTTP; Thu, 16 Aug 2012 19:13:16 -0700 (PDT) In-Reply-To: References: <812700A304640D4292205D5E83FC59E1061C211D@p-embx01-eq.jnpr.net> <3512BB31280C39448A9880F61DD54CEB09C07E@xmb-aln-x09.cisco.com> Date: Thu, 16 Aug 2012 22:13:16 -0400 Message-ID: From: Alia Atlas To: Mach Chen Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: quoted-printable Cc: "UTTARO, JAMES" , "Dutta, Pranjal K \(Pranjal\)" , "Shah, Himanshu" , "irs-discuss@ietf.org" Subject: Re: [irs-discuss] =?gb2312?b?tPC4tDogIElSUyBjb21tZW50cw==?= X-BeenThere: irs-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Aug 2012 02:13:18 -0000 Hi Mach, Right - that is one reason why I'm not sure that a CSPF computation piece is needed for the RSVP sub-interface. On the other side, there's benefit to not requiring an application to understand too many different protocols. We need to discuss what scope makes sense for the sub-interfaces. I think the use-cases will drive this. Alia On Thu, Aug 16, 2012 at 10:06 PM, Mach Chen wrote: > Hi Alia, > > I am a little confused, the said RSVP sub-interface (on-demand CSPF inter= face) seems what exactly PCEP does today. My understanding of IRS is that i= t may be complementary on topology discovery. > > Best regards, > Mach > >> -----=D3=CA=BC=FE=D4=AD=BC=FE----- >> =B7=A2=BC=FE=C8=CB: irs-discuss-bounces@ietf.org [mailto:irs-discuss-bou= nces@ietf.org] =B4=FA >> =B1=ED Alia Atlas >> =B7=A2=CB=CD=CA=B1=BC=E4: 2012=C4=EA8=D4=C217=C8=D5 9:45 >> =CA=D5=BC=FE=C8=CB: Shah, Himanshu >> =B3=AD=CB=CD: UTTARO, JAMES; Dutta, Pranjal K (Pranjal); irs-discuss@iet= f.org >> =D6=F7=CC=E2: Re: [irs-discuss] IRS comments >> >> I'm not entirely clear on the model or question you are asking. An >> application could learn topology via IRS to the appropriate IRS >> agents, do CSPF computations, and support a signaling/CSPF-like >> sub-interface (if we define such for IRS) as an IRS agent. Another >> application could query the first for the CSPF results and then use >> IRS to trigger signaling on the appropriate device. >> >> I'm not sure if it makes sense to have an IRS sub-interface that >> requests CSPF computation, but it might come as part of an RSVP >> sub-interface to trigger signaling. We'll have to see about >> use-cases. >> >> I don't see a strong motivation to duplicate existing work. >> >> Alia >> >> On Thu, Aug 16, 2012 at 2:46 PM, Shah, Himanshu wrote: >> > I was wondering if PCE and IRS could have overlapping functionality. >> > >> > Meaning, can an IRS interface user at both ends (node and controller) = be a >> non-PCE entity and perform >> > the same service as what PCE does? >> > >> > It seems like you are saying that could work co-operatively... >> > >> > Thanks, >> > himanshu >> >> =3D=3Dsnip=3D=3D=3D >> _______________________________________________ >> irs-discuss mailing list >> irs-discuss@ietf.org >> https://www.ietf.org/mailman/listinfo/irs-discuss Return-Path: 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 110FD21F848B for ; Thu, 16 Aug 2012 19:11:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.567 X-Spam-Level: X-Spam-Status: No, score=-3.567 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 BLb21nKcZk9a for ; Thu, 16 Aug 2012 19:11:29 -0700 (PDT) Received: from mail-gg0-f172.google.com (mail-gg0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id D0C3A21F8489 for ; Thu, 16 Aug 2012 19:11:28 -0700 (PDT) Received: by ggnh4 with SMTP id h4so3950659ggn.31 for ; Thu, 16 Aug 2012 19:11:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=LhK3BQM/pG0p+KUKo6pmLZNVaNJiqnmvOLarGhNG9Gs=; b=pgEMzdr/gvUiFv6eGJt3LsOaEFzs5dJ/QIMx88BIA9SNxTi398HqkLTn6GnJExkGF5 9pNUys/nNNGCNCwvoV+dIPGRff58mezbFPlhKZ2yHJ8DIiQBb9g6T4eO3/elfCMdNP+m xRSeQRwAL8+X+gtB0HexssWy0EjgAyeFe18NwDi24eRYrdIXY1ZBehKSmwN6O0BCYlig Ojcmfkoog3wZ8hITcUsqZDVrtyOfBpbxg2l32hulxKqx5s7Spc7dKs8WnW9CdQPDjc2C GhF5QHh8aXtj1KNAvG1Da/81NdpsFRaDgcT58LZ4mEhU5TxFQSyNL6V04X74AK9mukZ7 FdCg== MIME-Version: 1.0 Received: by 10.50.36.195 with SMTP id s3mr202959igj.63.1345169485076; Thu, 16 Aug 2012 19:11:25 -0700 (PDT) Received: by 10.50.91.135 with HTTP; Thu, 16 Aug 2012 19:11:24 -0700 (PDT) In-Reply-To: References: <812700A304640D4292205D5E83FC59E1061C211D@p-embx01-eq.jnpr.net> <502D2692.2030105@cttc.es> Date: Thu, 16 Aug 2012 22:11:24 -0400 Message-ID: From: Alia Atlas To: "Dutta, Pranjal K (Pranjal)" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Ramon Casellas , "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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Aug 2012 02:11:30 -0000 If there are always IP-FRR alternates that can be used and only a single covered failure has happened, then the slow path reconvergence needn't impact traffic (ignoring the issue of u-loops which we do understand how to handle). As for MRT, the advantage is that it guarantees there'll always be an alternate, unlike LFA. Some method has to be used to get that level of coverage - depending on how bad the FIB convergence times would be. Alia On Thu, Aug 16, 2012 at 10:06 PM, Dutta, Pranjal K (Pranjal) wrote: > > IP-FRR/LFA can mitigate one aspect of the problem but most of FIB converg= ence issues in FRR based solutions arise rather during slow > path convergence after a fast failover. When SPF recompute after > the FRR switch requires touching the flows again (e.g SPF recompute > chose a new primary next-hop) then tricks in FIB convergence matters. > So I would be a bit cautious...MRT etc may not be available in all > topologies. > > Thanks, > Pranjal > > -----Original Message----- > From: Alia Atlas [mailto:akatlas@gmail.com] > Sent: Thursday, August 16, 2012 6:50 PM > To: Dutta, Pranjal K (Pranjal) > Cc: Ramon Casellas; irs-discuss@ietf.org > Subject: Re: [irs-discuss] IRS comments > > On Thu, Aug 16, 2012 at 7:41 PM, Dutta, Pranjal K (Pranjal) > wrote: >> Thanks for detailed explanation. My question on LSA flooding was not in = the context of PCE or CSPF/TE-DB but on the issue of "regular/unconstrained= " SPF computation in IGPs. The dynamics between a) CSPF on TE-DB and b) reg= ular SPF on each link state change in a network are much different. My conc= ern was primarily on b) - I don't see what it achieves and in fact may degr= ade FIB convergence performance abysmally. > > [Alia] What it could accomplish is allowing other types of algorithms > than simple SPF for computing routes. As for FIB convergence, this > is certainly a concern. I do think that fast-reroute technology could > be used to mitigate the problem - but only really for single failures. > >> As Alia has clarified, we haven't heard of any clear, realistic use case= of b). I agree with you that missing pieces in PCE may be addressed thru I= RS. >> >> Thanks, >> Pranjal >> >> >> >> -----Original Message----- >> From: Ramon Casellas [mailto:ramon.casellas@cttc.es] >> Sent: Thursday, August 16, 2012 9:58 AM >> To: Dutta, Pranjal K (Pranjal) >> Cc: Alia Atlas; irs-discuss@ietf.org >> Subject: Re: [irs-discuss] IRS comments >> >> On 08/16/2012 06:14 PM, Dutta, Pranjal K (Pranjal) 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 pr= ecisely 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 OS= PF/ISIS as it is done today. So routers would build neighboring relationshi= p/adjacencies to participate in flooding and each router builds its LSDB. >>> >>> Then the IRS "application" would track LSDB changes and pull up the "di= ffs" from each router (thru "controller") whenever there is a change. The a= pplication 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? >>> >> >> >> Pranjal, all, >> >> My two cents. Apologies if this is well known, I am not sure I fully >> grasped your question... >> >> IMHO, the idea of separating LSA flooding from CSPF computation has >> indeed been a current topic for a while, and when it is tied to the idea >> of offloading the CSPF computation to a dedicated centralized server >> (for example a PCE), I would guess/say that this is usually scoped and >> applies to the case when one formally decouples the control plane from >> the data plane (thus constructing a LSDB and establishing adjacencies in >> the control plane network and also constructing a separated Traffic >> Engineering Database or TED, which is described via opaque LSAs). >> >> In this particular scenario, the CSPF refers to /applies to the >> dataplane only (as is done in GMPLS/PCE), and one still needs SPF for >> the addresses in the DCN. In other words, OSPF-TE is used to disseminate >> data plane (TE) link/node attribute changes (in addition to what OSFPv2 >> already does) and for this establishes routing adjacencies and the PCE >> performs CSPF on the TED, which can be a completely different topology. >> >> However, regarding your question "how different from a PCE", I would say >> these are complementary : first a) the PCE architecture does not specify >> how it obtains the Traffic Engineering Database (TED) to construct the >> directed graph on which it operates (i.e., performs CSPF, usually upon >> request); the PCE does not usually care much about the control plane >> topology and, b) what you refer to "push to each router" and "inject >> entries into the RIB" is completely orthogonal to a PCE. >> >> For a), and as stated previously in the list, a common way is to be a >> passive listener or to sniff LSAs with opaque (MPLS TE, area-wide) or to >> contact a topology server or NMS that has the current topology (TED). >> In other words, a PCE is a decoupled functional component and the >> protocol (PCEP) only specifies the interface to request path >> computations. Even if one uses a PCE and a lightweight LSA flooding >> protocol, SPF still needs to be executed by nodes to "forward" control >> packets, usually using the uncontrained shortest IP route. For b) note >> that, as of now, there is no standard way by which a PCE can configure >> the dataplane by itself. By "configure the dataplane" one can mean to >> "trigger" the establishment of LSPs via RSVP-TE signaling, or configure >> the cross-connects via OpenFlow or to set up state in the datapath >> (could even be configuring the RIB), somehow. >> >> Recently, Ed has started work in stateful PCE, and it is possible that >> in the future it will have the capability to "command" the establishment >> of connections. >> >> In summary, I see the (generic) relationship between PCE and IRS in two >> main ways: >> >> * As a means to communicate / obtain the TED, typically constructed via >> OSPF-TE opaque LSAs. This would be an alternative to existing methods / >> current practice. Another main driver for this is the Hierarchical PCE >> (H-PCE) in case a parent PCE needs to know about an (aggregated) >> topology within a (child) domain, since parent / child PCEs may not be >> in the same IGP area. >> In this sense, and as stated in the list, for this, other considered >> solutions are BGPLS / north bound interfaces or to use notify (PCNtf) >> messages wrapping TE LSAs for this. >> >> * As a means to define data plane state (much like OpenFlow) once a Path >> has been computed. >> >> Imho these are two areas which the PCE architecture and protocol do not >> currently cover and in which an architecture such as IRS could be helpfu= l. >> >> Hope this helps (a little!) >> >> Best regards >> >> Ramon >> >> -- >> Ramon Casellas, Ph.D. >> Research Associate - Optical Networking Area --http://wikiona.cttc.es >> CTTC - Centre Tecnol=F2gic de Telecomunicacions de Catalunya, PMT Ed B4 >> Av. Carl Friedrich Gauss, 7 - 08860 Castelldefels (Barcelona) - Spain >> Tel.: +34 93 645 29 00 -- Fax. +34 93 645 29 01 >> >> >> Return-Path: 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 1D57021F8514 for ; Thu, 16 Aug 2012 19:10:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.665 X-Spam-Level: X-Spam-Status: No, score=0.665 tagged_above=-999 required=5 tests=[AWL=-2.123, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, CN_BODY_35=0.339, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4, SARE_SUB_ENC_GB2312=1.345] 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 qzx4pIQFFglq for ; Thu, 16 Aug 2012 19:10:06 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 81E5321F8512 for ; Thu, 16 Aug 2012 19:10:06 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml201-edg.china.huawei.com) ([172.18.9.243]) by dfwrg02-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AIY18754; Thu, 16 Aug 2012 18:10:06 -0800 (PST) Received: from DFWEML406-HUB.china.huawei.com (10.193.5.131) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 16 Aug 2012 19:08:28 -0700 Received: from SZXEML403-HUB.china.huawei.com (10.82.67.35) by dfweml406-hub.china.huawei.com (10.193.5.131) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 16 Aug 2012 19:08:34 -0700 Received: from SZXEML511-MBS.china.huawei.com ([169.254.4.86]) by szxeml403-hub.china.huawei.com ([::1]) with mapi id 14.01.0323.003; Fri, 17 Aug 2012 10:06:55 +0800 From: Mach Chen To: Alia Atlas , "Shah, Himanshu" Thread-Topic: [irs-discuss] IRS comments Thread-Index: Ac1utoJXMLn1Fv5cTmO9ZkEBmEbA7gABwUJeAhOezIAAAeHBAAABnwCAAHz4WAAAYnx4AAADAtaAAAFAFIAAAWTiAAACsjgAAABFcQAAA0u0AAAADucAAAA1foAAAckFAAAHy5EAAAHV1YAAAdkdAAAEme+AAAUvGYAAFVTUAAADbfoAAAUkXwAADptygAARQljg Date: Fri, 17 Aug 2012 02:06:54 +0000 Message-ID: References: <812700A304640D4292205D5E83FC59E1061C211D@p-embx01-eq.jnpr.net> <3512BB31280C39448A9880F61DD54CEB09C07E@xmb-aln-x09.cisco.com> In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.96.190] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "UTTARO, JAMES" , "Dutta, Pranjal K \(Pranjal\)" , "irs-discuss@ietf.org" Subject: [irs-discuss] =?gb2312?b?tPC4tDogIElSUyBjb21tZW50cw==?= X-BeenThere: irs-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Aug 2012 02:10:07 -0000 SGkgQWxpYSwNCg0KSSBhbSBhIGxpdHRsZSBjb25mdXNlZCwgdGhlIHNhaWQgUlNWUCBzdWItaW50 ZXJmYWNlIChvbi1kZW1hbmQgQ1NQRiBpbnRlcmZhY2UpIHNlZW1zIHdoYXQgZXhhY3RseSBQQ0VQ IGRvZXMgdG9kYXkuIE15IHVuZGVyc3RhbmRpbmcgb2YgSVJTIGlzIHRoYXQgaXQgbWF5IGJlIGNv bXBsZW1lbnRhcnkgb24gdG9wb2xvZ3kgZGlzY292ZXJ5LiANCg0KQmVzdCByZWdhcmRzLA0KTWFj aA0KDQo+IC0tLS0t08q8/tStvP4tLS0tLQ0KPiC3orz+yMs6IGlycy1kaXNjdXNzLWJvdW5jZXNA aWV0Zi5vcmcgW21haWx0bzppcnMtZGlzY3Vzcy1ib3VuY2VzQGlldGYub3JnXSC0+g0KPiCx7SBB bGlhIEF0bGFzDQo+ILeiy83KsbzkOiAyMDEyxOo41MIxN8jVIDk6NDUNCj4gytW8/sjLOiBTaGFo LCBIaW1hbnNodQ0KPiCzrcvNOiBVVFRBUk8sIEpBTUVTOyBEdXR0YSwgUHJhbmphbCBLIChQcmFu amFsKTsgaXJzLWRpc2N1c3NAaWV0Zi5vcmcNCj4g1vfM4jogUmU6IFtpcnMtZGlzY3Vzc10gSVJT IGNvbW1lbnRzDQo+IA0KPiBJJ20gbm90IGVudGlyZWx5IGNsZWFyIG9uIHRoZSBtb2RlbCBvciBx dWVzdGlvbiB5b3UgYXJlIGFza2luZy4gIEFuDQo+IGFwcGxpY2F0aW9uIGNvdWxkIGxlYXJuIHRv cG9sb2d5IHZpYSBJUlMgdG8gdGhlIGFwcHJvcHJpYXRlIElSUw0KPiBhZ2VudHMsIGRvIENTUEYg Y29tcHV0YXRpb25zLCBhbmQgc3VwcG9ydCBhIHNpZ25hbGluZy9DU1BGLWxpa2UNCj4gc3ViLWlu dGVyZmFjZSAoaWYgd2UgZGVmaW5lIHN1Y2ggZm9yIElSUykgYXMgYW4gSVJTIGFnZW50LiAgQW5v dGhlcg0KPiBhcHBsaWNhdGlvbiBjb3VsZCBxdWVyeSB0aGUgZmlyc3QgZm9yIHRoZSBDU1BGIHJl c3VsdHMgYW5kIHRoZW4gdXNlDQo+IElSUyB0byB0cmlnZ2VyIHNpZ25hbGluZyBvbiB0aGUgYXBw cm9wcmlhdGUgZGV2aWNlLg0KPiANCj4gSSdtIG5vdCBzdXJlIGlmIGl0IG1ha2VzIHNlbnNlIHRv IGhhdmUgYW4gSVJTIHN1Yi1pbnRlcmZhY2UgdGhhdA0KPiByZXF1ZXN0cyBDU1BGIGNvbXB1dGF0 aW9uLCBidXQgaXQgbWlnaHQgY29tZSBhcyBwYXJ0IG9mIGFuIFJTVlANCj4gc3ViLWludGVyZmFj ZSB0byB0cmlnZ2VyIHNpZ25hbGluZy4gIFdlJ2xsIGhhdmUgdG8gc2VlIGFib3V0DQo+IHVzZS1j YXNlcy4NCj4gDQo+IEkgZG9uJ3Qgc2VlIGEgc3Ryb25nIG1vdGl2YXRpb24gdG8gZHVwbGljYXRl IGV4aXN0aW5nIHdvcmsuDQo+IA0KPiBBbGlhDQo+IA0KPiBPbiBUaHUsIEF1ZyAxNiwgMjAxMiBh dCAyOjQ2IFBNLCBTaGFoLCBIaW1hbnNodSA8aHNoYWhAY2llbmEuY29tPiB3cm90ZToNCj4gPiBJ IHdhcyB3b25kZXJpbmcgaWYgUENFIGFuZCBJUlMgY291bGQgaGF2ZSBvdmVybGFwcGluZyBmdW5j dGlvbmFsaXR5Lg0KPiA+DQo+ID4gTWVhbmluZywgY2FuIGFuIElSUyBpbnRlcmZhY2UgdXNlciBh dCBib3RoIGVuZHMgKG5vZGUgYW5kIGNvbnRyb2xsZXIpIGJlIGENCj4gbm9uLVBDRSBlbnRpdHkg YW5kIHBlcmZvcm0NCj4gPiB0aGUgc2FtZSBzZXJ2aWNlIGFzIHdoYXQgUENFIGRvZXM/DQo+ID4N Cj4gPiBJdCBzZWVtcyBsaWtlIHlvdSBhcmUgc2F5aW5nIHRoYXQgY291bGQgd29yayBjby1vcGVy YXRpdmVseS4uLg0KPiA+DQo+ID4gVGhhbmtzLA0KPiA+IGhpbWFuc2h1DQo+IA0KPiA9PXNuaXA9 PT0NCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4g aXJzLWRpc2N1c3MgbWFpbGluZyBsaXN0DQo+IGlycy1kaXNjdXNzQGlldGYub3JnDQo+IGh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaXJzLWRpc2N1c3MNCg== Return-Path: 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 8529F21F846C for ; Thu, 16 Aug 2012 19:06:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.399 X-Spam-Level: X-Spam-Status: No, score=-7.399 tagged_above=-999 required=5 tests=[AWL=-0.800, 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 HpQwuPs1uSvV for ; Thu, 16 Aug 2012 19:06:25 -0700 (PDT) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id 8F56521F843C for ; Thu, 16 Aug 2012 19:06:25 -0700 (PDT) Received: from ihemail2.lucent.com (h135-245-2-35.lucent.com [135.245.2.35]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id q7H26LDY028798 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 16 Aug 2012 21:06:21 -0500 (CDT) Received: from inbansmailrelay1.in.alcatel-lucent.com (h135-250-11-31.lucent.com [135.250.11.31]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id q7H26HOU027071 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 16 Aug 2012 21:06:20 -0500 (CDT) Received: from INBANSXCHHUB01.in.alcatel-lucent.com (inbansxchhub01.in.alcatel-lucent.com [135.250.12.32]) by inbansmailrelay1.in.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id q7H26HRD004950 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 17 Aug 2012 07:36:17 +0530 Received: from INBANSXCHMBSA3.in.alcatel-lucent.com ([135.250.12.50]) by INBANSXCHHUB01.in.alcatel-lucent.com ([135.250.12.32]) with mapi; Fri, 17 Aug 2012 07:36:17 +0530 From: "Dutta, Pranjal K (Pranjal)" To: Alia Atlas Date: Fri, 17 Aug 2012 07:36:14 +0530 Thread-Topic: [irs-discuss] IRS comments Thread-Index: Ac18GqX4md3CyRYlR0WqzkZPIcCSBgAANUyw Message-ID: References: <812700A304640D4292205D5E83FC59E1061C211D@p-embx01-eq.jnpr.net> <502D2692.2030105@cttc.es> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 Cc: Ramon Casellas , "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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Aug 2012 02:06:26 -0000 IP-FRR/LFA can mitigate one aspect of the problem but most of FIB convergen= ce issues in FRR based solutions arise rather during slow=20 path convergence after a fast failover. When SPF recompute after=20 the FRR switch requires touching the flows again (e.g SPF recompute=20 chose a new primary next-hop) then tricks in FIB convergence matters.=20 So I would be a bit cautious...MRT etc may not be available in all=20 topologies. Thanks, Pranjal=20 -----Original Message----- From: Alia Atlas [mailto:akatlas@gmail.com]=20 Sent: Thursday, August 16, 2012 6:50 PM To: Dutta, Pranjal K (Pranjal) Cc: Ramon Casellas; irs-discuss@ietf.org Subject: Re: [irs-discuss] IRS comments On Thu, Aug 16, 2012 at 7:41 PM, Dutta, Pranjal K (Pranjal) wrote: > Thanks for detailed explanation. My question on LSA flooding was not in t= he context of PCE or CSPF/TE-DB but on the issue of "regular/unconstrained"= SPF computation in IGPs. The dynamics between a) CSPF on TE-DB and b) regu= lar SPF on each link state change in a network are much different. My conce= rn was primarily on b) - I don't see what it achieves and in fact may degra= de FIB convergence performance abysmally. [Alia] What it could accomplish is allowing other types of algorithms than simple SPF for computing routes. As for FIB convergence, this is certainly a concern. I do think that fast-reroute technology could be used to mitigate the problem - but only really for single failures. > As Alia has clarified, we haven't heard of any clear, realistic use case = of b). I agree with you that missing pieces in PCE may be addressed thru IR= S. > > Thanks, > Pranjal > > > > -----Original Message----- > From: Ramon Casellas [mailto:ramon.casellas@cttc.es] > Sent: Thursday, August 16, 2012 9:58 AM > To: Dutta, Pranjal K (Pranjal) > Cc: Alia Atlas; irs-discuss@ietf.org > Subject: Re: [irs-discuss] IRS comments > > On 08/16/2012 06:14 PM, Dutta, Pranjal K (Pranjal) 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 pre= cisely 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 OSP= F/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 "dif= fs" from each router (thru "controller") whenever there is a change. The ap= plication 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? >> > > > Pranjal, all, > > My two cents. Apologies if this is well known, I am not sure I fully > grasped your question... > > IMHO, the idea of separating LSA flooding from CSPF computation has > indeed been a current topic for a while, and when it is tied to the idea > of offloading the CSPF computation to a dedicated centralized server > (for example a PCE), I would guess/say that this is usually scoped and > applies to the case when one formally decouples the control plane from > the data plane (thus constructing a LSDB and establishing adjacencies in > the control plane network and also constructing a separated Traffic > Engineering Database or TED, which is described via opaque LSAs). > > In this particular scenario, the CSPF refers to /applies to the > dataplane only (as is done in GMPLS/PCE), and one still needs SPF for > the addresses in the DCN. In other words, OSPF-TE is used to disseminate > data plane (TE) link/node attribute changes (in addition to what OSFPv2 > already does) and for this establishes routing adjacencies and the PCE > performs CSPF on the TED, which can be a completely different topology. > > However, regarding your question "how different from a PCE", I would say > these are complementary : first a) the PCE architecture does not specify > how it obtains the Traffic Engineering Database (TED) to construct the > directed graph on which it operates (i.e., performs CSPF, usually upon > request); the PCE does not usually care much about the control plane > topology and, b) what you refer to "push to each router" and "inject > entries into the RIB" is completely orthogonal to a PCE. > > For a), and as stated previously in the list, a common way is to be a > passive listener or to sniff LSAs with opaque (MPLS TE, area-wide) or to > contact a topology server or NMS that has the current topology (TED). > In other words, a PCE is a decoupled functional component and the > protocol (PCEP) only specifies the interface to request path > computations. Even if one uses a PCE and a lightweight LSA flooding > protocol, SPF still needs to be executed by nodes to "forward" control > packets, usually using the uncontrained shortest IP route. For b) note > that, as of now, there is no standard way by which a PCE can configure > the dataplane by itself. By "configure the dataplane" one can mean to > "trigger" the establishment of LSPs via RSVP-TE signaling, or configure > the cross-connects via OpenFlow or to set up state in the datapath > (could even be configuring the RIB), somehow. > > Recently, Ed has started work in stateful PCE, and it is possible that > in the future it will have the capability to "command" the establishment > of connections. > > In summary, I see the (generic) relationship between PCE and IRS in two > main ways: > > * As a means to communicate / obtain the TED, typically constructed via > OSPF-TE opaque LSAs. This would be an alternative to existing methods / > current practice. Another main driver for this is the Hierarchical PCE > (H-PCE) in case a parent PCE needs to know about an (aggregated) > topology within a (child) domain, since parent / child PCEs may not be > in the same IGP area. > In this sense, and as stated in the list, for this, other considered > solutions are BGPLS / north bound interfaces or to use notify (PCNtf) > messages wrapping TE LSAs for this. > > * As a means to define data plane state (much like OpenFlow) once a Path > has been computed. > > Imho these are two areas which the PCE architecture and protocol do not > currently cover and in which an architecture such as IRS could be helpful= . > > Hope this helps (a little!) > > Best regards > > Ramon > > -- > Ramon Casellas, Ph.D. > Research Associate - Optical Networking Area --http://wikiona.cttc.es > CTTC - Centre Tecnol=F2gic de Telecomunicacions de Catalunya, PMT Ed B4 > Av. Carl Friedrich Gauss, 7 - 08860 Castelldefels (Barcelona) - Spain > Tel.: +34 93 645 29 00 -- Fax. +34 93 645 29 01 > > > Return-Path: 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 CF01C21F844E for ; Thu, 16 Aug 2012 18:50:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.567 X-Spam-Level: X-Spam-Status: No, score=-3.567 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 CvRumQynQ3p7 for ; Thu, 16 Aug 2012 18:50:13 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id B909F21F8450 for ; Thu, 16 Aug 2012 18:50:13 -0700 (PDT) Received: by iabz21 with SMTP id z21so678099iab.31 for ; Thu, 16 Aug 2012 18:50:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=JAwlaMx1+cJX3bPzXa33Vxsl62ycWsXHUkuMP5pLVd8=; b=kcsff6kcZcMj70cSDL8wZ+QGQI38L9da7T3ztSaA0HIS2XOL1L/G0Kf7Mdn744sUms 8hXWf51JVNVbWyEWcvoXxmXs0qP6nqJ3rZw7gEixdqU7CreTTK/19E6dofYF6TUFFCuu a0BdeH/hwUgHcd1/bygig1WmOPt8PdPtteT5wpyBTk2BozW/k9P1N56bOYDqPvFyZ51u ldPZCt6grMp0A/rj/mhqYUlch4yl0LXpUedgPu41Fk5dmH667fgHEzqF4Kgp9veQEoon b0dBBVX644sPWMI99b33deyd2d+P6j/KvRPDQ7ZX6Z14pwq6p4G4XApWQfo/vviC+Syt H4vQ== MIME-Version: 1.0 Received: by 10.42.151.71 with SMTP id d7mr3023470icw.18.1345168213118; Thu, 16 Aug 2012 18:50:13 -0700 (PDT) Received: by 10.50.91.135 with HTTP; Thu, 16 Aug 2012 18:50:12 -0700 (PDT) In-Reply-To: References: <812700A304640D4292205D5E83FC59E1061C211D@p-embx01-eq.jnpr.net> <502D2692.2030105@cttc.es> Date: Thu, 16 Aug 2012 21:50:12 -0400 Message-ID: From: Alia Atlas To: "Dutta, Pranjal K (Pranjal)" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Ramon Casellas , "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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Aug 2012 01:50:15 -0000 On Thu, Aug 16, 2012 at 7:41 PM, Dutta, Pranjal K (Pranjal) wrote: > Thanks for detailed explanation. My question on LSA flooding was not in t= he context of PCE or CSPF/TE-DB but on the issue of "regular/unconstrained"= SPF computation in IGPs. The dynamics between a) CSPF on TE-DB and b) regu= lar SPF on each link state change in a network are much different. My conce= rn was primarily on b) - I don't see what it achieves and in fact may degra= de FIB convergence performance abysmally. [Alia] What it could accomplish is allowing other types of algorithms than simple SPF for computing routes. As for FIB convergence, this is certainly a concern. I do think that fast-reroute technology could be used to mitigate the problem - but only really for single failures. > As Alia has clarified, we haven't heard of any clear, realistic use case = of b). I agree with you that missing pieces in PCE may be addressed thru IR= S. > > Thanks, > Pranjal > > > > -----Original Message----- > From: Ramon Casellas [mailto:ramon.casellas@cttc.es] > Sent: Thursday, August 16, 2012 9:58 AM > To: Dutta, Pranjal K (Pranjal) > Cc: Alia Atlas; irs-discuss@ietf.org > Subject: Re: [irs-discuss] IRS comments > > On 08/16/2012 06:14 PM, Dutta, Pranjal K (Pranjal) 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 pre= cisely 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 OSP= F/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 "dif= fs" from each router (thru "controller") whenever there is a change. The ap= plication 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? >> > > > Pranjal, all, > > My two cents. Apologies if this is well known, I am not sure I fully > grasped your question... > > IMHO, the idea of separating LSA flooding from CSPF computation has > indeed been a current topic for a while, and when it is tied to the idea > of offloading the CSPF computation to a dedicated centralized server > (for example a PCE), I would guess/say that this is usually scoped and > applies to the case when one formally decouples the control plane from > the data plane (thus constructing a LSDB and establishing adjacencies in > the control plane network and also constructing a separated Traffic > Engineering Database or TED, which is described via opaque LSAs). > > In this particular scenario, the CSPF refers to /applies to the > dataplane only (as is done in GMPLS/PCE), and one still needs SPF for > the addresses in the DCN. In other words, OSPF-TE is used to disseminate > data plane (TE) link/node attribute changes (in addition to what OSFPv2 > already does) and for this establishes routing adjacencies and the PCE > performs CSPF on the TED, which can be a completely different topology. > > However, regarding your question "how different from a PCE", I would say > these are complementary : first a) the PCE architecture does not specify > how it obtains the Traffic Engineering Database (TED) to construct the > directed graph on which it operates (i.e., performs CSPF, usually upon > request); the PCE does not usually care much about the control plane > topology and, b) what you refer to "push to each router" and "inject > entries into the RIB" is completely orthogonal to a PCE. > > For a), and as stated previously in the list, a common way is to be a > passive listener or to sniff LSAs with opaque (MPLS TE, area-wide) or to > contact a topology server or NMS that has the current topology (TED). > In other words, a PCE is a decoupled functional component and the > protocol (PCEP) only specifies the interface to request path > computations. Even if one uses a PCE and a lightweight LSA flooding > protocol, SPF still needs to be executed by nodes to "forward" control > packets, usually using the uncontrained shortest IP route. For b) note > that, as of now, there is no standard way by which a PCE can configure > the dataplane by itself. By "configure the dataplane" one can mean to > "trigger" the establishment of LSPs via RSVP-TE signaling, or configure > the cross-connects via OpenFlow or to set up state in the datapath > (could even be configuring the RIB), somehow. > > Recently, Ed has started work in stateful PCE, and it is possible that > in the future it will have the capability to "command" the establishment > of connections. > > In summary, I see the (generic) relationship between PCE and IRS in two > main ways: > > * As a means to communicate / obtain the TED, typically constructed via > OSPF-TE opaque LSAs. This would be an alternative to existing methods / > current practice. Another main driver for this is the Hierarchical PCE > (H-PCE) in case a parent PCE needs to know about an (aggregated) > topology within a (child) domain, since parent / child PCEs may not be > in the same IGP area. > In this sense, and as stated in the list, for this, other considered > solutions are BGPLS / north bound interfaces or to use notify (PCNtf) > messages wrapping TE LSAs for this. > > * As a means to define data plane state (much like OpenFlow) once a Path > has been computed. > > Imho these are two areas which the PCE architecture and protocol do not > currently cover and in which an architecture such as IRS could be helpful= . > > Hope this helps (a little!) > > Best regards > > Ramon > > -- > Ramon Casellas, Ph.D. > Research Associate - Optical Networking Area --http://wikiona.cttc.es > CTTC - Centre Tecnol=F2gic de Telecomunicacions de Catalunya, PMT Ed B4 > Av. Carl Friedrich Gauss, 7 - 08860 Castelldefels (Barcelona) - Spain > Tel.: +34 93 645 29 00 -- Fax. +34 93 645 29 01 > > > Return-Path: 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 2F2D611E8091 for ; Thu, 16 Aug 2012 18:48:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.566 X-Spam-Level: X-Spam-Status: No, score=-3.566 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 bDENxPFGwoAe for ; Thu, 16 Aug 2012 18:48:03 -0700 (PDT) Received: from mail-gh0-f172.google.com (mail-gh0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id AFC8A21F84F2 for ; Thu, 16 Aug 2012 18:48:03 -0700 (PDT) Received: by ghbg16 with SMTP id g16so3931076ghb.31 for ; Thu, 16 Aug 2012 18:48:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=4m2wOeC0KTBbVReFUgccvXk+60m7OL5AKXXADvJqQHQ=; b=oW4rHSUSnOaz4xG7ED6Q/AYWPRS0nYLpCBp7h4GIn75CRotFikoTbVJJBYp7ASgpHk romLmE5DC0FgmD78QhmROHNvBzU7vQkU/48bKrc3aoaJ/J49jQyMdda6xYu+ABURq1Zk tZ9Zzlmo9UozDmUU91BYuPWTYwcP+SapM3yc5JlcLm7sgdTFOAfh30QddIGlPHuegybJ GiQMEBeb/pLe3eI/GUTPDSKic66YMCxcJWfbhb/mOTZuf6klCxWyVjnLw/Dg95/d8O2G dPfdegXOfvo4CVDFjmKuO1TPFy+jIPNOJD4MRKRrVX3pvaK/vI0Q9+37FKNI05bTNoYt OZwg== MIME-Version: 1.0 Received: by 10.50.209.8 with SMTP id mi8mr164050igc.63.1345168082784; Thu, 16 Aug 2012 18:48:02 -0700 (PDT) Received: by 10.50.91.135 with HTTP; Thu, 16 Aug 2012 18:48:02 -0700 (PDT) In-Reply-To: References: <812700A304640D4292205D5E83FC59E1061C211D@p-embx01-eq.jnpr.net> <3512BB31280C39448A9880F61DD54CEB09C07E@xmb-aln-x09.cisco.com> Date: Thu, 16 Aug 2012 21:48:02 -0400 Message-ID: From: Alia Atlas To: "Shah, Himanshu" Content-Type: text/plain; charset=ISO-8859-1 Cc: "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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Aug 2012 01:48:04 -0000 That's a good question and we need to figure out the appropriate boundaries for what constitutes the "Routing System". For instance, I'm not sure that it makes sense to be able to change the admin-status of a physical interface - but if one thinks about a use-case around creating an overlay network, I can see the need to create the tunnel, turn it into an interface, turn on OSPF across it, and then enable the interface. This is where I think that having clear motivating use-cases will help us define the borders for the sub-interfaces more clearly. Alia On Thu, Aug 16, 2012 at 2:56 PM, Shah, Himanshu wrote: > I used ifMIB info to refer to ifTable specific information for each interface as ifSpeed, ifOperStatus, ifAdminStatus, ifMTU, etc etc > Most of them are read but some are read/write - such as admin-status. > So for example, would IRS interface provide changing admin-status of an interface on a node? > > /himanshu ===snip=== Return-Path: 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 3A81811E809C for ; Thu, 16 Aug 2012 18:44:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.566 X-Spam-Level: X-Spam-Status: No, score=-3.566 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 XyarRkaH+nrZ for ; Thu, 16 Aug 2012 18:44:48 -0700 (PDT) Received: from mail-gg0-f172.google.com (mail-gg0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id AD0F811E8091 for ; Thu, 16 Aug 2012 18:44:48 -0700 (PDT) Received: by ggnh4 with SMTP id h4so3934510ggn.31 for ; Thu, 16 Aug 2012 18:44:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=wgkzvpLgjbCjzh/79PKhyAakb2SM5Z6YpusMUH3A2qI=; b=F4YlZ5FJED03xPfmK9UT3VPDCh/Bv0iQSF/eng6ddrTzNwF4b55N4UP1TqCsHOFWnd nqUO5Djpx2zNQtE+LM2Telm1vEyB9ztCWPhaGVpHfw6HvHy6oWF4t95AZOwG9Jyxb5CJ vl99ANi+o7PNNXvX0qolxtAapiJzQsI8cPibfNCYF2NPRkAeAxttTsxG749g2g6qHiF8 V3S51NGFgAqhWUnUg+woHCnr9L1LpZ1Btrj6BHhbkx2gIlaII8yNy1ypJzNgabhxcnxP vHSb5Mdg760wxQMVO8Gn7tezbz4Sa4VtDA8IhPCiwWVvEGE8zFIa3rJ3ozcAxuYjU4Wf xzgw== MIME-Version: 1.0 Received: by 10.50.149.202 with SMTP id uc10mr247453igb.2.1345167887922; Thu, 16 Aug 2012 18:44:47 -0700 (PDT) Received: by 10.50.91.135 with HTTP; Thu, 16 Aug 2012 18:44:47 -0700 (PDT) In-Reply-To: References: <812700A304640D4292205D5E83FC59E1061C211D@p-embx01-eq.jnpr.net> <3512BB31280C39448A9880F61DD54CEB09C07E@xmb-aln-x09.cisco.com> Date: Thu, 16 Aug 2012 21:44:47 -0400 Message-ID: From: Alia Atlas To: "Shah, Himanshu" Content-Type: text/plain; charset=ISO-8859-1 Cc: "UTTARO, JAMES" , "Dutta, Pranjal K \(Pranjal\)" , "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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Aug 2012 01:44:49 -0000 I'm not entirely clear on the model or question you are asking. An application could learn topology via IRS to the appropriate IRS agents, do CSPF computations, and support a signaling/CSPF-like sub-interface (if we define such for IRS) as an IRS agent. Another application could query the first for the CSPF results and then use IRS to trigger signaling on the appropriate device. I'm not sure if it makes sense to have an IRS sub-interface that requests CSPF computation, but it might come as part of an RSVP sub-interface to trigger signaling. We'll have to see about use-cases. I don't see a strong motivation to duplicate existing work. Alia On Thu, Aug 16, 2012 at 2:46 PM, Shah, Himanshu wrote: > I was wondering if PCE and IRS could have overlapping functionality. > > Meaning, can an IRS interface user at both ends (node and controller) be a non-PCE entity and perform > the same service as what PCE does? > > It seems like you are saying that could work co-operatively... > > Thanks, > himanshu ==snip=== Return-Path: 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 9B6BF21F8499 for ; Thu, 16 Aug 2012 16:41:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.336 X-Spam-Level: X-Spam-Status: No, score=-9.336 tagged_above=-999 required=5 tests=[AWL=1.263, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 kP7DCPZEBDCf for ; Thu, 16 Aug 2012 16:41:34 -0700 (PDT) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id 84C0721F849D for ; Thu, 16 Aug 2012 16:41:34 -0700 (PDT) Received: from inbansmailrelay1.in.alcatel-lucent.com (h135-250-11-31.lucent.com [135.250.11.31]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id q7GNfKqI008940 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 16 Aug 2012 18:41:25 -0500 (CDT) Received: from INBANSXCHHUB01.in.alcatel-lucent.com (inbansxchhub01.in.alcatel-lucent.com [135.250.12.32]) by inbansmailrelay1.in.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id q7GNfHHi000505 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 17 Aug 2012 05:11:19 +0530 Received: from INBANSXCHMBSA3.in.alcatel-lucent.com ([135.250.12.50]) by INBANSXCHHUB01.in.alcatel-lucent.com ([135.250.12.32]) with mapi; Fri, 17 Aug 2012 05:11:17 +0530 From: "Dutta, Pranjal K (Pranjal)" To: Ramon Casellas Date: Fri, 17 Aug 2012 05:11:14 +0530 Thread-Topic: [irs-discuss] IRS comments Thread-Index: Ac170FD8YsogUq94QjGrnd+7/mQr+QALs+4g Message-ID: References: <812700A304640D4292205D5E83FC59E1061C211D@p-embx01-eq.jnpr.net> <502D2692.2030105@cttc.es> In-Reply-To: <502D2692.2030105@cttc.es> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 Cc: "irs-discuss@ietf.org" , Alia Atlas 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Aug 2012 23:41:35 -0000 Thanks for detailed explanation. My question on LSA flooding was not in the= context of PCE or CSPF/TE-DB but on the issue of "regular/unconstrained" S= PF computation in IGPs. The dynamics between a) CSPF on TE-DB and b) regula= r SPF on each link state change in a network are much different. My concern= was primarily on b) - I don't see what it achieves and in fact may degrade= FIB convergence performance abysmally.=20 As Alia has clarified, we haven't heard of any clear, realistic use case of= b). I agree with you that missing pieces in PCE may be addressed thru IRS.= =20 Thanks, Pranjal -----Original Message----- From: Ramon Casellas [mailto:ramon.casellas@cttc.es]=20 Sent: Thursday, August 16, 2012 9:58 AM To: Dutta, Pranjal K (Pranjal) Cc: Alia Atlas; irs-discuss@ietf.org Subject: Re: [irs-discuss] IRS comments On 08/16/2012 06:14 PM, Dutta, Pranjal K (Pranjal) 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 prec= isely 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 "diff= s" from each router (thru "controller") whenever there is a change. The app= lication would compute SPF on behalf of each router (LSDB). The result of t= he 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? > Pranjal, all, My two cents. Apologies if this is well known, I am not sure I fully=20 grasped your question... IMHO, the idea of separating LSA flooding from CSPF computation has=20 indeed been a current topic for a while, and when it is tied to the idea=20 of offloading the CSPF computation to a dedicated centralized server=20 (for example a PCE), I would guess/say that this is usually scoped and=20 applies to the case when one formally decouples the control plane from=20 the data plane (thus constructing a LSDB and establishing adjacencies in=20 the control plane network and also constructing a separated Traffic=20 Engineering Database or TED, which is described via opaque LSAs). In this particular scenario, the CSPF refers to /applies to the=20 dataplane only (as is done in GMPLS/PCE), and one still needs SPF for=20 the addresses in the DCN. In other words, OSPF-TE is used to disseminate=20 data plane (TE) link/node attribute changes (in addition to what OSFPv2=20 already does) and for this establishes routing adjacencies and the PCE=20 performs CSPF on the TED, which can be a completely different topology. However, regarding your question "how different from a PCE", I would say=20 these are complementary : first a) the PCE architecture does not specify=20 how it obtains the Traffic Engineering Database (TED) to construct the=20 directed graph on which it operates (i.e., performs CSPF, usually upon=20 request); the PCE does not usually care much about the control plane=20 topology and, b) what you refer to "push to each router" and "inject=20 entries into the RIB" is completely orthogonal to a PCE. For a), and as stated previously in the list, a common way is to be a=20 passive listener or to sniff LSAs with opaque (MPLS TE, area-wide) or to=20 contact a topology server or NMS that has the current topology (TED).=20 In other words, a PCE is a decoupled functional component and the=20 protocol (PCEP) only specifies the interface to request path=20 computations. Even if one uses a PCE and a lightweight LSA flooding=20 protocol, SPF still needs to be executed by nodes to "forward" control=20 packets, usually using the uncontrained shortest IP route. For b) note=20 that, as of now, there is no standard way by which a PCE can configure=20 the dataplane by itself. By "configure the dataplane" one can mean to=20 "trigger" the establishment of LSPs via RSVP-TE signaling, or configure=20 the cross-connects via OpenFlow or to set up state in the datapath=20 (could even be configuring the RIB), somehow. Recently, Ed has started work in stateful PCE, and it is possible that=20 in the future it will have the capability to "command" the establishment=20 of connections. In summary, I see the (generic) relationship between PCE and IRS in two=20 main ways: * As a means to communicate / obtain the TED, typically constructed via=20 OSPF-TE opaque LSAs. This would be an alternative to existing methods /=20 current practice. Another main driver for this is the Hierarchical PCE=20 (H-PCE) in case a parent PCE needs to know about an (aggregated)=20 topology within a (child) domain, since parent / child PCEs may not be=20 in the same IGP area. In this sense, and as stated in the list, for this, other considered=20 solutions are BGPLS / north bound interfaces or to use notify (PCNtf)=20 messages wrapping TE LSAs for this. * As a means to define data plane state (much like OpenFlow) once a Path=20 has been computed. Imho these are two areas which the PCE architecture and protocol do not=20 currently cover and in which an architecture such as IRS could be helpful. Hope this helps (a little!) Best regards Ramon --=20 Ramon Casellas, Ph.D. Research Associate - Optical Networking Area --http://wikiona.cttc.es CTTC - Centre Tecnol=F2gic de Telecomunicacions de Catalunya, PMT Ed B4 Av. Carl Friedrich Gauss, 7 - 08860 Castelldefels (Barcelona) - Spain Tel.: +34 93 645 29 00 -- Fax. +34 93 645 29 01 Return-Path: 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 16FE821F853E for ; Thu, 16 Aug 2012 11:56:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.155 X-Spam-Level: X-Spam-Status: No, score=-3.155 tagged_above=-999 required=5 tests=[AWL=0.110, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-1] 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 50sGiKakTTNn for ; Thu, 16 Aug 2012 11:56:39 -0700 (PDT) Received: from mx0a-00103a01.pphosted.com (mx0a-00103a01.pphosted.com [67.231.144.234]) by ietfa.amsl.com (Postfix) with ESMTP id 2FE3E21F852E for ; Thu, 16 Aug 2012 11:56:39 -0700 (PDT) Received: from pps.filterd (m0000419 [127.0.0.1]) by mx0a-00103a01.pphosted.com (8.14.4/8.14.4) with SMTP id q7GIse2i008286; Thu, 16 Aug 2012 14:56:38 -0400 Received: from mdwexght01.ciena.com (LIN1-118-36-28.ciena.com [63.118.36.28]) by mx0a-00103a01.pphosted.com with ESMTP id 16s6hpr0a9-2 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 16 Aug 2012 14:56:37 -0400 Received: from MDWEXGMB02.ciena.com ([::1]) by MDWEXGHT01.ciena.com ([::1]) with mapi; Thu, 16 Aug 2012 14:56:38 -0400 From: "Shah, Himanshu" To: Alia Atlas Date: Thu, 16 Aug 2012 14:56:37 -0400 Thread-Topic: [irs-discuss] IRS comments Thread-Index: Ac17y3hz2DUwJMtBQH+hMHqljlO2/gAFAZBQ Message-ID: References: <812700A304640D4292205D5E83FC59E1061C211D@p-embx01-eq.jnpr.net> <3512BB31280C39448A9880F61DD54CEB09C07E@xmb-aln-x09.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-tm-as-product-ver: SMEX-10.0.0.1412-7.000.1014-19120.000 x-tm-as-result: No--32.805800-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.7.7855, 1.0.260, 0.0.0000 definitions=2012-08-16_06:2012-08-16, 2012-08-16, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=1 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=6.0.2-1203120001 definitions=main-1208160201 Cc: "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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Aug 2012 18:56:40 -0000 I used ifMIB info to refer to ifTable specific information for each interfa= ce as ifSpeed, ifOperStatus, ifAdminStatus, ifMTU, etc etc Most of them are read but some are read/write - such as admin-status. So for example, would IRS interface provide changing admin-status of an int= erface on a node? /himanshu -----Original Message----- From: Alia Atlas [mailto:akatlas@gmail.com]=20 Sent: Thursday, August 16, 2012 12:23 PM To: Shah, Himanshu Cc: irs-discuss@ietf.org Subject: Re: [irs-discuss] IRS comments ACLs as in for BGP policy or as in policy-based-routing/firewalls? Both would be likely needed. ifMIB info? I'm not sure what aspects you are poking at. In terms of read= ing information for the topology export, yes... In terms of writing state,= I don't think so... Alia On Thu, Aug 16, 2012 at 10:42 AM, Shah, Himanshu wrote: > This is precisely the answer I was looking for. > It's a domain issue. This is how IRS distinguishes itself from=20 > OpenFlow/ForCES/GSMP etc etc > > Understand the reasoning but was hoping that IRS would provide one=20 > uniform interface - top to bottom, so implementers do not have to deal wi= th supporting multiple utilities. > > What about ACL (Access Control List), ifMIB specific info etc. (trying=20 > to get sense on the lowest layer that IRS will cover) > > Thanks, > himanshu > > > -----Original Message----- > From: Alia Atlas [mailto:akatlas@gmail.com] > Sent: Wednesday, August 15, 2012 10:57 PM > To: Shah, Himanshu > Cc: UTTARO, JAMES; irs-discuss@ietf.org > Subject: Re: [irs-discuss] IRS comments > > What is the benefit of allowing access to the FIB vs. the associated comp= lexity? > If something wants to inject state directly into the forwarding plane, is= n't that what ForCES or OpenFlow is for? > > Why get into low-level assembly when we've got a C-equiv? (Still not a h= igher level language that apps might speak with associated abstractions, bu= t closer). > > Alia ---snip--- Return-Path: 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 039E621F8582 for ; Thu, 16 Aug 2012 11:46:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.144 X-Spam-Level: X-Spam-Status: No, score=-3.144 tagged_above=-999 required=5 tests=[AWL=0.121, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-1] 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 o2c3Wq8tKscF for ; Thu, 16 Aug 2012 11:46:41 -0700 (PDT) Received: from mx0a-00103a01.pphosted.com (mx0a-00103a01.pphosted.com [67.231.144.234]) by ietfa.amsl.com (Postfix) with ESMTP id C2EF021F849B for ; Thu, 16 Aug 2012 11:46:41 -0700 (PDT) Received: from pps.filterd (m0000419 [127.0.0.1]) by mx0a-00103a01.pphosted.com (8.14.4/8.14.4) with SMTP id q7GIYn8F001454; Thu, 16 Aug 2012 14:46:37 -0400 Received: from mdwexght01.ciena.com (LIN1-118-36-28.ciena.com [63.118.36.28]) by mx0a-00103a01.pphosted.com with ESMTP id 16s58r08pr-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 16 Aug 2012 14:46:37 -0400 Received: from MDWEXCHCGSIHT01.ciena.com (10.4.140.106) by MDWEXGHT01.ciena.com (10.4.140.138) with Microsoft SMTP Server (TLS) id 8.3.192.1; Thu, 16 Aug 2012 14:46:37 -0400 Received: from MDWEXGMB02.ciena.com ([::1]) by MDWEXCHCGSIHT01.ciena.com ([::1]) with mapi; Thu, 16 Aug 2012 14:46:34 -0400 From: "Shah, Himanshu" To: Alia Atlas Date: Thu, 16 Aug 2012 14:46:32 -0400 Thread-Topic: [irs-discuss] IRS comments Thread-Index: Ac17yuXJNZ/bmZOJTuyxeKabkmdX4gAEgpqA Message-ID: References: <812700A304640D4292205D5E83FC59E1061C211D@p-embx01-eq.jnpr.net> <3512BB31280C39448A9880F61DD54CEB09C07E@xmb-aln-x09.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US X-TM-AS-Product-Ver: SMEX-10.0.0.1412-7.000.1014-19120.000 X-TM-AS-Result: No--34.608900-8.000000-31 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.7.7855, 1.0.260, 0.0.0000 definitions=2012-08-16_06:2012-08-16, 2012-08-16, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=1 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=6.0.2-1203120001 definitions=main-1208160197 Cc: "UTTARO, JAMES" , "Dutta, Pranjal K \(Pranjal\)" , "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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Aug 2012 18:46:43 -0000 I was wondering if PCE and IRS could have overlapping functionality. Meaning, can an IRS interface user at both ends (node and controller) be a = non-PCE entity and perform the same service as what PCE does? It seems like you are saying that could work co-operatively... Thanks, himanshu -----Original Message----- From: Alia Atlas [mailto:akatlas@gmail.com] Sent: Thursday, August 16, 2012 12:19 PM To: Shah, Himanshu Cc: Dutta, Pranjal K (Pranjal); UTTARO, JAMES; irs-discuss@ietf.org Subject: Re: [irs-discuss] IRS comments Can you be more specific on the "what about PCE which offloads CSP"? An IRS agent could be co-located with a PCE and support the appropriate sub= -interface. A PCE could use IRS to talk to an IRS agent on a device to lea= rn topology. Alia On Thu, Aug 16, 2012 at 10:41 AM, Shah, Himanshu wrote: > I do agree but was asking specifically to understand the difference betwe= en IRS and other utilities like OpenFlow, GSMP, etc. > and what is in IRS scope. IRS just provides the interface. If it were t= o cover FIB, the "controller" would not add FIB and RIB in > the same node/network. > > Anyway, curious about IRS boundaries - what about PCE which offloads CSPF= ? > > Thanks, > Himanshu > > -----Original Message----- > From: Dutta, Pranjal K (Pranjal) > [mailto:pranjal.dutta@alcatel-lucent.com] > Sent: Thursday, August 16, 2012 12:30 AM > To: Shah, Himanshu; UTTARO, JAMES; Alia Atlas > Cc: irs-discuss@ietf.org > Subject: RE: [irs-discuss] IRS comments > > I think I may be missing something basic here. If access to both RIB (inj= ecting route) and FIB (injecting h/w entry??) are allowed then what decides= the consistency between RIB and FIB? I think at this moment we shouldn't g= o below the RIB. > > Thanks, > Pranjal > > -----Original Message----- > From: irs-discuss-bounces@ietf.org > [mailto:irs-discuss-bounces@ietf.org] On Behalf Of Shah, Himanshu > Sent: Wednesday, August 15, 2012 7:02 PM > To: UTTARO, JAMES; Alia Atlas > Cc: irs-discuss@ietf.org > Subject: Re: [irs-discuss] IRS comments > > Yes I agree. I meant precedence value (pardon the use of wrong terminolog= y). > Each entity that injects route to routing table has an associated precede= nce value.. > > Anyway, I am more curious to know why not allow access to FIB.. > > /himanshu > > -----Original Message----- > From: UTTARO, JAMES [mailto:ju1738@att.com] > Sent: Wednesday, August 15, 2012 7:50 PM > To: Shah, Himanshu; Alia Atlas > Cc: irs-discuss@ietf.org > Subject: RE: [irs-discuss] IRS comments > > Inject routes yes, but I would not assume that implies that all state fro= m IRS is prioritized.. I think an important point to remember is that how I= RS interfaces with routing state learned via network protocols needs to be = part of this effort.. > > Jim Uttaro > > -----Original Message----- > From: irs-discuss-bounces@ietf.org > [mailto:irs-discuss-bounces@ietf.org] On Behalf Of Shah, Himanshu > Sent: Wednesday, August 15, 2012 6:57 PM > To: Alia Atlas > Cc: irs-discuss@ietf.org > Subject: Re: [irs-discuss] IRS comments > > OK - So that I am clear... > > IRS would provide interface to RIB such that routes can be injected with = priority and the local routing table manager on the node would then apply p= recedence rules, select the route, do ARP resolve (if ETH) and inject the p= refix with next-hop info into the FIB. > > The next step is then programming the FIB on the line card (if applicable= ). > > Would make sense for IRS to not provide interface to the FIB on the secon= d step. > But you are saying that it would also not provide interface to FIB of the= first step. > > Is that correct? > > /himanshu > > -----Original Message----- > From: Alia Atlas [mailto:akatlas@gmail.com] > Sent: Wednesday, August 15, 2012 6:05 PM > To: Shah, Himanshu > Cc: irs-discuss@ietf.org > Subject: Re: [irs-discuss] IRS comments > > I don't see IRS going below the RIB layer to FIB. > > Alia > > On Wed, Aug 15, 2012 at 2:21 PM, Shah, Himanshu wrote: >> I will let Ed clarify on what he means by "controller" . >> >> >> >> But here is my view of "application", "controller", "use-case" etc >> etc, >> >> >> >> When an XaaS processes a request it takes into consideration of >> availability of the CPU, memory, application data, cost of power, etc. >> to instantiate a VM on some host machine. >> >> One additional resource taken into consideration is the availability >> and/or requirement of the network connectivity between the resources >> >> such as VM, application data, requester, etc. >> >> >> >> The provider of XaaS thingy is the application server. >> >> (Centralized) Network "Controller(s)" knows current state of network >> infrastructure and (to be decided how much it) controls member >> network nodes using IRS. >> >> The "use case" here is to be able to dynamically create L2/L2.5/L3 >> connectivity with specific TE characteristics between the (perhaps >> geographically dispersed) resource points. >> >> >> >> In hierarchical fashion: Application server <- (application interface)= -> >> Network Controller <- (IRS) -> Network Node >> >> >> >> As we heard at IETF, IRS has tentacles in network nodes from BGP >> policies, all the way down to FIBs/LFIBs/ACL. >> >> >> >> So we need use cases for which applications would require >> accessibility to - >> >> BGP Policies >> >> RIB >> >> LSDB ( I saw an email which talks about reducing IGP to link >> distribution protocol and running SPF in centralized network >> controller) >> >> LIB >> >> FIB >> >> ACL (this is perhaps obvious) >> >> Etc etc >> >> >> >> I broad brushed and simplified a lot here to express my view - not >> sure if this jives with others. >> >> >> >> /Himanshu >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> From: irs-discuss-bounces@ietf.org >> [mailto:irs-discuss-bounces@ietf.org] On Behalf Of Olen Stokes >> Sent: Wednesday, August 15, 2012 1:30 PM >> To: Edward Crabbe; Alia Atlas >> Cc: David Lake (dlake); irs-discuss@ietf.org >> >> >> Subject: Re: [irs-discuss] IRS comments >> >> >> >> Thanks. Can you also give us what you mean by "controller". >> >> >> >> Olen >> >> >> >> From: Edward Crabbe [mailto:edc@google.com] >> Sent: Wednesday, August 15, 2012 1:24 PM >> To: Alia Atlas >> Cc: David Lake (dlake); Olen Stokes; irs-discuss@ietf.org >> Subject: Re: [irs-discuss] IRS comments >> >> >> >> s/wg/pre-BOF proto-wg :P/g >> >> On Wed, Aug 15, 2012 at 10:22 AM, Edward Crabbe wrote: >> >> +1 Alia. There's been a lot of confusion over this term. Having >> +gone a few >> rounds with folks on this one in other forums, I'll point out that >> what most people mean by application (myself included) is some set of >> control software (a scheduler, a path optimizer etc) that provides >> instructions to the controller, which are in turn translated to the appr= opriate PDUs. >> >> >> >> Having 'end user' applications request/make changes to forwarding >> state without an intermediate broker/aggregator acting on their >> behalf sounds like a recipe for disaster for operational networks, >> or, as is more likely, a quick hike to the protocol grave yard >> (followed by a long grave-side party >> :P) for the wg. >> >> >> >> my 2c. >> >> >> >> On Wed, Aug 15, 2012 at 8:48 AM, Alia Atlas wrote: >> >> Hi David, >> >> We do need to clarify what is meant by an application. I would not >> expect that real user-land applications would talk directly to >> routing devices via IRS. I can see that going through an >> intermediary. The IRS abstractions are unlikely to be as high-level >> as user-land applications would want and the security and policy >> issues would get exciting. >> >> Clarifying what applications are more in-scope initially is part of >> where use-cases will help. Can you write up ones to >> categorize/describe your thoughts? >> >> Alia >> >> >> On Wed, Aug 15, 2012 at 11:40 AM, David Lake (dlake) >> >> wrote: >>> As another newbie to this, I have some questions about "application >>> vendors." >>> >>> Who is the target audience here ? That will determine what functional= ity >>> and abstraction of the network we need to expose to that "application." >>> >>> This presently appears to be a little confused - at least in my mind. >>> The draft talks very much as if the application we are addressing is >>> an OSS/BSS system, essentially provisioning from the domain owner. >>> >>> However, linking this to the wider goals of SDN as voiced by >>> customers/users at the first Open Network Summit, there appears to >>> be a desire for cross-domain and user-land application integration. >>> >>> At this level - as an example giving a content cache the ability to >>> ensure delivery of an HD video to an end user - the application will >>> not be interested in the underlying topology of the network; it will >>> need to know that application X can be delivered with parameters Y betw= een reading from >>> the content store to delivery to the user's browser. How the stream >>> traverses the infrastructure is immaterial. >>> >>> Are we intending that IRS satisfies BOTH these requirements (i.e. >>> for ALL applications ?), or should we be more prescriptive about >>> which application space we are addressing ? >>> >>> Thanks >>> >>> David >>> >>> -----Original Message----- >>> From: irs-discuss-bounces@ietf.org >>> [mailto:irs-discuss-bounces@ietf.org] >>> On Behalf Of Alia Atlas >>> Sent: Wednesday, August 15, 2012 7:23 AM >>> To: Olen Stokes >>> Cc: irs-discuss@ietf.org >>> Subject: Re: [irs-discuss] IRS comments >>> >>> I have not specifically heard from application vendors about this. >>> My current plan is that we focus on a Use-Cases draft and define >>> within that some motivating use-cases that we agree are good first >>> targets. Those can drive which subset of functionality we focus on. >>> >>> More use-cases are, of course, quite welcome. Posting them to the >>> mailing list is a good first start. Russ White is starting the >>> general use-cases draft based on the three use-cases that he sent to th= e list. >>> >>> Alia >>> >>> On Wed, Aug 15, 2012 at 9:43 AM, Olen Stokes >>> >>> wrote: >>>> Are there applications vendors out there that already have specific >>>> requirements for what this " subset of the data-models for sub-interfa= ces" >>>> should be? >>>> >>>> Olen >>>> >>>> -----Original Message----- >>>> From: irs-discuss-bounces@ietf.org >>>> [mailto:irs-discuss-bounces@ietf.org] On Behalf Of Alia Atlas >>>> Sent: Wednesday, August 15, 2012 9:08 AM >>>> To: Shah, Himanshu >>>> Cc: Gert Grammel; irs-discuss@ietf.org; Lenny Giuliano; Thomas >>>> Nadeau; Alia Atlas; Scott Whyte >>>> Subject: Re: [irs-discuss] IRS comments >>>> >>>> Hi Himanshu, >>>> >>>> Welcome. I agree that IRS isn't going to spring into being fully >>>> formed - I expect that we'll focus on a subset of the data-models >>>> for sub-interfaces along with an associated protocol (whether that >>>> is a new one or extending an existing one). >>>> >>>> Alia >>>> >>>> On Wed, Aug 15, 2012 at 7:41 AM, Shah, Himanshu wrot= e: >>>>> Newbie to this discussions list and have read only a last couple >>>>> of mails, so pardon the repeat if somebody has already raised the >>>>> following as a concern. >>>>> >>>>> I realize we are early in IRS architecture definition but one >>>>> thing to keep in mind is the user experience. >>>>> We need to make sure that exposed interface to >>>>> RIB/LFIB/FIB/IGPs/BGP/LSDBs etc etc provide a consistent >>>>> predictive action/response/events even when different >>>>> implementations has varying capabilities. >>>>> >>>>> At the moment it seems like a wild wild west. >>>>> Perhaps IRS can be defined in phases starting with a simpler, >>>>> limited version.. >>>>> >>>>> Thanks, >>>>> himanshu >>>>> >>>>> >>>>> -----Original Message----- >>>>> From: irs-discuss-bounces@ietf.org >>>>> [mailto:irs-discuss-bounces@ietf.org] On Behalf Of Alia Atlas >>>>> Sent: Monday, August 13, 2012 8:41 AM >>>>> To: Scott Whyte >>>>> Cc: Thomas Nadeau; Gert Grammel; Alia Atlas; Lenny Giuliano; >>>>> irs-discuss@ietf.org >>>>> Subject: Re: [irs-discuss] IRS comments >>>>> >>>>> ...snip... >>>>> >>>>> On Fri, Aug 10, 2012 at 9:03 PM, Scott Whyte wrot= e: >>>>>> On Fri, Aug 10, 2012 at 5:16 PM, Alia Atlas wrot= e: >>>>> >>>>>>> I do think it is important to have the RIB as an arbitration mechan= ism >>>>>>> on the device. Russ's suggestion that for the RIB sub-interface, = the >>>>>>> IRS agent might communicate logically to an IRS routing process >>>>>>> gives good semantics and interactions. Obviously, >>>>>>> implementations may differ. >>>>>> >>>>>> As long as the arbitration mechanism is reconfigurable by the >>>>>> operator to whatever precedence they want, I agree. Its not >>>>>> clear to me if various RIB implementations treat all proffered >>>>>> routes the same, nor if they store the same meta-data with all proto= col sources. >>>>>> So there needs to be some way for the operator to leverage >>>>>> exposed protocol-specific optimizations, without conflict from >>>>>> the other routing processes, if they so desire. OTOH if it can >>>>>> all be done via static routes, it seems much simpler. :) >>>>> >>>>> Clearly the IRS sub-interface for the RIB needs to >>>>> introduce/define the different precedences; my assumption is that >>>>> it would be per route with a well-defined small set of meta-data. >>>>> This is part of where having good use-cases will help us >>>>> understand what behavior is necessary. The static routes do seem lik= e a simpler case to start with. >>>>> >>>>> Alia >>>>> _______________________________________________ >>>>> 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 >>> _______________________________________________ >>> 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 >> >> >> >> > _______________________________________________ > 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 Return-Path: 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 E016A21F8644 for ; Thu, 16 Aug 2012 09:58:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.049 X-Spam-Level: * X-Spam-Status: No, score=1.049 tagged_above=-999 required=5 tests=[AWL=3.648, BAYES_00=-2.599] 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 9RhXvtiX8xvL for ; Thu, 16 Aug 2012 09:58:04 -0700 (PDT) Received: from villa.puc.rediris.es (unknown [IPv6:2001:720:418:ca00::7]) by ietfa.amsl.com (Postfix) with ESMTP id B6B5721F862A for ; Thu, 16 Aug 2012 09:58:03 -0700 (PDT) Received: from [84.88.62.208] (helo=leo) by villa.puc.rediris.es with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1T23OO-0004aC-Rx; Thu, 16 Aug 2012 18:57:56 +0200 Received: from [192.168.101.65] (unknown [192.168.101.65]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by leo (Postfix) with ESMTPSA id BC03F1FE9D; Thu, 16 Aug 2012 18:57:50 +0200 (CEST) X-Envelope-From: ramon.casellas@cttc.es Message-ID: <502D2692.2030105@cttc.es> Date: Thu, 16 Aug 2012 18:57:54 +0200 From: Ramon Casellas Organization: CTTC User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120814 Thunderbird/15.0 MIME-Version: 1.0 To: "Dutta, Pranjal K (Pranjal)" References: <812700A304640D4292205D5E83FC59E1061C211D@p-embx01-eq.jnpr.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-SPF-Received: 4 X-Spamina-Bogosity: Ham Cc: "irs-discuss@ietf.org" , Alia Atlas 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Aug 2012 16:58:05 -0000 On 08/16/2012 06:14 PM, Dutta, Pranjal K (Pranjal) 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? > Pranjal, all, My two cents. Apologies if this is well known, I am not sure I fully grasped your question... IMHO, the idea of separating LSA flooding from CSPF computation has indeed been a current topic for a while, and when it is tied to the idea of offloading the CSPF computation to a dedicated centralized server (for example a PCE), I would guess/say that this is usually scoped and applies to the case when one formally decouples the control plane from the data plane (thus constructing a LSDB and establishing adjacencies in the control plane network and also constructing a separated Traffic Engineering Database or TED, which is described via opaque LSAs). In this particular scenario, the CSPF refers to /applies to the dataplane only (as is done in GMPLS/PCE), and one still needs SPF for the addresses in the DCN. In other words, OSPF-TE is used to disseminate data plane (TE) link/node attribute changes (in addition to what OSFPv2 already does) and for this establishes routing adjacencies and the PCE performs CSPF on the TED, which can be a completely different topology. However, regarding your question "how different from a PCE", I would say these are complementary : first a) the PCE architecture does not specify how it obtains the Traffic Engineering Database (TED) to construct the directed graph on which it operates (i.e., performs CSPF, usually upon request); the PCE does not usually care much about the control plane topology and, b) what you refer to "push to each router" and "inject entries into the RIB" is completely orthogonal to a PCE. For a), and as stated previously in the list, a common way is to be a passive listener or to sniff LSAs with opaque (MPLS TE, area-wide) or to contact a topology server or NMS that has the current topology (TED). In other words, a PCE is a decoupled functional component and the protocol (PCEP) only specifies the interface to request path computations. Even if one uses a PCE and a lightweight LSA flooding protocol, SPF still needs to be executed by nodes to "forward" control packets, usually using the uncontrained shortest IP route. For b) note that, as of now, there is no standard way by which a PCE can configure the dataplane by itself. By "configure the dataplane" one can mean to "trigger" the establishment of LSPs via RSVP-TE signaling, or configure the cross-connects via OpenFlow or to set up state in the datapath (could even be configuring the RIB), somehow. Recently, Ed has started work in stateful PCE, and it is possible that in the future it will have the capability to "command" the establishment of connections. In summary, I see the (generic) relationship between PCE and IRS in two main ways: * As a means to communicate / obtain the TED, typically constructed via OSPF-TE opaque LSAs. This would be an alternative to existing methods / current practice. Another main driver for this is the Hierarchical PCE (H-PCE) in case a parent PCE needs to know about an (aggregated) topology within a (child) domain, since parent / child PCEs may not be in the same IGP area. In this sense, and as stated in the list, for this, other considered solutions are BGPLS / north bound interfaces or to use notify (PCNtf) messages wrapping TE LSAs for this. * As a means to define data plane state (much like OpenFlow) once a Path has been computed. Imho these are two areas which the PCE architecture and protocol do not currently cover and in which an architecture such as IRS could be helpful. Hope this helps (a little!) Best regards Ramon -- Ramon Casellas, Ph.D. Research Associate - Optical Networking Area --http://wikiona.cttc.es CTTC - Centre Tecnològic de Telecomunicacions de Catalunya, PMT Ed B4 Av. Carl Friedrich Gauss, 7 - 08860 Castelldefels (Barcelona) - Spain Tel.: +34 93 645 29 00 -- Fax. +34 93 645 29 01 Return-Path: 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 4567421F8493 for ; Thu, 16 Aug 2012 09:40:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.377 X-Spam-Level: X-Spam-Status: No, score=-7.377 tagged_above=-999 required=5 tests=[AWL=-0.778, 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 eEqx9aLb2EQc for ; Thu, 16 Aug 2012 09:40:12 -0700 (PDT) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by ietfa.amsl.com (Postfix) with ESMTP id 8B81021F847D for ; Thu, 16 Aug 2012 09:40:10 -0700 (PDT) Received: from inbansmailrelay2.in.alcatel-lucent.com (h135-250-11-33.lucent.com [135.250.11.33]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id q7GGdvT5014872 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 16 Aug 2012 11:39:59 -0500 (CDT) Received: from INBANSXCHHUB01.in.alcatel-lucent.com (inbansxchhub01.in.alcatel-lucent.com [135.250.12.32]) by inbansmailrelay2.in.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id q7GGdtkL019279 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 16 Aug 2012 22:09:55 +0530 Received: from INBANSXCHMBSA3.in.alcatel-lucent.com ([135.250.12.50]) by INBANSXCHHUB01.in.alcatel-lucent.com ([135.250.12.32]) with mapi; Thu, 16 Aug 2012 22:09:55 +0530 From: "Dutta, Pranjal K (Pranjal)" To: Alia Atlas Date: Thu, 16 Aug 2012 22:09:53 +0530 Thread-Topic: [irs-discuss] IRS comments Thread-Index: Ac17zRQp7s3++JopSNaXHriSbSfc6gAAHFBg Message-ID: References: <812700A304640D4292205D5E83FC59E1061C211D@p-embx01-eq.jnpr.net> <3512BB31280C39448A9880F61DD54CEB09C07E@xmb-aln-x09.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 Cc: "UTTARO, JAMES" , "Shah, Himanshu" , "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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Aug 2012 16:40:13 -0000 Thanks for the clarification. Yes, that's why I was poking for use-cases fi= rst.=20 Thanks, Pranjal -----Original Message----- From: Alia Atlas [mailto:akatlas@gmail.com]=20 Sent: Thursday, August 16, 2012 9:35 AM To: Dutta, Pranjal K (Pranjal) Cc: Shah, Himanshu; UTTARO, JAMES; irs-discuss@ietf.org Subject: Re: [irs-discuss] IRS comments 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) 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 prec= isely 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 "diff= s" from each router (thru "controller") whenever there is a change. The app= lication would compute SPF on behalf of each router (LSDB). The result of t= he 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 scalabi= lity numbers in LSDB we are talking about? > > The "application" would be running in a high performance server and so SP= F compute there is not an issue and perhaps it is good way to synchronize F= IB update (to a certain extent) to avoid u-loops etc. > > But when we are managing all routers in the purview of the application, t= he computing power in each router is not uniform. To be realistic, I have s= ome concerns on how much "real-timeness" we could achieve between applicati= on and controllers on such proposals, esp. when scaling numbers are high. T= his leads to higher time lag on inconsistency between application SPF compu= te 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 perfor= mance 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 i= ssue 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 persiste= ncy of RSVP-TE tunnels in dynamic environments. > > I apologize if I misunderstood the intent. > > Thanks, > Pranjal ---snip--- Return-Path: 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 20ED521F8596 for ; Thu, 16 Aug 2012 09:34:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.565 X-Spam-Level: X-Spam-Status: No, score=-3.565 tagged_above=-999 required=5 tests=[AWL=0.034, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 hWktMNhlmB7A for ; Thu, 16 Aug 2012 09:34:52 -0700 (PDT) Received: from mail-gg0-f172.google.com (mail-gg0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 67E3221F85A7 for ; Thu, 16 Aug 2012 09:34:52 -0700 (PDT) Received: by ggnh4 with SMTP id h4so3409897ggn.31 for ; Thu, 16 Aug 2012 09:34:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=J377X5dlflz+YQEu+bBM7h3DKuJosP39SAWc92IEFRk=; b=a1Tlcu+EvT3Em+2GtarDhrKdh8XDuYx5CCTmFBC/cf9AkKHYUE9ojfVoFwd5wirN2x xenf17eUeFI1D7UkbnY0xgp7oJNsYp+7uVrzNppBwO3ZVlVbQJ6d5EJWt2N1qSmzmmff PgKRGiPnVvk8VAePjpt19LLk5zjileBFjOeSwwdr3zEI/uEn3J7QMKL6XcYehaKuKeb+ Eby+sqTzzFUGHME/jIWh47SsnKbrDlkVIAGReNnfmtc/BCGU+YqFueVbN8s8t4JEh4RK tBWJ8qKwMlakRmVJ2s2Pwz2jzpm9S2GS4JjYL+itAJfOQQ02RZcPeTyIcjQUSri0l86y ozxA== MIME-Version: 1.0 Received: by 10.50.36.195 with SMTP id s3mr2361004igj.63.1345134883742; Thu, 16 Aug 2012 09:34:43 -0700 (PDT) Received: by 10.50.91.135 with HTTP; Thu, 16 Aug 2012 09:34:43 -0700 (PDT) In-Reply-To: References: <812700A304640D4292205D5E83FC59E1061C211D@p-embx01-eq.jnpr.net> <3512BB31280C39448A9880F61DD54CEB09C07E@xmb-aln-x09.cisco.com> Date: Thu, 16 Aug 2012 12:34:43 -0400 Message-ID: From: Alia Atlas To: "Dutta, Pranjal K (Pranjal)" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "UTTARO, JAMES" , "Shah, Himanshu" , "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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Aug 2012 16:34:53 -0000 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) 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 prec= isely 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 "diff= s" from each router (thru "controller") whenever there is a change. The app= lication would compute SPF on behalf of each router (LSDB). The result of t= he 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 scalabi= lity numbers in LSDB we are talking about? > > The "application" would be running in a high performance server and so SP= F compute there is not an issue and perhaps it is good way to synchronize F= IB update (to a certain extent) to avoid u-loops etc. > > But when we are managing all routers in the purview of the application, t= he computing power in each router is not uniform. To be realistic, I have s= ome concerns on how much "real-timeness" we could achieve between applicati= on and controllers on such proposals, esp. when scaling numbers are high. T= his leads to higher time lag on inconsistency between application SPF compu= te 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 perfor= mance 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 i= ssue 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 persiste= ncy of RSVP-TE tunnels in dynamic environments. > > I apologize if I misunderstood the intent. > > Thanks, > Pranjal ---snip--- Return-Path: 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 2D8E521F8629 for ; Thu, 16 Aug 2012 09:23:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.565 X-Spam-Level: X-Spam-Status: No, score=-3.565 tagged_above=-999 required=5 tests=[AWL=0.034, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 EO-pNwakfPrO for ; Thu, 16 Aug 2012 09:23:27 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 622FF21F8611 for ; Thu, 16 Aug 2012 09:23:26 -0700 (PDT) Received: by yenm5 with SMTP id m5so3386384yen.31 for ; Thu, 16 Aug 2012 09:23:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=oIE96mT2edGkk1m0+LcxQ2TT6pw8rc624R3pXnOcVDk=; b=h+DuT7WR7RYAuoUms3kB1HP06lBPNJv+SeyIgFHlDGpdBsuWCyFA1fvOdbMbaxiWMh 4g0bDJuVkFzuOrH/vgkTaoC26Fp08fi7zRdW9VpDN811ApUKiPrCR9Glx0VPVmZb0sLt QKWe7jfP8YbozVbxbhGrE90xt2O65vjdt4RibUaBYoaXpOksK2cTw5KldVGzF5bWnOiz ddlRUCbW49RTvUW4daFtbTIjy0SZFoAkWDhja7/cBfeKQSr4ZoR8RPMOWPCDnhgvHzhY ZnspZS3oIq03inzjnOaHUP44cX9JcYQ4XUrHPSCi568xBgOCAhODLF3XncWgsrJfmoSr u6Ow== MIME-Version: 1.0 Received: by 10.50.203.101 with SMTP id kp5mr2367180igc.2.1345134205624; Thu, 16 Aug 2012 09:23:25 -0700 (PDT) Received: by 10.50.91.135 with HTTP; Thu, 16 Aug 2012 09:23:25 -0700 (PDT) In-Reply-To: References: <812700A304640D4292205D5E83FC59E1061C211D@p-embx01-eq.jnpr.net> <3512BB31280C39448A9880F61DD54CEB09C07E@xmb-aln-x09.cisco.com> Date: Thu, 16 Aug 2012 12:23:25 -0400 Message-ID: From: Alia Atlas To: "Shah, Himanshu" Content-Type: text/plain; charset=ISO-8859-1 Cc: "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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Aug 2012 16:23:29 -0000 ACLs as in for BGP policy or as in policy-based-routing/firewalls? Both would be likely needed. ifMIB info? I'm not sure what aspects you are poking at. In terms of reading information for the topology export, yes... In terms of writing state, I don't think so... Alia On Thu, Aug 16, 2012 at 10:42 AM, Shah, Himanshu wrote: > This is precisely the answer I was looking for. > It's a domain issue. This is how IRS distinguishes itself from OpenFlow/ForCES/GSMP etc etc > > Understand the reasoning but was hoping that IRS would provide one uniform interface - top to bottom, > so implementers do not have to deal with supporting multiple utilities. > > What about ACL (Access Control List), ifMIB specific info etc. (trying to get sense on the lowest layer that IRS will cover) > > Thanks, > himanshu > > > -----Original Message----- > From: Alia Atlas [mailto:akatlas@gmail.com] > Sent: Wednesday, August 15, 2012 10:57 PM > To: Shah, Himanshu > Cc: UTTARO, JAMES; irs-discuss@ietf.org > Subject: Re: [irs-discuss] IRS comments > > What is the benefit of allowing access to the FIB vs. the associated complexity? > If something wants to inject state directly into the forwarding plane, isn't that what ForCES or OpenFlow is for? > > Why get into low-level assembly when we've got a C-equiv? (Still not a higher level language that apps might speak with associated abstractions, but closer). > > Alia ---snip--- Return-Path: 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 4EB4021F85CE for ; Thu, 16 Aug 2012 09:19:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.564 X-Spam-Level: X-Spam-Status: No, score=-3.564 tagged_above=-999 required=5 tests=[AWL=0.035, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 EWeGKQYBuViB for ; Thu, 16 Aug 2012 09:19:20 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id E963A21F85E0 for ; Thu, 16 Aug 2012 09:19:19 -0700 (PDT) Received: by yenm5 with SMTP id m5so3381455yen.31 for ; Thu, 16 Aug 2012 09:19:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=aefrdz0q4vFaaXjc5gahvajzTFksKl8KA9E7jjlQjg8=; b=xJlyIjlpyH2dYk64UUDOURZ0Pt019ZuA6VsTuc/9DhEw0svoP7akj2UYpnHZYTMALj aI42IYsRmPpvrgA1uCMoRJATlCnrJOqj9/ychVpDgh+mSF5dV/zxivn1vY+vKhH5icqg u1G4ng2s3jYm/eUM/zUgqENEVHiooiVfJmSuKdUesrIdPuv+iOg9jpjXXADluhaQ4FKy ojv9K1bmmcIr9I/Hu40/Gc++SRpMj863H2c6I9+h9qcVVExxIEkDMx/mAKRY/VjFPaXK 5yPD+TEqBwYPJNwwfzRhu4PQzJyC1HsKiEIa56NucnHwFHHUrdx8B1qvxaJdeHCQV60A lj2Q== MIME-Version: 1.0 Received: by 10.50.95.225 with SMTP id dn1mr2283863igb.58.1345133958863; Thu, 16 Aug 2012 09:19:18 -0700 (PDT) Received: by 10.50.91.135 with HTTP; Thu, 16 Aug 2012 09:19:18 -0700 (PDT) In-Reply-To: References: <812700A304640D4292205D5E83FC59E1061C211D@p-embx01-eq.jnpr.net> <3512BB31280C39448A9880F61DD54CEB09C07E@xmb-aln-x09.cisco.com> Date: Thu, 16 Aug 2012 12:19:18 -0400 Message-ID: From: Alia Atlas To: "Shah, Himanshu" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "UTTARO, JAMES" , "Dutta, Pranjal K \(Pranjal\)" , "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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Aug 2012 16:19:21 -0000 Can you be more specific on the "what about PCE which offloads CSP"? An IRS agent could be co-located with a PCE and support the appropriate sub-interface. A PCE could use IRS to talk to an IRS agent on a device to learn topology. Alia On Thu, Aug 16, 2012 at 10:41 AM, Shah, Himanshu wrote: > I do agree but was asking specifically to understand the difference betwe= en IRS and other utilities like OpenFlow, GSMP, etc. > and what is in IRS scope. IRS just provides the interface. If it were t= o cover FIB, the "controller" would not add FIB and RIB in > the same node/network. > > Anyway, curious about IRS boundaries - what about PCE which offloads CSPF= ? > > Thanks, > Himanshu > > -----Original Message----- > From: Dutta, Pranjal K (Pranjal) [mailto:pranjal.dutta@alcatel-lucent.com= ] > Sent: Thursday, August 16, 2012 12:30 AM > To: Shah, Himanshu; UTTARO, JAMES; Alia Atlas > Cc: irs-discuss@ietf.org > Subject: RE: [irs-discuss] IRS comments > > I think I may be missing something basic here. If access to both RIB (inj= ecting route) and FIB (injecting h/w entry??) are allowed then what decides= the consistency between RIB and FIB? I think at this moment we shouldn't g= o below the RIB. > > Thanks, > Pranjal > > -----Original Message----- > From: irs-discuss-bounces@ietf.org [mailto:irs-discuss-bounces@ietf.org] = On Behalf Of Shah, Himanshu > Sent: Wednesday, August 15, 2012 7:02 PM > To: UTTARO, JAMES; Alia Atlas > Cc: irs-discuss@ietf.org > Subject: Re: [irs-discuss] IRS comments > > Yes I agree. I meant precedence value (pardon the use of wrong terminolog= y). > Each entity that injects route to routing table has an associated precede= nce value.. > > Anyway, I am more curious to know why not allow access to FIB.. > > /himanshu > > -----Original Message----- > From: UTTARO, JAMES [mailto:ju1738@att.com] > Sent: Wednesday, August 15, 2012 7:50 PM > To: Shah, Himanshu; Alia Atlas > Cc: irs-discuss@ietf.org > Subject: RE: [irs-discuss] IRS comments > > Inject routes yes, but I would not assume that implies that all state fro= m IRS is prioritized.. I think an important point to remember is that how I= RS interfaces with routing state learned via network protocols needs to be = part of this effort.. > > Jim Uttaro > > -----Original Message----- > From: irs-discuss-bounces@ietf.org [mailto:irs-discuss-bounces@ietf.org] = On Behalf Of Shah, Himanshu > Sent: Wednesday, August 15, 2012 6:57 PM > To: Alia Atlas > Cc: irs-discuss@ietf.org > Subject: Re: [irs-discuss] IRS comments > > OK - So that I am clear... > > IRS would provide interface to RIB such that routes can be injected with = priority and the local routing table manager on the node would then apply p= recedence rules, select the route, do ARP resolve (if ETH) and inject the p= refix with next-hop info into the FIB. > > The next step is then programming the FIB on the line card (if applicable= ). > > Would make sense for IRS to not provide interface to the FIB on the secon= d step. > But you are saying that it would also not provide interface to FIB of the= first step. > > Is that correct? > > /himanshu > > -----Original Message----- > From: Alia Atlas [mailto:akatlas@gmail.com] > Sent: Wednesday, August 15, 2012 6:05 PM > To: Shah, Himanshu > Cc: irs-discuss@ietf.org > Subject: Re: [irs-discuss] IRS comments > > I don't see IRS going below the RIB layer to FIB. > > Alia > > On Wed, Aug 15, 2012 at 2:21 PM, Shah, Himanshu wrote: >> I will let Ed clarify on what he means by "controller" . >> >> >> >> But here is my view of "application", "controller", "use-case" etc >> etc, >> >> >> >> When an XaaS processes a request it takes into consideration of >> availability of the CPU, memory, application data, cost of power, etc. >> to instantiate a VM on some host machine. >> >> One additional resource taken into consideration is the availability >> and/or requirement of the network connectivity between the resources >> >> such as VM, application data, requester, etc. >> >> >> >> The provider of XaaS thingy is the application server. >> >> (Centralized) Network "Controller(s)" knows current state of network >> infrastructure and (to be decided how much it) controls member network >> nodes using IRS. >> >> The "use case" here is to be able to dynamically create L2/L2.5/L3 >> connectivity with specific TE characteristics between the (perhaps >> geographically dispersed) resource points. >> >> >> >> In hierarchical fashion: Application server <- (application interface)= -> >> Network Controller <- (IRS) -> Network Node >> >> >> >> As we heard at IETF, IRS has tentacles in network nodes from BGP >> policies, all the way down to FIBs/LFIBs/ACL. >> >> >> >> So we need use cases for which applications would require >> accessibility to - >> >> BGP Policies >> >> RIB >> >> LSDB ( I saw an email which talks about reducing IGP to link >> distribution protocol and running SPF in centralized network >> controller) >> >> LIB >> >> FIB >> >> ACL (this is perhaps obvious) >> >> Etc etc >> >> >> >> I broad brushed and simplified a lot here to express my view - not >> sure if this jives with others. >> >> >> >> /Himanshu >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> From: irs-discuss-bounces@ietf.org >> [mailto:irs-discuss-bounces@ietf.org] On Behalf Of Olen Stokes >> Sent: Wednesday, August 15, 2012 1:30 PM >> To: Edward Crabbe; Alia Atlas >> Cc: David Lake (dlake); irs-discuss@ietf.org >> >> >> Subject: Re: [irs-discuss] IRS comments >> >> >> >> Thanks. Can you also give us what you mean by "controller". >> >> >> >> Olen >> >> >> >> From: Edward Crabbe [mailto:edc@google.com] >> Sent: Wednesday, August 15, 2012 1:24 PM >> To: Alia Atlas >> Cc: David Lake (dlake); Olen Stokes; irs-discuss@ietf.org >> Subject: Re: [irs-discuss] IRS comments >> >> >> >> s/wg/pre-BOF proto-wg :P/g >> >> On Wed, Aug 15, 2012 at 10:22 AM, Edward Crabbe wrote: >> >> +1 Alia. There's been a lot of confusion over this term. Having gone >> +a few >> rounds with folks on this one in other forums, I'll point out that >> what most people mean by application (myself included) is some set of >> control software (a scheduler, a path optimizer etc) that provides >> instructions to the controller, which are in turn translated to the appr= opriate PDUs. >> >> >> >> Having 'end user' applications request/make changes to forwarding >> state without an intermediate broker/aggregator acting on their behalf >> sounds like a recipe for disaster for operational networks, or, as is >> more likely, a quick hike to the protocol grave yard (followed by a >> long grave-side party >> :P) for the wg. >> >> >> >> my 2c. >> >> >> >> On Wed, Aug 15, 2012 at 8:48 AM, Alia Atlas wrote: >> >> Hi David, >> >> We do need to clarify what is meant by an application. I would not >> expect that real user-land applications would talk directly to routing >> devices via IRS. I can see that going through an intermediary. The >> IRS abstractions are unlikely to be as high-level as user-land >> applications would want and the security and policy issues would get >> exciting. >> >> Clarifying what applications are more in-scope initially is part of >> where use-cases will help. Can you write up ones to >> categorize/describe your thoughts? >> >> Alia >> >> >> On Wed, Aug 15, 2012 at 11:40 AM, David Lake (dlake) >> wrote: >>> As another newbie to this, I have some questions about "application >>> vendors." >>> >>> Who is the target audience here ? That will determine what functional= ity >>> and abstraction of the network we need to expose to that "application." >>> >>> This presently appears to be a little confused - at least in my mind. >>> The draft talks very much as if the application we are addressing is >>> an OSS/BSS system, essentially provisioning from the domain owner. >>> >>> However, linking this to the wider goals of SDN as voiced by >>> customers/users at the first Open Network Summit, there appears to be >>> a desire for cross-domain and user-land application integration. >>> >>> At this level - as an example giving a content cache the ability to >>> ensure delivery of an HD video to an end user - the application will >>> not be interested in the underlying topology of the network; it will >>> need to know that application X can be delivered with parameters Y betw= een reading from >>> the content store to delivery to the user's browser. How the stream >>> traverses the infrastructure is immaterial. >>> >>> Are we intending that IRS satisfies BOTH these requirements (i.e. for >>> ALL applications ?), or should we be more prescriptive about which >>> application space we are addressing ? >>> >>> Thanks >>> >>> David >>> >>> -----Original Message----- >>> From: irs-discuss-bounces@ietf.org >>> [mailto:irs-discuss-bounces@ietf.org] >>> On Behalf Of Alia Atlas >>> Sent: Wednesday, August 15, 2012 7:23 AM >>> To: Olen Stokes >>> Cc: irs-discuss@ietf.org >>> Subject: Re: [irs-discuss] IRS comments >>> >>> I have not specifically heard from application vendors about this. >>> My current plan is that we focus on a Use-Cases draft and define >>> within that some motivating use-cases that we agree are good first >>> targets. Those can drive which subset of functionality we focus on. >>> >>> More use-cases are, of course, quite welcome. Posting them to the >>> mailing list is a good first start. Russ White is starting the >>> general use-cases draft based on the three use-cases that he sent to th= e list. >>> >>> Alia >>> >>> On Wed, Aug 15, 2012 at 9:43 AM, Olen Stokes >>> >>> wrote: >>>> Are there applications vendors out there that already have specific >>>> requirements for what this " subset of the data-models for sub-interfa= ces" >>>> should be? >>>> >>>> Olen >>>> >>>> -----Original Message----- >>>> From: irs-discuss-bounces@ietf.org >>>> [mailto:irs-discuss-bounces@ietf.org] On Behalf Of Alia Atlas >>>> Sent: Wednesday, August 15, 2012 9:08 AM >>>> To: Shah, Himanshu >>>> Cc: Gert Grammel; irs-discuss@ietf.org; Lenny Giuliano; Thomas >>>> Nadeau; Alia Atlas; Scott Whyte >>>> Subject: Re: [irs-discuss] IRS comments >>>> >>>> Hi Himanshu, >>>> >>>> Welcome. I agree that IRS isn't going to spring into being fully >>>> formed - I expect that we'll focus on a subset of the data-models >>>> for sub-interfaces along with an associated protocol (whether that >>>> is a new one or extending an existing one). >>>> >>>> Alia >>>> >>>> On Wed, Aug 15, 2012 at 7:41 AM, Shah, Himanshu wrot= e: >>>>> Newbie to this discussions list and have read only a last couple of >>>>> mails, so pardon the repeat if somebody has already raised the >>>>> following as a concern. >>>>> >>>>> I realize we are early in IRS architecture definition but one thing >>>>> to keep in mind is the user experience. >>>>> We need to make sure that exposed interface to >>>>> RIB/LFIB/FIB/IGPs/BGP/LSDBs etc etc provide a consistent >>>>> predictive action/response/events even when different >>>>> implementations has varying capabilities. >>>>> >>>>> At the moment it seems like a wild wild west. >>>>> Perhaps IRS can be defined in phases starting with a simpler, >>>>> limited version.. >>>>> >>>>> Thanks, >>>>> himanshu >>>>> >>>>> >>>>> -----Original Message----- >>>>> From: irs-discuss-bounces@ietf.org >>>>> [mailto:irs-discuss-bounces@ietf.org] On Behalf Of Alia Atlas >>>>> Sent: Monday, August 13, 2012 8:41 AM >>>>> To: Scott Whyte >>>>> Cc: Thomas Nadeau; Gert Grammel; Alia Atlas; Lenny Giuliano; >>>>> irs-discuss@ietf.org >>>>> Subject: Re: [irs-discuss] IRS comments >>>>> >>>>> ...snip... >>>>> >>>>> On Fri, Aug 10, 2012 at 9:03 PM, Scott Whyte wrot= e: >>>>>> On Fri, Aug 10, 2012 at 5:16 PM, Alia Atlas wrot= e: >>>>> >>>>>>> I do think it is important to have the RIB as an arbitration mechan= ism >>>>>>> on the device. Russ's suggestion that for the RIB sub-interface, = the >>>>>>> IRS agent might communicate logically to an IRS routing process >>>>>>> gives good semantics and interactions. Obviously, >>>>>>> implementations may differ. >>>>>> >>>>>> As long as the arbitration mechanism is reconfigurable by the >>>>>> operator to whatever precedence they want, I agree. Its not clear >>>>>> to me if various RIB implementations treat all proffered routes >>>>>> the same, nor if they store the same meta-data with all protocol sou= rces. >>>>>> So there needs to be some way for the operator to leverage exposed >>>>>> protocol-specific optimizations, without conflict from the other >>>>>> routing processes, if they so desire. OTOH if it can all be done >>>>>> via static routes, it seems much simpler. :) >>>>> >>>>> Clearly the IRS sub-interface for the RIB needs to introduce/define >>>>> the different precedences; my assumption is that it would be per >>>>> route with a well-defined small set of meta-data. This is part of >>>>> where having good use-cases will help us understand what behavior >>>>> is necessary. The static routes do seem like a simpler case to start= with. >>>>> >>>>> Alia >>>>> _______________________________________________ >>>>> 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 >>> _______________________________________________ >>> 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 >> >> >> >> > _______________________________________________ > 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 Return-Path: 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 5341A21F8659 for ; Thu, 16 Aug 2012 09:14:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.305 X-Spam-Level: X-Spam-Status: No, score=-9.305 tagged_above=-999 required=5 tests=[AWL=1.294, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 Gxk67TT5XKyC for ; Thu, 16 Aug 2012 09:14:35 -0700 (PDT) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id 2809021F8532 for ; Thu, 16 Aug 2012 09:14:30 -0700 (PDT) Received: from inbansmailrelay2.in.alcatel-lucent.com (h135-250-11-33.lucent.com [135.250.11.33]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id q7GGENNs028213 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 16 Aug 2012 11:14:25 -0500 (CDT) Received: from INBANSXCHHUB01.in.alcatel-lucent.com (inbansxchhub01.in.alcatel-lucent.com [135.250.12.32]) by inbansmailrelay2.in.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id q7GGEIxg018460 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 16 Aug 2012 21:44:19 +0530 Received: from INBANSXCHMBSA3.in.alcatel-lucent.com ([135.250.12.50]) by INBANSXCHHUB01.in.alcatel-lucent.com ([135.250.12.32]) with mapi; Thu, 16 Aug 2012 21:44:18 +0530 From: "Dutta, Pranjal K (Pranjal)" To: "Shah, Himanshu" , "UTTARO, JAMES" , Alia Atlas Date: Thu, 16 Aug 2012 21:44:14 +0530 Thread-Topic: [irs-discuss] IRS comments Thread-Index: Ac15UPmWZFj3YBmsT9Smjrge48ksHAATypTAAFoVXoAAAUAUgAABZOIAAAKyOQAAAEVwAAADS7QAAAAO5wAAADV/gAAByQUAAAfLkAAAAdXVgAAGmN5wAAiugSAADB62sAAI/lNwAAmQUNA= Message-ID: References: <812700A304640D4292205D5E83FC59E1061C211D@p-embx01-eq.jnpr.net> <3512BB31280C39448A9880F61DD54CEB09C07E@xmb-aln-x09.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 Cc: "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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Aug 2012 16:14:36 -0000 "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 precis= ely 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/I= SIS as it is done today. So routers would build neighboring relationship/ad= jacencies 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 appli= cation would compute SPF on behalf of each router (LSDB). The result of the= compute would be pushed by application to each Router (thru controller) an= d 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 scalabili= ty 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 som= e concerns on how much "real-timeness" we could achieve between application= and controllers on such proposals, esp. when scaling numbers are high. Thi= s leads to higher time lag on inconsistency between application SPF compute= and FIB update. It's almost like the classic "slow peering" issues with TC= P like protocols - the high performance peer is slowed down by low performa= nce peer. Static route interface is good thing because it is a state that persists lo= nger. IGPs may be deployed in very dynamic environments where tight coupling is d= esirable between SPF compute and FIB update. In scaled environments the iss= ue 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 persistenc= y of RSVP-TE tunnels in dynamic environments. I apologize if I misunderstood the intent. Thanks, Pranjal -----Original Message----- From: Shah, Himanshu [mailto:hshah@ciena.com] Sent: Thursday, August 16, 2012 7:41 AM To: Dutta, Pranjal K (Pranjal); UTTARO, JAMES; Alia Atlas Cc: irs-discuss@ietf.org Subject: RE: [irs-discuss] IRS comments I do agree but was asking specifically to understand the difference between= IRS and other utilities like OpenFlow, GSMP, etc. and what is in IRS scope. IRS just provides the interface. If it were to = cover FIB, the "controller" would not add FIB and RIB in the same node/network. Anyway, curious about IRS boundaries - what about PCE which offloads CSPF? Thanks, Himanshu -----Original Message----- From: Dutta, Pranjal K (Pranjal) [mailto:pranjal.dutta@alcatel-lucent.com] Sent: Thursday, August 16, 2012 12:30 AM To: Shah, Himanshu; UTTARO, JAMES; Alia Atlas Cc: irs-discuss@ietf.org Subject: RE: [irs-discuss] IRS comments I think I may be missing something basic here. If access to both RIB (injec= ting route) and FIB (injecting h/w entry??) are allowed then what decides t= he consistency between RIB and FIB? I think at this moment we shouldn't go = below the RIB. Thanks, Pranjal -----Original Message----- From: irs-discuss-bounces@ietf.org [mailto:irs-discuss-bounces@ietf.org] On= Behalf Of Shah, Himanshu Sent: Wednesday, August 15, 2012 7:02 PM To: UTTARO, JAMES; Alia Atlas Cc: irs-discuss@ietf.org Subject: Re: [irs-discuss] IRS comments Yes I agree. I meant precedence value (pardon the use of wrong terminology)= . Each entity that injects route to routing table has an associated precedenc= e value.. Anyway, I am more curious to know why not allow access to FIB.. /himanshu -----Original Message----- From: UTTARO, JAMES [mailto:ju1738@att.com] Sent: Wednesday, August 15, 2012 7:50 PM To: Shah, Himanshu; Alia Atlas Cc: irs-discuss@ietf.org Subject: RE: [irs-discuss] IRS comments Inject routes yes, but I would not assume that implies that all state from = IRS is prioritized.. I think an important point to remember is that how IRS= interfaces with routing state learned via network protocols needs to be pa= rt of this effort.. Jim Uttaro -----Original Message----- From: irs-discuss-bounces@ietf.org [mailto:irs-discuss-bounces@ietf.org] On= Behalf Of Shah, Himanshu Sent: Wednesday, August 15, 2012 6:57 PM To: Alia Atlas Cc: irs-discuss@ietf.org Subject: Re: [irs-discuss] IRS comments OK - So that I am clear... IRS would provide interface to RIB such that routes can be injected with pr= iority and the local routing table manager on the node would then apply pre= cedence rules, select the route, do ARP resolve (if ETH) and inject the pre= fix with next-hop info into the FIB. The next step is then programming the FIB on the line card (if applicable). Would make sense for IRS to not provide interface to the FIB on the second = step. But you are saying that it would also not provide interface to FIB of the f= irst step. Is that correct? /himanshu -----Original Message----- From: Alia Atlas [mailto:akatlas@gmail.com] Sent: Wednesday, August 15, 2012 6:05 PM To: Shah, Himanshu Cc: irs-discuss@ietf.org Subject: Re: [irs-discuss] IRS comments I don't see IRS going below the RIB layer to FIB. Alia On Wed, Aug 15, 2012 at 2:21 PM, Shah, Himanshu wrote: > I will let Ed clarify on what he means by "controller" . > > > > But here is my view of "application", "controller", "use-case" etc > etc, > > > > When an XaaS processes a request it takes into consideration of > availability of the CPU, memory, application data, cost of power, etc. > to instantiate a VM on some host machine. > > One additional resource taken into consideration is the availability > and/or requirement of the network connectivity between the resources > > such as VM, application data, requester, etc. > > > > The provider of XaaS thingy is the application server. > > (Centralized) Network "Controller(s)" knows current state of network > infrastructure and (to be decided how much it) controls member network > nodes using IRS. > > The "use case" here is to be able to dynamically create L2/L2.5/L3 > connectivity with specific TE characteristics between the (perhaps > geographically dispersed) resource points. > > > > In hierarchical fashion: Application server <- (application interface) = -> > Network Controller <- (IRS) -> Network Node > > > > As we heard at IETF, IRS has tentacles in network nodes from BGP > policies, all the way down to FIBs/LFIBs/ACL. > > > > So we need use cases for which applications would require > accessibility to - > > BGP Policies > > RIB > > LSDB ( I saw an email which talks about reducing IGP to link > distribution protocol and running SPF in centralized network > controller) > > LIB > > FIB > > ACL (this is perhaps obvious) > > Etc etc > > > > I broad brushed and simplified a lot here to express my view - not > sure if this jives with others. > > > > /Himanshu > > > > > > > > > > > > > > > > > > From: irs-discuss-bounces@ietf.org > [mailto:irs-discuss-bounces@ietf.org] On Behalf Of Olen Stokes > Sent: Wednesday, August 15, 2012 1:30 PM > To: Edward Crabbe; Alia Atlas > Cc: David Lake (dlake); irs-discuss@ietf.org > > > Subject: Re: [irs-discuss] IRS comments > > > > Thanks. Can you also give us what you mean by "controller". > > > > Olen > > > > From: Edward Crabbe [mailto:edc@google.com] > Sent: Wednesday, August 15, 2012 1:24 PM > To: Alia Atlas > Cc: David Lake (dlake); Olen Stokes; irs-discuss@ietf.org > Subject: Re: [irs-discuss] IRS comments > > > > s/wg/pre-BOF proto-wg :P/g > > On Wed, Aug 15, 2012 at 10:22 AM, Edward Crabbe wrote: > > +1 Alia. There's been a lot of confusion over this term. Having gone > +a few > rounds with folks on this one in other forums, I'll point out that > what most people mean by application (myself included) is some set of > control software (a scheduler, a path optimizer etc) that provides > instructions to the controller, which are in turn translated to the appro= priate PDUs. > > > > Having 'end user' applications request/make changes to forwarding > state without an intermediate broker/aggregator acting on their behalf > sounds like a recipe for disaster for operational networks, or, as is > more likely, a quick hike to the protocol grave yard (followed by a > long grave-side party > :P) for the wg. > > > > my 2c. > > > > On Wed, Aug 15, 2012 at 8:48 AM, Alia Atlas wrote: > > Hi David, > > We do need to clarify what is meant by an application. I would not > expect that real user-land applications would talk directly to routing > devices via IRS. I can see that going through an intermediary. The > IRS abstractions are unlikely to be as high-level as user-land > applications would want and the security and policy issues would get > exciting. > > Clarifying what applications are more in-scope initially is part of > where use-cases will help. Can you write up ones to > categorize/describe your thoughts? > > Alia > > > On Wed, Aug 15, 2012 at 11:40 AM, David Lake (dlake) > wrote: >> As another newbie to this, I have some questions about "application >> vendors." >> >> Who is the target audience here ? That will determine what functionali= ty >> and abstraction of the network we need to expose to that "application." >> >> This presently appears to be a little confused - at least in my mind. >> The draft talks very much as if the application we are addressing is >> an OSS/BSS system, essentially provisioning from the domain owner. >> >> However, linking this to the wider goals of SDN as voiced by >> customers/users at the first Open Network Summit, there appears to be >> a desire for cross-domain and user-land application integration. >> >> At this level - as an example giving a content cache the ability to >> ensure delivery of an HD video to an end user - the application will >> not be interested in the underlying topology of the network; it will >> need to know that application X can be delivered with parameters Y betwe= en reading from >> the content store to delivery to the user's browser. How the stream >> traverses the infrastructure is immaterial. >> >> Are we intending that IRS satisfies BOTH these requirements (i.e. for >> ALL applications ?), or should we be more prescriptive about which >> application space we are addressing ? >> >> Thanks >> >> David >> >> -----Original Message----- >> From: irs-discuss-bounces@ietf.org >> [mailto:irs-discuss-bounces@ietf.org] >> On Behalf Of Alia Atlas >> Sent: Wednesday, August 15, 2012 7:23 AM >> To: Olen Stokes >> Cc: irs-discuss@ietf.org >> Subject: Re: [irs-discuss] IRS comments >> >> I have not specifically heard from application vendors about this. >> My current plan is that we focus on a Use-Cases draft and define >> within that some motivating use-cases that we agree are good first >> targets. Those can drive which subset of functionality we focus on. >> >> More use-cases are, of course, quite welcome. Posting them to the >> mailing list is a good first start. Russ White is starting the >> general use-cases draft based on the three use-cases that he sent to the= list. >> >> Alia >> >> On Wed, Aug 15, 2012 at 9:43 AM, Olen Stokes >> >> wrote: >>> Are there applications vendors out there that already have specific >>> requirements for what this " subset of the data-models for sub-interfac= es" >>> should be? >>> >>> Olen >>> >>> -----Original Message----- >>> From: irs-discuss-bounces@ietf.org >>> [mailto:irs-discuss-bounces@ietf.org] On Behalf Of Alia Atlas >>> Sent: Wednesday, August 15, 2012 9:08 AM >>> To: Shah, Himanshu >>> Cc: Gert Grammel; irs-discuss@ietf.org; Lenny Giuliano; Thomas >>> Nadeau; Alia Atlas; Scott Whyte >>> Subject: Re: [irs-discuss] IRS comments >>> >>> Hi Himanshu, >>> >>> Welcome. I agree that IRS isn't going to spring into being fully >>> formed - I expect that we'll focus on a subset of the data-models >>> for sub-interfaces along with an associated protocol (whether that >>> is a new one or extending an existing one). >>> >>> Alia >>> >>> On Wed, Aug 15, 2012 at 7:41 AM, Shah, Himanshu wrote= : >>>> Newbie to this discussions list and have read only a last couple of >>>> mails, so pardon the repeat if somebody has already raised the >>>> following as a concern. >>>> >>>> I realize we are early in IRS architecture definition but one thing >>>> to keep in mind is the user experience. >>>> We need to make sure that exposed interface to >>>> RIB/LFIB/FIB/IGPs/BGP/LSDBs etc etc provide a consistent >>>> predictive action/response/events even when different >>>> implementations has varying capabilities. >>>> >>>> At the moment it seems like a wild wild west. >>>> Perhaps IRS can be defined in phases starting with a simpler, >>>> limited version.. >>>> >>>> Thanks, >>>> himanshu >>>> >>>> >>>> -----Original Message----- >>>> From: irs-discuss-bounces@ietf.org >>>> [mailto:irs-discuss-bounces@ietf.org] On Behalf Of Alia Atlas >>>> Sent: Monday, August 13, 2012 8:41 AM >>>> To: Scott Whyte >>>> Cc: Thomas Nadeau; Gert Grammel; Alia Atlas; Lenny Giuliano; >>>> irs-discuss@ietf.org >>>> Subject: Re: [irs-discuss] IRS comments >>>> >>>> ...snip... >>>> >>>> On Fri, Aug 10, 2012 at 9:03 PM, Scott Whyte wrote= : >>>>> On Fri, Aug 10, 2012 at 5:16 PM, Alia Atlas wrote= : >>>> >>>>>> I do think it is important to have the RIB as an arbitration mechani= sm >>>>>> on the device. Russ's suggestion that for the RIB sub-interface, t= he >>>>>> IRS agent might communicate logically to an IRS routing process >>>>>> gives good semantics and interactions. Obviously, >>>>>> implementations may differ. >>>>> >>>>> As long as the arbitration mechanism is reconfigurable by the >>>>> operator to whatever precedence they want, I agree. Its not clear >>>>> to me if various RIB implementations treat all proffered routes >>>>> the same, nor if they store the same meta-data with all protocol sour= ces. >>>>> So there needs to be some way for the operator to leverage exposed >>>>> protocol-specific optimizations, without conflict from the other >>>>> routing processes, if they so desire. OTOH if it can all be done >>>>> via static routes, it seems much simpler. :) >>>> >>>> Clearly the IRS sub-interface for the RIB needs to introduce/define >>>> the different precedences; my assumption is that it would be per >>>> route with a well-defined small set of meta-data. This is part of >>>> where having good use-cases will help us understand what behavior >>>> is necessary. The static routes do seem like a simpler case to start = with. >>>> >>>> Alia >>>> _______________________________________________ >>>> 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 >> _______________________________________________ >> 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 > > > > _______________________________________________ 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 Return-Path: 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 9F74C21F85DD for ; Thu, 16 Aug 2012 07:42:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.13 X-Spam-Level: X-Spam-Status: No, score=-3.13 tagged_above=-999 required=5 tests=[AWL=0.135, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-1] 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 0oSsm1R5iCZO for ; Thu, 16 Aug 2012 07:42:51 -0700 (PDT) Received: from mx0a-00103a01.pphosted.com (mx0a-00103a01.pphosted.com [67.231.144.234]) by ietfa.amsl.com (Postfix) with ESMTP id 598EF21F85E0 for ; Thu, 16 Aug 2012 07:42:51 -0700 (PDT) Received: from pps.filterd (m0000419 [127.0.0.1]) by mx0a-00103a01.pphosted.com (8.14.4/8.14.4) with SMTP id q7GEYtFB015754; Thu, 16 Aug 2012 10:42:50 -0400 Received: from mdwexght02.ciena.com (LIN1-118-36-29.ciena.com [63.118.36.29]) by mx0a-00103a01.pphosted.com with ESMTP id 16s1py88ru-2 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 16 Aug 2012 10:42:50 -0400 Received: from MDWEXCHCGSIHT01.ciena.com (10.4.140.106) by MDWEXGHT02.ciena.com (10.4.140.213) with Microsoft SMTP Server (TLS) id 8.3.192.1; Thu, 16 Aug 2012 10:42:50 -0400 Received: from MDWEXGMB02.ciena.com ([::1]) by MDWEXCHCGSIHT01.ciena.com ([::1]) with mapi; Thu, 16 Aug 2012 10:42:50 -0400 From: "Shah, Himanshu" To: Alia Atlas Date: Thu, 16 Aug 2012 10:42:48 -0400 Thread-Topic: [irs-discuss] IRS comments Thread-Index: Ac17WskSuUbg+KudT3aBV+c9faJxUAAR1p2w Message-ID: References: <812700A304640D4292205D5E83FC59E1061C211D@p-embx01-eq.jnpr.net> <3512BB31280C39448A9880F61DD54CEB09C07E@xmb-aln-x09.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-tm-as-product-ver: SMEX-10.0.0.1412-7.000.1014-19116.000 x-tm-as-result: No--22.740000-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.7.7855, 1.0.260, 0.0.0000 definitions=2012-08-16_05:2012-08-16, 2012-08-16, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=1 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=6.0.2-1203120001 definitions=main-1208160131 Cc: "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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Aug 2012 14:42:52 -0000 This is precisely the answer I was looking for. It's a domain issue. This is how IRS distinguishes itself from OpenFlow/For= CES/GSMP etc etc Understand the reasoning but was hoping that IRS would provide one uniform = interface - top to bottom, so implementers do not have to deal with supporting multiple utilities. What about ACL (Access Control List), ifMIB specific info etc. (trying to g= et sense on the lowest layer that IRS will cover) Thanks, himanshu -----Original Message----- From: Alia Atlas [mailto:akatlas@gmail.com] Sent: Wednesday, August 15, 2012 10:57 PM To: Shah, Himanshu Cc: UTTARO, JAMES; irs-discuss@ietf.org Subject: Re: [irs-discuss] IRS comments What is the benefit of allowing access to the FIB vs. the associated comple= xity? If something wants to inject state directly into the forwarding plane, isn'= t that what ForCES or OpenFlow is for? Why get into low-level assembly when we've got a C-equiv? (Still not a hig= her level language that apps might speak with associated abstractions, but = closer). Alia On Wed, Aug 15, 2012 at 10:01 PM, Shah, Himanshu wrote: > Yes I agree. I meant precedence value (pardon the use of wrong terminolog= y). > Each entity that injects route to routing table has an associated precede= nce value.. > > Anyway, I am more curious to know why not allow access to FIB.. > > /himanshu > > -----Original Message----- > From: UTTARO, JAMES [mailto:ju1738@att.com] > Sent: Wednesday, August 15, 2012 7:50 PM > To: Shah, Himanshu; Alia Atlas > Cc: irs-discuss@ietf.org > Subject: RE: [irs-discuss] IRS comments > > Inject routes yes, but I would not assume that implies that all state fro= m IRS is prioritized.. I think an important point to remember is that how I= RS interfaces with routing state learned via network protocols needs to be = part of this effort.. > > Jim Uttaro > > -----Original Message----- > From: irs-discuss-bounces@ietf.org > [mailto:irs-discuss-bounces@ietf.org] On Behalf Of Shah, Himanshu > Sent: Wednesday, August 15, 2012 6:57 PM > To: Alia Atlas > Cc: irs-discuss@ietf.org > Subject: Re: [irs-discuss] IRS comments > > OK - So that I am clear... > > IRS would provide interface to RIB such that routes can be injected with = priority and the local routing table manager on the node would then apply p= recedence rules, select the route, do ARP resolve (if ETH) and inject the p= refix with next-hop info into the FIB. > > The next step is then programming the FIB on the line card (if applicable= ). > > Would make sense for IRS to not provide interface to the FIB on the secon= d step. > But you are saying that it would also not provide interface to FIB of the= first step. > > Is that correct? > > /himanshu > > -----Original Message----- > From: Alia Atlas [mailto:akatlas@gmail.com] > Sent: Wednesday, August 15, 2012 6:05 PM > To: Shah, Himanshu > Cc: irs-discuss@ietf.org > Subject: Re: [irs-discuss] IRS comments > > I don't see IRS going below the RIB layer to FIB. > > Alia > > On Wed, Aug 15, 2012 at 2:21 PM, Shah, Himanshu wrote: >> I will let Ed clarify on what he means by "controller" . >> >> >> >> But here is my view of "application", "controller", "use-case" etc >> etc, >> >> >> >> When an XaaS processes a request it takes into consideration of >> availability of the CPU, memory, application data, cost of power, etc. >> to instantiate a VM on some host machine. >> >> One additional resource taken into consideration is the availability >> and/or requirement of the network connectivity between the resources >> >> such as VM, application data, requester, etc. >> >> >> >> The provider of XaaS thingy is the application server. >> >> (Centralized) Network "Controller(s)" knows current state of network >> infrastructure and (to be decided how much it) controls member >> network nodes using IRS. >> >> The "use case" here is to be able to dynamically create L2/L2.5/L3 >> connectivity with specific TE characteristics between the (perhaps >> geographically dispersed) resource points. >> >> >> >> In hierarchical fashion: Application server <- (application interface)= -> >> Network Controller <- (IRS) -> Network Node >> >> >> >> As we heard at IETF, IRS has tentacles in network nodes from BGP >> policies, all the way down to FIBs/LFIBs/ACL. >> >> >> >> So we need use cases for which applications would require >> accessibility to - >> >> BGP Policies >> >> RIB >> >> LSDB ( I saw an email which talks about reducing IGP to link >> distribution protocol and running SPF in centralized network >> controller) >> >> LIB >> >> FIB >> >> ACL (this is perhaps obvious) >> >> Etc etc >> >> >> >> I broad brushed and simplified a lot here to express my view - not >> sure if this jives with others. >> >> >> >> /Himanshu >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> From: irs-discuss-bounces@ietf.org >> [mailto:irs-discuss-bounces@ietf.org] On Behalf Of Olen Stokes >> Sent: Wednesday, August 15, 2012 1:30 PM >> To: Edward Crabbe; Alia Atlas >> Cc: David Lake (dlake); irs-discuss@ietf.org >> >> >> Subject: Re: [irs-discuss] IRS comments >> >> >> >> Thanks. Can you also give us what you mean by "controller". >> >> >> >> Olen >> >> >> >> From: Edward Crabbe [mailto:edc@google.com] >> Sent: Wednesday, August 15, 2012 1:24 PM >> To: Alia Atlas >> Cc: David Lake (dlake); Olen Stokes; irs-discuss@ietf.org >> Subject: Re: [irs-discuss] IRS comments >> >> >> >> s/wg/pre-BOF proto-wg :P/g >> >> On Wed, Aug 15, 2012 at 10:22 AM, Edward Crabbe wrote: >> >> +1 Alia. There's been a lot of confusion over this term. Having >> +gone a few >> rounds with folks on this one in other forums, I'll point out that >> what most people mean by application (myself included) is some set of >> control software (a scheduler, a path optimizer etc) that provides >> instructions to the controller, which are in turn translated to the appr= opriate PDUs. >> >> >> >> Having 'end user' applications request/make changes to forwarding >> state without an intermediate broker/aggregator acting on their >> behalf sounds like a recipe for disaster for operational networks, >> or, as is more likely, a quick hike to the protocol grave yard >> (followed by a long grave-side party >> :P) for the wg. >> >> >> >> my 2c. >> >> >> >> On Wed, Aug 15, 2012 at 8:48 AM, Alia Atlas wrote: >> >> Hi David, >> >> We do need to clarify what is meant by an application. I would not >> expect that real user-land applications would talk directly to >> routing devices via IRS. I can see that going through an >> intermediary. The IRS abstractions are unlikely to be as high-level >> as user-land applications would want and the security and policy >> issues would get exciting. >> >> Clarifying what applications are more in-scope initially is part of >> where use-cases will help. Can you write up ones to >> categorize/describe your thoughts? >> >> Alia >> >> >> On Wed, Aug 15, 2012 at 11:40 AM, David Lake (dlake) >> >> wrote: >>> As another newbie to this, I have some questions about "application >>> vendors." >>> >>> Who is the target audience here ? That will determine what functional= ity >>> and abstraction of the network we need to expose to that "application." >>> >>> This presently appears to be a little confused - at least in my mind. >>> The draft talks very much as if the application we are addressing is >>> an OSS/BSS system, essentially provisioning from the domain owner. >>> >>> However, linking this to the wider goals of SDN as voiced by >>> customers/users at the first Open Network Summit, there appears to >>> be a desire for cross-domain and user-land application integration. >>> >>> At this level - as an example giving a content cache the ability to >>> ensure delivery of an HD video to an end user - the application will >>> not be interested in the underlying topology of the network; it will >>> need to know that application X can be delivered with parameters Y betw= een reading from >>> the content store to delivery to the user's browser. How the stream >>> traverses the infrastructure is immaterial. >>> >>> Are we intending that IRS satisfies BOTH these requirements (i.e. >>> for ALL applications ?), or should we be more prescriptive about >>> which application space we are addressing ? >>> >>> Thanks >>> >>> David >>> >>> -----Original Message----- >>> From: irs-discuss-bounces@ietf.org >>> [mailto:irs-discuss-bounces@ietf.org] >>> On Behalf Of Alia Atlas >>> Sent: Wednesday, August 15, 2012 7:23 AM >>> To: Olen Stokes >>> Cc: irs-discuss@ietf.org >>> Subject: Re: [irs-discuss] IRS comments >>> >>> I have not specifically heard from application vendors about this. >>> My current plan is that we focus on a Use-Cases draft and define >>> within that some motivating use-cases that we agree are good first >>> targets. Those can drive which subset of functionality we focus on. >>> >>> More use-cases are, of course, quite welcome. Posting them to the >>> mailing list is a good first start. Russ White is starting the >>> general use-cases draft based on the three use-cases that he sent to th= e list. >>> >>> Alia >>> >>> On Wed, Aug 15, 2012 at 9:43 AM, Olen Stokes >>> >>> wrote: >>>> Are there applications vendors out there that already have specific >>>> requirements for what this " subset of the data-models for sub-interfa= ces" >>>> should be? >>>> >>>> Olen >>>> >>>> -----Original Message----- >>>> From: irs-discuss-bounces@ietf.org >>>> [mailto:irs-discuss-bounces@ietf.org] On Behalf Of Alia Atlas >>>> Sent: Wednesday, August 15, 2012 9:08 AM >>>> To: Shah, Himanshu >>>> Cc: Gert Grammel; irs-discuss@ietf.org; Lenny Giuliano; Thomas >>>> Nadeau; Alia Atlas; Scott Whyte >>>> Subject: Re: [irs-discuss] IRS comments >>>> >>>> Hi Himanshu, >>>> >>>> Welcome. I agree that IRS isn't going to spring into being fully >>>> formed - I expect that we'll focus on a subset of the data-models >>>> for sub-interfaces along with an associated protocol (whether that >>>> is a new one or extending an existing one). >>>> >>>> Alia >>>> >>>> On Wed, Aug 15, 2012 at 7:41 AM, Shah, Himanshu wrot= e: >>>>> Newbie to this discussions list and have read only a last couple >>>>> of mails, so pardon the repeat if somebody has already raised the >>>>> following as a concern. >>>>> >>>>> I realize we are early in IRS architecture definition but one >>>>> thing to keep in mind is the user experience. >>>>> We need to make sure that exposed interface to >>>>> RIB/LFIB/FIB/IGPs/BGP/LSDBs etc etc provide a consistent >>>>> predictive action/response/events even when different >>>>> implementations has varying capabilities. >>>>> >>>>> At the moment it seems like a wild wild west. >>>>> Perhaps IRS can be defined in phases starting with a simpler, >>>>> limited version.. >>>>> >>>>> Thanks, >>>>> himanshu >>>>> >>>>> >>>>> -----Original Message----- >>>>> From: irs-discuss-bounces@ietf.org >>>>> [mailto:irs-discuss-bounces@ietf.org] On Behalf Of Alia Atlas >>>>> Sent: Monday, August 13, 2012 8:41 AM >>>>> To: Scott Whyte >>>>> Cc: Thomas Nadeau; Gert Grammel; Alia Atlas; Lenny Giuliano; >>>>> irs-discuss@ietf.org >>>>> Subject: Re: [irs-discuss] IRS comments >>>>> >>>>> ...snip... >>>>> >>>>> On Fri, Aug 10, 2012 at 9:03 PM, Scott Whyte wrot= e: >>>>>> On Fri, Aug 10, 2012 at 5:16 PM, Alia Atlas wrot= e: >>>>> >>>>>>> I do think it is important to have the RIB as an arbitration mechan= ism >>>>>>> on the device. Russ's suggestion that for the RIB sub-interface, = the >>>>>>> IRS agent might communicate logically to an IRS routing process >>>>>>> gives good semantics and interactions. Obviously, >>>>>>> implementations may differ. >>>>>> >>>>>> As long as the arbitration mechanism is reconfigurable by the >>>>>> operator to whatever precedence they want, I agree. Its not >>>>>> clear to me if various RIB implementations treat all proffered >>>>>> routes the same, nor if they store the same meta-data with all proto= col sources. >>>>>> So there needs to be some way for the operator to leverage >>>>>> exposed protocol-specific optimizations, without conflict from >>>>>> the other routing processes, if they so desire. OTOH if it can >>>>>> all be done via static routes, it seems much simpler. :) >>>>> >>>>> Clearly the IRS sub-interface for the RIB needs to >>>>> introduce/define the different precedences; my assumption is that >>>>> it would be per route with a well-defined small set of meta-data. >>>>> This is part of where having good use-cases will help us >>>>> understand what behavior is necessary. The static routes do seem lik= e a simpler case to start with. >>>>> >>>>> Alia >>>>> _______________________________________________ >>>>> 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 >>> _______________________________________________ >>> 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 >> >> >> >> > _______________________________________________ > irs-discuss mailing list > irs-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/irs-discuss Return-Path: 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 3C27921F85D3 for ; Thu, 16 Aug 2012 07:42:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.114 X-Spam-Level: X-Spam-Status: No, score=-3.114 tagged_above=-999 required=5 tests=[AWL=0.151, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-1] 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 ena9WEgFK26i for ; Thu, 16 Aug 2012 07:42:27 -0700 (PDT) Received: from mx0b-00103a01.pphosted.com (mx0b-00103a01.pphosted.com [67.231.152.227]) by ietfa.amsl.com (Postfix) with ESMTP id 9CDD621F85D2 for ; Thu, 16 Aug 2012 07:42:27 -0700 (PDT) Received: from pps.filterd (m0001124 [127.0.0.1]) by mx0b-00103a01.pphosted.com (8.14.4/8.14.4) with SMTP id q7GEYwVl011125; Thu, 16 Aug 2012 10:41:08 -0400 Received: from mdwexght02.ciena.com (LIN1-118-36-29.ciena.com [63.118.36.29]) by mx0b-00103a01.pphosted.com with ESMTP id 16s0nk8c20-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 16 Aug 2012 10:41:07 -0400 Received: from MDWEXCHCGSIHT01.ciena.com (10.4.140.106) by MDWEXGHT02.ciena.com (10.4.140.213) with Microsoft SMTP Server (TLS) id 8.3.192.1; Thu, 16 Aug 2012 10:41:09 -0400 Received: from MDWEXGMB02.ciena.com ([::1]) by MDWEXCHCGSIHT01.ciena.com ([::1]) with mapi; Thu, 16 Aug 2012 10:41:09 -0400 From: "Shah, Himanshu" To: "Dutta, Pranjal K (Pranjal)" , "UTTARO, JAMES" , Alia Atlas Date: Thu, 16 Aug 2012 10:41:06 -0400 Thread-Topic: [irs-discuss] IRS comments Thread-Index: Ac15UPmWZFj3YBmsT9Smjrge48ksHAATypTAAFoVXoAAAUAUgAABZOIAAAKyOQAAAEVwAAADS7QAAAAO5wAAADV/gAAByQUAAAfLkAAAAdXVgAAGmN5wAAiugSAADB62sAAI/lNw Message-ID: References: <812700A304640D4292205D5E83FC59E1061C211D@p-embx01-eq.jnpr.net> <3512BB31280C39448A9880F61DD54CEB09C07E@xmb-aln-x09.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-tm-as-product-ver: SMEX-10.0.0.1412-7.000.1014-19116.000 x-tm-as-result: No--22.740000-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.7.7855, 1.0.260, 0.0.0000 definitions=2012-08-16_05:2012-08-16, 2012-08-16, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=1 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=6.0.2-1203120001 definitions=main-1208160131 Cc: "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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Aug 2012 14:42:29 -0000 I do agree but was asking specifically to understand the difference between= IRS and other utilities like OpenFlow, GSMP, etc. and what is in IRS scope. IRS just provides the interface. If it were to = cover FIB, the "controller" would not add FIB and RIB in the same node/network. Anyway, curious about IRS boundaries - what about PCE which offloads CSPF? Thanks, Himanshu -----Original Message----- From: Dutta, Pranjal K (Pranjal) [mailto:pranjal.dutta@alcatel-lucent.com] Sent: Thursday, August 16, 2012 12:30 AM To: Shah, Himanshu; UTTARO, JAMES; Alia Atlas Cc: irs-discuss@ietf.org Subject: RE: [irs-discuss] IRS comments I think I may be missing something basic here. If access to both RIB (injec= ting route) and FIB (injecting h/w entry??) are allowed then what decides t= he consistency between RIB and FIB? I think at this moment we shouldn't go = below the RIB. Thanks, Pranjal -----Original Message----- From: irs-discuss-bounces@ietf.org [mailto:irs-discuss-bounces@ietf.org] On= Behalf Of Shah, Himanshu Sent: Wednesday, August 15, 2012 7:02 PM To: UTTARO, JAMES; Alia Atlas Cc: irs-discuss@ietf.org Subject: Re: [irs-discuss] IRS comments Yes I agree. I meant precedence value (pardon the use of wrong terminology)= . Each entity that injects route to routing table has an associated precedenc= e value.. Anyway, I am more curious to know why not allow access to FIB.. /himanshu -----Original Message----- From: UTTARO, JAMES [mailto:ju1738@att.com] Sent: Wednesday, August 15, 2012 7:50 PM To: Shah, Himanshu; Alia Atlas Cc: irs-discuss@ietf.org Subject: RE: [irs-discuss] IRS comments Inject routes yes, but I would not assume that implies that all state from = IRS is prioritized.. I think an important point to remember is that how IRS= interfaces with routing state learned via network protocols needs to be pa= rt of this effort.. Jim Uttaro -----Original Message----- From: irs-discuss-bounces@ietf.org [mailto:irs-discuss-bounces@ietf.org] On= Behalf Of Shah, Himanshu Sent: Wednesday, August 15, 2012 6:57 PM To: Alia Atlas Cc: irs-discuss@ietf.org Subject: Re: [irs-discuss] IRS comments OK - So that I am clear... IRS would provide interface to RIB such that routes can be injected with pr= iority and the local routing table manager on the node would then apply pre= cedence rules, select the route, do ARP resolve (if ETH) and inject the pre= fix with next-hop info into the FIB. The next step is then programming the FIB on the line card (if applicable). Would make sense for IRS to not provide interface to the FIB on the second = step. But you are saying that it would also not provide interface to FIB of the f= irst step. Is that correct? /himanshu -----Original Message----- From: Alia Atlas [mailto:akatlas@gmail.com] Sent: Wednesday, August 15, 2012 6:05 PM To: Shah, Himanshu Cc: irs-discuss@ietf.org Subject: Re: [irs-discuss] IRS comments I don't see IRS going below the RIB layer to FIB. Alia On Wed, Aug 15, 2012 at 2:21 PM, Shah, Himanshu wrote: > I will let Ed clarify on what he means by "controller" . > > > > But here is my view of "application", "controller", "use-case" etc > etc, > > > > When an XaaS processes a request it takes into consideration of > availability of the CPU, memory, application data, cost of power, etc. > to instantiate a VM on some host machine. > > One additional resource taken into consideration is the availability > and/or requirement of the network connectivity between the resources > > such as VM, application data, requester, etc. > > > > The provider of XaaS thingy is the application server. > > (Centralized) Network "Controller(s)" knows current state of network > infrastructure and (to be decided how much it) controls member network > nodes using IRS. > > The "use case" here is to be able to dynamically create L2/L2.5/L3 > connectivity with specific TE characteristics between the (perhaps > geographically dispersed) resource points. > > > > In hierarchical fashion: Application server <- (application interface) = -> > Network Controller <- (IRS) -> Network Node > > > > As we heard at IETF, IRS has tentacles in network nodes from BGP > policies, all the way down to FIBs/LFIBs/ACL. > > > > So we need use cases for which applications would require > accessibility to - > > BGP Policies > > RIB > > LSDB ( I saw an email which talks about reducing IGP to link > distribution protocol and running SPF in centralized network > controller) > > LIB > > FIB > > ACL (this is perhaps obvious) > > Etc etc > > > > I broad brushed and simplified a lot here to express my view - not > sure if this jives with others. > > > > /Himanshu > > > > > > > > > > > > > > > > > > From: irs-discuss-bounces@ietf.org > [mailto:irs-discuss-bounces@ietf.org] On Behalf Of Olen Stokes > Sent: Wednesday, August 15, 2012 1:30 PM > To: Edward Crabbe; Alia Atlas > Cc: David Lake (dlake); irs-discuss@ietf.org > > > Subject: Re: [irs-discuss] IRS comments > > > > Thanks. Can you also give us what you mean by "controller". > > > > Olen > > > > From: Edward Crabbe [mailto:edc@google.com] > Sent: Wednesday, August 15, 2012 1:24 PM > To: Alia Atlas > Cc: David Lake (dlake); Olen Stokes; irs-discuss@ietf.org > Subject: Re: [irs-discuss] IRS comments > > > > s/wg/pre-BOF proto-wg :P/g > > On Wed, Aug 15, 2012 at 10:22 AM, Edward Crabbe wrote: > > +1 Alia. There's been a lot of confusion over this term. Having gone > +a few > rounds with folks on this one in other forums, I'll point out that > what most people mean by application (myself included) is some set of > control software (a scheduler, a path optimizer etc) that provides > instructions to the controller, which are in turn translated to the appro= priate PDUs. > > > > Having 'end user' applications request/make changes to forwarding > state without an intermediate broker/aggregator acting on their behalf > sounds like a recipe for disaster for operational networks, or, as is > more likely, a quick hike to the protocol grave yard (followed by a > long grave-side party > :P) for the wg. > > > > my 2c. > > > > On Wed, Aug 15, 2012 at 8:48 AM, Alia Atlas wrote: > > Hi David, > > We do need to clarify what is meant by an application. I would not > expect that real user-land applications would talk directly to routing > devices via IRS. I can see that going through an intermediary. The > IRS abstractions are unlikely to be as high-level as user-land > applications would want and the security and policy issues would get > exciting. > > Clarifying what applications are more in-scope initially is part of > where use-cases will help. Can you write up ones to > categorize/describe your thoughts? > > Alia > > > On Wed, Aug 15, 2012 at 11:40 AM, David Lake (dlake) > wrote: >> As another newbie to this, I have some questions about "application >> vendors." >> >> Who is the target audience here ? That will determine what functionali= ty >> and abstraction of the network we need to expose to that "application." >> >> This presently appears to be a little confused - at least in my mind. >> The draft talks very much as if the application we are addressing is >> an OSS/BSS system, essentially provisioning from the domain owner. >> >> However, linking this to the wider goals of SDN as voiced by >> customers/users at the first Open Network Summit, there appears to be >> a desire for cross-domain and user-land application integration. >> >> At this level - as an example giving a content cache the ability to >> ensure delivery of an HD video to an end user - the application will >> not be interested in the underlying topology of the network; it will >> need to know that application X can be delivered with parameters Y betwe= en reading from >> the content store to delivery to the user's browser. How the stream >> traverses the infrastructure is immaterial. >> >> Are we intending that IRS satisfies BOTH these requirements (i.e. for >> ALL applications ?), or should we be more prescriptive about which >> application space we are addressing ? >> >> Thanks >> >> David >> >> -----Original Message----- >> From: irs-discuss-bounces@ietf.org >> [mailto:irs-discuss-bounces@ietf.org] >> On Behalf Of Alia Atlas >> Sent: Wednesday, August 15, 2012 7:23 AM >> To: Olen Stokes >> Cc: irs-discuss@ietf.org >> Subject: Re: [irs-discuss] IRS comments >> >> I have not specifically heard from application vendors about this. >> My current plan is that we focus on a Use-Cases draft and define >> within that some motivating use-cases that we agree are good first >> targets. Those can drive which subset of functionality we focus on. >> >> More use-cases are, of course, quite welcome. Posting them to the >> mailing list is a good first start. Russ White is starting the >> general use-cases draft based on the three use-cases that he sent to the= list. >> >> Alia >> >> On Wed, Aug 15, 2012 at 9:43 AM, Olen Stokes >> >> wrote: >>> Are there applications vendors out there that already have specific >>> requirements for what this " subset of the data-models for sub-interfac= es" >>> should be? >>> >>> Olen >>> >>> -----Original Message----- >>> From: irs-discuss-bounces@ietf.org >>> [mailto:irs-discuss-bounces@ietf.org] On Behalf Of Alia Atlas >>> Sent: Wednesday, August 15, 2012 9:08 AM >>> To: Shah, Himanshu >>> Cc: Gert Grammel; irs-discuss@ietf.org; Lenny Giuliano; Thomas >>> Nadeau; Alia Atlas; Scott Whyte >>> Subject: Re: [irs-discuss] IRS comments >>> >>> Hi Himanshu, >>> >>> Welcome. I agree that IRS isn't going to spring into being fully >>> formed - I expect that we'll focus on a subset of the data-models >>> for sub-interfaces along with an associated protocol (whether that >>> is a new one or extending an existing one). >>> >>> Alia >>> >>> On Wed, Aug 15, 2012 at 7:41 AM, Shah, Himanshu wrote= : >>>> Newbie to this discussions list and have read only a last couple of >>>> mails, so pardon the repeat if somebody has already raised the >>>> following as a concern. >>>> >>>> I realize we are early in IRS architecture definition but one thing >>>> to keep in mind is the user experience. >>>> We need to make sure that exposed interface to >>>> RIB/LFIB/FIB/IGPs/BGP/LSDBs etc etc provide a consistent >>>> predictive action/response/events even when different >>>> implementations has varying capabilities. >>>> >>>> At the moment it seems like a wild wild west. >>>> Perhaps IRS can be defined in phases starting with a simpler, >>>> limited version.. >>>> >>>> Thanks, >>>> himanshu >>>> >>>> >>>> -----Original Message----- >>>> From: irs-discuss-bounces@ietf.org >>>> [mailto:irs-discuss-bounces@ietf.org] On Behalf Of Alia Atlas >>>> Sent: Monday, August 13, 2012 8:41 AM >>>> To: Scott Whyte >>>> Cc: Thomas Nadeau; Gert Grammel; Alia Atlas; Lenny Giuliano; >>>> irs-discuss@ietf.org >>>> Subject: Re: [irs-discuss] IRS comments >>>> >>>> ...snip... >>>> >>>> On Fri, Aug 10, 2012 at 9:03 PM, Scott Whyte wrote= : >>>>> On Fri, Aug 10, 2012 at 5:16 PM, Alia Atlas wrote= : >>>> >>>>>> I do think it is important to have the RIB as an arbitration mechani= sm >>>>>> on the device. Russ's suggestion that for the RIB sub-interface, t= he >>>>>> IRS agent might communicate logically to an IRS routing process >>>>>> gives good semantics and interactions. Obviously, >>>>>> implementations may differ. >>>>> >>>>> As long as the arbitration mechanism is reconfigurable by the >>>>> operator to whatever precedence they want, I agree. Its not clear >>>>> to me if various RIB implementations treat all proffered routes >>>>> the same, nor if they store the same meta-data with all protocol sour= ces. >>>>> So there needs to be some way for the operator to leverage exposed >>>>> protocol-specific optimizations, without conflict from the other >>>>> routing processes, if they so desire. OTOH if it can all be done >>>>> via static routes, it seems much simpler. :) >>>> >>>> Clearly the IRS sub-interface for the RIB needs to introduce/define >>>> the different precedences; my assumption is that it would be per >>>> route with a well-defined small set of meta-data. This is part of >>>> where having good use-cases will help us understand what behavior >>>> is necessary. The static routes do seem like a simpler case to start = with. >>>> >>>> Alia >>>> _______________________________________________ >>>> 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 >> _______________________________________________ >> 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 > > > > _______________________________________________ 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 Return-Path: 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 5B72321E8053 for ; Wed, 15 Aug 2012 21:30:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.349 X-Spam-Level: X-Spam-Status: No, score=-7.349 tagged_above=-999 required=5 tests=[AWL=-0.750, 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 2CrQf8dtUnsM for ; Wed, 15 Aug 2012 21:30:30 -0700 (PDT) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id 2B72521E8050 for ; Wed, 15 Aug 2012 21:30:30 -0700 (PDT) Received: from ihemail2.lucent.com (h135-245-2-35.lucent.com [135.245.2.35]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id q7G4UQnZ011256 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 15 Aug 2012 23:30:26 -0500 (CDT) Received: from inbansmailrelay2.in.alcatel-lucent.com (h135-250-11-33.lucent.com [135.250.11.33]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id q7G4UNvi009037 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 15 Aug 2012 23:30:25 -0500 (CDT) Received: from INBANSXCHHUB02.in.alcatel-lucent.com (inbansxchhub02.in.alcatel-lucent.com [135.250.12.35]) by inbansmailrelay2.in.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id q7G4ULZ1027922 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 16 Aug 2012 10:00:22 +0530 Received: from INBANSXCHMBSA3.in.alcatel-lucent.com ([135.250.12.50]) by INBANSXCHHUB02.in.alcatel-lucent.com ([135.250.12.35]) with mapi; Thu, 16 Aug 2012 10:00:21 +0530 From: "Dutta, Pranjal K (Pranjal)" To: "Shah, Himanshu" , "UTTARO, JAMES" , Alia Atlas Date: Thu, 16 Aug 2012 10:00:19 +0530 Thread-Topic: [irs-discuss] IRS comments Thread-Index: Ac15UPmWZFj3YBmsT9Smjrge48ksHAATypTAAFoVXoAAAUAUgAABZOIAAAKyOQAAAEVwAAADS7QAAAAO5wAAADV/gAAByQUAAAfLkAAAAdXVgAAGmN5wAAiugSAADB62sA== Message-ID: References: <812700A304640D4292205D5E83FC59E1061C211D@p-embx01-eq.jnpr.net> <3512BB31280C39448A9880F61DD54CEB09C07E@xmb-aln-x09.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 Cc: "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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Aug 2012 04:30:32 -0000 I think I may be missing something basic here. If access to both RIB (injec= ting route) and FIB (injecting h/w entry??) are allowed then what decides t= he consistency between RIB and FIB? I think at this moment we shouldn't go = below the RIB. Thanks, Pranjal -----Original Message----- From: irs-discuss-bounces@ietf.org [mailto:irs-discuss-bounces@ietf.org] On= Behalf Of Shah, Himanshu Sent: Wednesday, August 15, 2012 7:02 PM To: UTTARO, JAMES; Alia Atlas Cc: irs-discuss@ietf.org Subject: Re: [irs-discuss] IRS comments Yes I agree. I meant precedence value (pardon the use of wrong terminology)= .=20 Each entity that injects route to routing table has an associated precedenc= e value.. Anyway, I am more curious to know why not allow access to FIB.. /himanshu -----Original Message----- From: UTTARO, JAMES [mailto:ju1738@att.com]=20 Sent: Wednesday, August 15, 2012 7:50 PM To: Shah, Himanshu; Alia Atlas Cc: irs-discuss@ietf.org Subject: RE: [irs-discuss] IRS comments Inject routes yes, but I would not assume that implies that all state from = IRS is prioritized.. I think an important point to remember is that how IRS= interfaces with routing state learned via network protocols needs to be pa= rt of this effort.. Jim Uttaro -----Original Message----- From: irs-discuss-bounces@ietf.org [mailto:irs-discuss-bounces@ietf.org] On= Behalf Of Shah, Himanshu Sent: Wednesday, August 15, 2012 6:57 PM To: Alia Atlas Cc: irs-discuss@ietf.org Subject: Re: [irs-discuss] IRS comments OK - So that I am clear... IRS would provide interface to RIB such that routes can be injected with pr= iority and the local routing table manager on the node would then apply pre= cedence rules, select the route, do ARP resolve (if ETH) and inject the pre= fix with next-hop info into the FIB. The next step is then programming the FIB on the line card (if applicable). Would make sense for IRS to not provide interface to the FIB on the second = step. But you are saying that it would also not provide interface to FIB of the f= irst step.=20 Is that correct? /himanshu -----Original Message----- From: Alia Atlas [mailto:akatlas@gmail.com] Sent: Wednesday, August 15, 2012 6:05 PM To: Shah, Himanshu Cc: irs-discuss@ietf.org Subject: Re: [irs-discuss] IRS comments I don't see IRS going below the RIB layer to FIB. Alia On Wed, Aug 15, 2012 at 2:21 PM, Shah, Himanshu wrote: > I will let Ed clarify on what he means by "controller" . > > > > But here is my view of "application", "controller", "use-case" etc=20 > etc, > > > > When an XaaS processes a request it takes into consideration of=20 > availability of the CPU, memory, application data, cost of power, etc. > to instantiate a VM on some host machine. > > One additional resource taken into consideration is the availability=20 > and/or requirement of the network connectivity between the resources > > such as VM, application data, requester, etc. > > > > The provider of XaaS thingy is the application server. > > (Centralized) Network "Controller(s)" knows current state of network=20 > infrastructure and (to be decided how much it) controls member network=20 > nodes using IRS. > > The "use case" here is to be able to dynamically create L2/L2.5/L3=20 > connectivity with specific TE characteristics between the (perhaps=20 > geographically dispersed) resource points. > > > > In hierarchical fashion: Application server <- (application interface) = -> > Network Controller <- (IRS) -> Network Node > > > > As we heard at IETF, IRS has tentacles in network nodes from BGP=20 > policies, all the way down to FIBs/LFIBs/ACL. > > > > So we need use cases for which applications would require=20 > accessibility to - > > BGP Policies > > RIB > > LSDB ( I saw an email which talks about reducing IGP to link=20 > distribution protocol and running SPF in centralized network > controller) > > LIB > > FIB > > ACL (this is perhaps obvious) > > Etc etc > > > > I broad brushed and simplified a lot here to express my view - not=20 > sure if this jives with others. > > > > /Himanshu > > > > > > > > > > > > > > > > > > From: irs-discuss-bounces@ietf.org > [mailto:irs-discuss-bounces@ietf.org] On Behalf Of Olen Stokes > Sent: Wednesday, August 15, 2012 1:30 PM > To: Edward Crabbe; Alia Atlas > Cc: David Lake (dlake); irs-discuss@ietf.org > > > Subject: Re: [irs-discuss] IRS comments > > > > Thanks. Can you also give us what you mean by "controller". > > > > Olen > > > > From: Edward Crabbe [mailto:edc@google.com] > Sent: Wednesday, August 15, 2012 1:24 PM > To: Alia Atlas > Cc: David Lake (dlake); Olen Stokes; irs-discuss@ietf.org > Subject: Re: [irs-discuss] IRS comments > > > > s/wg/pre-BOF proto-wg :P/g > > On Wed, Aug 15, 2012 at 10:22 AM, Edward Crabbe wrote: > > +1 Alia. There's been a lot of confusion over this term. Having gone=20 > +a few > rounds with folks on this one in other forums, I'll point out that=20 > what most people mean by application (myself included) is some set of=20 > control software (a scheduler, a path optimizer etc) that provides=20 > instructions to the controller, which are in turn translated to the appro= priate PDUs. > > > > Having 'end user' applications request/make changes to forwarding=20 > state without an intermediate broker/aggregator acting on their behalf=20 > sounds like a recipe for disaster for operational networks, or, as is=20 > more likely, a quick hike to the protocol grave yard (followed by a=20 > long grave-side party > :P) for the wg. > > > > my 2c. > > > > On Wed, Aug 15, 2012 at 8:48 AM, Alia Atlas wrote: > > Hi David, > > We do need to clarify what is meant by an application. I would not=20 > expect that real user-land applications would talk directly to routing=20 > devices via IRS. I can see that going through an intermediary. The=20 > IRS abstractions are unlikely to be as high-level as user-land=20 > applications would want and the security and policy issues would get=20 > exciting. > > Clarifying what applications are more in-scope initially is part of=20 > where use-cases will help. Can you write up ones to=20 > categorize/describe your thoughts? > > Alia > > > On Wed, Aug 15, 2012 at 11:40 AM, David Lake (dlake) > wrote: >> As another newbie to this, I have some questions about "application=20 >> vendors." >> >> Who is the target audience here ? That will determine what functionali= ty >> and abstraction of the network we need to expose to that "application." >> >> This presently appears to be a little confused - at least in my mind. =20 >> The draft talks very much as if the application we are addressing is=20 >> an OSS/BSS system, essentially provisioning from the domain owner. >> >> However, linking this to the wider goals of SDN as voiced by=20 >> customers/users at the first Open Network Summit, there appears to be=20 >> a desire for cross-domain and user-land application integration. >> >> At this level - as an example giving a content cache the ability to=20 >> ensure delivery of an HD video to an end user - the application will=20 >> not be interested in the underlying topology of the network; it will=20 >> need to know that application X can be delivered with parameters Y betwe= en reading from >> the content store to delivery to the user's browser. How the stream >> traverses the infrastructure is immaterial. >> >> Are we intending that IRS satisfies BOTH these requirements (i.e. for=20 >> ALL applications ?), or should we be more prescriptive about which=20 >> application space we are addressing ? >> >> Thanks >> >> David >> >> -----Original Message----- >> From: irs-discuss-bounces@ietf.org >> [mailto:irs-discuss-bounces@ietf.org] >> On Behalf Of Alia Atlas >> Sent: Wednesday, August 15, 2012 7:23 AM >> To: Olen Stokes >> Cc: irs-discuss@ietf.org >> Subject: Re: [irs-discuss] IRS comments >> >> I have not specifically heard from application vendors about this. >> My current plan is that we focus on a Use-Cases draft and define=20 >> within that some motivating use-cases that we agree are good first=20 >> targets. Those can drive which subset of functionality we focus on. >> >> More use-cases are, of course, quite welcome. Posting them to the=20 >> mailing list is a good first start. Russ White is starting the=20 >> general use-cases draft based on the three use-cases that he sent to the= list. >> >> Alia >> >> On Wed, Aug 15, 2012 at 9:43 AM, Olen Stokes=20 >> >> wrote: >>> Are there applications vendors out there that already have specific=20 >>> requirements for what this " subset of the data-models for sub-interfac= es" >>> should be? >>> >>> Olen >>> >>> -----Original Message----- >>> From: irs-discuss-bounces@ietf.org >>> [mailto:irs-discuss-bounces@ietf.org] On Behalf Of Alia Atlas >>> Sent: Wednesday, August 15, 2012 9:08 AM >>> To: Shah, Himanshu >>> Cc: Gert Grammel; irs-discuss@ietf.org; Lenny Giuliano; Thomas=20 >>> Nadeau; Alia Atlas; Scott Whyte >>> Subject: Re: [irs-discuss] IRS comments >>> >>> Hi Himanshu, >>> >>> Welcome. I agree that IRS isn't going to spring into being fully >>> formed - I expect that we'll focus on a subset of the data-models=20 >>> for sub-interfaces along with an associated protocol (whether that=20 >>> is a new one or extending an existing one). >>> >>> Alia >>> >>> On Wed, Aug 15, 2012 at 7:41 AM, Shah, Himanshu wrote= : >>>> Newbie to this discussions list and have read only a last couple of=20 >>>> mails, so pardon the repeat if somebody has already raised the=20 >>>> following as a concern. >>>> >>>> I realize we are early in IRS architecture definition but one thing=20 >>>> to keep in mind is the user experience. >>>> We need to make sure that exposed interface to=20 >>>> RIB/LFIB/FIB/IGPs/BGP/LSDBs etc etc provide a consistent=20 >>>> predictive action/response/events even when different=20 >>>> implementations has varying capabilities. >>>> >>>> At the moment it seems like a wild wild west. >>>> Perhaps IRS can be defined in phases starting with a simpler,=20 >>>> limited version.. >>>> >>>> Thanks, >>>> himanshu >>>> >>>> >>>> -----Original Message----- >>>> From: irs-discuss-bounces@ietf.org >>>> [mailto:irs-discuss-bounces@ietf.org] On Behalf Of Alia Atlas >>>> Sent: Monday, August 13, 2012 8:41 AM >>>> To: Scott Whyte >>>> Cc: Thomas Nadeau; Gert Grammel; Alia Atlas; Lenny Giuliano;=20 >>>> irs-discuss@ietf.org >>>> Subject: Re: [irs-discuss] IRS comments >>>> >>>> ...snip... >>>> >>>> On Fri, Aug 10, 2012 at 9:03 PM, Scott Whyte wrote= : >>>>> On Fri, Aug 10, 2012 at 5:16 PM, Alia Atlas wrote= : >>>> >>>>>> I do think it is important to have the RIB as an arbitration mechani= sm >>>>>> on the device. Russ's suggestion that for the RIB sub-interface, t= he >>>>>> IRS agent might communicate logically to an IRS routing process=20 >>>>>> gives good semantics and interactions. Obviously,=20 >>>>>> implementations may differ. >>>>> >>>>> As long as the arbitration mechanism is reconfigurable by the=20 >>>>> operator to whatever precedence they want, I agree. Its not clear=20 >>>>> to me if various RIB implementations treat all proffered routes=20 >>>>> the same, nor if they store the same meta-data with all protocol sour= ces. >>>>> So there needs to be some way for the operator to leverage exposed=20 >>>>> protocol-specific optimizations, without conflict from the other=20 >>>>> routing processes, if they so desire. OTOH if it can all be done=20 >>>>> via static routes, it seems much simpler. :) >>>> >>>> Clearly the IRS sub-interface for the RIB needs to introduce/define=20 >>>> the different precedences; my assumption is that it would be per=20 >>>> route with a well-defined small set of meta-data. This is part of=20 >>>> where having good use-cases will help us understand what behavior=20 >>>> is necessary. The static routes do seem like a simpler case to start = with. >>>> >>>> Alia >>>> _______________________________________________ >>>> 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 >> _______________________________________________ >> 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 > > > > _______________________________________________ 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 Return-Path: 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 C861911E80E6 for ; Wed, 15 Aug 2012 19:56:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.564 X-Spam-Level: X-Spam-Status: No, score=-3.564 tagged_above=-999 required=5 tests=[AWL=0.035, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 owtxHrQPjgDM for ; Wed, 15 Aug 2012 19:56:46 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 606D411E80E5 for ; Wed, 15 Aug 2012 19:56:46 -0700 (PDT) Received: by vcbfo14 with SMTP id fo14so2370067vcb.31 for ; Wed, 15 Aug 2012 19:56:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=38XjsY4Wf5SHcvmxDGyO2uNrzrZ6Q3FbkbUlNktvgEc=; b=wMZWOWJm8MtTgzuzT089CCwBTNc7Z6XSHRnhkY1on3rnXyEHGS2/F3QSxNm0SUSgz7 n2dGAsb+wPRceoa7wZaTeCu5Y7m1eMyqQOb2WG+CD456uGCAm1OGeulA8BXexCQp6/Js qUigNtMvZZ6ZUAxqEseEs1Q6H6q6GhIJ28lkoolfJ6hKo1Z4wMPNvQ8F+x64lIEKu0yi E7SMDVtyBeWxyMxFRlvFupXXJnpc/IzDJt8h5hOaPlyJ9EaXQeJYan2dTX1NDYyr/DM0 74kZ0itgwsRWEjRHAt+jPPpv99KhpuG1mwlxDfkFpmPDMH4UkqDrNeF0mvPVWuRPgNBS k/7g== MIME-Version: 1.0 Received: by 10.58.151.197 with SMTP id us5mr15848645veb.14.1345085805628; Wed, 15 Aug 2012 19:56:45 -0700 (PDT) Received: by 10.220.49.204 with HTTP; Wed, 15 Aug 2012 19:56:45 -0700 (PDT) In-Reply-To: References: <812700A304640D4292205D5E83FC59E1061C211D@p-embx01-eq.jnpr.net> <3512BB31280C39448A9880F61DD54CEB09C07E@xmb-aln-x09.cisco.com> Date: Wed, 15 Aug 2012 22:56:45 -0400 Message-ID: From: Alia Atlas To: "Shah, Himanshu" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "UTTARO, JAMES" , "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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Aug 2012 02:56:47 -0000 What is the benefit of allowing access to the FIB vs. the associated comple= xity? If something wants to inject state directly into the forwarding plane, isn't that what ForCES or OpenFlow is for? Why get into low-level assembly when we've got a C-equiv? (Still not a higher level language that apps might speak with associated abstractions, but closer). Alia On Wed, Aug 15, 2012 at 10:01 PM, Shah, Himanshu wrote: > Yes I agree. I meant precedence value (pardon the use of wrong terminolog= y). > Each entity that injects route to routing table has an associated precede= nce value.. > > Anyway, I am more curious to know why not allow access to FIB.. > > /himanshu > > -----Original Message----- > From: UTTARO, JAMES [mailto:ju1738@att.com] > Sent: Wednesday, August 15, 2012 7:50 PM > To: Shah, Himanshu; Alia Atlas > Cc: irs-discuss@ietf.org > Subject: RE: [irs-discuss] IRS comments > > Inject routes yes, but I would not assume that implies that all state fro= m IRS is prioritized.. I think an important point to remember is that how I= RS interfaces with routing state learned via network protocols needs to be = part of this effort.. > > Jim Uttaro > > -----Original Message----- > From: irs-discuss-bounces@ietf.org [mailto:irs-discuss-bounces@ietf.org] = On Behalf Of Shah, Himanshu > Sent: Wednesday, August 15, 2012 6:57 PM > To: Alia Atlas > Cc: irs-discuss@ietf.org > Subject: Re: [irs-discuss] IRS comments > > OK - So that I am clear... > > IRS would provide interface to RIB such that routes can be injected with = priority and the local routing table manager on the node would then apply p= recedence rules, select the route, do ARP resolve (if ETH) and inject the p= refix with next-hop info into the FIB. > > The next step is then programming the FIB on the line card (if applicable= ). > > Would make sense for IRS to not provide interface to the FIB on the secon= d step. > But you are saying that it would also not provide interface to FIB of the= first step. > > Is that correct? > > /himanshu > > -----Original Message----- > From: Alia Atlas [mailto:akatlas@gmail.com] > Sent: Wednesday, August 15, 2012 6:05 PM > To: Shah, Himanshu > Cc: irs-discuss@ietf.org > Subject: Re: [irs-discuss] IRS comments > > I don't see IRS going below the RIB layer to FIB. > > Alia > > On Wed, Aug 15, 2012 at 2:21 PM, Shah, Himanshu wrote: >> I will let Ed clarify on what he means by "controller" . >> >> >> >> But here is my view of "application", "controller", "use-case" etc >> etc, >> >> >> >> When an XaaS processes a request it takes into consideration of >> availability of the CPU, memory, application data, cost of power, etc. >> to instantiate a VM on some host machine. >> >> One additional resource taken into consideration is the availability >> and/or requirement of the network connectivity between the resources >> >> such as VM, application data, requester, etc. >> >> >> >> The provider of XaaS thingy is the application server. >> >> (Centralized) Network "Controller(s)" knows current state of network >> infrastructure and (to be decided how much it) controls member network >> nodes using IRS. >> >> The "use case" here is to be able to dynamically create L2/L2.5/L3 >> connectivity with specific TE characteristics between the (perhaps >> geographically dispersed) resource points. >> >> >> >> In hierarchical fashion: Application server <- (application interface)= -> >> Network Controller <- (IRS) -> Network Node >> >> >> >> As we heard at IETF, IRS has tentacles in network nodes from BGP >> policies, all the way down to FIBs/LFIBs/ACL. >> >> >> >> So we need use cases for which applications would require >> accessibility to - >> >> BGP Policies >> >> RIB >> >> LSDB ( I saw an email which talks about reducing IGP to link >> distribution protocol and running SPF in centralized network >> controller) >> >> LIB >> >> FIB >> >> ACL (this is perhaps obvious) >> >> Etc etc >> >> >> >> I broad brushed and simplified a lot here to express my view - not >> sure if this jives with others. >> >> >> >> /Himanshu >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> From: irs-discuss-bounces@ietf.org >> [mailto:irs-discuss-bounces@ietf.org] On Behalf Of Olen Stokes >> Sent: Wednesday, August 15, 2012 1:30 PM >> To: Edward Crabbe; Alia Atlas >> Cc: David Lake (dlake); irs-discuss@ietf.org >> >> >> Subject: Re: [irs-discuss] IRS comments >> >> >> >> Thanks. Can you also give us what you mean by "controller". >> >> >> >> Olen >> >> >> >> From: Edward Crabbe [mailto:edc@google.com] >> Sent: Wednesday, August 15, 2012 1:24 PM >> To: Alia Atlas >> Cc: David Lake (dlake); Olen Stokes; irs-discuss@ietf.org >> Subject: Re: [irs-discuss] IRS comments >> >> >> >> s/wg/pre-BOF proto-wg :P/g >> >> On Wed, Aug 15, 2012 at 10:22 AM, Edward Crabbe wrote: >> >> +1 Alia. There's been a lot of confusion over this term. Having gone >> +a few >> rounds with folks on this one in other forums, I'll point out that >> what most people mean by application (myself included) is some set of >> control software (a scheduler, a path optimizer etc) that provides >> instructions to the controller, which are in turn translated to the appr= opriate PDUs. >> >> >> >> Having 'end user' applications request/make changes to forwarding >> state without an intermediate broker/aggregator acting on their behalf >> sounds like a recipe for disaster for operational networks, or, as is >> more likely, a quick hike to the protocol grave yard (followed by a >> long grave-side party >> :P) for the wg. >> >> >> >> my 2c. >> >> >> >> On Wed, Aug 15, 2012 at 8:48 AM, Alia Atlas wrote: >> >> Hi David, >> >> We do need to clarify what is meant by an application. I would not >> expect that real user-land applications would talk directly to routing >> devices via IRS. I can see that going through an intermediary. The >> IRS abstractions are unlikely to be as high-level as user-land >> applications would want and the security and policy issues would get >> exciting. >> >> Clarifying what applications are more in-scope initially is part of >> where use-cases will help. Can you write up ones to >> categorize/describe your thoughts? >> >> Alia >> >> >> On Wed, Aug 15, 2012 at 11:40 AM, David Lake (dlake) >> wrote: >>> As another newbie to this, I have some questions about "application >>> vendors." >>> >>> Who is the target audience here ? That will determine what functional= ity >>> and abstraction of the network we need to expose to that "application." >>> >>> This presently appears to be a little confused - at least in my mind. >>> The draft talks very much as if the application we are addressing is >>> an OSS/BSS system, essentially provisioning from the domain owner. >>> >>> However, linking this to the wider goals of SDN as voiced by >>> customers/users at the first Open Network Summit, there appears to be >>> a desire for cross-domain and user-land application integration. >>> >>> At this level - as an example giving a content cache the ability to >>> ensure delivery of an HD video to an end user - the application will >>> not be interested in the underlying topology of the network; it will >>> need to know that application X can be delivered with parameters Y betw= een reading from >>> the content store to delivery to the user's browser. How the stream >>> traverses the infrastructure is immaterial. >>> >>> Are we intending that IRS satisfies BOTH these requirements (i.e. for >>> ALL applications ?), or should we be more prescriptive about which >>> application space we are addressing ? >>> >>> Thanks >>> >>> David >>> >>> -----Original Message----- >>> From: irs-discuss-bounces@ietf.org >>> [mailto:irs-discuss-bounces@ietf.org] >>> On Behalf Of Alia Atlas >>> Sent: Wednesday, August 15, 2012 7:23 AM >>> To: Olen Stokes >>> Cc: irs-discuss@ietf.org >>> Subject: Re: [irs-discuss] IRS comments >>> >>> I have not specifically heard from application vendors about this. >>> My current plan is that we focus on a Use-Cases draft and define >>> within that some motivating use-cases that we agree are good first >>> targets. Those can drive which subset of functionality we focus on. >>> >>> More use-cases are, of course, quite welcome. Posting them to the >>> mailing list is a good first start. Russ White is starting the >>> general use-cases draft based on the three use-cases that he sent to th= e list. >>> >>> Alia >>> >>> On Wed, Aug 15, 2012 at 9:43 AM, Olen Stokes >>> >>> wrote: >>>> Are there applications vendors out there that already have specific >>>> requirements for what this " subset of the data-models for sub-interfa= ces" >>>> should be? >>>> >>>> Olen >>>> >>>> -----Original Message----- >>>> From: irs-discuss-bounces@ietf.org >>>> [mailto:irs-discuss-bounces@ietf.org] On Behalf Of Alia Atlas >>>> Sent: Wednesday, August 15, 2012 9:08 AM >>>> To: Shah, Himanshu >>>> Cc: Gert Grammel; irs-discuss@ietf.org; Lenny Giuliano; Thomas >>>> Nadeau; Alia Atlas; Scott Whyte >>>> Subject: Re: [irs-discuss] IRS comments >>>> >>>> Hi Himanshu, >>>> >>>> Welcome. I agree that IRS isn't going to spring into being fully >>>> formed - I expect that we'll focus on a subset of the data-models >>>> for sub-interfaces along with an associated protocol (whether that >>>> is a new one or extending an existing one). >>>> >>>> Alia >>>> >>>> On Wed, Aug 15, 2012 at 7:41 AM, Shah, Himanshu wrot= e: >>>>> Newbie to this discussions list and have read only a last couple of >>>>> mails, so pardon the repeat if somebody has already raised the >>>>> following as a concern. >>>>> >>>>> I realize we are early in IRS architecture definition but one thing >>>>> to keep in mind is the user experience. >>>>> We need to make sure that exposed interface to >>>>> RIB/LFIB/FIB/IGPs/BGP/LSDBs etc etc provide a consistent >>>>> predictive action/response/events even when different >>>>> implementations has varying capabilities. >>>>> >>>>> At the moment it seems like a wild wild west. >>>>> Perhaps IRS can be defined in phases starting with a simpler, >>>>> limited version.. >>>>> >>>>> Thanks, >>>>> himanshu >>>>> >>>>> >>>>> -----Original Message----- >>>>> From: irs-discuss-bounces@ietf.org >>>>> [mailto:irs-discuss-bounces@ietf.org] On Behalf Of Alia Atlas >>>>> Sent: Monday, August 13, 2012 8:41 AM >>>>> To: Scott Whyte >>>>> Cc: Thomas Nadeau; Gert Grammel; Alia Atlas; Lenny Giuliano; >>>>> irs-discuss@ietf.org >>>>> Subject: Re: [irs-discuss] IRS comments >>>>> >>>>> ...snip... >>>>> >>>>> On Fri, Aug 10, 2012 at 9:03 PM, Scott Whyte wrot= e: >>>>>> On Fri, Aug 10, 2012 at 5:16 PM, Alia Atlas wrot= e: >>>>> >>>>>>> I do think it is important to have the RIB as an arbitration mechan= ism >>>>>>> on the device. Russ's suggestion that for the RIB sub-interface, = the >>>>>>> IRS agent might communicate logically to an IRS routing process >>>>>>> gives good semantics and interactions. Obviously, >>>>>>> implementations may differ. >>>>>> >>>>>> As long as the arbitration mechanism is reconfigurable by the >>>>>> operator to whatever precedence they want, I agree. Its not clear >>>>>> to me if various RIB implementations treat all proffered routes >>>>>> the same, nor if they store the same meta-data with all protocol sou= rces. >>>>>> So there needs to be some way for the operator to leverage exposed >>>>>> protocol-specific optimizations, without conflict from the other >>>>>> routing processes, if they so desire. OTOH if it can all be done >>>>>> via static routes, it seems much simpler. :) >>>>> >>>>> Clearly the IRS sub-interface for the RIB needs to introduce/define >>>>> the different precedences; my assumption is that it would be per >>>>> route with a well-defined small set of meta-data. This is part of >>>>> where having good use-cases will help us understand what behavior >>>>> is necessary. The static routes do seem like a simpler case to start= with. >>>>> >>>>> Alia >>>>> _______________________________________________ >>>>> 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 >>> _______________________________________________ >>> 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 >> >> >> >> > _______________________________________________ > irs-discuss mailing list > irs-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/irs-discuss Return-Path: 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 5D68521F84FB for ; Wed, 15 Aug 2012 19:54:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.563 X-Spam-Level: X-Spam-Status: No, score=-3.563 tagged_above=-999 required=5 tests=[AWL=0.036, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 64cCiBZXWsV5 for ; Wed, 15 Aug 2012 19:54:57 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 098D421E8048 for ; Wed, 15 Aug 2012 19:54:56 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so2359170vbb.31 for ; Wed, 15 Aug 2012 19:54:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ae5OYcMLknCEjAXhh1oig5OVKdp7LNQrMr+W/lXsGE4=; b=ohlOtx8/ReA1NpHsaFT1d7+4GwuhMh06vXDoaOq0j3GdaahJH8UDJ80AjeBkUELX29 emQjbJE6kCyR9wN+/t+oZWBSz+B+0/mv/1LMD8xVNZIlik/d+l5quoohbHotVlkHFvKV otuwbfaaVAPRI35ZsMfMU6qqDKl9/aYVIRqqm0rFiBA6KrV4EdchiRxa7/55i4CEqPa3 MZMJYm4KS11zIWMqxTfA68UyRu08X/DNCTEo611SzlYUiNIcWxb+2EkhJegFsxVSHPbL pyQC0Uzt9mug+BqA4JycshKOD6FSmypovrkYmT7KXfNEtuCY3sP+aFlIuKMb768u3U7h Laiw== MIME-Version: 1.0 Received: by 10.58.102.83 with SMTP id fm19mr15788291veb.24.1345085696344; Wed, 15 Aug 2012 19:54:56 -0700 (PDT) Received: by 10.220.49.204 with HTTP; Wed, 15 Aug 2012 19:54:56 -0700 (PDT) In-Reply-To: References: <812700A304640D4292205D5E83FC59E1061C211D@p-embx01-eq.jnpr.net> <3512BB31280C39448A9880F61DD54CEB09C07E@xmb-aln-x09.cisco.com> Date: Wed, 15 Aug 2012 22:54:56 -0400 Message-ID: From: Alia Atlas To: "UTTARO, JAMES" Content-Type: text/plain; charset=ISO-8859-1 Cc: "Shah, Himanshu" , "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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Aug 2012 02:54:58 -0000 Definitely agree - an IRS client has specific authorization and scope for what it can do - and that includes what prioritization it can specify for its static routes and so on.. Alia On Wed, Aug 15, 2012 at 7:50 PM, UTTARO, JAMES wrote: > Inject routes yes, but I would not assume that implies that all state from IRS is prioritized.. I think an important point to remember is that how IRS interfaces with routing state learned via network protocols needs to be part of this effort.. > > Jim Uttaro > > -----Original Message----- > From: irs-discuss-bounces@ietf.org [mailto:irs-discuss-bounces@ietf.org] On Behalf Of Shah, Himanshu > Sent: Wednesday, August 15, 2012 6:57 PM > To: Alia Atlas > Cc: irs-discuss@ietf.org > Subject: Re: [irs-discuss] IRS comments > > OK - So that I am clear... > > IRS would provide interface to RIB such that routes can be injected with priority > and the local routing table manager on the node would then apply precedence rules, select the route, > do ARP resolve (if ETH) and inject the prefix with next-hop info into the FIB. > > The next step is then programming the FIB on the line card (if applicable). > > Would make sense for IRS to not provide interface to the FIB on the second step. > But you are saying that it would also not provide interface to FIB of the first step. > > Is that correct? > > /himanshu > > -----Original Message----- > From: Alia Atlas [mailto:akatlas@gmail.com] > Sent: Wednesday, August 15, 2012 6:05 PM > To: Shah, Himanshu > Cc: irs-discuss@ietf.org > Subject: Re: [irs-discuss] IRS comments > > I don't see IRS going below the RIB layer to FIB. > > Alia > > On Wed, Aug 15, 2012 at 2:21 PM, Shah, Himanshu wrote: >> I will let Ed clarify on what he means by "controller" . >> >> >> >> But here is my view of "application", "controller", "use-case" etc >> etc, >> >> >> >> When an XaaS processes a request it takes into consideration of >> availability of the CPU, memory, application data, cost of power, etc. >> to instantiate a VM on some host machine. >> >> One additional resource taken into consideration is the availability >> and/or requirement of the network connectivity between the resources >> >> such as VM, application data, requester, etc. >> >> >> >> The provider of XaaS thingy is the application server. >> >> (Centralized) Network "Controller(s)" knows current state of network >> infrastructure and (to be decided how much it) controls member network >> nodes using IRS. >> >> The "use case" here is to be able to dynamically create L2/L2.5/L3 >> connectivity with specific TE characteristics between the (perhaps >> geographically dispersed) resource points. >> >> >> >> In hierarchical fashion: Application server <- (application interface) -> >> Network Controller <- (IRS) -> Network Node >> >> >> >> As we heard at IETF, IRS has tentacles in network nodes from BGP >> policies, all the way down to FIBs/LFIBs/ACL. >> >> >> >> So we need use cases for which applications would require >> accessibility to - >> >> BGP Policies >> >> RIB >> >> LSDB ( I saw an email which talks about reducing IGP to link >> distribution protocol and running SPF in centralized network >> controller) >> >> LIB >> >> FIB >> >> ACL (this is perhaps obvious) >> >> Etc etc >> >> >> >> I broad brushed and simplified a lot here to express my view - not >> sure if this jives with others. >> >> >> >> /Himanshu >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> From: irs-discuss-bounces@ietf.org >> [mailto:irs-discuss-bounces@ietf.org] On Behalf Of Olen Stokes >> Sent: Wednesday, August 15, 2012 1:30 PM >> To: Edward Crabbe; Alia Atlas >> Cc: David Lake (dlake); irs-discuss@ietf.org >> >> >> Subject: Re: [irs-discuss] IRS comments >> >> >> >> Thanks. Can you also give us what you mean by "controller". >> >> >> >> Olen >> >> >> >> From: Edward Crabbe [mailto:edc@google.com] >> Sent: Wednesday, August 15, 2012 1:24 PM >> To: Alia Atlas >> Cc: David Lake (dlake); Olen Stokes; irs-discuss@ietf.org >> Subject: Re: [irs-discuss] IRS comments >> >> >> >> s/wg/pre-BOF proto-wg :P/g >> >> On Wed, Aug 15, 2012 at 10:22 AM, Edward Crabbe wrote: >> >> +1 Alia. There's been a lot of confusion over this term. Having gone >> +a few >> rounds with folks on this one in other forums, I'll point out that >> what most people mean by application (myself included) is some set of >> control software (a scheduler, a path optimizer etc) that provides >> instructions to the controller, which are in turn translated to the appropriate PDUs. >> >> >> >> Having 'end user' applications request/make changes to forwarding >> state without an intermediate broker/aggregator acting on their behalf >> sounds like a recipe for disaster for operational networks, or, as is >> more likely, a quick hike to the protocol grave yard (followed by a >> long grave-side party >> :P) for the wg. >> >> >> >> my 2c. >> >> >> >> On Wed, Aug 15, 2012 at 8:48 AM, Alia Atlas wrote: >> >> Hi David, >> >> We do need to clarify what is meant by an application. I would not >> expect that real user-land applications would talk directly to routing >> devices via IRS. I can see that going through an intermediary. The >> IRS abstractions are unlikely to be as high-level as user-land >> applications would want and the security and policy issues would get >> exciting. >> >> Clarifying what applications are more in-scope initially is part of >> where use-cases will help. Can you write up ones to >> categorize/describe your thoughts? >> >> Alia >> >> >> On Wed, Aug 15, 2012 at 11:40 AM, David Lake (dlake) >> wrote: >>> As another newbie to this, I have some questions about "application >>> vendors." >>> >>> Who is the target audience here ? That will determine what functionality >>> and abstraction of the network we need to expose to that "application." >>> >>> This presently appears to be a little confused - at least in my mind. >>> The draft talks very much as if the application we are addressing is >>> an OSS/BSS system, essentially provisioning from the domain owner. >>> >>> However, linking this to the wider goals of SDN as voiced by >>> customers/users at the first Open Network Summit, there appears to be >>> a desire for cross-domain and user-land application integration. >>> >>> At this level - as an example giving a content cache the ability to >>> ensure delivery of an HD video to an end user - the application will >>> not be interested in the underlying topology of the network; it will >>> need to know that application X can be delivered with parameters Y between reading from >>> the content store to delivery to the user's browser. How the stream >>> traverses the infrastructure is immaterial. >>> >>> Are we intending that IRS satisfies BOTH these requirements (i.e. for >>> ALL applications ?), or should we be more prescriptive about which >>> application space we are addressing ? >>> >>> Thanks >>> >>> David >>> >>> -----Original Message----- >>> From: irs-discuss-bounces@ietf.org >>> [mailto:irs-discuss-bounces@ietf.org] >>> On Behalf Of Alia Atlas >>> Sent: Wednesday, August 15, 2012 7:23 AM >>> To: Olen Stokes >>> Cc: irs-discuss@ietf.org >>> Subject: Re: [irs-discuss] IRS comments >>> >>> I have not specifically heard from application vendors about this. >>> My current plan is that we focus on a Use-Cases draft and define >>> within that some motivating use-cases that we agree are good first >>> targets. Those can drive which subset of functionality we focus on. >>> >>> More use-cases are, of course, quite welcome. Posting them to the >>> mailing list is a good first start. Russ White is starting the >>> general use-cases draft based on the three use-cases that he sent to the list. >>> >>> Alia >>> >>> On Wed, Aug 15, 2012 at 9:43 AM, Olen Stokes >>> >>> wrote: >>>> Are there applications vendors out there that already have specific >>>> requirements for what this " subset of the data-models for sub-interfaces" >>>> should be? >>>> >>>> Olen >>>> >>>> -----Original Message----- >>>> From: irs-discuss-bounces@ietf.org >>>> [mailto:irs-discuss-bounces@ietf.org] On Behalf Of Alia Atlas >>>> Sent: Wednesday, August 15, 2012 9:08 AM >>>> To: Shah, Himanshu >>>> Cc: Gert Grammel; irs-discuss@ietf.org; Lenny Giuliano; Thomas >>>> Nadeau; Alia Atlas; Scott Whyte >>>> Subject: Re: [irs-discuss] IRS comments >>>> >>>> Hi Himanshu, >>>> >>>> Welcome. I agree that IRS isn't going to spring into being fully >>>> formed - I expect that we'll focus on a subset of the data-models >>>> for sub-interfaces along with an associated protocol (whether that >>>> is a new one or extending an existing one). >>>> >>>> Alia >>>> >>>> On Wed, Aug 15, 2012 at 7:41 AM, Shah, Himanshu wrote: >>>>> Newbie to this discussions list and have read only a last couple of >>>>> mails, so pardon the repeat if somebody has already raised the >>>>> following as a concern. >>>>> >>>>> I realize we are early in IRS architecture definition but one thing >>>>> to keep in mind is the user experience. >>>>> We need to make sure that exposed interface to >>>>> RIB/LFIB/FIB/IGPs/BGP/LSDBs etc etc provide a consistent >>>>> predictive action/response/events even when different >>>>> implementations has varying capabilities. >>>>> >>>>> At the moment it seems like a wild wild west. >>>>> Perhaps IRS can be defined in phases starting with a simpler, >>>>> limited version.. >>>>> >>>>> Thanks, >>>>> himanshu >>>>> >>>>> >>>>> -----Original Message----- >>>>> From: irs-discuss-bounces@ietf.org >>>>> [mailto:irs-discuss-bounces@ietf.org] On Behalf Of Alia Atlas >>>>> Sent: Monday, August 13, 2012 8:41 AM >>>>> To: Scott Whyte >>>>> Cc: Thomas Nadeau; Gert Grammel; Alia Atlas; Lenny Giuliano; >>>>> irs-discuss@ietf.org >>>>> Subject: Re: [irs-discuss] IRS comments >>>>> >>>>> ...snip... >>>>> >>>>> On Fri, Aug 10, 2012 at 9:03 PM, Scott Whyte wrote: >>>>>> On Fri, Aug 10, 2012 at 5:16 PM, Alia Atlas wrote: >>>>> >>>>>>> I do think it is important to have the RIB as an arbitration mechanism >>>>>>> on the device. Russ's suggestion that for the RIB sub-interface, the >>>>>>> IRS agent might communicate logically to an IRS routing process >>>>>>> gives good semantics and interactions. Obviously, >>>>>>> implementations may differ. >>>>>> >>>>>> As long as the arbitration mechanism is reconfigurable by the >>>>>> operator to whatever precedence they want, I agree. Its not clear >>>>>> to me if various RIB implementations treat all proffered routes >>>>>> the same, nor if they store the same meta-data with all protocol sources. >>>>>> So there needs to be some way for the operator to leverage exposed >>>>>> protocol-specific optimizations, without conflict from the other >>>>>> routing processes, if they so desire. OTOH if it can all be done >>>>>> via static routes, it seems much simpler. :) >>>>> >>>>> Clearly the IRS sub-interface for the RIB needs to introduce/define >>>>> the different precedences; my assumption is that it would be per >>>>> route with a well-defined small set of meta-data. This is part of >>>>> where having good use-cases will help us understand what behavior >>>>> is necessary. The static routes do seem like a simpler case to start with. >>>>> >>>>> Alia >>>>> _______________________________________________ >>>>> 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 >>> _______________________________________________ >>> 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 >> >> >> >> > _______________________________________________ > irs-discuss mailing list > irs-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/irs-discuss Return-Path: 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 29FE021E8048 for ; Wed, 15 Aug 2012 19:53:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.562 X-Spam-Level: X-Spam-Status: No, score=-3.562 tagged_above=-999 required=5 tests=[AWL=0.037, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 jsovWnBSw1jn for ; Wed, 15 Aug 2012 19:53:32 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 813C211E80E4 for ; Wed, 15 Aug 2012 19:53:32 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so2358545vbb.31 for ; Wed, 15 Aug 2012 19:53:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=B2G3zCelt0GOaLlsAEPV5AAWTpDwapvWbbWZOS2x2rw=; b=0jBTNtzrT6mntGHHvNlqbs9H+0UfT7OmB6fxeKKoxjeMsA/FpJzsOy8LVi+V37r6m5 vqtUOquz1h5BDRSWgAnjpYV/UOdr+XX7ordlWp+AX9sxrUJqMkdwZbyb64FTDCKQoD/a OFVTOpbNQkoRnsaNtyifIqGHAhTIAWSioMPdU57DegtRlIPjZKQc77pXmDNvk6ryPKxb dbSg2+aaxkCu86yVsv6TcRSfr8ChwuxyDeDXlJNmR/KMWA90oHe7vjnUoziPUjWluOjq uYdWSkoqkY5FReuT1Rg8URIbqbERAS9ikuV9X0gAxSrb3Iy8AcYIunix8Um4wGFdaqWB ZwRA== MIME-Version: 1.0 Received: by 10.221.2.8 with SMTP id ns8mr8840814vcb.0.1345085611835; Wed, 15 Aug 2012 19:53:31 -0700 (PDT) Received: by 10.220.49.204 with HTTP; Wed, 15 Aug 2012 19:53:31 -0700 (PDT) In-Reply-To: <1D30AF33624CDD4A99E8C395069A2A161FE11D7F@dfweml513-mbs.china.huawei.com> References: <812700A304640D4292205D5E83FC59E1061C211D@p-embx01-eq.jnpr.net> <3512BB31280C39448A9880F61DD54CEB09C07E@xmb-aln-x09.cisco.com> <502BFD81.4070809@raszuk.net> <1D30AF33624CDD4A99E8C395069A2A161FE11D7F@dfweml513-mbs.china.huawei.com> Date: Wed, 15 Aug 2012 22:53:31 -0400 Message-ID: From: Alia Atlas To: Lin Han Content-Type: text/plain; charset=ISO-8859-1 Cc: Olen Stokes , Edward Crabbe , "David Lake \(dlake\)" , "robert@raszuk.net" , "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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Aug 2012 02:53:33 -0000 Good questions. On Wed, Aug 15, 2012 at 9:56 PM, Lin Han wrote: > Will IRS provide a channel for data such as data packet punt and injection? As you said inject OAM into the created LSP. Given that an IRS agent can inject a static route or a policy-based route, it is easy to specify an appropriate next-hop/tunnel to direct packets to an appropriate location. I do think that the ability to inject packets would be useful - though I have concerns about scale for that - and it is somewhat arguable as to whether it fits under the "routing system". > Also, what is the good means of learning more topology and dynamic events and related state easily? Do you have any rough idea? I thought PCE has learnt all from the running protocol since it is part of the topo. IRS is the means :-) We're working on defining that based on the requirements. Alia > Lin > > -----Original Message----- > From: irs-discuss-bounces@ietf.org [mailto:irs-discuss-bounces@ietf.org] On Behalf Of Alia Atlas > Sent: Wednesday, August 15, 2012 3:12 PM > To: robert@raszuk.net > Cc: Olen Stokes; Edward Crabbe; David Lake (dlake); irs-discuss@ietf.org > Subject: Re: [irs-discuss] IRS comments > > On Wed, Aug 15, 2012 at 3:50 PM, Robert Raszuk wrote: >> >>> It could just as easily describe a PCE. >> >> >> PCE could be a controller just talking to headends and asking them to signal >> LSP X with RSVP-TE or it could talk to all head, tail and via nodes and >> actually program the forwarding label entries. >> >> I am observing that IRS framework is more of the former case rather then the >> latter in general. >> >> However if this is the former then I am a bit not clear what value it is to >> deliver if we compare it with current statefull PCE efforts ;) > > Other than providing a good means of learning more topology and > dynamic events and related state easily?? Feedback loops - and an > easy mechanism to, for instance, test a created LSP via OAM before > declaring the new one up? > > Alia > >> Best, >> R. >> >> >> >> > _______________________________________________ > irs-discuss mailing list > irs-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/irs-discuss Return-Path: 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 13B0A21E8048 for ; Wed, 15 Aug 2012 19:47:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.562 X-Spam-Level: X-Spam-Status: No, score=-3.562 tagged_above=-999 required=5 tests=[AWL=0.037, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 EGBl4gGPMKbS for ; Wed, 15 Aug 2012 19:47:48 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id A3D7911E80E1 for ; Wed, 15 Aug 2012 19:47:48 -0700 (PDT) Received: by vcbfo14 with SMTP id fo14so2365800vcb.31 for ; Wed, 15 Aug 2012 19:47:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=OfayiH3cGf6gJb7yfeJRx+nO5R+PifhbAhhDtGNsyXE=; b=NCu7tTKcBHZimRtUO3DsTEgwZSkeDqreDFV5stQGJE+yCTsI2yjTLV5zw+zHxT6it7 mho5t4IfJSFnevS4hQkiMHlch/7DJ5F8j/XFYkEhnSzStF+BBogbomgRLRKWaZ8J2rue pekDssgh6NbGv6cSf0RGZlF38PjfpKwWrrKOjJJKv8xdSFHuRaXz6FELxHz2ljrReXQD kKIovezs2k8hGWhmZS4oiAM0dFsJNrW8A3rX+mpooz2yzl1ZJ2EDGjY4S9YEDdUDUDRg xh8GujpdY5MYT7XKtbzLBEs4pt8BHJMdSoY8l01000KoFAAHzuC0fIOLGxbPf3hKu09F RofA== MIME-Version: 1.0 Received: by 10.58.151.197 with SMTP id us5mr15836764veb.14.1345085268093; Wed, 15 Aug 2012 19:47:48 -0700 (PDT) Received: by 10.220.49.204 with HTTP; Wed, 15 Aug 2012 19:47:47 -0700 (PDT) In-Reply-To: References: <812700A304640D4292205D5E83FC59E1061C211D@p-embx01-eq.jnpr.net> <3512BB31280C39448A9880F61DD54CEB09C07E@xmb-aln-x09.cisco.com> Date: Wed, 15 Aug 2012 22:47:47 -0400 Message-ID: From: Alia Atlas To: "Shah, Himanshu" Content-Type: text/plain; charset=ISO-8859-1 Cc: "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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Aug 2012 02:47:50 -0000 Yes, that's my current opinion. Given that IRS can provide the desired priority for the route within its constraints, and given that there can be multiple IRS clients trying to specify routes, there's a need for a local routing table manager to apply precedence regardless. Alia On Wed, Aug 15, 2012 at 6:57 PM, Shah, Himanshu wrote: > OK - So that I am clear... > > IRS would provide interface to RIB such that routes can be injected with priority > and the local routing table manager on the node would then apply precedence rules, select the route, > do ARP resolve (if ETH) and inject the prefix with next-hop info into the FIB. > > The next step is then programming the FIB on the line card (if applicable). > > Would make sense for IRS to not provide interface to the FIB on the second step. > But you are saying that it would also not provide interface to FIB of the first step. > > Is that correct? > > /himanshu > > -----Original Message----- > From: Alia Atlas [mailto:akatlas@gmail.com] > Sent: Wednesday, August 15, 2012 6:05 PM > To: Shah, Himanshu > Cc: irs-discuss@ietf.org > Subject: Re: [irs-discuss] IRS comments > > I don't see IRS going below the RIB layer to FIB. > > Alia > > On Wed, Aug 15, 2012 at 2:21 PM, Shah, Himanshu wrote: >> I will let Ed clarify on what he means by "controller" . >> >> >> >> But here is my view of "application", "controller", "use-case" etc >> etc, >> >> >> >> When an XaaS processes a request it takes into consideration of >> availability of the CPU, memory, application data, cost of power, etc. >> to instantiate a VM on some host machine. >> >> One additional resource taken into consideration is the availability >> and/or requirement of the network connectivity between the resources >> >> such as VM, application data, requester, etc. >> >> >> >> The provider of XaaS thingy is the application server. >> >> (Centralized) Network "Controller(s)" knows current state of network >> infrastructure and (to be decided how much it) controls member network >> nodes using IRS. >> >> The "use case" here is to be able to dynamically create L2/L2.5/L3 >> connectivity with specific TE characteristics between the (perhaps >> geographically dispersed) resource points. >> >> >> >> In hierarchical fashion: Application server <- (application interface) -> >> Network Controller <- (IRS) -> Network Node >> >> >> >> As we heard at IETF, IRS has tentacles in network nodes from BGP >> policies, all the way down to FIBs/LFIBs/ACL. >> >> >> >> So we need use cases for which applications would require >> accessibility to - >> >> BGP Policies >> >> RIB >> >> LSDB ( I saw an email which talks about reducing IGP to link >> distribution protocol and running SPF in centralized network >> controller) >> >> LIB >> >> FIB >> >> ACL (this is perhaps obvious) >> >> Etc etc >> >> >> >> I broad brushed and simplified a lot here to express my view - not >> sure if this jives with others. >> >> >> >> /Himanshu >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> From: irs-discuss-bounces@ietf.org >> [mailto:irs-discuss-bounces@ietf.org] On Behalf Of Olen Stokes >> Sent: Wednesday, August 15, 2012 1:30 PM >> To: Edward Crabbe; Alia Atlas >> Cc: David Lake (dlake); irs-discuss@ietf.org >> >> >> Subject: Re: [irs-discuss] IRS comments >> >> >> >> Thanks. Can you also give us what you mean by "controller". >> >> >> >> Olen >> >> >> >> From: Edward Crabbe [mailto:edc@google.com] >> Sent: Wednesday, August 15, 2012 1:24 PM >> To: Alia Atlas >> Cc: David Lake (dlake); Olen Stokes; irs-discuss@ietf.org >> Subject: Re: [irs-discuss] IRS comments >> >> >> >> s/wg/pre-BOF proto-wg :P/g >> >> On Wed, Aug 15, 2012 at 10:22 AM, Edward Crabbe wrote: >> >> +1 Alia. There's been a lot of confusion over this term. Having gone >> +a few >> rounds with folks on this one in other forums, I'll point out that >> what most people mean by application (myself included) is some set of >> control software (a scheduler, a path optimizer etc) that provides >> instructions to the controller, which are in turn translated to the appropriate PDUs. >> >> >> >> Having 'end user' applications request/make changes to forwarding >> state without an intermediate broker/aggregator acting on their behalf >> sounds like a recipe for disaster for operational networks, or, as is >> more likely, a quick hike to the protocol grave yard (followed by a >> long grave-side party >> :P) for the wg. >> >> >> >> my 2c. >> >> >> >> On Wed, Aug 15, 2012 at 8:48 AM, Alia Atlas wrote: >> >> Hi David, >> >> We do need to clarify what is meant by an application. I would not >> expect that real user-land applications would talk directly to routing >> devices via IRS. I can see that going through an intermediary. The >> IRS abstractions are unlikely to be as high-level as user-land >> applications would want and the security and policy issues would get >> exciting. >> >> Clarifying what applications are more in-scope initially is part of >> where use-cases will help. Can you write up ones to >> categorize/describe your thoughts? >> >> Alia >> >> >> On Wed, Aug 15, 2012 at 11:40 AM, David Lake (dlake) >> wrote: >>> As another newbie to this, I have some questions about "application >>> vendors." >>> >>> Who is the target audience here ? That will determine what functionality >>> and abstraction of the network we need to expose to that "application." >>> >>> This presently appears to be a little confused - at least in my mind. >>> The draft talks very much as if the application we are addressing is >>> an OSS/BSS system, essentially provisioning from the domain owner. >>> >>> However, linking this to the wider goals of SDN as voiced by >>> customers/users at the first Open Network Summit, there appears to be >>> a desire for cross-domain and user-land application integration. >>> >>> At this level - as an example giving a content cache the ability to >>> ensure delivery of an HD video to an end user - the application will >>> not be interested in the underlying topology of the network; it will >>> need to know that application X can be delivered with parameters Y between reading from >>> the content store to delivery to the user's browser. How the stream >>> traverses the infrastructure is immaterial. >>> >>> Are we intending that IRS satisfies BOTH these requirements (i.e. for >>> ALL applications ?), or should we be more prescriptive about which >>> application space we are addressing ? >>> >>> Thanks >>> >>> David >>> >>> -----Original Message----- >>> From: irs-discuss-bounces@ietf.org >>> [mailto:irs-discuss-bounces@ietf.org] >>> On Behalf Of Alia Atlas >>> Sent: Wednesday, August 15, 2012 7:23 AM >>> To: Olen Stokes >>> Cc: irs-discuss@ietf.org >>> Subject: Re: [irs-discuss] IRS comments >>> >>> I have not specifically heard from application vendors about this. >>> My current plan is that we focus on a Use-Cases draft and define >>> within that some motivating use-cases that we agree are good first >>> targets. Those can drive which subset of functionality we focus on. >>> >>> More use-cases are, of course, quite welcome. Posting them to the >>> mailing list is a good first start. Russ White is starting the >>> general use-cases draft based on the three use-cases that he sent to the list. >>> >>> Alia >>> >>> On Wed, Aug 15, 2012 at 9:43 AM, Olen Stokes >>> >>> wrote: >>>> Are there applications vendors out there that already have specific >>>> requirements for what this " subset of the data-models for sub-interfaces" >>>> should be? >>>> >>>> Olen >>>> >>>> -----Original Message----- >>>> From: irs-discuss-bounces@ietf.org >>>> [mailto:irs-discuss-bounces@ietf.org] On Behalf Of Alia Atlas >>>> Sent: Wednesday, August 15, 2012 9:08 AM >>>> To: Shah, Himanshu >>>> Cc: Gert Grammel; irs-discuss@ietf.org; Lenny Giuliano; Thomas >>>> Nadeau; Alia Atlas; Scott Whyte >>>> Subject: Re: [irs-discuss] IRS comments >>>> >>>> Hi Himanshu, >>>> >>>> Welcome. I agree that IRS isn't going to spring into being fully >>>> formed - I expect that we'll focus on a subset of the data-models >>>> for sub-interfaces along with an associated protocol (whether that >>>> is a new one or extending an existing one). >>>> >>>> Alia >>>> >>>> On Wed, Aug 15, 2012 at 7:41 AM, Shah, Himanshu wrote: >>>>> Newbie to this discussions list and have read only a last couple of >>>>> mails, so pardon the repeat if somebody has already raised the >>>>> following as a concern. >>>>> >>>>> I realize we are early in IRS architecture definition but one thing >>>>> to keep in mind is the user experience. >>>>> We need to make sure that exposed interface to >>>>> RIB/LFIB/FIB/IGPs/BGP/LSDBs etc etc provide a consistent >>>>> predictive action/response/events even when different >>>>> implementations has varying capabilities. >>>>> >>>>> At the moment it seems like a wild wild west. >>>>> Perhaps IRS can be defined in phases starting with a simpler, >>>>> limited version.. >>>>> >>>>> Thanks, >>>>> himanshu >>>>> >>>>> >>>>> -----Original Message----- >>>>> From: irs-discuss-bounces@ietf.org >>>>> [mailto:irs-discuss-bounces@ietf.org] On Behalf Of Alia Atlas >>>>> Sent: Monday, August 13, 2012 8:41 AM >>>>> To: Scott Whyte >>>>> Cc: Thomas Nadeau; Gert Grammel; Alia Atlas; Lenny Giuliano; >>>>> irs-discuss@ietf.org >>>>> Subject: Re: [irs-discuss] IRS comments >>>>> >>>>> ...snip... >>>>> >>>>> On Fri, Aug 10, 2012 at 9:03 PM, Scott Whyte wrote: >>>>>> On Fri, Aug 10, 2012 at 5:16 PM, Alia Atlas wrote: >>>>> >>>>>>> I do think it is important to have the RIB as an arbitration mechanism >>>>>>> on the device. Russ's suggestion that for the RIB sub-interface, the >>>>>>> IRS agent might communicate logically to an IRS routing process >>>>>>> gives good semantics and interactions. Obviously, >>>>>>> implementations may differ. >>>>>> >>>>>> As long as the arbitration mechanism is reconfigurable by the >>>>>> operator to whatever precedence they want, I agree. Its not clear >>>>>> to me if various RIB implementations treat all proffered routes >>>>>> the same, nor if they store the same meta-data with all protocol sources. >>>>>> So there needs to be some way for the operator to leverage exposed >>>>>> protocol-specific optimizations, without conflict from the other >>>>>> routing processes, if they so desire. OTOH if it can all be done >>>>>> via static routes, it seems much simpler. :) >>>>> >>>>> Clearly the IRS sub-interface for the RIB needs to introduce/define >>>>> the different precedences; my assumption is that it would be per >>>>> route with a well-defined small set of meta-data. This is part of >>>>> where having good use-cases will help us understand what behavior >>>>> is necessary. The static routes do seem like a simpler case to start with. >>>>> >>>>> Alia >>>>> _______________________________________________ >>>>> 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 >>> _______________________________________________ >>> 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 >> >> >> >> Return-Path: 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 E906921E8041 for ; Wed, 15 Aug 2012 19:01:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.092 X-Spam-Level: X-Spam-Status: No, score=-3.092 tagged_above=-999 required=5 tests=[AWL=0.173, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-1] 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 gU38Nv6NytyN for ; Wed, 15 Aug 2012 19:01:56 -0700 (PDT) Received: from mx0b-00103a01.pphosted.com (mx0b-00103a01.pphosted.com [67.231.152.227]) by ietfa.amsl.com (Postfix) with ESMTP id 7D30611E809B for ; Wed, 15 Aug 2012 19:01:56 -0700 (PDT) Received: from pps.filterd (m0001124 [127.0.0.1]) by mx0b-00103a01.pphosted.com (8.14.4/8.14.4) with SMTP id q7G2171A026554; Wed, 15 Aug 2012 22:01:54 -0400 Received: from mdwexght01.ciena.com (LIN1-118-36-28.ciena.com [63.118.36.28]) by mx0b-00103a01.pphosted.com with ESMTP id 16rndw88c1-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 15 Aug 2012 22:01:53 -0400 Received: from MDWEXGMB02.ciena.com ([::1]) by MDWEXGHT01.ciena.com ([::1]) with mapi; Wed, 15 Aug 2012 22:01:55 -0400 From: "Shah, Himanshu" To: "UTTARO, JAMES" , Alia Atlas Date: Wed, 15 Aug 2012 22:01:53 -0400 Thread-Topic: [irs-discuss] IRS comments Thread-Index: Ac15UPmWZFj3YBmsT9Smjrge48ksHAATypTAAFoVXoAAAUAUgAABZOIAAAKyOQAAAEVwAAADS7QAAAAO5wAAADV/gAAByQUAAAfLkAAAAdXVgAAGmN5wAAiugSA= Message-ID: References: <812700A304640D4292205D5E83FC59E1061C211D@p-embx01-eq.jnpr.net> <3512BB31280C39448A9880F61DD54CEB09C07E@xmb-aln-x09.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-tm-as-product-ver: SMEX-10.0.0.1412-7.000.1014-19116.000 x-tm-as-result: No--48.915700-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.7.7855, 1.0.260, 0.0.0000 definitions=2012-08-15_05:2012-08-15, 2012-08-15, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=1 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=6.0.2-1203120001 definitions=main-1208150329 Cc: "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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Aug 2012 02:01:58 -0000 Yes I agree. I meant precedence value (pardon the use of wrong terminology)= .=20 Each entity that injects route to routing table has an associated precedenc= e value.. Anyway, I am more curious to know why not allow access to FIB.. /himanshu -----Original Message----- From: UTTARO, JAMES [mailto:ju1738@att.com]=20 Sent: Wednesday, August 15, 2012 7:50 PM To: Shah, Himanshu; Alia Atlas Cc: irs-discuss@ietf.org Subject: RE: [irs-discuss] IRS comments Inject routes yes, but I would not assume that implies that all state from = IRS is prioritized.. I think an important point to remember is that how IRS= interfaces with routing state learned via network protocols needs to be pa= rt of this effort.. Jim Uttaro -----Original Message----- From: irs-discuss-bounces@ietf.org [mailto:irs-discuss-bounces@ietf.org] On= Behalf Of Shah, Himanshu Sent: Wednesday, August 15, 2012 6:57 PM To: Alia Atlas Cc: irs-discuss@ietf.org Subject: Re: [irs-discuss] IRS comments OK - So that I am clear... IRS would provide interface to RIB such that routes can be injected with pr= iority and the local routing table manager on the node would then apply pre= cedence rules, select the route, do ARP resolve (if ETH) and inject the pre= fix with next-hop info into the FIB. The next step is then programming the FIB on the line card (if applicable). Would make sense for IRS to not provide interface to the FIB on the second = step. But you are saying that it would also not provide interface to FIB of the f= irst step.=20 Is that correct? /himanshu -----Original Message----- From: Alia Atlas [mailto:akatlas@gmail.com] Sent: Wednesday, August 15, 2012 6:05 PM To: Shah, Himanshu Cc: irs-discuss@ietf.org Subject: Re: [irs-discuss] IRS comments I don't see IRS going below the RIB layer to FIB. Alia On Wed, Aug 15, 2012 at 2:21 PM, Shah, Himanshu wrote: > I will let Ed clarify on what he means by "controller" . > > > > But here is my view of "application", "controller", "use-case" etc=20 > etc, > > > > When an XaaS processes a request it takes into consideration of=20 > availability of the CPU, memory, application data, cost of power, etc. > to instantiate a VM on some host machine. > > One additional resource taken into consideration is the availability=20 > and/or requirement of the network connectivity between the resources > > such as VM, application data, requester, etc. > > > > The provider of XaaS thingy is the application server. > > (Centralized) Network "Controller(s)" knows current state of network=20 > infrastructure and (to be decided how much it) controls member network=20 > nodes using IRS. > > The "use case" here is to be able to dynamically create L2/L2.5/L3=20 > connectivity with specific TE characteristics between the (perhaps=20 > geographically dispersed) resource points. > > > > In hierarchical fashion: Application server <- (application interface) = -> > Network Controller <- (IRS) -> Network Node > > > > As we heard at IETF, IRS has tentacles in network nodes from BGP=20 > policies, all the way down to FIBs/LFIBs/ACL. > > > > So we need use cases for which applications would require=20 > accessibility to - > > BGP Policies > > RIB > > LSDB ( I saw an email which talks about reducing IGP to link=20 > distribution protocol and running SPF in centralized network > controller) > > LIB > > FIB > > ACL (this is perhaps obvious) > > Etc etc > > > > I broad brushed and simplified a lot here to express my view - not=20 > sure if this jives with others. > > > > /Himanshu > > > > > > > > > > > > > > > > > > From: irs-discuss-bounces@ietf.org > [mailto:irs-discuss-bounces@ietf.org] On Behalf Of Olen Stokes > Sent: Wednesday, August 15, 2012 1:30 PM > To: Edward Crabbe; Alia Atlas > Cc: David Lake (dlake); irs-discuss@ietf.org > > > Subject: Re: [irs-discuss] IRS comments > > > > Thanks. Can you also give us what you mean by "controller". > > > > Olen > > > > From: Edward Crabbe [mailto:edc@google.com] > Sent: Wednesday, August 15, 2012 1:24 PM > To: Alia Atlas > Cc: David Lake (dlake); Olen Stokes; irs-discuss@ietf.org > Subject: Re: [irs-discuss] IRS comments > > > > s/wg/pre-BOF proto-wg :P/g > > On Wed, Aug 15, 2012 at 10:22 AM, Edward Crabbe wrote: > > +1 Alia. There's been a lot of confusion over this term. Having gone=20 > +a few > rounds with folks on this one in other forums, I'll point out that=20 > what most people mean by application (myself included) is some set of=20 > control software (a scheduler, a path optimizer etc) that provides=20 > instructions to the controller, which are in turn translated to the appro= priate PDUs. > > > > Having 'end user' applications request/make changes to forwarding=20 > state without an intermediate broker/aggregator acting on their behalf=20 > sounds like a recipe for disaster for operational networks, or, as is=20 > more likely, a quick hike to the protocol grave yard (followed by a=20 > long grave-side party > :P) for the wg. > > > > my 2c. > > > > On Wed, Aug 15, 2012 at 8:48 AM, Alia Atlas wrote: > > Hi David, > > We do need to clarify what is meant by an application. I would not=20 > expect that real user-land applications would talk directly to routing=20 > devices via IRS. I can see that going through an intermediary. The=20 > IRS abstractions are unlikely to be as high-level as user-land=20 > applications would want and the security and policy issues would get=20 > exciting. > > Clarifying what applications are more in-scope initially is part of=20 > where use-cases will help. Can you write up ones to=20 > categorize/describe your thoughts? > > Alia > > > On Wed, Aug 15, 2012 at 11:40 AM, David Lake (dlake) > wrote: >> As another newbie to this, I have some questions about "application=20 >> vendors." >> >> Who is the target audience here ? That will determine what functionali= ty >> and abstraction of the network we need to expose to that "application." >> >> This presently appears to be a little confused - at least in my mind. =20 >> The draft talks very much as if the application we are addressing is=20 >> an OSS/BSS system, essentially provisioning from the domain owner. >> >> However, linking this to the wider goals of SDN as voiced by=20 >> customers/users at the first Open Network Summit, there appears to be=20 >> a desire for cross-domain and user-land application integration. >> >> At this level - as an example giving a content cache the ability to=20 >> ensure delivery of an HD video to an end user - the application will=20 >> not be interested in the underlying topology of the network; it will=20 >> need to know that application X can be delivered with parameters Y betwe= en reading from >> the content store to delivery to the user's browser. How the stream >> traverses the infrastructure is immaterial. >> >> Are we intending that IRS satisfies BOTH these requirements (i.e. for=20 >> ALL applications ?), or should we be more prescriptive about which=20 >> application space we are addressing ? >> >> Thanks >> >> David >> >> -----Original Message----- >> From: irs-discuss-bounces@ietf.org >> [mailto:irs-discuss-bounces@ietf.org] >> On Behalf Of Alia Atlas >> Sent: Wednesday, August 15, 2012 7:23 AM >> To: Olen Stokes >> Cc: irs-discuss@ietf.org >> Subject: Re: [irs-discuss] IRS comments >> >> I have not specifically heard from application vendors about this. >> My current plan is that we focus on a Use-Cases draft and define=20 >> within that some motivating use-cases that we agree are good first=20 >> targets. Those can drive which subset of functionality we focus on. >> >> More use-cases are, of course, quite welcome. Posting them to the=20 >> mailing list is a good first start. Russ White is starting the=20 >> general use-cases draft based on the three use-cases that he sent to the= list. >> >> Alia >> >> On Wed, Aug 15, 2012 at 9:43 AM, Olen Stokes=20 >> >> wrote: >>> Are there applications vendors out there that already have specific=20 >>> requirements for what this " subset of the data-models for sub-interfac= es" >>> should be? >>> >>> Olen >>> >>> -----Original Message----- >>> From: irs-discuss-bounces@ietf.org >>> [mailto:irs-discuss-bounces@ietf.org] On Behalf Of Alia Atlas >>> Sent: Wednesday, August 15, 2012 9:08 AM >>> To: Shah, Himanshu >>> Cc: Gert Grammel; irs-discuss@ietf.org; Lenny Giuliano; Thomas=20 >>> Nadeau; Alia Atlas; Scott Whyte >>> Subject: Re: [irs-discuss] IRS comments >>> >>> Hi Himanshu, >>> >>> Welcome. I agree that IRS isn't going to spring into being fully >>> formed - I expect that we'll focus on a subset of the data-models=20 >>> for sub-interfaces along with an associated protocol (whether that=20 >>> is a new one or extending an existing one). >>> >>> Alia >>> >>> On Wed, Aug 15, 2012 at 7:41 AM, Shah, Himanshu wrote= : >>>> Newbie to this discussions list and have read only a last couple of=20 >>>> mails, so pardon the repeat if somebody has already raised the=20 >>>> following as a concern. >>>> >>>> I realize we are early in IRS architecture definition but one thing=20 >>>> to keep in mind is the user experience. >>>> We need to make sure that exposed interface to=20 >>>> RIB/LFIB/FIB/IGPs/BGP/LSDBs etc etc provide a consistent=20 >>>> predictive action/response/events even when different=20 >>>> implementations has varying capabilities. >>>> >>>> At the moment it seems like a wild wild west. >>>> Perhaps IRS can be defined in phases starting with a simpler,=20 >>>> limited version.. >>>> >>>> Thanks, >>>> himanshu >>>> >>>> >>>> -----Original Message----- >>>> From: irs-discuss-bounces@ietf.org >>>> [mailto:irs-discuss-bounces@ietf.org] On Behalf Of Alia Atlas >>>> Sent: Monday, August 13, 2012 8:41 AM >>>> To: Scott Whyte >>>> Cc: Thomas Nadeau; Gert Grammel; Alia Atlas; Lenny Giuliano;=20 >>>> irs-discuss@ietf.org >>>> Subject: Re: [irs-discuss] IRS comments >>>> >>>> ...snip... >>>> >>>> On Fri, Aug 10, 2012 at 9:03 PM, Scott Whyte wrote= : >>>>> On Fri, Aug 10, 2012 at 5:16 PM, Alia Atlas wrote= : >>>> >>>>>> I do think it is important to have the RIB as an arbitration mechani= sm >>>>>> on the device. Russ's suggestion that for the RIB sub-interface, t= he >>>>>> IRS agent might communicate logically to an IRS routing process=20 >>>>>> gives good semantics and interactions. Obviously,=20 >>>>>> implementations may differ. >>>>> >>>>> As long as the arbitration mechanism is reconfigurable by the=20 >>>>> operator to whatever precedence they want, I agree. Its not clear=20 >>>>> to me if various RIB implementations treat all proffered routes=20 >>>>> the same, nor if they store the same meta-data with all protocol sour= ces. >>>>> So there needs to be some way for the operator to leverage exposed=20 >>>>> protocol-specific optimizations, without conflict from the other=20 >>>>> routing processes, if they so desire. OTOH if it can all be done=20 >>>>> via static routes, it seems much simpler. :) >>>> >>>> Clearly the IRS sub-interface for the RIB needs to introduce/define=20 >>>> the different precedences; my assumption is that it would be per=20 >>>> route with a well-defined small set of meta-data. This is part of=20 >>>> where having good use-cases will help us understand what behavior=20 >>>> is necessary. The static routes do seem like a simpler case to start = with. >>>> >>>> Alia >>>> _______________________________________________ >>>> 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 >> _______________________________________________ >> 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 > > > > _______________________________________________ irs-discuss mailing list irs-discuss@ietf.org https://www.ietf.org/mailman/listinfo/irs-discuss Return-Path: 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 5881A21E8041 for ; Wed, 15 Aug 2012 18:58:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[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 M4RKu-MP3TTt for ; Wed, 15 Aug 2012 18:58:21 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 513D811E809B for ; Wed, 15 Aug 2012 18:58:11 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml202-edg.china.huawei.com) ([172.18.9.243]) by dfwrg02-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AIX35980; Wed, 15 Aug 2012 17:58:11 -0800 (PST) Received: from DFWEML407-HUB.china.huawei.com (10.193.5.132) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 15 Aug 2012 18:56:32 -0700 Received: from DFWEML513-MBS.china.huawei.com ([169.254.4.5]) by dfweml407-hub.china.huawei.com ([10.193.5.132]) with mapi id 14.01.0323.003; Wed, 15 Aug 2012 18:56:30 -0700 From: Lin Han To: Alia Atlas , "robert@raszuk.net" Thread-Topic: [irs-discuss] IRS comments Thread-Index: AQHNezMFFk/Z1s09GUmYoTpEkZqfvZdbrMHw Date: Thu, 16 Aug 2012 01:56:30 +0000 Message-ID: <1D30AF33624CDD4A99E8C395069A2A161FE11D7F@dfweml513-mbs.china.huawei.com> References: <812700A304640D4292205D5E83FC59E1061C211D@p-embx01-eq.jnpr.net> <3512BB31280C39448A9880F61DD54CEB09C07E@xmb-aln-x09.cisco.com> <502BFD81.4070809@raszuk.net> In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.212.246.41] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: Olen Stokes , Edward Crabbe , "David Lake \(dlake\)" , "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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Aug 2012 01:58:22 -0000 Will IRS provide a channel for data such as data packet punt and injection?= As you said inject OAM into the created LSP. Also, what is the good means of learning more topology and dynamic events a= nd related state easily? Do you have any rough idea? I thought PCE has lear= nt all from the running protocol since it is part of the topo. Lin -----Original Message----- From: irs-discuss-bounces@ietf.org [mailto:irs-discuss-bounces@ietf.org] On= Behalf Of Alia Atlas Sent: Wednesday, August 15, 2012 3:12 PM To: robert@raszuk.net Cc: Olen Stokes; Edward Crabbe; David Lake (dlake); irs-discuss@ietf.org Subject: Re: [irs-discuss] IRS comments On Wed, Aug 15, 2012 at 3:50 PM, Robert Raszuk wrote: > >> It could just as easily describe a PCE. > > > PCE could be a controller just talking to headends and asking them to sig= nal > LSP X with RSVP-TE or it could talk to all head, tail and via nodes and > actually program the forwarding label entries. > > I am observing that IRS framework is more of the former case rather then = the > latter in general. > > However if this is the former then I am a bit not clear what value it is = to > deliver if we compare it with current statefull PCE efforts ;) Other than providing a good means of learning more topology and dynamic events and related state easily?? Feedback loops - and an easy mechanism to, for instance, test a created LSP via OAM before declaring the new one up? Alia > Best, > R. > > > > _______________________________________________ irs-discuss mailing list irs-discuss@ietf.org https://www.ietf.org/mailman/listinfo/irs-discuss Return-Path: 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 5CBDB11E80BA for ; Wed, 15 Aug 2012 16:50:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.336 X-Spam-Level: X-Spam-Status: No, score=-106.336 tagged_above=-999 required=5 tests=[AWL=0.263, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 J1NoKH9+qGzk for ; Wed, 15 Aug 2012 16:50:53 -0700 (PDT) Received: from nbfkord-smmo03.seg.att.com (nbfkord-smmo03.seg.att.com [209.65.160.84]) by ietfa.amsl.com (Postfix) with ESMTP id 5134211E8098 for ; Wed, 15 Aug 2012 16:50:52 -0700 (PDT) Received: from unknown [144.160.128.153] (EHLO nbfkord-smmo03.seg.att.com) by nbfkord-smmo03.seg.att.com(mxl_mta-6.11.0-10) with ESMTP id cd53c205.7d0b7940.706501.00-593.1941499.nbfkord-smmo03.seg.att.com (envelope-from ); Wed, 15 Aug 2012 23:50:52 +0000 (UTC) X-MXL-Hash: 502c35dc1ec6b8de-163576c0ff6b146c29d310bbbcaa8bde23d1b77b Received: from unknown [144.160.128.153] (EHLO flpi408.enaf.ffdc.sbc.com) by nbfkord-smmo03.seg.att.com(mxl_mta-6.11.0-10) over TLS secured channel with ESMTP id 0d53c205.0.706467.00-445.1941410.nbfkord-smmo03.seg.att.com (envelope-from ); Wed, 15 Aug 2012 23:50:41 +0000 (UTC) X-MXL-Hash: 502c35d17ba60584-0c9c78a790eedca323848652975c5cae537f64a9 Received: from enaf.ffdc.sbc.com (localhost.localdomain [127.0.0.1]) by flpi408.enaf.ffdc.sbc.com (8.14.5/8.14.5) with ESMTP id q7FNodbi014537; Wed, 15 Aug 2012 16:50:40 -0700 Received: from fflint03.pst.cso.att.com (fflint03.pst.cso.att.com [150.234.39.63]) by flpi408.enaf.ffdc.sbc.com (8.14.5/8.14.5) with ESMTP id q7FNoR6G014398 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 15 Aug 2012 16:50:33 -0700 Received: from MISOUT7MSGHUB9C.ITServices.sbc.com (misout7msghub9c.itservices.sbc.com [144.151.223.82]) by fflint03.pst.cso.att.com (RSA Interceptor); Wed, 15 Aug 2012 16:50:09 -0700 Received: from MISOUT7MSGUSR9I.ITServices.sbc.com ([144.151.223.56]) by MISOUT7MSGHUB9C.ITServices.sbc.com ([144.151.223.82]) with mapi id 14.02.0298.004; Wed, 15 Aug 2012 19:50:09 -0400 From: "UTTARO, JAMES" To: "'Shah, Himanshu'" , Alia Atlas Thread-Topic: [irs-discuss] IRS comments Thread-Index: Ac15UPmWZFj3YBmsT9Smjrge48ksHAATypTAAFoVXoAAAUAUgAABZOIAAAKyOQAAAEVwAAADS7QAAAAO5wAAADV/gAAByQUAAAfLkAAAAdXVgAAGmN5w Date: Wed, 15 Aug 2012 23:50:08 +0000 Message-ID: References: <812700A304640D4292205D5E83FC59E1061C211D@p-embx01-eq.jnpr.net> <3512BB31280C39448A9880F61DD54CEB09C07E@xmb-aln-x09.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.121.71] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.128.153] X-AnalysisOut: [v=1.0 c=1 a=yNG8JE4Tb-gA:10 a=ofMgfj31e3cA:10 a=BLceEmwcHo] X-AnalysisOut: [wA:10 a=kj9zAlcOel0A:10 a=xwOvzTHDVLE4u4nGvK72ag==:17 a=48] X-AnalysisOut: [vgC7mUAAAA:8 a=pGLkceISAAAA:8 a=FmoMKUsJAAAA:8 a=1XWaLZrsA] X-AnalysisOut: [AAA:8 a=AUd_NHdVAAAA:8 a=vI_dY4GQAAAA:8 a=Gt8pL4kg_UWlm4jt] X-AnalysisOut: [V5IA:9 a=CjuIK1q_8ugA:10 a=lZB815dzVvQA:10 a=MSl-tDqOz04A:] X-AnalysisOut: [10 a=AopqHHen_-cA:10 a=UTB_XpHje0EA:10 a=JfD0Fch1gWkA:10 a] X-AnalysisOut: [=UmnohBiOdKAA:10 a=l-h6ECO8BAhncfZ0:21 a=S9T28lsuGa6_XL2f:] X-AnalysisOut: [21] Cc: "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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Aug 2012 23:50:54 -0000 Inject routes yes, but I would not assume that implies that all state from = IRS is prioritized.. I think an important point to remember is that how IRS= interfaces with routing state learned via network protocols needs to be pa= rt of this effort.. Jim Uttaro -----Original Message----- From: irs-discuss-bounces@ietf.org [mailto:irs-discuss-bounces@ietf.org] On= Behalf Of Shah, Himanshu Sent: Wednesday, August 15, 2012 6:57 PM To: Alia Atlas Cc: irs-discuss@ietf.org Subject: Re: [irs-discuss] IRS comments OK - So that I am clear... IRS would provide interface to RIB such that routes can be injected with pr= iority and the local routing table manager on the node would then apply precedence= rules, select the route, do ARP resolve (if ETH) and inject the prefix with next-hop info into the F= IB. The next step is then programming the FIB on the line card (if applicable). Would make sense for IRS to not provide interface to the FIB on the second = step. But you are saying that it would also not provide interface to FIB of the f= irst step.=20 Is that correct? /himanshu -----Original Message----- From: Alia Atlas [mailto:akatlas@gmail.com]=20 Sent: Wednesday, August 15, 2012 6:05 PM To: Shah, Himanshu Cc: irs-discuss@ietf.org Subject: Re: [irs-discuss] IRS comments I don't see IRS going below the RIB layer to FIB. Alia On Wed, Aug 15, 2012 at 2:21 PM, Shah, Himanshu wrote: > I will let Ed clarify on what he means by "controller" . > > > > But here is my view of "application", "controller", "use-case" etc=20 > etc, > > > > When an XaaS processes a request it takes into consideration of=20 > availability of the CPU, memory, application data, cost of power, etc.=20 > to instantiate a VM on some host machine. > > One additional resource taken into consideration is the availability=20 > and/or requirement of the network connectivity between the resources > > such as VM, application data, requester, etc. > > > > The provider of XaaS thingy is the application server. > > (Centralized) Network "Controller(s)" knows current state of network=20 > infrastructure and (to be decided how much it) controls member network=20 > nodes using IRS. > > The "use case" here is to be able to dynamically create L2/L2.5/L3=20 > connectivity with specific TE characteristics between the (perhaps=20 > geographically dispersed) resource points. > > > > In hierarchical fashion: Application server <- (application interface) = -> > Network Controller <- (IRS) -> Network Node > > > > As we heard at IETF, IRS has tentacles in network nodes from BGP=20 > policies, all the way down to FIBs/LFIBs/ACL. > > > > So we need use cases for which applications would require=20 > accessibility to - > > BGP Policies > > RIB > > LSDB ( I saw an email which talks about reducing IGP to link=20 > distribution protocol and running SPF in centralized network=20 > controller) > > LIB > > FIB > > ACL (this is perhaps obvious) > > Etc etc > > > > I broad brushed and simplified a lot here to express my view - not=20 > sure if this jives with others. > > > > /Himanshu > > > > > > > > > > > > > > > > > > From: irs-discuss-bounces@ietf.org=20 > [mailto:irs-discuss-bounces@ietf.org] On Behalf Of Olen Stokes > Sent: Wednesday, August 15, 2012 1:30 PM > To: Edward Crabbe; Alia Atlas > Cc: David Lake (dlake); irs-discuss@ietf.org > > > Subject: Re: [irs-discuss] IRS comments > > > > Thanks. Can you also give us what you mean by "controller". > > > > Olen > > > > From: Edward Crabbe [mailto:edc@google.com] > Sent: Wednesday, August 15, 2012 1:24 PM > To: Alia Atlas > Cc: David Lake (dlake); Olen Stokes; irs-discuss@ietf.org > Subject: Re: [irs-discuss] IRS comments > > > > s/wg/pre-BOF proto-wg :P/g > > On Wed, Aug 15, 2012 at 10:22 AM, Edward Crabbe wrote: > > +1 Alia. There's been a lot of confusion over this term. Having gone=20 > +a few > rounds with folks on this one in other forums, I'll point out that=20 > what most people mean by application (myself included) is some set of=20 > control software (a scheduler, a path optimizer etc) that provides=20 > instructions to the controller, which are in turn translated to the appro= priate PDUs. > > > > Having 'end user' applications request/make changes to forwarding=20 > state without an intermediate broker/aggregator acting on their behalf=20 > sounds like a recipe for disaster for operational networks, or, as is=20 > more likely, a quick hike to the protocol grave yard (followed by a=20 > long grave-side party > :P) for the wg. > > > > my 2c. > > > > On Wed, Aug 15, 2012 at 8:48 AM, Alia Atlas wrote: > > Hi David, > > We do need to clarify what is meant by an application. I would not=20 > expect that real user-land applications would talk directly to routing=20 > devices via IRS. I can see that going through an intermediary. The=20 > IRS abstractions are unlikely to be as high-level as user-land=20 > applications would want and the security and policy issues would get=20 > exciting. > > Clarifying what applications are more in-scope initially is part of=20 > where use-cases will help. Can you write up ones to=20 > categorize/describe your thoughts? > > Alia > > > On Wed, Aug 15, 2012 at 11:40 AM, David Lake (dlake) > wrote: >> As another newbie to this, I have some questions about "application=20 >> vendors." >> >> Who is the target audience here ? That will determine what functionali= ty >> and abstraction of the network we need to expose to that "application." >> >> This presently appears to be a little confused - at least in my mind. =20 >> The draft talks very much as if the application we are addressing is=20 >> an OSS/BSS system, essentially provisioning from the domain owner. >> >> However, linking this to the wider goals of SDN as voiced by=20 >> customers/users at the first Open Network Summit, there appears to be=20 >> a desire for cross-domain and user-land application integration. >> >> At this level - as an example giving a content cache the ability to=20 >> ensure delivery of an HD video to an end user - the application will=20 >> not be interested in the underlying topology of the network; it will =20 >> need to know that application X can be delivered with parameters Y betwe= en reading from >> the content store to delivery to the user's browser. How the stream >> traverses the infrastructure is immaterial. >> >> Are we intending that IRS satisfies BOTH these requirements (i.e. for=20 >> ALL applications ?), or should we be more prescriptive about which=20 >> application space we are addressing ? >> >> Thanks >> >> David >> >> -----Original Message----- >> From: irs-discuss-bounces@ietf.org=20 >> [mailto:irs-discuss-bounces@ietf.org] >> On Behalf Of Alia Atlas >> Sent: Wednesday, August 15, 2012 7:23 AM >> To: Olen Stokes >> Cc: irs-discuss@ietf.org >> Subject: Re: [irs-discuss] IRS comments >> >> I have not specifically heard from application vendors about this. >> My current plan is that we focus on a Use-Cases draft and define=20 >> within that some motivating use-cases that we agree are good first=20 >> targets. Those can drive which subset of functionality we focus on. >> >> More use-cases are, of course, quite welcome. Posting them to the=20 >> mailing list is a good first start. Russ White is starting the=20 >> general use-cases draft based on the three use-cases that he sent to the= list. >> >> Alia >> >> On Wed, Aug 15, 2012 at 9:43 AM, Olen Stokes=20 >> >> wrote: >>> Are there applications vendors out there that already have specific=20 >>> requirements for what this " subset of the data-models for sub-interfac= es" >>> should be? >>> >>> Olen >>> >>> -----Original Message----- >>> From: irs-discuss-bounces@ietf.org >>> [mailto:irs-discuss-bounces@ietf.org] On Behalf Of Alia Atlas >>> Sent: Wednesday, August 15, 2012 9:08 AM >>> To: Shah, Himanshu >>> Cc: Gert Grammel; irs-discuss@ietf.org; Lenny Giuliano; Thomas=20 >>> Nadeau; Alia Atlas; Scott Whyte >>> Subject: Re: [irs-discuss] IRS comments >>> >>> Hi Himanshu, >>> >>> Welcome. I agree that IRS isn't going to spring into being fully >>> formed - I expect that we'll focus on a subset of the data-models=20 >>> for sub-interfaces along with an associated protocol (whether that=20 >>> is a new one or extending an existing one). >>> >>> Alia >>> >>> On Wed, Aug 15, 2012 at 7:41 AM, Shah, Himanshu wrote= : >>>> Newbie to this discussions list and have read only a last couple of=20 >>>> mails, so pardon the repeat if somebody has already raised the=20 >>>> following as a concern. >>>> >>>> I realize we are early in IRS architecture definition but one thing=20 >>>> to keep in mind is the user experience. >>>> We need to make sure that exposed interface to=20 >>>> RIB/LFIB/FIB/IGPs/BGP/LSDBs etc etc provide a consistent=20 >>>> predictive action/response/events even when different=20 >>>> implementations has varying capabilities. >>>> >>>> At the moment it seems like a wild wild west. >>>> Perhaps IRS can be defined in phases starting with a simpler,=20 >>>> limited version.. >>>> >>>> Thanks, >>>> himanshu >>>> >>>> >>>> -----Original Message----- >>>> From: irs-discuss-bounces@ietf.org >>>> [mailto:irs-discuss-bounces@ietf.org] On Behalf Of Alia Atlas >>>> Sent: Monday, August 13, 2012 8:41 AM >>>> To: Scott Whyte >>>> Cc: Thomas Nadeau; Gert Grammel; Alia Atlas; Lenny Giuliano;=20 >>>> irs-discuss@ietf.org >>>> Subject: Re: [irs-discuss] IRS comments >>>> >>>> ...snip... >>>> >>>> On Fri, Aug 10, 2012 at 9:03 PM, Scott Whyte wrote= : >>>>> On Fri, Aug 10, 2012 at 5:16 PM, Alia Atlas wrote= : >>>> >>>>>> I do think it is important to have the RIB as an arbitration mechani= sm >>>>>> on the device. Russ's suggestion that for the RIB sub-interface, t= he >>>>>> IRS agent might communicate logically to an IRS routing process=20 >>>>>> gives good semantics and interactions. Obviously,=20 >>>>>> implementations may differ. >>>>> >>>>> As long as the arbitration mechanism is reconfigurable by the=20 >>>>> operator to whatever precedence they want, I agree. Its not clear=20 >>>>> to me if various RIB implementations treat all proffered routes=20 >>>>> the same, nor if they store the same meta-data with all protocol sour= ces. >>>>> So there needs to be some way for the operator to leverage exposed=20 >>>>> protocol-specific optimizations, without conflict from the other=20 >>>>> routing processes, if they so desire. OTOH if it can all be done=20 >>>>> via static routes, it seems much simpler. :) >>>> >>>> Clearly the IRS sub-interface for the RIB needs to introduce/define=20 >>>> the different precedences; my assumption is that it would be per=20 >>>> route with a well-defined small set of meta-data. This is part of=20 >>>> where having good use-cases will help us understand what behavior=20 >>>> is necessary. The static routes do seem like a simpler case to start = with. >>>> >>>> Alia >>>> _______________________________________________ >>>> 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 >> _______________________________________________ >> 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 > > > > _______________________________________________ irs-discuss mailing list irs-discuss@ietf.org https://www.ietf.org/mailman/listinfo/irs-discuss Return-Path: 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 3E65011E8098 for ; Wed, 15 Aug 2012 15:57:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.063 X-Spam-Level: X-Spam-Status: No, score=-3.063 tagged_above=-999 required=5 tests=[AWL=0.202, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-1] 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 Fh+oTpYhY5oa for ; Wed, 15 Aug 2012 15:57:15 -0700 (PDT) Received: from mx0b-00103a01.pphosted.com (mx0b-00103a01.pphosted.com [67.231.152.227]) by ietfa.amsl.com (Postfix) with ESMTP id 018D311E808A for ; Wed, 15 Aug 2012 15:57:14 -0700 (PDT) Received: from pps.filterd (m0001124 [127.0.0.1]) by mx0b-00103a01.pphosted.com (8.14.4/8.14.4) with SMTP id q7FMtepa027130; Wed, 15 Aug 2012 18:57:13 -0400 Received: from mdwexght01.ciena.com (LIN1-118-36-28.ciena.com [63.118.36.28]) by mx0b-00103a01.pphosted.com with ESMTP id 16rja6rdfu-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 15 Aug 2012 18:57:13 -0400 Received: from MDWEXCHCGSIHT01.ciena.com (10.4.140.106) by MDWEXGHT01.ciena.com (10.4.140.138) with Microsoft SMTP Server (TLS) id 8.3.192.1; Wed, 15 Aug 2012 18:57:14 -0400 Received: from MDWEXGMB02.ciena.com ([::1]) by MDWEXCHCGSIHT01.ciena.com ([::1]) with mapi; Wed, 15 Aug 2012 18:57:14 -0400 From: "Shah, Himanshu" To: Alia Atlas Date: Wed, 15 Aug 2012 18:57:13 -0400 Thread-Topic: [irs-discuss] IRS comments Thread-Index: Ac17MfqUbwfYeQeXSS+olnEYNqNtXAABDuLw Message-ID: References: <812700A304640D4292205D5E83FC59E1061C211D@p-embx01-eq.jnpr.net> <3512BB31280C39448A9880F61DD54CEB09C07E@xmb-aln-x09.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US X-TM-AS-Product-Ver: SMEX-10.0.0.1412-7.000.1014-19116.000 X-TM-AS-Result: No--27.506800-8.000000-31 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.7.7855, 1.0.260, 0.0.0000 definitions=2012-08-15_04:2012-08-15, 2012-08-15, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=1 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=6.0.2-1203120001 definitions=main-1208150277 Cc: "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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Aug 2012 22:57:16 -0000 OK - So that I am clear... IRS would provide interface to RIB such that routes can be injected with pr= iority and the local routing table manager on the node would then apply precedence= rules, select the route, do ARP resolve (if ETH) and inject the prefix with next-hop info into the F= IB. The next step is then programming the FIB on the line card (if applicable). Would make sense for IRS to not provide interface to the FIB on the second = step. But you are saying that it would also not provide interface to FIB of the f= irst step.=20 Is that correct? /himanshu -----Original Message----- From: Alia Atlas [mailto:akatlas@gmail.com]=20 Sent: Wednesday, August 15, 2012 6:05 PM To: Shah, Himanshu Cc: irs-discuss@ietf.org Subject: Re: [irs-discuss] IRS comments I don't see IRS going below the RIB layer to FIB. Alia On Wed, Aug 15, 2012 at 2:21 PM, Shah, Himanshu wrote: > I will let Ed clarify on what he means by "controller" . > > > > But here is my view of "application", "controller", "use-case" etc=20 > etc, > > > > When an XaaS processes a request it takes into consideration of=20 > availability of the CPU, memory, application data, cost of power, etc.=20 > to instantiate a VM on some host machine. > > One additional resource taken into consideration is the availability=20 > and/or requirement of the network connectivity between the resources > > such as VM, application data, requester, etc. > > > > The provider of XaaS thingy is the application server. > > (Centralized) Network "Controller(s)" knows current state of network=20 > infrastructure and (to be decided how much it) controls member network=20 > nodes using IRS. > > The "use case" here is to be able to dynamically create L2/L2.5/L3=20 > connectivity with specific TE characteristics between the (perhaps=20 > geographically dispersed) resource points. > > > > In hierarchical fashion: Application server <- (application interface) = -> > Network Controller <- (IRS) -> Network Node > > > > As we heard at IETF, IRS has tentacles in network nodes from BGP=20 > policies, all the way down to FIBs/LFIBs/ACL. > > > > So we need use cases for which applications would require=20 > accessibility to - > > BGP Policies > > RIB > > LSDB ( I saw an email which talks about reducing IGP to link=20 > distribution protocol and running SPF in centralized network=20 > controller) > > LIB > > FIB > > ACL (this is perhaps obvious) > > Etc etc > > > > I broad brushed and simplified a lot here to express my view - not=20 > sure if this jives with others. > > > > /Himanshu > > > > > > > > > > > > > > > > > > From: irs-discuss-bounces@ietf.org=20 > [mailto:irs-discuss-bounces@ietf.org] On Behalf Of Olen Stokes > Sent: Wednesday, August 15, 2012 1:30 PM > To: Edward Crabbe; Alia Atlas > Cc: David Lake (dlake); irs-discuss@ietf.org > > > Subject: Re: [irs-discuss] IRS comments > > > > Thanks. Can you also give us what you mean by "controller". > > > > Olen > > > > From: Edward Crabbe [mailto:edc@google.com] > Sent: Wednesday, August 15, 2012 1:24 PM > To: Alia Atlas > Cc: David Lake (dlake); Olen Stokes; irs-discuss@ietf.org > Subject: Re: [irs-discuss] IRS comments > > > > s/wg/pre-BOF proto-wg :P/g > > On Wed, Aug 15, 2012 at 10:22 AM, Edward Crabbe wrote: > > +1 Alia. There's been a lot of confusion over this term. Having gone=20 > +a few > rounds with folks on this one in other forums, I'll point out that=20 > what most people mean by application (myself included) is some set of=20 > control software (a scheduler, a path optimizer etc) that provides=20 > instructions to the controller, which are in turn translated to the appro= priate PDUs. > > > > Having 'end user' applications request/make changes to forwarding=20 > state without an intermediate broker/aggregator acting on their behalf=20 > sounds like a recipe for disaster for operational networks, or, as is=20 > more likely, a quick hike to the protocol grave yard (followed by a=20 > long grave-side party > :P) for the wg. > > > > my 2c. > > > > On Wed, Aug 15, 2012 at 8:48 AM, Alia Atlas wrote: > > Hi David, > > We do need to clarify what is meant by an application. I would not=20 > expect that real user-land applications would talk directly to routing=20 > devices via IRS. I can see that going through an intermediary. The=20 > IRS abstractions are unlikely to be as high-level as user-land=20 > applications would want and the security and policy issues would get=20 > exciting. > > Clarifying what applications are more in-scope initially is part of=20 > where use-cases will help. Can you write up ones to=20 > categorize/describe your thoughts? > > Alia > > > On Wed, Aug 15, 2012 at 11:40 AM, David Lake (dlake) > wrote: >> As another newbie to this, I have some questions about "application=20 >> vendors." >> >> Who is the target audience here ? That will determine what functionali= ty >> and abstraction of the network we need to expose to that "application." >> >> This presently appears to be a little confused - at least in my mind. =20 >> The draft talks very much as if the application we are addressing is=20 >> an OSS/BSS system, essentially provisioning from the domain owner. >> >> However, linking this to the wider goals of SDN as voiced by=20 >> customers/users at the first Open Network Summit, there appears to be=20 >> a desire for cross-domain and user-land application integration. >> >> At this level - as an example giving a content cache the ability to=20 >> ensure delivery of an HD video to an end user - the application will=20 >> not be interested in the underlying topology of the network; it will =20 >> need to know that application X can be delivered with parameters Y betwe= en reading from >> the content store to delivery to the user's browser. How the stream >> traverses the infrastructure is immaterial. >> >> Are we intending that IRS satisfies BOTH these requirements (i.e. for=20 >> ALL applications ?), or should we be more prescriptive about which=20 >> application space we are addressing ? >> >> Thanks >> >> David >> >> -----Original Message----- >> From: irs-discuss-bounces@ietf.org=20 >> [mailto:irs-discuss-bounces@ietf.org] >> On Behalf Of Alia Atlas >> Sent: Wednesday, August 15, 2012 7:23 AM >> To: Olen Stokes >> Cc: irs-discuss@ietf.org >> Subject: Re: [irs-discuss] IRS comments >> >> I have not specifically heard from application vendors about this. >> My current plan is that we focus on a Use-Cases draft and define=20 >> within that some motivating use-cases that we agree are good first=20 >> targets. Those can drive which subset of functionality we focus on. >> >> More use-cases are, of course, quite welcome. Posting them to the=20 >> mailing list is a good first start. Russ White is starting the=20 >> general use-cases draft based on the three use-cases that he sent to the= list. >> >> Alia >> >> On Wed, Aug 15, 2012 at 9:43 AM, Olen Stokes=20 >> >> wrote: >>> Are there applications vendors out there that already have specific=20 >>> requirements for what this " subset of the data-models for sub-interfac= es" >>> should be? >>> >>> Olen >>> >>> -----Original Message----- >>> From: irs-discuss-bounces@ietf.org >>> [mailto:irs-discuss-bounces@ietf.org] On Behalf Of Alia Atlas >>> Sent: Wednesday, August 15, 2012 9:08 AM >>> To: Shah, Himanshu >>> Cc: Gert Grammel; irs-discuss@ietf.org; Lenny Giuliano; Thomas=20 >>> Nadeau; Alia Atlas; Scott Whyte >>> Subject: Re: [irs-discuss] IRS comments >>> >>> Hi Himanshu, >>> >>> Welcome. I agree that IRS isn't going to spring into being fully >>> formed - I expect that we'll focus on a subset of the data-models=20 >>> for sub-interfaces along with an associated protocol (whether that=20 >>> is a new one or extending an existing one). >>> >>> Alia >>> >>> On Wed, Aug 15, 2012 at 7:41 AM, Shah, Himanshu wrote= : >>>> Newbie to this discussions list and have read only a last couple of=20 >>>> mails, so pardon the repeat if somebody has already raised the=20 >>>> following as a concern. >>>> >>>> I realize we are early in IRS architecture definition but one thing=20 >>>> to keep in mind is the user experience. >>>> We need to make sure that exposed interface to=20 >>>> RIB/LFIB/FIB/IGPs/BGP/LSDBs etc etc provide a consistent=20 >>>> predictive action/response/events even when different=20 >>>> implementations has varying capabilities. >>>> >>>> At the moment it seems like a wild wild west. >>>> Perhaps IRS can be defined in phases starting with a simpler,=20 >>>> limited version.. >>>> >>>> Thanks, >>>> himanshu >>>> >>>> >>>> -----Original Message----- >>>> From: irs-discuss-bounces@ietf.org >>>> [mailto:irs-discuss-bounces@ietf.org] On Behalf Of Alia Atlas >>>> Sent: Monday, August 13, 2012 8:41 AM >>>> To: Scott Whyte >>>> Cc: Thomas Nadeau; Gert Grammel; Alia Atlas; Lenny Giuliano;=20 >>>> irs-discuss@ietf.org >>>> Subject: Re: [irs-discuss] IRS comments >>>> >>>> ...snip... >>>> >>>> On Fri, Aug 10, 2012 at 9:03 PM, Scott Whyte wrote= : >>>>> On Fri, Aug 10, 2012 at 5:16 PM, Alia Atlas wrote= : >>>> >>>>>> I do think it is important to have the RIB as an arbitration mechani= sm >>>>>> on the device. Russ's suggestion that for the RIB sub-interface, t= he >>>>>> IRS agent might communicate logically to an IRS routing process=20 >>>>>> gives good semantics and interactions. Obviously,=20 >>>>>> implementations may differ. >>>>> >>>>> As long as the arbitration mechanism is reconfigurable by the=20 >>>>> operator to whatever precedence they want, I agree. Its not clear=20 >>>>> to me if various RIB implementations treat all proffered routes=20 >>>>> the same, nor if they store the same meta-data with all protocol sour= ces. >>>>> So there needs to be some way for the operator to leverage exposed=20 >>>>> protocol-specific optimizations, without conflict from the other=20 >>>>> routing processes, if they so desire. OTOH if it can all be done=20 >>>>> via static routes, it seems much simpler. :) >>>> >>>> Clearly the IRS sub-interface for the RIB needs to introduce/define=20 >>>> the different precedences; my assumption is that it would be per=20 >>>> route with a well-defined small set of meta-data. This is part of=20 >>>> where having good use-cases will help us understand what behavior=20 >>>> is necessary. The static routes do seem like a simpler case to start = with. >>>> >>>> Alia >>>> _______________________________________________ >>>> 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 >> _______________________________________________ >> 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 > > > > Return-Path: 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 C41B621F85E3 for ; Wed, 15 Aug 2012 15:11:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.561 X-Spam-Level: X-Spam-Status: No, score=-3.561 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 jIlFMdI5iFHv for ; Wed, 15 Aug 2012 15:11:57 -0700 (PDT) Received: from mail-gg0-f172.google.com (mail-gg0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 400E521F85DF for ; Wed, 15 Aug 2012 15:11:57 -0700 (PDT) Received: by ggnh4 with SMTP id h4so2531478ggn.31 for ; Wed, 15 Aug 2012 15:11:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=fW63rmmyZI+qywZUqFIWnVMhVBVzmu5ZP7m55WBb9e4=; b=o937Dgfupf3/0uVIaFXOOnZ64HtApt7iWX1FyKOAvPwsU+oBMUCRBDagIm6+p4czYd ry7/mXuxpaxLCMtklYb0X1sm4EhGyAYhEYZsXYQRQi4WITr8lX2nFvUp8pz8X8F8W8Jr OdkRUhmeScuOwieGrjOW7gc4Mg4pdL4M7KsQ3inZhsu7QPF/mHIoZDgx3Zh7OwScbJRz U8vTc6TU2RBeLFV++EfHISthMGwRSFKnYpi+l0TyiyusRHTSN84FQD/1uEYxKlxX86T7 c/p9gqFAFSU3HlMI/DRhwSbLLDVDG6UkFsi+7P/nG4J4i0K4dqhXmIthy1SZyQkztlJa rLcA== MIME-Version: 1.0 Received: by 10.42.100.147 with SMTP id a19mr8114411ico.11.1345068716347; Wed, 15 Aug 2012 15:11:56 -0700 (PDT) Received: by 10.50.91.135 with HTTP; Wed, 15 Aug 2012 15:11:56 -0700 (PDT) In-Reply-To: <502BFD81.4070809@raszuk.net> References: <812700A304640D4292205D5E83FC59E1061C211D@p-embx01-eq.jnpr.net> <3512BB31280C39448A9880F61DD54CEB09C07E@xmb-aln-x09.cisco.com> <502BFD81.4070809@raszuk.net> Date: Wed, 15 Aug 2012 18:11:56 -0400 Message-ID: From: Alia Atlas To: robert@raszuk.net Content-Type: text/plain; charset=ISO-8859-1 Cc: Olen Stokes , Edward Crabbe , "David Lake \(dlake\)" , "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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Aug 2012 22:11:58 -0000 On Wed, Aug 15, 2012 at 3:50 PM, Robert Raszuk wrote: > >> It could just as easily describe a PCE. > > > PCE could be a controller just talking to headends and asking them to signal > LSP X with RSVP-TE or it could talk to all head, tail and via nodes and > actually program the forwarding label entries. > > I am observing that IRS framework is more of the former case rather then the > latter in general. > > However if this is the former then I am a bit not clear what value it is to > deliver if we compare it with current statefull PCE efforts ;) Other than providing a good means of learning more topology and dynamic events and related state easily?? Feedback loops - and an easy mechanism to, for instance, test a created LSP via OAM before declaring the new one up? Alia > Best, > R. > > > > Return-Path: 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 06D8121F84B2 for ; Wed, 15 Aug 2012 15:10:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.56 X-Spam-Level: X-Spam-Status: No, score=-3.56 tagged_above=-999 required=5 tests=[AWL=0.039, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 0eKeT9JkAhOp for ; Wed, 15 Aug 2012 15:10:13 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id E880A21F8498 for ; Wed, 15 Aug 2012 15:10:12 -0700 (PDT) Received: by iabz21 with SMTP id z21so268333iab.31 for ; Wed, 15 Aug 2012 15:10:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=2SJQCMTvEs0tzYQAZPJJ404Eup3leWE//vhZ1hao1D4=; b=xLvmsPV7w2dqHKv4TeppP+W7fsYnVmwO3AsbkM+16GhAKaCd+wEUOTyccVrEpGQek2 Uukyzrh+93RiJTh9Zy2kH/ZhuowKGX5j2WqGhxj1OdkPOkgsvHHrFfo/aoFf6lgjxHd0 wiVMhMr06GzLdimeEhHoLB1en9mpJBr7On6S5tIl5tqTPp7RfMAJwnN/w0b8zA5idqR7 QsvIoeCfYspMEy1Aqm/IBdmdhuJL2KVuN1ODMAexFtbRJNCJfMVyee3eMNWl8nmp6gS/ SQSHLgDC2CEQyTiwm2S8HEQIpZHfni59JkKqE5PJ5CTueFPJ43rFEjrp47i2+esX3lBk GtHQ== MIME-Version: 1.0 Received: by 10.42.86.138 with SMTP id u10mr3996756icl.32.1345068612359; Wed, 15 Aug 2012 15:10:12 -0700 (PDT) Received: by 10.50.91.135 with HTTP; Wed, 15 Aug 2012 15:10:12 -0700 (PDT) In-Reply-To: References: <812700A304640D4292205D5E83FC59E1061C211D@p-embx01-eq.jnpr.net> <3512BB31280C39448A9880F61DD54CEB09C07E@xmb-aln-x09.cisco.com> Date: Wed, 15 Aug 2012 18:10:12 -0400 Message-ID: From: Alia Atlas To: Olen Stokes Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: Edward Crabbe , "David Lake \(dlake\)" , "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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Aug 2012 22:10:14 -0000 I don't think it implies a reference to an OpenFlow Controller. An IRS client might live in a controller application that serves a similar functional role. This is part of what use-cases may help with. Alia On Wed, Aug 15, 2012 at 2:38 PM, Olen Stokes wrote: > I understand that. Sorry, I should have been more specific. I am trying= to > understand if usage of the word =93controller=94 on this list implies a > reference to any existing description such as =93Open Flow Controller=94. > > > > Olen > > > > From: Edward Crabbe [mailto:edc@google.com] > Sent: Wednesday, August 15, 2012 2:20 PM > To: Olen Stokes > Cc: Alia Atlas; David Lake (dlake); irs-discuss@ietf.org > > > Subject: Re: [irs-discuss] IRS comments > > > > The software (interacting with the 'applications' and) generating the act= ual > PDUs understood by the NEs. > > > > On Wed, Aug 15, 2012 at 10:30 AM, Olen Stokes > wrote: > > Thanks. Can you also give us what you mean by =93controller=94. > > > > Olen > > > > From: Edward Crabbe [mailto:edc@google.com] > Sent: Wednesday, August 15, 2012 1:24 PM > To: Alia Atlas > Cc: David Lake (dlake); Olen Stokes; irs-discuss@ietf.org > > > Subject: Re: [irs-discuss] IRS comments > > > > s/wg/pre-BOF proto-wg :P/g > > On Wed, Aug 15, 2012 at 10:22 AM, Edward Crabbe wrote: > > +1 Alia. There's been a lot of confusion over this term. Having gone a = few > rounds with folks on this one in other forums, I'll point out that what m= ost > people mean by application (myself included) is some set of control softw= are > (a scheduler, a path optimizer etc) that provides instructions to the > controller, which are in turn translated to the appropriate PDUs. > > > > Having 'end user' applications request/make changes to forwarding state > without an intermediate broker/aggregator acting on their behalf sounds l= ike > a recipe for disaster for operational networks, or, as is more likely, a > quick hike to the protocol grave yard (followed by a long grave-side part= y > :P) for the wg. > > > > my 2c. > > > > On Wed, Aug 15, 2012 at 8:48 AM, Alia Atlas wrote: > > Hi David, > > We do need to clarify what is meant by an application. I would not > expect that real user-land applications would talk directly to routing > devices via IRS. I can see that going through an intermediary. The > IRS abstractions are unlikely to be as high-level as user-land > applications would want and the security and policy issues would get > exciting. > > Clarifying what applications are more in-scope initially is part of > where use-cases will help. Can you write up ones to > categorize/describe your thoughts? > > Alia > > > On Wed, Aug 15, 2012 at 11:40 AM, David Lake (dlake) > wrote: >> As another newbie to this, I have some questions about "application >> vendors." >> >> Who is the target audience here ? That will determine what functionali= ty >> and abstraction of the network we need to expose to that "application." >> >> This presently appears to be a little confused - at least in my mind. T= he >> draft talks very much as if the application we are addressing is an OSS/= BSS >> system, essentially provisioning from the domain owner. >> >> However, linking this to the wider goals of SDN as voiced by >> customers/users at the first Open Network Summit, there appears to be a >> desire for cross-domain and user-land application integration. >> >> At this level - as an example giving a content cache the ability to ensu= re >> delivery of an HD video to an end user - the application will not be >> interested in the underlying topology of the network; it will need to k= now >> that application X can be delivered with parameters Y between reading fr= om >> the content store to delivery to the user's browser. How the stream >> traverses the infrastructure is immaterial. >> >> Are we intending that IRS satisfies BOTH these requirements (i.e. for AL= L >> applications ?), or should we be more prescriptive about which applicati= on >> space we are addressing ? >> >> Thanks >> >> David >> >> -----Original Message----- >> From: irs-discuss-bounces@ietf.org [mailto:irs-discuss-bounces@ietf.org] >> On Behalf Of Alia Atlas >> Sent: Wednesday, August 15, 2012 7:23 AM >> To: Olen Stokes >> Cc: irs-discuss@ietf.org >> Subject: Re: [irs-discuss] IRS comments >> >> I have not specifically heard from application vendors about this. >> My current plan is that we focus on a Use-Cases draft and define within >> that some motivating use-cases that we agree are good first targets. Th= ose >> can drive which subset of functionality we focus on. >> >> More use-cases are, of course, quite welcome. Posting them to the maili= ng >> list is a good first start. Russ White is starting the general use-case= s >> draft based on the three use-cases that he sent to the list. >> >> Alia >> >> On Wed, Aug 15, 2012 at 9:43 AM, Olen Stokes >> wrote: >>> Are there applications vendors out there that already have specific >>> requirements for what this " subset of the data-models for sub-interfac= es" >>> should be? >>> >>> Olen >>> >>> -----Original Message----- >>> From: irs-discuss-bounces@ietf.org >>> [mailto:irs-discuss-bounces@ietf.org] On Behalf Of Alia Atlas >>> Sent: Wednesday, August 15, 2012 9:08 AM >>> To: Shah, Himanshu >>> Cc: Gert Grammel; irs-discuss@ietf.org; Lenny Giuliano; Thomas Nadeau; >>> Alia Atlas; Scott Whyte >>> Subject: Re: [irs-discuss] IRS comments >>> >>> Hi Himanshu, >>> >>> Welcome. I agree that IRS isn't going to spring into being fully >>> formed - I expect that we'll focus on a subset of the data-models for >>> sub-interfaces along with an associated protocol (whether that is a new= one >>> or extending an existing one). >>> >>> Alia >>> >>> On Wed, Aug 15, 2012 at 7:41 AM, Shah, Himanshu wrote= : >>>> Newbie to this discussions list and have read only a last couple of >>>> mails, so pardon the repeat if somebody has already raised the followi= ng as >>>> a concern. >>>> >>>> I realize we are early in IRS architecture definition but one thing to >>>> keep in mind is the user experience. >>>> We need to make sure that exposed interface to >>>> RIB/LFIB/FIB/IGPs/BGP/LSDBs etc etc provide a consistent predictive >>>> action/response/events even when different implementations has varying >>>> capabilities. >>>> >>>> At the moment it seems like a wild wild west. >>>> Perhaps IRS can be defined in phases starting with a simpler, limited >>>> version.. >>>> >>>> Thanks, >>>> himanshu >>>> >>>> >>>> -----Original Message----- >>>> From: irs-discuss-bounces@ietf.org >>>> [mailto:irs-discuss-bounces@ietf.org] On Behalf Of Alia Atlas >>>> Sent: Monday, August 13, 2012 8:41 AM >>>> To: Scott Whyte >>>> Cc: Thomas Nadeau; Gert Grammel; Alia Atlas; Lenny Giuliano; >>>> irs-discuss@ietf.org >>>> Subject: Re: [irs-discuss] IRS comments >>>> >>>> ...snip... >>>> >>>> On Fri, Aug 10, 2012 at 9:03 PM, Scott Whyte wrote= : >>>>> On Fri, Aug 10, 2012 at 5:16 PM, Alia Atlas wrote= : >>>> >>>>>> I do think it is important to have the RIB as an arbitration mechani= sm >>>>>> on the device. Russ's suggestion that for the RIB sub-interface, t= he >>>>>> IRS agent might communicate logically to an IRS routing process >>>>>> gives good semantics and interactions. Obviously, implementations >>>>>> may differ. >>>>> >>>>> As long as the arbitration mechanism is reconfigurable by the >>>>> operator to whatever precedence they want, I agree. Its not clear >>>>> to me if various RIB implementations treat all proffered routes the >>>>> same, nor if they store the same meta-data with all protocol sources. >>>>> So there needs to be some way for the operator to leverage exposed >>>>> protocol-specific optimizations, without conflict from the other >>>>> routing processes, if they so desire. OTOH if it can all be done >>>>> via static routes, it seems much simpler. :) >>>> >>>> Clearly the IRS sub-interface for the RIB needs to introduce/define th= e >>>> different precedences; my assumption is that it would be per route wit= h a >>>> well-defined small set of meta-data. This is part of where having goo= d >>>> use-cases will help us understand what behavior is necessary. The sta= tic >>>> routes do seem like a simpler case to start with. >>>> >>>> Alia >>>> _______________________________________________ >>>> 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 >> _______________________________________________ >> 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 > > > > > > Return-Path: 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 1166921E8041 for ; Wed, 15 Aug 2012 15:09:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.56 X-Spam-Level: X-Spam-Status: No, score=-3.56 tagged_above=-999 required=5 tests=[AWL=0.039, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 WVcpgz67k5aH for ; Wed, 15 Aug 2012 15:09:08 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id C789521F85C7 for ; Wed, 15 Aug 2012 15:09:07 -0700 (PDT) Received: by yenm5 with SMTP id m5so2519219yen.31 for ; Wed, 15 Aug 2012 15:09:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=yAVib4r0FGboMgapaXnZFUHv7JJZ1JpFTNAV8OVDQ4I=; b=Cnv5qVadcjXTSSmGp5HXVZvIBYEVMg+zY9fwfyA1ebIMo/pB1BWkC4zhhY8B6UmGXy FWHpmGtDJCSBFI8OlgytNQPs3BH03VfBngdDHgNk8MBgqaLIbILGBRekwivWgHmy22DO PqCKe7nK/KyaFP5HefgFh/tRwl2rWuCyEbRCnKHCywb+sXTfXPVRPmwAoSMbNlR8ODV/ /bCpsK5zLxub/MV1HkmJ7s4UybqUBwKTEYLWg9NjZcCDSQ9yOtWDa3c9WHWuP3YFVu6i 8dW9DIIQAr7uPPN/Jq3+m428ZTBwqKrzJM0ccWh+dmq8eI974dLpDQHCwCvQOYTaPgJ5 OAnA== MIME-Version: 1.0 Received: by 10.42.151.71 with SMTP id d7mr15335146icw.18.1345068547094; Wed, 15 Aug 2012 15:09:07 -0700 (PDT) Received: by 10.50.91.135 with HTTP; Wed, 15 Aug 2012 15:09:06 -0700 (PDT) In-Reply-To: References: <812700A304640D4292205D5E83FC59E1061C211D@p-embx01-eq.jnpr.net> <3512BB31280C39448A9880F61DD54CEB09C07E@xmb-aln-x09.cisco.com> Date: Wed, 15 Aug 2012 18:09:06 -0400 Message-ID: From: Alia Atlas To: Edward Crabbe Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: "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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Aug 2012 22:09:09 -0000 On Wed, Aug 15, 2012 at 2:26 PM, Edward Crabbe wrote: > It's not clear to me that IRS has 'tentacles' (;)) in the LFIB... Perhaps the correct term is the LIB rather than the LFIB.... This is the control plane's mapping of incoming MPLS label to next-hops with associated label operations. (I think of them as puppet strings rather than tentacles - but if you prefer a more aquatic description...) > Is this the case? And if so, I guess I'll repeat the question I asked af= ter > Alia's presentation in the RTG meeting: will there be a mechanism to > negotiate and specify encapsulation types as well as form FECs etc? I think of a next-hop as including the outgoing interface and encapsulation type, with associated details. I've got that in the IRS framework draft in the RIB sub-interface description. Could you take a look and tell me what, at a high level, you see as missing? > On Wed, Aug 15, 2012 at 11:21 AM, Shah, Himanshu wrote: >> >> I will let Ed clarify on what he means by =93controller=94 . >> >> >> >> But here is my view of =93application=94, =93controller=94, =93use-case= =94 etc etc, >> >> >> >> When an XaaS processes a request it takes into consideration of >> availability of the CPU, memory, application data, cost of power, etc. t= o >> instantiate a VM on some host machine. >> >> One additional resource taken into consideration is the availability >> and/or requirement of the network connectivity between the resources >> >> such as VM, application data, requester, etc. >> >> >> >> The provider of XaaS thingy is the application server. >> >> (Centralized) Network =93Controller(s)=94 knows current state of networ= k >> infrastructure and (to be decided how much it) controls member network n= odes >> using IRS. >> >> The =93use case=94 here is to be able to dynamically create L2/L2.5/L3 >> connectivity with specific TE characteristics between the (perhaps >> geographically dispersed) resource points. >> >> >> >> In hierarchical fashion: Application server <- (application interface) >> -> Network Controller <- (IRS) -> Network Node >> >> >> >> As we heard at IETF, IRS has tentacles in network nodes from BGP policie= s, >> all the way down to FIBs/LFIBs/ACL. >> >> >> >> So we need use cases for which applications would require accessibility = to >> =96 >> >> BGP Policies >> >> RIB >> >> LSDB ( I saw an email which talks about reducing IGP to link distributio= n >> protocol and running SPF in centralized network controller) >> >> LIB >> >> FIB >> >> ACL (this is perhaps obvious) >> >> Etc etc >> >> >> >> I broad brushed and simplified a lot here to express my view =96 not sur= e if >> this jives with others. >> >> >> >> /Himanshu >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> From: irs-discuss-bounces@ietf.org [mailto:irs-discuss-bounces@ietf.org] >> On Behalf Of Olen Stokes >> Sent: Wednesday, August 15, 2012 1:30 PM >> To: Edward Crabbe; Alia Atlas >> Cc: David Lake (dlake); irs-discuss@ietf.org >> >> >> Subject: Re: [irs-discuss] IRS comments >> >> >> >> Thanks. Can you also give us what you mean by =93controller=94. >> >> >> >> Olen >> >> >> >> From: Edward Crabbe [mailto:edc@google.com] >> Sent: Wednesday, August 15, 2012 1:24 PM >> To: Alia Atlas >> Cc: David Lake (dlake); Olen Stokes; irs-discuss@ietf.org >> Subject: Re: [irs-discuss] IRS comments >> >> >> >> s/wg/pre-BOF proto-wg :P/g >> >> On Wed, Aug 15, 2012 at 10:22 AM, Edward Crabbe wrote: >> >> +1 Alia. There's been a lot of confusion over this term. Having gone a >> few rounds with folks on this one in other forums, I'll point out that w= hat >> most people mean by application (myself included) is some set of control >> software (a scheduler, a path optimizer etc) that provides instructions= to >> the controller, which are in turn translated to the appropriate PDUs. >> >> >> >> Having 'end user' applications request/make changes to forwarding state >> without an intermediate broker/aggregator acting on their behalf sounds = like >> a recipe for disaster for operational networks, or, as is more likely, a >> quick hike to the protocol grave yard (followed by a long grave-side par= ty >> :P) for the wg. >> >> >> >> my 2c. >> >> >> >> On Wed, Aug 15, 2012 at 8:48 AM, Alia Atlas wrote: >> >> Hi David, >> >> We do need to clarify what is meant by an application. I would not >> expect that real user-land applications would talk directly to routing >> devices via IRS. I can see that going through an intermediary. The >> IRS abstractions are unlikely to be as high-level as user-land >> applications would want and the security and policy issues would get >> exciting. >> >> Clarifying what applications are more in-scope initially is part of >> where use-cases will help. Can you write up ones to >> categorize/describe your thoughts? >> >> Alia >> >> >> On Wed, Aug 15, 2012 at 11:40 AM, David Lake (dlake) >> wrote: >> > As another newbie to this, I have some questions about "application >> > vendors." >> > >> > Who is the target audience here ? That will determine what >> > functionality and abstraction of the network we need to expose to that >> > "application." >> > >> > This presently appears to be a little confused - at least in my mind. >> > The draft talks very much as if the application we are addressing is a= n >> > OSS/BSS system, essentially provisioning from the domain owner. >> > >> > However, linking this to the wider goals of SDN as voiced by >> > customers/users at the first Open Network Summit, there appears to be = a >> > desire for cross-domain and user-land application integration. >> > >> > At this level - as an example giving a content cache the ability to >> > ensure delivery of an HD video to an end user - the application will n= ot be >> > interested in the underlying topology of the network; it will need to= know >> > that application X can be delivered with parameters Y between reading = from >> > the content store to delivery to the user's browser. How the stream >> > traverses the infrastructure is immaterial. >> > >> > Are we intending that IRS satisfies BOTH these requirements (i.e. for >> > ALL applications ?), or should we be more prescriptive about which >> > application space we are addressing ? >> > >> > Thanks >> > >> > David >> > >> > -----Original Message----- >> > From: irs-discuss-bounces@ietf.org [mailto:irs-discuss-bounces@ietf.or= g] >> > On Behalf Of Alia Atlas >> > Sent: Wednesday, August 15, 2012 7:23 AM >> > To: Olen Stokes >> > Cc: irs-discuss@ietf.org >> > Subject: Re: [irs-discuss] IRS comments >> > >> > I have not specifically heard from application vendors about this. >> > My current plan is that we focus on a Use-Cases draft and define withi= n >> > that some motivating use-cases that we agree are good first targets. = Those >> > can drive which subset of functionality we focus on. >> > >> > More use-cases are, of course, quite welcome. Posting them to the >> > mailing list is a good first start. Russ White is starting the genera= l >> > use-cases draft based on the three use-cases that he sent to the list. >> > >> > Alia >> > >> > On Wed, Aug 15, 2012 at 9:43 AM, Olen Stokes >> > wrote: >> >> Are there applications vendors out there that already have specific >> >> requirements for what this " subset of the data-models for sub-interf= aces" >> >> should be? >> >> >> >> Olen >> >> >> >> -----Original Message----- >> >> From: irs-discuss-bounces@ietf.org >> >> [mailto:irs-discuss-bounces@ietf.org] On Behalf Of Alia Atlas >> >> Sent: Wednesday, August 15, 2012 9:08 AM >> >> To: Shah, Himanshu >> >> Cc: Gert Grammel; irs-discuss@ietf.org; Lenny Giuliano; Thomas Nadeau= ; >> >> Alia Atlas; Scott Whyte >> >> Subject: Re: [irs-discuss] IRS comments >> >> >> >> Hi Himanshu, >> >> >> >> Welcome. I agree that IRS isn't going to spring into being fully >> >> formed - I expect that we'll focus on a subset of the data-models for >> >> sub-interfaces along with an associated protocol (whether that is a n= ew one >> >> or extending an existing one). >> >> >> >> Alia >> >> >> >> On Wed, Aug 15, 2012 at 7:41 AM, Shah, Himanshu >> >> wrote: >> >>> Newbie to this discussions list and have read only a last couple of >> >>> mails, so pardon the repeat if somebody has already raised the follo= wing as >> >>> a concern. >> >>> >> >>> I realize we are early in IRS architecture definition but one thing = to >> >>> keep in mind is the user experience. >> >>> We need to make sure that exposed interface to >> >>> RIB/LFIB/FIB/IGPs/BGP/LSDBs etc etc provide a consistent predictive >> >>> action/response/events even when different implementations has varyi= ng >> >>> capabilities. >> >>> >> >>> At the moment it seems like a wild wild west. >> >>> Perhaps IRS can be defined in phases starting with a simpler, limite= d >> >>> version.. >> >>> >> >>> Thanks, >> >>> himanshu >> >>> >> >>> >> >>> -----Original Message----- >> >>> From: irs-discuss-bounces@ietf.org >> >>> [mailto:irs-discuss-bounces@ietf.org] On Behalf Of Alia Atlas >> >>> Sent: Monday, August 13, 2012 8:41 AM >> >>> To: Scott Whyte >> >>> Cc: Thomas Nadeau; Gert Grammel; Alia Atlas; Lenny Giuliano; >> >>> irs-discuss@ietf.org >> >>> Subject: Re: [irs-discuss] IRS comments >> >>> >> >>> ...snip... >> >>> >> >>> On Fri, Aug 10, 2012 at 9:03 PM, Scott Whyte >> >>> wrote: >> >>>> On Fri, Aug 10, 2012 at 5:16 PM, Alia Atlas >> >>>> wrote: >> >>> >> >>>>> I do think it is important to have the RIB as an arbitration >> >>>>> mechanism >> >>>>> on the device. Russ's suggestion that for the RIB sub-interface, >> >>>>> the >> >>>>> IRS agent might communicate logically to an IRS routing process >> >>>>> gives good semantics and interactions. Obviously, implementations >> >>>>> may differ. >> >>>> >> >>>> As long as the arbitration mechanism is reconfigurable by the >> >>>> operator to whatever precedence they want, I agree. Its not clear >> >>>> to me if various RIB implementations treat all proffered routes the >> >>>> same, nor if they store the same meta-data with all protocol source= s. >> >>>> So there needs to be some way for the operator to leverage exposed >> >>>> protocol-specific optimizations, without conflict from the other >> >>>> routing processes, if they so desire. OTOH if it can all be done >> >>>> via static routes, it seems much simpler. :) >> >>> >> >>> Clearly the IRS sub-interface for the RIB needs to introduce/define >> >>> the different precedences; my assumption is that it would be per rou= te with >> >>> a well-defined small set of meta-data. This is part of where having= good >> >>> use-cases will help us understand what behavior is necessary. The s= tatic >> >>> routes do seem like a simpler case to start with. >> >>> >> >>> Alia >> >>> _______________________________________________ >> >>> 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 >> > _______________________________________________ >> > 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 >> >> >> >> > > Return-Path: 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 3B60321F8605 for ; Wed, 15 Aug 2012 15:04:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.559 X-Spam-Level: X-Spam-Status: No, score=-3.559 tagged_above=-999 required=5 tests=[AWL=0.040, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 KRUdOXq2zKo4 for ; Wed, 15 Aug 2012 15:04:44 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 1251A21F8602 for ; Wed, 15 Aug 2012 15:04:41 -0700 (PDT) Received: by iabz21 with SMTP id z21so267387iab.31 for ; Wed, 15 Aug 2012 15:04:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=yegO3hUzEchvCdIh/GLKkeBNjducdxN3fB/3wfSuNng=; b=gaFq5bsf12JxOCkxU670iIZ8gqJ+A7kj2u0ZjsFZYgb/8D3wc8qVu4DIg569NzhZDt atk+ZJkFlCG+rg0YHe3lGHVqnUhdn3yQamj1d731m2q/bTidgWhgLo/YWwvFKnCtMdIi Qtuxw15HWjh71PRNR5viFdssC6aeMiywrCSlHrwZFKycaGLdy9Up7dFqslouM25VaLRZ eg4Y3jCBAKPRZzTGSl2IPMkVzvHfFmu0oNimeKJSF5J4LGu3bksS2nPeJwmPmt6RwgFa zMNKPPSTUaXRiF8IP7KujDBEYZvJs1E+obJ5eBn7KiZc3OGaKbLmveLgrL1LUfsZbNzk sWsA== MIME-Version: 1.0 Received: by 10.42.86.138 with SMTP id u10mr3988636icl.32.1345068280594; Wed, 15 Aug 2012 15:04:40 -0700 (PDT) Received: by 10.50.91.135 with HTTP; Wed, 15 Aug 2012 15:04:40 -0700 (PDT) In-Reply-To: References: <812700A304640D4292205D5E83FC59E1061C211D@p-embx01-eq.jnpr.net> <3512BB31280C39448A9880F61DD54CEB09C07E@xmb-aln-x09.cisco.com> Date: Wed, 15 Aug 2012 18:04:40 -0400 Message-ID: From: Alia Atlas To: "Shah, Himanshu" Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: "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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Aug 2012 22:04:45 -0000 I don't see IRS going below the RIB layer to FIB. Alia On Wed, Aug 15, 2012 at 2:21 PM, Shah, Himanshu wrote: > I will let Ed clarify on what he means by =93controller=94 . > > > > But here is my view of =93application=94, =93controller=94, =93use-case= =94 etc etc, > > > > When an XaaS processes a request it takes into consideration of availabil= ity > of the CPU, memory, application data, cost of power, etc. to instantiate = a > VM on some host machine. > > One additional resource taken into consideration is the availability and/= or > requirement of the network connectivity between the resources > > such as VM, application data, requester, etc. > > > > The provider of XaaS thingy is the application server. > > (Centralized) Network =93Controller(s)=94 knows current state of network > infrastructure and (to be decided how much it) controls member network no= des > using IRS. > > The =93use case=94 here is to be able to dynamically create L2/L2.5/L3 > connectivity with specific TE characteristics between the (perhaps > geographically dispersed) resource points. > > > > In hierarchical fashion: Application server <- (application interface) = -> > Network Controller <- (IRS) -> Network Node > > > > As we heard at IETF, IRS has tentacles in network nodes from BGP policies= , > all the way down to FIBs/LFIBs/ACL. > > > > So we need use cases for which applications would require accessibility t= o =96 > > BGP Policies > > RIB > > LSDB ( I saw an email which talks about reducing IGP to link distribution > protocol and running SPF in centralized network controller) > > LIB > > FIB > > ACL (this is perhaps obvious) > > Etc etc > > > > I broad brushed and simplified a lot here to express my view =96 not sure= if > this jives with others. > > > > /Himanshu > > > > > > > > > > > > > > > > > > From: irs-discuss-bounces@ietf.org [mailto:irs-discuss-bounces@ietf.org] = On > Behalf Of Olen Stokes > Sent: Wednesday, August 15, 2012 1:30 PM > To: Edward Crabbe; Alia Atlas > Cc: David Lake (dlake); irs-discuss@ietf.org > > > Subject: Re: [irs-discuss] IRS comments > > > > Thanks. Can you also give us what you mean by =93controller=94. > > > > Olen > > > > From: Edward Crabbe [mailto:edc@google.com] > Sent: Wednesday, August 15, 2012 1:24 PM > To: Alia Atlas > Cc: David Lake (dlake); Olen Stokes; irs-discuss@ietf.org > Subject: Re: [irs-discuss] IRS comments > > > > s/wg/pre-BOF proto-wg :P/g > > On Wed, Aug 15, 2012 at 10:22 AM, Edward Crabbe wrote: > > +1 Alia. There's been a lot of confusion over this term. Having gone a = few > rounds with folks on this one in other forums, I'll point out that what m= ost > people mean by application (myself included) is some set of control softw= are > (a scheduler, a path optimizer etc) that provides instructions to the > controller, which are in turn translated to the appropriate PDUs. > > > > Having 'end user' applications request/make changes to forwarding state > without an intermediate broker/aggregator acting on their behalf sounds l= ike > a recipe for disaster for operational networks, or, as is more likely, a > quick hike to the protocol grave yard (followed by a long grave-side part= y > :P) for the wg. > > > > my 2c. > > > > On Wed, Aug 15, 2012 at 8:48 AM, Alia Atlas wrote: > > Hi David, > > We do need to clarify what is meant by an application. I would not > expect that real user-land applications would talk directly to routing > devices via IRS. I can see that going through an intermediary. The > IRS abstractions are unlikely to be as high-level as user-land > applications would want and the security and policy issues would get > exciting. > > Clarifying what applications are more in-scope initially is part of > where use-cases will help. Can you write up ones to > categorize/describe your thoughts? > > Alia > > > On Wed, Aug 15, 2012 at 11:40 AM, David Lake (dlake) > wrote: >> As another newbie to this, I have some questions about "application >> vendors." >> >> Who is the target audience here ? That will determine what functionali= ty >> and abstraction of the network we need to expose to that "application." >> >> This presently appears to be a little confused - at least in my mind. T= he >> draft talks very much as if the application we are addressing is an OSS/= BSS >> system, essentially provisioning from the domain owner. >> >> However, linking this to the wider goals of SDN as voiced by >> customers/users at the first Open Network Summit, there appears to be a >> desire for cross-domain and user-land application integration. >> >> At this level - as an example giving a content cache the ability to ensu= re >> delivery of an HD video to an end user - the application will not be >> interested in the underlying topology of the network; it will need to k= now >> that application X can be delivered with parameters Y between reading fr= om >> the content store to delivery to the user's browser. How the stream >> traverses the infrastructure is immaterial. >> >> Are we intending that IRS satisfies BOTH these requirements (i.e. for AL= L >> applications ?), or should we be more prescriptive about which applicati= on >> space we are addressing ? >> >> Thanks >> >> David >> >> -----Original Message----- >> From: irs-discuss-bounces@ietf.org [mailto:irs-discuss-bounces@ietf.org] >> On Behalf Of Alia Atlas >> Sent: Wednesday, August 15, 2012 7:23 AM >> To: Olen Stokes >> Cc: irs-discuss@ietf.org >> Subject: Re: [irs-discuss] IRS comments >> >> I have not specifically heard from application vendors about this. >> My current plan is that we focus on a Use-Cases draft and define within >> that some motivating use-cases that we agree are good first targets. Th= ose >> can drive which subset of functionality we focus on. >> >> More use-cases are, of course, quite welcome. Posting them to the maili= ng >> list is a good first start. Russ White is starting the general use-case= s >> draft based on the three use-cases that he sent to the list. >> >> Alia >> >> On Wed, Aug 15, 2012 at 9:43 AM, Olen Stokes >> wrote: >>> Are there applications vendors out there that already have specific >>> requirements for what this " subset of the data-models for sub-interfac= es" >>> should be? >>> >>> Olen >>> >>> -----Original Message----- >>> From: irs-discuss-bounces@ietf.org >>> [mailto:irs-discuss-bounces@ietf.org] On Behalf Of Alia Atlas >>> Sent: Wednesday, August 15, 2012 9:08 AM >>> To: Shah, Himanshu >>> Cc: Gert Grammel; irs-discuss@ietf.org; Lenny Giuliano; Thomas Nadeau; >>> Alia Atlas; Scott Whyte >>> Subject: Re: [irs-discuss] IRS comments >>> >>> Hi Himanshu, >>> >>> Welcome. I agree that IRS isn't going to spring into being fully >>> formed - I expect that we'll focus on a subset of the data-models for >>> sub-interfaces along with an associated protocol (whether that is a new= one >>> or extending an existing one). >>> >>> Alia >>> >>> On Wed, Aug 15, 2012 at 7:41 AM, Shah, Himanshu wrote= : >>>> Newbie to this discussions list and have read only a last couple of >>>> mails, so pardon the repeat if somebody has already raised the followi= ng as >>>> a concern. >>>> >>>> I realize we are early in IRS architecture definition but one thing to >>>> keep in mind is the user experience. >>>> We need to make sure that exposed interface to >>>> RIB/LFIB/FIB/IGPs/BGP/LSDBs etc etc provide a consistent predictive >>>> action/response/events even when different implementations has varying >>>> capabilities. >>>> >>>> At the moment it seems like a wild wild west. >>>> Perhaps IRS can be defined in phases starting with a simpler, limited >>>> version.. >>>> >>>> Thanks, >>>> himanshu >>>> >>>> >>>> -----Original Message----- >>>> From: irs-discuss-bounces@ietf.org >>>> [mailto:irs-discuss-bounces@ietf.org] On Behalf Of Alia Atlas >>>> Sent: Monday, August 13, 2012 8:41 AM >>>> To: Scott Whyte >>>> Cc: Thomas Nadeau; Gert Grammel; Alia Atlas; Lenny Giuliano; >>>> irs-discuss@ietf.org >>>> Subject: Re: [irs-discuss] IRS comments >>>> >>>> ...snip... >>>> >>>> On Fri, Aug 10, 2012 at 9:03 PM, Scott Whyte wrote= : >>>>> On Fri, Aug 10, 2012 at 5:16 PM, Alia Atlas wrote= : >>>> >>>>>> I do think it is important to have the RIB as an arbitration mechani= sm >>>>>> on the device. Russ's suggestion that for the RIB sub-interface, t= he >>>>>> IRS agent might communicate logically to an IRS routing process >>>>>> gives good semantics and interactions. Obviously, implementations >>>>>> may differ. >>>>> >>>>> As long as the arbitration mechanism is reconfigurable by the >>>>> operator to whatever precedence they want, I agree. Its not clear >>>>> to me if various RIB implementations treat all proffered routes the >>>>> same, nor if they store the same meta-data with all protocol sources. >>>>> So there needs to be some way for the operator to leverage exposed >>>>> protocol-specific optimizations, without conflict from the other >>>>> routing processes, if they so desire. OTOH if it can all be done >>>>> via static routes, it seems much simpler. :) >>>> >>>> Clearly the IRS sub-interface for the RIB needs to introduce/define th= e >>>> different precedences; my assumption is that it would be per route wit= h a >>>> well-defined small set of meta-data. This is part of where having goo= d >>>> use-cases will help us understand what behavior is necessary. The sta= tic >>>> routes do seem like a simpler case to start with. >>>> >>>> Alia >>>> _______________________________________________ >>>> 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 >> _______________________________________________ >> 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 > > > > Return-Path: 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 9650321F862B for ; Wed, 15 Aug 2012 12:50:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7HisAdMmHXXG for ; Wed, 15 Aug 2012 12:50:28 -0700 (PDT) Received: from mail1310.opentransfer.com (mail1310.opentransfer.com [76.162.254.103]) by ietfa.amsl.com (Postfix) with ESMTP id B516321F861C for ; Wed, 15 Aug 2012 12:50:27 -0700 (PDT) Received: (qmail 6186 invoked by uid 399); 15 Aug 2012 19:51:27 -0000 Received: from unknown (HELO ?10.4.3.202?) (pbs:robert@raszuk.net@62.237.32.50) by mail1310.opentransfer.com with ESMTPM; 15 Aug 2012 19:51:27 -0000 X-Originating-IP: 62.237.32.50 Message-ID: <502BFD81.4070809@raszuk.net> Date: Wed, 15 Aug 2012 21:50:25 +0200 From: Robert Raszuk User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: Edward Crabbe References: <812700A304640D4292205D5E83FC59E1061C211D@p-embx01-eq.jnpr.net> <3512BB31280C39448A9880F61DD54CEB09C07E@xmb-aln-x09.cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Alia Atlas , Olen Stokes , "David Lake \(dlake\)" , "irs-discuss@ietf.org" Subject: Re: [irs-discuss] IRS comments X-BeenThere: irs-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: robert@raszuk.net List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Aug 2012 19:50:29 -0000 > It could just as easily describe a PCE. PCE could be a controller just talking to headends and asking them to signal LSP X with RSVP-TE or it could talk to all head, tail and via nodes and actually program the forwarding label entries. I am observing that IRS framework is more of the former case rather then the latter in general. However if this is the former then I am a bit not clear what value it is to deliver if we compare it with current statefull PCE efforts ;) Best, R. Return-Path: 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 7395D21E8034 for ; Wed, 15 Aug 2012 11:57:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.837 X-Spam-Level: X-Spam-Status: No, score=-102.837 tagged_above=-999 required=5 tests=[AWL=0.139, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sfFWlgMOj3rD for ; Wed, 15 Aug 2012 11:57:32 -0700 (PDT) Received: from mail-gh0-f172.google.com (mail-gh0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id C450921F8702 for ; Wed, 15 Aug 2012 11:57:31 -0700 (PDT) Received: by ghbg16 with SMTP id g16so2326904ghb.31 for ; Wed, 15 Aug 2012 11:57:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=k4N6X4DgWySkURXbXvTD2WQKZATAIdxBPuXG1FmwmGI=; b=GO4Ixjo7epo6gqopn36u10GcrMwl0mP/04vaFAe7cL2hJcF2F2cnOO25fi4tgXfKCO A3whD4B39im66fnnQrOjlQY14WLWiWoI8BYxFPhMtMy8k9NIdJ9PoxsxRbsIsY0ARH0d wBWoCWG3hUnK/h+Nss8nLAmu5PC/dqjEnnamkqHe68ViF+sFRgokOCUJpxadQPEUBkgm SnnoS0/BpsuVept1OlNbswIBbCVJXf21kCbICksyIGixs6riWFf6XIPHiqHThYxCTlrp hLaH/3kif9om4KZKnvPN2wSQc+mh2uKvfn8Ffw+YYOSMDYNQIG76NrG4nWqYUN8serru c0eQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=k4N6X4DgWySkURXbXvTD2WQKZATAIdxBPuXG1FmwmGI=; b=hZeIVkMPhTBo3lLktmO0zMZOyluyHJ48cN8Ou0wewXnKpc+EzLe9YBRY+kxyHrmgMp EujbzPHffDDopQ08Xm4a6Ddrz9Alx/+fUnue4LN3eiRFlG6VMtzwivmb+VB4OAWc5a4H JHJ1yZO3tF/dAru/SjjxX5+FosCreX6uPM6+sNiuyWZZ2ZycHR0JUN8bAu76JYjglSek fm4qxq1MWjh5IwQ3ICHCScCmdUmAXNIlj6wusG5w9/vXrJoYXlvnP6+xCFgWpEyqBwhc Cp3KPQDB4ea7ESb5D5trHKWo92D7WyFkXwMZVjQO7+tmbwl9I6zcvJu/bX6dlfaw2OLN 9fww== Received: by 10.50.10.197 with SMTP id k5mr19623245igb.39.1345057050677; Wed, 15 Aug 2012 11:57:30 -0700 (PDT) Received: by 10.50.10.197 with SMTP id k5mr19623206igb.39.1345057049862; Wed, 15 Aug 2012 11:57:29 -0700 (PDT) MIME-Version: 1.0 Received: by 10.50.237.67 with HTTP; Wed, 15 Aug 2012 11:56:49 -0700 (PDT) In-Reply-To: References: <812700A304640D4292205D5E83FC59E1061C211D@p-embx01-eq.jnpr.net> <3512BB31280C39448A9880F61DD54CEB09C07E@xmb-aln-x09.cisco.com> From: Edward Crabbe Date: Wed, 15 Aug 2012 11:56:49 -0700 Message-ID: To: Olen Stokes Content-Type: multipart/alternative; boundary=14dae9340929a8e16e04c7527f05 X-System-Of-Record: true X-Gm-Message-State: ALoCoQmJIJG+yoVSKlOrmAXH3dYtPgOKGglorihWpyez5Q/XlIXNYds76omYb3YRfAoHrnWOcL1tTJmYlZXJFFUEAM6911ZjN7biEULDEddMDLytkU54d3UxDTbEeGer6kIeup9STVkzYJIWR8uqelOJv/vGQUBqCznS9lfW+4/EA/L4MD7H0fQSNyjgUAQVFJd10qynTHIj Cc: "irs-discuss@ietf.org" , "David Lake \(dlake\)" , Alia Atlas 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Aug 2012 18:57:33 -0000 --14dae9340929a8e16e04c7527f05 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Olen, Nope, I'm using it in a very general sense. It could just as easily describe a PCE. On Wed, Aug 15, 2012 at 11:38 AM, Olen Stokes wrote: > I understand that. Sorry, I should have been more specific. I am trying > to understand if usage of the word =93controller=94 on this list implies = a > reference to any existing description such as =93Open Flow Controller=94.= **** > > ** ** > > Olen**** > > ** ** > > *From:* Edward Crabbe [mailto:edc@google.com] > *Sent:* Wednesday, August 15, 2012 2:20 PM > *To:* Olen Stokes > *Cc:* Alia Atlas; David Lake (dlake); irs-discuss@ietf.org > > *Subject:* Re: [irs-discuss] IRS comments**** > > ** ** > > The software (interacting with the 'applications' and) generating the > actual PDUs understood by the NEs. **** > > ** ** > > On Wed, Aug 15, 2012 at 10:30 AM, Olen Stokes > wrote:**** > > Thanks. Can you also give us what you mean by =93controller=94. **** > > **** > > Olen**** > > **** > > *From:* Edward Crabbe [mailto:edc@google.com] > *Sent:* Wednesday, August 15, 2012 1:24 PM > *To:* Alia Atlas > *Cc:* David Lake (dlake); Olen Stokes; irs-discuss@ietf.org**** > > > *Subject:* Re: [irs-discuss] IRS comments**** > > **** > > s/wg/pre-BOF proto-wg :P/g **** > > On Wed, Aug 15, 2012 at 10:22 AM, Edward Crabbe wrote:**= * > * > > +1 Alia. There's been a lot of confusion over this term. Having gone a > few rounds with folks on this one in other forums, I'll point out that wh= at > most people mean by application (myself included) is some set of control > software (a scheduler, a path optimizer etc) that provides instructions = to > the controller, which are in turn translated to the appropriate PDUs.**** > > **** > > Having 'end user' applications request/make changes to forwarding state > without an intermediate broker/aggregator acting on their behalf sounds > like a recipe for disaster for operational networks, or, as is more likel= y, > a quick hike to the protocol grave yard (followed by a long grave-side > party :P) for the wg. **** > > **** > > my 2c. **** > > **** > > On Wed, Aug 15, 2012 at 8:48 AM, Alia Atlas wrote:***= * > > Hi David, > > We do need to clarify what is meant by an application. I would not > expect that real user-land applications would talk directly to routing > devices via IRS. I can see that going through an intermediary. The > IRS abstractions are unlikely to be as high-level as user-land > applications would want and the security and policy issues would get > exciting. > > Clarifying what applications are more in-scope initially is part of > where use-cases will help. Can you write up ones to > categorize/describe your thoughts? > > Alia**** > > > On Wed, Aug 15, 2012 at 11:40 AM, David Lake (dlake) > wrote: > > As another newbie to this, I have some questions about "application > vendors." > > > > Who is the target audience here ? That will determine what > functionality and abstraction of the network we need to expose to that > "application." > > > > This presently appears to be a little confused - at least in my mind. > The draft talks very much as if the application we are addressing is an > OSS/BSS system, essentially provisioning from the domain owner. > > > > However, linking this to the wider goals of SDN as voiced by > customers/users at the first Open Network Summit, there appears to be a > desire for cross-domain and user-land application integration. > > > > At this level - as an example giving a content cache the ability to > ensure delivery of an HD video to an end user - the application will not = be > interested in the underlying topology of the network; it will need to kn= ow > that application X can be delivered with parameters Y between reading fro= m > the content store to delivery to the user's browser. How the stream > traverses the infrastructure is immaterial. > > > > Are we intending that IRS satisfies BOTH these requirements (i.e. for > ALL applications ?), or should we be more prescriptive about which > application space we are addressing ? > > > > Thanks > > > > David > > > > -----Original Message----- > > From: irs-discuss-bounces@ietf.org [mailto:irs-discuss-bounces@ietf.org= ] > On Behalf Of Alia Atlas > > Sent: Wednesday, August 15, 2012 7:23 AM > > To: Olen Stokes > > Cc: irs-discuss@ietf.org > > Subject: Re: [irs-discuss] IRS comments > > > > I have not specifically heard from application vendors about this. > > My current plan is that we focus on a Use-Cases draft and define within > that some motivating use-cases that we agree are good first targets. Tho= se > can drive which subset of functionality we focus on. > > > > More use-cases are, of course, quite welcome. Posting them to the > mailing list is a good first start. Russ White is starting the general > use-cases draft based on the three use-cases that he sent to the list. > > > > Alia > > > > On Wed, Aug 15, 2012 at 9:43 AM, Olen Stokes < > ostokes@extremenetworks.com> wrote: > >> Are there applications vendors out there that already have specific > requirements for what this " subset of the data-models for sub-interfaces= " > should be? > >> > >> Olen > >> > >> -----Original Message----- > >> From: irs-discuss-bounces@ietf.org > >> [mailto:irs-discuss-bounces@ietf.org] On Behalf Of Alia Atlas > >> Sent: Wednesday, August 15, 2012 9:08 AM > >> To: Shah, Himanshu > >> Cc: Gert Grammel; irs-discuss@ietf.org; Lenny Giuliano; Thomas Nadeau; > >> Alia Atlas; Scott Whyte > >> Subject: Re: [irs-discuss] IRS comments > >> > >> Hi Himanshu, > >> > >> Welcome. I agree that IRS isn't going to spring into being fully > >> formed - I expect that we'll focus on a subset of the data-models for > sub-interfaces along with an associated protocol (whether that is a new o= ne > or extending an existing one). > >> > >> Alia > >> > >> On Wed, Aug 15, 2012 at 7:41 AM, Shah, Himanshu > wrote: > >>> Newbie to this discussions list and have read only a last couple of > mails, so pardon the repeat if somebody has already raised the following = as > a concern. > >>> > >>> I realize we are early in IRS architecture definition but one thing t= o > keep in mind is the user experience. > >>> We need to make sure that exposed interface to > >>> RIB/LFIB/FIB/IGPs/BGP/LSDBs etc etc provide a consistent predictive > action/response/events even when different implementations has varying > capabilities. > >>> > >>> At the moment it seems like a wild wild west. > >>> Perhaps IRS can be defined in phases starting with a simpler, limited > version.. > >>> > >>> Thanks, > >>> himanshu > >>> > >>> > >>> -----Original Message----- > >>> From: irs-discuss-bounces@ietf.org > >>> [mailto:irs-discuss-bounces@ietf.org] On Behalf Of Alia Atlas > >>> Sent: Monday, August 13, 2012 8:41 AM > >>> To: Scott Whyte > >>> Cc: Thomas Nadeau; Gert Grammel; Alia Atlas; Lenny Giuliano; > >>> irs-discuss@ietf.org > >>> Subject: Re: [irs-discuss] IRS comments > >>> > >>> ...snip... > >>> > >>> On Fri, Aug 10, 2012 at 9:03 PM, Scott Whyte > wrote: > >>>> On Fri, Aug 10, 2012 at 5:16 PM, Alia Atlas > wrote: > >>> > >>>>> I do think it is important to have the RIB as an arbitration > mechanism > >>>>> on the device. Russ's suggestion that for the RIB sub-interface, > the > >>>>> IRS agent might communicate logically to an IRS routing process > >>>>> gives good semantics and interactions. Obviously, implementations > >>>>> may differ. > >>>> > >>>> As long as the arbitration mechanism is reconfigurable by the > >>>> operator to whatever precedence they want, I agree. Its not clear > >>>> to me if various RIB implementations treat all proffered routes the > >>>> same, nor if they store the same meta-data with all protocol sources= . > >>>> So there needs to be some way for the operator to leverage exposed > >>>> protocol-specific optimizations, without conflict from the other > >>>> routing processes, if they so desire. OTOH if it can all be done > >>>> via static routes, it seems much simpler. :) > >>> > >>> Clearly the IRS sub-interface for the RIB needs to introduce/define > the different precedences; my assumption is that it would be per route wi= th > a well-defined small set of meta-data. This is part of where having good > use-cases will help us understand what behavior is necessary. The static > routes do seem like a simpler case to start with. > >>> > >>> Alia > >>> _______________________________________________ > >>> 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 > > _______________________________________________ > > 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**** > > **** > > **** > > ** ** > --14dae9340929a8e16e04c7527f05 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
Olen,

Nope, I'm using it in a very general sen= se. =A0It could just as easily describe a PCE. =A0=A0

On Wed, Aug 15, 2012 at 11:38 AM, Olen Stokes <osto= kes@extremenetworks.com> wrote:

I understand = that.=A0 Sorry, I should have been more specific.=A0 I am trying to underst= and if usage of the word =93controller=94 on this list implies a reference = to any existing description such as =93Open Flow Controller=94.

=A0<= /p>

Olen

=A0<= /p>

From: Edwar= d Crabbe [mailto:edc@go= ogle.com]
Sent: Wednesday, August 15, 2012 2:20 PM
To: Olen StokesCc: Alia Atlas; David Lake (dlake); irs-discuss@ietf.org


Subject: Re: [irs-discuss] IRS comments

=A0

=

The software (interacting with the 'applications= ' and) generating the actual PDUs understood by the NEs.=A0

=A0

On Wed, Aug 15, 2012 at 10:30 AM, Olen Stokes <ostokes@extremenetworks.com&g= t; wrote:

Thanks.=A0 Can = you also give us what you mean by =93controller=94.=A0

=A0

Olen

=A0<= /p>

From: Edwar= d Crabbe [mailto:edc@go= ogle.com]
Sent: Wednesday, August 15, 2012 1:24 PM
To: Alia AtlasCc: David Lake (dlake); Olen Stokes; irs-discuss@ietf.org


Subject: Re: [irs-discuss] IRS = comments

=A0<= u>

s/wg= /pre-BOF proto-wg :P/g =A0

On Wed, Aug 15, 2012 at 10:22 AM, Edward Crabbe= <edc@google.com= > wrote:

+1 Alia. =A0There's= been a lot of confusion over this term. =A0Having gone a few rounds with f= olks on this one in other forums, I'll point out that what most people = mean by application (myself included) is some set of control software (a sc= heduler, a path optimizer etc) =A0that provides instructions to the control= ler, which are in turn translated to the appropriate PDUs.

=A0

Having 'end user' applications request/make changes to forw= arding state without an intermediate broker/aggregator acting on their beha= lf sounds like a recipe for disaster for operational networks, or, as is mo= re likely, a quick hike to the protocol grave yard (followed by a long grav= e-side party :P) for the wg. =A0

=A0

my 2c.=A0

=A0

On Wed, Aug 15,= 2012 at 8:48 AM, Alia Atlas <akatlas@gmail.com> wrote:

Hi David,

We do need to clarify what is meant= by an application. =A0I would not
expect that real user-land applicatio= ns would talk directly to routing
devices via IRS. =A0I can see that goi= ng through an intermediary. =A0The
IRS abstractions are unlikely to be as high-level as user-land
applicati= ons would want and the security and policy issues would get
exciting.
Clarifying what applications are more in-scope initially is part of where use-cases will help. =A0Can you write up ones to
categorize/descri= be your thoughts?

Alia


On Wed, Aug 15, 2012 at 11:40= AM, David Lake (dlake) <dlake@cisco.com> wrote:
> As another newbie to this, I have some questions about "applicati= on vendors."
>
> Who is the target audience here ? =A0 Tha= t will determine what functionality and abstraction of the network we need = to expose to that "application."
>
> This presently appears to be a little confused - at least in m= y mind. =A0The draft talks very much as if the application we are addressin= g is an OSS/BSS system, essentially provisioning from the domain owner.
>
> However, linking this to the wider goals of SDN as voiced by c= ustomers/users at the first Open Network Summit, there appears to be a desi= re for cross-domain and user-land application integration.
>
> At this level - as an example giving a content cache the ability to en= sure delivery of an HD video to an end user - the application will not be i= nterested in the underlying topology of the network; it will =A0need to kno= w that application X can be delivered with parameters Y between reading fro= m the content store to delivery to the user's browser. =A0 How the stre= am traverses the infrastructure is immaterial.
>
> Are we intending that IRS satisfies BOTH these requirements (i= .e. for ALL applications ?), or should we be more prescriptive about which = application space we are addressing ?
>
> Thanks
>
> David
>
> -----Original Message-----
> From: irs-discuss-boun= ces@ietf.org [mailto:irs-discuss-bounces@ietf.org] On Behalf Of Alia Atlas > Sent: Wednesday, August 15, 2012 7:23 AM
> To: Olen Stokes
&g= t; Cc: irs-discus= s@ietf.org
> Subject: Re: [irs-discuss] IRS comments
>
> I have not specifically heard from application vendors about this.
> My current plan is that we focus on a Use-Cases draft and define withi= n that some motivating use-cases that we agree are good first targets. =A0T= hose can drive which subset of functionality we focus on.
>
> M= ore use-cases are, of course, quite welcome. =A0Posting them to the mailing= list is a good first start. =A0Russ White is starting the general use-case= s draft based on the three use-cases that he sent to the list.
>
> Alia
>
> On Wed, Aug 15, 2012 at 9:43 AM, Olen Sto= kes <os= tokes@extremenetworks.com> wrote:
>> Are there applications= vendors out there that already have specific requirements for what this &q= uot; subset of the data-models for sub-interfaces" =A0should be?
>>
>> Olen
>>
>> -----Original Message----= -
>> From: irs-discuss-bounces@ietf.org
>> [mailto:irs-discuss-bounces= @ietf.org] On Behalf Of Alia Atlas
>> Sent: Wednesday, August 15, 2012 9:08 AM
>> To: Shah, Him= anshu
>> Cc: Gert Grammel; irs-discuss@ietf.org; Lenny Giuliano; Thomas Nadeau;=
>> Alia Atlas; Scott Whyte
>> Subject: Re: [irs-discuss] IRS= comments
>>
>> Hi Himanshu,
>>
>> Welc= ome. =A0 I agree that IRS isn't going to spring into being fully
>> formed - I expect that we'll focus on a subset of the data-mod= els for sub-interfaces along with an associated protocol (whether that is a= new one or extending an existing one).
>>
>> Alia
>>
>> On Wed, Aug 15, 2012 at 7= :41 AM, Shah, Himanshu <hshah@ciena.com> wrote:
>>> Newbie to this discussi= ons list and have read only a last couple of mails, so pardon the repeat if= somebody has already raised the following as a concern.
>>>
>>> I realize we are early in IRS architecture def= inition but one thing to keep in mind is the user experience.
>>&g= t; We need to make sure that exposed interface to
>>> RIB/LFIB/= FIB/IGPs/BGP/LSDBs etc etc =A0provide a consistent predictive action/respon= se/events even when different implementations has varying capabilities.
>>>
>>> At the moment it seems like a wild wild west.<= br>>>> Perhaps IRS can be defined in phases starting with a simple= r, limited version..
>>>
>>> Thanks,
>>>= ; himanshu
>>>
>>>
>>> -----Original Message-----
= >>> From: irs-discuss-bounces@ietf.org
>>> [mailto:irs-discuss-bou= nces@ietf.org] On Behalf Of Alia Atlas
>>> Sent: Monday, August 13, 2012 8:41 AM
>>> To: Scot= t Whyte
>>> Cc: Thomas Nadeau; Gert Grammel; Alia Atlas; Lenny = Giuliano;
>>> irs-discuss@ietf.org
>>> Subject: Re: [irs-discuss] IRS comments
>>>
>= ;>> ...snip...
>>>
>>> On Fri, Aug 10, 2012 a= t 9:03 PM, Scott Whyte <swhyte@google.com> wrote:
>>>> On Fri, Aug 10, 2012 at 5:16 PM, Alia Atlas <akatlas@gmail.com> wrot= e:
>>>
>>>>> I do think it is important to ha= ve the RIB as an arbitration mechanism
>>>>> on the device. =A0 Russ's suggestion that for the = RIB sub-interface, the
>>>>> IRS agent might communicate = logically to an IRS routing process
>>>>> gives good sema= ntics and interactions. =A0Obviously, implementations
>>>>> may differ.
>>>>
>>>> As= long as the arbitration mechanism is reconfigurable by the
>>>= > operator to whatever precedence they want, I agree. =A0Its not clear >>>> to me if various RIB implementations treat all proffered r= outes the
>>>> same, nor if they store the same meta-data wi= th all protocol sources.
>>>> So there needs to be some way = for the operator to leverage exposed
>>>> protocol-specific optimizations, without conflict from the= other
>>>> routing processes, if they so desire. =A0OTOH if= it can all be done
>>>> via static routes, it seems much si= mpler. :)
>>>
>>> Clearly the IRS sub-interface for the RIB need= s to introduce/define the different precedences; my assumption is that it w= ould be per route with a well-defined small set of meta-data. =A0This is pa= rt of where having good use-cases will help us understand what behavior is = necessary. =A0The static =A0routes do seem like a simpler case to start wit= h.
>>>
>>> Alia
>>> _________________________= ______________________
>>> irs-discuss mailing list
>>= > irs-discuss@= ietf.org
>>> https://www.ietf.org/mailman/listinfo/irs-discuss
= >> _______________________________________________
>> irs-di= scuss mailing list
>> irs-disc= uss@ietf.org
>> https://www.ietf.org/mailman/listinfo/irs= -discuss
> _______________________________________________
> irs-discuss ma= iling list
> irs-discuss@ietf.org
> https://www.ietf.org/mailman/listin= fo/irs-discuss
_______________________________________________
irs-discuss mailing list=
irs-discuss@i= etf.org
https://www.ietf.org/mailman/listinfo/irs-discuss

=A0

<= /div>

=A0

=A0


--14dae9340929a8e16e04c7527f05-- Return-Path: 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 9E42E21F8733 for ; Wed, 15 Aug 2012 11:38:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tlY6WJRMRFr5 for ; Wed, 15 Aug 2012 11:38:03 -0700 (PDT) Received: from ussc-casht-p1.extremenetworks.com (ussc-casht-p2.extremenetworks.com [207.179.9.62]) by ietfa.amsl.com (Postfix) with ESMTP id 8987621F870F for ; Wed, 15 Aug 2012 11:38:03 -0700 (PDT) Received: from USEXCHANGE.corp.extremenetworks.com ([10.0.4.74]) by ussc-casht-p2.corp.extremenetworks.com ([10.255.181.88]) with mapi; Wed, 15 Aug 2012 11:38:03 -0700 From: Olen Stokes To: Edward Crabbe Date: Wed, 15 Aug 2012 11:38:01 -0700 Thread-Topic: [irs-discuss] IRS comments Thread-Index: Ac17ErPTZN1QUmmCSvK6zfhaIXCEjAAATRUg Message-ID: References: <812700A304640D4292205D5E83FC59E1061C211D@p-embx01-eq.jnpr.net> <3512BB31280C39448A9880F61DD54CEB09C07E@xmb-aln-x09.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_A3C4E51A53661B4EBEE7C5F5E6FCDEB5025AB94FE8E4USEXCHANGEc_" MIME-Version: 1.0 Cc: "irs-discuss@ietf.org" , "David Lake \(dlake\)" , Alia Atlas 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Aug 2012 18:38:06 -0000 --_000_A3C4E51A53661B4EBEE7C5F5E6FCDEB5025AB94FE8E4USEXCHANGEc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I understand that. Sorry, I should have been more specific. I am trying t= o understand if usage of the word "controller" on this list implies a refer= ence to any existing description such as "Open Flow Controller". Olen From: Edward Crabbe [mailto:edc@google.com] Sent: Wednesday, August 15, 2012 2:20 PM To: Olen Stokes Cc: Alia Atlas; David Lake (dlake); irs-discuss@ietf.org Subject: Re: [irs-discuss] IRS comments The software (interacting with the 'applications' and) generating the actua= l PDUs understood by the NEs. On Wed, Aug 15, 2012 at 10:30 AM, Olen Stokes > wrote: Thanks. Can you also give us what you mean by "controller". Olen From: Edward Crabbe [mailto:edc@google.com] Sent: Wednesday, August 15, 2012 1:24 PM To: Alia Atlas Cc: David Lake (dlake); Olen Stokes; irs-discuss@ietf.org Subject: Re: [irs-discuss] IRS comments s/wg/pre-BOF proto-wg :P/g On Wed, Aug 15, 2012 at 10:22 AM, Edward Crabbe > wrote: +1 Alia. There's been a lot of confusion over this term. Having gone a fe= w rounds with folks on this one in other forums, I'll point out that what m= ost people mean by application (myself included) is some set of control sof= tware (a scheduler, a path optimizer etc) that provides instructions to th= e controller, which are in turn translated to the appropriate PDUs. Having 'end user' applications request/make changes to forwarding state wit= hout an intermediate broker/aggregator acting on their behalf sounds like a= recipe for disaster for operational networks, or, as is more likely, a qui= ck hike to the protocol grave yard (followed by a long grave-side party :P)= for the wg. my 2c. On Wed, Aug 15, 2012 at 8:48 AM, Alia Atlas > wrote: Hi David, We do need to clarify what is meant by an application. I would not expect that real user-land applications would talk directly to routing devices via IRS. I can see that going through an intermediary. The IRS abstractions are unlikely to be as high-level as user-land applications would want and the security and policy issues would get exciting. Clarifying what applications are more in-scope initially is part of where use-cases will help. Can you write up ones to categorize/describe your thoughts? Alia On Wed, Aug 15, 2012 at 11:40 AM, David Lake (dlake) > wrote: > As another newbie to this, I have some questions about "application vendo= rs." > > Who is the target audience here ? That will determine what functionalit= y and abstraction of the network we need to expose to that "application." > > This presently appears to be a little confused - at least in my mind. Th= e draft talks very much as if the application we are addressing is an OSS/B= SS system, essentially provisioning from the domain owner. > > However, linking this to the wider goals of SDN as voiced by customers/us= ers at the first Open Network Summit, there appears to be a desire for cros= s-domain and user-land application integration. > > At this level - as an example giving a content cache the ability to ensur= e delivery of an HD video to an end user - the application will not be inte= rested in the underlying topology of the network; it will need to know tha= t application X can be delivered with parameters Y between reading from the= content store to delivery to the user's browser. How the stream traverse= s the infrastructure is immaterial. > > Are we intending that IRS satisfies BOTH these requirements (i.e. for ALL= applications ?), or should we be more prescriptive about which application= space we are addressing ? > > Thanks > > David > > -----Original Message----- > From: irs-discuss-bounces@ietf.org [= mailto:irs-discuss-bounces@ietf.org] O= n Behalf Of Alia Atlas > Sent: Wednesday, August 15, 2012 7:23 AM > To: Olen Stokes > Cc: irs-discuss@ietf.org > Subject: Re: [irs-discuss] IRS comments > > I have not specifically heard from application vendors about this. > My current plan is that we focus on a Use-Cases draft and define within t= hat some motivating use-cases that we agree are good first targets. Those = can drive which subset of functionality we focus on. > > More use-cases are, of course, quite welcome. Posting them to the mailin= g list is a good first start. Russ White is starting the general use-cases= draft based on the three use-cases that he sent to the list. > > Alia > > On Wed, Aug 15, 2012 at 9:43 AM, Olen Stokes > wrote: >> Are there applications vendors out there that already have specific requ= irements for what this " subset of the data-models for sub-interfaces" sho= uld be? >> >> Olen >> >> -----Original Message----- >> From: irs-discuss-bounces@ietf.org >> [mailto:irs-discuss-bounces@ietf.org] On Behalf Of Alia Atlas >> Sent: Wednesday, August 15, 2012 9:08 AM >> To: Shah, Himanshu >> Cc: Gert Grammel; irs-discuss@ietf.org; Len= ny Giuliano; Thomas Nadeau; >> Alia Atlas; Scott Whyte >> Subject: Re: [irs-discuss] IRS comments >> >> Hi Himanshu, >> >> Welcome. I agree that IRS isn't going to spring into being fully >> formed - I expect that we'll focus on a subset of the data-models for su= b-interfaces along with an associated protocol (whether that is a new one o= r extending an existing one). >> >> Alia >> >> On Wed, Aug 15, 2012 at 7:41 AM, Shah, Himanshu > wrote: >>> Newbie to this discussions list and have read only a last couple of mai= ls, so pardon the repeat if somebody has already raised the following as a = concern. >>> >>> I realize we are early in IRS architecture definition but one thing to = keep in mind is the user experience. >>> We need to make sure that exposed interface to >>> RIB/LFIB/FIB/IGPs/BGP/LSDBs etc etc provide a consistent predictive ac= tion/response/events even when different implementations has varying capabi= lities. >>> >>> At the moment it seems like a wild wild west. >>> Perhaps IRS can be defined in phases starting with a simpler, limited v= ersion.. >>> >>> Thanks, >>> himanshu >>> >>> >>> -----Original Message----- >>> From: irs-discuss-bounces@ietf.org >>> [mailto:irs-discuss-bounces@ietf.org] On Behalf Of Alia Atlas >>> Sent: Monday, August 13, 2012 8:41 AM >>> To: Scott Whyte >>> Cc: Thomas Nadeau; Gert Grammel; Alia Atlas; Lenny Giuliano; >>> irs-discuss@ietf.org >>> Subject: Re: [irs-discuss] IRS comments >>> >>> ...snip... >>> >>> On Fri, Aug 10, 2012 at 9:03 PM, Scott Whyte > wrote: >>>> On Fri, Aug 10, 2012 at 5:16 PM, Alia Atlas > wrote: >>> >>>>> I do think it is important to have the RIB as an arbitration mechanis= m >>>>> on the device. Russ's suggestion that for the RIB sub-interface, th= e >>>>> IRS agent might communicate logically to an IRS routing process >>>>> gives good semantics and interactions. Obviously, implementations >>>>> may differ. >>>> >>>> As long as the arbitration mechanism is reconfigurable by the >>>> operator to whatever precedence they want, I agree. Its not clear >>>> to me if various RIB implementations treat all proffered routes the >>>> same, nor if they store the same meta-data with all protocol sources. >>>> So there needs to be some way for the operator to leverage exposed >>>> protocol-specific optimizations, without conflict from the other >>>> routing processes, if they so desire. OTOH if it can all be done >>>> via static routes, it seems much simpler. :) >>> >>> Clearly the IRS sub-interface for the RIB needs to introduce/define the= different precedences; my assumption is that it would be per route with a = well-defined small set of meta-data. This is part of where having good use= -cases will help us understand what behavior is necessary. The static rou= tes do seem like a simpler case to start with. >>> >>> Alia >>> _______________________________________________ >>> 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 > _______________________________________________ > 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 --_000_A3C4E51A53661B4EBEE7C5F5E6FCDEB5025AB94FE8E4USEXCHANGEc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I underst= and that.  Sorry, I should have been more specific.  I am trying = to understand if usage of the word “controller” on this list im= plies a reference to any existing description such as “Open Flow Cont= roller”.

 =

Olen

 

From: Edward Crabbe [mailto:edc@google.com]
Sent: Wednesday, August = 15, 2012 2:20 PM
To: Olen Stokes
Cc: Alia Atlas; David = Lake (dlake); irs-discuss@ietf.org
Subject: Re: [irs-discuss] IRS= comments

 

The software (interacting with the 'applications' and) g= enerating the actual PDUs understood by the NEs. 

<= p class=3DMsoNormal> 

On Wed, = Aug 15, 2012 at 10:30 AM, Olen Stokes <ostokes@extremenetworks.com> wrote:<= o:p>

Thanks.  Can you also give us wh= at you mean by “controller”. 

 

Olen

 

From: Edward Crabbe [mailto= :edc@google.com] Sent: Wednesday, August 15, 2012 1:24 PM
To: Alia Atlas<= br>Cc: David Lake (dlake); Olen Stokes; irs-discuss@ietf.org


Subject: Re: [irs-discuss] IRS c= omments

 

s/= wg/pre-BOF proto-wg :P/g  

On Wed, Aug 15, 2= 012 at 10:22 AM, Edward Crabbe <edc@google.com> wrote:

+1 Alia. &nb= sp;There's been a lot of confusion over this term.  Having gone a few = rounds with folks on this one in other forums, I'll point out that what mos= t people mean by application (myself included) is some set of control softw= are (a scheduler, a path optimizer etc)  that provides instructions to= the controller, which are in turn translated to the appropriate PDUs.=

 

Having 'end us= er' applications request/make changes to forwarding state without an interm= ediate broker/aggregator acting on their behalf sounds like a recipe for di= saster for operational networks, or, as is more likely, a quick hike to the= protocol grave yard (followed by a long grave-side party :P) for the wg. &= nbsp;

 

my 2c. 

 <= /p>

On Wed, Aug 15, 2012 at 8:48 AM, Alia Atlas <akatlas@gmail.com> wrote:=

Hi David,

We do need to clarify what is meant = by an application.  I would not
expect that real user-land applicat= ions would talk directly to routing
devices via IRS.  I can see tha= t going through an intermediary.  The
IRS abstractions are unlikely= to be as high-level as user-land
applications would want and the securi= ty and policy issues would get
exciting.

Clarifying what applicat= ions are more in-scope initially is part of
where use-cases will help. &= nbsp;Can you write up ones to
categorize/describe your thoughts?

Alia

<= br>On Wed, Aug 15, 2012 at 11:40 AM, David Lake (dlake) <dlake@cisco.com> wrote:
>= ; As another newbie to this, I have some questions about "application = vendors."
>
> Who is the target audience here ?   Tha= t will determine what functionality and abstraction of the network we need = to expose to that "application."
>
> This presently a= ppears to be a little confused - at least in my mind.  The draft talks= very much as if the application we are addressing is an OSS/BSS system, es= sentially provisioning from the domain owner.
>
> However, link= ing this to the wider goals of SDN as voiced by customers/users at the firs= t Open Network Summit, there appears to be a desire for cross-domain and us= er-land application integration.
>
> At this level - as an exam= ple giving a content cache the ability to ensure delivery of an HD video to= an end user - the application will not be interested in the underlying top= ology of the network; it will  need to know that application X can be = delivered with parameters Y between reading from the content store to deliv= ery to the user's browser.   How the stream traverses the infrastructu= re is immaterial.
>
> Are we intending that IRS satisfies BOTH = these requirements (i.e. for ALL applications ?), or should we be more pres= criptive about which application space we are addressing ?
>
> = Thanks
>
> David
>
> -----Original Message-----
= > From: irs-discuss-bounces@ietf.org [mailto:irs-discuss-bounces@ietf.org] On Beha= lf Of Alia Atlas
> Sent: Wednesday, August 15, 2012 7:23 AM
> T= o: Olen Stokes
> Cc: irs-discuss@ietf.org
> Subject: Re: [irs-discuss] IRS= comments
>
> I have not specifically heard from application ve= ndors about this.
> My current plan is that we focus on a Use-Cases d= raft and define within that some motivating use-cases that we agree are goo= d first targets.  Those can drive which subset of functionality we foc= us on.
>
> More use-cases are, of course, quite welcome.  = Posting them to the mailing list is a good first start.  Russ White is= starting the general use-cases draft based on the three use-cases that he = sent to the list.
>
> Alia
>
> On Wed, Aug 15, 2012= at 9:43 AM, Olen Stokes <ostokes@extremenetworks.com> wrote:
>> A= re there applications vendors out there that already have specific requirem= ents for what this " subset of the data-models for sub-interfaces"= ;  should be?
>>
>> Olen
>>
>> ---= --Original Message-----
>> From: irs-discuss-bounces@ietf.org
>&g= t; [mailto:irs-discuss-bounces@ietf.org] On Behalf Of Alia Atlas
>> Sen= t: Wednesday, August 15, 2012 9:08 AM
>> To: Shah, Himanshu
>= ;> Cc: Gert Grammel; irs-discuss@ietf.org; Lenny Giuliano; Thomas Nadeau;
>>= Alia Atlas; Scott Whyte
>> Subject: Re: [irs-discuss] IRS comment= s
>>
>> Hi Himanshu,
>>
>> Welcome. &nb= sp; I agree that IRS isn't going to spring into being fully
>> for= med - I expect that we'll focus on a subset of the data-models for sub-inte= rfaces along with an associated protocol (whether that is a new one or exte= nding an existing one).
>>
>> Alia
>>
>>= ; On Wed, Aug 15, 2012 at 7:41 AM, Shah, Himanshu <hshah@ciena.com> wrote:
>>&= gt; Newbie to this discussions list and have read only a last couple of mai= ls, so pardon the repeat if somebody has already raised the following as a = concern.
>>>
>>> I realize we are early in IRS arch= itecture definition but one thing to keep in mind is the user experience.>>> We need to make sure that exposed interface to
>>&g= t; RIB/LFIB/FIB/IGPs/BGP/LSDBs etc etc  provide a consistent predictiv= e action/response/events even when different implementations has varying ca= pabilities.
>>>
>>> At the moment it seems like a w= ild wild west.
>>> Perhaps IRS can be defined in phases startin= g with a simpler, limited version..
>>>
>>> Thanks,=
>>> himanshu
>>>
>>>
>>> -= ----Original Message-----
>>> From: irs-discuss-bounces@ietf.org
= >>> [mailto:irs-discuss-bounces@ietf.org] On Behalf Of Alia Atlas
&g= t;>> Sent: Monday, August 13, 2012 8:41 AM
>>> To: Scott = Whyte
>>> Cc: Thomas Nadeau; Gert Grammel; Alia Atlas; Lenny Gi= uliano;
>>> irs-discuss@ietf.org
>>> Subject: Re: [irs-discuss] = IRS comments
>>>
>>> ...snip...
>>>
= >>> On Fri, Aug 10, 2012 at 9:03 PM, Scott Whyte <swhyte@google.com> wrote:<= br>>>>> On Fri, Aug 10, 2012 at 5:16 PM, Alia Atlas <akatlas@gmail.com> w= rote:
>>>
>>>>> I do think it is important to= have the RIB as an arbitration mechanism
>>>>> on the de= vice.   Russ's suggestion that for the RIB sub-interface, the
>&= gt;>>> IRS agent might communicate logically to an IRS routing pro= cess
>>>>> gives good semantics and interactions.  O= bviously, implementations
>>>>> may differ.
>>&g= t;>
>>>> As long as the arbitration mechanism is reconfig= urable by the
>>>> operator to whatever precedence they want= , I agree.  Its not clear
>>>> to me if various RIB imp= lementations treat all proffered routes the
>>>> same, nor i= f they store the same meta-data with all protocol sources.
>>>&= gt; So there needs to be some way for the operator to leverage exposed
&= gt;>>> protocol-specific optimizations, without conflict from the = other
>>>> routing processes, if they so desire.  OTOH = if it can all be done
>>>> via static routes, it seems much = simpler. :)
>>>
>>> Clearly the IRS sub-interface f= or the RIB needs to introduce/define the different precedences; my assumpti= on is that it would be per route with a well-defined small set of meta-data= .  This is part of where having good use-cases will help us understand= what behavior is necessary.  The static  routes do seem like a s= impler case to start with.
>>>
>>> Alia
>>= > _______________________________________________
>>> irs-di= scuss mailing list
>>> irs-discuss@ietf.org
>>> https://www= .ietf.org/mailman/listinfo/irs-discuss
>> ____________________= ___________________________
>> irs-discuss mailing list
>>= ; irs-discuss@iet= f.org
>> https://www.ietf.org/mailman/listinfo/irs-discus= s
> _______________________________________________
> irs-d= iscuss mailing list
> irs-discuss@ietf.org
> https://www.ietf.org/mail= man/listinfo/irs-discuss
___________________________________________= ____
irs-discuss mailing list
irs-discuss@ietf.org
https://www.ietf.org/ma= ilman/listinfo/irs-discuss

 = ;

 

<= /div>

 

= --_000_A3C4E51A53661B4EBEE7C5F5E6FCDEB5025AB94FE8E4USEXCHANGEc_-- Return-Path: 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 1A7CD11E80BA for ; Wed, 15 Aug 2012 11:26:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.809 X-Spam-Level: X-Spam-Status: No, score=-102.809 tagged_above=-999 required=5 tests=[AWL=0.167, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YGV4pPoYdEKa for ; Wed, 15 Aug 2012 11:26:56 -0700 (PDT) Received: from mail-gh0-f172.google.com (mail-gh0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 39E0B11E808A for ; Wed, 15 Aug 2012 11:26:56 -0700 (PDT) Received: by ghbg16 with SMTP id g16so2287683ghb.31 for ; Wed, 15 Aug 2012 11:26:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=PW4AZ2qeDYBwv6vSaIpKmWtk/nTRxyCSa3SN5Ptbgeo=; b=l/TKNNVvIDrbvVjGdx+3MzjgLyeNXhMOt66welLrxDydLE0HsoL1/xAjpiQkGvx3M0 n7dOe6dqL/b4p79CRqscWKhJQ0vgTu7nKz9kk5aleVj66TrHY0hGbzmrbE9LtDN22y6V vF+jKBLlfpFeG0fWHloyqNA3kpcZVKi/fNKexGCQgAOQTeKMqCNPVyjVDnG+ysyYOrpF CZgUtrBS6AVhtBocqUJ2aSrHaVUfXoPcVta7AsGgAu7BjSitxfTsTpHrRdZKesJxTKRg gFJHRrFeKur1PfXX+PYjboB4e9PbjybtaCV06XoNwp/hlTjVl0w4h0PfW+IatZG6Odth NWfg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=PW4AZ2qeDYBwv6vSaIpKmWtk/nTRxyCSa3SN5Ptbgeo=; b=btPrcfKeqphsaRR1gOgCK3kE81nHrVAYfWzBXNDimz7moQdZNEjfW+EmuNRulQbiop 8/dYS9kkl7/O1OzI9QFPk7gPKQor//5lDbhTyGQTqULkotN1MwX5xSBC3HWjoI8wf5wt KfcT26oZPeWy9FKlwIunT5AoZMOq7OHpBIllnsIClk5sa1lpAkjnyDJ1dkHoRfXujkLs AqV4lvk9TstIEliihzQPLNBvgAeZQzU+TSTTX7Udms8ydzqlvSPn4I8GWeW2nT4dcnAX xWIeNC+7oxamSXpD2rCX+ttbWVR6JkIB+03p/iwMFJjkzDT7V9mJ8EvxOYvQ5bLyoEP6 Ns6Q== Received: by 10.43.45.200 with SMTP id ul8mr18970265icb.36.1345055214677; Wed, 15 Aug 2012 11:26:54 -0700 (PDT) Received: by 10.43.45.200 with SMTP id ul8mr18970238icb.36.1345055214437; Wed, 15 Aug 2012 11:26:54 -0700 (PDT) MIME-Version: 1.0 Received: by 10.50.237.67 with HTTP; Wed, 15 Aug 2012 11:26:13 -0700 (PDT) In-Reply-To: References: <812700A304640D4292205D5E83FC59E1061C211D@p-embx01-eq.jnpr.net> <3512BB31280C39448A9880F61DD54CEB09C07E@xmb-aln-x09.cisco.com> From: Edward Crabbe Date: Wed, 15 Aug 2012 11:26:13 -0700 Message-ID: To: "Shah, Himanshu" Content-Type: multipart/alternative; boundary=bcaec529972f4285f804c75212ee X-System-Of-Record: true X-Gm-Message-State: ALoCoQklVAhkl0T8h7NcAkPs5JEIrbdezpnyZ69D6u4eOoWCJkTfba33DjGC0bKdSISH/1c2q4Vk5gTd79DmLK09R0V1sCU7YNRI8dlPwg0kJOkZlMR41bsFvWRDBM9R9bH15h/br3/h4UOP6YsirGYPUsciwn8Bhe2vyn+MFRX/K7Zld/qAhDTOQHcr8XapBMvTY2l6IULR Cc: Olen Stokes , "irs-discuss@ietf.org" , "David Lake \(dlake\)" , Alia Atlas 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Aug 2012 18:26:58 -0000 --bcaec529972f4285f804c75212ee Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable It's not clear to me that IRS has 'tentacles' (;)) in the LFIB... Is this the case? And if so, I guess I'll repeat the question I asked after Alia's presentation in the RTG meeting: will there be a mechanism to negotiate and specify encapsulation types as well as form FECs etc? On Wed, Aug 15, 2012 at 11:21 AM, Shah, Himanshu wrote: > *I will let Ed clarify on what he means by =93controller=94 .* > > * * > > *But here is my view of =93application=94, =93controller=94, =93use-case= =94 etc etc, * > > * * > > *When an XaaS processes a request it takes into consideration of > availability of the CPU, memory, application data, cost of power, etc. to > instantiate a VM on some host machine.* > > *One additional resource taken into consideration is the availability > and/or requirement of the network connectivity between the resources* > > *such as VM, application data, requester, etc.* > > * * > > *The provider of XaaS thingy is the application server.* > > *(Centralized) Network =93Controller(s)=94 knows current state of networ= k > infrastructure and (to be decided how much it) controls member network > nodes using IRS.* > > *The =93use case=94 here is to be able to dynamically create L2/L2.5/L3 > connectivity with specific TE characteristics between the (perhaps > geographically dispersed) resource points.* > > * * > > *In hierarchical fashion: Application server <- (application interface) > -> Network Controller <- (IRS) -> Network Node* > > * * > > *As we heard at IETF, IRS has tentacles in network nodes from BGP > policies, all the way down to FIBs/LFIBs/ACL.* > > * * > > *So we need use cases for which applications would require accessibility > to =96* > > *BGP Policies* > > *RIB* > > *LSDB ( I saw an email which talks about reducing IGP to link > distribution protocol and running SPF in centralized network controller)* > > *LIB* > > *FIB* > > *ACL (this is perhaps obvious)* > > *Etc etc* > > * * > > *I broad brushed and simplified a lot here to express my view =96 not sur= e > if this jives with others.* > > * * > > */Himanshu* > > * * > > * * > > * * > > * * > > * * > > * * > > * * > > * * > > *From:* irs-discuss-bounces@ietf.org [mailto:irs-discuss-bounces@ietf.org= ] > *On Behalf Of *Olen Stokes > *Sent:* Wednesday, August 15, 2012 1:30 PM > *To:* Edward Crabbe; Alia Atlas > *Cc:* David Lake (dlake); irs-discuss@ietf.org > > *Subject:* Re: [irs-discuss] IRS comments**** > > ** ** > > Thanks. Can you also give us what you mean by =93controller=94. **** > > ** ** > > Olen**** > > ** ** > > *From:* Edward Crabbe [mailto:edc@google.com] > *Sent:* Wednesday, August 15, 2012 1:24 PM > *To:* Alia Atlas > *Cc:* David Lake (dlake); Olen Stokes; irs-discuss@ietf.org > *Subject:* Re: [irs-discuss] IRS comments**** > > ** ** > > s/wg/pre-BOF proto-wg :P/g **** > > On Wed, Aug 15, 2012 at 10:22 AM, Edward Crabbe wrote:**= * > * > > +1 Alia. There's been a lot of confusion over this term. Having gone a > few rounds with folks on this one in other forums, I'll point out that wh= at > most people mean by application (myself included) is some set of control > software (a scheduler, a path optimizer etc) that provides instructions = to > the controller, which are in turn translated to the appropriate PDUs.**** > > ** ** > > Having 'end user' applications request/make changes to forwarding state > without an intermediate broker/aggregator acting on their behalf sounds > like a recipe for disaster for operational networks, or, as is more likel= y, > a quick hike to the protocol grave yard (followed by a long grave-side > party :P) for the wg. **** > > ** ** > > my 2c. **** > > ** ** > > On Wed, Aug 15, 2012 at 8:48 AM, Alia Atlas wrote:***= * > > Hi David, > > We do need to clarify what is meant by an application. I would not > expect that real user-land applications would talk directly to routing > devices via IRS. I can see that going through an intermediary. The > IRS abstractions are unlikely to be as high-level as user-land > applications would want and the security and policy issues would get > exciting. > > Clarifying what applications are more in-scope initially is part of > where use-cases will help. Can you write up ones to > categorize/describe your thoughts? > > Alia**** > > > On Wed, Aug 15, 2012 at 11:40 AM, David Lake (dlake) > wrote: > > As another newbie to this, I have some questions about "application > vendors." > > > > Who is the target audience here ? That will determine what > functionality and abstraction of the network we need to expose to that > "application." > > > > This presently appears to be a little confused - at least in my mind. > The draft talks very much as if the application we are addressing is an > OSS/BSS system, essentially provisioning from the domain owner. > > > > However, linking this to the wider goals of SDN as voiced by > customers/users at the first Open Network Summit, there appears to be a > desire for cross-domain and user-land application integration. > > > > At this level - as an example giving a content cache the ability to > ensure delivery of an HD video to an end user - the application will not = be > interested in the underlying topology of the network; it will need to kn= ow > that application X can be delivered with parameters Y between reading fro= m > the content store to delivery to the user's browser. How the stream > traverses the infrastructure is immaterial. > > > > Are we intending that IRS satisfies BOTH these requirements (i.e. for > ALL applications ?), or should we be more prescriptive about which > application space we are addressing ? > > > > Thanks > > > > David > > > > -----Original Message----- > > From: irs-discuss-bounces@ietf.org [mailto:irs-discuss-bounces@ietf.org= ] > On Behalf Of Alia Atlas > > Sent: Wednesday, August 15, 2012 7:23 AM > > To: Olen Stokes > > Cc: irs-discuss@ietf.org > > Subject: Re: [irs-discuss] IRS comments > > > > I have not specifically heard from application vendors about this. > > My current plan is that we focus on a Use-Cases draft and define within > that some motivating use-cases that we agree are good first targets. Tho= se > can drive which subset of functionality we focus on. > > > > More use-cases are, of course, quite welcome. Posting them to the > mailing list is a good first start. Russ White is starting the general > use-cases draft based on the three use-cases that he sent to the list. > > > > Alia > > > > On Wed, Aug 15, 2012 at 9:43 AM, Olen Stokes < > ostokes@extremenetworks.com> wrote: > >> Are there applications vendors out there that already have specific > requirements for what this " subset of the data-models for sub-interfaces= " > should be? > >> > >> Olen > >> > >> -----Original Message----- > >> From: irs-discuss-bounces@ietf.org > >> [mailto:irs-discuss-bounces@ietf.org] On Behalf Of Alia Atlas > >> Sent: Wednesday, August 15, 2012 9:08 AM > >> To: Shah, Himanshu > >> Cc: Gert Grammel; irs-discuss@ietf.org; Lenny Giuliano; Thomas Nadeau; > >> Alia Atlas; Scott Whyte > >> Subject: Re: [irs-discuss] IRS comments > >> > >> Hi Himanshu, > >> > >> Welcome. I agree that IRS isn't going to spring into being fully > >> formed - I expect that we'll focus on a subset of the data-models for > sub-interfaces along with an associated protocol (whether that is a new o= ne > or extending an existing one). > >> > >> Alia > >> > >> On Wed, Aug 15, 2012 at 7:41 AM, Shah, Himanshu > wrote: > >>> Newbie to this discussions list and have read only a last couple of > mails, so pardon the repeat if somebody has already raised the following = as > a concern. > >>> > >>> I realize we are early in IRS architecture definition but one thing t= o > keep in mind is the user experience. > >>> We need to make sure that exposed interface to > >>> RIB/LFIB/FIB/IGPs/BGP/LSDBs etc etc provide a consistent predictive > action/response/events even when different implementations has varying > capabilities. > >>> > >>> At the moment it seems like a wild wild west. > >>> Perhaps IRS can be defined in phases starting with a simpler, limited > version.. > >>> > >>> Thanks, > >>> himanshu > >>> > >>> > >>> -----Original Message----- > >>> From: irs-discuss-bounces@ietf.org > >>> [mailto:irs-discuss-bounces@ietf.org] On Behalf Of Alia Atlas > >>> Sent: Monday, August 13, 2012 8:41 AM > >>> To: Scott Whyte > >>> Cc: Thomas Nadeau; Gert Grammel; Alia Atlas; Lenny Giuliano; > >>> irs-discuss@ietf.org > >>> Subject: Re: [irs-discuss] IRS comments > >>> > >>> ...snip... > >>> > >>> On Fri, Aug 10, 2012 at 9:03 PM, Scott Whyte > wrote: > >>>> On Fri, Aug 10, 2012 at 5:16 PM, Alia Atlas > wrote: > >>> > >>>>> I do think it is important to have the RIB as an arbitration > mechanism > >>>>> on the device. Russ's suggestion that for the RIB sub-interface, > the > >>>>> IRS agent might communicate logically to an IRS routing process > >>>>> gives good semantics and interactions. Obviously, implementations > >>>>> may differ. > >>>> > >>>> As long as the arbitration mechanism is reconfigurable by the > >>>> operator to whatever precedence they want, I agree. Its not clear > >>>> to me if various RIB implementations treat all proffered routes the > >>>> same, nor if they store the same meta-data with all protocol sources= . > >>>> So there needs to be some way for the operator to leverage exposed > >>>> protocol-specific optimizations, without conflict from the other > >>>> routing processes, if they so desire. OTOH if it can all be done > >>>> via static routes, it seems much simpler. :) > >>> > >>> Clearly the IRS sub-interface for the RIB needs to introduce/define > the different precedences; my assumption is that it would be per route wi= th > a well-defined small set of meta-data. This is part of where having good > use-cases will help us understand what behavior is necessary. The static > routes do seem like a simpler case to start with. > >>> > >>> Alia > >>> _______________________________________________ > >>> 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 > > _______________________________________________ > > 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**** > > ** ** > > ** ** > --bcaec529972f4285f804c75212ee Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable It's not clear to me that IRS has 'tentacles' (;)) in the LFIB.= .. =A0

Is this the case? =A0And if so, I guess I'll = repeat the question I asked after Alia's presentation in the RTG meetin= g: =A0will there be a mechanism to negotiate and specify encapsulation type= s as well as form FECs etc?=A0

On Wed, Aug 15, 2012 at 11:21 AM, Shah, Hima= nshu <hshah@ciena.com> wrote:

I will let Ed clarify on what he means by= =93controller=94 .

=A0

But here is = my view of =93application=94, =93controller=94, =93use-case=94 etc etc, =

=A0

When an XaaS= processes a request it takes into consideration of availability of the CPU= , memory, application data, cost of power, etc. to instantiate a VM on some= host machine.

One additional resourc= e taken into consideration is the availability and/or requirement of the ne= twork connectivity between the resources

such as VM, applicatio= n data, requester, etc.

= =A0

The provider of XaaS t= hingy is the application server.

(Centralized) Network =93Controller(s)=94 =A0= knows current state of network infrastructure and (to be decided how much i= t) controls member network nodes using IRS.

The =93use case=94 her= e is to be able to dynamically create L2/L2.5/L3 connectivity with specific= TE characteristics between the (perhaps geographically dispersed) resource= points.

=A0

In hierarchi= cal fashion:=A0=A0 Application server <- (application interface) -> N= etwork Controller <- (IRS) -> Network Node

=A0

As we heard = at IETF, IRS has tentacles in network nodes from BGP policies, all the way = down to FIBs/LFIBs/ACL.

=A0

So we need u= se cases for which applications would require accessibility to =96

BGP Policies=

RIB=

LSDB ( I saw an email = which talks about reducing IGP to link distribution protocol and running SP= F in centralized network controller)

LIB

FIB

ACL (this is perhaps o= bvious)

Etc etc

=A0

I broad brus= hed and simplified a lot here to express my view =96 not sure if this jives= with others.

=A0

/Himanshu=

=A0

=A0

=A0

=A0

=A0

=A0

=A0

=A0

From: irs= -discuss-bounces@ietf.org [mailto:irs-discuss-bounces@ietf.org] On Behalf= Of Olen Stokes
Sent: Wednesday, August 15, 2012 1:30 PM
To: Edward Crabbe= ; Alia Atlas
Cc: David Lake (dlake); irs-discuss@ietf.org


Subject: Re: [irs-discuss] IRS comments

= =A0

Thanks.=A0 = Can you also give us what you mean by =93controller=94.=A0

=A0<= /p>

Olen

=A0<= /p>

From: Edwar= d Crabbe [mail= to:edc@google.com]
Sent: Wednesday, August 15, 2012 1:24 PM
To: Alia AtlasCc: David Lake (dlake); Olen Stokes; irs-discuss@ietf.org
Subject: Re:= [irs-discuss] IRS comments

=A0

s/wg/pre-BOF proto-wg :P/g =A0

On Wed, Aug 15, 2012 at 10:22 AM, Edward Crabbe <= ;edc@google.com>= wrote:

+1 Alia. =A0There's been a lot of confusion over= this term. =A0Having gone a few rounds with folks on this one in other for= ums, I'll point out that what most people mean by application (myself i= ncluded) is some set of control software (a scheduler, a path optimizer etc= ) =A0that provides instructions to the controller, which are in turn transl= ated to the appropriate PDUs.

=A0

Having 'end user' applications request/make changes to forw= arding state without an intermediate broker/aggregator acting on their beha= lf sounds like a recipe for disaster for operational networks, or, as is mo= re likely, a quick hike to the protocol grave yard (followed by a long grav= e-side party :P) for the wg. =A0

=A0

my 2c.=A0

=A0

On Wed, Aug 15,= 2012 at 8:48 AM, Alia Atlas <akatlas@gmail.com> wrote:

Hi David,

We do need to clarify what is meant= by an application. =A0I would not
expect that real user-land applicatio= ns would talk directly to routing
devices via IRS. =A0I can see that goi= ng through an intermediary. =A0The
IRS abstractions are unlikely to be as high-level as user-land
applicati= ons would want and the security and policy issues would get
exciting.
Clarifying what applications are more in-scope initially is part of where use-cases will help. =A0Can you write up ones to
categorize/descri= be your thoughts?

Alia


On Wed, Aug 15, 2012 at 11:40= AM, David Lake (dlake) <dlake@cisco.com> wrote:
> As another newbie to this, I have some questions about "applicati= on vendors."
>
> Who is the target audience here ? =A0 Tha= t will determine what functionality and abstraction of the network we need = to expose to that "application."
>
> This presently appears to be a little confused - at least in m= y mind. =A0The draft talks very much as if the application we are addressin= g is an OSS/BSS system, essentially provisioning from the domain owner.
>
> However, linking this to the wider goals of SDN as voiced by c= ustomers/users at the first Open Network Summit, there appears to be a desi= re for cross-domain and user-land application integration.
>
> At this level - as an example giving a content cache the ability to en= sure delivery of an HD video to an end user - the application will not be i= nterested in the underlying topology of the network; it will =A0need to kno= w that application X can be delivered with parameters Y between reading fro= m the content store to delivery to the user's browser. =A0 How the stre= am traverses the infrastructure is immaterial.
>
> Are we intending that IRS satisfies BOTH these requirements (i= .e. for ALL applications ?), or should we be more prescriptive about which = application space we are addressing ?
>
> Thanks
>
> David
>
> -----Original Message-----
> From: irs-discuss-boun= ces@ietf.org [mailto:irs-discuss-bounces@ietf.org] On Behalf Of Alia Atlas > Sent: Wednesday, August 15, 2012 7:23 AM
> To: Olen Stokes
&g= t; Cc: irs-discus= s@ietf.org
> Subject: Re: [irs-discuss] IRS comments
>
> I have not specifically heard from application vendors about this.
> My current plan is that we focus on a Use-Cases draft and define withi= n that some motivating use-cases that we agree are good first targets. =A0T= hose can drive which subset of functionality we focus on.
>
> M= ore use-cases are, of course, quite welcome. =A0Posting them to the mailing= list is a good first start. =A0Russ White is starting the general use-case= s draft based on the three use-cases that he sent to the list.
>
> Alia
>
> On Wed, Aug 15, 2012 at 9:43 AM, Olen Sto= kes <os= tokes@extremenetworks.com> wrote:
>> Are there applications= vendors out there that already have specific requirements for what this &q= uot; subset of the data-models for sub-interfaces" =A0should be?
>>
>> Olen
>>
>> -----Original Message----= -
>> From: irs-discuss-bounces@ietf.org
>> [mailto:irs-discuss-bounces= @ietf.org] On Behalf Of Alia Atlas
>> Sent: Wednesday, August 15, 2012 9:08 AM
>> To: Shah, Him= anshu
>> Cc: Gert Grammel; irs-discuss@ietf.org; Lenny Giuliano; Thomas Nadeau;=
>> Alia Atlas; Scott Whyte
>> Subject: Re: [irs-discuss] IRS= comments
>>
>> Hi Himanshu,
>>
>> Welc= ome. =A0 I agree that IRS isn't going to spring into being fully
>> formed - I expect that we'll focus on a subset of the data-mod= els for sub-interfaces along with an associated protocol (whether that is a= new one or extending an existing one).
>>
>> Alia
>>
>> On Wed, Aug 15, 2012 at 7= :41 AM, Shah, Himanshu <hshah@ciena.com> wrote:
>>> Newbie to this discussi= ons list and have read only a last couple of mails, so pardon the repeat if= somebody has already raised the following as a concern.
>>>
>>> I realize we are early in IRS architecture def= inition but one thing to keep in mind is the user experience.
>>&g= t; We need to make sure that exposed interface to
>>> RIB/LFIB/= FIB/IGPs/BGP/LSDBs etc etc =A0provide a consistent predictive action/respon= se/events even when different implementations has varying capabilities.
>>>
>>> At the moment it seems like a wild wild west.<= br>>>> Perhaps IRS can be defined in phases starting with a simple= r, limited version..
>>>
>>> Thanks,
>>>= ; himanshu
>>>
>>>
>>> -----Original Message-----
= >>> From: irs-discuss-bounces@ietf.org
>>> [mailto:irs-discuss-bou= nces@ietf.org] On Behalf Of Alia Atlas
>>> Sent: Monday, August 13, 2012 8:41 AM
>>> To: Scot= t Whyte
>>> Cc: Thomas Nadeau; Gert Grammel; Alia Atlas; Lenny = Giuliano;
>>> irs-discuss@ietf.org
>>> Subject: Re: [irs-discuss] IRS comments
>>>
>= ;>> ...snip...
>>>
>>> On Fri, Aug 10, 2012 a= t 9:03 PM, Scott Whyte <swhyte@google.com> wrote:
>>>> On Fri, Aug 10, 2012 at 5:16 PM, Alia Atlas <akatlas@gmail.com> wrot= e:
>>>
>>>>> I do think it is important to ha= ve the RIB as an arbitration mechanism
>>>>> on the device. =A0 Russ's suggestion that for the = RIB sub-interface, the
>>>>> IRS agent might communicate = logically to an IRS routing process
>>>>> gives good sema= ntics and interactions. =A0Obviously, implementations
>>>>> may differ.
>>>>
>>>> As= long as the arbitration mechanism is reconfigurable by the
>>>= > operator to whatever precedence they want, I agree. =A0Its not clear >>>> to me if various RIB implementations treat all proffered r= outes the
>>>> same, nor if they store the same meta-data wi= th all protocol sources.
>>>> So there needs to be some way = for the operator to leverage exposed
>>>> protocol-specific optimizations, without conflict from the= other
>>>> routing processes, if they so desire. =A0OTOH if= it can all be done
>>>> via static routes, it seems much si= mpler. :)
>>>
>>> Clearly the IRS sub-interface for the RIB need= s to introduce/define the different precedences; my assumption is that it w= ould be per route with a well-defined small set of meta-data. =A0This is pa= rt of where having good use-cases will help us understand what behavior is = necessary. =A0The static =A0routes do seem like a simpler case to start wit= h.
>>>
>>> Alia
>>> _________________________= ______________________
>>> irs-discuss mailing list
>>= > irs-discuss@= ietf.org
>>> https://www.ietf.org/mailman/listinfo/irs-discuss
= >> _______________________________________________
>> irs-di= scuss mailing list
>> irs-disc= uss@ietf.org
>> https://www.ietf.org/mailman/listinfo/irs= -discuss
> _______________________________________________
> irs-discuss ma= iling list
> irs-discuss@ietf.org
> https://www.ietf.org/mailman/listin= fo/irs-discuss
_______________________________________________
irs-discuss mailing list=
irs-discuss@i= etf.org
https://www.ietf.org/mailman/listinfo/irs-discuss

=A0

<= /div>

=A0


--bcaec529972f4285f804c75212ee-- Return-Path: 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 B19FC21F87BF for ; Wed, 15 Aug 2012 11:22:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.962 X-Spam-Level: X-Spam-Status: No, score=-2.962 tagged_above=-999 required=5 tests=[AWL=0.302, BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8muZ2UdiTmZe for ; Wed, 15 Aug 2012 11:22:07 -0700 (PDT) Received: from mx0a-00103a01.pphosted.com (mx0a-00103a01.pphosted.com [67.231.144.234]) by ietfa.amsl.com (Postfix) with ESMTP id 63D3321F8745 for ; Wed, 15 Aug 2012 11:21:55 -0700 (PDT) Received: from pps.filterd (m0000419 [127.0.0.1]) by mx0a-00103a01.pphosted.com (8.14.4/8.14.4) with SMTP id q7FIKY2c003253; Wed, 15 Aug 2012 14:21:30 -0400 Received: from mdwexght02.ciena.com (LIN1-118-36-29.ciena.com [63.118.36.29]) by mx0a-00103a01.pphosted.com with ESMTP id 16rghw033n-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 15 Aug 2012 14:21:29 -0400 Received: from MDWEXGMB02.ciena.com ([::1]) by MDWEXGHT02.ciena.com ([::1]) with mapi; Wed, 15 Aug 2012 14:21:29 -0400 From: "Shah, Himanshu" To: Olen Stokes , Edward Crabbe , Alia Atlas Date: Wed, 15 Aug 2012 14:21:28 -0400 Thread-Topic: [irs-discuss] IRS comments Thread-Index: Ac17CumNRXBeBNRCSZOft8tf4DLXywAAFq5wAAC9qgA= Message-ID: References: <812700A304640D4292205D5E83FC59E1061C211D@p-embx01-eq.jnpr.net> <3512BB31280C39448A9880F61DD54CEB09C07E@xmb-aln-x09.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_B37E6A2CE5957F4E83C1D9845A0FFE38014A33C0A0MDWEXGMB02cie_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.7.7855, 1.0.260, 0.0.0000 definitions=2012-08-15_03:2012-08-15, 2012-08-15, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=1 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=6.0.2-1203120001 definitions=main-1208150193 Cc: "David Lake \(dlake\)" , "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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Aug 2012 18:22:11 -0000 --_000_B37E6A2CE5957F4E83C1D9845A0FFE38014A33C0A0MDWEXGMB02cie_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I will let Ed clarify on what he means by "controller" . But here is my view of "application", "controller", "use-case" etc etc, When an XaaS processes a request it takes into consideration of availabilit= y of the CPU, memory, application data, cost of power, etc. to instantiate = a VM on some host machine. One additional resource taken into consideration is the availability and/or= requirement of the network connectivity between the resources such as VM, application data, requester, etc. The provider of XaaS thingy is the application server. (Centralized) Network "Controller(s)" knows current state of network infra= structure and (to be decided how much it) controls member network nodes usi= ng IRS. The "use case" here is to be able to dynamically create L2/L2.5/L3 connecti= vity with specific TE characteristics between the (perhaps geographically d= ispersed) resource points. In hierarchical fashion: Application server <- (application interface) ->= Network Controller <- (IRS) -> Network Node As we heard at IETF, IRS has tentacles in network nodes from BGP policies, = all the way down to FIBs/LFIBs/ACL. So we need use cases for which applications would require accessibility to = - BGP Policies RIB LSDB ( I saw an email which talks about reducing IGP to link distribution p= rotocol and running SPF in centralized network controller) LIB FIB ACL (this is perhaps obvious) Etc etc I broad brushed and simplified a lot here to express my view - not sure if = this jives with others. /Himanshu From: irs-discuss-bounces@ietf.org [mailto:irs-discuss-bounces@ietf.org] On= Behalf Of Olen Stokes Sent: Wednesday, August 15, 2012 1:30 PM To: Edward Crabbe; Alia Atlas Cc: David Lake (dlake); irs-discuss@ietf.org Subject: Re: [irs-discuss] IRS comments Thanks. Can you also give us what you mean by "controller". Olen From: Edward Crabbe [mailto:edc@google.com] Sent: Wednesday, August 15, 2012 1:24 PM To: Alia Atlas Cc: David Lake (dlake); Olen Stokes; irs-discuss@ietf.org Subject: Re: [irs-discuss] IRS comments s/wg/pre-BOF proto-wg :P/g On Wed, Aug 15, 2012 at 10:22 AM, Edward Crabbe > wrote: +1 Alia. There's been a lot of confusion over this term. Having gone a fe= w rounds with folks on this one in other forums, I'll point out that what m= ost people mean by application (myself included) is some set of control sof= tware (a scheduler, a path optimizer etc) that provides instructions to th= e controller, which are in turn translated to the appropriate PDUs. Having 'end user' applications request/make changes to forwarding state wit= hout an intermediate broker/aggregator acting on their behalf sounds like a= recipe for disaster for operational networks, or, as is more likely, a qui= ck hike to the protocol grave yard (followed by a long grave-side party :P)= for the wg. my 2c. On Wed, Aug 15, 2012 at 8:48 AM, Alia Atlas > wrote: Hi David, We do need to clarify what is meant by an application. I would not expect that real user-land applications would talk directly to routing devices via IRS. I can see that going through an intermediary. The IRS abstractions are unlikely to be as high-level as user-land applications would want and the security and policy issues would get exciting. Clarifying what applications are more in-scope initially is part of where use-cases will help. Can you write up ones to categorize/describe your thoughts? Alia On Wed, Aug 15, 2012 at 11:40 AM, David Lake (dlake) > wrote: > As another newbie to this, I have some questions about "application vendo= rs." > > Who is the target audience here ? That will determine what functionalit= y and abstraction of the network we need to expose to that "application." > > This presently appears to be a little confused - at least in my mind. Th= e draft talks very much as if the application we are addressing is an OSS/B= SS system, essentially provisioning from the domain owner. > > However, linking this to the wider goals of SDN as voiced by customers/us= ers at the first Open Network Summit, there appears to be a desire for cros= s-domain and user-land application integration. > > At this level - as an example giving a content cache the ability to ensur= e delivery of an HD video to an end user - the application will not be inte= rested in the underlying topology of the network; it will need to know tha= t application X can be delivered with parameters Y between reading from the= content store to delivery to the user's browser. How the stream traverse= s the infrastructure is immaterial. > > Are we intending that IRS satisfies BOTH these requirements (i.e. for ALL= applications ?), or should we be more prescriptive about which application= space we are addressing ? > > Thanks > > David > > -----Original Message----- > From: irs-discuss-bounces@ietf.org [= mailto:irs-discuss-bounces@ietf.org] O= n Behalf Of Alia Atlas > Sent: Wednesday, August 15, 2012 7:23 AM > To: Olen Stokes > Cc: irs-discuss@ietf.org > Subject: Re: [irs-discuss] IRS comments > > I have not specifically heard from application vendors about this. > My current plan is that we focus on a Use-Cases draft and define within t= hat some motivating use-cases that we agree are good first targets. Those = can drive which subset of functionality we focus on. > > More use-cases are, of course, quite welcome. Posting them to the mailin= g list is a good first start. Russ White is starting the general use-cases= draft based on the three use-cases that he sent to the list. > > Alia > > On Wed, Aug 15, 2012 at 9:43 AM, Olen Stokes > wrote: >> Are there applications vendors out there that already have specific requ= irements for what this " subset of the data-models for sub-interfaces" sho= uld be? >> >> Olen >> >> -----Original Message----- >> From: irs-discuss-bounces@ietf.org >> [mailto:irs-discuss-bounces@ietf.org] On Behalf Of Alia Atlas >> Sent: Wednesday, August 15, 2012 9:08 AM >> To: Shah, Himanshu >> Cc: Gert Grammel; irs-discuss@ietf.org; Len= ny Giuliano; Thomas Nadeau; >> Alia Atlas; Scott Whyte >> Subject: Re: [irs-discuss] IRS comments >> >> Hi Himanshu, >> >> Welcome. I agree that IRS isn't going to spring into being fully >> formed - I expect that we'll focus on a subset of the data-models for su= b-interfaces along with an associated protocol (whether that is a new one o= r extending an existing one). >> >> Alia >> >> On Wed, Aug 15, 2012 at 7:41 AM, Shah, Himanshu > wrote: >>> Newbie to this discussions list and have read only a last couple of mai= ls, so pardon the repeat if somebody has already raised the following as a = concern. >>> >>> I realize we are early in IRS architecture definition but one thing to = keep in mind is the user experience. >>> We need to make sure that exposed interface to >>> RIB/LFIB/FIB/IGPs/BGP/LSDBs etc etc provide a consistent predictive ac= tion/response/events even when different implementations has varying capabi= lities. >>> >>> At the moment it seems like a wild wild west. >>> Perhaps IRS can be defined in phases starting with a simpler, limited v= ersion.. >>> >>> Thanks, >>> himanshu >>> >>> >>> -----Original Message----- >>> From: irs-discuss-bounces@ietf.org >>> [mailto:irs-discuss-bounces@ietf.org] On Behalf Of Alia Atlas >>> Sent: Monday, August 13, 2012 8:41 AM >>> To: Scott Whyte >>> Cc: Thomas Nadeau; Gert Grammel; Alia Atlas; Lenny Giuliano; >>> irs-discuss@ietf.org >>> Subject: Re: [irs-discuss] IRS comments >>> >>> ...snip... >>> >>> On Fri, Aug 10, 2012 at 9:03 PM, Scott Whyte > wrote: >>>> On Fri, Aug 10, 2012 at 5:16 PM, Alia Atlas > wrote: >>> >>>>> I do think it is important to have the RIB as an arbitration mechanis= m >>>>> on the device. Russ's suggestion that for the RIB sub-interface, th= e >>>>> IRS agent might communicate logically to an IRS routing process >>>>> gives good semantics and interactions. Obviously, implementations >>>>> may differ. >>>> >>>> As long as the arbitration mechanism is reconfigurable by the >>>> operator to whatever precedence they want, I agree. Its not clear >>>> to me if various RIB implementations treat all proffered routes the >>>> same, nor if they store the same meta-data with all protocol sources. >>>> So there needs to be some way for the operator to leverage exposed >>>> protocol-specific optimizations, without conflict from the other >>>> routing processes, if they so desire. OTOH if it can all be done >>>> via static routes, it seems much simpler. :) >>> >>> Clearly the IRS sub-interface for the RIB needs to introduce/define the= different precedences; my assumption is that it would be per route with a = well-defined small set of meta-data. This is part of where having good use= -cases will help us understand what behavior is necessary. The static rou= tes do seem like a simpler case to start with. >>> >>> Alia >>> _______________________________________________ >>> 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 > _______________________________________________ > 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 --_000_B37E6A2CE5957F4E83C1D9845A0FFE38014A33C0A0MDWEXGMB02cie_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I wi= ll let Ed clarify on what he means by “controller” .=

 <= /p>

But here is my view of “application= ”, “controller”, “use-case” etc etc,

 

When an XaaS processes a request it ta= kes into consideration of availability of the CPU, memory, application data= , cost of power, etc. to instantiate a VM on some host machine.<= /span>

One additional resource taken = into consideration is the availability and/or requirement of the network co= nnectivity between the resources

such as VM, application data, requester, etc.

 

The provider of XaaS thingy is the application= server.

(Centraliz= ed) Network “Controller(s)”  knows current state of networ= k infrastructure and (to be decided how much it) controls member network no= des using IRS.

The = “use case” here is to be able to dynamically create L2/L2.5/L3 = connectivity with specific TE characteristics between the (perhaps geograph= ically dispersed) resource points.

 

In hierarchical fashion:   Application server <- (applicat= ion interface) -> Network Controller <- (IRS) -> Network Node=

 

As we heard at IETF, IRS has tentac= les in network nodes from BGP policies, all the way down to FIBs/LFIBs/ACL.=

 <= /span>

So we need use cases for which= applications would require accessibility to –<= /p>

BGP Policies

RIB

LSDB ( I saw an email which talks about reducing IGP to link d= istribution protocol and running SPF in centralized network controller)

LIB<= /i>

FIB

ACL (this is perhaps obvious)<= /p>

Etc etc

 

I broad brushed and simplified a lot here to express my view = 211; not sure if this jives with others.

 

/Himanshu

 

 = ;

 

 

 

 

 

&n= bsp;

From: irs-discus= s-bounces@ietf.org [mailto:irs-discuss-bounces@ietf.org] On Behalf Of Olen Stokes
Sent: Wednesday, August 15, 2012 1:30 PM
To:<= /b> Edward Crabbe; Alia Atlas
Cc: David Lake (dlake); irs-discuss= @ietf.org
Subject: Re: [irs-discuss] IRS comments

 

Thanks.  Can you also give us what you mean by “con= troller”. 

 

Olen=

 

From: Edward Crabbe [mailto:= edc@google.com]
Sent: Wednesday, August 15, 2012 1:24 PM
= To: Alia Atlas
Cc: David Lake (dlake); Olen Stokes; irs-discuss@ietf.org
Subject: Re: [irs-discuss] IRS comments

 

s= /wg/pre-BOF proto-wg :P/g  

On= Wed, Aug 15, 2012 at 10:22 AM, Edward Crabbe <edc@google.com> wrote:

+1 Alia.  There's been a lot of confusion over this t= erm.  Having gone a few rounds with folks on this one in other forums,= I'll point out that what most people mean by application (myself included)= is some set of control software (a scheduler, a path optimizer etc)  = that provides instructions to the controller, which are in turn translated = to the appropriate PDUs.

 = ;

Having 'end user' applications r= equest/make changes to forwarding state without an intermediate broker/aggr= egator acting on their behalf sounds like a recipe for disaster for operati= onal networks, or, as is more likely, a quick hike to the protocol grave ya= rd (followed by a long grave-side party :P) for the wg.  

 

my 2c. 

 

On Wed, Aug 15, 2012 = at 8:48 AM, Alia Atlas <akatlas@gmail.com> wrote:

= Hi David,

We do need to clarify what is meant by an application. &nb= sp;I would not
expect that real user-land applications would talk direct= ly to routing
devices via IRS.  I can see that going through an int= ermediary.  The
IRS abstractions are unlikely to be as high-level a= s user-land
applications would want and the security and policy issues w= ould get
exciting.

Clarifying what applications are more in-scope= initially is part of
where use-cases will help.  Can you write up = ones to
categorize/describe your thoughts?

Alia


On Wed= , Aug 15, 2012 at 11:40 AM, David Lake (dlake) <dlake@cisco.com> wrote:
> As anot= her newbie to this, I have some questions about "application vendors.&= quot;
>
> Who is the target audience here ?   That will de= termine what functionality and abstraction of the network we need to expose= to that "application."
>
> This presently appears to= be a little confused - at least in my mind.  The draft talks very muc= h as if the application we are addressing is an OSS/BSS system, essentially= provisioning from the domain owner.
>
> However, linking this = to the wider goals of SDN as voiced by customers/users at the first Open Ne= twork Summit, there appears to be a desire for cross-domain and user-land a= pplication integration.
>
> At this level - as an example givin= g a content cache the ability to ensure delivery of an HD video to an end u= ser - the application will not be interested in the underlying topology of = the network; it will  need to know that application X can be delivered= with parameters Y between reading from the content store to delivery to th= e user's browser.   How the stream traverses the infrastructure is imm= aterial.
>
> Are we intending that IRS satisfies BOTH these req= uirements (i.e. for ALL applications ?), or should we be more prescriptive = about which application space we are addressing ?
>
> Thanks>
> David
>
> -----Original Message-----
> From= : irs-dis= cuss-bounces@ietf.org [mailto:irs-discuss-bounces@ietf.org] On Behalf Of Ali= a Atlas
> Sent: Wednesday, August 15, 2012 7:23 AM
> To: Olen S= tokes
> Cc: irs-discuss@ietf.org
> Subject: Re: [irs-discuss] IRS comments>
> I have not specifically heard from application vendors about= this.
> My current plan is that we focus on a Use-Cases draft and de= fine within that some motivating use-cases that we agree are good first tar= gets.  Those can drive which subset of functionality we focus on.
&= gt;
> More use-cases are, of course, quite welcome.  Posting the= m to the mailing list is a good first start.  Russ White is starting t= he general use-cases draft based on the three use-cases that he sent to the= list.
>
> Alia
>
> On Wed, Aug 15, 2012 at 9:43 AM= , Olen Stokes <ostokes@extremenetworks.com> wrote:
>> Are there ap= plications vendors out there that already have specific requirements for wh= at this " subset of the data-models for sub-interfaces"  sho= uld be?
>>
>> Olen
>>
>> -----Original = Message-----
>> From: irs-discuss-bounces@ietf.org
>> [mailto:= irs-discu= ss-bounces@ietf.org] On Behalf Of Alia Atlas
>> Sent: Wednesda= y, August 15, 2012 9:08 AM
>> To: Shah, Himanshu
>> Cc: G= ert Grammel; irs-= discuss@ietf.org; Lenny Giuliano; Thomas Nadeau;
>> Alia Atlas= ; Scott Whyte
>> Subject: Re: [irs-discuss] IRS comments
>&g= t;
>> Hi Himanshu,
>>
>> Welcome.   I agree= that IRS isn't going to spring into being fully
>> formed - I exp= ect that we'll focus on a subset of the data-models for sub-interfaces alon= g with an associated protocol (whether that is a new one or extending an ex= isting one).
>>
>> Alia
>>
>> On Wed, A= ug 15, 2012 at 7:41 AM, Shah, Himanshu <hshah@ciena.com> wrote:
>>> Newbie = to this discussions list and have read only a last couple of mails, so pard= on the repeat if somebody has already raised the following as a concern.>>>
>>> I realize we are early in IRS architecture de= finition but one thing to keep in mind is the user experience.
>>&= gt; We need to make sure that exposed interface to
>>> RIB/LFIB= /FIB/IGPs/BGP/LSDBs etc etc  provide a consistent predictive action/re= sponse/events even when different implementations has varying capabilities.=
>>>
>>> At the moment it seems like a wild wild we= st.
>>> Perhaps IRS can be defined in phases starting with a si= mpler, limited version..
>>>
>>> Thanks,
>>= ;> himanshu
>>>
>>>
>>> -----Origina= l Message-----
>>> From: irs-discuss-bounces@ietf.org
>>>= ; [mailto:irs-discuss-bounces@ietf.org] On Behalf Of Alia Atlas
>>> = Sent: Monday, August 13, 2012 8:41 AM
>>> To: Scott Whyte
&g= t;>> Cc: Thomas Nadeau; Gert Grammel; Alia Atlas; Lenny Giuliano;
= >>> irs-= discuss@ietf.org
>>> Subject: Re: [irs-discuss] IRS comment= s
>>>
>>> ...snip...
>>>
>>>= ; On Fri, Aug 10, 2012 at 9:03 PM, Scott Whyte <swhyte@google.com> wrote:
>>= >> On Fri, Aug 10, 2012 at 5:16 PM, Alia Atlas <akatlas@gmail.com> wrote:
&g= t;>>
>>>>> I do think it is important to have the R= IB as an arbitration mechanism
>>>>> on the device.  = ; Russ's suggestion that for the RIB sub-interface, the
>>>>= > IRS agent might communicate logically to an IRS routing process
>= ;>>>> gives good semantics and interactions.  Obviously, i= mplementations
>>>>> may differ.
>>>>
&= gt;>>> As long as the arbitration mechanism is reconfigurable by t= he
>>>> operator to whatever precedence they want, I agree. =  Its not clear
>>>> to me if various RIB implementation= s treat all proffered routes the
>>>> same, nor if they stor= e the same meta-data with all protocol sources.
>>>> So ther= e needs to be some way for the operator to leverage exposed
>>>= > protocol-specific optimizations, without conflict from the other
&g= t;>>> routing processes, if they so desire.  OTOH if it can a= ll be done
>>>> via static routes, it seems much simpler. :)=
>>>
>>> Clearly the IRS sub-interface for the RIB = needs to introduce/define the different precedences; my assumption is that = it would be per route with a well-defined small set of meta-data.  Thi= s is part of where having good use-cases will help us understand what behav= ior is necessary.  The static  routes do seem like a simpler case= to start with.
>>>
>>> Alia
>>> ______= _________________________________________
>>> irs-discuss maili= ng list
>>> irs-discuss@ietf.org
>>> https://www.ietf.org/m= ailman/listinfo/irs-discuss
>> _______________________________= ________________
>> irs-discuss mailing list
>> irs-discuss@ietf.org=
>> https://www.ietf.org/mailman/listinfo/irs-discuss
= > _______________________________________________
> irs-discuss ma= iling list
> irs-discuss@ietf.org
> https://www.ietf.org/mailman/listin= fo/irs-discuss
_______________________________________________
ir= s-discuss mailing list
irs-discuss@ietf.org
https://www.ietf.org/mailman/list= info/irs-discuss

<= o:p> 

 = ;

= --_000_B37E6A2CE5957F4E83C1D9845A0FFE38014A33C0A0MDWEXGMB02cie_-- Return-Path: 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 21C5D21F86B2 for ; Wed, 15 Aug 2012 11:21:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.768 X-Spam-Level: X-Spam-Status: No, score=-102.768 tagged_above=-999 required=5 tests=[AWL=0.208, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CDbll+TtyM5l for ; Wed, 15 Aug 2012 11:20:58 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 4538F21F8773 for ; Wed, 15 Aug 2012 11:20:49 -0700 (PDT) Received: by yhq56 with SMTP id 56so2266597yhq.31 for ; Wed, 15 Aug 2012 11:20:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=3JvZ9Ie5NQ9hlW8nV0upSjKfjUG6LhBqKdUkbVQTCM8=; b=FxvP3tN/2FpqA9DZSo/AmwKzwm2tyjmMz0aRUgoJ86L3LXmLtg7iZQ3ke3RPqDO8lM 1zhvjKDSgHeW1oDKfmMAgVVy4lAgKQl7sUnhNNLK5qBwogKOP6eOGFxbCCOmMWMBUekW 1tk+nDYCtODbRcPmFn4GZDcrb3ScLpU+PFW73BBoaBuvJnGAsGrYTdHMP+6nLIZOP69+ 5HclVG4e+pGjWYhEKVmdJe3CREMyjuRf1jfsn5u8+MtwfYSDhKhMCGG81P6XrKWT0mj3 meVRlQW/gt5UxoSsPAoOEfBiGndVB5t7Tp9+TN5ksYPidmmqGsRYzbz1vkApMofVIzAA +7PA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=3JvZ9Ie5NQ9hlW8nV0upSjKfjUG6LhBqKdUkbVQTCM8=; b=HrDaEtlB5ONUWM9/XEJhB1KwerGoq4WxOJRnC/SofUYdoyV8zySKa3PbjsgDJ2Yagh lVRw4tQfQU5fEsX0HrbHCUFTKaUNJlpa3ZKcJbGliToUesJbus7P6oG9rapPcyNQBkHz GEU71BRJxAO9X3j3Uu0HM68BkDs12o7yDjLc0cONmMujHSufqxjmxkCvDhjBCvCqFT9w QUge7DVX+qPZ/at2jeMMqj7OwfAb5qRBVC2gs7YwNw5R7y0FBoC2A/LTA5BWkBJlTVfb vhv5kXycTJfQMmLji6JwifUtkgAIlRiwmfLljXVPpRNa/9L4wZkEIjDch+u5POWuO7E/ EBRQ== Received: by 10.50.161.234 with SMTP id xv10mr7913317igb.39.1345054848417; Wed, 15 Aug 2012 11:20:48 -0700 (PDT) Received: by 10.50.161.234 with SMTP id xv10mr7913273igb.39.1345054847592; Wed, 15 Aug 2012 11:20:47 -0700 (PDT) MIME-Version: 1.0 Received: by 10.50.237.67 with HTTP; Wed, 15 Aug 2012 11:20:07 -0700 (PDT) In-Reply-To: References: <812700A304640D4292205D5E83FC59E1061C211D@p-embx01-eq.jnpr.net> <3512BB31280C39448A9880F61DD54CEB09C07E@xmb-aln-x09.cisco.com> From: Edward Crabbe Date: Wed, 15 Aug 2012 11:20:07 -0700 Message-ID: To: Olen Stokes Content-Type: multipart/alternative; boundary=14dae93410c364e86604c751fc5d X-System-Of-Record: true X-Gm-Message-State: ALoCoQn5wpHd7SYl22cocUr1wzmkOpkF/Wlj2uMgyfDqDyiqkniRRQ/ky1jQeShUAPT493/6sHSL8PERGb2v/Xys+9exR1JTBFqGWTM0pV7UCxgapOXsLuu94kLsak74NaD9FXY0MNDj2ZC68oufbHplKR7DXrcv6rCH6AY/TuOVggndgvCpx106+NLb22whUmWeQ9uE5ILf Cc: "irs-discuss@ietf.org" , "David Lake \(dlake\)" , Alia Atlas 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Aug 2012 18:21:00 -0000 --14dae93410c364e86604c751fc5d Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable The software (interacting with the 'applications' and) generating the actual PDUs understood by the NEs. On Wed, Aug 15, 2012 at 10:30 AM, Olen Stokes wrote: > Thanks. Can you also give us what you mean by =93controller=94. **** > > ** ** > > Olen**** > > ** ** > > *From:* Edward Crabbe [mailto:edc@google.com] > *Sent:* Wednesday, August 15, 2012 1:24 PM > *To:* Alia Atlas > *Cc:* David Lake (dlake); Olen Stokes; irs-discuss@ietf.org > > *Subject:* Re: [irs-discuss] IRS comments**** > > ** ** > > s/wg/pre-BOF proto-wg :P/g **** > > On Wed, Aug 15, 2012 at 10:22 AM, Edward Crabbe wrote:**= * > * > > +1 Alia. There's been a lot of confusion over this term. Having gone a > few rounds with folks on this one in other forums, I'll point out that wh= at > most people mean by application (myself included) is some set of control > software (a scheduler, a path optimizer etc) that provides instructions = to > the controller, which are in turn translated to the appropriate PDUs.**** > > ** ** > > Having 'end user' applications request/make changes to forwarding state > without an intermediate broker/aggregator acting on their behalf sounds > like a recipe for disaster for operational networks, or, as is more likel= y, > a quick hike to the protocol grave yard (followed by a long grave-side > party :P) for the wg. **** > > ** ** > > my 2c. **** > > ** ** > > On Wed, Aug 15, 2012 at 8:48 AM, Alia Atlas wrote:***= * > > Hi David, > > We do need to clarify what is meant by an application. I would not > expect that real user-land applications would talk directly to routing > devices via IRS. I can see that going through an intermediary. The > IRS abstractions are unlikely to be as high-level as user-land > applications would want and the security and policy issues would get > exciting. > > Clarifying what applications are more in-scope initially is part of > where use-cases will help. Can you write up ones to > categorize/describe your thoughts? > > Alia**** > > > On Wed, Aug 15, 2012 at 11:40 AM, David Lake (dlake) > wrote: > > As another newbie to this, I have some questions about "application > vendors." > > > > Who is the target audience here ? That will determine what > functionality and abstraction of the network we need to expose to that > "application." > > > > This presently appears to be a little confused - at least in my mind. > The draft talks very much as if the application we are addressing is an > OSS/BSS system, essentially provisioning from the domain owner. > > > > However, linking this to the wider goals of SDN as voiced by > customers/users at the first Open Network Summit, there appears to be a > desire for cross-domain and user-land application integration. > > > > At this level - as an example giving a content cache the ability to > ensure delivery of an HD video to an end user - the application will not = be > interested in the underlying topology of the network; it will need to kn= ow > that application X can be delivered with parameters Y between reading fro= m > the content store to delivery to the user's browser. How the stream > traverses the infrastructure is immaterial. > > > > Are we intending that IRS satisfies BOTH these requirements (i.e. for > ALL applications ?), or should we be more prescriptive about which > application space we are addressing ? > > > > Thanks > > > > David > > > > -----Original Message----- > > From: irs-discuss-bounces@ietf.org [mailto:irs-discuss-bounces@ietf.org= ] > On Behalf Of Alia Atlas > > Sent: Wednesday, August 15, 2012 7:23 AM > > To: Olen Stokes > > Cc: irs-discuss@ietf.org > > Subject: Re: [irs-discuss] IRS comments > > > > I have not specifically heard from application vendors about this. > > My current plan is that we focus on a Use-Cases draft and define within > that some motivating use-cases that we agree are good first targets. Tho= se > can drive which subset of functionality we focus on. > > > > More use-cases are, of course, quite welcome. Posting them to the > mailing list is a good first start. Russ White is starting the general > use-cases draft based on the three use-cases that he sent to the list. > > > > Alia > > > > On Wed, Aug 15, 2012 at 9:43 AM, Olen Stokes < > ostokes@extremenetworks.com> wrote: > >> Are there applications vendors out there that already have specific > requirements for what this " subset of the data-models for sub-interfaces= " > should be? > >> > >> Olen > >> > >> -----Original Message----- > >> From: irs-discuss-bounces@ietf.org > >> [mailto:irs-discuss-bounces@ietf.org] On Behalf Of Alia Atlas > >> Sent: Wednesday, August 15, 2012 9:08 AM > >> To: Shah, Himanshu > >> Cc: Gert Grammel; irs-discuss@ietf.org; Lenny Giuliano; Thomas Nadeau; > >> Alia Atlas; Scott Whyte > >> Subject: Re: [irs-discuss] IRS comments > >> > >> Hi Himanshu, > >> > >> Welcome. I agree that IRS isn't going to spring into being fully > >> formed - I expect that we'll focus on a subset of the data-models for > sub-interfaces along with an associated protocol (whether that is a new o= ne > or extending an existing one). > >> > >> Alia > >> > >> On Wed, Aug 15, 2012 at 7:41 AM, Shah, Himanshu > wrote: > >>> Newbie to this discussions list and have read only a last couple of > mails, so pardon the repeat if somebody has already raised the following = as > a concern. > >>> > >>> I realize we are early in IRS architecture definition but one thing t= o > keep in mind is the user experience. > >>> We need to make sure that exposed interface to > >>> RIB/LFIB/FIB/IGPs/BGP/LSDBs etc etc provide a consistent predictive > action/response/events even when different implementations has varying > capabilities. > >>> > >>> At the moment it seems like a wild wild west. > >>> Perhaps IRS can be defined in phases starting with a simpler, limited > version.. > >>> > >>> Thanks, > >>> himanshu > >>> > >>> > >>> -----Original Message----- > >>> From: irs-discuss-bounces@ietf.org > >>> [mailto:irs-discuss-bounces@ietf.org] On Behalf Of Alia Atlas > >>> Sent: Monday, August 13, 2012 8:41 AM > >>> To: Scott Whyte > >>> Cc: Thomas Nadeau; Gert Grammel; Alia Atlas; Lenny Giuliano; > >>> irs-discuss@ietf.org > >>> Subject: Re: [irs-discuss] IRS comments > >>> > >>> ...snip... > >>> > >>> On Fri, Aug 10, 2012 at 9:03 PM, Scott Whyte > wrote: > >>>> On Fri, Aug 10, 2012 at 5:16 PM, Alia Atlas > wrote: > >>> > >>>>> I do think it is important to have the RIB as an arbitration > mechanism > >>>>> on the device. Russ's suggestion that for the RIB sub-interface, > the > >>>>> IRS agent might communicate logically to an IRS routing process > >>>>> gives good semantics and interactions. Obviously, implementations > >>>>> may differ. > >>>> > >>>> As long as the arbitration mechanism is reconfigurable by the > >>>> operator to whatever precedence they want, I agree. Its not clear > >>>> to me if various RIB implementations treat all proffered routes the > >>>> same, nor if they store the same meta-data with all protocol sources= . > >>>> So there needs to be some way for the operator to leverage exposed > >>>> protocol-specific optimizations, without conflict from the other > >>>> routing processes, if they so desire. OTOH if it can all be done > >>>> via static routes, it seems much simpler. :) > >>> > >>> Clearly the IRS sub-interface for the RIB needs to introduce/define > the different precedences; my assumption is that it would be per route wi= th > a well-defined small set of meta-data. This is part of where having good > use-cases will help us understand what behavior is necessary. The static > routes do seem like a simpler case to start with. > >>> > >>> Alia > >>> _______________________________________________ > >>> 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 > > _______________________________________________ > > 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**** > > ** ** > > ** ** > --14dae93410c364e86604c751fc5d Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable The software (interacting with the 'applications' and) generating t= he actual PDUs understood by the NEs.=A0

On Wed, Aug 15, 2012 at 10:30 AM, Olen Stokes <ostokes@extremen= etworks.com> wrote:

Thanks.=A0 Ca= n you also give us what you mean by =93controller=94.=A0

=A0<= /p>

Olen

=A0<= /p>

From: Edwar= d Crabbe [mailto:edc@go= ogle.com]
Sent: Wednesday, August 15, 2012 1:24 PM
To: Alia AtlasCc: David Lake (dlake); Olen Stokes; irs-discuss@ietf.org


Subject: Re: [irs-discuss] IRS comments

=A0

=

s/wg/pre-BOF proto-wg= :P/g =A0

On Wed, Aug 15, 2012 at 10:22 AM, Edward Crabbe= <edc@google.com= > wrote:

+1 Alia. =A0There's= been a lot of confusion over this term. =A0Having gone a few rounds with f= olks on this one in other forums, I'll point out that what most people = mean by application (myself included) is some set of control software (a sc= heduler, a path optimizer etc) =A0that provides instructions to the control= ler, which are in turn translated to the appropriate PDUs.

=A0

Having 'end user' applications request/make changes to forw= arding state without an intermediate broker/aggregator acting on their beha= lf sounds like a recipe for disaster for operational networks, or, as is mo= re likely, a quick hike to the protocol grave yard (followed by a long grav= e-side party :P) for the wg. =A0

=A0

my 2c.=A0

=A0

On Wed, Aug 15,= 2012 at 8:48 AM, Alia Atlas <akatlas@gmail.com> wrote:

Hi David,

We do need to clarify what is meant= by an application. =A0I would not
expect that real user-land applicatio= ns would talk directly to routing
devices via IRS. =A0I can see that goi= ng through an intermediary. =A0The
IRS abstractions are unlikely to be as high-level as user-land
applicati= ons would want and the security and policy issues would get
exciting.
Clarifying what applications are more in-scope initially is part of where use-cases will help. =A0Can you write up ones to
categorize/descri= be your thoughts?

Alia


On Wed, Aug 15, 2012 at 11:40= AM, David Lake (dlake) <dlake@cisco.com> wrote:
> As another newbie to this, I have some questions about "applicati= on vendors."
>
> Who is the target audience here ? =A0 Tha= t will determine what functionality and abstraction of the network we need = to expose to that "application."
>
> This presently appears to be a little confused - at least in m= y mind. =A0The draft talks very much as if the application we are addressin= g is an OSS/BSS system, essentially provisioning from the domain owner.
>
> However, linking this to the wider goals of SDN as voiced by c= ustomers/users at the first Open Network Summit, there appears to be a desi= re for cross-domain and user-land application integration.
>
> At this level - as an example giving a content cache the ability to en= sure delivery of an HD video to an end user - the application will not be i= nterested in the underlying topology of the network; it will =A0need to kno= w that application X can be delivered with parameters Y between reading fro= m the content store to delivery to the user's browser. =A0 How the stre= am traverses the infrastructure is immaterial.
>
> Are we intending that IRS satisfies BOTH these requirements (i= .e. for ALL applications ?), or should we be more prescriptive about which = application space we are addressing ?
>
> Thanks
>
> David
>
> -----Original Message-----
> From: irs-discuss-boun= ces@ietf.org [mailto:irs-discuss-bounces@ietf.org] On Behalf Of Alia Atlas > Sent: Wednesday, August 15, 2012 7:23 AM
> To: Olen Stokes
&g= t; Cc: irs-discus= s@ietf.org
> Subject: Re: [irs-discuss] IRS comments
>
> I have not specifically heard from application vendors about this.
> My current plan is that we focus on a Use-Cases draft and define withi= n that some motivating use-cases that we agree are good first targets. =A0T= hose can drive which subset of functionality we focus on.
>
> M= ore use-cases are, of course, quite welcome. =A0Posting them to the mailing= list is a good first start. =A0Russ White is starting the general use-case= s draft based on the three use-cases that he sent to the list.
>
> Alia
>
> On Wed, Aug 15, 2012 at 9:43 AM, Olen Sto= kes <os= tokes@extremenetworks.com> wrote:
>> Are there applications= vendors out there that already have specific requirements for what this &q= uot; subset of the data-models for sub-interfaces" =A0should be?
>>
>> Olen
>>
>> -----Original Message----= -
>> From: irs-discuss-bounces@ietf.org
>> [mailto:irs-discuss-bounces= @ietf.org] On Behalf Of Alia Atlas
>> Sent: Wednesday, August 15, 2012 9:08 AM
>> To: Shah, Him= anshu
>> Cc: Gert Grammel; irs-discuss@ietf.org; Lenny Giuliano; Thomas Nadeau;=
>> Alia Atlas; Scott Whyte
>> Subject: Re: [irs-discuss] IRS= comments
>>
>> Hi Himanshu,
>>
>> Welc= ome. =A0 I agree that IRS isn't going to spring into being fully
>> formed - I expect that we'll focus on a subset of the data-mod= els for sub-interfaces along with an associated protocol (whether that is a= new one or extending an existing one).
>>
>> Alia
>>
>> On Wed, Aug 15, 2012 at 7= :41 AM, Shah, Himanshu <hshah@ciena.com> wrote:
>>> Newbie to this discussi= ons list and have read only a last couple of mails, so pardon the repeat if= somebody has already raised the following as a concern.
>>>
>>> I realize we are early in IRS architecture def= inition but one thing to keep in mind is the user experience.
>>&g= t; We need to make sure that exposed interface to
>>> RIB/LFIB/= FIB/IGPs/BGP/LSDBs etc etc =A0provide a consistent predictive action/respon= se/events even when different implementations has varying capabilities.
>>>
>>> At the moment it seems like a wild wild west.<= br>>>> Perhaps IRS can be defined in phases starting with a simple= r, limited version..
>>>
>>> Thanks,
>>>= ; himanshu
>>>
>>>
>>> -----Original Message-----
= >>> From: irs-discuss-bounces@ietf.org
>>> [mailto:irs-discuss-bou= nces@ietf.org] On Behalf Of Alia Atlas
>>> Sent: Monday, August 13, 2012 8:41 AM
>>> To: Scot= t Whyte
>>> Cc: Thomas Nadeau; Gert Grammel; Alia Atlas; Lenny = Giuliano;
>>> irs-discuss@ietf.org
>>> Subject: Re: [irs-discuss] IRS comments
>>>
>= ;>> ...snip...
>>>
>>> On Fri, Aug 10, 2012 a= t 9:03 PM, Scott Whyte <swhyte@google.com> wrote:
>>>> On Fri, Aug 10, 2012 at 5:16 PM, Alia Atlas <akatlas@gmail.com> wrot= e:
>>>
>>>>> I do think it is important to ha= ve the RIB as an arbitration mechanism
>>>>> on the device. =A0 Russ's suggestion that for the = RIB sub-interface, the
>>>>> IRS agent might communicate = logically to an IRS routing process
>>>>> gives good sema= ntics and interactions. =A0Obviously, implementations
>>>>> may differ.
>>>>
>>>> As= long as the arbitration mechanism is reconfigurable by the
>>>= > operator to whatever precedence they want, I agree. =A0Its not clear >>>> to me if various RIB implementations treat all proffered r= outes the
>>>> same, nor if they store the same meta-data wi= th all protocol sources.
>>>> So there needs to be some way = for the operator to leverage exposed
>>>> protocol-specific optimizations, without conflict from the= other
>>>> routing processes, if they so desire. =A0OTOH if= it can all be done
>>>> via static routes, it seems much si= mpler. :)
>>>
>>> Clearly the IRS sub-interface for the RIB need= s to introduce/define the different precedences; my assumption is that it w= ould be per route with a well-defined small set of meta-data. =A0This is pa= rt of where having good use-cases will help us understand what behavior is = necessary. =A0The static =A0routes do seem like a simpler case to start wit= h.
>>>
>>> Alia
>>> _________________________= ______________________
>>> irs-discuss mailing list
>>= > irs-discuss@= ietf.org
>>> https://www.ietf.org/mailman/listinfo/irs-discuss
= >> _______________________________________________
>> irs-di= scuss mailing list
>> irs-disc= uss@ietf.org
>> https://www.ietf.org/mailman/listinfo/irs= -discuss
> _______________________________________________
> irs-discuss ma= iling list
> irs-discuss@ietf.org
> https://www.ietf.org/mailman/listin= fo/irs-discuss
_______________________________________________
irs-discuss mailing list=
irs-discuss@i= etf.org
https://www.ietf.org/mailman/listinfo/irs-discuss

=A0

<= /div>

=A0


--14dae93410c364e86604c751fc5d-- Return-Path: 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 98D9F21F86C9 for ; Wed, 15 Aug 2012 10:49:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.558 X-Spam-Level: X-Spam-Status: No, score=-3.558 tagged_above=-999 required=5 tests=[AWL=0.041, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8loPJOyyihSL for ; Wed, 15 Aug 2012 10:48:59 -0700 (PDT) Received: from mail-gg0-f172.google.com (mail-gg0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 5D78421F86C6 for ; Wed, 15 Aug 2012 10:48:59 -0700 (PDT) Received: by ggnh4 with SMTP id h4so2245940ggn.31 for ; Wed, 15 Aug 2012 10:48:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=ttB1kAcTkd0yzEdkP2BUg2qIFg2QdeEKrv2mnfkN4gE=; b=peJ93VJdgVYEYAplPdGWNyu8cYgdENLLra/ie5l8tcy+K9dvKLtdV/mGOjI7XfVmQV NNGrP5AJ3zPIfKmkjSuLjkF6IcAcViQR6xMpkq0EOegtRYV96JTzi/faMAXq07y9nLOK LNdioTCDhevbtkMrDM28aC/YlKTqvjkHzthvEnNUNRzYrUt+t3ySlEa/d6FAVteUOC35 kfJroPCkLjGpdWkJV21tCjwQMloFxnp4z1pmJdT5vwrEwRSYGJhAR2Q8vnGWLkhDPZq+ hnF4UcG/lSRoZqaogjgZu1kLieJ9Am7bE31+xqq6yrqxYQ0o/qMhq13WxjXKGjGoYXh/ iPmg== MIME-Version: 1.0 Received: by 10.50.237.38 with SMTP id uz6mr19476786igc.2.1345052938743; Wed, 15 Aug 2012 10:48:58 -0700 (PDT) Received: by 10.50.91.135 with HTTP; Wed, 15 Aug 2012 10:48:58 -0700 (PDT) In-Reply-To: <3512BB31280C39448A9880F61DD54CEB09C6A2@xmb-aln-x09.cisco.com> References: <812700A304640D4292205D5E83FC59E1061C211D@p-embx01-eq.jnpr.net> <3512BB31280C39448A9880F61DD54CEB09C07E@xmb-aln-x09.cisco.com> <3512BB31280C39448A9880F61DD54CEB09C530@xmb-aln-x09.cisco.com> <3512BB31280C39448A9880F61DD54CEB09C6A2@xmb-aln-x09.cisco.com> Date: Wed, 15 Aug 2012 13:48:58 -0400 Message-ID: From: Alia Atlas To: "David Lake (dlake)" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Olen Stokes , "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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Aug 2012 17:49:00 -0000 Sounds good. Let me know if/when you'd like me to review it. Alia On Wed, Aug 15, 2012 at 1:38 PM, David Lake (dlake) wrote= : > HI Alia > > OK - I'll work on a user-land use-case, and we'll try and factor where IR= S sits. > > I think that will definitely help define which applications IRS is releva= nt for, and maybe give pointers to where additional work could be applied. > > Thanks ! > > David > > -----Original Message----- > From: Alia Atlas [mailto:akatlas@gmail.com] > Sent: Wednesday, August 15, 2012 10:36 AM > To: David Lake (dlake) > Cc: Olen Stokes; irs-discuss@ietf.org > Subject: Re: [irs-discuss] IRS comments > > Hi David, > > I agree that the abstractions that are appropriate for a higher layer app= lication are probably not those appropriate for IRS, where some understandi= ng of the routing system, learnt topology, etc, are appropriate. > > If we do it right, the IRS protocol might be able to work with different = data-models representing those - but I think considering such data-models i= s quite out-of-scope. Let's let IRS get real legs and definition. I don't= think it makes sense to fold those requirements and use-cases into IRS - e= ven though the same protocol might eventually suffice. > > That said, if you have a model where there's an intermediary (where orche= strator, service-specific app, controller, etc) that can do the translation= , such use-cases would be of interest. I'm certainly interested in verifyi= ng that top-down use-cases can connect up with the information and controls= that IRS is intended to provide. > > Alia > > On Wed, Aug 15, 2012 at 1:11 PM, David Lake (dlake) wro= te: >> Hi Alia >> >> I already have some use-cases in mind for network service delivery and I= 'll work on writing them up. >> >> It does appear that the application that the current IRS draft refers to= is management and provisioning within the SP domain. Whilst I agree that = these are areas in need to standardisation and enhancement, this could be s= een as a sub-set of the wider application integration to the transport laye= r that is needed - a use-case, if you will. >> >> The underlying principles of IRS as put out in the draft does appear to = provide an extensible, scalable protocol that would appeal to generic appli= cation providers - what will be key is to ensure that the primitives provid= ed to/from the application are relevant and in terms that an application pr= ovider would understand. It is unlikely that the nuances of routing will = be of any interest to most applications. >> >> One possible solution to this is to create another protocol similar and = related to IRS that represents the entirety of the transport infrastructure= between content and consumer in terms that are relevant to the application= . However, I want to avoid creating yet another layer with the associated= RPC complexities - that will not assist with long-term adoption. >> >> So, I am wondering if IRS can become a more broad-based representative p= rotocol with one defined use-case being the kind of lower-level RP integrat= ion that is currently envisaged ? >> >> David >> >> -----Original Message----- >> From: Alia Atlas [mailto:akatlas@gmail.com] >> Sent: Wednesday, August 15, 2012 8:48 AM >> To: David Lake (dlake) >> Cc: Olen Stokes; irs-discuss@ietf.org >> Subject: Re: [irs-discuss] IRS comments >> >> Hi David, >> >> We do need to clarify what is meant by an application. I would not expe= ct that real user-land applications would talk directly to routing devices = via IRS. I can see that going through an intermediary. The IRS abstractio= ns are unlikely to be as high-level as user-land applications would want an= d the security and policy issues would get exciting. >> >> Clarifying what applications are more in-scope initially is part of wher= e use-cases will help. Can you write up ones to categorize/describe your t= houghts? >> >> Alia >> >> On Wed, Aug 15, 2012 at 11:40 AM, David Lake (dlake) w= rote: >>> As another newbie to this, I have some questions about "application ven= dors." >>> >>> Who is the target audience here ? That will determine what functional= ity and abstraction of the network we need to expose to that "application." >>> >>> This presently appears to be a little confused - at least in my mind. = The draft talks very much as if the application we are addressing is an OSS= /BSS system, essentially provisioning from the domain owner. >>> >>> However, linking this to the wider goals of SDN as voiced by customers/= users at the first Open Network Summit, there appears to be a desire for cr= oss-domain and user-land application integration. >>> >>> At this level - as an example giving a content cache the ability to ens= ure delivery of an HD video to an end user - the application will not be in= terested in the underlying topology of the network; it will need to know t= hat application X can be delivered with parameters Y between reading from t= he content store to delivery to the user's browser. How the stream traver= ses the infrastructure is immaterial. >>> >>> Are we intending that IRS satisfies BOTH these requirements (i.e. for A= LL applications ?), or should we be more prescriptive about which applicati= on space we are addressing ? >>> >>> Thanks >>> >>> David >>> >>> -----Original Message----- >>> From: irs-discuss-bounces@ietf.org >>> [mailto:irs-discuss-bounces@ietf.org] On Behalf Of Alia Atlas >>> Sent: Wednesday, August 15, 2012 7:23 AM >>> To: Olen Stokes >>> Cc: irs-discuss@ietf.org >>> Subject: Re: [irs-discuss] IRS comments >>> >>> I have not specifically heard from application vendors about this. >>> My current plan is that we focus on a Use-Cases draft and define within= that some motivating use-cases that we agree are good first targets. Thos= e can drive which subset of functionality we focus on. >>> >>> More use-cases are, of course, quite welcome. Posting them to the mail= ing list is a good first start. Russ White is starting the general use-cas= es draft based on the three use-cases that he sent to the list. >>> >>> Alia >>> >>> On Wed, Aug 15, 2012 at 9:43 AM, Olen Stokes wrote: >>>> Are there applications vendors out there that already have specific re= quirements for what this " subset of the data-models for sub-interfaces" s= hould be? >>>> >>>> Olen >>>> >>>> -----Original Message----- >>>> From: irs-discuss-bounces@ietf.org >>>> [mailto:irs-discuss-bounces@ietf.org] On Behalf Of Alia Atlas >>>> Sent: Wednesday, August 15, 2012 9:08 AM >>>> To: Shah, Himanshu >>>> Cc: Gert Grammel; irs-discuss@ietf.org; Lenny Giuliano; Thomas >>>> Nadeau; Alia Atlas; Scott Whyte >>>> Subject: Re: [irs-discuss] IRS comments >>>> >>>> Hi Himanshu, >>>> >>>> Welcome. I agree that IRS isn't going to spring into being fully >>>> formed - I expect that we'll focus on a subset of the data-models for = sub-interfaces along with an associated protocol (whether that is a new one= or extending an existing one). >>>> >>>> Alia >>>> >>>> On Wed, Aug 15, 2012 at 7:41 AM, Shah, Himanshu wrot= e: >>>>> Newbie to this discussions list and have read only a last couple of m= ails, so pardon the repeat if somebody has already raised the following as = a concern. >>>>> >>>>> I realize we are early in IRS architecture definition but one thing t= o keep in mind is the user experience. >>>>> We need to make sure that exposed interface to >>>>> RIB/LFIB/FIB/IGPs/BGP/LSDBs etc etc provide a consistent predictive = action/response/events even when different implementations has varying capa= bilities. >>>>> >>>>> At the moment it seems like a wild wild west. >>>>> Perhaps IRS can be defined in phases starting with a simpler, limited= version.. >>>>> >>>>> Thanks, >>>>> himanshu >>>>> >>>>> >>>>> -----Original Message----- >>>>> From: irs-discuss-bounces@ietf.org >>>>> [mailto:irs-discuss-bounces@ietf.org] On Behalf Of Alia Atlas >>>>> Sent: Monday, August 13, 2012 8:41 AM >>>>> To: Scott Whyte >>>>> Cc: Thomas Nadeau; Gert Grammel; Alia Atlas; Lenny Giuliano; >>>>> irs-discuss@ietf.org >>>>> Subject: Re: [irs-discuss] IRS comments >>>>> >>>>> ...snip... >>>>> >>>>> On Fri, Aug 10, 2012 at 9:03 PM, Scott Whyte wrot= e: >>>>>> On Fri, Aug 10, 2012 at 5:16 PM, Alia Atlas wrot= e: >>>>> >>>>>>> I do think it is important to have the RIB as an arbitration mechan= ism >>>>>>> on the device. Russ's suggestion that for the RIB sub-interface, = the >>>>>>> IRS agent might communicate logically to an IRS routing process >>>>>>> gives good semantics and interactions. Obviously, >>>>>>> implementations may differ. >>>>>> >>>>>> As long as the arbitration mechanism is reconfigurable by the >>>>>> operator to whatever precedence they want, I agree. Its not clear >>>>>> to me if various RIB implementations treat all proffered routes >>>>>> the same, nor if they store the same meta-data with all protocol sou= rces. >>>>>> So there needs to be some way for the operator to leverage exposed >>>>>> protocol-specific optimizations, without conflict from the other >>>>>> routing processes, if they so desire. OTOH if it can all be done >>>>>> via static routes, it seems much simpler. :) >>>>> >>>>> Clearly the IRS sub-interface for the RIB needs to introduce/define t= he different precedences; my assumption is that it would be per route with = a well-defined small set of meta-data. This is part of where having good u= se-cases will help us understand what behavior is necessary. The static r= outes do seem like a simpler case to start with. >>>>> >>>>> Alia >>>>> _______________________________________________ >>>>> 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 >>> _______________________________________________ >>> irs-discuss mailing list >>> irs-discuss@ietf.org >>> https://www.ietf.org/mailman/listinfo/irs-discuss Return-Path: 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 7AC1E21F8691 for ; Wed, 15 Aug 2012 10:38:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JkXgbgcAedfz for ; Wed, 15 Aug 2012 10:38:38 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 3BF7121F8634 for ; Wed, 15 Aug 2012 10:38:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dlake@cisco.com; l=10137; q=dns/txt; s=iport; t=1345052318; x=1346261918; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=t++lbk9jf1vmN7oSOQPNsvuqykaXVKWw+sPWuvJljok=; b=nEfghqNjAhm394PbkMB6WsxMl6KwT19B/hS6DRTa3CdZ06HE3lTdIIHQ ktKLxV1FjLMJGdw0AFYU+etOjgxL4XYPbtMGod2at0+6rHWL89qgytq+H Ecpt+gdaUI6LqKZD6Sfkq0mqLj+LdeLnKy4sIVQ6ZGhTfld5sNRWiYw4F c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAH7dK1CtJXHB/2dsb2JhbABFuheBB4IgAQEBBAEBAQ8BJzQLDAQCAQgOAwEDAQEBChQJByEGCxQDBggCBA4FCBMHh1wDCwELmgOWdA2JSgSKJGQUhWNgA5FpOIFbjF+DIIFmgl+BVg X-IronPort-AV: E=Sophos;i="4.77,774,1336348800"; d="scan'208";a="111871799" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-2.cisco.com with ESMTP; 15 Aug 2012 17:38:37 +0000 Received: from xhc-rcd-x02.cisco.com (xhc-rcd-x02.cisco.com [173.37.183.76]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id q7FHcae8016024 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 15 Aug 2012 17:38:36 GMT Received: from xmb-aln-x09.cisco.com ([169.254.4.26]) by xhc-rcd-x02.cisco.com ([173.37.183.76]) with mapi id 14.02.0298.004; Wed, 15 Aug 2012 12:38:34 -0500 From: "David Lake (dlake)" To: Alia Atlas Thread-Topic: [irs-discuss] IRS comments Thread-Index: Ac15UPmWZFj3YBmsT9Smjrge48ksHAATypTAAFwtz4AAAUAUgAABZOIAAAg193D//9YNAIAAP9Og///eRoCAAFOO8A== Date: Wed, 15 Aug 2012 17:38:32 +0000 Message-ID: <3512BB31280C39448A9880F61DD54CEB09C6A2@xmb-aln-x09.cisco.com> References: <812700A304640D4292205D5E83FC59E1061C211D@p-embx01-eq.jnpr.net> <3512BB31280C39448A9880F61DD54CEB09C07E@xmb-aln-x09.cisco.com> <3512BB31280C39448A9880F61DD54CEB09C530@xmb-aln-x09.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [171.71.119.1] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19114.006 x-tm-as-result: No--50.974800-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Olen Stokes , "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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Aug 2012 17:38:39 -0000 HI Alia OK - I'll work on a user-land use-case, and we'll try and factor where IRS = sits. I think that will definitely help define which applications IRS is relevant= for, and maybe give pointers to where additional work could be applied. Thanks ! David -----Original Message----- From: Alia Atlas [mailto:akatlas@gmail.com]=20 Sent: Wednesday, August 15, 2012 10:36 AM To: David Lake (dlake) Cc: Olen Stokes; irs-discuss@ietf.org Subject: Re: [irs-discuss] IRS comments Hi David, I agree that the abstractions that are appropriate for a higher layer appli= cation are probably not those appropriate for IRS, where some understanding= of the routing system, learnt topology, etc, are appropriate. If we do it right, the IRS protocol might be able to work with different da= ta-models representing those - but I think considering such data-models is = quite out-of-scope. Let's let IRS get real legs and definition. I don't t= hink it makes sense to fold those requirements and use-cases into IRS - eve= n though the same protocol might eventually suffice. That said, if you have a model where there's an intermediary (where orchest= rator, service-specific app, controller, etc) that can do the translation, = such use-cases would be of interest. I'm certainly interested in verifying= that top-down use-cases can connect up with the information and controls t= hat IRS is intended to provide. Alia On Wed, Aug 15, 2012 at 1:11 PM, David Lake (dlake) wrote= : > Hi Alia > > I already have some use-cases in mind for network service delivery and I'= ll work on writing them up. > > It does appear that the application that the current IRS draft refers to = is management and provisioning within the SP domain. Whilst I agree that t= hese are areas in need to standardisation and enhancement, this could be se= en as a sub-set of the wider application integration to the transport layer= that is needed - a use-case, if you will. > > The underlying principles of IRS as put out in the draft does appear to p= rovide an extensible, scalable protocol that would appeal to generic applic= ation providers - what will be key is to ensure that the primitives provide= d to/from the application are relevant and in terms that an application pro= vider would understand. It is unlikely that the nuances of routing will b= e of any interest to most applications. > > One possible solution to this is to create another protocol similar and r= elated to IRS that represents the entirety of the transport infrastructure = between content and consumer in terms that are relevant to the application.= However, I want to avoid creating yet another layer with the associated = RPC complexities - that will not assist with long-term adoption. > > So, I am wondering if IRS can become a more broad-based representative pr= otocol with one defined use-case being the kind of lower-level RP integrati= on that is currently envisaged ? > > David > > -----Original Message----- > From: Alia Atlas [mailto:akatlas@gmail.com] > Sent: Wednesday, August 15, 2012 8:48 AM > To: David Lake (dlake) > Cc: Olen Stokes; irs-discuss@ietf.org > Subject: Re: [irs-discuss] IRS comments > > Hi David, > > We do need to clarify what is meant by an application. I would not expec= t that real user-land applications would talk directly to routing devices v= ia IRS. I can see that going through an intermediary. The IRS abstraction= s are unlikely to be as high-level as user-land applications would want and= the security and policy issues would get exciting. > > Clarifying what applications are more in-scope initially is part of where= use-cases will help. Can you write up ones to categorize/describe your th= oughts? > > Alia > > On Wed, Aug 15, 2012 at 11:40 AM, David Lake (dlake) wr= ote: >> As another newbie to this, I have some questions about "application vend= ors." >> >> Who is the target audience here ? That will determine what functionali= ty and abstraction of the network we need to expose to that "application." >> >> This presently appears to be a little confused - at least in my mind. T= he draft talks very much as if the application we are addressing is an OSS/= BSS system, essentially provisioning from the domain owner. >> >> However, linking this to the wider goals of SDN as voiced by customers/u= sers at the first Open Network Summit, there appears to be a desire for cro= ss-domain and user-land application integration. >> >> At this level - as an example giving a content cache the ability to ensu= re delivery of an HD video to an end user - the application will not be int= erested in the underlying topology of the network; it will need to know th= at application X can be delivered with parameters Y between reading from th= e content store to delivery to the user's browser. How the stream travers= es the infrastructure is immaterial. >> >> Are we intending that IRS satisfies BOTH these requirements (i.e. for AL= L applications ?), or should we be more prescriptive about which applicatio= n space we are addressing ? >> >> Thanks >> >> David >> >> -----Original Message----- >> From: irs-discuss-bounces@ietf.org >> [mailto:irs-discuss-bounces@ietf.org] On Behalf Of Alia Atlas >> Sent: Wednesday, August 15, 2012 7:23 AM >> To: Olen Stokes >> Cc: irs-discuss@ietf.org >> Subject: Re: [irs-discuss] IRS comments >> >> I have not specifically heard from application vendors about this. >> My current plan is that we focus on a Use-Cases draft and define within = that some motivating use-cases that we agree are good first targets. Those= can drive which subset of functionality we focus on. >> >> More use-cases are, of course, quite welcome. Posting them to the maili= ng list is a good first start. Russ White is starting the general use-case= s draft based on the three use-cases that he sent to the list. >> >> Alia >> >> On Wed, Aug 15, 2012 at 9:43 AM, Olen Stokes wrote: >>> Are there applications vendors out there that already have specific req= uirements for what this " subset of the data-models for sub-interfaces" sh= ould be? >>> >>> Olen >>> >>> -----Original Message----- >>> From: irs-discuss-bounces@ietf.org >>> [mailto:irs-discuss-bounces@ietf.org] On Behalf Of Alia Atlas >>> Sent: Wednesday, August 15, 2012 9:08 AM >>> To: Shah, Himanshu >>> Cc: Gert Grammel; irs-discuss@ietf.org; Lenny Giuliano; Thomas=20 >>> Nadeau; Alia Atlas; Scott Whyte >>> Subject: Re: [irs-discuss] IRS comments >>> >>> Hi Himanshu, >>> >>> Welcome. I agree that IRS isn't going to spring into being fully >>> formed - I expect that we'll focus on a subset of the data-models for s= ub-interfaces along with an associated protocol (whether that is a new one = or extending an existing one). >>> >>> Alia >>> >>> On Wed, Aug 15, 2012 at 7:41 AM, Shah, Himanshu wrote= : >>>> Newbie to this discussions list and have read only a last couple of ma= ils, so pardon the repeat if somebody has already raised the following as a= concern. >>>> >>>> I realize we are early in IRS architecture definition but one thing to= keep in mind is the user experience. >>>> We need to make sure that exposed interface to=20 >>>> RIB/LFIB/FIB/IGPs/BGP/LSDBs etc etc provide a consistent predictive a= ction/response/events even when different implementations has varying capab= ilities. >>>> >>>> At the moment it seems like a wild wild west. >>>> Perhaps IRS can be defined in phases starting with a simpler, limited = version.. >>>> >>>> Thanks, >>>> himanshu >>>> >>>> >>>> -----Original Message----- >>>> From: irs-discuss-bounces@ietf.org >>>> [mailto:irs-discuss-bounces@ietf.org] On Behalf Of Alia Atlas >>>> Sent: Monday, August 13, 2012 8:41 AM >>>> To: Scott Whyte >>>> Cc: Thomas Nadeau; Gert Grammel; Alia Atlas; Lenny Giuliano;=20 >>>> irs-discuss@ietf.org >>>> Subject: Re: [irs-discuss] IRS comments >>>> >>>> ...snip... >>>> >>>> On Fri, Aug 10, 2012 at 9:03 PM, Scott Whyte wrote= : >>>>> On Fri, Aug 10, 2012 at 5:16 PM, Alia Atlas wrote= : >>>> >>>>>> I do think it is important to have the RIB as an arbitration mechani= sm >>>>>> on the device. Russ's suggestion that for the RIB sub-interface, t= he >>>>>> IRS agent might communicate logically to an IRS routing process=20 >>>>>> gives good semantics and interactions. Obviously,=20 >>>>>> implementations may differ. >>>>> >>>>> As long as the arbitration mechanism is reconfigurable by the=20 >>>>> operator to whatever precedence they want, I agree. Its not clear=20 >>>>> to me if various RIB implementations treat all proffered routes=20 >>>>> the same, nor if they store the same meta-data with all protocol sour= ces. >>>>> So there needs to be some way for the operator to leverage exposed=20 >>>>> protocol-specific optimizations, without conflict from the other=20 >>>>> routing processes, if they so desire. OTOH if it can all be done=20 >>>>> via static routes, it seems much simpler. :) >>>> >>>> Clearly the IRS sub-interface for the RIB needs to introduce/define th= e different precedences; my assumption is that it would be per route with a= well-defined small set of meta-data. This is part of where having good us= e-cases will help us understand what behavior is necessary. The static ro= utes do seem like a simpler case to start with. >>>> >>>> Alia >>>> _______________________________________________ >>>> 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 >> _______________________________________________ >> irs-discuss mailing list >> irs-discuss@ietf.org >> https://www.ietf.org/mailman/listinfo/irs-discuss Return-Path: 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 CB8A621F84F1 for ; Wed, 15 Aug 2012 10:36:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.558 X-Spam-Level: X-Spam-Status: No, score=-3.558 tagged_above=-999 required=5 tests=[AWL=0.041, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jg9bLWE7cEt3 for ; Wed, 15 Aug 2012 10:36:58 -0700 (PDT) Received: from mail-gh0-f172.google.com (mail-gh0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id C752D21F84E1 for ; Wed, 15 Aug 2012 10:36:57 -0700 (PDT) Received: by ghbg16 with SMTP id g16so2228536ghb.31 for ; Wed, 15 Aug 2012 10:36:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=cXQ7kupgSv5Gbh5JkVPHkTBfuQk8bHNTtno700CjVtQ=; b=vdYeuVmZ1ds/tlfRF1spOOSsh/SyYyZl+n7G3Yxs/8dv8/s9+qzP7/I46Hh9irwX2/ DhFIKFnzBWpYjKmVhCMz4cBr0iiFIfofvOndAz0siOwaX2mVCpqIcd5IL2O6ZODx4z4b vK9lFYD7zaLf4rGC+2KQCV1G8XP45OwRnTDmUhcd2zjNQIlD1PnHtFQv9KoqeABkFxqs b+UGUqO98wfpJdkq03AFjJIaXnYXNnsUzCCCh2sgpz1urdPlTLcMt9FphdeVD4HkJPUS P51MGTphbneaqFwyWf/AepTm1Uvi6aRZiycGjCmnoU/ZIkGNM1m6wD5pbyphAFfe/WCl AiZw== MIME-Version: 1.0 Received: by 10.50.183.200 with SMTP id eo8mr19819104igc.63.1345052216685; Wed, 15 Aug 2012 10:36:56 -0700 (PDT) Received: by 10.50.91.135 with HTTP; Wed, 15 Aug 2012 10:36:56 -0700 (PDT) In-Reply-To: References: <812700A304640D4292205D5E83FC59E1061C211D@p-embx01-eq.jnpr.net> <3512BB31280C39448A9880F61DD54CEB09C07E@xmb-aln-x09.cisco.com> Date: Wed, 15 Aug 2012 13:36:56 -0400 Message-ID: From: Alia Atlas To: Edward Crabbe Content-Type: text/plain; charset=ISO-8859-1 Cc: Olen Stokes , "David Lake \(dlake\)" , "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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Aug 2012 17:36:58 -0000 Want to write up a good clear definition to put in the problem-statement? I think that Chris Liljenstolpe is also working on that... Alia On Wed, Aug 15, 2012 at 1:22 PM, Edward Crabbe wrote: > +1 Alia. There's been a lot of confusion over this term. Having gone a few > rounds with folks on this one in other forums, I'll point out that what most > people mean by application (myself included) is some set of control software > (a scheduler, a path optimizer etc) that provides instructions to the > controller, which are in turn translated to the appropriate PDUs. > > Having 'end user' applications request/make changes to forwarding state > without an intermediate broker/aggregator acting on their behalf sounds like > a recipe for disaster for operational networks, or, as is more likely, a > quick hike to the protocol grave yard (followed by a long grave-side party > :P) for the wg. > > my 2c. > > On Wed, Aug 15, 2012 at 8:48 AM, Alia Atlas wrote: >> >> Hi David, >> >> We do need to clarify what is meant by an application. I would not >> expect that real user-land applications would talk directly to routing >> devices via IRS. I can see that going through an intermediary. The >> IRS abstractions are unlikely to be as high-level as user-land >> applications would want and the security and policy issues would get >> exciting. >> >> Clarifying what applications are more in-scope initially is part of >> where use-cases will help. Can you write up ones to >> categorize/describe your thoughts? >> >> Alia >> >> On Wed, Aug 15, 2012 at 11:40 AM, David Lake (dlake) >> wrote: >> > As another newbie to this, I have some questions about "application >> > vendors." >> > >> > Who is the target audience here ? That will determine what >> > functionality and abstraction of the network we need to expose to that >> > "application." >> > >> > This presently appears to be a little confused - at least in my mind. >> > The draft talks very much as if the application we are addressing is an >> > OSS/BSS system, essentially provisioning from the domain owner. >> > >> > However, linking this to the wider goals of SDN as voiced by >> > customers/users at the first Open Network Summit, there appears to be a >> > desire for cross-domain and user-land application integration. >> > >> > At this level - as an example giving a content cache the ability to >> > ensure delivery of an HD video to an end user - the application will not be >> > interested in the underlying topology of the network; it will need to know >> > that application X can be delivered with parameters Y between reading from >> > the content store to delivery to the user's browser. How the stream >> > traverses the infrastructure is immaterial. >> > >> > Are we intending that IRS satisfies BOTH these requirements (i.e. for >> > ALL applications ?), or should we be more prescriptive about which >> > application space we are addressing ? >> > >> > Thanks >> > >> > David >> > >> > -----Original Message----- >> > From: irs-discuss-bounces@ietf.org [mailto:irs-discuss-bounces@ietf.org] >> > On Behalf Of Alia Atlas >> > Sent: Wednesday, August 15, 2012 7:23 AM >> > To: Olen Stokes >> > Cc: irs-discuss@ietf.org >> > Subject: Re: [irs-discuss] IRS comments >> > >> > I have not specifically heard from application vendors about this. >> > My current plan is that we focus on a Use-Cases draft and define within >> > that some motivating use-cases that we agree are good first targets. Those >> > can drive which subset of functionality we focus on. >> > >> > More use-cases are, of course, quite welcome. Posting them to the >> > mailing list is a good first start. Russ White is starting the general >> > use-cases draft based on the three use-cases that he sent to the list. >> > >> > Alia >> > >> > On Wed, Aug 15, 2012 at 9:43 AM, Olen Stokes >> > wrote: >> >> Are there applications vendors out there that already have specific >> >> requirements for what this " subset of the data-models for sub-interfaces" >> >> should be? >> >> >> >> Olen >> >> >> >> -----Original Message----- >> >> From: irs-discuss-bounces@ietf.org >> >> [mailto:irs-discuss-bounces@ietf.org] On Behalf Of Alia Atlas >> >> Sent: Wednesday, August 15, 2012 9:08 AM >> >> To: Shah, Himanshu >> >> Cc: Gert Grammel; irs-discuss@ietf.org; Lenny Giuliano; Thomas Nadeau; >> >> Alia Atlas; Scott Whyte >> >> Subject: Re: [irs-discuss] IRS comments >> >> >> >> Hi Himanshu, >> >> >> >> Welcome. I agree that IRS isn't going to spring into being fully >> >> formed - I expect that we'll focus on a subset of the data-models for >> >> sub-interfaces along with an associated protocol (whether that is a new one >> >> or extending an existing one). >> >> >> >> Alia >> >> >> >> On Wed, Aug 15, 2012 at 7:41 AM, Shah, Himanshu >> >> wrote: >> >>> Newbie to this discussions list and have read only a last couple of >> >>> mails, so pardon the repeat if somebody has already raised the following as >> >>> a concern. >> >>> >> >>> I realize we are early in IRS architecture definition but one thing to >> >>> keep in mind is the user experience. >> >>> We need to make sure that exposed interface to >> >>> RIB/LFIB/FIB/IGPs/BGP/LSDBs etc etc provide a consistent predictive >> >>> action/response/events even when different implementations has varying >> >>> capabilities. >> >>> >> >>> At the moment it seems like a wild wild west. >> >>> Perhaps IRS can be defined in phases starting with a simpler, limited >> >>> version.. >> >>> >> >>> Thanks, >> >>> himanshu >> >>> >> >>> >> >>> -----Original Message----- >> >>> From: irs-discuss-bounces@ietf.org >> >>> [mailto:irs-discuss-bounces@ietf.org] On Behalf Of Alia Atlas >> >>> Sent: Monday, August 13, 2012 8:41 AM >> >>> To: Scott Whyte >> >>> Cc: Thomas Nadeau; Gert Grammel; Alia Atlas; Lenny Giuliano; >> >>> irs-discuss@ietf.org >> >>> Subject: Re: [irs-discuss] IRS comments >> >>> >> >>> ...snip... >> >>> >> >>> On Fri, Aug 10, 2012 at 9:03 PM, Scott Whyte >> >>> wrote: >> >>>> On Fri, Aug 10, 2012 at 5:16 PM, Alia Atlas >> >>>> wrote: >> >>> >> >>>>> I do think it is important to have the RIB as an arbitration >> >>>>> mechanism >> >>>>> on the device. Russ's suggestion that for the RIB sub-interface, >> >>>>> the >> >>>>> IRS agent might communicate logically to an IRS routing process >> >>>>> gives good semantics and interactions. Obviously, implementations >> >>>>> may differ. >> >>>> >> >>>> As long as the arbitration mechanism is reconfigurable by the >> >>>> operator to whatever precedence they want, I agree. Its not clear >> >>>> to me if various RIB implementations treat all proffered routes the >> >>>> same, nor if they store the same meta-data with all protocol sources. >> >>>> So there needs to be some way for the operator to leverage exposed >> >>>> protocol-specific optimizations, without conflict from the other >> >>>> routing processes, if they so desire. OTOH if it can all be done >> >>>> via static routes, it seems much simpler. :) >> >>> >> >>> Clearly the IRS sub-interface for the RIB needs to introduce/define >> >>> the different precedences; my assumption is that it would be per route with >> >>> a well-defined small set of meta-data. This is part of where having good >> >>> use-cases will help us understand what behavior is necessary. The static >> >>> routes do seem like a simpler case to start with. >> >>> >> >>> Alia >> >>> _______________________________________________ >> >>> 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 >> > _______________________________________________ >> > 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 > > Return-Path: 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 ED44A21F8413 for ; Wed, 15 Aug 2012 10:36:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.557 X-Spam-Level: X-Spam-Status: No, score=-3.557 tagged_above=-999 required=5 tests=[AWL=0.042, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cmIyeq6YNb5L for ; Wed, 15 Aug 2012 10:36:06 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id BC2ED21F84DD for ; Wed, 15 Aug 2012 10:36:04 -0700 (PDT) Received: by yenm5 with SMTP id m5so2220259yen.31 for ; Wed, 15 Aug 2012 10:36:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=LPoB9AQj0cAAUMz5vxRAUpjMibCVTFXK2xjnQvuee68=; b=Ve5cmSeIIX0BWJAhWl07Kn4VXRT71wmRGE19RAGRqt6vwYFrrafmiaMFMQFcBZ1GA3 StQefVJUD/Y/FluZGF7pkS7LNeIftb7p7TgtfM5X7O1zjrzEqEABGp9fSN/5WmT71Bnt V8wMQymhu5iDhaVsEsO0rE0JMx/fa2yIkIKRpIB8x7jSyjxuy/HMUnmsopO4naa5WXBb BVEZHvcwK+YYK20nt9tV9Mh7vIWUS+6rVf6dcOCNmcjHKwR+yABsdcHj9tDkzPveXAVo przYe96ssC7mtzbUce/99VitynYjFKxZrEqB3+HRfxLLTWdbS/e2Unfa6qC4X+vGt01B OtEg== MIME-Version: 1.0 Received: by 10.50.183.200 with SMTP id eo8mr19816249igc.63.1345052163744; Wed, 15 Aug 2012 10:36:03 -0700 (PDT) Received: by 10.50.91.135 with HTTP; Wed, 15 Aug 2012 10:36:03 -0700 (PDT) In-Reply-To: <3512BB31280C39448A9880F61DD54CEB09C530@xmb-aln-x09.cisco.com> References: <812700A304640D4292205D5E83FC59E1061C211D@p-embx01-eq.jnpr.net> <3512BB31280C39448A9880F61DD54CEB09C07E@xmb-aln-x09.cisco.com> <3512BB31280C39448A9880F61DD54CEB09C530@xmb-aln-x09.cisco.com> Date: Wed, 15 Aug 2012 13:36:03 -0400 Message-ID: From: Alia Atlas To: "David Lake (dlake)" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Olen Stokes , "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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Aug 2012 17:36:13 -0000 Hi David, I agree that the abstractions that are appropriate for a higher layer application are probably not those appropriate for IRS, where some understanding of the routing system, learnt topology, etc, are appropriate. If we do it right, the IRS protocol might be able to work with different data-models representing those - but I think considering such data-models is quite out-of-scope. Let's let IRS get real legs and definition. I don't think it makes sense to fold those requirements and use-cases into IRS - even though the same protocol might eventually suffice. That said, if you have a model where there's an intermediary (where orchestrator, service-specific app, controller, etc) that can do the translation, such use-cases would be of interest. I'm certainly interested in verifying that top-down use-cases can connect up with the information and controls that IRS is intended to provide. Alia On Wed, Aug 15, 2012 at 1:11 PM, David Lake (dlake) wrote= : > Hi Alia > > I already have some use-cases in mind for network service delivery and I'= ll work on writing them up. > > It does appear that the application that the current IRS draft refers to = is management and provisioning within the SP domain. Whilst I agree that t= hese are areas in need to standardisation and enhancement, this could be se= en as a sub-set of the wider application integration to the transport layer= that is needed - a use-case, if you will. > > The underlying principles of IRS as put out in the draft does appear to p= rovide an extensible, scalable protocol that would appeal to generic applic= ation providers - what will be key is to ensure that the primitives provide= d to/from the application are relevant and in terms that an application pro= vider would understand. It is unlikely that the nuances of routing will b= e of any interest to most applications. > > One possible solution to this is to create another protocol similar and r= elated to IRS that represents the entirety of the transport infrastructure = between content and consumer in terms that are relevant to the application.= However, I want to avoid creating yet another layer with the associated = RPC complexities - that will not assist with long-term adoption. > > So, I am wondering if IRS can become a more broad-based representative pr= otocol with one defined use-case being the kind of lower-level RP integrati= on that is currently envisaged ? > > David > > -----Original Message----- > From: Alia Atlas [mailto:akatlas@gmail.com] > Sent: Wednesday, August 15, 2012 8:48 AM > To: David Lake (dlake) > Cc: Olen Stokes; irs-discuss@ietf.org > Subject: Re: [irs-discuss] IRS comments > > Hi David, > > We do need to clarify what is meant by an application. I would not expec= t that real user-land applications would talk directly to routing devices v= ia IRS. I can see that going through an intermediary. The IRS abstraction= s are unlikely to be as high-level as user-land applications would want and= the security and policy issues would get exciting. > > Clarifying what applications are more in-scope initially is part of where= use-cases will help. Can you write up ones to categorize/describe your th= oughts? > > Alia > > On Wed, Aug 15, 2012 at 11:40 AM, David Lake (dlake) wr= ote: >> As another newbie to this, I have some questions about "application vend= ors." >> >> Who is the target audience here ? That will determine what functionali= ty and abstraction of the network we need to expose to that "application." >> >> This presently appears to be a little confused - at least in my mind. T= he draft talks very much as if the application we are addressing is an OSS/= BSS system, essentially provisioning from the domain owner. >> >> However, linking this to the wider goals of SDN as voiced by customers/u= sers at the first Open Network Summit, there appears to be a desire for cro= ss-domain and user-land application integration. >> >> At this level - as an example giving a content cache the ability to ensu= re delivery of an HD video to an end user - the application will not be int= erested in the underlying topology of the network; it will need to know th= at application X can be delivered with parameters Y between reading from th= e content store to delivery to the user's browser. How the stream travers= es the infrastructure is immaterial. >> >> Are we intending that IRS satisfies BOTH these requirements (i.e. for AL= L applications ?), or should we be more prescriptive about which applicatio= n space we are addressing ? >> >> Thanks >> >> David >> >> -----Original Message----- >> From: irs-discuss-bounces@ietf.org >> [mailto:irs-discuss-bounces@ietf.org] On Behalf Of Alia Atlas >> Sent: Wednesday, August 15, 2012 7:23 AM >> To: Olen Stokes >> Cc: irs-discuss@ietf.org >> Subject: Re: [irs-discuss] IRS comments >> >> I have not specifically heard from application vendors about this. >> My current plan is that we focus on a Use-Cases draft and define within = that some motivating use-cases that we agree are good first targets. Those= can drive which subset of functionality we focus on. >> >> More use-cases are, of course, quite welcome. Posting them to the maili= ng list is a good first start. Russ White is starting the general use-case= s draft based on the three use-cases that he sent to the list. >> >> Alia >> >> On Wed, Aug 15, 2012 at 9:43 AM, Olen Stokes wrote: >>> Are there applications vendors out there that already have specific req= uirements for what this " subset of the data-models for sub-interfaces" sh= ould be? >>> >>> Olen >>> >>> -----Original Message----- >>> From: irs-discuss-bounces@ietf.org >>> [mailto:irs-discuss-bounces@ietf.org] On Behalf Of Alia Atlas >>> Sent: Wednesday, August 15, 2012 9:08 AM >>> To: Shah, Himanshu >>> Cc: Gert Grammel; irs-discuss@ietf.org; Lenny Giuliano; Thomas >>> Nadeau; Alia Atlas; Scott Whyte >>> Subject: Re: [irs-discuss] IRS comments >>> >>> Hi Himanshu, >>> >>> Welcome. I agree that IRS isn't going to spring into being fully >>> formed - I expect that we'll focus on a subset of the data-models for s= ub-interfaces along with an associated protocol (whether that is a new one = or extending an existing one). >>> >>> Alia >>> >>> On Wed, Aug 15, 2012 at 7:41 AM, Shah, Himanshu wrote= : >>>> Newbie to this discussions list and have read only a last couple of ma= ils, so pardon the repeat if somebody has already raised the following as a= concern. >>>> >>>> I realize we are early in IRS architecture definition but one thing to= keep in mind is the user experience. >>>> We need to make sure that exposed interface to >>>> RIB/LFIB/FIB/IGPs/BGP/LSDBs etc etc provide a consistent predictive a= ction/response/events even when different implementations has varying capab= ilities. >>>> >>>> At the moment it seems like a wild wild west. >>>> Perhaps IRS can be defined in phases starting with a simpler, limited = version.. >>>> >>>> Thanks, >>>> himanshu >>>> >>>> >>>> -----Original Message----- >>>> From: irs-discuss-bounces@ietf.org >>>> [mailto:irs-discuss-bounces@ietf.org] On Behalf Of Alia Atlas >>>> Sent: Monday, August 13, 2012 8:41 AM >>>> To: Scott Whyte >>>> Cc: Thomas Nadeau; Gert Grammel; Alia Atlas; Lenny Giuliano; >>>> irs-discuss@ietf.org >>>> Subject: Re: [irs-discuss] IRS comments >>>> >>>> ...snip... >>>> >>>> On Fri, Aug 10, 2012 at 9:03 PM, Scott Whyte wrote= : >>>>> On Fri, Aug 10, 2012 at 5:16 PM, Alia Atlas wrote= : >>>> >>>>>> I do think it is important to have the RIB as an arbitration mechani= sm >>>>>> on the device. Russ's suggestion that for the RIB sub-interface, t= he >>>>>> IRS agent might communicate logically to an IRS routing process >>>>>> gives good semantics and interactions. Obviously, implementations >>>>>> may differ. >>>>> >>>>> As long as the arbitration mechanism is reconfigurable by the >>>>> operator to whatever precedence they want, I agree. Its not clear >>>>> to me if various RIB implementations treat all proffered routes the >>>>> same, nor if they store the same meta-data with all protocol sources. >>>>> So there needs to be some way for the operator to leverage exposed >>>>> protocol-specific optimizations, without conflict from the other >>>>> routing processes, if they so desire. OTOH if it can all be done >>>>> via static routes, it seems much simpler. :) >>>> >>>> Clearly the IRS sub-interface for the RIB needs to introduce/define th= e different precedences; my assumption is that it would be per route with a= well-defined small set of meta-data. This is part of where having good us= e-cases will help us understand what behavior is necessary. The static ro= utes do seem like a simpler case to start with. >>>> >>>> Alia >>>> _______________________________________________ >>>> 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 >> _______________________________________________ >> irs-discuss mailing list >> irs-discuss@ietf.org >> https://www.ietf.org/mailman/listinfo/irs-discuss Return-Path: 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 1294D21F8732 for ; Wed, 15 Aug 2012 10:30:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CxxXCPtaAFhA for ; Wed, 15 Aug 2012 10:30:23 -0700 (PDT) Received: from ussc-casht-p1.extremenetworks.com (ussc-casht-p1.extremenetworks.com [207.179.9.62]) by ietfa.amsl.com (Postfix) with ESMTP id 5C1B721F8724 for ; Wed, 15 Aug 2012 10:30:23 -0700 (PDT) Received: from USEXCHANGE.corp.extremenetworks.com ([10.0.4.74]) by ussc-casht-p1.corp.extremenetworks.com ([10.0.4.73]) with mapi; Wed, 15 Aug 2012 10:30:23 -0700 From: Olen Stokes To: Edward Crabbe , Alia Atlas Date: Wed, 15 Aug 2012 10:30:21 -0700 Thread-Topic: [irs-discuss] IRS comments Thread-Index: Ac17CumNRXBeBNRCSZOft8tf4DLXywAAFq5w Message-ID: References: <812700A304640D4292205D5E83FC59E1061C211D@p-embx01-eq.jnpr.net> <3512BB31280C39448A9880F61DD54CEB09C07E@xmb-aln-x09.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_A3C4E51A53661B4EBEE7C5F5E6FCDEB5025AB94FE847USEXCHANGEc_" MIME-Version: 1.0 Cc: "David Lake \(dlake\)" , "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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Aug 2012 17:30:26 -0000 --_000_A3C4E51A53661B4EBEE7C5F5E6FCDEB5025AB94FE847USEXCHANGEc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thanks. Can you also give us what you mean by "controller". Olen From: Edward Crabbe [mailto:edc@google.com] Sent: Wednesday, August 15, 2012 1:24 PM To: Alia Atlas Cc: David Lake (dlake); Olen Stokes; irs-discuss@ietf.org Subject: Re: [irs-discuss] IRS comments s/wg/pre-BOF proto-wg :P/g On Wed, Aug 15, 2012 at 10:22 AM, Edward Crabbe > wrote: +1 Alia. There's been a lot of confusion over this term. Having gone a fe= w rounds with folks on this one in other forums, I'll point out that what m= ost people mean by application (myself included) is some set of control sof= tware (a scheduler, a path optimizer etc) that provides instructions to th= e controller, which are in turn translated to the appropriate PDUs. Having 'end user' applications request/make changes to forwarding state wit= hout an intermediate broker/aggregator acting on their behalf sounds like a= recipe for disaster for operational networks, or, as is more likely, a qui= ck hike to the protocol grave yard (followed by a long grave-side party :P)= for the wg. my 2c. On Wed, Aug 15, 2012 at 8:48 AM, Alia Atlas > wrote: Hi David, We do need to clarify what is meant by an application. I would not expect that real user-land applications would talk directly to routing devices via IRS. I can see that going through an intermediary. The IRS abstractions are unlikely to be as high-level as user-land applications would want and the security and policy issues would get exciting. Clarifying what applications are more in-scope initially is part of where use-cases will help. Can you write up ones to categorize/describe your thoughts? Alia On Wed, Aug 15, 2012 at 11:40 AM, David Lake (dlake) > wrote: > As another newbie to this, I have some questions about "application vendo= rs." > > Who is the target audience here ? That will determine what functionalit= y and abstraction of the network we need to expose to that "application." > > This presently appears to be a little confused - at least in my mind. Th= e draft talks very much as if the application we are addressing is an OSS/B= SS system, essentially provisioning from the domain owner. > > However, linking this to the wider goals of SDN as voiced by customers/us= ers at the first Open Network Summit, there appears to be a desire for cros= s-domain and user-land application integration. > > At this level - as an example giving a content cache the ability to ensur= e delivery of an HD video to an end user - the application will not be inte= rested in the underlying topology of the network; it will need to know tha= t application X can be delivered with parameters Y between reading from the= content store to delivery to the user's browser. How the stream traverse= s the infrastructure is immaterial. > > Are we intending that IRS satisfies BOTH these requirements (i.e. for ALL= applications ?), or should we be more prescriptive about which application= space we are addressing ? > > Thanks > > David > > -----Original Message----- > From: irs-discuss-bounces@ietf.org [= mailto:irs-discuss-bounces@ietf.org] O= n Behalf Of Alia Atlas > Sent: Wednesday, August 15, 2012 7:23 AM > To: Olen Stokes > Cc: irs-discuss@ietf.org > Subject: Re: [irs-discuss] IRS comments > > I have not specifically heard from application vendors about this. > My current plan is that we focus on a Use-Cases draft and define within t= hat some motivating use-cases that we agree are good first targets. Those = can drive which subset of functionality we focus on. > > More use-cases are, of course, quite welcome. Posting them to the mailin= g list is a good first start. Russ White is starting the general use-cases= draft based on the three use-cases that he sent to the list. > > Alia > > On Wed, Aug 15, 2012 at 9:43 AM, Olen Stokes > wrote: >> Are there applications vendors out there that already have specific requ= irements for what this " subset of the data-models for sub-interfaces" sho= uld be? >> >> Olen >> >> -----Original Message----- >> From: irs-discuss-bounces@ietf.org >> [mailto:irs-discuss-bounces@ietf.org] On Behalf Of Alia Atlas >> Sent: Wednesday, August 15, 2012 9:08 AM >> To: Shah, Himanshu >> Cc: Gert Grammel; irs-discuss@ietf.org; Len= ny Giuliano; Thomas Nadeau; >> Alia Atlas; Scott Whyte >> Subject: Re: [irs-discuss] IRS comments >> >> Hi Himanshu, >> >> Welcome. I agree that IRS isn't going to spring into being fully >> formed - I expect that we'll focus on a subset of the data-models for su= b-interfaces along with an associated protocol (whether that is a new one o= r extending an existing one). >> >> Alia >> >> On Wed, Aug 15, 2012 at 7:41 AM, Shah, Himanshu > wrote: >>> Newbie to this discussions list and have read only a last couple of mai= ls, so pardon the repeat if somebody has already raised the following as a = concern. >>> >>> I realize we are early in IRS architecture definition but one thing to = keep in mind is the user experience. >>> We need to make sure that exposed interface to >>> RIB/LFIB/FIB/IGPs/BGP/LSDBs etc etc provide a consistent predictive ac= tion/response/events even when different implementations has varying capabi= lities. >>> >>> At the moment it seems like a wild wild west. >>> Perhaps IRS can be defined in phases starting with a simpler, limited v= ersion.. >>> >>> Thanks, >>> himanshu >>> >>> >>> -----Original Message----- >>> From: irs-discuss-bounces@ietf.org >>> [mailto:irs-discuss-bounces@ietf.org] On Behalf Of Alia Atlas >>> Sent: Monday, August 13, 2012 8:41 AM >>> To: Scott Whyte >>> Cc: Thomas Nadeau; Gert Grammel; Alia Atlas; Lenny Giuliano; >>> irs-discuss@ietf.org >>> Subject: Re: [irs-discuss] IRS comments >>> >>> ...snip... >>> >>> On Fri, Aug 10, 2012 at 9:03 PM, Scott Whyte > wrote: >>>> On Fri, Aug 10, 2012 at 5:16 PM, Alia Atlas > wrote: >>> >>>>> I do think it is important to have the RIB as an arbitration mechanis= m >>>>> on the device. Russ's suggestion that for the RIB sub-interface, th= e >>>>> IRS agent might communicate logically to an IRS routing process >>>>> gives good semantics and interactions. Obviously, implementations >>>>> may differ. >>>> >>>> As long as the arbitration mechanism is reconfigurable by the >>>> operator to whatever precedence they want, I agree. Its not clear >>>> to me if various RIB implementations treat all proffered routes the >>>> same, nor if they store the same meta-data with all protocol sources. >>>> So there needs to be some way for the operator to leverage exposed >>>> protocol-specific optimizations, without conflict from the other >>>> routing processes, if they so desire. OTOH if it can all be done >>>> via static routes, it seems much simpler. :) >>> >>> Clearly the IRS sub-interface for the RIB needs to introduce/define the= different precedences; my assumption is that it would be per route with a = well-defined small set of meta-data. This is part of where having good use= -cases will help us understand what behavior is necessary. The static rou= tes do seem like a simpler case to start with. >>> >>> Alia >>> _______________________________________________ >>> 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 > _______________________________________________ > 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 --_000_A3C4E51A53661B4EBEE7C5F5E6FCDEB5025AB94FE847USEXCHANGEc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Thanks.&n= bsp; Can you also give us what you mean by “controller”.  =

 <= /p>

Olen

 

From: Edward Cra= bbe [mailto:edc@google.com]
Sent: Wednesday, August 15, 2012 1:2= 4 PM
To: Alia Atlas
Cc: David Lake (dlake); Olen Stokes= ; irs-discuss@ietf.org
Subject: Re: [irs-discuss] IRS comments

 

s/wg/pre-BOF proto-wg :P/g  

On Wed, Aug 15, 2012 at 10:22 AM, Edwa= rd Crabbe <edc@googl= e.com> wrote:

+1 Alia.  Ther= e's been a lot of confusion over this term.  Having gone a few rounds = with folks on this one in other forums, I'll point out that what most peopl= e mean by application (myself included) is some set of control software (a = scheduler, a path optimizer etc)  that provides instructions to the co= ntroller, which are in turn translated to the appropriate PDUs.<= /p>

 

Having 'end user' applications request/make changes to forwarding st= ate without an intermediate broker/aggregator acting on their behalf sounds= like a recipe for disaster for operational networks, or, as is more likely= , a quick hike to the protocol grave yard (followed by a long grave-side pa= rty :P) for the wg.  

 

my 2c. <= /p>

 

On Wed, Aug 15, 2012 at 8:48 AM, Alia Atlas <akatlas@gmail.com> wrot= e:

Hi David,

We do need to clarif= y what is meant by an application.  I would not
expect that real us= er-land applications would talk directly to routing
devices via IRS. &nb= sp;I can see that going through an intermediary.  The
IRS abstracti= ons are unlikely to be as high-level as user-land
applications would wan= t and the security and policy issues would get
exciting.

Clarifyi= ng what applications are more in-scope initially is part of
where use-ca= ses will help.  Can you write up ones to
categorize/describe your t= houghts?

Alia


On Wed, Aug 15, 2012 at 11:40 AM, David Lak= e (dlake) <dlake@ci= sco.com> wrote:
> As another newbie to this, I have some quest= ions about "application vendors."
>
> Who is the targ= et audience here ?   That will determine what functionality and abstra= ction of the network we need to expose to that "application."
= >
> This presently appears to be a little confused - at least in m= y mind.  The draft talks very much as if the application we are addres= sing is an OSS/BSS system, essentially provisioning from the domain owner.<= br>>
> However, linking this to the wider goals of SDN as voiced b= y customers/users at the first Open Network Summit, there appears to be a d= esire for cross-domain and user-land application integration.
>
&g= t; At this level - as an example giving a content cache the ability to ensu= re delivery of an HD video to an end user - the application will not be int= erested in the underlying topology of the network; it will  need to kn= ow that application X can be delivered with parameters Y between reading fr= om the content store to delivery to the user's browser.   How the stre= am traverses the infrastructure is immaterial.
>
> Are we inten= ding that IRS satisfies BOTH these requirements (i.e. for ALL applications = ?), or should we be more prescriptive about which application space we are = addressing ?
>
> Thanks
>
> David
>
> -= ----Original Message-----
> From: irs-discuss-bounces@ietf.org [mailto:irs-discuss-= bounces@ietf.org] On Behalf Of Alia Atlas
> Sent: Wednesday, Augu= st 15, 2012 7:23 AM
> To: Olen Stokes
> Cc: irs-discuss@ietf.org
> Sub= ject: Re: [irs-discuss] IRS comments
>
> I have not specificall= y heard from application vendors about this.
> My current plan is tha= t we focus on a Use-Cases draft and define within that some motivating use-= cases that we agree are good first targets.  Those can drive which sub= set of functionality we focus on.
>
> More use-cases are, of co= urse, quite welcome.  Posting them to the mailing list is a good first= start.  Russ White is starting the general use-cases draft based on t= he three use-cases that he sent to the list.
>
> Alia
>> On Wed, Aug 15, 2012 at 9:43 AM, Olen Stokes <ostokes@extremenetworks.com> wrote:
>> Are there applications vendors out there that alr= eady have specific requirements for what this " subset of the data-mod= els for sub-interfaces"  should be?
>>
>> Olen<= br>>>
>> -----Original Message-----
>> From: irs-discuss-bou= nces@ietf.org
>> [mailto:irs-discuss-bounces@ietf.org] On Behalf Of= Alia Atlas
>> Sent: Wednesday, August 15, 2012 9:08 AM
>>= ; To: Shah, Himanshu
>> Cc: Gert Grammel; irs-discuss@ietf.org; Lenny Giuliano;= Thomas Nadeau;
>> Alia Atlas; Scott Whyte
>> Subject: Re= : [irs-discuss] IRS comments
>>
>> Hi Himanshu,
>&g= t;
>> Welcome.   I agree that IRS isn't going to spring into = being fully
>> formed - I expect that we'll focus on a subset of t= he data-models for sub-interfaces along with an associated protocol (whethe= r that is a new one or extending an existing one).
>>
>> = Alia
>>
>> On Wed, Aug 15, 2012 at 7:41 AM, Shah, Himansh= u <hshah@ciena.com<= /a>> wrote:
>>> Newbie to this discussions list and have rea= d only a last couple of mails, so pardon the repeat if somebody has already= raised the following as a concern.
>>>
>>> I reali= ze we are early in IRS architecture definition but one thing to keep in min= d is the user experience.
>>> We need to make sure that exposed= interface to
>>> RIB/LFIB/FIB/IGPs/BGP/LSDBs etc etc  pro= vide a consistent predictive action/response/events even when different imp= lementations has varying capabilities.
>>>
>>> At t= he moment it seems like a wild wild west.
>>> Perhaps IRS can b= e defined in phases starting with a simpler, limited version..
>>&= gt;
>>> Thanks,
>>> himanshu
>>>
>= ;>>
>>> -----Original Message-----
>>> From: = irs-discu= ss-bounces@ietf.org
>>> [mailto:irs-discuss-bounces@ietf.org] On= Behalf Of Alia Atlas
>>> Sent: Monday, August 13, 2012 8:41 AM=
>>> To: Scott Whyte
>>> Cc: Thomas Nadeau; Gert Gr= ammel; Alia Atlas; Lenny Giuliano;
>>> irs-discuss@ietf.org
>>> = Subject: Re: [irs-discuss] IRS comments
>>>
>>> ...= snip...
>>>
>>> On Fri, Aug 10, 2012 at 9:03 PM, Sc= ott Whyte <swhyte= @google.com> wrote:
>>>> On Fri, Aug 10, 2012 at 5:16= PM, Alia Atlas <= akatlas@gmail.com> wrote:
>>>
>>>>> I = do think it is important to have the RIB as an arbitration mechanism
>= ;>>>> on the device.   Russ's suggestion that for the RIB = sub-interface, the
>>>>> IRS agent might communicate logi= cally to an IRS routing process
>>>>> gives good semantic= s and interactions.  Obviously, implementations
>>>>>= ; may differ.
>>>>
>>>> As long as the arbitr= ation mechanism is reconfigurable by the
>>>> operator to wh= atever precedence they want, I agree.  Its not clear
>>>&g= t; to me if various RIB implementations treat all proffered routes the
&= gt;>>> same, nor if they store the same meta-data with all protoco= l sources.
>>>> So there needs to be some way for the operat= or to leverage exposed
>>>> protocol-specific optimizations,= without conflict from the other
>>>> routing processes, if = they so desire.  OTOH if it can all be done
>>>> via st= atic routes, it seems much simpler. :)
>>>
>>> Clea= rly the IRS sub-interface for the RIB needs to introduce/define the differe= nt precedences; my assumption is that it would be per route with a well-def= ined small set of meta-data.  This is part of where having good use-ca= ses will help us understand what behavior is necessary.  The static &n= bsp;routes do seem like a simpler case to start with.
>>>
&g= t;>> Alia
>>> ___________________________________________= ____
>>> irs-discuss mailing list
>>> irs-discuss@ietf.org
&g= t;>> https://www.ietf.org/mailman/listinfo/irs-discuss
&g= t;> _______________________________________________
>> irs-disc= uss 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
_________________= ______________________________
irs-discuss mailing list
irs-discuss@ietf.org
https://www.ietf.org/mailman/listinfo/irs-discuss

 

<= /div>

 

= --_000_A3C4E51A53661B4EBEE7C5F5E6FCDEB5025AB94FE847USEXCHANGEc_-- Return-Path: 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 88DCA11E80BF for ; Wed, 15 Aug 2012 10:25:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.698 X-Spam-Level: X-Spam-Status: No, score=-102.698 tagged_above=-999 required=5 tests=[AWL=0.278, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hWauJsTiEnjn for ; Wed, 15 Aug 2012 10:25:04 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 05D9411E80BA for ; Wed, 15 Aug 2012 10:25:03 -0700 (PDT) Received: by yhq56 with SMTP id 56so2200000yhq.31 for ; Wed, 15 Aug 2012 10:25:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=JgKOTi7MQ+C4LPoGumdHOtHGhGXtoHKZJNQYI+iUcmI=; b=BuKrj0l5p7cGOr48MowzuCMToxdIUBfYo2q5epoT038IPjOnmCVxuLBFk0vmGLHkL2 V2AVfGPmoc0iabQcHJLnuzEhwiC6/6wISbi28UqDodpYVwWCaDIoq1bMFEQyoVZ0LVaO OB7KQ8gMXNxEv18l3Sh6nT0egr1rGls/WtWcWzxoSesRB56Y0W4rtrZ4/l5R8qgCHC/R z5xZ/eTp+z0N0lEuuhSXvfepv8YjhglPKjZotw0wdsgFDzuSV05xIV4xcQjdKcs8rtAe vhfdapS+TZ52vR7w4m0zQ4sWkDXo6QKURsl30aec2QlibJFMNy9ZOSp5nCLAOW21gG2m h9qg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=JgKOTi7MQ+C4LPoGumdHOtHGhGXtoHKZJNQYI+iUcmI=; b=LArgMADxbCzmt3BZHB1CrNi2WAzwYdrqFsnzmfe2FTGIrexfcKth1RCWbE4wleulA9 8qCdJiKRQ0dYXSnK6oEZJh5fX31heoxdcivP0g0f91Gy6ZbyId10SbFqoqbQ9cVDjI/Y GT41Z3uyUQmKG5MZ5xgOGBYaWqPSuGBrmC99tD4Xa17o4NvPupq/YkPyHB6c+uYwNjwo DOaxTuijACI7T76EoNtEcaQyGhWDxBILNQFCZJoUPl6ZdxsC3NRu7IIewZ1MygPFatAa RXI8h6lpJAh2IXLrFWm6dDN1tpv1ANu/NRJ3UpsOp+glTymeqp19zXgnVt9JN9gzbzn9 rVBA== Received: by 10.50.237.38 with SMTP id uz6mr19391098igc.2.1345051502926; Wed, 15 Aug 2012 10:25:02 -0700 (PDT) Received: by 10.50.237.38 with SMTP id uz6mr19391083igc.2.1345051502779; Wed, 15 Aug 2012 10:25:02 -0700 (PDT) MIME-Version: 1.0 Received: by 10.50.237.67 with HTTP; Wed, 15 Aug 2012 10:24:22 -0700 (PDT) In-Reply-To: References: <812700A304640D4292205D5E83FC59E1061C211D@p-embx01-eq.jnpr.net> <3512BB31280C39448A9880F61DD54CEB09C07E@xmb-aln-x09.cisco.com> From: Edward Crabbe Date: Wed, 15 Aug 2012 10:24:22 -0700 Message-ID: To: Alia Atlas Content-Type: multipart/alternative; boundary=f46d0447882f071ba104c751355f X-System-Of-Record: true X-Gm-Message-State: ALoCoQkVgE0tkCE9y7h+FbkrEx7lZR1h1LNDtJItalqXFbdjfVQPBekufxwB5modQAUvfvxetHP/1AScSgpgGYC653VzGjjk7e6h2BdNUR0GLO1Ip2IVidLkMmkKUzl0KHe3te097r4fYzKzBrsp9ev+vwHpyTXe4OqWHoLbmTsF/BmsEjsz2esFvVX0TnqT605wyyHBmbrs Cc: Olen Stokes , "David Lake \(dlake\)" , "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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Aug 2012 17:25:05 -0000 --f46d0447882f071ba104c751355f Content-Type: text/plain; charset=ISO-8859-1 s/wg/pre-BOF proto-wg :P/g On Wed, Aug 15, 2012 at 10:22 AM, Edward Crabbe wrote: > +1 Alia. There's been a lot of confusion over this term. Having gone a > few rounds with folks on this one in other forums, I'll point out that what > most people mean by application (myself included) is some set of control > software (a scheduler, a path optimizer etc) that provides instructions to > the controller, which are in turn translated to the appropriate PDUs. > > Having 'end user' applications request/make changes to forwarding state > without an intermediate broker/aggregator acting on their behalf sounds > like a recipe for disaster for operational networks, or, as is more likely, > a quick hike to the protocol grave yard (followed by a long grave-side > party :P) for the wg. > > my 2c. > > On Wed, Aug 15, 2012 at 8:48 AM, Alia Atlas wrote: > >> Hi David, >> >> We do need to clarify what is meant by an application. I would not >> expect that real user-land applications would talk directly to routing >> devices via IRS. I can see that going through an intermediary. The >> IRS abstractions are unlikely to be as high-level as user-land >> applications would want and the security and policy issues would get >> exciting. >> >> Clarifying what applications are more in-scope initially is part of >> where use-cases will help. Can you write up ones to >> categorize/describe your thoughts? >> >> Alia >> >> On Wed, Aug 15, 2012 at 11:40 AM, David Lake (dlake) >> wrote: >> > As another newbie to this, I have some questions about "application >> vendors." >> > >> > Who is the target audience here ? That will determine what >> functionality and abstraction of the network we need to expose to that >> "application." >> > >> > This presently appears to be a little confused - at least in my mind. >> The draft talks very much as if the application we are addressing is an >> OSS/BSS system, essentially provisioning from the domain owner. >> > >> > However, linking this to the wider goals of SDN as voiced by >> customers/users at the first Open Network Summit, there appears to be a >> desire for cross-domain and user-land application integration. >> > >> > At this level - as an example giving a content cache the ability to >> ensure delivery of an HD video to an end user - the application will not be >> interested in the underlying topology of the network; it will need to know >> that application X can be delivered with parameters Y between reading from >> the content store to delivery to the user's browser. How the stream >> traverses the infrastructure is immaterial. >> > >> > Are we intending that IRS satisfies BOTH these requirements (i.e. for >> ALL applications ?), or should we be more prescriptive about which >> application space we are addressing ? >> > >> > Thanks >> > >> > David >> > >> > -----Original Message----- >> > From: irs-discuss-bounces@ietf.org [mailto:irs-discuss-bounces@ietf.org] >> On Behalf Of Alia Atlas >> > Sent: Wednesday, August 15, 2012 7:23 AM >> > To: Olen Stokes >> > Cc: irs-discuss@ietf.org >> > Subject: Re: [irs-discuss] IRS comments >> > >> > I have not specifically heard from application vendors about this. >> > My current plan is that we focus on a Use-Cases draft and define within >> that some motivating use-cases that we agree are good first targets. Those >> can drive which subset of functionality we focus on. >> > >> > More use-cases are, of course, quite welcome. Posting them to the >> mailing list is a good first start. Russ White is starting the general >> use-cases draft based on the three use-cases that he sent to the list. >> > >> > Alia >> > >> > On Wed, Aug 15, 2012 at 9:43 AM, Olen Stokes < >> ostokes@extremenetworks.com> wrote: >> >> Are there applications vendors out there that already have specific >> requirements for what this " subset of the data-models for sub-interfaces" >> should be? >> >> >> >> Olen >> >> >> >> -----Original Message----- >> >> From: irs-discuss-bounces@ietf.org >> >> [mailto:irs-discuss-bounces@ietf.org] On Behalf Of Alia Atlas >> >> Sent: Wednesday, August 15, 2012 9:08 AM >> >> To: Shah, Himanshu >> >> Cc: Gert Grammel; irs-discuss@ietf.org; Lenny Giuliano; Thomas Nadeau; >> >> Alia Atlas; Scott Whyte >> >> Subject: Re: [irs-discuss] IRS comments >> >> >> >> Hi Himanshu, >> >> >> >> Welcome. I agree that IRS isn't going to spring into being fully >> >> formed - I expect that we'll focus on a subset of the data-models for >> sub-interfaces along with an associated protocol (whether that is a new one >> or extending an existing one). >> >> >> >> Alia >> >> >> >> On Wed, Aug 15, 2012 at 7:41 AM, Shah, Himanshu >> wrote: >> >>> Newbie to this discussions list and have read only a last couple of >> mails, so pardon the repeat if somebody has already raised the following as >> a concern. >> >>> >> >>> I realize we are early in IRS architecture definition but one thing >> to keep in mind is the user experience. >> >>> We need to make sure that exposed interface to >> >>> RIB/LFIB/FIB/IGPs/BGP/LSDBs etc etc provide a consistent predictive >> action/response/events even when different implementations has varying >> capabilities. >> >>> >> >>> At the moment it seems like a wild wild west. >> >>> Perhaps IRS can be defined in phases starting with a simpler, limited >> version.. >> >>> >> >>> Thanks, >> >>> himanshu >> >>> >> >>> >> >>> -----Original Message----- >> >>> From: irs-discuss-bounces@ietf.org >> >>> [mailto:irs-discuss-bounces@ietf.org] On Behalf Of Alia Atlas >> >>> Sent: Monday, August 13, 2012 8:41 AM >> >>> To: Scott Whyte >> >>> Cc: Thomas Nadeau; Gert Grammel; Alia Atlas; Lenny Giuliano; >> >>> irs-discuss@ietf.org >> >>> Subject: Re: [irs-discuss] IRS comments >> >>> >> >>> ...snip... >> >>> >> >>> On Fri, Aug 10, 2012 at 9:03 PM, Scott Whyte >> wrote: >> >>>> On Fri, Aug 10, 2012 at 5:16 PM, Alia Atlas >> wrote: >> >>> >> >>>>> I do think it is important to have the RIB as an arbitration >> mechanism >> >>>>> on the device. Russ's suggestion that for the RIB sub-interface, >> the >> >>>>> IRS agent might communicate logically to an IRS routing process >> >>>>> gives good semantics and interactions. Obviously, implementations >> >>>>> may differ. >> >>>> >> >>>> As long as the arbitration mechanism is reconfigurable by the >> >>>> operator to whatever precedence they want, I agree. Its not clear >> >>>> to me if various RIB implementations treat all proffered routes the >> >>>> same, nor if they store the same meta-data with all protocol sources. >> >>>> So there needs to be some way for the operator to leverage exposed >> >>>> protocol-specific optimizations, without conflict from the other >> >>>> routing processes, if they so desire. OTOH if it can all be done >> >>>> via static routes, it seems much simpler. :) >> >>> >> >>> Clearly the IRS sub-interface for the RIB needs to introduce/define >> the different precedences; my assumption is that it would be per route with >> a well-defined small set of meta-data. This is part of where having good >> use-cases will help us understand what behavior is necessary. The static >> routes do seem like a simpler case to start with. >> >>> >> >>> Alia >> >>> _______________________________________________ >> >>> 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 >> > _______________________________________________ >> > 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 >> > > --f46d0447882f071ba104c751355f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable s/wg/pre-BOF proto-wg :P/g =A0

On Wed, Au= g 15, 2012 at 10:22 AM, Edward Crabbe <edc@google.com> wrote:
+1 Alia. =A0There's been a lot of confusion over this term. =A0Having g= one a few rounds with folks on this one in other forums, I'll point out= that what most people mean by application (myself included) is some set of= control software (a scheduler, a path optimizer etc) =A0that provides inst= ructions to the controller, which are in turn translated to the appropriate= PDUs.

Having 'end user' applications request/make changes = to forwarding state without an intermediate broker/aggregator acting on the= ir behalf sounds like a recipe for disaster for operational networks, or, a= s is more likely, a quick hike to the protocol grave yard (followed by a lo= ng grave-side party :P) for the wg. =A0

my 2c.=A0
=

On Wed, Aug 15, 2012 at 8:48 AM, Alia A= tlas <akatlas@gmail.com> wrote:
Hi David,

We do need to clarify what is meant by an application. =A0I would not
expect that real user-land applications would talk directly to routing
devices via IRS. =A0I can see that going through an intermediary. =A0The IRS abstractions are unlikely to be as high-level as user-land
applications would want and the security and policy issues would get
exciting.

Clarifying what applications are more in-scope initially is part of
where use-cases will help. =A0Can you write up ones to
categorize/describe your thoughts?

Alia

On Wed, Aug 15, 2012 at 11:40 AM, David Lake (dlake) <dlake@cisco.com> wrote:
> As another newbie to this, I have some questions about "applicati= on vendors."
>
> Who is the target audience here ? =A0 That will determine what functio= nality and abstraction of the network we need to expose to that "appli= cation."
>
> This presently appears to be a little confused - at least in my mind. = =A0The draft talks very much as if the application we are addressing is an = OSS/BSS system, essentially provisioning from the domain owner.
>
> However, linking this to the wider goals of SDN as voiced by customers= /users at the first Open Network Summit, there appears to be a desire for c= ross-domain and user-land application integration.
>
> At this level - as an example giving a content cache the ability to en= sure delivery of an HD video to an end user - the application will not be i= nterested in the underlying topology of the network; it will =A0need to kno= w that application X can be delivered with parameters Y between reading fro= m the content store to delivery to the user's browser. =A0 How the stre= am traverses the infrastructure is immaterial.
>
> Are we intending that IRS satisfies BOTH these requirements (i.e. for = ALL applications ?), or should we be more prescriptive about which applicat= ion space we are addressing ?
>
> Thanks
>
> David
>
> -----Original Message-----
> From: irs-discuss-bounces@ietf.org [mailto:irs-discuss-bounces@ietf.org] On Beha= lf Of Alia Atlas
> Sent: Wednesday, August 15, 2012 7:23 AM
> To: Olen Stokes
> Cc: irs-disc= uss@ietf.org
> Subject: Re: [irs-discuss] IRS comments
>
> I have not specifically heard from application vendors about this.
> My current plan is that we focus on a Use-Cases draft and define withi= n that some motivating use-cases that we agree are good first targets. =A0T= hose can drive which subset of functionality we focus on.
>
> More use-cases are, of course, quite welcome. =A0Posting them to the m= ailing list is a good first start. =A0Russ White is starting the general us= e-cases draft based on the three use-cases that he sent to the list.
>
> Alia
>
> On Wed, Aug 15, 2012 at 9:43 AM, Olen Stokes <ostokes@extremenetworks.com= > wrote:
>> Are there applications vendors out there that already have specifi= c requirements for what this " subset of the data-models for sub-inter= faces" =A0should be?
>>
>> Olen
>>
>> -----Original Message-----
>> From: irs-discuss-bounces@ietf.org
>> [mailto:irs-discuss-bounces@ietf.org] On Behalf Of Alia Atlas
>> Sent: Wednesday, August 15, 2012 9:08 AM
>> To: Shah, Himanshu
>> Cc: Gert Grammel; irs-discuss@ietf.org; Lenny Giuliano; Thomas Nadeau;
>> Alia Atlas; Scott Whyte
>> Subject: Re: [irs-discuss] IRS comments
>>
>> Hi Himanshu,
>>
>> Welcome. =A0 I agree that IRS isn't going to spring into being= fully
>> formed - I expect that we'll focus on a subset of the data-mod= els for sub-interfaces along with an associated protocol (whether that is a= new one or extending an existing one).
>>
>> Alia
>>
>> On Wed, Aug 15, 2012 at 7:41 AM, Shah, Himanshu <hshah@ciena.com> wrote:
>>> Newbie to this discussions list and have read only a last coup= le of mails, so pardon the repeat if somebody has already raised the follow= ing as a concern.
>>>
>>> I realize we are early in IRS architecture definition but one = thing to keep in mind is the user experience.
>>> We need to make sure that exposed interface to
>>> RIB/LFIB/FIB/IGPs/BGP/LSDBs etc etc =A0provide a consistent pr= edictive action/response/events even when different implementations has var= ying capabilities.
>>>
>>> At the moment it seems like a wild wild west.
>>> Perhaps IRS can be defined in phases starting with a simpler, = limited version..
>>>
>>> Thanks,
>>> himanshu
>>>
>>>
>>> -----Original Message-----
>>> From: irs-discuss-bounces@ietf.org
>>> [mailto:irs-discuss-bounces@ietf.org] On Behalf Of Alia Atlas
>>> Sent: Monday, August 13, 2012 8:41 AM
>>> To: Scott Whyte
>>> Cc: Thomas Nadeau; Gert Grammel; Alia Atlas; Lenny Giuliano; >>> irs-= discuss@ietf.org
>>> Subject: Re: [irs-discuss] IRS comments
>>>
>>> ...snip...
>>>
>>> On Fri, Aug 10, 2012 at 9:03 PM, Scott Whyte <swhyte@google.com> wrote:<= br> >>>> On Fri, Aug 10, 2012 at 5:16 PM, Alia Atlas <akatlas@gmail.com> wrot= e:
>>>
>>>>> I do think it is important to have the RIB as an arbit= ration mechanism
>>>>> on the device. =A0 Russ's suggestion that for the = RIB sub-interface, the
>>>>> IRS agent might communicate logically to an IRS routin= g process
>>>>> gives good semantics and interactions. =A0Obviously, i= mplementations
>>>>> may differ.
>>>>
>>>> As long as the arbitration mechanism is reconfigurable by = the
>>>> operator to whatever precedence they want, I agree. =A0Its= not clear
>>>> to me if various RIB implementations treat all proffered r= outes the
>>>> same, nor if they store the same meta-data with all protoc= ol sources.
>>>> So there needs to be some way for the operator to leverage= exposed
>>>> protocol-specific optimizations, without conflict from the= other
>>>> routing processes, if they so desire. =A0OTOH if it can al= l be done
>>>> via static routes, it seems much simpler. :)
>>>
>>> Clearly the IRS sub-interface for the RIB needs to introduce/d= efine the different precedences; my assumption is that it would be per rout= e with a well-defined small set of meta-data. =A0This is part of where havi= ng good use-cases will help us understand what behavior is necessary. =A0Th= e static =A0routes do seem like a simpler case to start with.
>>>
>>> Alia
>>> _______________________________________________
>>> irs-discuss mailing list
>>> irs-= discuss@ietf.org
>>> https://www.ietf.org/mailman/listinfo/irs-discuss
>> _______________________________________________
>> irs-discuss mailing list
>> irs-disc= uss@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
_______________________________________________
irs-discuss mailing list
irs-discuss@ietf.= org
https://www.ietf.org/mailman/listinfo/irs-discuss


--f46d0447882f071ba104c751355f-- Return-Path: 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 851BB11E80CC for ; Wed, 15 Aug 2012 10:23:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.559 X-Spam-Level: X-Spam-Status: No, score=-102.559 tagged_above=-999 required=5 tests=[AWL=0.417, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dmlXkqDrg9RK for ; Wed, 15 Aug 2012 10:23:29 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id E16A921F86AA for ; Wed, 15 Aug 2012 10:23:28 -0700 (PDT) Received: by yhq56 with SMTP id 56so2197945yhq.31 for ; Wed, 15 Aug 2012 10:23:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=wR/dRnyP4xv4JNKLi6gb4HL/14ZP8k90OgoF7gQS9pM=; b=hmVbWC1ppzG7bRZHiCE749C/b1TtHDJo4S23zfxkZu5pregraWt/oB5usAzHu6eTqB Nde3OLoACwrOveLInMF6+ebXx0SVeRpmR91h8qxoPyhwdBuNMoB3oJG+8V9ci6R8M+L+ hKApke4ZrQPuAK0YEqxqXsgEVIVvX/+8y5ZsTXsKjmd3V9BnJzcbqa2FTDuH36Tbxovz O5lRJ6mXRJcNifq5V6R2SprEZIrI5LaEwvWtnz8znrzCTh2mmZmWG3CafoyEiQyl0XuZ 4+uuP6CPUpKQEjKJQS7sk7nwnex2IBK7OQeP/7X/TUPz81yMlGB8lhrkidJ2Q3yx0a6e cEcg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=wR/dRnyP4xv4JNKLi6gb4HL/14ZP8k90OgoF7gQS9pM=; b=CGkKM7ltv+2c/ZvtZTnlOVCRkHVUaN52RLKTQb98+LT6yAoMyQkopAPG/8F56wFCmc rHhDcRVKLELVcFi3eUO27/1PBiQDOq+UiS/WZkw/KUGJzOecI/LCrCWZP6Bbi7ms2g+B 060Nc9CSAaap9+7jKcynDtz2NZJpQw8ybIxqaRksex4VHZNfN0mF1gWUoOMuSz8m5IWh HCj4q37lMFYi7BgUMFj128EvJyGGwOuDQ0paaq3wfsDPXvxcJ+UNI64sYsL6RXXLpSvB fYNXVdZEaLW1YuB7pvKXnrTvCYqpvmAZ6anjlSWesyycAwVlzTTkDDq6VYA/XdmV6eBw vEug== Received: by 10.50.182.232 with SMTP id eh8mr19322566igc.48.1345051403287; Wed, 15 Aug 2012 10:23:23 -0700 (PDT) Received: by 10.50.182.232 with SMTP id eh8mr19322536igc.48.1345051402868; Wed, 15 Aug 2012 10:23:22 -0700 (PDT) MIME-Version: 1.0 Received: by 10.50.237.67 with HTTP; Wed, 15 Aug 2012 10:22:42 -0700 (PDT) In-Reply-To: References: <812700A304640D4292205D5E83FC59E1061C211D@p-embx01-eq.jnpr.net> <3512BB31280C39448A9880F61DD54CEB09C07E@xmb-aln-x09.cisco.com> From: Edward Crabbe Date: Wed, 15 Aug 2012 10:22:42 -0700 Message-ID: To: Alia Atlas Content-Type: multipart/alternative; boundary=14dae9340e1b12973204c7512f9b X-System-Of-Record: true X-Gm-Message-State: ALoCoQlDuzsGBGkj5PJPhUs4kgtWB8+NuxOCgsH3Gz9tEHvXvH5y8opr4gehMXH80F0K2Ay6x6Zol4vcatdQaXb1O3fGF8XAEpA5/gw910dPZZaBBU5bI1b4sc6W0ZW46V85WAwlfeY1QQy4shJ3Fn58pzAzm3Z6L7psGUAWTygOjZ8GP+T/KqhE8tJ74HCM/Dl+AFNMSrA4 Cc: Olen Stokes , "David Lake \(dlake\)" , "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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Aug 2012 17:23:30 -0000 --14dae9340e1b12973204c7512f9b Content-Type: text/plain; charset=ISO-8859-1 +1 Alia. There's been a lot of confusion over this term. Having gone a few rounds with folks on this one in other forums, I'll point out that what most people mean by application (myself included) is some set of control software (a scheduler, a path optimizer etc) that provides instructions to the controller, which are in turn translated to the appropriate PDUs. Having 'end user' applications request/make changes to forwarding state without an intermediate broker/aggregator acting on their behalf sounds like a recipe for disaster for operational networks, or, as is more likely, a quick hike to the protocol grave yard (followed by a long grave-side party :P) for the wg. my 2c. On Wed, Aug 15, 2012 at 8:48 AM, Alia Atlas wrote: > Hi David, > > We do need to clarify what is meant by an application. I would not > expect that real user-land applications would talk directly to routing > devices via IRS. I can see that going through an intermediary. The > IRS abstractions are unlikely to be as high-level as user-land > applications would want and the security and policy issues would get > exciting. > > Clarifying what applications are more in-scope initially is part of > where use-cases will help. Can you write up ones to > categorize/describe your thoughts? > > Alia > > On Wed, Aug 15, 2012 at 11:40 AM, David Lake (dlake) > wrote: > > As another newbie to this, I have some questions about "application > vendors." > > > > Who is the target audience here ? That will determine what > functionality and abstraction of the network we need to expose to that > "application." > > > > This presently appears to be a little confused - at least in my mind. > The draft talks very much as if the application we are addressing is an > OSS/BSS system, essentially provisioning from the domain owner. > > > > However, linking this to the wider goals of SDN as voiced by > customers/users at the first Open Network Summit, there appears to be a > desire for cross-domain and user-land application integration. > > > > At this level - as an example giving a content cache the ability to > ensure delivery of an HD video to an end user - the application will not be > interested in the underlying topology of the network; it will need to know > that application X can be delivered with parameters Y between reading from > the content store to delivery to the user's browser. How the stream > traverses the infrastructure is immaterial. > > > > Are we intending that IRS satisfies BOTH these requirements (i.e. for > ALL applications ?), or should we be more prescriptive about which > application space we are addressing ? > > > > Thanks > > > > David > > > > -----Original Message----- > > From: irs-discuss-bounces@ietf.org [mailto:irs-discuss-bounces@ietf.org] > On Behalf Of Alia Atlas > > Sent: Wednesday, August 15, 2012 7:23 AM > > To: Olen Stokes > > Cc: irs-discuss@ietf.org > > Subject: Re: [irs-discuss] IRS comments > > > > I have not specifically heard from application vendors about this. > > My current plan is that we focus on a Use-Cases draft and define within > that some motivating use-cases that we agree are good first targets. Those > can drive which subset of functionality we focus on. > > > > More use-cases are, of course, quite welcome. Posting them to the > mailing list is a good first start. Russ White is starting the general > use-cases draft based on the three use-cases that he sent to the list. > > > > Alia > > > > On Wed, Aug 15, 2012 at 9:43 AM, Olen Stokes < > ostokes@extremenetworks.com> wrote: > >> Are there applications vendors out there that already have specific > requirements for what this " subset of the data-models for sub-interfaces" > should be? > >> > >> Olen > >> > >> -----Original Message----- > >> From: irs-discuss-bounces@ietf.org > >> [mailto:irs-discuss-bounces@ietf.org] On Behalf Of Alia Atlas > >> Sent: Wednesday, August 15, 2012 9:08 AM > >> To: Shah, Himanshu > >> Cc: Gert Grammel; irs-discuss@ietf.org; Lenny Giuliano; Thomas Nadeau; > >> Alia Atlas; Scott Whyte > >> Subject: Re: [irs-discuss] IRS comments > >> > >> Hi Himanshu, > >> > >> Welcome. I agree that IRS isn't going to spring into being fully > >> formed - I expect that we'll focus on a subset of the data-models for > sub-interfaces along with an associated protocol (whether that is a new one > or extending an existing one). > >> > >> Alia > >> > >> On Wed, Aug 15, 2012 at 7:41 AM, Shah, Himanshu > wrote: > >>> Newbie to this discussions list and have read only a last couple of > mails, so pardon the repeat if somebody has already raised the following as > a concern. > >>> > >>> I realize we are early in IRS architecture definition but one thing to > keep in mind is the user experience. > >>> We need to make sure that exposed interface to > >>> RIB/LFIB/FIB/IGPs/BGP/LSDBs etc etc provide a consistent predictive > action/response/events even when different implementations has varying > capabilities. > >>> > >>> At the moment it seems like a wild wild west. > >>> Perhaps IRS can be defined in phases starting with a simpler, limited > version.. > >>> > >>> Thanks, > >>> himanshu > >>> > >>> > >>> -----Original Message----- > >>> From: irs-discuss-bounces@ietf.org > >>> [mailto:irs-discuss-bounces@ietf.org] On Behalf Of Alia Atlas > >>> Sent: Monday, August 13, 2012 8:41 AM > >>> To: Scott Whyte > >>> Cc: Thomas Nadeau; Gert Grammel; Alia Atlas; Lenny Giuliano; > >>> irs-discuss@ietf.org > >>> Subject: Re: [irs-discuss] IRS comments > >>> > >>> ...snip... > >>> > >>> On Fri, Aug 10, 2012 at 9:03 PM, Scott Whyte > wrote: > >>>> On Fri, Aug 10, 2012 at 5:16 PM, Alia Atlas > wrote: > >>> > >>>>> I do think it is important to have the RIB as an arbitration > mechanism > >>>>> on the device. Russ's suggestion that for the RIB sub-interface, > the > >>>>> IRS agent might communicate logically to an IRS routing process > >>>>> gives good semantics and interactions. Obviously, implementations > >>>>> may differ. > >>>> > >>>> As long as the arbitration mechanism is reconfigurable by the > >>>> operator to whatever precedence they want, I agree. Its not clear > >>>> to me if various RIB implementations treat all proffered routes the > >>>> same, nor if they store the same meta-data with all protocol sources. > >>>> So there needs to be some way for the operator to leverage exposed > >>>> protocol-specific optimizations, without conflict from the other > >>>> routing processes, if they so desire. OTOH if it can all be done > >>>> via static routes, it seems much simpler. :) > >>> > >>> Clearly the IRS sub-interface for the RIB needs to introduce/define > the different precedences; my assumption is that it would be per route with > a well-defined small set of meta-data. This is part of where having good > use-cases will help us understand what behavior is necessary. The static > routes do seem like a simpler case to start with. > >>> > >>> Alia > >>> _______________________________________________ > >>> 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 > > _______________________________________________ > > 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 > --14dae9340e1b12973204c7512f9b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable +1 Alia. =A0There's been a lot of confusion over this term. =A0Having g= one a few rounds with folks on this one in other forums, I'll point out= that what most people mean by application (myself included) is some set of= control software (a scheduler, a path optimizer etc) =A0that provides inst= ructions to the controller, which are in turn translated to the appropriate= PDUs.

Having 'end user' applications request/make changes = to forwarding state without an intermediate broker/aggregator acting on the= ir behalf sounds like a recipe for disaster for operational networks, or, a= s is more likely, a quick hike to the protocol grave yard (followed by a lo= ng grave-side party :P) for the wg. =A0

my 2c.=A0

On W= ed, Aug 15, 2012 at 8:48 AM, Alia Atlas <akatlas@gmail.com> = wrote:
Hi David,

We do need to clarify what is meant by an application. =A0I would not
expect that real user-land applications would talk directly to routing
devices via IRS. =A0I can see that going through an intermediary. =A0The IRS abstractions are unlikely to be as high-level as user-land
applications would want and the security and policy issues would get
exciting.

Clarifying what applications are more in-scope initially is part of
where use-cases will help. =A0Can you write up ones to
categorize/describe your thoughts?

Alia

On Wed, Aug 15, 2012 at 11:40 AM, David Lake (dlake) <dlake@cisco.com> wrote:
> As another newbie to this, I have some questions about "applicati= on vendors."
>
> Who is the target audience here ? =A0 That will determine what functio= nality and abstraction of the network we need to expose to that "appli= cation."
>
> This presently appears to be a little confused - at least in my mind. = =A0The draft talks very much as if the application we are addressing is an = OSS/BSS system, essentially provisioning from the domain owner.
>
> However, linking this to the wider goals of SDN as voiced by customers= /users at the first Open Network Summit, there appears to be a desire for c= ross-domain and user-land application integration.
>
> At this level - as an example giving a content cache the ability to en= sure delivery of an HD video to an end user - the application will not be i= nterested in the underlying topology of the network; it will =A0need to kno= w that application X can be delivered with parameters Y between reading fro= m the content store to delivery to the user's browser. =A0 How the stre= am traverses the infrastructure is immaterial.
>
> Are we intending that IRS satisfies BOTH these requirements (i.e. for = ALL applications ?), or should we be more prescriptive about which applicat= ion space we are addressing ?
>
> Thanks
>
> David
>
> -----Original Message-----
> From: irs-discuss-boun= ces@ietf.org [mailto:ir= s-discuss-bounces@ietf.org] On Behalf Of Alia Atlas
> Sent: Wednesday, August 15, 2012 7:23 AM
> To: Olen Stokes
> Cc: irs-discuss@ietf.org > Subject: Re: [irs-discuss] IRS comments
>
> I have not specifically heard from application vendors about this.
> My current plan is that we focus on a Use-Cases draft and define withi= n that some motivating use-cases that we agree are good first targets. =A0T= hose can drive which subset of functionality we focus on.
>
> More use-cases are, of course, quite welcome. =A0Posting them to the m= ailing list is a good first start. =A0Russ White is starting the general us= e-cases draft based on the three use-cases that he sent to the list.
>
> Alia
>
> On Wed, Aug 15, 2012 at 9:43 AM, Olen Stokes <ostokes@extremenetworks.com> wrote:
>> Are there applications vendors out there that already have specifi= c requirements for what this " subset of the data-models for sub-inter= faces" =A0should be?
>>
>> Olen
>>
>> -----Original Message-----
>> From: irs-discuss-= bounces@ietf.org
>> [mailto:irs-discus= s-bounces@ietf.org] On Behalf Of Alia Atlas
>> Sent: Wednesday, August 15, 2012 9:08 AM
>> To: Shah, Himanshu
>> Cc: Gert Grammel; irs-disc= uss@ietf.org; Lenny Giuliano; Thomas Nadeau;
>> Alia Atlas; Scott Whyte
>> Subject: Re: [irs-discuss] IRS comments
>>
>> Hi Himanshu,
>>
>> Welcome. =A0 I agree that IRS isn't going to spring into being= fully
>> formed - I expect that we'll focus on a subset of the data-mod= els for sub-interfaces along with an associated protocol (whether that is a= new one or extending an existing one).
>>
>> Alia
>>
>> On Wed, Aug 15, 2012 at 7:41 AM, Shah, Himanshu <hshah@ciena.com> wrote:
>>> Newbie to this discussions list and have read only a last coup= le of mails, so pardon the repeat if somebody has already raised the follow= ing as a concern.
>>>
>>> I realize we are early in IRS architecture definition but one = thing to keep in mind is the user experience.
>>> We need to make sure that exposed interface to
>>> RIB/LFIB/FIB/IGPs/BGP/LSDBs etc etc =A0provide a consistent pr= edictive action/response/events even when different implementations has var= ying capabilities.
>>>
>>> At the moment it seems like a wild wild west.
>>> Perhaps IRS can be defined in phases starting with a simpler, = limited version..
>>>
>>> Thanks,
>>> himanshu
>>>
>>>
>>> -----Original Message-----
>>> From: irs-disc= uss-bounces@ietf.org
>>> [mailto:irs-di= scuss-bounces@ietf.org] On Behalf Of Alia Atlas
>>> Sent: Monday, August 13, 2012 8:41 AM
>>> To: Scott Whyte
>>> Cc: Thomas Nadeau; Gert Grammel; Alia Atlas; Lenny Giuliano; >>> irs-discuss@ietf.org
>>> Subject: Re: [irs-discuss] IRS comments
>>>
>>> ...snip...
>>>
>>> On Fri, Aug 10, 2012 at 9:03 PM, Scott Whyte <swhyte@google.com> wrote:
>>>> On Fri, Aug 10, 2012 at 5:16 PM, Alia Atlas <akatlas@gmail.com> wrote:
>>>
>>>>> I do think it is important to have the RIB as an arbit= ration mechanism
>>>>> on the device. =A0 Russ's suggestion that for the = RIB sub-interface, the
>>>>> IRS agent might communicate logically to an IRS routin= g process
>>>>> gives good semantics and interactions. =A0Obviously, i= mplementations
>>>>> may differ.
>>>>
>>>> As long as the arbitration mechanism is reconfigurable by = the
>>>> operator to whatever precedence they want, I agree. =A0Its= not clear
>>>> to me if various RIB implementations treat all proffered r= outes the
>>>> same, nor if they store the same meta-data with all protoc= ol sources.
>>>> So there needs to be some way for the operator to leverage= exposed
>>>> protocol-specific optimizations, without conflict from the= other
>>>> routing processes, if they so desire. =A0OTOH if it can al= l be done
>>>> via static routes, it seems much simpler. :)
>>>
>>> Clearly the IRS sub-interface for the RIB needs to introduce/d= efine the different precedences; my assumption is that it would be per rout= e with a well-defined small set of meta-data. =A0This is part of where havi= ng good use-cases will help us understand what behavior is necessary. =A0Th= e static =A0routes do seem like a simpler case to start with.
>>>
>>> Alia
>>> _______________________________________________
>>> 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
> _______________________________________________
> 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

--14dae9340e1b12973204c7512f9b-- Return-Path: 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 8FA1F21F8794 for ; Wed, 15 Aug 2012 10:11:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IGUtJNtBKYrF for ; Wed, 15 Aug 2012 10:11:57 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 8634C21F8772 for ; Wed, 15 Aug 2012 10:11:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8439; q=dns/txt; s=iport; t=1345050717; x=1346260317; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=Vlh33bjfRTdX3d9xtzCkxRmQ5HhIlG6jZDS8PSVdKFY=; b=HzisdjYOUHp97WSQo+nTCjMhsfid2U7G6nOh2upOxa7BYaJuXpGLxSpN leg1aYY9nPuWkyYti6WdyY57w/r7aKwT6WISzhjJfAdKesR7PGcoNMqk1 QdvB4faGBtkHT5q+99LlMVjzROceMVMA+X9+EGdNJfZwGWv4WEPWpGEMK s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAILXK1CtJV2b/2dsb2JhbABFuheBB4IgAQEBBAEBAQ8BJzQLDAQCAQgOAwEDAQEBChQJByEGCxQDBggCBA4FCBMHh1wDCwELmXiWcg2JSgSKJGQUhWNgA5FpOIFbjF+DIIFmgl+BVg X-IronPort-AV: E=Sophos;i="4.77,774,1336348800"; d="scan'208";a="108891965" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-9.cisco.com with ESMTP; 15 Aug 2012 17:11:56 +0000 Received: from xhc-rcd-x10.cisco.com (xhc-rcd-x10.cisco.com [173.37.183.84]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id q7FHBusJ003149 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 15 Aug 2012 17:11:56 GMT Received: from xmb-aln-x09.cisco.com ([169.254.4.26]) by xhc-rcd-x10.cisco.com ([173.37.183.84]) with mapi id 14.02.0298.004; Wed, 15 Aug 2012 12:11:56 -0500 From: "David Lake (dlake)" To: Alia Atlas Thread-Topic: [irs-discuss] IRS comments Thread-Index: Ac15UPmWZFj3YBmsT9Smjrge48ksHAATypTAAFwtz4AAAUAUgAABZOIAAAg193D//9YNAIAAP9Og Date: Wed, 15 Aug 2012 17:11:55 +0000 Message-ID: <3512BB31280C39448A9880F61DD54CEB09C530@xmb-aln-x09.cisco.com> References: <812700A304640D4292205D5E83FC59E1061C211D@p-embx01-eq.jnpr.net> <3512BB31280C39448A9880F61DD54CEB09C07E@xmb-aln-x09.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [171.71.119.1] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19114.004 x-tm-as-result: No--52.359700-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Olen Stokes , "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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Aug 2012 17:11:58 -0000 Hi Alia I already have some use-cases in mind for network service delivery and I'll= work on writing them up. It does appear that the application that the current IRS draft refers to is= management and provisioning within the SP domain. Whilst I agree that the= se are areas in need to standardisation and enhancement, this could be seen= as a sub-set of the wider application integration to the transport layer t= hat is needed - a use-case, if you will. The underlying principles of IRS as put out in the draft does appear to pro= vide an extensible, scalable protocol that would appeal to generic applicat= ion providers - what will be key is to ensure that the primitives provided = to/from the application are relevant and in terms that an application provi= der would understand. It is unlikely that the nuances of routing will be = of any interest to most applications.=20 One possible solution to this is to create another protocol similar and rel= ated to IRS that represents the entirety of the transport infrastructure be= tween content and consumer in terms that are relevant to the application. = However, I want to avoid creating yet another layer with the associated RP= C complexities - that will not assist with long-term adoption. So, I am wondering if IRS can become a more broad-based representative prot= ocol with one defined use-case being the kind of lower-level RP integration= that is currently envisaged ? David -----Original Message----- From: Alia Atlas [mailto:akatlas@gmail.com]=20 Sent: Wednesday, August 15, 2012 8:48 AM To: David Lake (dlake) Cc: Olen Stokes; irs-discuss@ietf.org Subject: Re: [irs-discuss] IRS comments Hi David, We do need to clarify what is meant by an application. I would not expect = that real user-land applications would talk directly to routing devices via= IRS. I can see that going through an intermediary. The IRS abstractions = are unlikely to be as high-level as user-land applications would want and t= he security and policy issues would get exciting. Clarifying what applications are more in-scope initially is part of where u= se-cases will help. Can you write up ones to categorize/describe your thou= ghts? Alia On Wed, Aug 15, 2012 at 11:40 AM, David Lake (dlake) wrot= e: > As another newbie to this, I have some questions about "application vendo= rs." > > Who is the target audience here ? That will determine what functionalit= y and abstraction of the network we need to expose to that "application." > > This presently appears to be a little confused - at least in my mind. Th= e draft talks very much as if the application we are addressing is an OSS/B= SS system, essentially provisioning from the domain owner. > > However, linking this to the wider goals of SDN as voiced by customers/us= ers at the first Open Network Summit, there appears to be a desire for cros= s-domain and user-land application integration. > > At this level - as an example giving a content cache the ability to ensur= e delivery of an HD video to an end user - the application will not be inte= rested in the underlying topology of the network; it will need to know tha= t application X can be delivered with parameters Y between reading from the= content store to delivery to the user's browser. How the stream traverse= s the infrastructure is immaterial. > > Are we intending that IRS satisfies BOTH these requirements (i.e. for ALL= applications ?), or should we be more prescriptive about which application= space we are addressing ? > > Thanks > > David > > -----Original Message----- > From: irs-discuss-bounces@ietf.org=20 > [mailto:irs-discuss-bounces@ietf.org] On Behalf Of Alia Atlas > Sent: Wednesday, August 15, 2012 7:23 AM > To: Olen Stokes > Cc: irs-discuss@ietf.org > Subject: Re: [irs-discuss] IRS comments > > I have not specifically heard from application vendors about this. > My current plan is that we focus on a Use-Cases draft and define within t= hat some motivating use-cases that we agree are good first targets. Those = can drive which subset of functionality we focus on. > > More use-cases are, of course, quite welcome. Posting them to the mailin= g list is a good first start. Russ White is starting the general use-cases= draft based on the three use-cases that he sent to the list. > > Alia > > On Wed, Aug 15, 2012 at 9:43 AM, Olen Stokes wrote: >> Are there applications vendors out there that already have specific requ= irements for what this " subset of the data-models for sub-interfaces" sho= uld be? >> >> Olen >> >> -----Original Message----- >> From: irs-discuss-bounces@ietf.org >> [mailto:irs-discuss-bounces@ietf.org] On Behalf Of Alia Atlas >> Sent: Wednesday, August 15, 2012 9:08 AM >> To: Shah, Himanshu >> Cc: Gert Grammel; irs-discuss@ietf.org; Lenny Giuliano; Thomas=20 >> Nadeau; Alia Atlas; Scott Whyte >> Subject: Re: [irs-discuss] IRS comments >> >> Hi Himanshu, >> >> Welcome. I agree that IRS isn't going to spring into being fully >> formed - I expect that we'll focus on a subset of the data-models for su= b-interfaces along with an associated protocol (whether that is a new one o= r extending an existing one). >> >> Alia >> >> On Wed, Aug 15, 2012 at 7:41 AM, Shah, Himanshu wrote: >>> Newbie to this discussions list and have read only a last couple of mai= ls, so pardon the repeat if somebody has already raised the following as a = concern. >>> >>> I realize we are early in IRS architecture definition but one thing to = keep in mind is the user experience. >>> We need to make sure that exposed interface to=20 >>> RIB/LFIB/FIB/IGPs/BGP/LSDBs etc etc provide a consistent predictive ac= tion/response/events even when different implementations has varying capabi= lities. >>> >>> At the moment it seems like a wild wild west. >>> Perhaps IRS can be defined in phases starting with a simpler, limited v= ersion.. >>> >>> Thanks, >>> himanshu >>> >>> >>> -----Original Message----- >>> From: irs-discuss-bounces@ietf.org >>> [mailto:irs-discuss-bounces@ietf.org] On Behalf Of Alia Atlas >>> Sent: Monday, August 13, 2012 8:41 AM >>> To: Scott Whyte >>> Cc: Thomas Nadeau; Gert Grammel; Alia Atlas; Lenny Giuliano;=20 >>> irs-discuss@ietf.org >>> Subject: Re: [irs-discuss] IRS comments >>> >>> ...snip... >>> >>> On Fri, Aug 10, 2012 at 9:03 PM, Scott Whyte wrote: >>>> On Fri, Aug 10, 2012 at 5:16 PM, Alia Atlas wrote: >>> >>>>> I do think it is important to have the RIB as an arbitration mechanis= m >>>>> on the device. Russ's suggestion that for the RIB sub-interface, th= e >>>>> IRS agent might communicate logically to an IRS routing process=20 >>>>> gives good semantics and interactions. Obviously, implementations=20 >>>>> may differ. >>>> >>>> As long as the arbitration mechanism is reconfigurable by the=20 >>>> operator to whatever precedence they want, I agree. Its not clear=20 >>>> to me if various RIB implementations treat all proffered routes the=20 >>>> same, nor if they store the same meta-data with all protocol sources. >>>> So there needs to be some way for the operator to leverage exposed=20 >>>> protocol-specific optimizations, without conflict from the other=20 >>>> routing processes, if they so desire. OTOH if it can all be done=20 >>>> via static routes, it seems much simpler. :) >>> >>> Clearly the IRS sub-interface for the RIB needs to introduce/define the= different precedences; my assumption is that it would be per route with a = well-defined small set of meta-data. This is part of where having good use= -cases will help us understand what behavior is necessary. The static rou= tes do seem like a simpler case to start with. >>> >>> Alia >>> _______________________________________________ >>> 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 > _______________________________________________ > irs-discuss mailing list > irs-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/irs-discuss Return-Path: 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 E33AA21F8826 for ; Wed, 15 Aug 2012 09:59:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.399 X-Spam-Level: X-Spam-Status: No, score=-7.399 tagged_above=-999 required=5 tests=[AWL=-0.800, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4nycHV7Tv0aq for ; Wed, 15 Aug 2012 09:59:39 -0700 (PDT) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by ietfa.amsl.com (Postfix) with ESMTP id B116A21F85AC for ; Wed, 15 Aug 2012 09:59:32 -0700 (PDT) Received: from inbansmailrelay2.in.alcatel-lucent.com (h135-250-11-33.lucent.com [135.250.11.33]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id q7FGxQZ2016536 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 15 Aug 2012 11:59:28 -0500 (CDT) Received: from INBANSXCHHUB03.in.alcatel-lucent.com (inbansxchhub03.in.alcatel-lucent.com [135.250.12.80]) by inbansmailrelay2.in.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id q7FGxP10008577 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 15 Aug 2012 22:29:25 +0530 Received: from INBANSXCHMBSA3.in.alcatel-lucent.com ([135.250.12.50]) by INBANSXCHHUB03.in.alcatel-lucent.com ([135.250.12.80]) with mapi; Wed, 15 Aug 2012 22:29:25 +0530 From: "Dutta, Pranjal K (Pranjal)" To: Alia Atlas Date: Wed, 15 Aug 2012 22:29:23 +0530 Thread-Topic: [irs-discuss] IRS comments Thread-Index: Ac17Bgaqgwk9l/rTQpG8K2ktnROtcAAAME+w Message-ID: References: <812700A304640D4292205D5E83FC59E1061C211D@p-embx01-eq.jnpr.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 Cc: "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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Aug 2012 16:59:41 -0000 I agree. I saw your responses later and I think building strong use-cases f= irst would help. I am looking more from an implementation perspective and t= hus interested to see what makes more realistic. =20 Thanks, Pranjal -----Original Message----- From: Alia Atlas [mailto:akatlas@gmail.com]=20 Sent: Wednesday, August 15, 2012 9:50 AM To: Dutta, Pranjal K (Pranjal) Cc: irs-discuss@ietf.org Subject: Re: [irs-discuss] IRS comments This is why I want to focus on use-cases. From there, I think we can develop realistic requirements. Feel free to contribute :-) Alia On Wed, Aug 15, 2012 at 12:47 PM, Dutta, Pranjal K (Pranjal) wrote: > +1. I am a newbie and have been observing the discussions so far. However= it is not clear to me about the requirements. I think a sound approach is = to solidify the requirements and then think about the solutions (APIs, the = real-time transaction protocol etc). > > Thanks, > Pranjal > > -----Original Message----- > From: irs-discuss-bounces@ietf.org [mailto:irs-discuss-bounces@ietf.org] = On Behalf Of Olen Stokes > Sent: Wednesday, August 15, 2012 6:43 AM > To: Alia Atlas; Shah, Himanshu > Cc: Gert Grammel; irs-discuss@ietf.org; Lenny Giuliano; Thomas Nadeau; Al= ia Atlas; Scott Whyte > Subject: Re: [irs-discuss] IRS comments > > Are there applications vendors out there that already have specific requi= rements for what this " subset of the data-models for sub-interfaces" shou= ld be? > > Olen > > -----Original Message----- > From: irs-discuss-bounces@ietf.org [mailto:irs-discuss-bounces@ietf.org] = On Behalf Of Alia Atlas > Sent: Wednesday, August 15, 2012 9:08 AM > To: Shah, Himanshu > Cc: Gert Grammel; irs-discuss@ietf.org; Lenny Giuliano; Thomas Nadeau; Al= ia Atlas; Scott Whyte > Subject: Re: [irs-discuss] IRS comments > > Hi Himanshu, > > Welcome. I agree that IRS isn't going to spring into being fully > formed - I expect that we'll focus on a subset of the data-models for sub= -interfaces along with an associated protocol (whether that is a new one or= extending an existing one). > > Alia > > On Wed, Aug 15, 2012 at 7:41 AM, Shah, Himanshu wrote: >> Newbie to this discussions list and have read only a last couple of mail= s, so pardon the repeat if somebody has already raised the following as a c= oncern. >> >> I realize we are early in IRS architecture definition but one thing to k= eep in mind is the user experience. >> We need to make sure that exposed interface to >> RIB/LFIB/FIB/IGPs/BGP/LSDBs etc etc provide a consistent predictive act= ion/response/events even when different implementations has varying capabil= ities. >> >> At the moment it seems like a wild wild west. >> Perhaps IRS can be defined in phases starting with a simpler, limited ve= rsion.. >> >> Thanks, >> himanshu >> >> >> -----Original Message----- >> From: irs-discuss-bounces@ietf.org >> [mailto:irs-discuss-bounces@ietf.org] On Behalf Of Alia Atlas >> Sent: Monday, August 13, 2012 8:41 AM >> To: Scott Whyte >> Cc: Thomas Nadeau; Gert Grammel; Alia Atlas; Lenny Giuliano; >> irs-discuss@ietf.org >> Subject: Re: [irs-discuss] IRS comments >> >> ...snip... >> >> On Fri, Aug 10, 2012 at 9:03 PM, Scott Whyte wrote: >>> On Fri, Aug 10, 2012 at 5:16 PM, Alia Atlas wrote: >> >>>> I do think it is important to have the RIB as an arbitration mechanism >>>> on the device. Russ's suggestion that for the RIB sub-interface, the >>>> IRS agent might communicate logically to an IRS routing process >>>> gives good semantics and interactions. Obviously, implementations >>>> may differ. >>> >>> As long as the arbitration mechanism is reconfigurable by the >>> operator to whatever precedence they want, I agree. Its not clear to >>> me if various RIB implementations treat all proffered routes the >>> same, nor if they store the same meta-data with all protocol sources. >>> So there needs to be some way for the operator to leverage exposed >>> protocol-specific optimizations, without conflict from the other >>> routing processes, if they so desire. OTOH if it can all be done via >>> static routes, it seems much simpler. :) >> >> Clearly the IRS sub-interface for the RIB needs to introduce/define the = different precedences; my assumption is that it would be per route with a w= ell-defined small set of meta-data. This is part of where having good use-= cases will help us understand what behavior is necessary. The static rout= es do seem like a simpler case to start with. >> >> Alia >> _______________________________________________ >> 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 > _______________________________________________ > irs-discuss mailing list > irs-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/irs-discuss Return-Path: 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 5906021F8819 for ; Wed, 15 Aug 2012 09:50:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.556 X-Spam-Level: X-Spam-Status: No, score=-3.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jnPXM8K1MtRs for ; Wed, 15 Aug 2012 09:50:05 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 189A221F87DA for ; Wed, 15 Aug 2012 09:50:04 -0700 (PDT) Received: by yhq56 with SMTP id 56so2157022yhq.31 for ; Wed, 15 Aug 2012 09:50:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=YrhTokIdGp3D6CCXau6+AiO8mSM44piFcnCx11Md3Sc=; b=fvW2rK7Dwyaca1dYyMC7gja1QNLCH1xEWeDdmr7ziClgon//wzh/tgCzXSTCUQqytQ Y8aayPOJthr0Um3X1AuLzhDuO/SXzyuvxT9E8rnV/A0WEC6f7nnvxf4pl1E9smwmqBfr 90KbO2b6pbesf4zMiUDni4KFo45dx556KRwppFuNtsy1rCJLUI1o8QkIEFwezxPVqshK G1aaPWZYBLVJjd6eNyrUZu39wm+NJgG3sggkMFDYsSqggdPYNDB3lYIFhKq6TEy5QBgJ eJGBa7/kwmoswFcLPsw3MFpRwDzO2xXrH4foObi+dOPd6Dsro67S1vjDfhHqm2yhttrJ XxLQ== MIME-Version: 1.0 Received: by 10.50.237.38 with SMTP id uz6mr19248711igc.2.1345049404536; Wed, 15 Aug 2012 09:50:04 -0700 (PDT) Received: by 10.50.91.135 with HTTP; Wed, 15 Aug 2012 09:50:04 -0700 (PDT) In-Reply-To: References: <812700A304640D4292205D5E83FC59E1061C211D@p-embx01-eq.jnpr.net> Date: Wed, 15 Aug 2012 12:50:04 -0400 Message-ID: From: Alia Atlas To: "Dutta, Pranjal K (Pranjal)" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Aug 2012 16:50:06 -0000 This is why I want to focus on use-cases. From there, I think we can develop realistic requirements. Feel free to contribute :-) Alia On Wed, Aug 15, 2012 at 12:47 PM, Dutta, Pranjal K (Pranjal) wrote: > +1. I am a newbie and have been observing the discussions so far. However= it is not clear to me about the requirements. I think a sound approach is = to solidify the requirements and then think about the solutions (APIs, the = real-time transaction protocol etc). > > Thanks, > Pranjal > > -----Original Message----- > From: irs-discuss-bounces@ietf.org [mailto:irs-discuss-bounces@ietf.org] = On Behalf Of Olen Stokes > Sent: Wednesday, August 15, 2012 6:43 AM > To: Alia Atlas; Shah, Himanshu > Cc: Gert Grammel; irs-discuss@ietf.org; Lenny Giuliano; Thomas Nadeau; Al= ia Atlas; Scott Whyte > Subject: Re: [irs-discuss] IRS comments > > Are there applications vendors out there that already have specific requi= rements for what this " subset of the data-models for sub-interfaces" shou= ld be? > > Olen > > -----Original Message----- > From: irs-discuss-bounces@ietf.org [mailto:irs-discuss-bounces@ietf.org] = On Behalf Of Alia Atlas > Sent: Wednesday, August 15, 2012 9:08 AM > To: Shah, Himanshu > Cc: Gert Grammel; irs-discuss@ietf.org; Lenny Giuliano; Thomas Nadeau; Al= ia Atlas; Scott Whyte > Subject: Re: [irs-discuss] IRS comments > > Hi Himanshu, > > Welcome. I agree that IRS isn't going to spring into being fully > formed - I expect that we'll focus on a subset of the data-models for sub= -interfaces along with an associated protocol (whether that is a new one or= extending an existing one). > > Alia > > On Wed, Aug 15, 2012 at 7:41 AM, Shah, Himanshu wrote: >> Newbie to this discussions list and have read only a last couple of mail= s, so pardon the repeat if somebody has already raised the following as a c= oncern. >> >> I realize we are early in IRS architecture definition but one thing to k= eep in mind is the user experience. >> We need to make sure that exposed interface to >> RIB/LFIB/FIB/IGPs/BGP/LSDBs etc etc provide a consistent predictive act= ion/response/events even when different implementations has varying capabil= ities. >> >> At the moment it seems like a wild wild west. >> Perhaps IRS can be defined in phases starting with a simpler, limited ve= rsion.. >> >> Thanks, >> himanshu >> >> >> -----Original Message----- >> From: irs-discuss-bounces@ietf.org >> [mailto:irs-discuss-bounces@ietf.org] On Behalf Of Alia Atlas >> Sent: Monday, August 13, 2012 8:41 AM >> To: Scott Whyte >> Cc: Thomas Nadeau; Gert Grammel; Alia Atlas; Lenny Giuliano; >> irs-discuss@ietf.org >> Subject: Re: [irs-discuss] IRS comments >> >> ...snip... >> >> On Fri, Aug 10, 2012 at 9:03 PM, Scott Whyte wrote: >>> On Fri, Aug 10, 2012 at 5:16 PM, Alia Atlas wrote: >> >>>> I do think it is important to have the RIB as an arbitration mechanism >>>> on the device. Russ's suggestion that for the RIB sub-interface, the >>>> IRS agent might communicate logically to an IRS routing process >>>> gives good semantics and interactions. Obviously, implementations >>>> may differ. >>> >>> As long as the arbitration mechanism is reconfigurable by the >>> operator to whatever precedence they want, I agree. Its not clear to >>> me if various RIB implementations treat all proffered routes the >>> same, nor if they store the same meta-data with all protocol sources. >>> So there needs to be some way for the operator to leverage exposed >>> protocol-specific optimizations, without conflict from the other >>> routing processes, if they so desire. OTOH if it can all be done via >>> static routes, it seems much simpler. :) >> >> Clearly the IRS sub-interface for the RIB needs to introduce/define the = different precedences; my assumption is that it would be per route with a w= ell-defined small set of meta-data. This is part of where having good use-= cases will help us understand what behavior is necessary. The static rout= es do seem like a simpler case to start with. >> >> Alia >> _______________________________________________ >> 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 > _______________________________________________ > irs-discuss mailing list > irs-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/irs-discuss Return-Path: 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 BD9BC21F87CB for ; Wed, 15 Aug 2012 09:47:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.456 X-Spam-Level: X-Spam-Status: No, score=-7.456 tagged_above=-999 required=5 tests=[AWL=-0.857, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3XxrwskV3i5f for ; Wed, 15 Aug 2012 09:47:57 -0700 (PDT) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by ietfa.amsl.com (Postfix) with ESMTP id E90A121F8782 for ; Wed, 15 Aug 2012 09:47:56 -0700 (PDT) Received: from inbansmailrelay1.in.alcatel-lucent.com (h135-250-11-31.lucent.com [135.250.11.31]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id q7FGlj2W008530 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 15 Aug 2012 11:47:47 -0500 (CDT) Received: from INBANSXCHHUB03.in.alcatel-lucent.com (inbansxchhub03.in.alcatel-lucent.com [135.250.12.80]) by inbansmailrelay1.in.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id q7FGlhGn001103 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 15 Aug 2012 22:17:44 +0530 Received: from INBANSXCHMBSA3.in.alcatel-lucent.com ([135.250.12.50]) by INBANSXCHHUB03.in.alcatel-lucent.com ([135.250.12.80]) with mapi; Wed, 15 Aug 2012 22:17:43 +0530 From: "Dutta, Pranjal K (Pranjal)" To: Olen Stokes , Alia Atlas , "Shah, Himanshu" Date: Wed, 15 Aug 2012 22:17:40 +0530 Thread-Topic: [irs-discuss] IRS comments Thread-Index: Ac165vtcYYt4PdYBQh2nm9DShDU0rQABDvZgAAaBO+A= Message-ID: References: <812700A304640D4292205D5E83FC59E1061C211D@p-embx01-eq.jnpr.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 Cc: Gert Grammel , "irs-discuss@ietf.org" , Lenny Giuliano , Thomas Nadeau , Alia Atlas , Scott Whyte 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Aug 2012 16:47:57 -0000 +1. I am a newbie and have been observing the discussions so far. However i= t is not clear to me about the requirements. I think a sound approach is to= solidify the requirements and then think about the solutions (APIs, the re= al-time transaction protocol etc).=20 Thanks, Pranjal -----Original Message----- From: irs-discuss-bounces@ietf.org [mailto:irs-discuss-bounces@ietf.org] On= Behalf Of Olen Stokes Sent: Wednesday, August 15, 2012 6:43 AM To: Alia Atlas; Shah, Himanshu Cc: Gert Grammel; irs-discuss@ietf.org; Lenny Giuliano; Thomas Nadeau; Alia= Atlas; Scott Whyte Subject: Re: [irs-discuss] IRS comments Are there applications vendors out there that already have specific require= ments for what this " subset of the data-models for sub-interfaces" should= be? =20 Olen -----Original Message----- From: irs-discuss-bounces@ietf.org [mailto:irs-discuss-bounces@ietf.org] On= Behalf Of Alia Atlas Sent: Wednesday, August 15, 2012 9:08 AM To: Shah, Himanshu Cc: Gert Grammel; irs-discuss@ietf.org; Lenny Giuliano; Thomas Nadeau; Alia= Atlas; Scott Whyte Subject: Re: [irs-discuss] IRS comments Hi Himanshu, Welcome. I agree that IRS isn't going to spring into being fully formed - I expect that we'll focus on a subset of the data-models for sub-i= nterfaces along with an associated protocol (whether that is a new one or e= xtending an existing one). Alia On Wed, Aug 15, 2012 at 7:41 AM, Shah, Himanshu wrote: > Newbie to this discussions list and have read only a last couple of mails= , so pardon the repeat if somebody has already raised the following as a co= ncern. > > I realize we are early in IRS architecture definition but one thing to ke= ep in mind is the user experience. > We need to make sure that exposed interface to=20 > RIB/LFIB/FIB/IGPs/BGP/LSDBs etc etc provide a consistent predictive acti= on/response/events even when different implementations has varying capabili= ties. > > At the moment it seems like a wild wild west. > Perhaps IRS can be defined in phases starting with a simpler, limited ver= sion.. > > Thanks, > himanshu > > > -----Original Message----- > From: irs-discuss-bounces@ietf.org=20 > [mailto:irs-discuss-bounces@ietf.org] On Behalf Of Alia Atlas > Sent: Monday, August 13, 2012 8:41 AM > To: Scott Whyte > Cc: Thomas Nadeau; Gert Grammel; Alia Atlas; Lenny Giuliano;=20 > irs-discuss@ietf.org > Subject: Re: [irs-discuss] IRS comments > > ...snip... > > On Fri, Aug 10, 2012 at 9:03 PM, Scott Whyte wrote: >> On Fri, Aug 10, 2012 at 5:16 PM, Alia Atlas wrote: > >>> I do think it is important to have the RIB as an arbitration mechanism >>> on the device. Russ's suggestion that for the RIB sub-interface, the >>> IRS agent might communicate logically to an IRS routing process=20 >>> gives good semantics and interactions. Obviously, implementations=20 >>> may differ. >> >> As long as the arbitration mechanism is reconfigurable by the=20 >> operator to whatever precedence they want, I agree. Its not clear to=20 >> me if various RIB implementations treat all proffered routes the=20 >> same, nor if they store the same meta-data with all protocol sources. =20 >> So there needs to be some way for the operator to leverage exposed=20 >> protocol-specific optimizations, without conflict from the other=20 >> routing processes, if they so desire. OTOH if it can all be done via=20 >> static routes, it seems much simpler. :) > > Clearly the IRS sub-interface for the RIB needs to introduce/define the d= ifferent precedences; my assumption is that it would be per route with a we= ll-defined small set of meta-data. This is part of where having good use-c= ases will help us understand what behavior is necessary. The static route= s do seem like a simpler case to start with. > > Alia > _______________________________________________ > 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 _______________________________________________ irs-discuss mailing list irs-discuss@ietf.org https://www.ietf.org/mailman/listinfo/irs-discuss Return-Path: 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 D303A21F885D for ; Wed, 15 Aug 2012 08:48:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BhpncnmflQqq for ; Wed, 15 Aug 2012 08:48:22 -0700 (PDT) Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 79FCB21F8844 for ; Wed, 15 Aug 2012 08:48:22 -0700 (PDT) Received: by wgbdr13 with SMTP id dr13so1023921wgb.13 for ; Wed, 15 Aug 2012 08:48:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=2j2nQbwnvaPhPdL1RIm4njqK3W+FNJAyhBzsK53iCRA=; b=C3ZRXLXXwrvCdJrBuvOs3BlW6c2oNlaQwczetCiCOw+UdzHLxbER16cft4kALyABVD uXqOjS3bs7YywtwJszkmisLM5w+uYjhOnibCvzW0UhQ0OHyQGBodRiweCULfDc3YmXuF 6usbVUG/y+/YdVVXdOE9BoKzaVY6+obDuxw1QcIVCAoTMW9xeHdeNM5JB2FgRnjaGm58 XUL/jtLiV/MY5mDnDk5Sw9bzH1QeKnE3KvYSEuUv52cYKQsJ//uhEFVn1FZrp0fSBvHu bpjNYzIB+2eQvntQqmlhU1r9cg/OLjgxGQWE4FL9JL1IU0oldo3CXzh/1JvFz5I9kn8B KcrQ== MIME-Version: 1.0 Received: by 10.50.209.8 with SMTP id mi8mr19343788igc.63.1345045700606; Wed, 15 Aug 2012 08:48:20 -0700 (PDT) Received: by 10.50.91.135 with HTTP; Wed, 15 Aug 2012 08:48:20 -0700 (PDT) In-Reply-To: <3512BB31280C39448A9880F61DD54CEB09C07E@xmb-aln-x09.cisco.com> References: <812700A304640D4292205D5E83FC59E1061C211D@p-embx01-eq.jnpr.net> <3512BB31280C39448A9880F61DD54CEB09C07E@xmb-aln-x09.cisco.com> Date: Wed, 15 Aug 2012 11:48:20 -0400 Message-ID: From: Alia Atlas To: "David Lake (dlake)" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Olen Stokes , "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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Aug 2012 15:48:23 -0000 Hi David, We do need to clarify what is meant by an application. I would not expect that real user-land applications would talk directly to routing devices via IRS. I can see that going through an intermediary. The IRS abstractions are unlikely to be as high-level as user-land applications would want and the security and policy issues would get exciting. Clarifying what applications are more in-scope initially is part of where use-cases will help. Can you write up ones to categorize/describe your thoughts? Alia On Wed, Aug 15, 2012 at 11:40 AM, David Lake (dlake) wrot= e: > As another newbie to this, I have some questions about "application vendo= rs." > > Who is the target audience here ? That will determine what functionalit= y and abstraction of the network we need to expose to that "application." > > This presently appears to be a little confused - at least in my mind. Th= e draft talks very much as if the application we are addressing is an OSS/B= SS system, essentially provisioning from the domain owner. > > However, linking this to the wider goals of SDN as voiced by customers/us= ers at the first Open Network Summit, there appears to be a desire for cros= s-domain and user-land application integration. > > At this level - as an example giving a content cache the ability to ensur= e delivery of an HD video to an end user - the application will not be inte= rested in the underlying topology of the network; it will need to know tha= t application X can be delivered with parameters Y between reading from the= content store to delivery to the user's browser. How the stream traverse= s the infrastructure is immaterial. > > Are we intending that IRS satisfies BOTH these requirements (i.e. for ALL= applications ?), or should we be more prescriptive about which application= space we are addressing ? > > Thanks > > David > > -----Original Message----- > From: irs-discuss-bounces@ietf.org [mailto:irs-discuss-bounces@ietf.org] = On Behalf Of Alia Atlas > Sent: Wednesday, August 15, 2012 7:23 AM > To: Olen Stokes > Cc: irs-discuss@ietf.org > Subject: Re: [irs-discuss] IRS comments > > I have not specifically heard from application vendors about this. > My current plan is that we focus on a Use-Cases draft and define within t= hat some motivating use-cases that we agree are good first targets. Those = can drive which subset of functionality we focus on. > > More use-cases are, of course, quite welcome. Posting them to the mailin= g list is a good first start. Russ White is starting the general use-cases= draft based on the three use-cases that he sent to the list. > > Alia > > On Wed, Aug 15, 2012 at 9:43 AM, Olen Stokes wrote: >> Are there applications vendors out there that already have specific requ= irements for what this " subset of the data-models for sub-interfaces" sho= uld be? >> >> Olen >> >> -----Original Message----- >> From: irs-discuss-bounces@ietf.org >> [mailto:irs-discuss-bounces@ietf.org] On Behalf Of Alia Atlas >> Sent: Wednesday, August 15, 2012 9:08 AM >> To: Shah, Himanshu >> Cc: Gert Grammel; irs-discuss@ietf.org; Lenny Giuliano; Thomas Nadeau; >> Alia Atlas; Scott Whyte >> Subject: Re: [irs-discuss] IRS comments >> >> Hi Himanshu, >> >> Welcome. I agree that IRS isn't going to spring into being fully >> formed - I expect that we'll focus on a subset of the data-models for su= b-interfaces along with an associated protocol (whether that is a new one o= r extending an existing one). >> >> Alia >> >> On Wed, Aug 15, 2012 at 7:41 AM, Shah, Himanshu wrote: >>> Newbie to this discussions list and have read only a last couple of mai= ls, so pardon the repeat if somebody has already raised the following as a = concern. >>> >>> I realize we are early in IRS architecture definition but one thing to = keep in mind is the user experience. >>> We need to make sure that exposed interface to >>> RIB/LFIB/FIB/IGPs/BGP/LSDBs etc etc provide a consistent predictive ac= tion/response/events even when different implementations has varying capabi= lities. >>> >>> At the moment it seems like a wild wild west. >>> Perhaps IRS can be defined in phases starting with a simpler, limited v= ersion.. >>> >>> Thanks, >>> himanshu >>> >>> >>> -----Original Message----- >>> From: irs-discuss-bounces@ietf.org >>> [mailto:irs-discuss-bounces@ietf.org] On Behalf Of Alia Atlas >>> Sent: Monday, August 13, 2012 8:41 AM >>> To: Scott Whyte >>> Cc: Thomas Nadeau; Gert Grammel; Alia Atlas; Lenny Giuliano; >>> irs-discuss@ietf.org >>> Subject: Re: [irs-discuss] IRS comments >>> >>> ...snip... >>> >>> On Fri, Aug 10, 2012 at 9:03 PM, Scott Whyte wrote: >>>> On Fri, Aug 10, 2012 at 5:16 PM, Alia Atlas wrote: >>> >>>>> I do think it is important to have the RIB as an arbitration mechanis= m >>>>> on the device. Russ's suggestion that for the RIB sub-interface, th= e >>>>> IRS agent might communicate logically to an IRS routing process >>>>> gives good semantics and interactions. Obviously, implementations >>>>> may differ. >>>> >>>> As long as the arbitration mechanism is reconfigurable by the >>>> operator to whatever precedence they want, I agree. Its not clear >>>> to me if various RIB implementations treat all proffered routes the >>>> same, nor if they store the same meta-data with all protocol sources. >>>> So there needs to be some way for the operator to leverage exposed >>>> protocol-specific optimizations, without conflict from the other >>>> routing processes, if they so desire. OTOH if it can all be done >>>> via static routes, it seems much simpler. :) >>> >>> Clearly the IRS sub-interface for the RIB needs to introduce/define the= different precedences; my assumption is that it would be per route with a = well-defined small set of meta-data. This is part of where having good use= -cases will help us understand what behavior is necessary. The static rou= tes do seem like a simpler case to start with. >>> >>> Alia >>> _______________________________________________ >>> 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 > _______________________________________________ > irs-discuss mailing list > irs-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/irs-discuss Return-Path: 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 8489421E80F5 for ; Wed, 15 Aug 2012 08:40:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EEAE+pWlZqXo for ; Wed, 15 Aug 2012 08:40:37 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 8236521E80F4 for ; Wed, 15 Aug 2012 08:40:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dlake@cisco.com; l=5959; q=dns/txt; s=iport; t=1345045237; x=1346254837; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=hu91XDwUE+wr0kaNUcNRe1hpmuIcSPi0sBj3a9dvq48=; b=hH/1vjybrqGBElTUfuLdM9nOJ+jX7EwDgdnk4Q7tt4UdhBPzYy35B2dZ PxS2FdgDTlx7kvwyBsB939OFO1wZX2lFAAUNU4aeVH5axdbm+AxrJSe4Z feYVKD22SJuFIrTugxZtwXxB/oTVuFe9hC3VV10GGg/Bx2fb429O7mztG 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAKTCK1CtJV2Z/2dsb2JhbABFuheBB4IgAQEBBAEBAQ8BJzQLDAQCAQgOAwEDAQEBChQJByEGCxQDBggBAQQBDQUIGodcAwwLmWmWcg2JSgSKJGQUhWNgA5FpOIFbjF+DIIFmgl+BVg X-IronPort-AV: E=Sophos;i="4.77,773,1336348800"; d="scan'208";a="111848061" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-5.cisco.com with ESMTP; 15 Aug 2012 15:40:35 +0000 Received: from xhc-rcd-x13.cisco.com (xhc-rcd-x13.cisco.com [173.37.183.87]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id q7FFeZLH031465 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 15 Aug 2012 15:40:35 GMT Received: from xmb-aln-x09.cisco.com ([169.254.4.26]) by xhc-rcd-x13.cisco.com ([173.37.183.87]) with mapi id 14.02.0298.004; Wed, 15 Aug 2012 10:40:35 -0500 From: "David Lake (dlake)" To: Alia Atlas , Olen Stokes Thread-Topic: [irs-discuss] IRS comments Thread-Index: Ac15UPmWZFj3YBmsT9Smjrge48ksHAATypTAAFwtz4AAAUAUgAABZOIAAAg193A= Date: Wed, 15 Aug 2012 15:40:34 +0000 Message-ID: <3512BB31280C39448A9880F61DD54CEB09C07E@xmb-aln-x09.cisco.com> References: <812700A304640D4292205D5E83FC59E1061C211D@p-embx01-eq.jnpr.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.20.230.217] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19114.004 x-tm-as-result: No--51.626000-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Aug 2012 15:40:38 -0000 As another newbie to this, I have some questions about "application vendors= ." Who is the target audience here ? That will determine what functionality = and abstraction of the network we need to expose to that "application." This presently appears to be a little confused - at least in my mind. The = draft talks very much as if the application we are addressing is an OSS/BSS= system, essentially provisioning from the domain owner. However, linking this to the wider goals of SDN as voiced by customers/user= s at the first Open Network Summit, there appears to be a desire for cross-= domain and user-land application integration. At this level - as an example giving a content cache the ability to ensure = delivery of an HD video to an end user - the application will not be intere= sted in the underlying topology of the network; it will need to know that = application X can be delivered with parameters Y between reading from the c= ontent store to delivery to the user's browser. How the stream traverses = the infrastructure is immaterial. Are we intending that IRS satisfies BOTH these requirements (i.e. for ALL a= pplications ?), or should we be more prescriptive about which application s= pace we are addressing ? Thanks David -----Original Message----- From: irs-discuss-bounces@ietf.org [mailto:irs-discuss-bounces@ietf.org] On= Behalf Of Alia Atlas Sent: Wednesday, August 15, 2012 7:23 AM To: Olen Stokes Cc: irs-discuss@ietf.org Subject: Re: [irs-discuss] IRS comments I have not specifically heard from application vendors about this. My current plan is that we focus on a Use-Cases draft and define within tha= t some motivating use-cases that we agree are good first targets. Those ca= n drive which subset of functionality we focus on. More use-cases are, of course, quite welcome. Posting them to the mailing = list is a good first start. Russ White is starting the general use-cases d= raft based on the three use-cases that he sent to the list. Alia On Wed, Aug 15, 2012 at 9:43 AM, Olen Stokes = wrote: > Are there applications vendors out there that already have specific requi= rements for what this " subset of the data-models for sub-interfaces" shou= ld be? > > Olen > > -----Original Message----- > From: irs-discuss-bounces@ietf.org=20 > [mailto:irs-discuss-bounces@ietf.org] On Behalf Of Alia Atlas > Sent: Wednesday, August 15, 2012 9:08 AM > To: Shah, Himanshu > Cc: Gert Grammel; irs-discuss@ietf.org; Lenny Giuliano; Thomas Nadeau;=20 > Alia Atlas; Scott Whyte > Subject: Re: [irs-discuss] IRS comments > > Hi Himanshu, > > Welcome. I agree that IRS isn't going to spring into being fully > formed - I expect that we'll focus on a subset of the data-models for sub= -interfaces along with an associated protocol (whether that is a new one or= extending an existing one). > > Alia > > On Wed, Aug 15, 2012 at 7:41 AM, Shah, Himanshu wrote: >> Newbie to this discussions list and have read only a last couple of mail= s, so pardon the repeat if somebody has already raised the following as a c= oncern. >> >> I realize we are early in IRS architecture definition but one thing to k= eep in mind is the user experience. >> We need to make sure that exposed interface to=20 >> RIB/LFIB/FIB/IGPs/BGP/LSDBs etc etc provide a consistent predictive act= ion/response/events even when different implementations has varying capabil= ities. >> >> At the moment it seems like a wild wild west. >> Perhaps IRS can be defined in phases starting with a simpler, limited ve= rsion.. >> >> Thanks, >> himanshu >> >> >> -----Original Message----- >> From: irs-discuss-bounces@ietf.org >> [mailto:irs-discuss-bounces@ietf.org] On Behalf Of Alia Atlas >> Sent: Monday, August 13, 2012 8:41 AM >> To: Scott Whyte >> Cc: Thomas Nadeau; Gert Grammel; Alia Atlas; Lenny Giuliano;=20 >> irs-discuss@ietf.org >> Subject: Re: [irs-discuss] IRS comments >> >> ...snip... >> >> On Fri, Aug 10, 2012 at 9:03 PM, Scott Whyte wrote: >>> On Fri, Aug 10, 2012 at 5:16 PM, Alia Atlas wrote: >> >>>> I do think it is important to have the RIB as an arbitration mechanism >>>> on the device. Russ's suggestion that for the RIB sub-interface, the >>>> IRS agent might communicate logically to an IRS routing process=20 >>>> gives good semantics and interactions. Obviously, implementations=20 >>>> may differ. >>> >>> As long as the arbitration mechanism is reconfigurable by the=20 >>> operator to whatever precedence they want, I agree. Its not clear=20 >>> to me if various RIB implementations treat all proffered routes the=20 >>> same, nor if they store the same meta-data with all protocol sources. >>> So there needs to be some way for the operator to leverage exposed=20 >>> protocol-specific optimizations, without conflict from the other=20 >>> routing processes, if they so desire. OTOH if it can all be done=20 >>> via static routes, it seems much simpler. :) >> >> Clearly the IRS sub-interface for the RIB needs to introduce/define the = different precedences; my assumption is that it would be per route with a w= ell-defined small set of meta-data. This is part of where having good use-= cases will help us understand what behavior is necessary. The static rout= es do seem like a simpler case to start with. >> >> Alia >> _______________________________________________ >> 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 _______________________________________________ irs-discuss mailing list irs-discuss@ietf.org https://www.ietf.org/mailman/listinfo/irs-discuss Return-Path: 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 A470621F8702 for ; Wed, 15 Aug 2012 07:32:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.555 X-Spam-Level: X-Spam-Status: No, score=-3.555 tagged_above=-999 required=5 tests=[AWL=0.044, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RVBvxpGNYHvf for ; Wed, 15 Aug 2012 07:32:36 -0700 (PDT) Received: from mail-qa0-f51.google.com (mail-qa0-f51.google.com [209.85.216.51]) by ietfa.amsl.com (Postfix) with ESMTP id 2FCD021F86F3 for ; Wed, 15 Aug 2012 07:32:36 -0700 (PDT) Received: by qadz3 with SMTP id z3so1295068qad.10 for ; Wed, 15 Aug 2012 07:32:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=l2rhqjFKGiwPKycJ14h4mUSv4XzlRBhhnpaGO5g8dOQ=; b=BaX+qb8pYY9XB0jbC8IYlD3nSyl/vSB3NCRj6JOjw7lLJVTh3jXkIc8IAlf8b3183D DZhnyEPXFAt0PF5M01iEmCm5bxu11VcTHTPsBapt5fZOy6N09t4vwRy7DDAFO1xOLxyB RhhAttg4p5KuUQTLlwUxl3cMWRVMaT643kkeXbFTc6Y307qngDDn8Ng/xCcrw5azOSqK YXKrzf5lNGjGvwY0WGW0rLPvQ40poUSG3j6BlFPusXLqgBkkWlhDQIV1TodAnoyXvZII VQB2fCRbvfzHBbBBlQU0VcetJSMCb8M9OgEq+pXlZW4qaNYAJjn7FFTaI4vpEoUcoUNY hgPQ== MIME-Version: 1.0 Received: by 10.50.95.225 with SMTP id dn1mr18438898igb.58.1345041155369; Wed, 15 Aug 2012 07:32:35 -0700 (PDT) Received: by 10.50.91.135 with HTTP; Wed, 15 Aug 2012 07:32:35 -0700 (PDT) Date: Wed, 15 Aug 2012 10:32:35 -0400 Message-ID: From: Alia Atlas To: irs-discuss@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [irs-discuss] plan before next IETF and drafts X-BeenThere: irs-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Aug 2012 14:32:36 -0000 We are trying to ramp IRS up for a BOF at the next IETF. This means going very quickly on getting additional focus and drafts together to explain the focus, scope, use-cases, etc. Our first goal is to have an expanded/updated set of drafts by September 10 at the latest. Among those drafts are at least a General Use-Cases, a Topology-specific Use-Cases and Requirements, and an IRS protocol requirements. We're also looking at a Policy Framework and a draft about data-model architecture. If you are interested in contributing to any of these drafts, please let me know. If you're working on other related drafts, I'd be interested in hearing about them. Also, please send comments on the existing IRS problem-statement and IRS framework drafts. I expect that we'll revise them at the end of the month. Thanks, Alia Return-Path: 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 5AB8121F87E8 for ; Wed, 15 Aug 2012 07:23:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.554 X-Spam-Level: X-Spam-Status: No, score=-3.554 tagged_above=-999 required=5 tests=[AWL=0.045, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8Bw+KLmTo+zm for ; Wed, 15 Aug 2012 07:23:23 -0700 (PDT) Received: from mail-gg0-f172.google.com (mail-gg0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8079721F87C1 for ; Wed, 15 Aug 2012 07:23:23 -0700 (PDT) Received: by ggnh4 with SMTP id h4so1989640ggn.31 for ; Wed, 15 Aug 2012 07:23:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=VFclhf5J3nKBZY88wVgPLRDnkM0v7v/B6Tbjh2pz7eY=; b=tGlUhHTpFFhy7/jInq/L53jUg8goxPuasTIY4JHbPfx1Wyd9LWmp5+z3Dj0d+CboCB 6LczfgGi62cbliaPsUxl9RWP9nDcBnEigVpODz/NvfjQlgjUkm3ZbTpr3kyFire4chmV M54mHTI4hnVSmpHyDVdPjZUhwpbwkXVfSA7ndXd2HBlJsAmeN8t6vvRFFzlX/fGrvrM7 abDiFY5VRuwBOF52INIqQTYhQiYIIvcSYrqE8utVN+KRXddrhKF6z1uRU5l0tijAqdil 2m1yCOMiBdo7Q4GCjSL+W8uiMuxtUKaZr1LdGGC5Oh/TPnzV+zzlba/8kCgqYgPLCYro s9wQ== MIME-Version: 1.0 Received: by 10.50.149.202 with SMTP id uc10mr14599478igb.2.1345040602735; Wed, 15 Aug 2012 07:23:22 -0700 (PDT) Received: by 10.50.91.135 with HTTP; Wed, 15 Aug 2012 07:23:22 -0700 (PDT) In-Reply-To: References: <812700A304640D4292205D5E83FC59E1061C211D@p-embx01-eq.jnpr.net> Date: Wed, 15 Aug 2012 10:23:22 -0400 Message-ID: From: Alia Atlas To: Olen Stokes Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Aug 2012 14:23:24 -0000 I have not specifically heard from application vendors about this. My current plan is that we focus on a Use-Cases draft and define within that some motivating use-cases that we agree are good first targets. Those can drive which subset of functionality we focus on. More use-cases are, of course, quite welcome. Posting them to the mailing list is a good first start. Russ White is starting the general use-cases draft based on the three use-cases that he sent to the list. Alia On Wed, Aug 15, 2012 at 9:43 AM, Olen Stokes wrote: > Are there applications vendors out there that already have specific requi= rements for what this " subset of the data-models for sub-interfaces" shou= ld be? > > Olen > > -----Original Message----- > From: irs-discuss-bounces@ietf.org [mailto:irs-discuss-bounces@ietf.org] = On Behalf Of Alia Atlas > Sent: Wednesday, August 15, 2012 9:08 AM > To: Shah, Himanshu > Cc: Gert Grammel; irs-discuss@ietf.org; Lenny Giuliano; Thomas Nadeau; Al= ia Atlas; Scott Whyte > Subject: Re: [irs-discuss] IRS comments > > Hi Himanshu, > > Welcome. I agree that IRS isn't going to spring into being fully > formed - I expect that we'll focus on a subset of the data-models for sub= -interfaces along with an associated protocol (whether that is a new one or= extending an existing one). > > Alia > > On Wed, Aug 15, 2012 at 7:41 AM, Shah, Himanshu wrote: >> Newbie to this discussions list and have read only a last couple of mail= s, so pardon the repeat if somebody has already raised the following as a c= oncern. >> >> I realize we are early in IRS architecture definition but one thing to k= eep in mind is the user experience. >> We need to make sure that exposed interface to >> RIB/LFIB/FIB/IGPs/BGP/LSDBs etc etc provide a consistent predictive act= ion/response/events even when different implementations has varying capabil= ities. >> >> At the moment it seems like a wild wild west. >> Perhaps IRS can be defined in phases starting with a simpler, limited ve= rsion.. >> >> Thanks, >> himanshu >> >> >> -----Original Message----- >> From: irs-discuss-bounces@ietf.org >> [mailto:irs-discuss-bounces@ietf.org] On Behalf Of Alia Atlas >> Sent: Monday, August 13, 2012 8:41 AM >> To: Scott Whyte >> Cc: Thomas Nadeau; Gert Grammel; Alia Atlas; Lenny Giuliano; >> irs-discuss@ietf.org >> Subject: Re: [irs-discuss] IRS comments >> >> ...snip... >> >> On Fri, Aug 10, 2012 at 9:03 PM, Scott Whyte wrote: >>> On Fri, Aug 10, 2012 at 5:16 PM, Alia Atlas wrote: >> >>>> I do think it is important to have the RIB as an arbitration mechanism >>>> on the device. Russ's suggestion that for the RIB sub-interface, the >>>> IRS agent might communicate logically to an IRS routing process >>>> gives good semantics and interactions. Obviously, implementations >>>> may differ. >>> >>> As long as the arbitration mechanism is reconfigurable by the >>> operator to whatever precedence they want, I agree. Its not clear to >>> me if various RIB implementations treat all proffered routes the >>> same, nor if they store the same meta-data with all protocol sources. >>> So there needs to be some way for the operator to leverage exposed >>> protocol-specific optimizations, without conflict from the other >>> routing processes, if they so desire. OTOH if it can all be done via >>> static routes, it seems much simpler. :) >> >> Clearly the IRS sub-interface for the RIB needs to introduce/define the = different precedences; my assumption is that it would be per route with a w= ell-defined small set of meta-data. This is part of where having good use-= cases will help us understand what behavior is necessary. The static rout= es do seem like a simpler case to start with. >> >> Alia >> _______________________________________________ >> 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 Return-Path: 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 70D2421F8879 for ; Wed, 15 Aug 2012 06:43:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nlsUq1+tKf-a for ; Wed, 15 Aug 2012 06:43:29 -0700 (PDT) Received: from ussc-casht-p1.extremenetworks.com (ussc-casht-p2.extremenetworks.com [207.179.9.62]) by ietfa.amsl.com (Postfix) with ESMTP id DA8E321F8839 for ; Wed, 15 Aug 2012 06:43:29 -0700 (PDT) Received: from USEXCHANGE.corp.extremenetworks.com ([10.0.4.74]) by ussc-casht-p2.corp.extremenetworks.com ([10.255.181.88]) with mapi; Wed, 15 Aug 2012 06:43:29 -0700 From: Olen Stokes To: Alia Atlas , "Shah, Himanshu" Date: Wed, 15 Aug 2012 06:43:27 -0700 Thread-Topic: [irs-discuss] IRS comments Thread-Index: Ac165vtcYYt4PdYBQh2nm9DShDU0rQABDvZg Message-ID: References: <812700A304640D4292205D5E83FC59E1061C211D@p-embx01-eq.jnpr.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Gert Grammel , "irs-discuss@ietf.org" , Lenny Giuliano , Thomas Nadeau , Alia Atlas , Scott Whyte 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Aug 2012 13:43:30 -0000 Are there applications vendors out there that already have specific require= ments for what this " subset of the data-models for sub-interfaces" should= be? =20 Olen -----Original Message----- From: irs-discuss-bounces@ietf.org [mailto:irs-discuss-bounces@ietf.org] On= Behalf Of Alia Atlas Sent: Wednesday, August 15, 2012 9:08 AM To: Shah, Himanshu Cc: Gert Grammel; irs-discuss@ietf.org; Lenny Giuliano; Thomas Nadeau; Alia= Atlas; Scott Whyte Subject: Re: [irs-discuss] IRS comments Hi Himanshu, Welcome. I agree that IRS isn't going to spring into being fully formed - I expect that we'll focus on a subset of the data-models for sub-i= nterfaces along with an associated protocol (whether that is a new one or e= xtending an existing one). Alia On Wed, Aug 15, 2012 at 7:41 AM, Shah, Himanshu wrote: > Newbie to this discussions list and have read only a last couple of mails= , so pardon the repeat if somebody has already raised the following as a co= ncern. > > I realize we are early in IRS architecture definition but one thing to ke= ep in mind is the user experience. > We need to make sure that exposed interface to=20 > RIB/LFIB/FIB/IGPs/BGP/LSDBs etc etc provide a consistent predictive acti= on/response/events even when different implementations has varying capabili= ties. > > At the moment it seems like a wild wild west. > Perhaps IRS can be defined in phases starting with a simpler, limited ver= sion.. > > Thanks, > himanshu > > > -----Original Message----- > From: irs-discuss-bounces@ietf.org=20 > [mailto:irs-discuss-bounces@ietf.org] On Behalf Of Alia Atlas > Sent: Monday, August 13, 2012 8:41 AM > To: Scott Whyte > Cc: Thomas Nadeau; Gert Grammel; Alia Atlas; Lenny Giuliano;=20 > irs-discuss@ietf.org > Subject: Re: [irs-discuss] IRS comments > > ...snip... > > On Fri, Aug 10, 2012 at 9:03 PM, Scott Whyte wrote: >> On Fri, Aug 10, 2012 at 5:16 PM, Alia Atlas wrote: > >>> I do think it is important to have the RIB as an arbitration mechanism >>> on the device. Russ's suggestion that for the RIB sub-interface, the >>> IRS agent might communicate logically to an IRS routing process=20 >>> gives good semantics and interactions. Obviously, implementations=20 >>> may differ. >> >> As long as the arbitration mechanism is reconfigurable by the=20 >> operator to whatever precedence they want, I agree. Its not clear to=20 >> me if various RIB implementations treat all proffered routes the=20 >> same, nor if they store the same meta-data with all protocol sources. =20 >> So there needs to be some way for the operator to leverage exposed=20 >> protocol-specific optimizations, without conflict from the other=20 >> routing processes, if they so desire. OTOH if it can all be done via=20 >> static routes, it seems much simpler. :) > > Clearly the IRS sub-interface for the RIB needs to introduce/define the d= ifferent precedences; my assumption is that it would be per route with a we= ll-defined small set of meta-data. This is part of where having good use-c= ases will help us understand what behavior is necessary. The static route= s do seem like a simpler case to start with. > > Alia > _______________________________________________ > 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 Return-Path: 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 8A6C921F8823 for ; Wed, 15 Aug 2012 06:07:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.553 X-Spam-Level: X-Spam-Status: No, score=-3.553 tagged_above=-999 required=5 tests=[AWL=0.046, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YuwsJUyWRvr7 for ; Wed, 15 Aug 2012 06:07:41 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 6688B21F8829 for ; Wed, 15 Aug 2012 06:07:40 -0700 (PDT) Received: by yhq56 with SMTP id 56so1877745yhq.31 for ; Wed, 15 Aug 2012 06:07:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=BJCBIcoIVpRvznIacj1MhEOjhcxvzK5nyPFGiz/YeZ8=; b=nXwj9+UOWJrcxxfiFGu8TMPlMo2c9N7ldO6WzITUC4hauURCcod+0v6FxuczF5MgQ5 1oPoEKYnFG6R8aMqpHBgcB0RbOys0X43Zr9nySj7/2/lhLqduN5ydkbqQBY3XxnS3xdL pufyhLNDM/SBs25FobR6OsuQAVyE4C6UrW1s3o0rnAzE93AApQdvBikOSYFsgEvkJIQB WbKpq2xbiKHADtJsy5oCNRvaqzMo1O0k8LTNGcqAEJNaaJ8rXDnDdggpkJvncJyw1oB2 fZfgXdffE2+79m6H2UBUQI7xCv8L/qEzdC9Ie7iPH388csK0W4LhEbhkv55nTm5olNal mVDA== MIME-Version: 1.0 Received: by 10.50.213.106 with SMTP id nr10mr18065022igc.58.1345036059656; Wed, 15 Aug 2012 06:07:39 -0700 (PDT) Received: by 10.50.91.135 with HTTP; Wed, 15 Aug 2012 06:07:39 -0700 (PDT) In-Reply-To: References: <812700A304640D4292205D5E83FC59E1061C211D@p-embx01-eq.jnpr.net> Date: Wed, 15 Aug 2012 09:07:39 -0400 Message-ID: From: Alia Atlas To: "Shah, Himanshu" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Gert Grammel , "irs-discuss@ietf.org" , Lenny Giuliano , Thomas Nadeau , Alia Atlas , Scott Whyte 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Aug 2012 13:07:41 -0000 Hi Himanshu, Welcome. I agree that IRS isn't going to spring into being fully formed - I expect that we'll focus on a subset of the data-models for sub-interfaces along with an associated protocol (whether that is a new one or extending an existing one). Alia On Wed, Aug 15, 2012 at 7:41 AM, Shah, Himanshu wrote: > Newbie to this discussions list and have read only a last couple of mails= , so pardon the repeat if somebody has already raised the following as a co= ncern. > > I realize we are early in IRS architecture definition but one thing to ke= ep in mind is the user experience. > We need to make sure that exposed interface to RIB/LFIB/FIB/IGPs/BGP/LSDB= s etc etc provide a > consistent predictive action/response/events even when different implemen= tations has varying capabilities. > > At the moment it seems like a wild wild west. > Perhaps IRS can be defined in phases starting with a simpler, limited ver= sion.. > > Thanks, > himanshu > > > -----Original Message----- > From: irs-discuss-bounces@ietf.org [mailto:irs-discuss-bounces@ietf.org] = On Behalf Of Alia Atlas > Sent: Monday, August 13, 2012 8:41 AM > To: Scott Whyte > Cc: Thomas Nadeau; Gert Grammel; Alia Atlas; Lenny Giuliano; irs-discuss@= ietf.org > Subject: Re: [irs-discuss] IRS comments > > ...snip... > > On Fri, Aug 10, 2012 at 9:03 PM, Scott Whyte wrote: >> On Fri, Aug 10, 2012 at 5:16 PM, Alia Atlas wrote: > >>> I do think it is important to have the RIB as an arbitration mechanism >>> on the device. Russ's suggestion that for the RIB sub-interface, the >>> IRS agent might communicate logically to an IRS routing process gives >>> good semantics and interactions. Obviously, implementations may >>> differ. >> >> As long as the arbitration mechanism is reconfigurable by the operator >> to whatever precedence they want, I agree. Its not clear to me if >> various RIB implementations treat all proffered routes the same, nor >> if they store the same meta-data with all protocol sources. So there >> needs to be some way for the operator to leverage exposed >> protocol-specific optimizations, without conflict from the other >> routing processes, if they so desire. OTOH if it can all be done via >> static routes, it seems much simpler. :) > > Clearly the IRS sub-interface for the RIB needs to introduce/define the d= ifferent precedences; my assumption is that it would be per route with a we= ll-defined small set of meta-data. This is part of where having good use-c= ases will help us understand what behavior is necessary. The static route= s do seem like a simpler case to start with. > > Alia > _______________________________________________ > irs-discuss mailing list > irs-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/irs-discuss Return-Path: 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 C7E9321F86A4 for ; Wed, 15 Aug 2012 04:41:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.861 X-Spam-Level: X-Spam-Status: No, score=-2.861 tagged_above=-999 required=5 tests=[AWL=0.404, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XO0LDbizoUg5 for ; Wed, 15 Aug 2012 04:41:32 -0700 (PDT) Received: from mx0a-00103a01.pphosted.com (mx0a-00103a01.pphosted.com [67.231.144.234]) by ietfa.amsl.com (Postfix) with ESMTP id 3A80D21F85C3 for ; Wed, 15 Aug 2012 04:41:28 -0700 (PDT) Received: from pps.filterd (m0000419 [127.0.0.1]) by mx0a-00103a01.pphosted.com (8.14.4/8.14.4) with SMTP id q7FBeGtv028525; Wed, 15 Aug 2012 07:41:26 -0400 Received: from mdwexght02.ciena.com (LIN1-118-36-29.ciena.com [63.118.36.29]) by mx0a-00103a01.pphosted.com with ESMTP id 16ra8e0442-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 15 Aug 2012 07:41:26 -0400 Received: from MDWEXCHCGSIHT01.ciena.com (10.4.140.106) by MDWEXGHT02.ciena.com (10.4.140.213) with Microsoft SMTP Server (TLS) id 8.3.192.1; Wed, 15 Aug 2012 07:41:27 -0400 Received: from MDWEXGMB02.ciena.com ([::1]) by MDWEXCHCGSIHT01.ciena.com ([::1]) with mapi; Wed, 15 Aug 2012 07:41:27 -0400 From: "Shah, Himanshu" To: Alia Atlas , Scott Whyte Date: Wed, 15 Aug 2012 07:41:26 -0400 Thread-Topic: [irs-discuss] IRS comments Thread-Index: Ac15UPmWZFj3YBmsT9Smjrge48ksHAATypTA Message-ID: References: <812700A304640D4292205D5E83FC59E1061C211D@p-embx01-eq.jnpr.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-tm-as-product-ver: SMEX-10.0.0.1412-7.000.1014-19114.004 x-tm-as-result: No--47.155700-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.7.7855, 1.0.260, 0.0.0000 definitions=2012-08-15_01:2012-08-15, 2012-08-15, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=1 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=6.0.2-1203120001 definitions=main-1208150077 Cc: Thomas Nadeau , Gert Grammel , Alia Atlas , Lenny Giuliano , "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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Aug 2012 11:41:32 -0000 Newbie to this discussions list and have read only a last couple of mails, = so pardon the repeat if somebody has already raised the following as a conc= ern. I realize we are early in IRS architecture definition but one thing to keep= in mind is the user experience. We need to make sure that exposed interface to RIB/LFIB/FIB/IGPs/BGP/LSDBs = etc etc provide a=20 consistent predictive action/response/events even when different implementa= tions has varying capabilities. At the moment it seems like a wild wild west.=20 Perhaps IRS can be defined in phases starting with a simpler, limited versi= on.. Thanks, himanshu -----Original Message----- From: irs-discuss-bounces@ietf.org [mailto:irs-discuss-bounces@ietf.org] On= Behalf Of Alia Atlas Sent: Monday, August 13, 2012 8:41 AM To: Scott Whyte Cc: Thomas Nadeau; Gert Grammel; Alia Atlas; Lenny Giuliano; irs-discuss@ie= tf.org Subject: Re: [irs-discuss] IRS comments ...snip... On Fri, Aug 10, 2012 at 9:03 PM, Scott Whyte wrote: > On Fri, Aug 10, 2012 at 5:16 PM, Alia Atlas wrote: >> I do think it is important to have the RIB as an arbitration mechanism >> on the device. Russ's suggestion that for the RIB sub-interface, the >> IRS agent might communicate logically to an IRS routing process gives=20 >> good semantics and interactions. Obviously, implementations may=20 >> differ. > > As long as the arbitration mechanism is reconfigurable by the operator=20 > to whatever precedence they want, I agree. Its not clear to me if=20 > various RIB implementations treat all proffered routes the same, nor=20 > if they store the same meta-data with all protocol sources. So there=20 > needs to be some way for the operator to leverage exposed=20 > protocol-specific optimizations, without conflict from the other=20 > routing processes, if they so desire. OTOH if it can all be done via=20 > static routes, it seems much simpler. :) Clearly the IRS sub-interface for the RIB needs to introduce/define the dif= ferent precedences; my assumption is that it would be per route with a well= -defined small set of meta-data. This is part of where having good use-cas= es will help us understand what behavior is necessary. The static routes = do seem like a simpler case to start with. Alia _______________________________________________ irs-discuss mailing list irs-discuss@ietf.org https://www.ietf.org/mailman/listinfo/irs-discuss Return-Path: 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 6E99C21F8705 for ; Mon, 13 Aug 2012 05:41:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.562 X-Spam-Level: X-Spam-Status: No, score=-3.562 tagged_above=-999 required=5 tests=[AWL=0.037, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 59hv6E4dbJ1k for ; Mon, 13 Aug 2012 05:41:29 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8994021F8702 for ; Mon, 13 Aug 2012 05:41:29 -0700 (PDT) Received: by yenm5 with SMTP id m5so3411432yen.31 for ; Mon, 13 Aug 2012 05:41:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=o3rBvhJ2pCEHGz5bpAgsn9PUnKC6FYv3WkzJs0sk4j8=; b=dG9PTmgo8Su0BvzoGVNLf9Okn38LScDE9ILnQooLxJS048BlAT5Yx/9Wa+aosrQHT2 SkbRNdJ6NKyhd2RFkaSaEJLiChXAdtIj+pCoT8vsgVG67cCbT9dRTCzBGy/wdc8jMBH1 2FLMhQWp2UbBfIX3eCP4mppvBlIFTBGXBpXwLrbD+3KMMdJQmv6+HtduYAgAp/M6geqs hz1a1b/egVeSxnW++REUXiHHwIcY6Kl3ecxlq+neq4WJPGUCZxdMQQfMlsyzH+RqwoMt 5/r/6OD5a1/ItyxJNs6e56IOJH6RipmsZQebedY/CR2Ny0yjJWOE+ky1+ix3DmmaY8Jv jH/g== MIME-Version: 1.0 Received: by 10.50.183.200 with SMTP id eo8mr5253072igc.63.1344861688822; Mon, 13 Aug 2012 05:41:28 -0700 (PDT) Received: by 10.50.91.135 with HTTP; Mon, 13 Aug 2012 05:41:28 -0700 (PDT) In-Reply-To: References: <812700A304640D4292205D5E83FC59E1061C211D@p-embx01-eq.jnpr.net> Date: Mon, 13 Aug 2012 08:41:28 -0400 Message-ID: From: Alia Atlas To: Scott Whyte Content-Type: text/plain; charset=ISO-8859-1 Cc: Thomas Nadeau , Gert Grammel , Alia Atlas , Lenny Giuliano , 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Aug 2012 12:41:30 -0000 ...snip... On Fri, Aug 10, 2012 at 9:03 PM, Scott Whyte wrote: > On Fri, Aug 10, 2012 at 5:16 PM, Alia Atlas wrote: >> I do think it is important to have the RIB as an arbitration mechanism >> on the device. Russ's suggestion that for the RIB sub-interface, the >> IRS agent might communicate logically to an IRS routing process gives >> good semantics and interactions. Obviously, implementations may >> differ. > > As long as the arbitration mechanism is reconfigurable by the operator > to whatever precedence they want, I agree. Its not clear to me if > various RIB implementations treat all proffered routes the same, nor > if they store the same meta-data with all protocol sources. So there > needs to be some way for the operator to leverage exposed > protocol-specific optimizations, without conflict from the other > routing processes, if they so desire. OTOH if it can all be done via > static routes, it seems much simpler. :) Clearly the IRS sub-interface for the RIB needs to introduce/define the different precedences; my assumption is that it would be per route with a well-defined small set of meta-data. This is part of where having good use-cases will help us understand what behavior is necessary. The static routes do seem like a simpler case to start with. Alia Return-Path: 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 4F62F11E80AE for ; Fri, 10 Aug 2012 18:03:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.977 X-Spam-Level: X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ImOdFeJ7b9vo for ; Fri, 10 Aug 2012 18:03:13 -0700 (PDT) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id B790921F84F4 for ; Fri, 10 Aug 2012 18:03:12 -0700 (PDT) Received: by lahm15 with SMTP id m15so1200674lah.31 for ; Fri, 10 Aug 2012 18:03:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-system-of-record; bh=0DzenpKwPquVAiKpxowOInGLSeAMV5K1k9g+axIq730=; b=YKdHJpEUXd/0phllEfrMUHiYXH+MKLwxS6xKds3MaUVz0HTWhoUbzcf/tm1za175yV XrjRdPM7uraNu9UfrU8xeFoO/BkqhRZsZlMyeYf29/MD+h5LWDSATtWVvdl+UeWP+Vlq cY3VBbKErLPvYBYz+tOdRKwZL0Ij+J6DPXQ+cTLNCrvZDA/HyiWf3Um8xufICk/xZylM WiVj65YvjhffvtGPChvSrWZDM8xhdtONiVxgm8GVUL7R+zAf5pisotMOKg5UcVagW0SF WI+2QEUOYfQguemWiTjLB/SLpXT2WwqtXdadEXD7nCXA94aQgtIpcKPwaem04cCNCxX0 hR9g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=0DzenpKwPquVAiKpxowOInGLSeAMV5K1k9g+axIq730=; b=J8VjLtulDBCRQlszHD5jWK/yN3gAiMgiicTMjvdQQsZw7tt0WnXpI1KAi9kBmiSDKS d5RlPo2gSy3pT4IXahtt85X+mBQP83+XEypI8BraH1DUb2sEcL1in4BYr/OH7L/RU0pv U6eY48IMpr8867IWjAidZFegWwiaElqLCUmLXc3e5JyV2I3+CXSP0zOBvDk/JKOCmSQG +ZvGEsApBiSXos+1XQiGZ9B9Ms26/8+VHPeEOFquoXgO8H4acSvhsTQLcuTPzTIWaFDI s5U/jc/sNyKujU4H0JTZI/NSO0DMQ3Z1MTcfOXnN3G4e4MNkp1wXJwNIV/BGaAfaQa+Q nnyA== Received: by 10.152.108.42 with SMTP id hh10mr4740207lab.9.1344646991682; Fri, 10 Aug 2012 18:03:11 -0700 (PDT) MIME-Version: 1.0 Received: by 10.152.108.42 with SMTP id hh10mr4740186lab.9.1344646991511; Fri, 10 Aug 2012 18:03:11 -0700 (PDT) Received: by 10.112.38.38 with HTTP; Fri, 10 Aug 2012 18:03:11 -0700 (PDT) In-Reply-To: References: <812700A304640D4292205D5E83FC59E1061C211D@p-embx01-eq.jnpr.net> Date: Fri, 10 Aug 2012 18:03:11 -0700 Message-ID: From: Scott Whyte To: Alia Atlas Content-Type: text/plain; charset=UTF-8 X-System-Of-Record: true X-Gm-Message-State: ALoCoQkWabjmPWhks7RP7h9Ks0A7Ao+g67FjDO0YcX+8Y+X4OZE9GfvW0DdyrBodTXhDMS4FeS484v9ftSFHPREDILY7+ZacfVaYDdZ+H9n39eE9OLUd2+JJN3P8XphVTWvlZCShOevfWjQdzqo4Nnc+9Qj20YXMxUq+57+XracmTYbhq1zqAqKYyTHjA290hhprBQcwUeLp Cc: Thomas Nadeau , Gert Grammel , Alia Atlas , Lenny Giuliano , 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Aug 2012 01:03:14 -0000 On Fri, Aug 10, 2012 at 5:16 PM, Alia Atlas wrote: > Scott, > > In your example, the control plane would mostly move off the device; > it still exists. Dave Meyer asked if IRS would work to communicate > with routing if it were off the device. I'd be curious to hear > people's thoughts on that. My initial take is that IRS's > sub-interfaces should be useful regardless - but we need a good use > case describing that and it would, of course, depend on the > architectural model that moved the routing off the device. Noel's comment earlier got me thinking it sure would be nice to rip out all the routing baggage from ISIS, and just use the flooding mechanism to discover topology. And as discussed earlier in other threads, topology discovery does need to be run on the devices clearly, so I think we are in agreement here. > > I do think it is important to have the RIB as an arbitration mechanism > on the device. Russ's suggestion that for the RIB sub-interface, the > IRS agent might communicate logically to an IRS routing process gives > good semantics and interactions. Obviously, implementations may > differ. As long as the arbitration mechanism is reconfigurable by the operator to whatever precedence they want, I agree. Its not clear to me if various RIB implementations treat all proffered routes the same, nor if they store the same meta-data with all protocol sources. So there needs to be some way for the operator to leverage exposed protocol-specific optimizations, without conflict from the other routing processes, if they so desire. OTOH if it can all be done via static routes, it seems much simpler. :) -Scott > > Do you have a particular architectural model that you're thinking of > for having the control plane off the device? It's something I've > talked with various folks about - but have yet to see anything > convincing written down that addresses most of the issues - from link > verification and MTU to OAM and resiliency and interactions between > off-device control-plane controllers/orchestrators. > > > Alia > > On Fri, Aug 10, 2012 at 7:22 PM, Scott Whyte wrote: >> On Mon, Jul 30, 2012 at 6:40 PM, Gert Grammel wrote: >>> Tom, >>> >>> It is confusing to understand whether IRS belongs to a new network management plane or if it's more of a control plane extension. The draft wisely avoids this classification. >>> To me IRS appears to be a completely different beast which should best be characterized as 'Network Programming Plane' NPP. >>> It neither aims to do full provisioning (as a management plane would do) nor aims to replace routing (as a control plane would do). >> >> Alia's presentation has a diagram with a direct link between the IRS >> Agent and the RIB Manager; thus it does seem to replace routing. >> >>> Hence we better name the baby NPP -- thereby avoiding any linkage to taxation. >> >> If none of my switching nodes speak any kind of legacy control plane >> protocol, yet IRS remains stuffing 500,000 static routes into each >> (thus programming the network), NPP only makes sense to me if it >> subsumes the legacy control plane, not co-exists with it as I >> understand your taxonomy. >> >> -Scott >> >>> >>> >>> Gert >>> >>> >>> >>> >>> ----- Original Message ----- >>> From: irs-discuss-bounces@ietf.org >>> To: Lenny Giuliano; Alia Atlas >>> Cc: irs-discuss@ietf.org >>> Sent: Tue Jul 31 01:50:40 2012 >>> Subject: Re: [irs-discuss] IRS comments >>> >>> >>> [Re-adding IRS] >>> >>> Thank you for reviewing and the comments. We will incorporate the edits >>> in the next rev. >>> >>> --Tom >>> >>> >>> On 7/30/12 5:04 PM, "Lenny Giuliano" wrote: >>> >>>> >>>>Minor points: >>>> >>>>-section 4, para 2, 3rd sentence, "Howeve,r" >>>> >>>>-4.1.3 "There is no bidirectional programmatic interface to add, modify, >>>> remove or read state from the multicast RIB." >>>> -How is this unique to mcast? Couldn't you say the same thing >>>> about unicast? >>>> >>>>-4.1.3 "The multicast state added need not match to well-known protocol >>>> installed state. For instance, traffic received on an specified set, >>>> or all, interfaces that is destined to a particular prefix from all >>>> sources or a particular prefix could be subject to the specified >>>> replication." >>>> -Not clear to me at all what this para is saying. >>>> >>>>-"IRS"- you may want to select a different acronym that isn't related to >>>>something as unpopular as taxation (something we learned with AMT). >>>>Maybe >>>>RSI instead... >>>> >>>>Overall, I found the doc to be clearly written and straightforward. >>>>Sounds like Openflow for routers. Not sure if it's intentional that you >>>>didn't mention Openflow, but it did seem like an elephant in the room as >>>>I >>>>was reading thru. Also, I did wonder what was new and novel here, as >>>>this >>>>sounded like our SDK which has been around for years. >>>> >>>> >>>>-Lenny >>> >>> _______________________________________________ >>> 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 >> >> >> >> -- >> panem et circenses - a winning strategy for over 2000 years! >> _______________________________________________ >> irs-discuss mailing list >> irs-discuss@ietf.org >> https://www.ietf.org/mailman/listinfo/irs-discuss -- panem et circenses - a winning strategy for over 2000 years! Return-Path: 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 7407B21F8497 for ; Fri, 10 Aug 2012 17:16:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.56 X-Spam-Level: X-Spam-Status: No, score=-3.56 tagged_above=-999 required=5 tests=[AWL=0.039, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DHMfJK1rkhgY for ; Fri, 10 Aug 2012 17:16:47 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id A2B5021F8496 for ; Fri, 10 Aug 2012 17:16:47 -0700 (PDT) Received: by obbwc20 with SMTP id wc20so3419322obb.31 for ; Fri, 10 Aug 2012 17:16:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=5atY3wOxRR3P1fluIXKjA5FHTzKhVGlKkaACldyIMnE=; b=LytlLg0Z/nHDEabo1yv2JKgBhkEqK9MXepsVR3FIJpNWmpbttCuOWdrjK4aUyKPS9G GMyXq7Pb5kMW4yFwjiGTeuBkNyOgK1tJyosNWT0QnHumYycR+IR6w42FoiiVHcmHRDG9 BGM8tQuB26gmJzK5KK0JlsAR6W3GcnnBa7zr+bUA9wtYGw3n1s0+ofC/e5bJVY/Zuv08 +yWYSyB5SK1TkMbRFQpgMO1eFvCS5j+YbaBGyJHBbDYG981wFd07CpMm8d8RjwvYWW8/ V3ccRitAYgbhxpVd7eRiyp1QM2PhtwXp+z2En6S0AdVLGpRCmWDN8tvm4lGo9yDjy6X7 S20g== MIME-Version: 1.0 Received: by 10.50.213.106 with SMTP id nr10mr916362igc.58.1344644206845; Fri, 10 Aug 2012 17:16:46 -0700 (PDT) Received: by 10.50.91.135 with HTTP; Fri, 10 Aug 2012 17:16:46 -0700 (PDT) In-Reply-To: References: <812700A304640D4292205D5E83FC59E1061C211D@p-embx01-eq.jnpr.net> Date: Fri, 10 Aug 2012 20:16:46 -0400 Message-ID: From: Alia Atlas To: Scott Whyte Content-Type: text/plain; charset=ISO-8859-1 Cc: Thomas Nadeau , Gert Grammel , Alia Atlas , Lenny Giuliano , 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Aug 2012 00:16:48 -0000 Scott, In your example, the control plane would mostly move off the device; it still exists. Dave Meyer asked if IRS would work to communicate with routing if it were off the device. I'd be curious to hear people's thoughts on that. My initial take is that IRS's sub-interfaces should be useful regardless - but we need a good use case describing that and it would, of course, depend on the architectural model that moved the routing off the device. I do think it is important to have the RIB as an arbitration mechanism on the device. Russ's suggestion that for the RIB sub-interface, the IRS agent might communicate logically to an IRS routing process gives good semantics and interactions. Obviously, implementations may differ. Do you have a particular architectural model that you're thinking of for having the control plane off the device? It's something I've talked with various folks about - but have yet to see anything convincing written down that addresses most of the issues - from link verification and MTU to OAM and resiliency and interactions between off-device control-plane controllers/orchestrators. Alia On Fri, Aug 10, 2012 at 7:22 PM, Scott Whyte wrote: > On Mon, Jul 30, 2012 at 6:40 PM, Gert Grammel wrote: >> Tom, >> >> It is confusing to understand whether IRS belongs to a new network management plane or if it's more of a control plane extension. The draft wisely avoids this classification. >> To me IRS appears to be a completely different beast which should best be characterized as 'Network Programming Plane' NPP. >> It neither aims to do full provisioning (as a management plane would do) nor aims to replace routing (as a control plane would do). > > Alia's presentation has a diagram with a direct link between the IRS > Agent and the RIB Manager; thus it does seem to replace routing. > >> Hence we better name the baby NPP -- thereby avoiding any linkage to taxation. > > If none of my switching nodes speak any kind of legacy control plane > protocol, yet IRS remains stuffing 500,000 static routes into each > (thus programming the network), NPP only makes sense to me if it > subsumes the legacy control plane, not co-exists with it as I > understand your taxonomy. > > -Scott > >> >> >> Gert >> >> >> >> >> ----- Original Message ----- >> From: irs-discuss-bounces@ietf.org >> To: Lenny Giuliano; Alia Atlas >> Cc: irs-discuss@ietf.org >> Sent: Tue Jul 31 01:50:40 2012 >> Subject: Re: [irs-discuss] IRS comments >> >> >> [Re-adding IRS] >> >> Thank you for reviewing and the comments. We will incorporate the edits >> in the next rev. >> >> --Tom >> >> >> On 7/30/12 5:04 PM, "Lenny Giuliano" wrote: >> >>> >>>Minor points: >>> >>>-section 4, para 2, 3rd sentence, "Howeve,r" >>> >>>-4.1.3 "There is no bidirectional programmatic interface to add, modify, >>> remove or read state from the multicast RIB." >>> -How is this unique to mcast? Couldn't you say the same thing >>> about unicast? >>> >>>-4.1.3 "The multicast state added need not match to well-known protocol >>> installed state. For instance, traffic received on an specified set, >>> or all, interfaces that is destined to a particular prefix from all >>> sources or a particular prefix could be subject to the specified >>> replication." >>> -Not clear to me at all what this para is saying. >>> >>>-"IRS"- you may want to select a different acronym that isn't related to >>>something as unpopular as taxation (something we learned with AMT). >>>Maybe >>>RSI instead... >>> >>>Overall, I found the doc to be clearly written and straightforward. >>>Sounds like Openflow for routers. Not sure if it's intentional that you >>>didn't mention Openflow, but it did seem like an elephant in the room as >>>I >>>was reading thru. Also, I did wonder what was new and novel here, as >>>this >>>sounded like our SDK which has been around for years. >>> >>> >>>-Lenny >> >> _______________________________________________ >> 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 > > > > -- > panem et circenses - a winning strategy for over 2000 years! > _______________________________________________ > irs-discuss mailing list > irs-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/irs-discuss Return-Path: 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 E58F511E80E1 for ; Fri, 10 Aug 2012 16:22:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.977 X-Spam-Level: X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ftQGRN0nvYvA for ; Fri, 10 Aug 2012 16:22:55 -0700 (PDT) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id BDAC311E80AD for ; Fri, 10 Aug 2012 16:22:54 -0700 (PDT) Received: by lahm15 with SMTP id m15so1177128lah.31 for ; Fri, 10 Aug 2012 16:22:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-system-of-record; bh=b6om/d1KYm/TvJE4CEYapmLWb+xM1wtBoZ0pROhRh+8=; b=AsRjyTGw1Mqx1mk+J/hOdYa3SHDptw0CSLJndW99JDlV8zmNuNJfPGYSITYIXBYOaP hDXPdYJsUZMk3u9BLtIrchQnO3QGusbhXCWt8KTlncSYsqhk+M1VaSdDRudHtCHf/jcI zHpb6nBHZ7B7vPubsB34dqgXVAsv+WH+D4vzXi/QDzxcZOFIsd6OmCOhpLaSX0L8kwpT q7XEqkN870c0E/ls+4irAF0gmHuQtNCuP3XljU801GdI9EvSYdcQjShQbM3mfPIjioZ5 3wnYBXTI9zAd+0DxoYoUjLB07ClKmfPqdERibg3ATzBypMowtzj7okfA4iQZT+u0ykNa tClw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=b6om/d1KYm/TvJE4CEYapmLWb+xM1wtBoZ0pROhRh+8=; b=FbSSg+Qxze2Ox4UyhzCxpqk6aSkZHJqdX4r2Z5dSQD+dykE3+zN1ye2dLSlPI8Ctu+ 4PHK1KqGvahD5m+sUV17M8il2CyahSIKgZcbJfBr4QLPM6GL9hdyAjq9RYSv/OXSGBVA u0dwgOzMobeBk7dZj9TD/FWhwPjunmETRYQSxHIcdZX4C2JBMfeur93yf2zDRG5LuuKj VC0BTfhHmaTJ0FA/hk2h80oix6sRCk7DAICCCbjBRqKoVbWi7pDd3xo0vhaBCwykLscC VlkeIDmHotZcHngBuJwV3DYif3zfb2wvxLFKqRfYrB/x0zDaEv0RcP33E4jQnneaIa8K PM7g== Received: by 10.112.43.98 with SMTP id v2mr3079523lbl.1.1344640973657; Fri, 10 Aug 2012 16:22:53 -0700 (PDT) MIME-Version: 1.0 Received: by 10.112.43.98 with SMTP id v2mr3079513lbl.1.1344640973494; Fri, 10 Aug 2012 16:22:53 -0700 (PDT) Received: by 10.112.38.38 with HTTP; Fri, 10 Aug 2012 16:22:53 -0700 (PDT) In-Reply-To: <812700A304640D4292205D5E83FC59E1061C211D@p-embx01-eq.jnpr.net> References: <812700A304640D4292205D5E83FC59E1061C211D@p-embx01-eq.jnpr.net> Date: Fri, 10 Aug 2012 16:22:53 -0700 Message-ID: From: Scott Whyte To: Gert Grammel Content-Type: text/plain; charset=UTF-8 X-System-Of-Record: true X-Gm-Message-State: ALoCoQl2GhBjNaux3V7616goJzdK6jF6t9Cgt7jFc2SsqZZzlrryRydNp74gQx9izv7XT7G42566qKWg6IwPbPvAiWils9Rhcw80Xh3yPl3u7fuAhtyncpKyeCNG2dzikae1/TD7TsOvk2gO+6QhuJ3+YASs6f9K9kR722JD/jJFQH+djOY4TcmNwxLZaPQeK6+xDcy88ec3 Cc: Thomas Nadeau , Alia Atlas , Lenny Giuliano , 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Aug 2012 23:22:56 -0000 On Mon, Jul 30, 2012 at 6:40 PM, Gert Grammel wrote: > Tom, > > It is confusing to understand whether IRS belongs to a new network management plane or if it's more of a control plane extension. The draft wisely avoids this classification. > To me IRS appears to be a completely different beast which should best be characterized as 'Network Programming Plane' NPP. > It neither aims to do full provisioning (as a management plane would do) nor aims to replace routing (as a control plane would do). Alia's presentation has a diagram with a direct link between the IRS Agent and the RIB Manager; thus it does seem to replace routing. > Hence we better name the baby NPP -- thereby avoiding any linkage to taxation. If none of my switching nodes speak any kind of legacy control plane protocol, yet IRS remains stuffing 500,000 static routes into each (thus programming the network), NPP only makes sense to me if it subsumes the legacy control plane, not co-exists with it as I understand your taxonomy. -Scott > > > Gert > > > > > ----- Original Message ----- > From: irs-discuss-bounces@ietf.org > To: Lenny Giuliano; Alia Atlas > Cc: irs-discuss@ietf.org > Sent: Tue Jul 31 01:50:40 2012 > Subject: Re: [irs-discuss] IRS comments > > > [Re-adding IRS] > > Thank you for reviewing and the comments. We will incorporate the edits > in the next rev. > > --Tom > > > On 7/30/12 5:04 PM, "Lenny Giuliano" wrote: > >> >>Minor points: >> >>-section 4, para 2, 3rd sentence, "Howeve,r" >> >>-4.1.3 "There is no bidirectional programmatic interface to add, modify, >> remove or read state from the multicast RIB." >> -How is this unique to mcast? Couldn't you say the same thing >> about unicast? >> >>-4.1.3 "The multicast state added need not match to well-known protocol >> installed state. For instance, traffic received on an specified set, >> or all, interfaces that is destined to a particular prefix from all >> sources or a particular prefix could be subject to the specified >> replication." >> -Not clear to me at all what this para is saying. >> >>-"IRS"- you may want to select a different acronym that isn't related to >>something as unpopular as taxation (something we learned with AMT). >>Maybe >>RSI instead... >> >>Overall, I found the doc to be clearly written and straightforward. >>Sounds like Openflow for routers. Not sure if it's intentional that you >>didn't mention Openflow, but it did seem like an elephant in the room as >>I >>was reading thru. Also, I did wonder what was new and novel here, as >>this >>sounded like our SDK which has been around for years. >> >> >>-Lenny > > _______________________________________________ > 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 -- panem et circenses - a winning strategy for over 2000 years! Return-Path: 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 6A7A711E8087 for ; Fri, 10 Aug 2012 15:51:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.977 X-Spam-Level: X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IkvpWrD6yEnf for ; Fri, 10 Aug 2012 15:51:53 -0700 (PDT) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 94A9221F8598 for ; Fri, 10 Aug 2012 15:51:52 -0700 (PDT) Received: by lahm15 with SMTP id m15so1168893lah.31 for ; Fri, 10 Aug 2012 15:51:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-system-of-record; bh=/bGyPiViA/nHIcUheKILdjrCE9PerjdQGpIp0YpD7Dg=; b=FHFZYDSDGmlL/tYqIQ4cSng8Yas4tmW4ggBZZE1Q0oLGrzKJp/Ju1Sq2XOJ+12zRgB 52fe1XAgAPtVb5EntX7Upx2k6YNl5WxUTTRS8d1fHhm9EYShU/JHr2oOLR72yBPga5An GpB5S7pg+sOS22ebkAlgDNJweDRKB3RGaMNmSKJle7oJcY8iQO5KFip7QgAjbkp8Znuq Ro1zcLdb93iMN4ht+8MP7n6PmrPka/mHGAL0bQFaggv0hUXx7MNHEfowFZv4z6+GRL9L OqxB9uC7r1OrKLEXZBJ4cxO1YE1aFZwfvmhjEZd68qt3hhatSjv2OPr1YwmnejNxgFG3 B8MA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=/bGyPiViA/nHIcUheKILdjrCE9PerjdQGpIp0YpD7Dg=; b=koO4SKNx+2lA2T3AIYWJ2tkxMvAl2+/CoruDQ6vhUPXPhkUcuUUla25JGcucDperVI bUMVZAfQbBLOovkvobE3nglSGkpJdwkXy0tiWuqBBNm1jz2i33jy0Y4IC4vZnRl9ln+i QXz7pgk9ZswGJIJS9wPvb4OKJf7ikWwbpqgYytMAHHm8pjNjDKFYQEmklwMPjZ+P34HD y34LZi2KtO39janRHlJxAjpEK0OvueOSAcNgKdWH44bJg4ifEz6cK4xcTzkNRilRPKEE x6oIJs9KYViVFi2SiOno2RcOHs0456y53r/OCN+XEvxkkv8YpuX268ZME8ojFo/GkRHJ ZE5w== Received: by 10.152.105.132 with SMTP id gm4mr4419193lab.8.1344639111459; Fri, 10 Aug 2012 15:51:51 -0700 (PDT) MIME-Version: 1.0 Received: by 10.152.105.132 with SMTP id gm4mr4419180lab.8.1344639111322; Fri, 10 Aug 2012 15:51:51 -0700 (PDT) Received: by 10.112.38.38 with HTTP; Fri, 10 Aug 2012 15:51:51 -0700 (PDT) In-Reply-To: <50223B25.9080401@raszuk.net> References: <501B150C.9080304@raszuk.net> <50223B25.9080401@raszuk.net> Date: Fri, 10 Aug 2012 15:51:51 -0700 Message-ID: From: Scott Whyte To: robert@raszuk.net Content-Type: text/plain; charset=UTF-8 X-System-Of-Record: true X-Gm-Message-State: ALoCoQnx/FoBFE/3y1ibw/lSyPMkF5DCJB4rSGu50yfWJ4qSNNdWaJTUMuDnhc8oR/3GJcfrr9zTKo3NOubKDPKZnhkzoDKUyeD1O5QjRuyksQD7H7Ijv75If51QHEDQwZh74cqG+Z5pfjL7SnwwB9OFdQYbKOlPc9nBQZxAQjIl8PRESsKfLZX1mhev6y2boH3luS+P2TLi Cc: Edward Crabbe , "irs-discuss@ietf.org" Subject: Re: [irs-discuss] An idea ... MTR + IRS X-BeenThere: irs-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Aug 2012 22:51:53 -0000 On Wed, Aug 8, 2012 at 3:10 AM, Robert Raszuk wrote: > Ed, > > >> If topo information export is in scope (which I believe it is) and >> PBR route injection with nh recursion to rib (and thus connected >> routes) is in scope (which I'm quite sure it is) then yes, this is in >> scope. > > Great ! > > >> Although I'm not sure what it has to do with OF /OF controllers? ;P > > > One could observe that entire OF can be very easily mapped to well > implemented and scaable PBR ;) I guess that depends on what you define Policy Based ROUTING to be ;) -Scott > > Best, > > R. > > > _______________________________________________ > irs-discuss mailing list > irs-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/irs-discuss -- panem et circenses - a winning strategy for over 2000 years! Return-Path: 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 12A4321F85C0 for ; Fri, 10 Aug 2012 13:57:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.56 X-Spam-Level: X-Spam-Status: No, score=-3.56 tagged_above=-999 required=5 tests=[AWL=0.039, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vSFpHtxdYydI for ; Fri, 10 Aug 2012 13:57:30 -0700 (PDT) Received: from mail-gg0-f172.google.com (mail-gg0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 1C2E921F85BB for ; Fri, 10 Aug 2012 13:57:30 -0700 (PDT) Received: by ggnh4 with SMTP id h4so2245287ggn.31 for ; Fri, 10 Aug 2012 13:57:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=mNLFvh4I65aK7BrzpBiLjqjAv8CoXFsTyoX8Wgf5gCc=; b=jRWOZvFAMr0zq4KHwO+vD/8uNfQrIFDrN1Tkb5dJPOCE6D503FJuuxIVHeYHPOWc97 1sYvaX0w00IIu6QHmekqGky9NaLKZYQlmcmc47+zoiZdBy98gIAgr1O4dQJ3bK220ynU /z2VviEgJnK15tMSqKhznMcmbLYjUG/TDRPl/PRJoeRcIijIT33w3kEf8mtU8QTdSfbV MMW7Pxpybr61hd3Wz7yJqFoD8Vi5MYZ3rSbNEYWCie3k+W8dbYJtyChccLCchM128fUX t2aubTXQKwAswu885UjDlePHyc80zBWXc5FYASg3NAW9jpZiVTIhZv4LJSUpYFLKLh0F a52g== MIME-Version: 1.0 Received: by 10.50.95.225 with SMTP id dn1mr344319igb.58.1344632249329; Fri, 10 Aug 2012 13:57:29 -0700 (PDT) Received: by 10.50.91.135 with HTTP; Fri, 10 Aug 2012 13:57:29 -0700 (PDT) In-Reply-To: <50257286.9080307@raszuk.net> References: <50170D34.503@joelhalpern.com> <1FB014C5-8B5A-4D34-82AD-D8E64A0098FF@raszuk.net> <82E1F44F-5EB2-4B06-8682-724555B51896@raszuk.net> <728F9B956B2C48439CA9294B1723B14623759D2F@dfweml509-mbs.china.huawei.com> <502563A0.4020905@raszuk.net> <728F9B956B2C48439CA9294B1723B14623759EBF@dfweml509-mbs.china.huawei.com> <50257286.9080307@raszuk.net> Date: Fri, 10 Aug 2012 16:57:29 -0400 Message-ID: From: Alia Atlas To: robert@raszuk.net Content-Type: text/plain; charset=ISO-8859-1 Cc: Susan Hares , irs-discuss@ietf.org Subject: Re: [irs-discuss] IRS Problem Statement Posted X-BeenThere: irs-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Aug 2012 20:57:31 -0000 Hi Robert, The "streaming" adjective will be gone in the next draft revision. It was replaced by describing the key attributes needed for the interface. At the IGP level, I can see applications adding in new prefixes or data to distribute. We have to see what else makes sense for that sub-interface. Alia On Fri, Aug 10, 2012 at 4:43 PM, Robert Raszuk wrote: > Hi Sue, > > >> Robert: >> >> I am now confused. Can you give me more examples about the >> streaming aspect of IRS framework, and why you questioned it. >> >> Thanks, >> Sue Hares > > > The IRS framework draft says streaming 9 times (just few quotes ...): > > This document describes a framework for a standard, programmatic > interface for full-duplex, streaming state transfer in and out of the > Internet's routing system. > > + > > The IRS > is a programmatic, streaming interface for transferring state into > and out of the Internet's routing system, > > ... > > 4.3.1. IGP Interfaces > > The lack of a streaming programmatic interface to the IGPs limits the > ability of applications to influence and modify the desired behavior > of the IGP. > > ... > > >> and why you questioned it. > > Since I am quite pessimistic about influencing and modifying behaviour of > the control plane (example above: IGP) by some external controller driven by > applications. > > IMHO IGP should provide solid domain wide IP paths between the network edges > and should not be subject to fluctuations on a per application basis. > > Best regards, > R. > > > _______________________________________________ > irs-discuss mailing list > irs-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/irs-discuss Return-Path: 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 29E4521F86C5 for ; Fri, 10 Aug 2012 13:43:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8Je6wECpdPI8 for ; Fri, 10 Aug 2012 13:43:52 -0700 (PDT) Received: from mail1310.opentransfer.com (mail1310.opentransfer.com [76.162.254.103]) by ietfa.amsl.com (Postfix) with ESMTP id 7D12A21F85F0 for ; Fri, 10 Aug 2012 13:43:52 -0700 (PDT) Received: (qmail 5393 invoked by uid 399); 10 Aug 2012 20:44:51 -0000 Received: from unknown (HELO ?192.168.1.58?) (pbs:robert@raszuk.net@83.13.163.62) by mail1310.opentransfer.com with ESMTPM; 10 Aug 2012 20:44:51 -0000 X-Originating-IP: 83.13.163.62 Message-ID: <50257286.9080307@raszuk.net> Date: Fri, 10 Aug 2012 22:43:50 +0200 From: Robert Raszuk User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: Susan Hares References: <50170D34.503@joelhalpern.com> <1FB014C5-8B5A-4D34-82AD-D8E64A0098FF@raszuk.net> <82E1F44F-5EB2-4B06-8682-724555B51896@raszuk.net> <728F9B956B2C48439CA9294B1723B14623759D2F@dfweml509-mbs.china.huawei.com> <502563A0.4020905@raszuk.net> <728F9B956B2C48439CA9294B1723B14623759EBF@dfweml509-mbs.china.huawei.com> In-Reply-To: <728F9B956B2C48439CA9294B1723B14623759EBF@dfweml509-mbs.china.huawei.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: irs-discuss@ietf.org Subject: Re: [irs-discuss] IRS Problem Statement Posted X-BeenThere: irs-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: robert@raszuk.net List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Aug 2012 20:43:53 -0000 Hi Sue, > Robert: > > I am now confused. Can you give me more examples about the > streaming aspect of IRS framework, and why you questioned it. > > Thanks, > Sue Hares The IRS framework draft says streaming 9 times (just few quotes ...): This document describes a framework for a standard, programmatic interface for full-duplex, streaming state transfer in and out of the Internet's routing system. + The IRS is a programmatic, streaming interface for transferring state into and out of the Internet's routing system, ... 4.3.1. IGP Interfaces The lack of a streaming programmatic interface to the IGPs limits the ability of applications to influence and modify the desired behavior of the IGP. ... > and why you questioned it. Since I am quite pessimistic about influencing and modifying behaviour of the control plane (example above: IGP) by some external controller driven by applications. IMHO IGP should provide solid domain wide IP paths between the network edges and should not be subject to fluctuations on a per application basis. Best regards, R. Return-Path: 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 9A8A121F86C7 for ; Fri, 10 Aug 2012 12:45:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.428 X-Spam-Level: X-Spam-Status: No, score=-5.428 tagged_above=-999 required=5 tests=[AWL=1.171, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J679-QN1exvK for ; Fri, 10 Aug 2012 12:45:24 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 65C3321F86BD for ; Fri, 10 Aug 2012 12:45:24 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml201-edg.china.huawei.com) ([172.18.9.243]) by dfwrg02-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AIS76349; Fri, 10 Aug 2012 11:45:24 -0800 (PST) Received: from DFWEML406-HUB.china.huawei.com (10.193.5.131) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 10 Aug 2012 12:42:27 -0700 Received: from dfweml509-mbs.china.huawei.com ([169.254.12.123]) by dfweml406-hub.china.huawei.com ([10.193.5.131]) with mapi id 14.01.0323.003; Fri, 10 Aug 2012 12:42:29 -0700 From: Susan Hares To: "robert@raszuk.net" Thread-Topic: [irs-discuss] IRS Problem Statement Posted Thread-Index: AQHNbrcu8rUMPpqCAkO2bwjKkGKSBZdDCq4AgBBg6tCAAIxBAP//ixDw Date: Fri, 10 Aug 2012 19:42:29 +0000 Message-ID: <728F9B956B2C48439CA9294B1723B14623759EBF@dfweml509-mbs.china.huawei.com> References: <50170D34.503@joelhalpern.com> <1FB014C5-8B5A-4D34-82AD-D8E64A0098FF@raszuk.net> <82E1F44F-5EB2-4B06-8682-724555B51896@raszuk.net> <728F9B956B2C48439CA9294B1723B14623759D2F@dfweml509-mbs.china.huawei.com> <502563A0.4020905@raszuk.net> In-Reply-To: <502563A0.4020905@raszuk.net> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.212.244.143] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: Thomas Nadeau , "irs-discuss@ietf.org" , James Kempf , Alia Atlas , Thomas Nadeau , "Joel M. Halpern" Subject: Re: [irs-discuss] IRS Problem Statement Posted X-BeenThere: irs-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Aug 2012 19:45:25 -0000 Robert: I am now confused. Can you give me more examples about the streaming aspect= of IRS framework, and why you questioned it.=20 Thanks, Sue Hares=20 -----Original Message----- From: Robert Raszuk [mailto:robert@raszuk.net]=20 Sent: Friday, August 10, 2012 12:40 PM To: Susan Hares Cc: Alia Atlas; Thomas Nadeau; James Kempf; Joel M. Halpern; irs-discuss@ie= tf.org; Thomas Nadeau Subject: Re: [irs-discuss] IRS Problem Statement Posted Hi Sue, My below email expresses no questions or issues towards=20 draft-gredler-idr-ls-distribution. The streaming aspect of IRS framework into BGP or IGPs was questioned. Best regards, R. > Robert: > > [Catching up with old email] > > Why are you concerned with the streaming aspects of the data from BGP and= ISIS? If you are could you cross post to idr@ietf.org. > We are considering the draft-gredler-idr-ls-distribution at this time. > > Sue > > -----Original Message----- > From: irs-discuss-bounces@ietf.org [mailto:irs-discuss-bounces@ietf.org] = On Behalf Of Robert Raszuk > Sent: Monday, July 30, 2012 6:11 PM > To: Alia Atlas > Cc: Thomas Nadeau; James Kempf; Joel M. Halpern; irs-discuss@ietf.org; Th= omas Nadeau > Subject: Re: [irs-discuss] IRS Problem Statement Posted > > What is not clear for me is ability from arbitrary entities to be able to= write to BGP or ISIS at sort of ad-hoc streaming. I do not see anything go= od can be seen as result of this. > > Exporting information is fine - no objection at all. > > However for programming state into dynamic system the entity which writes= in should be the master and not the slave which unfortunately as of now it= looks like it is the latter. > > Perhaps you have in mind just adding bunch of ACLs on the edges, perhaps = just add static routes, perhaps insert network statements into BGP configur= ation. But till details are defined and till we understand how is this any = better from already standards based tools to do the same I think it is well= premature to judge any benefit from the IRS framework. > > Best Rgs, > R. > > > > Sent from my iPad > > On Jul 30, 2012, at 5:55 PM, Alia Atlas wrote: > >> Rob, >> >> We've been trying. I've written semi-copious words so far. >> I'd be happy to discuss with you in person as well and get your >> thoughts on reasonable use-cases. >> >> Describing an elephant for the first time is always tricky. >> >> Perhaps you could describe your perspective on the problem and what >> you think is unclear. >> >> Regards, >> Alia >> >> >> On Mon, Jul 30, 2012 at 7:31 PM, Robert Raszuk wrote= : >>> Tom, >>> >>> Yes indeed .. Clearly defining what problem are you trying to solve wou= ld be greatly helpful. >>> >>> Best, >>> R. >>> >>> >>> Sent from my iPad >>> >>> On Jul 30, 2012, at 3:54 PM, Thomas Nadeau wr= ote: >>> >>>> >>>> On Jul 30, 2012:3:39 PM, at 3:39 PM, "Joel M. Halpern" wrote: >>>> >>>>> Alia, I do have to disagree with one aspect of your characterization = fo ForCES. While the initial design goal was forwarding behavior, the prot= ocol design is such that it is usable over a broad range of abstraction lev= els. >>>>> >>>>> Similarly, depending upon exactly what we need, netconf + Netmad/YANG= may be suitable / useable. >>>> >>>> We are not ruling out any existing solutions, either in whole or in= part (modified). The goal right now is to define the problem space and a f= ramework of components that can be used to solve that problem. >>>> >>>>> On the other hand, I think that working out the problems and entities= that need to be modeled first (which probably does need a dedicated workin= g group), and then worrying about which protocol meets the requirements whe= n we know what exactly we need. At that point, the protocol work can be do= ne wherever appropriate. >>>> >>>> Yes, that is precisely what the goals are right now. >>>> >>>> --Tom >>>> >>>> >>>>> >>>>> yours, >>>>> Jitl >>>>> >>>>> On 7/30/2012 6:27 PM, Alia Atlas wrote: >>>>>> Hi James, >>>>>> >>>>>> Thanks for your thoughts. Streaming (as I've heard) is not as good= a >>>>>> description of the desired interface attributes as described in Sec >>>>>> 1.1, the functional overview. >>>>>> >>>>>> IRS is NOT about having interfaces to the forwarding plane. That's >>>>>> what ForCES is focused on. This is about communication to a router >>>>>> to install/retrieve routing state into the routing system (FIB, IGPs= , >>>>>> BGP, RSVP-TE, etc.) IRS is NOT splitting the control plane from th= e >>>>>> router. >>>>>> >>>>>> Are you suggesting that ForCES should drastically expand its scope? >>>>>> >>>>>> Before we start debating what and whether to expand existing >>>>>> protocols, I think we need a common understanding of the problem we'= re >>>>>> trying to solve and the related framework. >>>>>> >>>>>> Alia >>>>>> >>>>>> On Mon, Jul 30, 2012 at 6:11 PM, James Kempf wrote: >>>>>>> I don't understand why streaming is specified in this draft. And I = don't understand why this draft isn't put in the Forces framework. Forces i= s a framework explicitedly designed for device to controller communication.= Its major drawback it that it is a framework with a hole in the middle, in= that there are no specified devices. This draft would fill that hole. >>>>>>> >>>>>>> I don't think it is necessary to have a problem statement for route= r state update. Forces has already established that splitting the control p= lane into a separate device is, in some cases, an attractive design option.= So I think this should be submitted to the Forces working group, or, at le= ast, recast in the Forces framework. >>>>>>> >>>>>>> jak >>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: irs-discuss-bounces@ietf.org >>>>>>>> [mailto:irs-discuss-bounces@ietf.org] On Behalf Of Thomas Nadeau >>>>>>>> Sent: Monday, July 30, 2012 11:18 AM >>>>>>>> To: irs-discuss@ietf.org >>>>>>>> Subject: [irs-discuss] IRS Problem Statement Posted >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Please review and discuss. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> >>>>>>>> Tom, Alia, Ward >>>>>>>> >>>>>>>> >>>>>>>> http://lucidvision.com/draft-atlas-irs-problem-statement-00.txt >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> 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 >>>>>> _______________________________________________ >>>>>> 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 >>>>> >>>> >>>> _______________________________________________ >>>> 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 > > Return-Path: 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 519D021F8713 for ; Fri, 10 Aug 2012 12:40:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 67u3Nw1iKWip for ; Fri, 10 Aug 2012 12:40:19 -0700 (PDT) Received: from mail1310.opentransfer.com (mail1310.opentransfer.com [76.162.254.103]) by ietfa.amsl.com (Postfix) with ESMTP id F2C5C21F873A for ; Fri, 10 Aug 2012 12:40:18 -0700 (PDT) Received: (qmail 15195 invoked by uid 399); 10 Aug 2012 19:41:18 -0000 Received: from unknown (HELO ?192.168.1.58?) (pbs:robert@raszuk.net@83.13.163.62) by mail1310.opentransfer.com with ESMTPM; 10 Aug 2012 19:41:18 -0000 X-Originating-IP: 83.13.163.62 Message-ID: <502563A0.4020905@raszuk.net> Date: Fri, 10 Aug 2012 21:40:16 +0200 From: Robert Raszuk User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: Susan Hares References: <50170D34.503@joelhalpern.com> <1FB014C5-8B5A-4D34-82AD-D8E64A0098FF@raszuk.net> <82E1F44F-5EB2-4B06-8682-724555B51896@raszuk.net> <728F9B956B2C48439CA9294B1723B14623759D2F@dfweml509-mbs.china.huawei.com> In-Reply-To: <728F9B956B2C48439CA9294B1723B14623759D2F@dfweml509-mbs.china.huawei.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Thomas Nadeau , "irs-discuss@ietf.org" , James Kempf , Alia Atlas , Thomas Nadeau , "Joel M. Halpern" Subject: Re: [irs-discuss] IRS Problem Statement Posted X-BeenThere: irs-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: robert@raszuk.net List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Aug 2012 19:40:20 -0000 Hi Sue, My below email expresses no questions or issues towards draft-gredler-idr-ls-distribution. The streaming aspect of IRS framework into BGP or IGPs was questioned. Best regards, R. > Robert: > > [Catching up with old email] > > Why are you concerned with the streaming aspects of the data from BGP and ISIS? If you are could you cross post to idr@ietf.org. > We are considering the draft-gredler-idr-ls-distribution at this time. > > Sue > > -----Original Message----- > From: irs-discuss-bounces@ietf.org [mailto:irs-discuss-bounces@ietf.org] On Behalf Of Robert Raszuk > Sent: Monday, July 30, 2012 6:11 PM > To: Alia Atlas > Cc: Thomas Nadeau; James Kempf; Joel M. Halpern; irs-discuss@ietf.org; Thomas Nadeau > Subject: Re: [irs-discuss] IRS Problem Statement Posted > > What is not clear for me is ability from arbitrary entities to be able to write to BGP or ISIS at sort of ad-hoc streaming. I do not see anything good can be seen as result of this. > > Exporting information is fine - no objection at all. > > However for programming state into dynamic system the entity which writes in should be the master and not the slave which unfortunately as of now it looks like it is the latter. > > Perhaps you have in mind just adding bunch of ACLs on the edges, perhaps just add static routes, perhaps insert network statements into BGP configuration. But till details are defined and till we understand how is this any better from already standards based tools to do the same I think it is well premature to judge any benefit from the IRS framework. > > Best Rgs, > R. > > > > Sent from my iPad > > On Jul 30, 2012, at 5:55 PM, Alia Atlas wrote: > >> Rob, >> >> We've been trying. I've written semi-copious words so far. >> I'd be happy to discuss with you in person as well and get your >> thoughts on reasonable use-cases. >> >> Describing an elephant for the first time is always tricky. >> >> Perhaps you could describe your perspective on the problem and what >> you think is unclear. >> >> Regards, >> Alia >> >> >> On Mon, Jul 30, 2012 at 7:31 PM, Robert Raszuk wrote: >>> Tom, >>> >>> Yes indeed .. Clearly defining what problem are you trying to solve would be greatly helpful. >>> >>> Best, >>> R. >>> >>> >>> Sent from my iPad >>> >>> On Jul 30, 2012, at 3:54 PM, Thomas Nadeau wrote: >>> >>>> >>>> On Jul 30, 2012:3:39 PM, at 3:39 PM, "Joel M. Halpern" wrote: >>>> >>>>> Alia, I do have to disagree with one aspect of your characterization fo ForCES. While the initial design goal was forwarding behavior, the protocol design is such that it is usable over a broad range of abstraction levels. >>>>> >>>>> Similarly, depending upon exactly what we need, netconf + Netmad/YANG may be suitable / useable. >>>> >>>> We are not ruling out any existing solutions, either in whole or in part (modified). The goal right now is to define the problem space and a framework of components that can be used to solve that problem. >>>> >>>>> On the other hand, I think that working out the problems and entities that need to be modeled first (which probably does need a dedicated working group), and then worrying about which protocol meets the requirements when we know what exactly we need. At that point, the protocol work can be done wherever appropriate. >>>> >>>> Yes, that is precisely what the goals are right now. >>>> >>>> --Tom >>>> >>>> >>>>> >>>>> yours, >>>>> Jitl >>>>> >>>>> On 7/30/2012 6:27 PM, Alia Atlas wrote: >>>>>> Hi James, >>>>>> >>>>>> Thanks for your thoughts. Streaming (as I've heard) is not as good a >>>>>> description of the desired interface attributes as described in Sec >>>>>> 1.1, the functional overview. >>>>>> >>>>>> IRS is NOT about having interfaces to the forwarding plane. That's >>>>>> what ForCES is focused on. This is about communication to a router >>>>>> to install/retrieve routing state into the routing system (FIB, IGPs, >>>>>> BGP, RSVP-TE, etc.) IRS is NOT splitting the control plane from the >>>>>> router. >>>>>> >>>>>> Are you suggesting that ForCES should drastically expand its scope? >>>>>> >>>>>> Before we start debating what and whether to expand existing >>>>>> protocols, I think we need a common understanding of the problem we're >>>>>> trying to solve and the related framework. >>>>>> >>>>>> Alia >>>>>> >>>>>> On Mon, Jul 30, 2012 at 6:11 PM, James Kempf wrote: >>>>>>> I don't understand why streaming is specified in this draft. And I don't understand why this draft isn't put in the Forces framework. Forces is a framework explicitedly designed for device to controller communication. Its major drawback it that it is a framework with a hole in the middle, in that there are no specified devices. This draft would fill that hole. >>>>>>> >>>>>>> I don't think it is necessary to have a problem statement for router state update. Forces has already established that splitting the control plane into a separate device is, in some cases, an attractive design option. So I think this should be submitted to the Forces working group, or, at least, recast in the Forces framework. >>>>>>> >>>>>>> jak >>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: irs-discuss-bounces@ietf.org >>>>>>>> [mailto:irs-discuss-bounces@ietf.org] On Behalf Of Thomas Nadeau >>>>>>>> Sent: Monday, July 30, 2012 11:18 AM >>>>>>>> To: irs-discuss@ietf.org >>>>>>>> Subject: [irs-discuss] IRS Problem Statement Posted >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Please review and discuss. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> >>>>>>>> Tom, Alia, Ward >>>>>>>> >>>>>>>> >>>>>>>> http://lucidvision.com/draft-atlas-irs-problem-statement-00.txt >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> 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 >>>>>> _______________________________________________ >>>>>> 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 >>>>> >>>> >>>> _______________________________________________ >>>> 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 > > Return-Path: 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 C416711E809A for ; Fri, 10 Aug 2012 12:19:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.099 X-Spam-Level: X-Spam-Status: No, score=-5.099 tagged_above=-999 required=5 tests=[AWL=0.900, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 05lMSmvmxdYY for ; Fri, 10 Aug 2012 12:19:52 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 05EAC11E8099 for ; Fri, 10 Aug 2012 12:19:51 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml202-edg.china.huawei.com) ([172.18.9.243]) by dfwrg02-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AIS74784; Fri, 10 Aug 2012 11:19:51 -0800 (PST) Received: from DFWEML405-HUB.china.huawei.com (10.193.5.102) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 10 Aug 2012 12:17:36 -0700 Received: from dfweml509-mbs.china.huawei.com ([169.254.12.123]) by dfweml405-hub.china.huawei.com ([10.193.5.102]) with mapi id 14.01.0323.003; Fri, 10 Aug 2012 12:17:32 -0700 From: Susan Hares To: "robert@raszuk.net" , Thomas Nadeau Thread-Topic: [irs-discuss] Suggestions for IRS Way Forward Thread-Index: Ac1w/aRFxquJYy0LSJCFfpb4MILlegAO51CAAAIJPoABepTsoA== Date: Fri, 10 Aug 2012 19:17:32 +0000 Message-ID: <728F9B956B2C48439CA9294B1723B14623759DB0@dfweml509-mbs.china.huawei.com> References: <501B0D75.4090009@raszuk.net> In-Reply-To: <501B0D75.4090009@raszuk.net> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.212.244.143] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: James Kempf , "irs-discuss@ietf.org" Subject: Re: [irs-discuss] Suggestions for IRS Way Forward X-BeenThere: irs-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Aug 2012 19:19:52 -0000 Robert: Here's the questions I have to the authors of this draft:=20 1. How does this draft prevent sending this non-routing information to the = whole BGP peers? The draft says private peering. The question is regarding the private = peer - is do the implementations=20 Have the knobs to aid the detection and enforcement of this private pee= ring?=20 I believe you have seen the questions by operators (e.g., Rob). 2. How does this draft impact the ROA work? Is it orthogonal? Will the ROA= work be turned off For the draft-gredler-idr-ls-distribution-01?=20 3. Is this for IBGP only? Or is it for EBGP in AS Confederations?=20 How does the RR infrastructure get protected?=20 Sue=20 -----Original Message----- From: irs-discuss-bounces@ietf.org [mailto:irs-discuss-bounces@ietf.org] On= Behalf Of Robert Raszuk Sent: Thursday, August 02, 2012 4:30 PM To: Thomas Nadeau Cc: James Kempf; irs-discuss@ietf.org Subject: Re: [irs-discuss] Suggestions for IRS Way Forward Tom, > I agree that one of the top work items for this effort should be a > standardized topology function, and one that is accessible via a > non-routing protocol. So if the requirement is to have topology export via non-routing=20 protocol then I think we should seriously revisit or repackage the=20 draft-gredler-idr-ls-distribution-01 which works for for both OSPF and=20 ISIS. However before that let's really understand the requirement why it must=20 be exported via non-routing protocol .... Keep in mind that just to=20 parse BGP UPDATE messages and retrieve interesting pieces out it it=20 requires very little code rather then full BGP implementation. The particular feature I like about draft-gredler-idr-ls-distribution-01=20 is that it is read-only ;) R. > > I agree that one of the top work items for this effort should be a > standardized topology function, and one that is accessible via a > non-routing protocol. While not exactly "low hanging fruit", it is > something that (to me) is a clear work item with clear goals that should > be tackled straight away. > > --Tom > > > > On 8/2/12 3:24 PM, "James Kempf" wrote: > >> So after seeing part of Alia's talk this morning (I had to leave in the >> middle unfortunately), I'd like to make a couple suggestions. There were >> a lot of ideas presented in the talk, enough for an entire IETF Area. I >> think to make tangible progress, the work needs to be focussed on a smal= l >> subset that would be of immediate interest and usability. >> >> There are a couple areas that suggest themselves, but one that would be >> useful in work that I've been involved in is a standardized format for >> network topology representation and a protocol for exchanging it. The >> Onix OpenFlow controller has a network information base with a >> specialized format for network topology, and every OpenFlow controller >> requires this. Having a standardized way to represent it might foster a >> common topology database package. Another application is network >> management. Every network management system needs some kind of topology >> representation. Finally, though I am not an expert in PCE construction, >> it would seem to me that a PCE would need some kind of topology >> representation in order to perform path calculations. Having a way,for >> example, for the OpenFlow controller and the PCE to exchange topology >> information would be really useful. I would say to start with physical >> topology because that is fundamental, but make the format flexible enoug= h >> to support >> virtual topology representation. >> >> jak >> _______________________________________________ >> 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 > > _______________________________________________ irs-discuss mailing list irs-discuss@ietf.org https://www.ietf.org/mailman/listinfo/irs-discuss Return-Path: 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 22BD721F877B for ; Fri, 10 Aug 2012 11:30:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.357 X-Spam-Level: X-Spam-Status: No, score=-5.357 tagged_above=-999 required=5 tests=[AWL=1.242, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZeF3yh8UBJ9z for ; Fri, 10 Aug 2012 11:30:03 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id E64EA21F8745 for ; Fri, 10 Aug 2012 11:30:02 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml202-edg.china.huawei.com) ([172.18.9.243]) by dfwrg02-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AIS71851; Fri, 10 Aug 2012 10:30:02 -0800 (PST) Received: from DFWEML405-HUB.china.huawei.com (10.193.5.102) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 10 Aug 2012 11:27:19 -0700 Received: from dfweml509-mbs.china.huawei.com ([169.254.12.123]) by dfweml405-hub.china.huawei.com ([10.193.5.102]) with mapi id 14.01.0323.003; Fri, 10 Aug 2012 11:27:14 -0700 From: Susan Hares To: Robert Raszuk , Alia Atlas Thread-Topic: [irs-discuss] IRS Problem Statement Posted Thread-Index: AQHNbrcu8rUMPpqCAkO2bwjKkGKSBZdDCq4AgBBg6tA= Date: Fri, 10 Aug 2012 18:27:13 +0000 Message-ID: <728F9B956B2C48439CA9294B1723B14623759D2F@dfweml509-mbs.china.huawei.com> References: <50170D34.503@joelhalpern.com> <1FB014C5-8B5A-4D34-82AD-D8E64A0098FF@raszuk.net> <82E1F44F-5EB2-4B06-8682-724555B51896@raszuk.net> In-Reply-To: <82E1F44F-5EB2-4B06-8682-724555B51896@raszuk.net> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.212.244.143] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: Thomas Nadeau , Thomas Nadeau , James Kempf , "Joel M. Halpern" , "irs-discuss@ietf.org" Subject: Re: [irs-discuss] IRS Problem Statement Posted X-BeenThere: irs-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Aug 2012 18:30:04 -0000 Robert: [Catching up with old email] Why are you concerned with the streaming aspects of the data from BGP and I= SIS? If you are could you cross post to idr@ietf.org.=20 We are considering the draft-gredler-idr-ls-distribution at this time.=20 Sue=20 -----Original Message----- From: irs-discuss-bounces@ietf.org [mailto:irs-discuss-bounces@ietf.org] On= Behalf Of Robert Raszuk Sent: Monday, July 30, 2012 6:11 PM To: Alia Atlas Cc: Thomas Nadeau; James Kempf; Joel M. Halpern; irs-discuss@ietf.org; Thom= as Nadeau Subject: Re: [irs-discuss] IRS Problem Statement Posted What is not clear for me is ability from arbitrary entities to be able to w= rite to BGP or ISIS at sort of ad-hoc streaming. I do not see anything good= can be seen as result of this.=20 Exporting information is fine - no objection at all. However for programming state into dynamic system the entity which writes i= n should be the master and not the slave which unfortunately as of now it l= ooks like it is the latter. Perhaps you have in mind just adding bunch of ACLs on the edges, perhaps ju= st add static routes, perhaps insert network statements into BGP configurat= ion. But till details are defined and till we understand how is this any be= tter from already standards based tools to do the same I think it is well p= remature to judge any benefit from the IRS framework. Best Rgs, R. Sent from my iPad On Jul 30, 2012, at 5:55 PM, Alia Atlas wrote: > Rob, >=20 > We've been trying. I've written semi-copious words so far. > I'd be happy to discuss with you in person as well and get your > thoughts on reasonable use-cases. >=20 > Describing an elephant for the first time is always tricky. >=20 > Perhaps you could describe your perspective on the problem and what > you think is unclear. >=20 > Regards, > Alia >=20 >=20 > On Mon, Jul 30, 2012 at 7:31 PM, Robert Raszuk wrote: >> Tom, >>=20 >> Yes indeed .. Clearly defining what problem are you trying to solve woul= d be greatly helpful. >>=20 >> Best, >> R. >>=20 >>=20 >> Sent from my iPad >>=20 >> On Jul 30, 2012, at 3:54 PM, Thomas Nadeau wro= te: >>=20 >>>=20 >>> On Jul 30, 2012:3:39 PM, at 3:39 PM, "Joel M. Halpern" wrote: >>>=20 >>>> Alia, I do have to disagree with one aspect of your characterization f= o ForCES. While the initial design goal was forwarding behavior, the proto= col design is such that it is usable over a broad range of abstraction leve= ls. >>>>=20 >>>> Similarly, depending upon exactly what we need, netconf + Netmad/YANG = may be suitable / useable. >>>=20 >>> We are not ruling out any existing solutions, either in whole or in p= art (modified). The goal right now is to define the problem space and a fra= mework of components that can be used to solve that problem. >>>=20 >>>> On the other hand, I think that working out the problems and entities = that need to be modeled first (which probably does need a dedicated working= group), and then worrying about which protocol meets the requirements when= we know what exactly we need. At that point, the protocol work can be don= e wherever appropriate. >>>=20 >>> Yes, that is precisely what the goals are right now. >>>=20 >>> --Tom >>>=20 >>>=20 >>>>=20 >>>> yours, >>>> Jitl >>>>=20 >>>> On 7/30/2012 6:27 PM, Alia Atlas wrote: >>>>> Hi James, >>>>>=20 >>>>> Thanks for your thoughts. Streaming (as I've heard) is not as good = a >>>>> description of the desired interface attributes as described in Sec >>>>> 1.1, the functional overview. >>>>>=20 >>>>> IRS is NOT about having interfaces to the forwarding plane. That's >>>>> what ForCES is focused on. This is about communication to a router >>>>> to install/retrieve routing state into the routing system (FIB, IGPs, >>>>> BGP, RSVP-TE, etc.) IRS is NOT splitting the control plane from the >>>>> router. >>>>>=20 >>>>> Are you suggesting that ForCES should drastically expand its scope? >>>>>=20 >>>>> Before we start debating what and whether to expand existing >>>>> protocols, I think we need a common understanding of the problem we'r= e >>>>> trying to solve and the related framework. >>>>>=20 >>>>> Alia >>>>>=20 >>>>> On Mon, Jul 30, 2012 at 6:11 PM, James Kempf wrote: >>>>>> I don't understand why streaming is specified in this draft. And I d= on't understand why this draft isn't put in the Forces framework. Forces is= a framework explicitedly designed for device to controller communication. = Its major drawback it that it is a framework with a hole in the middle, in = that there are no specified devices. This draft would fill that hole. >>>>>>=20 >>>>>> I don't think it is necessary to have a problem statement for router= state update. Forces has already established that splitting the control pl= ane into a separate device is, in some cases, an attractive design option. = So I think this should be submitted to the Forces working group, or, at lea= st, recast in the Forces framework. >>>>>>=20 >>>>>> jak >>>>>>=20 >>>>>>> -----Original Message----- >>>>>>> From: irs-discuss-bounces@ietf.org >>>>>>> [mailto:irs-discuss-bounces@ietf.org] On Behalf Of Thomas Nadeau >>>>>>> Sent: Monday, July 30, 2012 11:18 AM >>>>>>> To: irs-discuss@ietf.org >>>>>>> Subject: [irs-discuss] IRS Problem Statement Posted >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> Please review and discuss. >>>>>>>=20 >>>>>>> Thanks, >>>>>>>=20 >>>>>>> Tom, Alia, Ward >>>>>>>=20 >>>>>>>=20 >>>>>>> http://lucidvision.com/draft-atlas-irs-problem-statement-00.txt >>>>>>>=20 >>>>>>>=20 >>>>>>> _______________________________________________ >>>>>>> irs-discuss mailing list >>>>>>> irs-discuss@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/irs-discuss >>>>>>>=20 >>>>>> _______________________________________________ >>>>>> 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 >>>>>=20 >>>> _______________________________________________ >>>> irs-discuss mailing list >>>> irs-discuss@ietf.org >>>> https://www.ietf.org/mailman/listinfo/irs-discuss >>>>=20 >>>=20 >>> _______________________________________________ >>> 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 Return-Path: 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 B99A221F85D6 for ; Thu, 9 Aug 2012 20:56:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.38 X-Spam-Level: X-Spam-Status: No, score=-6.38 tagged_above=-999 required=5 tests=[AWL=0.219, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ExUZ8bOMd3Dc for ; Thu, 9 Aug 2012 20:56:56 -0700 (PDT) Received: from exprod7og112.obsmtp.com (exprod7og112.obsmtp.com [64.18.2.177]) by ietfa.amsl.com (Postfix) with ESMTP id 0168721F85D5 for ; Thu, 9 Aug 2012 20:56:55 -0700 (PDT) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob112.postini.com ([64.18.6.12]) with SMTP ID DSNKUCSGhocBvonvrzjH+p+y/rsS/83pX3Lw@postini.com; Thu, 09 Aug 2012 20:56:56 PDT Received: from emailfeemea1.jnpr.net (172.26.192.140) by P-EMHUB03-HQ.jnpr.net (172.24.192.37) with Microsoft SMTP Server id 8.3.213.0; Thu, 9 Aug 2012 20:54:18 -0700 Received: from p-embx01-eq.jnpr.net ([172.26.192.150]) by emailfeemea1.jnpr.net with Microsoft SMTPSVC(6.0.3790.4675); Fri, 10 Aug 2012 04:54:16 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 10 Aug 2012 04:54:15 +0100 Message-ID: <812700A304640D4292205D5E83FC59E1061C2134@p-embx01-eq.jnpr.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [irs-discuss] IRS comments Thread-Index: Ac1utoJXMLn1Fv5cTmO9ZkEBmEbA7gABwUJeAcg805AAKmPZAAAHCbOAAAZRSNAABGlb6g== From: Gert Grammel To: , X-OriginalArrivalTime: 10 Aug 2012 03:54:16.0771 (UTC) FILETIME=[D02D0930:01CD76AB] Cc: Thomas Nadeau , Alia Atlas , Lenny Giuliano , 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Aug 2012 03:56:57 -0000 Susan, Q1: Which NM are you implying here?=20 A: traditionally a functional view on the subject has been used. Think = about it. Does the fact that a piece of Software monitors a device = justify to name it 'Network Management'? Is CLI a Network Management? Q2: Configuration included download plus transactional (roll = forward/roll-back).=20 A: that's what's required to keep two persistent databases aligned. A3: Your description does not match the current status of the IGPs or = BGP implementations.=20 Q3: what let you to that conclusion? Those are CP protocols. Q4: Where do you place the Graceful-Restart or Hitless Restart or High = availability work? Do you place this in a PCE or a stateful PCE?=20 A4: IETF work is always placed between 2 or more entities because we = deal with protocols. =20 ----- Original Message ----- From: Susan Hares To: Gert Grammel; Thomas Nadeau Cc: Thomas Nadeau; Lenny Giuliano; Alia Atlas; irs-discuss@ietf.org = Sent: Fri Aug 10 02:51:36 2012 Subject: RE: [irs-discuss] IRS comments Gert: I'm interested in discussing the theory of the network management. = Tradition Network management (ISO documents) looked at such generic = ideas as configuration, performance, fault management, and monitoring. = Which NM are you implying here?=20 Configuration included download plus transactional (roll = forward/roll-back).=20 Your description does not match the current status of the IGPs or BGP = implementations.=20 Where do you place the Graceful-Restart or Hitless Restart or High = availability work? Do you place this in a PCE or a stateful PCE?=20 Sue=20 -----Original Message----- From: Gert Grammel [mailto:ggrammel@juniper.net]=20 Sent: Thursday, August 09, 2012 1:00 PM To: Thomas Nadeau; Susan Hares Cc: Thomas Nadeau; Lenny Giuliano; Alia Atlas; irs-discuss@ietf.org Subject: RE: [irs-discuss] IRS comments Susan, The difference of a NP-plane compared to control and management planes can best be explained by describing a power cycle: - The Management plane supervises (Monitoring and Alarms), and when configuring, it creates persistent state in the switching element as well as in the Management plane itself. In other words state that remains in the box (switch and NMS) even after a power cycle.=20 - A control plane behaves differently. After a power cycle the switching element needs to re-learn state from its peers. - The NPP is a strange hybrid, it can create persistent state in the NPP but not in the switching element. In other words, if you re-start the NPP, all configuration comes up as of before. If you re-start the switching element, it needs to synch up with NPP. A nice example for a NPP function is e.g. a centralized PCE server. You can create a lot of persistent rules and parameters there on how to calculate the path. Those parameters will remain in the PCE-server even after a PCE-server re-start. Yet the PCE doesn't create persistent information in the switching elements. If those re-start, they'll have to re-synch.=20 I am well aware that in the past folks positioned various elements (PCE, RR, IRS, ...) either as part of the Control Plane or a part of the management plane. And yes, positioning is not an exact science. Nevertheless I believe that it is now time to give a class name to those vagabonding objects.=20 -- Gert -----Original Message----- From: Thomas Nadeau [mailto:tnadeau@lucidvision.com]=20 Sent: Thursday, August 09, 2012 9:38 AM To: Susan Hares Cc: Gert Grammel; Thomas Nadeau; Lenny Giuliano; Alia Atlas; irs-discuss@ietf.org Subject: Re: [irs-discuss] IRS comments We intended for irs to need both read and write capabilities, hence our use of "bidirectional" in describing the interface characteristics in the problem statement. One big difference between existing "network management" and what we are trying to specify now is real-time transactional capabilities. Tom=20 On Aug 9, 2012, at 10:57 AM, Susan Hares wrote: > Gert: >=20 > How do you characterize network management? Traditionally network management has been viewed in the IETF in two streams: monitoring (active or passive) and configuration. =20 >=20 > What parts of these features do you think the IRS system needs to avoid?=20 >=20 > Sue >=20 > -----Original Message----- > From: irs-discuss-bounces@ietf.org=20 > [mailto:irs-discuss-bounces@ietf.org] On Behalf Of Gert Grammel > Sent: Monday, July 30, 2012 6:41 PM > To: Thomas Nadeau; Lenny Giuliano; Alia Atlas > Cc: irs-discuss@ietf.org > Subject: Re: [irs-discuss] IRS comments >=20 > Tom, >=20 > It is confusing to understand whether IRS belongs to a new network management plane or if it's more of a control plane extension. The draft wisely avoids this classification. > To me IRS appears to be a completely different beast which should best be characterized as 'Network Programming Plane' NPP.=20 > It neither aims to do full provisioning (as a management plane would do) nor aims to replace routing (as a control plane would do). > Hence we better name the baby NPP -- thereby avoiding any linkage to taxation. >=20 >=20 > Gert >=20 >=20 >=20 >=20 > ----- Original Message ----- > From: irs-discuss-bounces@ietf.org > To: Lenny Giuliano; Alia Atlas > Cc: irs-discuss@ietf.org > Sent: Tue Jul 31 01:50:40 2012 > Subject: Re: [irs-discuss] IRS comments >=20 >=20 > [Re-adding IRS] >=20 > Thank you for reviewing and the comments. We will incorporate the=20 > edits in the next rev. >=20 > --Tom >=20 >=20 > On 7/30/12 5:04 PM, "Lenny Giuliano" wrote: >=20 >>=20 >> Minor points: >>=20 >> -section 4, para 2, 3rd sentence, "Howeve,r" >>=20 >> -4.1.3 "There is no bidirectional programmatic interface to add, modify, >> remove or read state from the multicast RIB." >> -How is this unique to mcast? Couldn't you say the same thing >> about unicast? >>=20 >> -4.1.3 "The multicast state added need not match to well-known protocol >> installed state. For instance, traffic received on an specified set, >> or all, interfaces that is destined to a particular prefix from all >> sources or a particular prefix could be subject to the specified >> replication." >> -Not clear to me at all what this para is saying. >>=20 >> -"IRS"- you may want to select a different acronym that isn't related >> to something as unpopular as taxation (something we learned with AMT). >> Maybe >> RSI instead... >>=20 >> Overall, I found the doc to be clearly written and straightforward. >> Sounds like Openflow for routers. Not sure if it's intentional that=20 >> you didn't mention Openflow, but it did seem like an elephant in the=20 >> room as I was reading thru. Also, I did wonder what was new and=20 >> novel here, as this sounded like our SDK which has been around for=20 >> years. >>=20 >>=20 >> -Lenny >=20 > _______________________________________________ > 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 > _______________________________________________ > irs-discuss mailing list > irs-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/irs-discuss >=20 Return-Path: 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 0695C21F85C6 for ; Thu, 9 Aug 2012 18:56:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.313 X-Spam-Level: X-Spam-Status: No, score=-5.313 tagged_above=-999 required=5 tests=[AWL=1.286, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TGuETQgTSiJk for ; Thu, 9 Aug 2012 18:56:13 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 228F321F85C5 for ; Thu, 9 Aug 2012 18:56:13 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml202-edg.china.huawei.com) ([172.18.9.243]) by dfwrg02-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AIS11449; Thu, 09 Aug 2012 17:56:12 -0800 (PST) Received: from DFWEML403-HUB.china.huawei.com (10.193.5.151) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 9 Aug 2012 18:51:40 -0700 Received: from dfweml509-mbs.china.huawei.com ([169.254.12.123]) by dfweml403-hub.china.huawei.com ([10.193.5.151]) with mapi id 14.01.0323.003; Thu, 9 Aug 2012 18:51:37 -0700 From: Susan Hares To: Gert Grammel , Thomas Nadeau Thread-Topic: [irs-discuss] IRS comments Thread-Index: Ac1utoJXMLn1Fv5cTmO9ZkEBmEbA7gABwUJeAcg805AAKmPZAAAHCbOAAAZRSNA= Date: Fri, 10 Aug 2012 01:51:36 +0000 Message-ID: <728F9B956B2C48439CA9294B1723B14623758172@dfweml509-mbs.china.huawei.com> References: <812700A304640D4292205D5E83FC59E1061C211D@p-embx01-eq.jnpr.net> <728F9B956B2C48439CA9294B1723B14623757671@dfweml509-mbs.china.huawei.com> <7441EA0C-2DB0-4B68-AD04-0F556CD1BE2E@lucidvision.com> <812700A304640D4292205D5E83FC59E107371740@p-embx01-eq.jnpr.net> In-Reply-To: <812700A304640D4292205D5E83FC59E107371740@p-embx01-eq.jnpr.net> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.212.246.116] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: Thomas Nadeau , Alia Atlas , Lenny Giuliano , "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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Aug 2012 01:56:14 -0000 Gert: I'm interested in discussing the theory of the network management. Traditio= n Network management (ISO documents) looked at such generic ideas as config= uration, performance, fault management, and monitoring. Which NM are you im= plying here?=20 Configuration included download plus transactional (roll forward/roll-back)= .=20 Your description does not match the current status of the IGPs or BGP imple= mentations.=20 Where do you place the Graceful-Restart or Hitless Restart or High availabi= lity work? Do you place this in a PCE or a stateful PCE?=20 Sue=20 -----Original Message----- From: Gert Grammel [mailto:ggrammel@juniper.net]=20 Sent: Thursday, August 09, 2012 1:00 PM To: Thomas Nadeau; Susan Hares Cc: Thomas Nadeau; Lenny Giuliano; Alia Atlas; irs-discuss@ietf.org Subject: RE: [irs-discuss] IRS comments Susan, The difference of a NP-plane compared to control and management planes can best be explained by describing a power cycle: - The Management plane supervises (Monitoring and Alarms), and when configuring, it creates persistent state in the switching element as well as in the Management plane itself. In other words state that remains in the box (switch and NMS) even after a power cycle.=20 - A control plane behaves differently. After a power cycle the switching element needs to re-learn state from its peers. - The NPP is a strange hybrid, it can create persistent state in the NPP but not in the switching element. In other words, if you re-start the NPP, all configuration comes up as of before. If you re-start the switching element, it needs to synch up with NPP. A nice example for a NPP function is e.g. a centralized PCE server. You can create a lot of persistent rules and parameters there on how to calculate the path. Those parameters will remain in the PCE-server even after a PCE-server re-start. Yet the PCE doesn't create persistent information in the switching elements. If those re-start, they'll have to re-synch.=20 I am well aware that in the past folks positioned various elements (PCE, RR, IRS, ...) either as part of the Control Plane or a part of the management plane. And yes, positioning is not an exact science. Nevertheless I believe that it is now time to give a class name to those vagabonding objects.=20 -- Gert -----Original Message----- From: Thomas Nadeau [mailto:tnadeau@lucidvision.com]=20 Sent: Thursday, August 09, 2012 9:38 AM To: Susan Hares Cc: Gert Grammel; Thomas Nadeau; Lenny Giuliano; Alia Atlas; irs-discuss@ietf.org Subject: Re: [irs-discuss] IRS comments We intended for irs to need both read and write capabilities, hence our use of "bidirectional" in describing the interface characteristics in the problem statement. One big difference between existing "network management" and what we are trying to specify now is real-time transactional capabilities. Tom=20 On Aug 9, 2012, at 10:57 AM, Susan Hares wrote: > Gert: >=20 > How do you characterize network management? Traditionally network management has been viewed in the IETF in two streams: monitoring (active or passive) and configuration. =20 >=20 > What parts of these features do you think the IRS system needs to avoid?=20 >=20 > Sue >=20 > -----Original Message----- > From: irs-discuss-bounces@ietf.org=20 > [mailto:irs-discuss-bounces@ietf.org] On Behalf Of Gert Grammel > Sent: Monday, July 30, 2012 6:41 PM > To: Thomas Nadeau; Lenny Giuliano; Alia Atlas > Cc: irs-discuss@ietf.org > Subject: Re: [irs-discuss] IRS comments >=20 > Tom, >=20 > It is confusing to understand whether IRS belongs to a new network management plane or if it's more of a control plane extension. The draft wisely avoids this classification. > To me IRS appears to be a completely different beast which should best be characterized as 'Network Programming Plane' NPP.=20 > It neither aims to do full provisioning (as a management plane would do) nor aims to replace routing (as a control plane would do). > Hence we better name the baby NPP -- thereby avoiding any linkage to taxation. >=20 >=20 > Gert >=20 >=20 >=20 >=20 > ----- Original Message ----- > From: irs-discuss-bounces@ietf.org > To: Lenny Giuliano; Alia Atlas > Cc: irs-discuss@ietf.org > Sent: Tue Jul 31 01:50:40 2012 > Subject: Re: [irs-discuss] IRS comments >=20 >=20 > [Re-adding IRS] >=20 > Thank you for reviewing and the comments. We will incorporate the=20 > edits in the next rev. >=20 > --Tom >=20 >=20 > On 7/30/12 5:04 PM, "Lenny Giuliano" wrote: >=20 >>=20 >> Minor points: >>=20 >> -section 4, para 2, 3rd sentence, "Howeve,r" >>=20 >> -4.1.3 "There is no bidirectional programmatic interface to add, modify, >> remove or read state from the multicast RIB." >> -How is this unique to mcast? Couldn't you say the same thing >> about unicast? >>=20 >> -4.1.3 "The multicast state added need not match to well-known protocol >> installed state. For instance, traffic received on an specified set, >> or all, interfaces that is destined to a particular prefix from all >> sources or a particular prefix could be subject to the specified >> replication." >> -Not clear to me at all what this para is saying. >>=20 >> -"IRS"- you may want to select a different acronym that isn't related >> to something as unpopular as taxation (something we learned with AMT). >> Maybe >> RSI instead... >>=20 >> Overall, I found the doc to be clearly written and straightforward. >> Sounds like Openflow for routers. Not sure if it's intentional that=20 >> you didn't mention Openflow, but it did seem like an elephant in the=20 >> room as I was reading thru. Also, I did wonder what was new and=20 >> novel here, as this sounded like our SDK which has been around for=20 >> years. >>=20 >>=20 >> -Lenny >=20 > _______________________________________________ > 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 > _______________________________________________ > irs-discuss mailing list > irs-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/irs-discuss >=20 Return-Path: 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 9125B21F8723 for ; Thu, 9 Aug 2012 13:02:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.325 X-Spam-Level: X-Spam-Status: No, score=-6.325 tagged_above=-999 required=5 tests=[AWL=0.274, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BgocZVXe3Jjx for ; Thu, 9 Aug 2012 13:02:06 -0700 (PDT) Received: from exprod7og110.obsmtp.com (exprod7og110.obsmtp.com [64.18.2.173]) by ietfa.amsl.com (Postfix) with ESMTP id 15F3221F8705 for ; Thu, 9 Aug 2012 13:02:05 -0700 (PDT) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob110.postini.com ([64.18.6.12]) with SMTP ID DSNKUCQXOi95ffxvl4No+CcuUyPizPAD7Xrp@postini.com; Thu, 09 Aug 2012 13:02:05 PDT Received: from emailfeemea1.jnpr.net (172.26.192.140) by P-EMHUB02-HQ.jnpr.net (172.24.192.36) with Microsoft SMTP Server id 8.3.213.0; Thu, 9 Aug 2012 12:59:47 -0700 Received: from p-embx01-eq.jnpr.net ([172.26.192.150]) by emailfeemea1.jnpr.net with Microsoft SMTPSVC(6.0.3790.4675); Thu, 9 Aug 2012 20:59:45 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 9 Aug 2012 20:59:43 +0100 Message-ID: <812700A304640D4292205D5E83FC59E107371740@p-embx01-eq.jnpr.net> In-Reply-To: <7441EA0C-2DB0-4B68-AD04-0F556CD1BE2E@lucidvision.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [irs-discuss] IRS comments Thread-Index: Ac12TWVEZoopc1DJQtSwOFdZL6Y+vAAFePMw References: <812700A304640D4292205D5E83FC59E1061C211D@p-embx01-eq.jnpr.net> <728F9B956B2C48439CA9294B1723B14623757671@dfweml509-mbs.china.huawei.com> <7441EA0C-2DB0-4B68-AD04-0F556CD1BE2E@lucidvision.com> From: Gert Grammel To: Thomas Nadeau , Susan Hares X-OriginalArrivalTime: 09 Aug 2012 19:59:45.0599 (UTC) FILETIME=[8608F4F0:01CD7669] Cc: Thomas Nadeau , Alia Atlas , Lenny Giuliano , 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Aug 2012 20:02:08 -0000 Susan, The difference of a NP-plane compared to control and management planes can best be explained by describing a power cycle: - The Management plane supervises (Monitoring and Alarms), and when configuring, it creates persistent state in the switching element as well as in the Management plane itself. In other words state that remains in the box (switch and NMS) even after a power cycle.=20 - A control plane behaves differently. After a power cycle the switching element needs to re-learn state from its peers. - The NPP is a strange hybrid, it can create persistent state in the NPP but not in the switching element. In other words, if you re-start the NPP, all configuration comes up as of before. If you re-start the switching element, it needs to synch up with NPP. A nice example for a NPP function is e.g. a centralized PCE server. You can create a lot of persistent rules and parameters there on how to calculate the path. Those parameters will remain in the PCE-server even after a PCE-server re-start. Yet the PCE doesn't create persistent information in the switching elements. If those re-start, they'll have to re-synch.=20 I am well aware that in the past folks positioned various elements (PCE, RR, IRS, ...) either as part of the Control Plane or a part of the management plane. And yes, positioning is not an exact science. Nevertheless I believe that it is now time to give a class name to those vagabonding objects.=20 -- Gert -----Original Message----- From: Thomas Nadeau [mailto:tnadeau@lucidvision.com]=20 Sent: Thursday, August 09, 2012 9:38 AM To: Susan Hares Cc: Gert Grammel; Thomas Nadeau; Lenny Giuliano; Alia Atlas; irs-discuss@ietf.org Subject: Re: [irs-discuss] IRS comments We intended for irs to need both read and write capabilities, hence our use of "bidirectional" in describing the interface characteristics in the problem statement. One big difference between existing "network management" and what we are trying to specify now is real-time transactional capabilities. Tom=20 On Aug 9, 2012, at 10:57 AM, Susan Hares wrote: > Gert: >=20 > How do you characterize network management? Traditionally network management has been viewed in the IETF in two streams: monitoring (active or passive) and configuration. =20 >=20 > What parts of these features do you think the IRS system needs to avoid?=20 >=20 > Sue >=20 > -----Original Message----- > From: irs-discuss-bounces@ietf.org=20 > [mailto:irs-discuss-bounces@ietf.org] On Behalf Of Gert Grammel > Sent: Monday, July 30, 2012 6:41 PM > To: Thomas Nadeau; Lenny Giuliano; Alia Atlas > Cc: irs-discuss@ietf.org > Subject: Re: [irs-discuss] IRS comments >=20 > Tom, >=20 > It is confusing to understand whether IRS belongs to a new network management plane or if it's more of a control plane extension. The draft wisely avoids this classification. > To me IRS appears to be a completely different beast which should best be characterized as 'Network Programming Plane' NPP.=20 > It neither aims to do full provisioning (as a management plane would do) nor aims to replace routing (as a control plane would do). > Hence we better name the baby NPP -- thereby avoiding any linkage to taxation. >=20 >=20 > Gert >=20 >=20 >=20 >=20 > ----- Original Message ----- > From: irs-discuss-bounces@ietf.org > To: Lenny Giuliano; Alia Atlas > Cc: irs-discuss@ietf.org > Sent: Tue Jul 31 01:50:40 2012 > Subject: Re: [irs-discuss] IRS comments >=20 >=20 > [Re-adding IRS] >=20 > Thank you for reviewing and the comments. We will incorporate the=20 > edits in the next rev. >=20 > --Tom >=20 >=20 > On 7/30/12 5:04 PM, "Lenny Giuliano" wrote: >=20 >>=20 >> Minor points: >>=20 >> -section 4, para 2, 3rd sentence, "Howeve,r" >>=20 >> -4.1.3 "There is no bidirectional programmatic interface to add, modify, >> remove or read state from the multicast RIB." >> -How is this unique to mcast? Couldn't you say the same thing >> about unicast? >>=20 >> -4.1.3 "The multicast state added need not match to well-known protocol >> installed state. For instance, traffic received on an specified set, >> or all, interfaces that is destined to a particular prefix from all >> sources or a particular prefix could be subject to the specified >> replication." >> -Not clear to me at all what this para is saying. >>=20 >> -"IRS"- you may want to select a different acronym that isn't related >> to something as unpopular as taxation (something we learned with AMT). >> Maybe >> RSI instead... >>=20 >> Overall, I found the doc to be clearly written and straightforward. >> Sounds like Openflow for routers. Not sure if it's intentional that=20 >> you didn't mention Openflow, but it did seem like an elephant in the=20 >> room as I was reading thru. Also, I did wonder what was new and=20 >> novel here, as this sounded like our SDK which has been around for=20 >> years. >>=20 >>=20 >> -Lenny >=20 > _______________________________________________ > 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 > _______________________________________________ > irs-discuss mailing list > irs-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/irs-discuss >=20 Return-Path: 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 372DD21F86F3 for ; Thu, 9 Aug 2012 09:38:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.203 X-Spam-Level: X-Spam-Status: No, score=-1.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hrjinttAJVdn for ; Thu, 9 Aug 2012 09:38:21 -0700 (PDT) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id 1412C21F86EA for ; Thu, 9 Aug 2012 09:38:20 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by lucidvision.com (Postfix) with ESMTP id 6DBF42240CB8; Thu, 9 Aug 2012 12:38:19 -0400 (EDT) X-Virus-Scanned: amavisd-new at www.lucidvision.com Received: from lucidvision.com ([127.0.0.1]) by localhost (static-72-71-250-34.cncdnh.fios.verizon.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gCoPqaYuvuCE; Thu, 9 Aug 2012 12:38:19 -0400 (EDT) Received: from [10.45.10.199] (unknown [166.137.86.226]) by lucidvision.com (Postfix) with ESMTP id AA0342240CB5; Thu, 9 Aug 2012 12:38:18 -0400 (EDT) References: <812700A304640D4292205D5E83FC59E1061C211D@p-embx01-eq.jnpr.net> <728F9B956B2C48439CA9294B1723B14623757671@dfweml509-mbs.china.huawei.com> In-Reply-To: <728F9B956B2C48439CA9294B1723B14623757671@dfweml509-mbs.china.huawei.com> Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: <7441EA0C-2DB0-4B68-AD04-0F556CD1BE2E@lucidvision.com> X-Mailer: iPhone Mail (9B206) From: Thomas Nadeau Date: Thu, 9 Aug 2012 12:38:12 -0400 To: Susan Hares Cc: Thomas Nadeau , Gert Grammel , Alia Atlas , Lenny Giuliano , "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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Aug 2012 16:38:22 -0000 We intended for irs to need both read and write capabilities, hence our use o= f "bidirectional" in describing the interface characteristics in the problem= statement. One big difference between existing "network management" and wh= at we are trying to specify now is real-time transactional capabilities. Tom=20 On Aug 9, 2012, at 10:57 AM, Susan Hares wrote: > Gert: >=20 > How do you characterize network management? Traditionally network managem= ent has been viewed in the IETF in two streams: monitoring (active or passi= ve) and configuration. =20 >=20 > What parts of these features do you think the IRS system needs to avoid?=20= >=20 > Sue=20 >=20 > -----Original Message----- > From: irs-discuss-bounces@ietf.org [mailto:irs-discuss-bounces@ietf.org] O= n Behalf Of Gert Grammel > Sent: Monday, July 30, 2012 6:41 PM > To: Thomas Nadeau; Lenny Giuliano; Alia Atlas > Cc: irs-discuss@ietf.org > Subject: Re: [irs-discuss] IRS comments >=20 > Tom, >=20 > It is confusing to understand whether IRS belongs to a new network managem= ent plane or if it's more of a control plane extension. The draft wisely avo= ids this classification. > To me IRS appears to be a completely different beast which should best be = characterized as 'Network Programming Plane' NPP.=20 > It neither aims to do full provisioning (as a management plane would do) n= or aims to replace routing (as a control plane would do). > Hence we better name the baby NPP -- thereby avoiding any linkage to taxat= ion. >=20 >=20 > Gert >=20 >=20 >=20 >=20 > ----- Original Message ----- > From: irs-discuss-bounces@ietf.org > To: Lenny Giuliano; Alia Atlas > Cc: irs-discuss@ietf.org > Sent: Tue Jul 31 01:50:40 2012 > Subject: Re: [irs-discuss] IRS comments >=20 >=20 > [Re-adding IRS] >=20 > Thank you for reviewing and the comments. We will incorporate the edits= > in the next rev. >=20 > --Tom >=20 >=20 > On 7/30/12 5:04 PM, "Lenny Giuliano" wrote: >=20 >>=20 >> Minor points: >>=20 >> -section 4, para 2, 3rd sentence, "Howeve,r" >>=20 >> -4.1.3 "There is no bidirectional programmatic interface to add, modify, >> remove or read state from the multicast RIB." >> -How is this unique to mcast? Couldn't you say the same thing >> about unicast? >>=20 >> -4.1.3 "The multicast state added need not match to well-known protocol >> installed state. For instance, traffic received on an specified set, >> or all, interfaces that is destined to a particular prefix from all >> sources or a particular prefix could be subject to the specified >> replication." >> -Not clear to me at all what this para is saying. >>=20 >> -"IRS"- you may want to select a different acronym that isn't related to >> something as unpopular as taxation (something we learned with AMT). >> Maybe=20 >> RSI instead... >>=20 >> Overall, I found the doc to be clearly written and straightforward. >> Sounds like Openflow for routers. Not sure if it's intentional that you >> didn't mention Openflow, but it did seem like an elephant in the room as >> I=20 >> was reading thru. Also, I did wonder what was new and novel here, as >> this=20 >> sounded like our SDK which has been around for years. >>=20 >>=20 >> -Lenny >=20 > _______________________________________________ > 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 > _______________________________________________ > irs-discuss mailing list > irs-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/irs-discuss >=20 Return-Path: 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 216D621F87AA; Thu, 9 Aug 2012 08:59:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.19 X-Spam-Level: X-Spam-Status: No, score=-6.19 tagged_above=-999 required=5 tests=[AWL=-0.191, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ayl4Gl3KJN+l; Thu, 9 Aug 2012 08:58:56 -0700 (PDT) Received: from exprod7og117.obsmtp.com (exprod7og117.obsmtp.com [64.18.2.6]) by ietfa.amsl.com (Postfix) with ESMTP id D399E21F8795; Thu, 9 Aug 2012 08:58:34 -0700 (PDT) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob117.postini.com ([64.18.6.12]) with SMTP ID DSNKUCPeKB6yJoiQFLOdNyb8sRcVlkfKwFOz@postini.com; Thu, 09 Aug 2012 08:58:53 PDT Received: from ubuntu (172.23.6.234) by P-EMHUB01-HQ.jnpr.net (172.24.192.33) with Microsoft SMTP Server id 8.3.213.0; Thu, 9 Aug 2012 08:57:42 -0700 Received: by ubuntu (Postfix, from userid 1000) id 979512B2D6; Thu, 9 Aug 2012 17:57:45 +0200 (CEST) Date: Thu, 9 Aug 2012 17:57:45 +0200 From: Hannes Gredler To: Greg Bernstein Message-ID: <20120809155745.GA27488@juniper.net> References: <501B0D75.4090009@raszuk.net> <7E89A05A-CE4E-4FCF-81AB-8F39B42FBF8E@cisco.com> <501C128D.10809@cs.yale.edu> <501C2047.1000100@bell-labs.com> <501C3999.3080804@cs.yale.edu> <5023DB7D.9010803@grotto-networking.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <5023DB7D.9010803@grotto-networking.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: idr@ietf.org, Volker Hilt , irs-discuss@ietf.org, James Kempf , IETF ALTO , Alia Atlas Subject: Re: [irs-discuss] [Idr] [alto] About ALTO, BGP-LS, IRS X-BeenThere: irs-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Aug 2012 15:59:00 -0000 hi greg, see comments inline prefixed by HG> On Thu, Aug 09, 2012 at 08:47:09AM -0700, Greg Bernstein wrote: | Some questions and comments on IRS, IDR, and ALTO... | | Would IRS apply to GMPLS controlled boxes such as TDM (G.709, SDH) or WDM | (WSON) network elements? | Setting state in a GMPLS controlled box can be rather trivial, i.e., just | setting up a cross connect. The penalties for screwing up the state in a WDM | box are rather terrible... Would IRS want state for all the LSP's traversing a | box? | | I'm a infrastructure plumber and trying to get folks to use the nifty optical | control plane more. In GMPLS we have technology specific data models (SDH, | G.709, WSON) that are fairly independent of specific routing protocols (OSPF, | IS-IS) so these can help with the modeling aspect of IRS.  However, in the | early days of GMPLS folks thought everything should be done in the same IGP | instance, later the OSPF folks decided multiple instances were better since the | service impacts of routing protocols is much different for circuit switched | technologies than IP. | | The model we are interested for in large-bandwidth use-cases in ALTO tries to | abstract away as many layers as possible.  For example, suppose that the use- | case is to set up a large IP pipe between mulitple data centers.  We could show | an abstracted graph that helps guide paths choices via costs and bandwidth | constraints.  The actual implementation technology could be IP-MPLS-G.709-MPLS- | IP  or IP-OpenFlow-WSON-OpenFlow-IP  (here I just mean a simple OpenFlow | controlled Ethernet switch that that can feed into our optical "express lane"). | | In other cases the data centers might want some special ethernet connectivity | over optical pipes (a different type of service). | | When I think of an IDR and sharing information between ASs then one may want to | (or need to) keep (sub-IP) layer specific for compatibility, i.e., connecting | the pipes between domains and adapting the higher layer protocols back out.  | It's useful to look at publicly available service maps for examples, I like | Level3's maps (http://maps.level3.com/default/#.UCFpjJYu9rh) --compare | wavelength services to other services -- and CenturyLink (http:// | www.centurylink-business.com/demos/network-maps.html) -- note how wavelength | service availability is limited compared to other services (our big pipe | networks are generally simpler than other service networks) --. | | It seems what BGP-LS would deliver to an ALTO server to digest and serve up in | abstracted form could be very different from what might be shared between | ASes.   HG> BGP-LS feeding an L3 routing topology into an ALTO server is one particular application of the protocol. as you may have noticed the encoding of the link entries in BGP-LS is a superset of all IGP extensions most notably including the MI (multiple instance) drafts. as such one could carry higher or lower-layer graphs (e.g. graphs of application clusters / graphs of DWDM wavelengths). sicne you are concerened about optical gear feel free to send text on the GMPLS link attributes that you would like to have supported. | On 8/3/2012 4:57 PM, Alia Atlas wrote: | I strongly agree that we need to start collecting the use-cases for | multiple abstraction levels as well as physical/virtual/private. | Alia | On Aug 3, 2012 4:51 PM, "Y. Richard Yang" wrote: | Hi Volker, | | On 8/3/12 12:02 PM, Volker Hilt wrote: | | I believe that the capability to provide a | simplified view on the network topology to an | application is a key feature rather than a bug. | Applications that want to have a view on network | topology don't need need a fine grained view on | the topology in most casts and benefit from | having an abstracted view. This will simplify | processing for the application and enables | providers to control the exposure of details. | Agreed. | | We've seen some numbers for topology data sizes | in the incremental updates presentation in the | ALTO meeting, which provide some insights into | the amounts of data needed for different topology | sizes. | | I like the idea of enabling an ALTO server to | offer different levels of details. This will | enable a server to tailor responses to the | specific client. It will add complexity as the | ALTO server itself will have to maintain the most | complex topology it is offering and will have to | keep this topology up to date. But this is an | interesting question for discussion in the WG. | | Glad that you also like the idea of different levels of | details of the network topology. If the ALTO Server is | given a detailed topology (constructed from multiple | sources, such as routing feed, LSP feed, configuration | files), we can offer multiple topology operators/ | aggregators to explore the detailed topology, according to | need and policy. A simple example operator is level (i.e., | hierarchy such as at the area level), but one might specify | other operators (e.g., fisheye focus). There are studies on | representation of multi-level graphs that we can try to | take advantage of. This can be a subject for the group to | explore. | | We may need to study/collect use cases for multiple level | topology. One interesting example immediately coming to | mind is the Abstract Node concept (specify IP prefix/ASN) | used in RSVP-TE. | | Cheers, | | Richard | | Cheers, | | Volker | | | | | | | | On 03.08.2012 11:03, Y. Richard Yang wrote: | Hi Stefano, | | Good post! I added the ALTO mailing | list, given the relevance. I hope | that this is OK cross posting. | | First, a few comments on ALTO: | | View granularity: | | - ALTO currently defines two abstract | network topology data structures: | Network Map and Cost Map(s). More link- | state oriented maps (graphs), | with aggregations and transformations, | can be added efficiently to ALTO. | Some initial efforts are already on the | way (e.g., see the graph | representation proposal at page 9: | http://www.ietf.org/proceedings/84/ | slides/slides-84-alto-1.pdf). Hence, | I see a natural next-step is for ALTO | to provide a link-state view to | external entities. | | - It is a good comment on the level of | details that ALTO should | delivery. This is a good question for | the ALTO working group and the | community to discuss. I feel that ALTO | should provide multi-levels of | granularity of views, and we should | discuss in the working group. | | Pull vs push delivery mechanism: | | - There are more discussions on adding | the incremental update in ALTO. | Multiple mechanisms have been | discussed. I feel that it is the right | direction for ALTO. | | Now let me understand the deployment | model of BGP-LS. Your explanation | on the issues of acquiring routing | state is excellent. Let me start by | understanding more details on the | deployment model of BGP-LS inside a | network: | | - A set N_igp of BGP-LS instances are | deployed to collect IGP info. You | need multiple instances because IGP | needs direct connectivity | (adjacency). Each instance here | receives (potentially multiple) IGP | updates and streams (relays) to an | another (remote) entity, which I | assume is a master BGP-LS instance. So | each of these N_igp instances is | IGP-in and BGP-LS out. This appears to | be shown in Figure 1 of | draft-gredler-idr-ls-distribution. | | - A set N_egp of BGP-LS instances are | deployed to collect BGP feeds. You | also may need multiple instances | because the network does not want to | see aggregated states but raw states. | These instances will feed to the | master BGP-LS as well. | | - The master BGP-LS aggregates the | multiple BGP-LS ins (and maybe some | direct IGP/EGP ins) and pushes (after | policy) to other BGP-LS peers to | use: for example, an ALTO Server | transforms/aggregates the feed to | generate ALTO views (maps and graphs), | and an PCE uses the feed to | maintain its TED. One could even | imagine that ALTO builds a detailed TED | and feeds to PCE, but this beyond the | scope of this discussion. The | master BGP-LS is BGP-LS in and BGP-LS | out. It is also possible that the | master BGP-LS does not push to any | other entities and simply maintains | an internal DB for others to query. | | Do I understand it correctly? | | Now, we can take a look at more | specifics of BGP-LS. | | A first perspective is the semantics of | the content. If the objective is | to solve the aforementioned deployment | issue, then an alternative | solution is to introduce a simple LS | update tunneling protocol, where a | link-state proxy forwards LS messages | to a collector. The current design | of BGP-LS starts with such a feeling | (i.e., an NLRI starts with the | Protocol ID, which indicates it is from | IS-IS level 1 IS-IS level 2, | OSPF, etc). However, the protocol | appears to (try to) go beyond simple | tunneling and introduces a common LS | schema, by converting/filtering | individual IGP LS messages to some | common format. I feel that it can be | helpful to first specify the schema (LS | data model) instead of the | specific encoding. For example, OSPF | specifies LS Age, and this is | filtered. (Please correct me if I | missed it). On the other hand, one can | think that some Age info can be helpful | for one to understand the | "freshness" of the LS. A problem | studied in database is heterogeneous | databases, to merge multiple data | sources (IS-IS, OSPF, etc) to a single | schema, and there can be many problems. | If there is such a study, please | do share a pointer. | | A second perspective is using BGP as | the transport. What key features | from BGP do we really need (yes, weak- | typed TLV encoding offers a lot of | flexibility)? What features of BGP do | we not need (e.g., BGP is a | routing protocol and hence builds in | features to handle convergence such | as dampening)? What may be missing | (e.g., a capability of pull or | filtering of push). I feel that these | issues should be discussed. If | they have already been discussed, | please do share a pointer, as I am | definitely a new comer. | | Thanks! | | Richard | | On 8/2/12 11:54 PM, stefano previdi | wrote: | All, | | as co-author of both BGP-LS | and ALTO drafts, I'd try to | clarify a few | things: | | ALTO has been designed in | order to deliver to | applications (through | http/json): | | 1. two maps representing the | network topology in an | abstracted view | (or set of views through | multiple maps). The map does | not include | the details of a link-state | database and therefore have | little use | for any element that would | need to retrieve from the | network the | detailed/complete network | layer topology, for example: | link | addresses or link BW | resources, etc. IOW: ALTO | maps do not have | the granularity of a link- | state database and ALTO | protocol is not | designed to deliver such | details. | | and/or | | 2. Ranking services where a | client sends a bunch of IP | addresses in | a message and the ALTO server | replies by ranking these | addresses | based on their topological/ | network distance (or whatever | criteria | the ALTO server has been | configured for). This is | called: Endpoint | Cost Service. | | When using ALTO maps, and the | ALTO protocol being http/pull | based, | there's no such concept of | unsolicited routing updates. | An ALTO | client is typically a browser | that will pull the maps from | an ALTO | server using http. The ALTO | server will make no effort to | ensure the | client has the latest view of | the topology (i.e.: It's the | role of the | client to poll for new maps | time to time). | | Now, in order for an ALTO | server to deliver Maps or | Ranking services, | it needs to build some form | of topology and in order to | achieve this, | it needs somehow to be fed by | either the operator | (configuration) or | to receive dynamically | topology information from the | network (e.g.: | ISIS/OSPF/BGP). | | Here we had two options: | 1. ALTO server to implement | ISIS/OSPF/BGP and establish | IGP adjacencies | to ABRs or L1L2 routers in | each area so to retrieve the | LSDB from | each area. In practice I know | no SP willing/accepting to | open their | IGP to an ALTO server. Also, | IGP requires direct | connectivity | (adjacency) so from an | operation point of view is | complex and not | desired. | 2. Use a database | distribution protocol running | on top of a reliable | transport layer that would | allow an ALTO server to | connect to a | _single_ and _remote_ Route | Reflector (i.e.: no need to | be directly | connected) and grab the whole | network topology that will be | updated | using standard routing | protocol mechanisms (i.e.: | routing updates) | and that would allow the | operator to control (through | policies and | filters) what to distribute | and to which server. | | Benefits: single (or dual at | most for redundancy) | connection for | the ALTO server (rather than | having a direct adjacency | with each | ABR) and, from the operator | perspective, single point of | distribution of network | topology (easier to apply | policies and | control what you deliver). | This is what BGP-LS is about. | | BGP-LS defines new AFI/SAFI | for a new NLRI and attributes | that convey | link-state and, more | generically, any type of | topology information. | The draft specifies NLRI and | attributes that map whatever | you can | find in a link-state | database. | | We currently have draft- | gredler-idr-ls-distribution | in the process | (hopefully) to be adopted as | WG item in IDR WG (so far we | 're getting | good support). We also have 3 | implementations of BGP-LS. | | Deployment-wise: BGP-LS is | not yet deployed, however, we | already have | deployments (I know at least | two) where an ALTO server | retrieves IP | prefix information from | remote BGP RRs (for ipv4). | The same scheme | will be used once BGP-LS will | be deployed (so to say that | it is not | something that we invented | after a couple of beers but | corresponds to | requirements for delivering | network services to upper | layers while | still controlling efficiently | what you distribute, to whom | and in | which form (note that, often, | beers are anyway part of the | process). | | More information here: | http://tools.ietf.org/html/ | draft-gredler-idr-ls- | distribution-02 | http://tools.ietf.org/html/ | draft-ietf-alto-protocol-12 | | Hope this helps. | | s. | | | | On Aug 3, 2012, at 1:29 AM, | Robert Raszuk wrote: | Tom, | | I agree | that one | of the top | work items | for this | effort | should be | a | standardized | topology | function, | and one | that is | accessible | via a | non- | routing | protocol. | So if the | requirement is to | have topology | export via non- | routing | protocol then I | think we should | seriously revisit | or repackage the | draft-gredler-idr- | ls-distribution-01 | which works for for | both OSPF | and ISIS. | | However before that | let's really | understand the | requirement why it | must be exported | via non-routing | protocol .... Keep | in mind that just | to parse BGP UPDATE | messages and | retrieve | interesting pieces | out it | it requires very | little code rather | then full BGP | implementation. | | The particular | feature I like | about | draft-gredler-idr- | ls-distribution-01 | is that it is read- | only ;) | | R. | | I agree | that one | of the top | work items | for this | effort | should be | a | standardized | topology | function, | and one | that is | accessible | via a | non- | routing | protocol. | While not | exactly | "low | hanging | fruit", it | is | something | that (to | me) is a | clear work | item with | clear | goals that | should | be tackled | straight | away. | | --Tom | | | | On 8/2/12 | 3:24 PM, | "James | Kempf" | | wrote: | | So | after | seeing | part | of | Alia's | talk | this | morning | (I | had | to | leave | in | the | middle | unfortunately), | I'd | like | to | make | a | couple | suggestions. | There | were | a lot | of | ideas | presented | in | the | talk, | enough | for | an | entire | IETF | Area. | I | think | to | make | tangible | progress, | the | work | needs | to be | focussed | on a | small | subset | that | would | be of | immediate | interest | and | usability. | | There | are a | couple | areas | that | suggest | themselves, | but | one | that | would | be | useful | in | work | that | I've | been | involved | in is | a | standardized | format | for | network | topology | representation | and a | protocol | for | exchanging | it. | The | Onix | OpenFlow | controller | has a | network | information | base | with | a | specialized | format | for | network | topology, | and | every | OpenFlow | controller | requires | this. | Having | a | standardized | way | to | represent | it | might | foster | a | common | topology | database | package. | Another | application | is | network | management. | Every | network | management | system | needs | some | kind | of | topology | representation. | Finally, | though | I am | not | an | expert | in | PCE | construction, | it | would | seem | to me | that | a PCE | would | need | some | kind | of | topology | representation | in | order | to | perform | path | calculations. | Having | a | way,for | example, | for | the | OpenFlow | controller | and | the | PCE | to | exchange | topology | information | would | be | really | useful. | I | would | say | to | start | with | physical | topology | because | that | is | fundamental, | but | make | the | format | flexible | enough | to | support | virtual | topology | representation. | | jak | _______________________________________________ | 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 | | | _______________________________________________ | 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 | | _______________________________________________ | 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 | | | _______________________________________________ | alto mailing list | alto@ietf.org | https://www.ietf.org/mailman/listinfo/alto | | | -- | =================================================== | Dr Greg Bernstein, Grotto Networking (510) 573-2237 | _______________________________________________ | Idr mailing list | Idr@ietf.org | https://www.ietf.org/mailman/listinfo/idr Return-Path: 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 5BC3B21F87AB; Thu, 9 Aug 2012 08:47:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.615 X-Spam-Level: X-Spam-Status: No, score=-1.615 tagged_above=-999 required=5 tests=[AWL=0.383, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_33=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BQEICb0rqvOD; Thu, 9 Aug 2012 08:47:17 -0700 (PDT) Received: from smtp.webfaction.com (mail6.webfaction.com [74.55.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 7DC7721F87AA; Thu, 9 Aug 2012 08:47:17 -0700 (PDT) Received: from [192.168.0.124] (c-67-170-243-110.hsd1.ca.comcast.net [67.170.243.110]) by smtp.webfaction.com (Postfix) with ESMTP id 5E096213ED44; Thu, 9 Aug 2012 10:47:15 -0500 (CDT) Message-ID: <5023DB7D.9010803@grotto-networking.com> Date: Thu, 09 Aug 2012 08:47:09 -0700 From: Greg Bernstein User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: Alia Atlas References: <501B0D75.4090009@raszuk.net> <7E89A05A-CE4E-4FCF-81AB-8F39B42FBF8E@cisco.com> <501C128D.10809@cs.yale.edu> <501C2047.1000100@bell-labs.com> <501C3999.3080804@cs.yale.edu> In-Reply-To: Content-Type: multipart/alternative; boundary="------------080100050901050805090804" Cc: idr@ietf.org, Volker Hilt , irs-discuss@ietf.org, James Kempf , IETF ALTO , "Y. Richard Yang" Subject: Re: [irs-discuss] [alto] About ALTO, BGP-LS, IRS X-BeenThere: irs-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Aug 2012 15:47:20 -0000 This is a multi-part message in MIME format. --------------080100050901050805090804 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Some questions and comments on IRS, IDR, and ALTO... Would IRS apply to GMPLS controlled boxes such as TDM (G.709, SDH) or WDM (WSON) network elements? Setting state in a GMPLS controlled box can be rather trivial, i.e., just setting up a cross connect. The penalties for screwing up the state in a WDM box are rather terrible... Would IRS want state for all the LSP's traversing a box? I'm a infrastructure plumber and trying to get folks to use the nifty optical control plane more. In GMPLS we have technology specific data models (SDH, G.709, WSON) that are fairly independent of specific routing protocols (OSPF, IS-IS) so these can help with the modeling aspect of IRS. However, in the early days of GMPLS folks thought everything should be done in the same IGP instance, later the OSPF folks decided multiple instances were better since the service impacts of routing protocols is much different for circuit switched technologies than IP. The model we are interested for in large-bandwidth use-cases in ALTO tries to abstract away as many layers as possible. For example, suppose that the use-case is to set up a large IP pipe between mulitple data centers. We could show an abstracted graph that helps guide paths choices via costs and bandwidth constraints. The actual implementation technology could be IP-MPLS-G.709-MPLS-IP or IP-OpenFlow-WSON-OpenFlow-IP (here I just mean a simple OpenFlow controlled Ethernet switch that that can feed into our optical "express lane"). In other cases the data centers might want some special ethernet connectivity over optical pipes (a different type of service). When I think of an IDR and sharing information between ASs then one may want to (or need to) keep (sub-IP) layer specific for compatibility, i.e., connecting the pipes between domains and adapting the higher layer protocols back out. It's useful to look at publicly available service maps for examples, I like Level3's maps (http://maps.level3.com/default/#.UCFpjJYu9rh) --compare wavelength services to other services -- and CenturyLink (http://www.centurylink-business.com/demos/network-maps.html) -- note how wavelength service availability is limited compared to other services (our big pipe networks are generally simpler than other service networks) --. It seems what BGP-LS would deliver to an ALTO server to digest and serve up in abstracted form could be very different from what might be shared between ASes. Cheers Greg On 8/3/2012 4:57 PM, Alia Atlas wrote: > > I strongly agree that we need to start collecting the use-cases for > multiple abstraction levels as well as physical/virtual/private. > > Alia > > On Aug 3, 2012 4:51 PM, "Y. Richard Yang" > wrote: > > Hi Volker, > > On 8/3/12 12:02 PM, Volker Hilt wrote: > > > I believe that the capability to provide a simplified view on > the network topology to an application is a key feature rather > than a bug. Applications that want to have a view on network > topology don't need need a fine grained view on the topology > in most casts and benefit from having an abstracted view. This > will simplify processing for the application and enables > providers to control the exposure of details. > > Agreed. > > We've seen some numbers for topology data sizes in the > incremental updates presentation in the ALTO meeting, which > provide some insights into the amounts of data needed for > different topology sizes. > > I like the idea of enabling an ALTO server to offer different > levels of details. This will enable a server to tailor > responses to the specific client. It will add complexity as > the ALTO server itself will have to maintain the most complex > topology it is offering and will have to keep this topology up > to date. But this is an interesting question for discussion in > the WG. > > Glad that you also like the idea of different levels of details of > the network topology. If the ALTO Server is given a detailed > topology (constructed from multiple sources, such as routing feed, > LSP feed, configuration files), we can offer multiple topology > operators/aggregators to explore the detailed topology, according > to need and policy. A simple example operator is level (i.e., > hierarchy such as at the area level), but one might specify other > operators (e.g., fisheye focus). There are studies on > representation of multi-level graphs that we can try to take > advantage of. This can be a subject for the group to explore. > > We may need to study/collect use cases for multiple level > topology. One interesting example immediately coming to mind is > the Abstract Node concept (specify IP prefix/ASN) used in RSVP-TE. > > Cheers, > > Richard > > Cheers, > > Volker > > > > > > > > On 03.08.2012 11:03, Y. Richard Yang wrote: > > Hi Stefano, > > Good post! I added the ALTO mailing list, given the > relevance. I hope > that this is OK cross posting. > > First, a few comments on ALTO: > > View granularity: > > - ALTO currently defines two abstract network topology > data structures: > Network Map and Cost Map(s). More link-state oriented maps > (graphs), > with aggregations and transformations, can be added > efficiently to ALTO. > Some initial efforts are already on the way (e.g., see the > graph > representation proposal at page 9: > http://www.ietf.org/proceedings/84/slides/slides-84-alto-1.pdf). > Hence, > I see a natural next-step is for ALTO to provide a > link-state view to > external entities. > > - It is a good comment on the level of details that ALTO > should > delivery. This is a good question for the ALTO working > group and the > community to discuss. I feel that ALTO should provide > multi-levels of > granularity of views, and we should discuss in the working > group. > > Pull vs push delivery mechanism: > > - There are more discussions on adding the incremental > update in ALTO. > Multiple mechanisms have been discussed. I feel that it is > the right > direction for ALTO. > > Now let me understand the deployment model of BGP-LS. Your > explanation > on the issues of acquiring routing state is excellent. Let > me start by > understanding more details on the deployment model of > BGP-LS inside a > network: > > - A set N_igp of BGP-LS instances are deployed to collect > IGP info. You > need multiple instances because IGP needs direct connectivity > (adjacency). Each instance here receives (potentially > multiple) IGP > updates and streams (relays) to an another (remote) > entity, which I > assume is a master BGP-LS instance. So each of these N_igp > instances is > IGP-in and BGP-LS out. This appears to be shown in Figure 1 of > draft-gredler-idr-ls-distribution. > > - A set N_egp of BGP-LS instances are deployed to collect > BGP feeds. You > also may need multiple instances because the network does > not want to > see aggregated states but raw states. These instances will > feed to the > master BGP-LS as well. > > - The master BGP-LS aggregates the multiple BGP-LS ins > (and maybe some > direct IGP/EGP ins) and pushes (after policy) to other > BGP-LS peers to > use: for example, an ALTO Server transforms/aggregates the > feed to > generate ALTO views (maps and graphs), and an PCE uses the > feed to > maintain its TED. One could even imagine that ALTO builds > a detailed TED > and feeds to PCE, but this beyond the scope of this > discussion. The > master BGP-LS is BGP-LS in and BGP-LS out. It is also > possible that the > master BGP-LS does not push to any other entities and > simply maintains > an internal DB for others to query. > > Do I understand it correctly? > > Now, we can take a look at more specifics of BGP-LS. > > A first perspective is the semantics of the content. If > the objective is > to solve the aforementioned deployment issue, then an > alternative > solution is to introduce a simple LS update tunneling > protocol, where a > link-state proxy forwards LS messages to a collector. The > current design > of BGP-LS starts with such a feeling (i.e., an NLRI starts > with the > Protocol ID, which indicates it is from IS-IS level 1 > IS-IS level 2, > OSPF, etc). However, the protocol appears to (try to) go > beyond simple > tunneling and introduces a common LS schema, by > converting/filtering > individual IGP LS messages to some common format. I feel > that it can be > helpful to first specify the schema (LS data model) > instead of the > specific encoding. For example, OSPF specifies LS Age, and > this is > filtered. (Please correct me if I missed it). On the other > hand, one can > think that some Age info can be helpful for one to > understand the > "freshness" of the LS. A problem studied in database is > heterogeneous > databases, to merge multiple data sources (IS-IS, OSPF, > etc) to a single > schema, and there can be many problems. If there is such a > study, please > do share a pointer. > > A second perspective is using BGP as the transport. What > key features > from BGP do we really need (yes, weak-typed TLV encoding > offers a lot of > flexibility)? What features of BGP do we not need (e.g., > BGP is a > routing protocol and hence builds in features to handle > convergence such > as dampening)? What may be missing (e.g., a capability of > pull or > filtering of push). I feel that these issues should be > discussed. If > they have already been discussed, please do share a > pointer, as I am > definitely a new comer. > > Thanks! > > Richard > > On 8/2/12 11:54 PM, stefano previdi wrote: > > All, > > as co-author of both BGP-LS and ALTO drafts, I'd try > to clarify a few > things: > > ALTO has been designed in order to deliver to > applications (through > http/json): > > 1. two maps representing the network topology in an > abstracted view > (or set of views through multiple maps). The map does > not include > the details of a link-state database and therefore > have little use > for any element that would need to retrieve from the > network the > detailed/complete network layer topology, for example: > link > addresses or link BW resources, etc. IOW: ALTO maps do > not have > the granularity of a link-state database and ALTO > protocol is not > designed to deliver such details. > > and/or > > 2. Ranking services where a client sends a bunch of IP > addresses in > a message and the ALTO server replies by ranking these > addresses > based on their topological/network distance (or > whatever criteria > the ALTO server has been configured for). This is > called: Endpoint > Cost Service. > > When using ALTO maps, and the ALTO protocol being > http/pull based, > there's no such concept of unsolicited routing > updates. An ALTO > client is typically a browser that will pull the maps > from an ALTO > server using http. The ALTO server will make no effort > to ensure the > client has the latest view of the topology (i.e.: It's > the role of the > client to poll for new maps time to time). > > Now, in order for an ALTO server to deliver Maps or > Ranking services, > it needs to build some form of topology and in order > to achieve this, > it needs somehow to be fed by either the operator > (configuration) or > to receive dynamically topology information from the > network (e.g.: > ISIS/OSPF/BGP). > > Here we had two options: > 1. ALTO server to implement ISIS/OSPF/BGP and > establish IGP adjacencies > to ABRs or L1L2 routers in each area so to retrieve > the LSDB from > each area. In practice I know no SP willing/accepting > to open their > IGP to an ALTO server. Also, IGP requires direct > connectivity > (adjacency) so from an operation point of view is > complex and not > desired. > 2. Use a database distribution protocol running on top > of a reliable > transport layer that would allow an ALTO server to > connect to a > _single_ and _remote_ Route Reflector (i.e.: no need > to be directly > connected) and grab the whole network topology that > will be updated > using standard routing protocol mechanisms (i.e.: > routing updates) > and that would allow the operator to control (through > policies and > filters) what to distribute and to which server. > > Benefits: single (or dual at most for redundancy) > connection for > the ALTO server (rather than having a direct adjacency > with each > ABR) and, from the operator perspective, single point of > distribution of network topology (easier to apply > policies and > control what you deliver). This is what BGP-LS is about. > > BGP-LS defines new AFI/SAFI for a new NLRI and > attributes that convey > link-state and, more generically, any type of topology > information. > The draft specifies NLRI and attributes that map > whatever you can > find in a link-state database. > > We currently have draft-gredler-idr-ls-distribution in > the process > (hopefully) to be adopted as WG item in IDR WG (so far > we 're getting > good support). We also have 3 implementations of BGP-LS. > > Deployment-wise: BGP-LS is not yet deployed, however, > we already have > deployments (I know at least two) where an ALTO server > retrieves IP > prefix information from remote BGP RRs (for ipv4). The > same scheme > will be used once BGP-LS will be deployed (so to say > that it is not > something that we invented after a couple of beers but > corresponds to > requirements for delivering network services to upper > layers while > still controlling efficiently what you distribute, to > whom and in > which form (note that, often, beers are anyway part of > the process). > > More information here: > http://tools.ietf.org/html/draft-gredler-idr-ls-distribution-02 > http://tools.ietf.org/html/draft-ietf-alto-protocol-12 > > Hope this helps. > > s. > > > > On Aug 3, 2012, at 1:29 AM, Robert Raszuk wrote: > > Tom, > > I agree that one of the top work items for > this effort should be a > standardized topology function, and one that > is accessible via a > non-routing protocol. > > So if the requirement is to have topology export > via non-routing > protocol then I think we should seriously revisit > or repackage the > draft-gredler-idr-ls-distribution-01 which works > for for both OSPF > and ISIS. > > However before that let's really understand the > requirement why it > must be exported via non-routing protocol .... > Keep in mind that just > to parse BGP UPDATE messages and retrieve > interesting pieces out it > it requires very little code rather then full BGP > implementation. > > The particular feature I like about > draft-gredler-idr-ls-distribution-01 is that it is > read-only ;) > > R. > > I agree that one of the top work items for > this effort should be a > standardized topology function, and one that > is accessible via a > non-routing protocol. While not exactly "low > hanging fruit", it is > something that (to me) is a clear work item > with clear goals that > should > be tackled straight away. > > --Tom > > > > On 8/2/12 3:24 PM, "James Kempf" > > wrote: > > So after seeing part of Alia's talk this > morning (I had to leave in > the > middle unfortunately), I'd like to make a > couple suggestions. There > were > a lot of ideas presented in the talk, > enough for an entire IETF > Area. I > think to make tangible progress, the work > needs to be focussed on a > small > subset that would be of immediate interest > and usability. > > There are a couple areas that suggest > themselves, but one that > would be > useful in work that I've been involved in > is a standardized format for > network topology representation and a > protocol for exchanging it. The > Onix OpenFlow controller has a network > information base with a > specialized format for network topology, > and every OpenFlow controller > requires this. Having a standardized way > to represent it might > foster a > common topology database package. Another > application is network > management. Every network management > system needs some kind of > topology > representation. Finally, though I am not > an expert in PCE > construction, > it would seem to me that a PCE would need > some kind of topology > representation in order to perform path > calculations. Having a way,for > example, for the OpenFlow controller and > the PCE to exchange topology > information would be really useful. I > would say to start with physical > topology because that is fundamental, but > make the format flexible > enough > to support > virtual topology representation. > > jak > _______________________________________________ > 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 > > > _______________________________________________ > 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 > > > _______________________________________________ > 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 > > > > _______________________________________________ > alto mailing list > alto@ietf.org > https://www.ietf.org/mailman/listinfo/alto -- =================================================== Dr Greg Bernstein, Grotto Networking (510) 573-2237 --------------080100050901050805090804 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Some questions and comments on IRS, IDR, and ALTO...

Would IRS apply to GMPLS controlled boxes such as TDM (G.709, SDH) or WDM (WSON) network elements?
Setting state in a GMPLS controlled box can be rather trivial, i.e., just setting up a cross connect. The penalties for screwing up the state in a WDM box are rather terrible... Would IRS want state for all the LSP's traversing a box?

I'm a infrastructure plumber and trying to get folks to use the nifty optical control plane more. In GMPLS we have technology specific data models (SDH, G.709, WSON) that are fairly independent of specific routing protocols (OSPF, IS-IS) so these can help with the modeling aspect of IRS.  However, in the early days of GMPLS folks thought everything should be done in the same IGP instance, later the OSPF folks decided multiple instances were better since the service impacts of routing protocols is much different for circuit switched technologies than IP.

The model we are interested for in large-bandwidth use-cases in ALTO tries to abstract away as many layers as possible.  For example, suppose that the use-case is to set up a large IP pipe between mulitple data centers.  We could show an abstracted graph that helps guide paths choices via costs and bandwidth constraints.  The actual implementation technology could be IP-MPLS-G.709-MPLS-IP  or IP-OpenFlow-WSON-OpenFlow-IP  (here I just mean a simple OpenFlow controlled Ethernet switch that that can feed into our optical "express lane").
In other cases the data centers might want some special ethernet connectivity over optical pipes (a different type of service).

When I think of an IDR and sharing information between ASs then one may want to (or need to) keep (sub-IP) layer specific for compatibility, i.e., connecting the pipes between domains and adapting the higher layer protocols back out.  It's useful to look at publicly available service maps for examples, I like Level3's maps (http://maps.level3.com/default/#.UCFpjJYu9rh) --compare wavelength services to other services -- and CenturyLink (http://www.centurylink-business.com/demos/network-maps.html) -- note how wavelength service availability is limited compared to other services (our big pipe networks are generally simpler than other service networks) --.

It seems what BGP-LS would deliver to an ALTO server to digest and serve up in abstracted form could be very different from what might be shared between ASes.  

Cheers
Greg


On 8/3/2012 4:57 PM, Alia Atlas wrote:

I strongly agree that we need to start collecting the use-cases for multiple abstraction levels as well as physical/virtual/private.

Alia

On Aug 3, 2012 4:51 PM, "Y. Richard Yang" <yry@cs.yale.edu> wrote:
Hi Volker,

On 8/3/12 12:02 PM, Volker Hilt wrote:

I believe that the capability to provide a simplified view on the network topology to an application is a key feature rather than a bug. Applications that want to have a view on network topology don't need need a fine grained view on the topology in most casts and benefit from having an abstracted view. This will simplify processing for the application and enables providers to control the exposure of details.
Agreed.

We've seen some numbers for topology data sizes in the incremental updates presentation in the ALTO meeting, which provide some insights into the amounts of data needed for different topology sizes.

I like the idea of enabling an ALTO server to offer different levels of details. This will enable a server to tailor responses to the specific client. It will add complexity as the ALTO server itself will have to maintain the most complex topology it is offering and will have to keep this topology up to date. But this is an interesting question for discussion in the WG.

Glad that you also like the idea of different levels of details of the network topology. If the ALTO Server is given a detailed topology (constructed from multiple sources, such as routing feed, LSP feed, configuration files), we can offer multiple topology operators/aggregators to explore the detailed topology, according to need and policy. A simple example operator is level (i.e., hierarchy such as at the area level), but one might specify other operators (e.g., fisheye focus). There are studies on representation of multi-level graphs that we can try to take advantage of. This can be a subject for the group to explore.

We may need to study/collect use cases for multiple level topology. One interesting example immediately coming to mind is the Abstract Node concept (specify IP prefix/ASN) used in RSVP-TE.

Cheers,

Richard

Cheers,

Volker







On 03.08.2012 11:03, Y. Richard Yang wrote:
Hi Stefano,

Good post! I added the ALTO mailing list, given the relevance. I hope
that this is OK cross posting.

First, a few comments on ALTO:

View granularity:

- ALTO currently defines two abstract network topology data structures:
Network Map and Cost Map(s). More link-state oriented maps (graphs),
with aggregations and transformations, can be added efficiently to ALTO.
Some initial efforts are already on the way (e.g., see the graph
representation proposal at page 9:
http://www.ietf.org/proceedings/84/slides/slides-84-alto-1.pdf). Hence,
I see a natural next-step is for ALTO to provide a link-state view to
external entities.

- It is a good comment on the level of details that ALTO should
delivery. This is a good question for the ALTO working group and the
community to discuss. I feel that ALTO should provide multi-levels of
granularity of views, and we should discuss in the working group.

Pull vs push delivery mechanism:

- There are more discussions on adding the incremental update in ALTO.
Multiple mechanisms have been discussed. I feel that it is the right
direction for ALTO.

Now let me understand the deployment model of BGP-LS. Your explanation
on the issues of acquiring routing state is excellent. Let me start by
understanding more details on the deployment model of BGP-LS inside a
network:

- A set N_igp of BGP-LS instances are deployed to collect IGP info. You
need multiple instances because IGP needs direct connectivity
(adjacency). Each instance here receives (potentially multiple) IGP
updates and streams (relays) to an another (remote) entity, which I
assume is a master BGP-LS instance. So each of these N_igp instances is
IGP-in and BGP-LS out. This appears to be shown in Figure 1 of
draft-gredler-idr-ls-distribution.

- A set N_egp of BGP-LS instances are deployed to collect BGP feeds. You
also may need multiple instances because the network does not want to
see aggregated states but raw states. These instances will feed to the
master BGP-LS as well.

- The master BGP-LS aggregates the multiple BGP-LS ins (and maybe some
direct IGP/EGP ins) and pushes (after policy) to other BGP-LS peers to
use: for example, an ALTO Server transforms/aggregates the feed to
generate ALTO views (maps and graphs), and an PCE uses the feed to
maintain its TED. One could even imagine that ALTO builds a detailed TED
and feeds to PCE, but this beyond the scope of this discussion. The
master BGP-LS is BGP-LS in and BGP-LS out. It is also possible that the
master BGP-LS does not push to any other entities and simply maintains
an internal DB for others to query.

Do I understand it correctly?

Now, we can take a look at more specifics of BGP-LS.

A first perspective is the semantics of the content. If the objective is
to solve the aforementioned deployment issue, then an alternative
solution is to introduce a simple LS update tunneling protocol, where a
link-state proxy forwards LS messages to a collector. The current design
of BGP-LS starts with such a feeling (i.e., an NLRI starts with the
Protocol ID, which indicates it is from IS-IS level 1 IS-IS level 2,
OSPF, etc). However, the protocol appears to (try to) go beyond simple
tunneling and introduces a common LS schema, by converting/filtering
individual IGP LS messages to some common format. I feel that it can be
helpful to first specify the schema (LS data model) instead of the
specific encoding. For example, OSPF specifies LS Age, and this is
filtered. (Please correct me if I missed it). On the other hand, one can
think that some Age info can be helpful for one to understand the
"freshness" of the LS. A problem studied in database is heterogeneous
databases, to merge multiple data sources (IS-IS, OSPF, etc) to a single
schema, and there can be many problems. If there is such a study, please
do share a pointer.

A second perspective is using BGP as the transport. What key features
from BGP do we really need (yes, weak-typed TLV encoding offers a lot of
flexibility)? What features of BGP do we not need (e.g., BGP is a
routing protocol and hence builds in features to handle convergence such
as dampening)? What may be missing (e.g., a capability of pull or
filtering of push). I feel that these issues should be discussed. If
they have already been discussed, please do share a pointer, as I am
definitely a new comer.

Thanks!

Richard

On 8/2/12 11:54 PM, stefano previdi wrote:
All,

as co-author of both BGP-LS and ALTO drafts, I'd try to clarify a few
things:

ALTO has been designed in order to deliver to applications (through
http/json):

1. two maps representing the network topology in an abstracted view
(or set of views through multiple maps). The map does not include
the details of a link-state database and therefore have little use
for any element that would need to retrieve from the network the
detailed/complete network layer topology, for example: link
addresses or link BW resources, etc. IOW: ALTO maps do not have
the granularity of a link-state database and ALTO protocol is not
designed to deliver such details.

and/or

2. Ranking services where a client sends a bunch of IP addresses in
a message and the ALTO server replies by ranking these addresses
based on their topological/network distance (or whatever criteria
the ALTO server has been configured for). This is called: Endpoint
Cost Service.

When using ALTO maps, and the ALTO protocol being http/pull based,
there's no such concept of unsolicited routing updates. An ALTO
client is typically a browser that will pull the maps from an ALTO
server using http. The ALTO server will make no effort to ensure the
client has the latest view of the topology (i.e.: It's the role of the
client to poll for new maps time to time).

Now, in order for an ALTO server to deliver Maps or Ranking services,
it needs to build some form of topology and in order to achieve this,
it needs somehow to be fed by either the operator (configuration) or
to receive dynamically topology information from the network (e.g.:
ISIS/OSPF/BGP).

Here we had two options:
1. ALTO server to implement ISIS/OSPF/BGP and establish IGP adjacencies
to ABRs or L1L2 routers in each area so to retrieve the LSDB from
each area. In practice I know no SP willing/accepting to open their
IGP to an ALTO server. Also, IGP requires direct connectivity
(adjacency) so from an operation point of view is complex and not
desired.
2. Use a database distribution protocol running on top of a reliable
transport layer that would allow an ALTO server to connect to a
_single_ and _remote_ Route Reflector (i.e.: no need to be directly
connected) and grab the whole network topology that will be updated
using standard routing protocol mechanisms (i.e.: routing updates)
and that would allow the operator to control (through policies and
filters) what to distribute and to which server.

Benefits: single (or dual at most for redundancy) connection for
the ALTO server (rather than having a direct adjacency with each
ABR) and, from the operator perspective, single point of
distribution of network topology (easier to apply policies and
control what you deliver). This is what BGP-LS is about.

BGP-LS defines new AFI/SAFI for a new NLRI and attributes that convey
link-state and, more generically, any type of topology information.
The draft specifies NLRI and attributes that map whatever you can
find in a link-state database.

We currently have draft-gredler-idr-ls-distribution in the process
(hopefully) to be adopted as WG item in IDR WG (so far we 're getting
good support). We also have 3 implementations of BGP-LS.

Deployment-wise: BGP-LS is not yet deployed, however, we already have
deployments (I know at least two) where an ALTO server retrieves IP
prefix information from remote BGP RRs (for ipv4). The same scheme
will be used once BGP-LS will be deployed (so to say that it is not
something that we invented after a couple of beers but corresponds to
requirements for delivering network services to upper layers while
still controlling efficiently what you distribute, to whom and in
which form (note that, often, beers are anyway part of the process).

More information here:
http://tools.ietf.org/html/draft-gredler-idr-ls-distribution-02
http://tools.ietf.org/html/draft-ietf-alto-protocol-12

Hope this helps.

s.



On Aug 3, 2012, at 1:29 AM, Robert Raszuk wrote:
Tom,

I agree that one of the top work items for this effort should be a
standardized topology function, and one that is accessible via a
non-routing protocol.
So if the requirement is to have topology export via non-routing
protocol then I think we should seriously revisit or repackage the
draft-gredler-idr-ls-distribution-01 which works for for both OSPF
and ISIS.

However before that let's really understand the requirement why it
must be exported via non-routing protocol .... Keep in mind that just
to parse BGP UPDATE messages and retrieve interesting pieces out it
it requires very little code rather then full BGP implementation.

The particular feature I like about
draft-gredler-idr-ls-distribution-01 is that it is read-only ;)

R.

I agree that one of the top work items for this effort should be a
standardized topology function, and one that is accessible via a
non-routing protocol. While not exactly "low hanging fruit", it is
something that (to me) is a clear work item with clear goals that
should
be tackled straight away.

--Tom



On 8/2/12 3:24 PM, "James Kempf" <james.kempf@ericsson.com> wrote:

So after seeing part of Alia's talk this morning (I had to leave in
the
middle unfortunately), I'd like to make a couple suggestions. There
were
a lot of ideas presented in the talk, enough for an entire IETF
Area. I
think to make tangible progress, the work needs to be focussed on a
small
subset that would be of immediate interest and usability.

There are a couple areas that suggest themselves, but one that
would be
useful in work that I've been involved in is a standardized format for
network topology representation and a protocol for exchanging it. The
Onix OpenFlow controller has a network information base with a
specialized format for network topology, and every OpenFlow controller
requires this. Having a standardized way to represent it might
foster a
common topology database package. Another application is network
management. Every network management system needs some kind of
topology
representation. Finally, though I am not an expert in PCE
construction,
it would seem to me that a PCE would need some kind of topology
representation in order to perform path calculations. Having a way,for
example, for the OpenFlow controller and the PCE to exchange topology
information would be really useful. I would say to start with physical
topology because that is fundamental, but make the format flexible
enough
to support
virtual topology representation.

jak
_______________________________________________
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


_______________________________________________
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

_______________________________________________
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


_______________________________________________
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto



-- 
===================================================
Dr Greg Bernstein, Grotto Networking (510) 573-2237
--------------080100050901050805090804-- Return-Path: 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 3001221F8621 for ; Thu, 9 Aug 2012 08:03:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.57 X-Spam-Level: X-Spam-Status: No, score=-2.57 tagged_above=-999 required=5 tests=[AWL=0.029, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bqlEoTXMeFDS for ; Thu, 9 Aug 2012 08:03:17 -0700 (PDT) Received: from mail1310.opentransfer.com (mail1310.opentransfer.com [76.162.254.103]) by ietfa.amsl.com (Postfix) with ESMTP id 2374A21F8762 for ; Thu, 9 Aug 2012 08:03:17 -0700 (PDT) Received: (qmail 20086 invoked by uid 399); 9 Aug 2012 15:04:16 -0000 Received: from unknown (HELO ?192.168.1.91?) (pbs:robert@raszuk.net@83.31.196.38) by mail1310.opentransfer.com with ESMTPM; 9 Aug 2012 15:04:16 -0000 X-Originating-IP: 83.31.196.38 Message-ID: <5023D130.8060306@raszuk.net> Date: Thu, 09 Aug 2012 17:03:12 +0200 From: Robert Raszuk User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: Susan Hares References: <812700A304640D4292205D5E83FC59E1061C211D@p-embx01-eq.jnpr.net> <728F9B956B2C48439CA9294B1723B14623757671@dfweml509-mbs.china.huawei.com> In-Reply-To: <728F9B956B2C48439CA9294B1723B14623757671@dfweml509-mbs.china.huawei.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Thomas Nadeau , Gert Grammel , Alia Atlas , Lenny Giuliano , "irs-discuss@ietf.org" Subject: Re: [irs-discuss] IRS comments X-BeenThere: irs-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: robert@raszuk.net List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Aug 2012 15:03:18 -0000 Hi Sue, I am not sure about the division you are drawing. Consider SNMP ... it has both "get" and "set". I think for IRS or for any SDN application the below must be combined and the boundary you have drawn removed. Best, R. > Gert: > > How do you characterize network management? Traditionally network > management has been viewed in the IETF in two streams: monitoring > (active or passive) and configuration. > > What parts of these features do you think the IRS system needs to > avoid? > > Sue > > -----Original Message----- From: irs-discuss-bounces@ietf.org > [mailto:irs-discuss-bounces@ietf.org] On Behalf Of Gert Grammel Sent: > Monday, July 30, 2012 6:41 PM To: Thomas Nadeau; Lenny Giuliano; Alia > Atlas Cc: irs-discuss@ietf.org Subject: Re: [irs-discuss] IRS > comments > > Tom, > > It is confusing to understand whether IRS belongs to a new network > management plane or if it's more of a control plane extension. The > draft wisely avoids this classification. To me IRS appears to be a > completely different beast which should best be characterized as > 'Network Programming Plane' NPP. It neither aims to do full > provisioning (as a management plane would do) nor aims to replace > routing (as a control plane would do). Hence we better name the baby > NPP -- thereby avoiding any linkage to taxation. > > > Gert > > > > > ----- Original Message ----- From: irs-discuss-bounces@ietf.org > To: Lenny Giuliano; Alia Atlas Cc: > irs-discuss@ietf.org Sent: Tue Jul 31 01:50:40 > 2012 Subject: Re: [irs-discuss] IRS comments > > > [Re-adding IRS] > > Thank you for reviewing and the comments. We will incorporate the > edits in the next rev. > > --Tom > > > On 7/30/12 5:04 PM, "Lenny Giuliano" wrote: > >> >> Minor points: >> >> -section 4, para 2, 3rd sentence, "Howeve,r" >> >> -4.1.3 "There is no bidirectional programmatic interface to add, >> modify, remove or read state from the multicast RIB." -How is this >> unique to mcast? Couldn't you say the same thing about unicast? >> >> -4.1.3 "The multicast state added need not match to well-known >> protocol installed state. For instance, traffic received on an >> specified set, or all, interfaces that is destined to a particular >> prefix from all sources or a particular prefix could be subject to >> the specified replication." -Not clear to me at all what this para >> is saying. >> >> -"IRS"- you may want to select a different acronym that isn't >> related to something as unpopular as taxation (something we learned >> with AMT). Maybe RSI instead... >> >> Overall, I found the doc to be clearly written and >> straightforward. Sounds like Openflow for routers. Not sure if >> it's intentional that you didn't mention Openflow, but it did seem >> like an elephant in the room as I was reading thru. Also, I did >> wonder what was new and novel here, as this sounded like our SDK >> which has been around for years. >> >> >> -Lenny > > _______________________________________________ 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 > _______________________________________________ irs-discuss mailing > list irs-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/irs-discuss > > Return-Path: 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 8CE9021F873E for ; Thu, 9 Aug 2012 07:59:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.265 X-Spam-Level: X-Spam-Status: No, score=-5.265 tagged_above=-999 required=5 tests=[AWL=1.334, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3b6xiw9XWFTw for ; Thu, 9 Aug 2012 07:59:23 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 604D621F8720 for ; Thu, 9 Aug 2012 07:59:23 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml201-edg.china.huawei.com) ([172.18.9.243]) by dfwrg02-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AIR72136; Thu, 09 Aug 2012 06:59:23 -0800 (PST) Received: from DFWEML405-HUB.china.huawei.com (10.193.5.102) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 9 Aug 2012 07:57:32 -0700 Received: from dfweml509-mbs.china.huawei.com ([169.254.12.123]) by dfweml405-hub.china.huawei.com ([10.193.5.102]) with mapi id 14.01.0323.003; Thu, 9 Aug 2012 07:57:36 -0700 From: Susan Hares To: Gert Grammel , Thomas Nadeau , Lenny Giuliano , Alia Atlas Thread-Topic: IRS comments Thread-Index: Ac1utoJXMLn1Fv5cTmO9ZkEBmEbA7gABwUJeAcg805A= Date: Thu, 9 Aug 2012 14:57:36 +0000 Message-ID: <728F9B956B2C48439CA9294B1723B14623757671@dfweml509-mbs.china.huawei.com> References: <812700A304640D4292205D5E83FC59E1061C211D@p-embx01-eq.jnpr.net> In-Reply-To: <812700A304640D4292205D5E83FC59E1061C211D@p-embx01-eq.jnpr.net> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.212.246.116] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Aug 2012 14:59:24 -0000 Gert: How do you characterize network management? Traditionally network manageme= nt has been viewed in the IETF in two streams: monitoring (active or passi= ve) and configuration. =20 What parts of these features do you think the IRS system needs to avoid?=20 Sue=20 -----Original Message----- From: irs-discuss-bounces@ietf.org [mailto:irs-discuss-bounces@ietf.org] On= Behalf Of Gert Grammel Sent: Monday, July 30, 2012 6:41 PM To: Thomas Nadeau; Lenny Giuliano; Alia Atlas Cc: irs-discuss@ietf.org Subject: Re: [irs-discuss] IRS comments Tom, It is confusing to understand whether IRS belongs to a new network manageme= nt plane or if it's more of a control plane extension. The draft wisely avo= ids this classification. To me IRS appears to be a completely different beast which should best be = characterized as 'Network Programming Plane' NPP.=20 It neither aims to do full provisioning (as a management plane would do) no= r aims to replace routing (as a control plane would do). Hence we better name the baby NPP -- thereby avoiding any linkage to taxati= on. Gert ----- Original Message ----- From: irs-discuss-bounces@ietf.org To: Lenny Giuliano; Alia Atlas Cc: irs-discuss@ietf.org Sent: Tue Jul 31 01:50:40 2012 Subject: Re: [irs-discuss] IRS comments [Re-adding IRS] Thank you for reviewing and the comments. We will incorporate the edits in the next rev. --Tom On 7/30/12 5:04 PM, "Lenny Giuliano" wrote: > >Minor points: > >-section 4, para 2, 3rd sentence, "Howeve,r" > >-4.1.3 "There is no bidirectional programmatic interface to add, modify, > remove or read state from the multicast RIB." > -How is this unique to mcast? Couldn't you say the same thing > about unicast? > >-4.1.3 "The multicast state added need not match to well-known protocol > installed state. For instance, traffic received on an specified set, > or all, interfaces that is destined to a particular prefix from all > sources or a particular prefix could be subject to the specified > replication." > -Not clear to me at all what this para is saying. > >-"IRS"- you may want to select a different acronym that isn't related to >something as unpopular as taxation (something we learned with AMT). >Maybe=20 >RSI instead... > >Overall, I found the doc to be clearly written and straightforward. >Sounds like Openflow for routers. Not sure if it's intentional that you >didn't mention Openflow, but it did seem like an elephant in the room as >I=20 >was reading thru. Also, I did wonder what was new and novel here, as >this=20 >sounded like our SDK which has been around for years. > > >-Lenny _______________________________________________ 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 Return-Path: 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 E246A11E8156 for ; Wed, 8 Aug 2012 18:55:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aWEzmsA6vLIa for ; Wed, 8 Aug 2012 18:55:12 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id CFF2711E8150 for ; Wed, 8 Aug 2012 18:55:11 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml202-edg.china.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath) with ESMTP id AJB18136; Wed, 08 Aug 2012 17:55:11 -0800 (PST) Received: from DFWEML404-HUB.china.huawei.com (10.193.5.203) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 8 Aug 2012 18:51:20 -0700 Received: from DFWEML513-MBS.china.huawei.com ([169.254.4.5]) by dfweml404-hub.china.huawei.com ([10.193.5.203]) with mapi id 14.01.0323.003; Wed, 8 Aug 2012 18:51:17 -0700 From: Lin Han To: Alia Atlas Thread-Topic: [irs-discuss] IRS comments Thread-Index: Ac1utoJXMLn1Fv5cTmO9ZkEBmEbA7gABwUJeAb9NQrAADyLEAAAOKtSw//+lOYCAAGgx4A== Date: Thu, 9 Aug 2012 01:51:17 +0000 Message-ID: <1D30AF33624CDD4A99E8C395069A2A161FE0FE73@dfweml513-mbs.china.huawei.com> References: <1D30AF33624CDD4A99E8C395069A2A161FE0FDBC@dfweml513-mbs.china.huawei.com> <1D30AF33624CDD4A99E8C395069A2A161FE0FE09@dfweml513-mbs.china.huawei.com> In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.212.245.79] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: Thomas Nadeau , Gert Grammel , Alia Atlas , Lenny Giuliano , "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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Aug 2012 01:55:13 -0000 See in line -----Original Message----- From: Alia Atlas [mailto:akatlas@gmail.com]=20 Sent: Wednesday, August 08, 2012 5:43 PM To: Lin Han Cc: Thomas Nadeau; Gert Grammel; Lenny Giuliano; Alia Atlas; irs-discuss@ie= tf.org Subject: Re: [irs-discuss] IRS comments Lin, IRS is about applications being able to provide routing-related state to a device and learn topology, measurement, relevant events, etc. from the devices. It is critical to enable a feedback loop so that an application can knowledgeably determine what state needs to be installed. [Lin] understood. As I said, in simple language, IRS try to provide the pro= gramming-ability for router (correct me if I'm wrong). To achieve it, routi= ng programmer (APP) needs to know the topo, state/stats, etc from device, o= r the event feedback as you said. Definitely, we need a new protocol. I think it is important to focus on the problem-statement, use-cases, framework and requirements for IRS. [Lin] Is there any other issues the problem-statement wants to solve except= programming-ability? People will have their own perspectives on how this can relate to the work going on in the ONF and other fora. In the IETF at this stage, I don't think it is really appropriate to do a serious compare/contrast draft. Certainly, if others disagree, I'd be happy to comment on preliminary write-ups or drafts. [Lin] I don't object IETF has its own version of SDN or OF. If IETF version= will better address issues and solutions, no doubt industry will accept it= . From this point of view, comparison with SDN/OF is inevitable no matter i= f we like or don't like. The important thing is it does not hurt us since c= omparison can drive us to provide better solution. If we don't compare (int= entionally or technically), it will only bring up the confusion and debatin= g. I believe that IRS offers a useful function for allowing services that require applications to be able to dynamically program routing state. That can be on devices that locally implement and use all, some, or very little of the routing system. A key component for a device is the RIB layer that provides indirection and policy to determine which state to install based upon preference and which applications have installed it. The discussion at the Routing Area open meeting did frame and provide additional context. I'd recommend listening to that if & when possible as well as looking at the slides and drafts. Alia On Wed, Aug 8, 2012 at 7:56 PM, Lin Han wrote: > Hi, Tom, > > I got the slide after digging tons of threads. > I agree that we should have a tech talk about what is the difference of I= RS and SDN/OF. This will make the frame work more convincing. > For example, after looking at the picture of Alias slide page 5, It canno= t stop me to think that IRS protocol does similar things as north bound API= , or OF, depending on what is the format of table we are going to use. > This frame work gave me a impression that we assume that we don't want to= simplify router architecture (for example, keep routing protocol running o= n router; IRS is just an extra new component), then what we can provide the= same thing (programming-ability) like SDN. Is this the best solution? > > Thanks > Lin > -----Original Message----- > From: Thomas Nadeau [mailto:tnadeau@juniper.net] > Sent: Wednesday, August 08, 2012 4:22 PM > To: Lin Han; Gert Grammel; Lenny Giuliano; Alia Atlas > Cc: irs-discuss@ietf.org > Subject: Re: IRS comments > > > > On 8/8/12 7:14 PM, "Lin Han" wrote: > >>Similar confusion by wisely avoidance -:) >> >>If possible, Someone can draw a simple picture of IRS location in a >>router with existence of other components. > > Did you see the slides that Alia sent out from the IETF Presentat= ion? > Unicast me if not and I will get them to you. > >>Also, I think people are confused by the comparison with SDN and OF. More >>clarification will be helpful. > > For that, we really should set up some internal tech talk thing. = Slides > can help, but having a decent presentation on this would go a long way. > Let me see what we can do in this regard. > > --Tom > > >> >>Lin >> >>-----Original Message----- >>From: irs-discuss-bounces@ietf.org [mailto:irs-discuss-bounces@ietf.org] >>On Behalf Of Gert Grammel >>Sent: Monday, July 30, 2012 6:41 PM >>To: Thomas Nadeau; Lenny Giuliano; Alia Atlas >>Cc: irs-discuss@ietf.org >>Subject: Re: [irs-discuss] IRS comments >> >>Tom, >> >>It is confusing to understand whether IRS belongs to a new network >>management plane or if it's more of a control plane extension. The draft >>wisely avoids this classification. >>To me IRS appears to be a completely different beast which should best be >> characterized as 'Network Programming Plane' NPP. >>It neither aims to do full provisioning (as a management plane would do) >>nor aims to replace routing (as a control plane would do). >>Hence we better name the baby NPP -- thereby avoiding any linkage to >>taxation. >> >> >>Gert >> >> >> >> >>----- Original Message ----- >>From: irs-discuss-bounces@ietf.org >>To: Lenny Giuliano; Alia Atlas >>Cc: irs-discuss@ietf.org >>Sent: Tue Jul 31 01:50:40 2012 >>Subject: Re: [irs-discuss] IRS comments >> >> >>[Re-adding IRS] >> >> Thank you for reviewing and the comments. We will incorporate the = edits >>in the next rev. >> >> --Tom >> >> >>On 7/30/12 5:04 PM, "Lenny Giuliano" wrote: >> >>> >>>Minor points: >>> >>>-section 4, para 2, 3rd sentence, "Howeve,r" >>> >>>-4.1.3 "There is no bidirectional programmatic interface to add, modify, >>> remove or read state from the multicast RIB." >>> -How is this unique to mcast? Couldn't you say the same thing >>> about unicast? >>> >>>-4.1.3 "The multicast state added need not match to well-known protocol >>> installed state. For instance, traffic received on an specified set= , >>> or all, interfaces that is destined to a particular prefix from all >>> sources or a particular prefix could be subject to the specified >>> replication." >>> -Not clear to me at all what this para is saying. >>> >>>-"IRS"- you may want to select a different acronym that isn't related to >>>something as unpopular as taxation (something we learned with AMT). >>>Maybe >>>RSI instead... >>> >>>Overall, I found the doc to be clearly written and straightforward. >>>Sounds like Openflow for routers. Not sure if it's intentional that you >>>didn't mention Openflow, but it did seem like an elephant in the room as >>>I >>>was reading thru. Also, I did wonder what was new and novel here, as >>>this >>>sounded like our SDK which has been around for years. >>> >>> >>>-Lenny >> >>_______________________________________________ >>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 > > _______________________________________________ > irs-discuss mailing list > irs-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/irs-discuss Return-Path: 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 9D85521F8501 for ; Wed, 8 Aug 2012 17:42:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.559 X-Spam-Level: X-Spam-Status: No, score=-3.559 tagged_above=-999 required=5 tests=[AWL=0.040, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PSxjgVENsoS9 for ; Wed, 8 Aug 2012 17:42:44 -0700 (PDT) Received: from mail-gh0-f172.google.com (mail-gh0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 55CC521F84F2 for ; Wed, 8 Aug 2012 17:42:44 -0700 (PDT) Received: by ghbg16 with SMTP id g16so1588337ghb.31 for ; Wed, 08 Aug 2012 17:42:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=b5Ttkj0bW2y5eySFK8rO/IyIQyjX2W0ai6tKRA6Sqb4=; b=ReRxq3b/wHIShpAw6zh7qR4gtMNwW+TUt7fUgwtvEjkG734QfhMDsTcVmNHVFwaqrF sUo66Q6pZm3HQULFjO26mVlxKLCXU++l5cOZv5v1Q3L6Ckdy172/NytzusUsIg2ABMBe fJ/k/VHkdgGDxlnTuoSOq66vhQVyW961QVVJXFwHbg1jTHPTQy5HCmCCL0Nk/4oAGen9 69yyWnIPks0W0ivYlHwLqRhurzxCClUjpHtJxK7HfrtPXBIdJOX3SHsyayESMcB21E/M 6f0ScwWdxuVeBXsXZVTRtR7QLeIhLbZfD4sSw2POfdBNESIM6BsEq9K71bPL84vepg0n SrOg== MIME-Version: 1.0 Received: by 10.50.209.8 with SMTP id mi8mr559359igc.63.1344472963409; Wed, 08 Aug 2012 17:42:43 -0700 (PDT) Received: by 10.50.91.135 with HTTP; Wed, 8 Aug 2012 17:42:43 -0700 (PDT) In-Reply-To: <1D30AF33624CDD4A99E8C395069A2A161FE0FE09@dfweml513-mbs.china.huawei.com> References: <1D30AF33624CDD4A99E8C395069A2A161FE0FDBC@dfweml513-mbs.china.huawei.com> <1D30AF33624CDD4A99E8C395069A2A161FE0FE09@dfweml513-mbs.china.huawei.com> Date: Wed, 8 Aug 2012 20:42:43 -0400 Message-ID: From: Alia Atlas To: Lin Han Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Thomas Nadeau , Gert Grammel , Alia Atlas , Lenny Giuliano , "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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Aug 2012 00:42:45 -0000 Lin, IRS is about applications being able to provide routing-related state to a device and learn topology, measurement, relevant events, etc. from the devices. It is critical to enable a feedback loop so that an application can knowledgeably determine what state needs to be installed. I think it is important to focus on the problem-statement, use-cases, framework and requirements for IRS. People will have their own perspectives on how this can relate to the work going on in the ONF and other fora. In the IETF at this stage, I don't think it is really appropriate to do a serious compare/contrast draft. Certainly, if others disagree, I'd be happy to comment on preliminary write-ups or drafts. I believe that IRS offers a useful function for allowing services that require applications to be able to dynamically program routing state. That can be on devices that locally implement and use all, some, or very little of the routing system. A key component for a device is the RIB layer that provides indirection and policy to determine which state to install based upon preference and which applications have installed it. The discussion at the Routing Area open meeting did frame and provide additional context. I'd recommend listening to that if & when possible as well as looking at the slides and drafts. Alia On Wed, Aug 8, 2012 at 7:56 PM, Lin Han wrote: > Hi, Tom, > > I got the slide after digging tons of threads. > I agree that we should have a tech talk about what is the difference of I= RS and SDN/OF. This will make the frame work more convincing. > For example, after looking at the picture of Alias slide page 5, It canno= t stop me to think that IRS protocol does similar things as north bound API= , or OF, depending on what is the format of table we are going to use. > This frame work gave me a impression that we assume that we don't want to= simplify router architecture (for example, keep routing protocol running o= n router; IRS is just an extra new component), then what we can provide the= same thing (programming-ability) like SDN. Is this the best solution? > > Thanks > Lin > -----Original Message----- > From: Thomas Nadeau [mailto:tnadeau@juniper.net] > Sent: Wednesday, August 08, 2012 4:22 PM > To: Lin Han; Gert Grammel; Lenny Giuliano; Alia Atlas > Cc: irs-discuss@ietf.org > Subject: Re: IRS comments > > > > On 8/8/12 7:14 PM, "Lin Han" wrote: > >>Similar confusion by wisely avoidance -:) >> >>If possible, Someone can draw a simple picture of IRS location in a >>router with existence of other components. > > Did you see the slides that Alia sent out from the IETF Presentat= ion? > Unicast me if not and I will get them to you. > >>Also, I think people are confused by the comparison with SDN and OF. More >>clarification will be helpful. > > For that, we really should set up some internal tech talk thing. = Slides > can help, but having a decent presentation on this would go a long way. > Let me see what we can do in this regard. > > --Tom > > >> >>Lin >> >>-----Original Message----- >>From: irs-discuss-bounces@ietf.org [mailto:irs-discuss-bounces@ietf.org] >>On Behalf Of Gert Grammel >>Sent: Monday, July 30, 2012 6:41 PM >>To: Thomas Nadeau; Lenny Giuliano; Alia Atlas >>Cc: irs-discuss@ietf.org >>Subject: Re: [irs-discuss] IRS comments >> >>Tom, >> >>It is confusing to understand whether IRS belongs to a new network >>management plane or if it's more of a control plane extension. The draft >>wisely avoids this classification. >>To me IRS appears to be a completely different beast which should best be >> characterized as 'Network Programming Plane' NPP. >>It neither aims to do full provisioning (as a management plane would do) >>nor aims to replace routing (as a control plane would do). >>Hence we better name the baby NPP -- thereby avoiding any linkage to >>taxation. >> >> >>Gert >> >> >> >> >>----- Original Message ----- >>From: irs-discuss-bounces@ietf.org >>To: Lenny Giuliano; Alia Atlas >>Cc: irs-discuss@ietf.org >>Sent: Tue Jul 31 01:50:40 2012 >>Subject: Re: [irs-discuss] IRS comments >> >> >>[Re-adding IRS] >> >> Thank you for reviewing and the comments. We will incorporate the = edits >>in the next rev. >> >> --Tom >> >> >>On 7/30/12 5:04 PM, "Lenny Giuliano" wrote: >> >>> >>>Minor points: >>> >>>-section 4, para 2, 3rd sentence, "Howeve,r" >>> >>>-4.1.3 "There is no bidirectional programmatic interface to add, modify, >>> remove or read state from the multicast RIB." >>> -How is this unique to mcast? Couldn't you say the same thing >>> about unicast? >>> >>>-4.1.3 "The multicast state added need not match to well-known protocol >>> installed state. For instance, traffic received on an specified set= , >>> or all, interfaces that is destined to a particular prefix from all >>> sources or a particular prefix could be subject to the specified >>> replication." >>> -Not clear to me at all what this para is saying. >>> >>>-"IRS"- you may want to select a different acronym that isn't related to >>>something as unpopular as taxation (something we learned with AMT). >>>Maybe >>>RSI instead... >>> >>>Overall, I found the doc to be clearly written and straightforward. >>>Sounds like Openflow for routers. Not sure if it's intentional that you >>>didn't mention Openflow, but it did seem like an elephant in the room as >>>I >>>was reading thru. Also, I did wonder what was new and novel here, as >>>this >>>sounded like our SDK which has been around for years. >>> >>> >>>-Lenny >> >>_______________________________________________ >>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 > > _______________________________________________ > irs-discuss mailing list > irs-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/irs-discuss Return-Path: 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 2B9B611E80F5 for ; Wed, 8 Aug 2012 16:58:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id do53a-qAXt62 for ; Wed, 8 Aug 2012 16:58:25 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 3205411E809B for ; Wed, 8 Aug 2012 16:58:25 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml202-edg.china.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath) with ESMTP id AJB12620; Wed, 08 Aug 2012 15:58:24 -0800 (PST) Received: from DFWEML406-HUB.china.huawei.com (10.193.5.131) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 8 Aug 2012 16:56:16 -0700 Received: from DFWEML513-MBS.china.huawei.com ([169.254.4.5]) by dfweml406-hub.china.huawei.com ([10.193.5.131]) with mapi id 14.01.0323.003; Wed, 8 Aug 2012 16:56:10 -0700 From: Lin Han To: Thomas Nadeau , Gert Grammel , Lenny Giuliano , Alia Atlas Thread-Topic: IRS comments Thread-Index: Ac1utoJXMLn1Fv5cTmO9ZkEBmEbA7gABwUJeAb9NQrAADyLEAAAOKtSw Date: Wed, 8 Aug 2012 23:56:10 +0000 Message-ID: <1D30AF33624CDD4A99E8C395069A2A161FE0FE09@dfweml513-mbs.china.huawei.com> References: <1D30AF33624CDD4A99E8C395069A2A161FE0FDBC@dfweml513-mbs.china.huawei.com> In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.212.245.79] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Aug 2012 23:58:26 -0000 Hi, Tom, I got the slide after digging tons of threads. I agree that we should have a tech talk about what is the difference of IRS= and SDN/OF. This will make the frame work more convincing. For example, after looking at the picture of Alias slide page 5, It cannot = stop me to think that IRS protocol does similar things as north bound API, = or OF, depending on what is the format of table we are going to use. This frame work gave me a impression that we assume that we don't want to s= implify router architecture (for example, keep routing protocol running on = router; IRS is just an extra new component), then what we can provide the s= ame thing (programming-ability) like SDN. Is this the best solution? Thanks Lin -----Original Message----- From: Thomas Nadeau [mailto:tnadeau@juniper.net]=20 Sent: Wednesday, August 08, 2012 4:22 PM To: Lin Han; Gert Grammel; Lenny Giuliano; Alia Atlas Cc: irs-discuss@ietf.org Subject: Re: IRS comments On 8/8/12 7:14 PM, "Lin Han" wrote: >Similar confusion by wisely avoidance -:) > >If possible, Someone can draw a simple picture of IRS location in a >router with existence of other components. Did you see the slides that Alia sent out from the IETF Presentation? Unicast me if not and I will get them to you. >Also, I think people are confused by the comparison with SDN and OF. More >clarification will be helpful. For that, we really should set up some internal tech talk thing. Slides can help, but having a decent presentation on this would go a long way. Let me see what we can do in this regard. --Tom > >Lin=20 > >-----Original Message----- >From: irs-discuss-bounces@ietf.org [mailto:irs-discuss-bounces@ietf.org] >On Behalf Of Gert Grammel >Sent: Monday, July 30, 2012 6:41 PM >To: Thomas Nadeau; Lenny Giuliano; Alia Atlas >Cc: irs-discuss@ietf.org >Subject: Re: [irs-discuss] IRS comments > >Tom, > >It is confusing to understand whether IRS belongs to a new network >management plane or if it's more of a control plane extension. The draft >wisely avoids this classification. >To me IRS appears to be a completely different beast which should best be > characterized as 'Network Programming Plane' NPP. >It neither aims to do full provisioning (as a management plane would do) >nor aims to replace routing (as a control plane would do). >Hence we better name the baby NPP -- thereby avoiding any linkage to >taxation. > > >Gert > > > > >----- Original Message ----- >From: irs-discuss-bounces@ietf.org >To: Lenny Giuliano; Alia Atlas >Cc: irs-discuss@ietf.org >Sent: Tue Jul 31 01:50:40 2012 >Subject: Re: [irs-discuss] IRS comments > > >[Re-adding IRS] > > Thank you for reviewing and the comments. We will incorporate the edits >in the next rev. > > --Tom > > >On 7/30/12 5:04 PM, "Lenny Giuliano" wrote: > >> >>Minor points: >> >>-section 4, para 2, 3rd sentence, "Howeve,r" >> >>-4.1.3 "There is no bidirectional programmatic interface to add, modify, >> remove or read state from the multicast RIB." >> -How is this unique to mcast? Couldn't you say the same thing >> about unicast? >> >>-4.1.3 "The multicast state added need not match to well-known protocol >> installed state. For instance, traffic received on an specified set, >> or all, interfaces that is destined to a particular prefix from all >> sources or a particular prefix could be subject to the specified >> replication." >> -Not clear to me at all what this para is saying. >> >>-"IRS"- you may want to select a different acronym that isn't related to >>something as unpopular as taxation (something we learned with AMT). >>Maybe=20 >>RSI instead... >> >>Overall, I found the doc to be clearly written and straightforward. >>Sounds like Openflow for routers. Not sure if it's intentional that you >>didn't mention Openflow, but it did seem like an elephant in the room as >>I=20 >>was reading thru. Also, I did wonder what was new and novel here, as >>this=20 >>sounded like our SDK which has been around for years. >> >> >>-Lenny > >_______________________________________________ >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 Return-Path: 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 3A4AD21F85CE for ; Wed, 8 Aug 2012 16:53:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fi5mZeG0DTxM for ; Wed, 8 Aug 2012 16:53:28 -0700 (PDT) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id DCD4421F859F for ; Wed, 8 Aug 2012 16:53:27 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by lucidvision.com (Postfix) with ESMTP id 233BA22398E9; Wed, 8 Aug 2012 19:53:27 -0400 (EDT) X-Virus-Scanned: amavisd-new at www.lucidvision.com Received: from lucidvision.com ([127.0.0.1]) by localhost (static-72-71-250-34.cncdnh.fios.verizon.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Huh+WhQgAVhA; Wed, 8 Aug 2012 19:53:26 -0400 (EDT) Received: from tnadeau-sslvpn-nc.jnpr.net (westford-nat.juniper.net [66.129.232.2]) by lucidvision.com (Postfix) with ESMTP id 9866F22398E6; Wed, 8 Aug 2012 19:53:23 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1485\)) From: Thomas Nadeau In-Reply-To: <1D30AF33624CDD4A99E8C395069A2A161FE0FDBC@dfweml513-mbs.china.huawei.com> Date: Wed, 8 Aug 2012 19:53:18 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <12D9C3A1-C8ED-4B68-B3B0-0BDB4DA72D42@lucidvision.com> References: <812700A304640D4292205D5E83FC59E1061C211D@p-embx01-eq.jnpr.net> <1D30AF33624CDD4A99E8C395069A2A161FE0FDBC@dfweml513-mbs.china.huawei.com> To: Lin Han X-Mailer: Apple Mail (2.1485) Cc: Thomas Nadeau , Gert Grammel , Alia Atlas , Lenny Giuliano , "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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Aug 2012 23:53:29 -0000 The slides can be found here: http://www.lucidvision.com/draft-ward-irs-framework-00.pptx=20 On Aug 8, 2012:7:14 PM, at 7:14 PM, Lin Han wrote: > Similar confusion by wisely avoidance -:) >=20 > If possible, Someone can draw a simple picture of IRS location in a = router with existence of other components. >=20 > Also, I think people are confused by the comparison with SDN and OF. = More clarification will be helpful. >=20 > Lin=20 >=20 > -----Original Message----- > From: irs-discuss-bounces@ietf.org = [mailto:irs-discuss-bounces@ietf.org] On Behalf Of Gert Grammel > Sent: Monday, July 30, 2012 6:41 PM > To: Thomas Nadeau; Lenny Giuliano; Alia Atlas > Cc: irs-discuss@ietf.org > Subject: Re: [irs-discuss] IRS comments >=20 > Tom, >=20 > It is confusing to understand whether IRS belongs to a new network = management plane or if it's more of a control plane extension. The draft = wisely avoids this classification. > To me IRS appears to be a completely different beast which should best = be characterized as 'Network Programming Plane' NPP.=20 > It neither aims to do full provisioning (as a management plane would = do) nor aims to replace routing (as a control plane would do). > Hence we better name the baby NPP -- thereby avoiding any linkage to = taxation. >=20 >=20 > Gert >=20 >=20 >=20 >=20 > ----- Original Message ----- > From: irs-discuss-bounces@ietf.org > To: Lenny Giuliano; Alia Atlas > Cc: irs-discuss@ietf.org > Sent: Tue Jul 31 01:50:40 2012 > Subject: Re: [irs-discuss] IRS comments >=20 >=20 > [Re-adding IRS] >=20 > Thank you for reviewing and the comments. We will incorporate = the edits > in the next rev. >=20 > --Tom >=20 >=20 > On 7/30/12 5:04 PM, "Lenny Giuliano" wrote: >=20 >>=20 >> Minor points: >>=20 >> -section 4, para 2, 3rd sentence, "Howeve,r" >>=20 >> -4.1.3 "There is no bidirectional programmatic interface to add, = modify, >> remove or read state from the multicast RIB." >> -How is this unique to mcast? Couldn't you say the same thing >> about unicast? >>=20 >> -4.1.3 "The multicast state added need not match to well-known = protocol >> installed state. For instance, traffic received on an specified = set, >> or all, interfaces that is destined to a particular prefix from all >> sources or a particular prefix could be subject to the specified >> replication." >> -Not clear to me at all what this para is saying. >>=20 >> -"IRS"- you may want to select a different acronym that isn't related = to >> something as unpopular as taxation (something we learned with AMT). >> Maybe=20 >> RSI instead... >>=20 >> Overall, I found the doc to be clearly written and straightforward. >> Sounds like Openflow for routers. Not sure if it's intentional that = you >> didn't mention Openflow, but it did seem like an elephant in the room = as >> I=20 >> was reading thru. Also, I did wonder what was new and novel here, as >> this=20 >> sounded like our SDK which has been around for years. >>=20 >>=20 >> -Lenny >=20 > _______________________________________________ > 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 > _______________________________________________ > irs-discuss mailing list > irs-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/irs-discuss >=20 Return-Path: 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 6266511E808D for ; Wed, 8 Aug 2012 16:26:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.375 X-Spam-Level: X-Spam-Status: No, score=-6.375 tagged_above=-999 required=5 tests=[AWL=0.224, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s+nnFyPy4ONo for ; Wed, 8 Aug 2012 16:26:45 -0700 (PDT) Received: from exprod7og109.obsmtp.com (exprod7og109.obsmtp.com [64.18.2.171]) by ietfa.amsl.com (Postfix) with ESMTP id C5F7011E8087 for ; Wed, 8 Aug 2012 16:26:43 -0700 (PDT) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob109.postini.com ([64.18.6.12]) with SMTP ID DSNKUCL1sh4SEuqO5WQCot3UWgMWTgix9BgU@postini.com; Wed, 08 Aug 2012 16:26:43 PDT Received: from P-CLDFE01-HQ.jnpr.net (172.24.192.59) by P-EMHUB03-HQ.jnpr.net (172.24.192.37) with Microsoft SMTP Server (TLS) id 8.3.213.0; Wed, 8 Aug 2012 16:25:58 -0700 Received: from p-emfe01-wf.jnpr.net (172.28.145.24) by p-cldfe01-hq.jnpr.net (172.24.192.59) with Microsoft SMTP Server (TLS) id 14.1.355.2; Wed, 8 Aug 2012 16:25:58 -0700 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe01-wf.jnpr.net ([fe80::d0d1:653d:5b91:a123%11]) with mapi; Wed, 8 Aug 2012 19:25:56 -0400 From: Thomas Nadeau To: Lin Han , Gert Grammel , Lenny Giuliano , Alia Atlas Date: Wed, 8 Aug 2012 19:21:58 -0400 Thread-Topic: IRS comments Thread-Index: Ac11vSi9vbTm3ZyNSu+JXzxURySWzA== Message-ID: In-Reply-To: <1D30AF33624CDD4A99E8C395069A2A161FE0FDBC@dfweml513-mbs.china.huawei.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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Aug 2012 23:26:46 -0000 On 8/8/12 7:14 PM, "Lin Han" wrote: >Similar confusion by wisely avoidance -:) > >If possible, Someone can draw a simple picture of IRS location in a >router with existence of other components. Did you see the slides that Alia sent out from the IETF Presentation? Unicast me if not and I will get them to you. >Also, I think people are confused by the comparison with SDN and OF. More >clarification will be helpful. For that, we really should set up some internal tech talk thing. Slides can help, but having a decent presentation on this would go a long way. Let me see what we can do in this regard. --Tom > >Lin=20 > >-----Original Message----- >From: irs-discuss-bounces@ietf.org [mailto:irs-discuss-bounces@ietf.org] >On Behalf Of Gert Grammel >Sent: Monday, July 30, 2012 6:41 PM >To: Thomas Nadeau; Lenny Giuliano; Alia Atlas >Cc: irs-discuss@ietf.org >Subject: Re: [irs-discuss] IRS comments > >Tom, > >It is confusing to understand whether IRS belongs to a new network >management plane or if it's more of a control plane extension. The draft >wisely avoids this classification. >To me IRS appears to be a completely different beast which should best be > characterized as 'Network Programming Plane' NPP. >It neither aims to do full provisioning (as a management plane would do) >nor aims to replace routing (as a control plane would do). >Hence we better name the baby NPP -- thereby avoiding any linkage to >taxation. > > >Gert > > > > >----- Original Message ----- >From: irs-discuss-bounces@ietf.org >To: Lenny Giuliano; Alia Atlas >Cc: irs-discuss@ietf.org >Sent: Tue Jul 31 01:50:40 2012 >Subject: Re: [irs-discuss] IRS comments > > >[Re-adding IRS] > > Thank you for reviewing and the comments. We will incorporate the edits >in the next rev. > > --Tom > > >On 7/30/12 5:04 PM, "Lenny Giuliano" wrote: > >> >>Minor points: >> >>-section 4, para 2, 3rd sentence, "Howeve,r" >> >>-4.1.3 "There is no bidirectional programmatic interface to add, modify, >> remove or read state from the multicast RIB." >> -How is this unique to mcast? Couldn't you say the same thing >> about unicast? >> >>-4.1.3 "The multicast state added need not match to well-known protocol >> installed state. For instance, traffic received on an specified set, >> or all, interfaces that is destined to a particular prefix from all >> sources or a particular prefix could be subject to the specified >> replication." >> -Not clear to me at all what this para is saying. >> >>-"IRS"- you may want to select a different acronym that isn't related to >>something as unpopular as taxation (something we learned with AMT). >>Maybe=20 >>RSI instead... >> >>Overall, I found the doc to be clearly written and straightforward. >>Sounds like Openflow for routers. Not sure if it's intentional that you >>didn't mention Openflow, but it did seem like an elephant in the room as >>I=20 >>was reading thru. Also, I did wonder what was new and novel here, as >>this=20 >>sounded like our SDK which has been around for years. >> >> >>-Lenny > >_______________________________________________ >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 Return-Path: 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 3871E21F85BB for ; Wed, 8 Aug 2012 16:17:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KemKNPv9fNiU for ; Wed, 8 Aug 2012 16:17:18 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 86DF821F85AD for ; Wed, 8 Aug 2012 16:17:18 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml202-edg.china.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath) with ESMTP id AJB10888; Wed, 08 Aug 2012 15:17:17 -0800 (PST) Received: from DFWEML404-HUB.china.huawei.com (10.193.5.203) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 8 Aug 2012 16:14:46 -0700 Received: from DFWEML513-MBS.china.huawei.com ([169.254.4.5]) by dfweml404-hub.china.huawei.com ([10.193.5.203]) with mapi id 14.01.0323.003; Wed, 8 Aug 2012 16:14:44 -0700 From: Lin Han To: Gert Grammel , Thomas Nadeau , Lenny Giuliano , Alia Atlas Thread-Topic: IRS comments Thread-Index: Ac1utoJXMLn1Fv5cTmO9ZkEBmEbA7gABwUJeAb9NQrA= Date: Wed, 8 Aug 2012 23:14:44 +0000 Message-ID: <1D30AF33624CDD4A99E8C395069A2A161FE0FDBC@dfweml513-mbs.china.huawei.com> References: <812700A304640D4292205D5E83FC59E1061C211D@p-embx01-eq.jnpr.net> In-Reply-To: <812700A304640D4292205D5E83FC59E1061C211D@p-embx01-eq.jnpr.net> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.212.245.79] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Aug 2012 23:17:19 -0000 Similar confusion by wisely avoidance -:) If possible, Someone can draw a simple picture of IRS location in a router = with existence of other components. Also, I think people are confused by the comparison with SDN and OF. More c= larification will be helpful. Lin=20 -----Original Message----- From: irs-discuss-bounces@ietf.org [mailto:irs-discuss-bounces@ietf.org] On= Behalf Of Gert Grammel Sent: Monday, July 30, 2012 6:41 PM To: Thomas Nadeau; Lenny Giuliano; Alia Atlas Cc: irs-discuss@ietf.org Subject: Re: [irs-discuss] IRS comments Tom, It is confusing to understand whether IRS belongs to a new network manageme= nt plane or if it's more of a control plane extension. The draft wisely avo= ids this classification. To me IRS appears to be a completely different beast which should best be = characterized as 'Network Programming Plane' NPP.=20 It neither aims to do full provisioning (as a management plane would do) no= r aims to replace routing (as a control plane would do). Hence we better name the baby NPP -- thereby avoiding any linkage to taxati= on. Gert ----- Original Message ----- From: irs-discuss-bounces@ietf.org To: Lenny Giuliano; Alia Atlas Cc: irs-discuss@ietf.org Sent: Tue Jul 31 01:50:40 2012 Subject: Re: [irs-discuss] IRS comments [Re-adding IRS] Thank you for reviewing and the comments. We will incorporate the edits in the next rev. --Tom On 7/30/12 5:04 PM, "Lenny Giuliano" wrote: > >Minor points: > >-section 4, para 2, 3rd sentence, "Howeve,r" > >-4.1.3 "There is no bidirectional programmatic interface to add, modify, > remove or read state from the multicast RIB." > -How is this unique to mcast? Couldn't you say the same thing > about unicast? > >-4.1.3 "The multicast state added need not match to well-known protocol > installed state. For instance, traffic received on an specified set, > or all, interfaces that is destined to a particular prefix from all > sources or a particular prefix could be subject to the specified > replication." > -Not clear to me at all what this para is saying. > >-"IRS"- you may want to select a different acronym that isn't related to >something as unpopular as taxation (something we learned with AMT). >Maybe=20 >RSI instead... > >Overall, I found the doc to be clearly written and straightforward. >Sounds like Openflow for routers. Not sure if it's intentional that you >didn't mention Openflow, but it did seem like an elephant in the room as >I=20 >was reading thru. Also, I did wonder what was new and novel here, as >this=20 >sounded like our SDK which has been around for years. > > >-Lenny _______________________________________________ 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 Return-Path: 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 C038C21F85E1 for ; Wed, 8 Aug 2012 07:59:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1X2Ka7ra-VXy for ; Wed, 8 Aug 2012 07:59:08 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id E639D21F8628 for ; Wed, 8 Aug 2012 07:59:07 -0700 (PDT) Received: by obbwc20 with SMTP id wc20so1504404obb.31 for ; Wed, 08 Aug 2012 07:59:07 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=4FrKfaWiDOjYIZRYw5gFUhEdmvJTOJLsh+XOslL3Tlw=; b=IPKa6zjCO+8wEYkpcUoN4H0khNik7tZAJbToHGFoocs51ZEChwf7L75yhGhOnvaqsL hyyXn8CZzpNgyip2QqVioMr9TiTfh/wV28Lc4g92aOwFez9nBMW8kfsBWZPlJhqcMw5A x2Vn7DrTAvctjPHKzwnsnmy4jrD6eDtVdElyFZQc07ah0xq3St+/SnRNGGXe9LIe1mbx P1scUIIdR6UyZgKnwlstDEOqftw0hfwYdw3zlFhhRK5BcgjgsHdFbGy3Eza19YdZ5h4S rA/Jx5V20caq4EJCJCCFQDCGshtkXS7s3NvZf2dX+2zFsFC3A3QA2dFjMNu0QjbfbR3b Ppqw== MIME-Version: 1.0 Received: by 10.182.146.46 with SMTP id sz14mr30255830obb.76.1344437947392; Wed, 08 Aug 2012 07:59:07 -0700 (PDT) Received: by 10.76.135.66 with HTTP; Wed, 8 Aug 2012 07:59:07 -0700 (PDT) X-Originating-IP: [63.156.62.121] In-Reply-To: <472BCA45-0462-45E0-BE89-339799915A9C@huawei.com> References: <501B150C.9080304@raszuk.net> <472BCA45-0462-45E0-BE89-339799915A9C@huawei.com> Date: Wed, 8 Aug 2012 07:59:07 -0700 Message-ID: From: David Meyer To: Tina TSOU Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQmdkRF0wwnbB6M2K2+c/cjpWNglfmPcegwtf7lSEOgLKVyLmFS6CB9arwmC7HT0qrlBxZGq Cc: "irs-discuss@ietf.org" , Edward Crabbe , "robert@raszuk.net" , Alia Atlas Subject: Re: [irs-discuss] An idea ... MTR + IRS X-BeenThere: irs-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Aug 2012 14:59:08 -0000 On Tue, Aug 7, 2012 at 9:07 PM, Tina TSOU wrote: > So, r u updating Nitin's statement as following? > > Top layer: Northboundapi #dmm: I propose we depricate the term "Northbound API". It is pretty much (if not completely) meaningless. > > Middle layer: IRS > > Bottom layer: IRS (topo export) > > > Tina > > On Aug 7, 2012, at 9:01 PM, "Alia Atlas" wrote: > > The requirement for topology export is DEFINITELY part of IRS. It is > a crucial piece for a meaningful feedback loop. Clearly there are > existing technology pieces that may have a role to play as well. > > Alia > > On Tue, Aug 7, 2012 at 10:40 PM, Tina TSOU > wrote: > > Oh, I meant in Nitin's description in the mailing list, there are 3 > sub-layers of a orchestrator. > > Top layer: Northboundapi > > Middle layer: IRS > > Bottom layer: topo export > > > Therefore, the topo export is not part of IRS. It is another layer which > sits below IRS. > > > Tina > > > On Aug 7, 2012, at 5:30 PM, "Alia Atlas" wrote: > > > Topology export is definitely under the umbrella of IRS - and we are > > actively starting to think about the associated requirements and > > use-cases. Feel free to contribute - on the list or towards drafts! > > > Alia > > > On Tue, Aug 7, 2012 at 6:23 PM, Tina TSOU > wrote: > > Nitin said topo information export is on the sub-layer under IRS. > > > > > Tina > > > > > From: irs-discuss-bounces@ietf.org [mailto:irs-discuss-bounces@ietf.org] On > > Behalf Of Edward Crabbe > > Sent: Tuesday, August 07, 2012 3:20 PM > > To: robert@raszuk.net > > Cc: irs-discuss@ietf.org > > > > Subject: Re: [irs-discuss] An idea ... MTR + IRS > > > > > Robert, > > > > > If topo information export is in scope (which I believe it is) and PBR route > > injection with nh recursion to rib (and thus connected routes) is in scope > > (which I'm quite sure it is) then yes, this is in scope. > > > > > Although I'm not sure what it has to do with OF /OF controllers? ;P > > > On Thu, Aug 2, 2012 at 5:02 PM, Robert Raszuk wrote: > > > Hi, > > > This morning Scott mentioned that he would like to use IRS to shut down all > > protocols and just be able to write to RIB. Now James said that he would > > like to get a network topology as "every OpenFlow controller requires this" > > > Both connected together resulted in an idea of using multi-topology-routing > > where your base topology discovers physical link connectivity graph while > > other topologies could be programmed by external entities example: OF > > controllers or any other external to routers network intelligence oracles to > > deliver actual services ? > > > Would that be in scope of IRS effort ? If so what would be the proposed > > "write to RIB" set of protocols ? Would you support OF 1.3 even if one would > > be happy to lock such topologies only to software/programmable switching > > paths ? > > > Best rgs, > > R. > > _______________________________________________ > > 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 > > > > _______________________________________________ > irs-discuss mailing list > irs-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/irs-discuss > Return-Path: 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 7F5F121F8501 for ; Wed, 8 Aug 2012 03:10:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.569 X-Spam-Level: X-Spam-Status: No, score=-2.569 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PZ4zquL2OvyJ for ; Wed, 8 Aug 2012 03:10:49 -0700 (PDT) Received: from mail1310.opentransfer.com (mail1310.opentransfer.com [76.162.254.103]) by ietfa.amsl.com (Postfix) with ESMTP id B1EEE21F84FE for ; Wed, 8 Aug 2012 03:10:48 -0700 (PDT) Received: (qmail 6440 invoked by uid 399); 8 Aug 2012 10:11:47 -0000 Received: from unknown (HELO ?192.168.1.91?) (pbs:robert@raszuk.net@83.31.225.201) by mail1310.opentransfer.com with ESMTPM; 8 Aug 2012 10:11:47 -0000 X-Originating-IP: 83.31.225.201 Message-ID: <50223B25.9080401@raszuk.net> Date: Wed, 08 Aug 2012 12:10:45 +0200 From: Robert Raszuk User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: Edward Crabbe References: <501B150C.9080304@raszuk.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "irs-discuss@ietf.org" Subject: Re: [irs-discuss] An idea ... MTR + IRS X-BeenThere: irs-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: robert@raszuk.net List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Aug 2012 10:10:49 -0000 Ed, > If topo information export is in scope (which I believe it is) and > PBR route injection with nh recursion to rib (and thus connected > routes) is in scope (which I'm quite sure it is) then yes, this is in > scope. Great ! > Although I'm not sure what it has to do with OF /OF controllers? ;P One could observe that entire OF can be very easily mapped to well implemented and scaable PBR ;) Best, R. Return-Path: 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 D09B511E812B for ; Tue, 7 Aug 2012 22:33:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.558 X-Spam-Level: X-Spam-Status: No, score=-3.558 tagged_above=-999 required=5 tests=[AWL=0.041, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0J4H+zDDcmoL for ; Tue, 7 Aug 2012 22:33:18 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id E5E9A11E8135 for ; Tue, 7 Aug 2012 22:33:17 -0700 (PDT) Received: by yenm5 with SMTP id m5so408362yen.31 for ; Tue, 07 Aug 2012 22:33:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=5GHw/T42YVDMuY9P/YgBmMHrLEU2TJYfWmz5K+n0xO4=; b=XENYtJX+8JaN7GjYwIWTbFkr7dbXtQgWZs9/QXcM+HpiL4Ni8ZomI9VPcZTCdVLPcA qi/pUosQi2qaVtq/E42MsXTgVAeZ+6U8dS5hNpamWbPuPc0YUTtcBekB4UBqKKt53AxI 63qry+y+9s33YZjo1VyupC2HYi6/EK/mvcy0/ldpP8mexzPzCEK6B4SEKAhDk4i37P+7 BM4g6RzvSyqyfmikzlYs16gcAsG/xSwCiXX3lykBrAkCy7j3gqAZ2rTLK5aFN5mXy9Qz sFGCoKOO3+98l5oO/35Xb7OC2SxiPZ6Xwf9LuWTriMEqpEWkP+Or/B7j1GbGFDiLXMFA uqGQ== MIME-Version: 1.0 Received: by 10.50.194.132 with SMTP id hw4mr684292igc.63.1344403982683; Tue, 07 Aug 2012 22:33:02 -0700 (PDT) Received: by 10.50.91.135 with HTTP; Tue, 7 Aug 2012 22:33:02 -0700 (PDT) In-Reply-To: References: <501B150C.9080304@raszuk.net> <472BCA45-0462-45E0-BE89-339799915A9C@huawei.com> Date: Wed, 8 Aug 2012 01:33:02 -0400 Message-ID: From: Alia Atlas To: Tina TSOU Content-Type: text/plain; charset=ISO-8859-1 Cc: Edward Crabbe , "robert@raszuk.net" , "irs-discuss@ietf.org" Subject: Re: [irs-discuss] An idea ... MTR + IRS X-BeenThere: irs-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Aug 2012 05:33:18 -0000 Tina, IRS makes no statement about orchestrators; I'm pretty sure the word doesn't appear in either draft at all. Certainly an orchestrator is a type of application that could use IRS. IRS includes routing state, topology, and the ability to get measurements and dynamic events. All may be needed for a meaningful feedback loop run by an application. Alia On Wed, Aug 8, 2012 at 1:24 AM, Tina TSOU wrote: > Alia, > It is just to clarification. > Just to confirm that draft-atlas and draft-ward state that IRS positions below the northboudapi in an orchestrator, and IRS includes both routing state and topo export. Is it correct understanding? > Thank you. > > Tina > > >> -----Original Message----- >> From: Alia Atlas [mailto:akatlas@gmail.com] >> Sent: Tuesday, August 07, 2012 9:38 PM >> To: Tina TSOU >> Cc: Edward Crabbe; robert@raszuk.net; irs-discuss@ietf.org >> Subject: Re: [irs-discuss] An idea ... MTR + IRS >> >> Tina, >> >> Nitin made a single comment on this list that you are reading too much >> into. >> >> I have written the two base drafts for IRS and am working on driving >> the definition of the work that is proposed. The presentation that I >> gave in Routing Area Open Meeting CLEARLY describes topology as not >> only being in the proposed scope, but one of the more urgent items. >> >> Why are you NOT listening? >> >> Perhaps rereading the problem-statement and framework drafts would >> help clarify your mental model? >> >> IRS does not talk about a northboundapi - there are applications that >> can use IRS. How those applications communicate with other >> applications is NOT in the proposed scope. >> >> Alia >> >> On Wed, Aug 8, 2012 at 12:07 AM, Tina TSOU >> wrote: >> > So, r u updating Nitin's statement as following? >> > >> > Top layer: Northboundapi >> > >> > Middle layer: IRS >> > >> > Bottom layer: IRS (topo export) >> > >> > >> > Tina >> > >> > On Aug 7, 2012, at 9:01 PM, "Alia Atlas" wrote: >> > >> > The requirement for topology export is DEFINITELY part of IRS. It is >> > a crucial piece for a meaningful feedback loop. Clearly there are >> > existing technology pieces that may have a role to play as well. >> > >> > Alia >> > >> > On Tue, Aug 7, 2012 at 10:40 PM, Tina TSOU >> >> > wrote: >> > >> > Oh, I meant in Nitin's description in the mailing list, there are 3 >> > sub-layers of a orchestrator. >> > >> > Top layer: Northboundapi >> > >> > Middle layer: IRS >> > >> > Bottom layer: topo export >> > >> > >> > Therefore, the topo export is not part of IRS. It is another layer >> which >> > sits below IRS. >> > >> > >> > Tina >> > >> > >> > On Aug 7, 2012, at 5:30 PM, "Alia Atlas" wrote: >> > >> > >> > Topology export is definitely under the umbrella of IRS - and we are >> > >> > actively starting to think about the associated requirements and >> > >> > use-cases. Feel free to contribute - on the list or towards drafts! >> > >> > >> > Alia >> > >> > >> > On Tue, Aug 7, 2012 at 6:23 PM, Tina TSOU >> >> > wrote: >> > >> > Nitin said topo information export is on the sub-layer under IRS. >> > >> > >> > >> > >> > Tina >> > >> > >> > >> > >> > From: irs-discuss-bounces@ietf.org [mailto:irs-discuss- >> bounces@ietf.org] On >> > >> > Behalf Of Edward Crabbe >> > >> > Sent: Tuesday, August 07, 2012 3:20 PM >> > >> > To: robert@raszuk.net >> > >> > Cc: irs-discuss@ietf.org >> > >> > >> > >> > Subject: Re: [irs-discuss] An idea ... MTR + IRS >> > >> > >> > >> > >> > Robert, >> > >> > >> > >> > >> > If topo information export is in scope (which I believe it is) and >> PBR route >> > >> > injection with nh recursion to rib (and thus connected routes) is in >> scope >> > >> > (which I'm quite sure it is) then yes, this is in scope. >> > >> > >> > >> > >> > Although I'm not sure what it has to do with OF /OF controllers? ;P >> > >> > >> > On Thu, Aug 2, 2012 at 5:02 PM, Robert Raszuk >> wrote: >> > >> > >> > Hi, >> > >> > >> > This morning Scott mentioned that he would like to use IRS to shut >> down all >> > >> > protocols and just be able to write to RIB. Now James said that he >> would >> > >> > like to get a network topology as "every OpenFlow controller requires >> this" >> > >> > >> > Both connected together resulted in an idea of using multi-topology- >> routing >> > >> > where your base topology discovers physical link connectivity graph >> while >> > >> > other topologies could be programmed by external entities example: OF >> > >> > controllers or any other external to routers network intelligence >> oracles to >> > >> > deliver actual services ? >> > >> > >> > Would that be in scope of IRS effort ? If so what would be the >> proposed >> > >> > "write to RIB" set of protocols ? Would you support OF 1.3 even if >> one would >> > >> > be happy to lock such topologies only to software/programmable >> switching >> > >> > paths ? >> > >> > >> > Best rgs, >> > >> > R. >> > >> > _______________________________________________ >> > >> > 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 >> > >> > Return-Path: 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 7A7AD11E812C for ; Tue, 7 Aug 2012 22:27:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.036 X-Spam-Level: X-Spam-Status: No, score=-6.036 tagged_above=-999 required=5 tests=[AWL=0.563, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kAoEBxIj1FrW for ; Tue, 7 Aug 2012 22:27:31 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 83DF421E8037 for ; Tue, 7 Aug 2012 22:27:31 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml202-edg.china.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath) with ESMTP id AIZ51305; Tue, 07 Aug 2012 21:27:30 -0800 (PST) Received: from DFWEML405-HUB.china.huawei.com (10.193.5.102) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 7 Aug 2012 22:25:15 -0700 Received: from DFWEML513-MBS.china.huawei.com ([169.254.4.5]) by dfweml405-hub.china.huawei.com ([10.193.5.102]) with mapi id 14.01.0323.003; Tue, 7 Aug 2012 22:24:57 -0700 From: Tina TSOU To: Alia Atlas Thread-Topic: [irs-discuss] An idea ... MTR + IRS Thread-Index: AQHNcQtKYupMqDzFFUKNbFLCjNCRxpdPaLsA//+LZRCAAJkkAP//rxEWgACL/oD//4xXPQAPuvyAAA00CiA= Date: Wed, 8 Aug 2012 05:24:56 +0000 Message-ID: References: <501B150C.9080304@raszuk.net> <472BCA45-0462-45E0-BE89-339799915A9C@huawei.com> In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.212.245.8] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: Edward Crabbe , "robert@raszuk.net" , "irs-discuss@ietf.org" Subject: Re: [irs-discuss] An idea ... MTR + IRS X-BeenThere: irs-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Aug 2012 05:27:32 -0000 Alia, It is just to clarification. Just to confirm that draft-atlas and draft-ward state that IRS positions be= low the northboudapi in an orchestrator, and IRS includes both routing stat= e and topo export. Is it correct understanding? Thank you. Tina > -----Original Message----- > From: Alia Atlas [mailto:akatlas@gmail.com] > Sent: Tuesday, August 07, 2012 9:38 PM > To: Tina TSOU > Cc: Edward Crabbe; robert@raszuk.net; irs-discuss@ietf.org > Subject: Re: [irs-discuss] An idea ... MTR + IRS >=20 > Tina, >=20 > Nitin made a single comment on this list that you are reading too much > into. >=20 > I have written the two base drafts for IRS and am working on driving > the definition of the work that is proposed. The presentation that I > gave in Routing Area Open Meeting CLEARLY describes topology as not > only being in the proposed scope, but one of the more urgent items. >=20 > Why are you NOT listening? >=20 > Perhaps rereading the problem-statement and framework drafts would > help clarify your mental model? >=20 > IRS does not talk about a northboundapi - there are applications that > can use IRS. How those applications communicate with other > applications is NOT in the proposed scope. >=20 > Alia >=20 > On Wed, Aug 8, 2012 at 12:07 AM, Tina TSOU > wrote: > > So, r u updating Nitin's statement as following? > > > > Top layer: Northboundapi > > > > Middle layer: IRS > > > > Bottom layer: IRS (topo export) > > > > > > Tina > > > > On Aug 7, 2012, at 9:01 PM, "Alia Atlas" wrote: > > > > The requirement for topology export is DEFINITELY part of IRS. It is > > a crucial piece for a meaningful feedback loop. Clearly there are > > existing technology pieces that may have a role to play as well. > > > > Alia > > > > On Tue, Aug 7, 2012 at 10:40 PM, Tina TSOU > > > wrote: > > > > Oh, I meant in Nitin's description in the mailing list, there are 3 > > sub-layers of a orchestrator. > > > > Top layer: Northboundapi > > > > Middle layer: IRS > > > > Bottom layer: topo export > > > > > > Therefore, the topo export is not part of IRS. It is another layer > which > > sits below IRS. > > > > > > Tina > > > > > > On Aug 7, 2012, at 5:30 PM, "Alia Atlas" wrote: > > > > > > Topology export is definitely under the umbrella of IRS - and we are > > > > actively starting to think about the associated requirements and > > > > use-cases. Feel free to contribute - on the list or towards drafts! > > > > > > Alia > > > > > > On Tue, Aug 7, 2012 at 6:23 PM, Tina TSOU > > > wrote: > > > > Nitin said topo information export is on the sub-layer under IRS. > > > > > > > > > > Tina > > > > > > > > > > From: irs-discuss-bounces@ietf.org [mailto:irs-discuss- > bounces@ietf.org] On > > > > Behalf Of Edward Crabbe > > > > Sent: Tuesday, August 07, 2012 3:20 PM > > > > To: robert@raszuk.net > > > > Cc: irs-discuss@ietf.org > > > > > > > > Subject: Re: [irs-discuss] An idea ... MTR + IRS > > > > > > > > > > Robert, > > > > > > > > > > If topo information export is in scope (which I believe it is) and > PBR route > > > > injection with nh recursion to rib (and thus connected routes) is in > scope > > > > (which I'm quite sure it is) then yes, this is in scope. > > > > > > > > > > Although I'm not sure what it has to do with OF /OF controllers? ;P > > > > > > On Thu, Aug 2, 2012 at 5:02 PM, Robert Raszuk > wrote: > > > > > > Hi, > > > > > > This morning Scott mentioned that he would like to use IRS to shut > down all > > > > protocols and just be able to write to RIB. Now James said that he > would > > > > like to get a network topology as "every OpenFlow controller requires > this" > > > > > > Both connected together resulted in an idea of using multi-topology- > routing > > > > where your base topology discovers physical link connectivity graph > while > > > > other topologies could be programmed by external entities example: OF > > > > controllers or any other external to routers network intelligence > oracles to > > > > deliver actual services ? > > > > > > Would that be in scope of IRS effort ? If so what would be the > proposed > > > > "write to RIB" set of protocols ? Would you support OF 1.3 even if > one would > > > > be happy to lock such topologies only to software/programmable > switching > > > > paths ? > > > > > > Best rgs, > > > > R. > > > > _______________________________________________ > > > > 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 > > > > Return-Path: 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 44CD911E80EA for ; Tue, 7 Aug 2012 21:38:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.557 X-Spam-Level: X-Spam-Status: No, score=-3.557 tagged_above=-999 required=5 tests=[AWL=0.042, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uhD1Kp1lLT8R for ; Tue, 7 Aug 2012 21:38:16 -0700 (PDT) Received: from mail-gh0-f172.google.com (mail-gh0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 17DBE11E80E2 for ; Tue, 7 Aug 2012 21:38:16 -0700 (PDT) Received: by ghbg16 with SMTP id g16so386073ghb.31 for ; Tue, 07 Aug 2012 21:38:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=CSWi56B3qVjg6b7/g931PKN6V/B250LzJv5ZV4eBF4s=; b=F7fOHD8r3XZBla8A2o32Wm0e20OSPNvC6/t/0boJ4Jg2Z3amG9MVGRbbn83U0yMSqB 947vG4BhbyJDO2pQgxcdiUFCsQB6vLdQD6kGk1D5EiZGE76h2dUVOql46Keu3uZTyoW0 W1kBdJIvXojbGUhd4VoWYgm2UvL1DwYESqRoD0TOjSpI0i/u2hHpkbw9xumk1nHdN7i+ OY8srvJSKwx5jcAnV2bY1H5Gdw6yJmB1Hz+RyvP2JSJYPPb88mDYppL39yNmk8ok93RC ZJfi/znjcr26osqwQw2Dzblgm0GZ1mVUEstTgjTT39fCQtlljWEPDKHn2Req6kCpJZky hjug== MIME-Version: 1.0 Received: by 10.50.213.106 with SMTP id nr10mr593690igc.58.1344400695317; Tue, 07 Aug 2012 21:38:15 -0700 (PDT) Received: by 10.50.91.135 with HTTP; Tue, 7 Aug 2012 21:38:15 -0700 (PDT) In-Reply-To: <472BCA45-0462-45E0-BE89-339799915A9C@huawei.com> References: <501B150C.9080304@raszuk.net> <472BCA45-0462-45E0-BE89-339799915A9C@huawei.com> Date: Wed, 8 Aug 2012 00:38:15 -0400 Message-ID: From: Alia Atlas To: Tina TSOU Content-Type: text/plain; charset=ISO-8859-1 Cc: Edward Crabbe , "robert@raszuk.net" , "irs-discuss@ietf.org" Subject: Re: [irs-discuss] An idea ... MTR + IRS X-BeenThere: irs-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Aug 2012 04:38:17 -0000 Tina, Nitin made a single comment on this list that you are reading too much into. I have written the two base drafts for IRS and am working on driving the definition of the work that is proposed. The presentation that I gave in Routing Area Open Meeting CLEARLY describes topology as not only being in the proposed scope, but one of the more urgent items. Why are you NOT listening? Perhaps rereading the problem-statement and framework drafts would help clarify your mental model? IRS does not talk about a northboundapi - there are applications that can use IRS. How those applications communicate with other applications is NOT in the proposed scope. Alia On Wed, Aug 8, 2012 at 12:07 AM, Tina TSOU wrote: > So, r u updating Nitin's statement as following? > > Top layer: Northboundapi > > Middle layer: IRS > > Bottom layer: IRS (topo export) > > > Tina > > On Aug 7, 2012, at 9:01 PM, "Alia Atlas" wrote: > > The requirement for topology export is DEFINITELY part of IRS. It is > a crucial piece for a meaningful feedback loop. Clearly there are > existing technology pieces that may have a role to play as well. > > Alia > > On Tue, Aug 7, 2012 at 10:40 PM, Tina TSOU > wrote: > > Oh, I meant in Nitin's description in the mailing list, there are 3 > sub-layers of a orchestrator. > > Top layer: Northboundapi > > Middle layer: IRS > > Bottom layer: topo export > > > Therefore, the topo export is not part of IRS. It is another layer which > sits below IRS. > > > Tina > > > On Aug 7, 2012, at 5:30 PM, "Alia Atlas" wrote: > > > Topology export is definitely under the umbrella of IRS - and we are > > actively starting to think about the associated requirements and > > use-cases. Feel free to contribute - on the list or towards drafts! > > > Alia > > > On Tue, Aug 7, 2012 at 6:23 PM, Tina TSOU > wrote: > > Nitin said topo information export is on the sub-layer under IRS. > > > > > Tina > > > > > From: irs-discuss-bounces@ietf.org [mailto:irs-discuss-bounces@ietf.org] On > > Behalf Of Edward Crabbe > > Sent: Tuesday, August 07, 2012 3:20 PM > > To: robert@raszuk.net > > Cc: irs-discuss@ietf.org > > > > Subject: Re: [irs-discuss] An idea ... MTR + IRS > > > > > Robert, > > > > > If topo information export is in scope (which I believe it is) and PBR route > > injection with nh recursion to rib (and thus connected routes) is in scope > > (which I'm quite sure it is) then yes, this is in scope. > > > > > Although I'm not sure what it has to do with OF /OF controllers? ;P > > > On Thu, Aug 2, 2012 at 5:02 PM, Robert Raszuk wrote: > > > Hi, > > > This morning Scott mentioned that he would like to use IRS to shut down all > > protocols and just be able to write to RIB. Now James said that he would > > like to get a network topology as "every OpenFlow controller requires this" > > > Both connected together resulted in an idea of using multi-topology-routing > > where your base topology discovers physical link connectivity graph while > > other topologies could be programmed by external entities example: OF > > controllers or any other external to routers network intelligence oracles to > > deliver actual services ? > > > Would that be in scope of IRS effort ? If so what would be the proposed > > "write to RIB" set of protocols ? Would you support OF 1.3 even if one would > > be happy to lock such topologies only to software/programmable switching > > paths ? > > > Best rgs, > > R. > > _______________________________________________ > > 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 > > Return-Path: 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 2628E11E80EA for ; Tue, 7 Aug 2012 21:11:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.025 X-Spam-Level: X-Spam-Status: No, score=-6.025 tagged_above=-999 required=5 tests=[AWL=0.573, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZQ+V7tW2pmyB for ; Tue, 7 Aug 2012 21:11:39 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 9BBB511E80E2 for ; Tue, 7 Aug 2012 21:11:38 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml202-edg.china.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath) with ESMTP id AIZ47401; Tue, 07 Aug 2012 20:11:38 -0800 (PST) Received: from DFWEML405-HUB.china.huawei.com (10.193.5.102) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 7 Aug 2012 21:07:54 -0700 Received: from DFWEML513-MBS.china.huawei.com ([169.254.4.5]) by dfweml405-hub.china.huawei.com ([10.193.5.102]) with mapi id 14.01.0323.003; Tue, 7 Aug 2012 21:07:50 -0700 From: Tina TSOU To: Alia Atlas Thread-Topic: [irs-discuss] An idea ... MTR + IRS Thread-Index: AQHNcQtKYupMqDzFFUKNbFLCjNCRxpdPaLsA//+LZRCAAJkkAP//rxEWgACL/oD//4xXPQ== Date: Wed, 8 Aug 2012 04:07:51 +0000 Message-ID: <472BCA45-0462-45E0-BE89-339799915A9C@huawei.com> References: <501B150C.9080304@raszuk.net> , In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_472BCA45046245E0BE89339799915A9Chuaweicom_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: Edward Crabbe , "robert@raszuk.net" , "irs-discuss@ietf.org" Subject: Re: [irs-discuss] An idea ... MTR + IRS X-BeenThere: irs-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Aug 2012 04:11:40 -0000 --_000_472BCA45046245E0BE89339799915A9Chuaweicom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable So, r u updating Nitin's statement as following? Top layer: Northboundapi Middle layer: IRS Bottom layer: IRS (topo export) Tina On Aug 7, 2012, at 9:01 PM, "Alia Atlas" > wrote: The requirement for topology export is DEFINITELY part of IRS. It is a crucial piece for a meaningful feedback loop. Clearly there are existing technology pieces that may have a role to play as well. Alia On Tue, Aug 7, 2012 at 10:40 PM, Tina TSOU > wrote: Oh, I meant in Nitin's description in the mailing list, there are 3 sub-lay= ers of a orchestrator. Top layer: Northboundapi Middle layer: IRS Bottom layer: topo export Therefore, the topo export is not part of IRS. It is another layer which si= ts below IRS. Tina On Aug 7, 2012, at 5:30 PM, "Alia Atlas" > wrote: Topology export is definitely under the umbrella of IRS - and we are actively starting to think about the associated requirements and use-cases. Feel free to contribute - on the list or towards drafts! Alia On Tue, Aug 7, 2012 at 6:23 PM, Tina TSOU > wrote: Nitin said topo information export is on the sub-layer under IRS. Tina From: irs-discuss-bounces@ietf.org [ma= ilto:irs-discuss-bounces@ietf.org] On Behalf Of Edward Crabbe Sent: Tuesday, August 07, 2012 3:20 PM To: robert@raszuk.net Cc: irs-discuss@ietf.org Subject: Re: [irs-discuss] An idea ... MTR + IRS Robert, If topo information export is in scope (which I believe it is) and PBR rout= e injection with nh recursion to rib (and thus connected routes) is in scope (which I'm quite sure it is) then yes, this is in scope. Although I'm not sure what it has to do with OF /OF controllers? ;P On Thu, Aug 2, 2012 at 5:02 PM, Robert Raszuk > wrote: Hi, This morning Scott mentioned that he would like to use IRS to shut down all protocols and just be able to write to RIB. Now James said that he would like to get a network topology as "every OpenFlow controller requires this" Both connected together resulted in an idea of using multi-topology-routing where your base topology discovers physical link connectivity graph while other topologies could be programmed by external entities example: OF controllers or any other external to routers network intelligence oracles t= o deliver actual services ? Would that be in scope of IRS effort ? If so what would be the proposed "write to RIB" set of protocols ? Would you support OF 1.3 even if one woul= d be happy to lock such topologies only to software/programmable switching paths ? Best rgs, R. _______________________________________________ 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 --_000_472BCA45046245E0BE89339799915A9Chuaweicom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
So, r u updating Nitin's statement as following?
Top layer: Northboundapi
Middle layer: IRS
Bottom layer: IRS (topo export)

Tina

On Aug 7, 2012, at 9:01 PM, "Alia Atlas" <akatlas@gmail.com> wrote:

The requirement for topology export is DEFINITELY part of IRS. &= nbsp;It is
a crucial piece for a meaningful feedback loop.   Clearly t= here are
existing technology pieces that may have a role to play as well.

Alia

On Tue, Aug 7, 2012 at 10:40 PM, Tina TSOU <Tina.Tsou.Zouting@huawei.com> wrote:
Oh, I meant in Nitin's description in the m= ailing list, there are 3 sub-layers of a orchestrator.
Top layer: Northboundapi
Middle layer: IRS
Bottom layer: topo export

Therefore, the topo export is not part of I= RS. It is another layer which sits below IRS.

Tina

On Aug 7, 2012, at 5:30 PM, "Alia Atla= s" <akatlas@gmail.com> = wrote:

Topology export is definitely under the umb= rella of IRS - and we are
actively starting to think about the associ= ated requirements and
use-cases.   Feel free to contrib= ute - on the list or towards drafts!

Alia

On Tue, Aug 7, 2012 at 6:23 PM, Tina TSOU &= lt;Tina.Tsou.Zouting@huawei= .com> wrote:
Nitin said topo information export is on th= e sub-layer under IRS.



Tina



From: irs-discuss-bounces@ietf.org [mailto:irs-discuss-bounces@ietf.org] On
Behalf Of Edward Crabbe
Sent: Tuesday, August 07, 2012 3:20 PM
To: ro= bert@raszuk.net
Cc: irs-discuss@ietf.org


Subject: Re: [irs-discuss] An idea ... MTR = + IRS



Robert,



If topo information export is in scope (whi= ch I believe it is) and PBR route
injection with nh recursion to rib (and thu= s connected routes) is in scope
(which I'm quite sure it is) then yes, this= is in scope.



Although I'm not sure what it has to do wit= h OF /OF controllers? ;P

On Thu, Aug 2, 2012 at 5:02 PM, Robert Rasz= uk <robert@raszuk.net> wrote= :

Hi,

This morning Scott mentioned that he would = like to use IRS to shut down all
protocols and just be able to write to RIB.= Now James said that he would
like to get a network topology as "eve= ry OpenFlow controller requires this"

Both connected together resulted in an idea= of using multi-topology-routing
where your base topology discovers physical= link connectivity graph while
other topologies could be programmed by ext= ernal entities example: OF
controllers or any other external to router= s network intelligence oracles to
deliver actual services ?

Would that be in scope of IRS effort ? If s= o what would be the proposed
"write to RIB" set of protocols ?= Would you support OF 1.3 even if one would
be happy to lock such topologies only to so= ftware/programmable switching
paths ?

Best rgs,
R.
___________________________________________= ____
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

--_000_472BCA45046245E0BE89339799915A9Chuaweicom_-- Return-Path: 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 5BF1921F85E6 for ; Tue, 7 Aug 2012 21:01:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.556 X-Spam-Level: X-Spam-Status: No, score=-3.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EOkpQYJv0j6S for ; Tue, 7 Aug 2012 21:01:50 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 8CA9721F85D0 for ; Tue, 7 Aug 2012 21:01:50 -0700 (PDT) Received: by yhq56 with SMTP id 56so358457yhq.31 for ; Tue, 07 Aug 2012 21:01:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=BPXUwdMWPGcyKo7v1fTl0xvai8VdLt8fx3W2GmJ+5h0=; b=CkgDcsQgzVrylr6TejJVdq/quYSJkgJ+i6q7Gw/vrMNKHgLc/A2iHVIdCAqMNjvJY9 5yDakX8pxirubZ3g1V00lG+PFY08bgB9VbzCYeTdMpu5XNqhADaATojd0Vpw0t4mj3Ty g2XHyD/1DfuZRmP2z4pfxplXbwSOm+06y4EdOyu25/KPsvwMA0dfjfZJTEnAVH92OtcK ZIP7lFqkOwjf2Z+48+4siFPfIdHwJF5UVl0tsMfp/ML8JpPPTzSkLuDAUHxBzqK4JalI 4+/hK5pDvMpn0HOLJW0nTb3ej8B0SzShalTYCz1kS46MwWoavu3lChEwQgWHbDkSUXhF rhdQ== MIME-Version: 1.0 Received: by 10.50.5.137 with SMTP id s9mr630461igs.2.1344398509937; Tue, 07 Aug 2012 21:01:49 -0700 (PDT) Received: by 10.50.91.135 with HTTP; Tue, 7 Aug 2012 21:01:49 -0700 (PDT) In-Reply-To: References: <501B150C.9080304@raszuk.net> Date: Wed, 8 Aug 2012 00:01:49 -0400 Message-ID: From: Alia Atlas To: Tina TSOU Content-Type: text/plain; charset=ISO-8859-1 Cc: Edward Crabbe , "robert@raszuk.net" , "irs-discuss@ietf.org" Subject: Re: [irs-discuss] An idea ... MTR + IRS X-BeenThere: irs-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Aug 2012 04:01:51 -0000 The requirement for topology export is DEFINITELY part of IRS. It is a crucial piece for a meaningful feedback loop. Clearly there are existing technology pieces that may have a role to play as well. Alia On Tue, Aug 7, 2012 at 10:40 PM, Tina TSOU wrote: > Oh, I meant in Nitin's description in the mailing list, there are 3 sub-layers of a orchestrator. > Top layer: Northboundapi > Middle layer: IRS > Bottom layer: topo export > > Therefore, the topo export is not part of IRS. It is another layer which sits below IRS. > > Tina > > On Aug 7, 2012, at 5:30 PM, "Alia Atlas" wrote: > >> Topology export is definitely under the umbrella of IRS - and we are >> actively starting to think about the associated requirements and >> use-cases. Feel free to contribute - on the list or towards drafts! >> >> Alia >> >> On Tue, Aug 7, 2012 at 6:23 PM, Tina TSOU wrote: >>> Nitin said topo information export is on the sub-layer under IRS. >>> >>> >>> >>> Tina >>> >>> >>> >>> From: irs-discuss-bounces@ietf.org [mailto:irs-discuss-bounces@ietf.org] On >>> Behalf Of Edward Crabbe >>> Sent: Tuesday, August 07, 2012 3:20 PM >>> To: robert@raszuk.net >>> Cc: irs-discuss@ietf.org >>> >>> >>> Subject: Re: [irs-discuss] An idea ... MTR + IRS >>> >>> >>> >>> Robert, >>> >>> >>> >>> If topo information export is in scope (which I believe it is) and PBR route >>> injection with nh recursion to rib (and thus connected routes) is in scope >>> (which I'm quite sure it is) then yes, this is in scope. >>> >>> >>> >>> Although I'm not sure what it has to do with OF /OF controllers? ;P >>> >>> On Thu, Aug 2, 2012 at 5:02 PM, Robert Raszuk wrote: >>> >>> Hi, >>> >>> This morning Scott mentioned that he would like to use IRS to shut down all >>> protocols and just be able to write to RIB. Now James said that he would >>> like to get a network topology as "every OpenFlow controller requires this" >>> >>> Both connected together resulted in an idea of using multi-topology-routing >>> where your base topology discovers physical link connectivity graph while >>> other topologies could be programmed by external entities example: OF >>> controllers or any other external to routers network intelligence oracles to >>> deliver actual services ? >>> >>> Would that be in scope of IRS effort ? If so what would be the proposed >>> "write to RIB" set of protocols ? Would you support OF 1.3 even if one would >>> be happy to lock such topologies only to software/programmable switching >>> paths ? >>> >>> Best rgs, >>> R. >>> _______________________________________________ >>> 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 >>> Return-Path: 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 6338611E8110 for ; Tue, 7 Aug 2012 19:42:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.016 X-Spam-Level: X-Spam-Status: No, score=-6.016 tagged_above=-999 required=5 tests=[AWL=0.583, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u0Ds86epjjjf for ; Tue, 7 Aug 2012 19:42:33 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id A1FAC11E80F3 for ; Tue, 7 Aug 2012 19:42:33 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml201-edg.china.huawei.com) ([172.18.9.243]) by dfwrg02-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AIP61718; Tue, 07 Aug 2012 18:42:33 -0800 (PST) Received: from DFWEML408-HUB.china.huawei.com (10.193.5.134) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 7 Aug 2012 19:40:47 -0700 Received: from DFWEML513-MBS.china.huawei.com ([169.254.4.5]) by dfweml408-hub.china.huawei.com ([10.193.5.134]) with mapi id 14.01.0323.003; Tue, 7 Aug 2012 19:40:46 -0700 From: Tina TSOU To: Alia Atlas Thread-Topic: [irs-discuss] An idea ... MTR + IRS Thread-Index: AQHNcQtKYupMqDzFFUKNbFLCjNCRxpdPaLsA//+LZRCAAJkkAP//rxEW Date: Wed, 8 Aug 2012 02:40:46 +0000 Message-ID: References: <501B150C.9080304@raszuk.net> , In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: Edward Crabbe , "robert@raszuk.net" , "irs-discuss@ietf.org" Subject: Re: [irs-discuss] An idea ... MTR + IRS X-BeenThere: irs-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Aug 2012 02:42:34 -0000 Oh, I meant in Nitin's description in the mailing list, there are 3 sub-lay= ers of a orchestrator. Top layer: Northboundapi Middle layer: IRS Bottom layer: topo export Therefore, the topo export is not part of IRS. It is another layer which si= ts below IRS. Tina On Aug 7, 2012, at 5:30 PM, "Alia Atlas" wrote: > Topology export is definitely under the umbrella of IRS - and we are > actively starting to think about the associated requirements and > use-cases. Feel free to contribute - on the list or towards drafts! >=20 > Alia >=20 > On Tue, Aug 7, 2012 at 6:23 PM, Tina TSOU = wrote: >> Nitin said topo information export is on the sub-layer under IRS. >>=20 >>=20 >>=20 >> Tina >>=20 >>=20 >>=20 >> From: irs-discuss-bounces@ietf.org [mailto:irs-discuss-bounces@ietf.org]= On >> Behalf Of Edward Crabbe >> Sent: Tuesday, August 07, 2012 3:20 PM >> To: robert@raszuk.net >> Cc: irs-discuss@ietf.org >>=20 >>=20 >> Subject: Re: [irs-discuss] An idea ... MTR + IRS >>=20 >>=20 >>=20 >> Robert, >>=20 >>=20 >>=20 >> If topo information export is in scope (which I believe it is) and PBR r= oute >> injection with nh recursion to rib (and thus connected routes) is in sco= pe >> (which I'm quite sure it is) then yes, this is in scope. >>=20 >>=20 >>=20 >> Although I'm not sure what it has to do with OF /OF controllers? ;P >>=20 >> On Thu, Aug 2, 2012 at 5:02 PM, Robert Raszuk wrote: >>=20 >> Hi, >>=20 >> This morning Scott mentioned that he would like to use IRS to shut down = all >> protocols and just be able to write to RIB. Now James said that he would >> like to get a network topology as "every OpenFlow controller requires th= is" >>=20 >> Both connected together resulted in an idea of using multi-topology-rout= ing >> where your base topology discovers physical link connectivity graph whil= e >> other topologies could be programmed by external entities example: OF >> controllers or any other external to routers network intelligence oracle= s to >> deliver actual services ? >>=20 >> Would that be in scope of IRS effort ? If so what would be the proposed >> "write to RIB" set of protocols ? Would you support OF 1.3 even if one w= ould >> be happy to lock such topologies only to software/programmable switching >> paths ? >>=20 >> Best rgs, >> R. >> _______________________________________________ >> irs-discuss mailing list >> irs-discuss@ietf.org >> https://www.ietf.org/mailman/listinfo/irs-discuss >>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> irs-discuss mailing list >> irs-discuss@ietf.org >> https://www.ietf.org/mailman/listinfo/irs-discuss >>=20 Return-Path: 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 EF73821F8540 for ; Tue, 7 Aug 2012 17:30:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.555 X-Spam-Level: X-Spam-Status: No, score=-3.555 tagged_above=-999 required=5 tests=[AWL=0.044, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BCrxPq8-EyRl for ; Tue, 7 Aug 2012 17:30:30 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 3627021F847D for ; Tue, 7 Aug 2012 17:30:27 -0700 (PDT) Received: by yenm5 with SMTP id m5so227074yen.31 for ; Tue, 07 Aug 2012 17:30:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=h2FeWML4srwc84AtaWXnhW6GMfvnCIywkV19IBGT0Kw=; b=rUK0veiKCY/PuEw9csFyqd6AoRnqHsPGX9QBBRM7xRNZddvbrL+yGfjOvR6RIorLu7 pUNTRmVktuyi8H5nK+z/ZQd3KdBWioOySg3wAMmyOqVk7obH13uWud8kWxlNAkvBsH9b 0MGPShG65B6oXmOJwOtvJvAAROYpOBMzUvsHYAt7PpzUZmXhmMZNVDyBvVBNnKiIm9B0 QPvbhONAZBeYgrpngLSy7+81MPbCUhLA3WBflw4BqocL9JbzlAVr+ook5xLkAyiN3KgY AWHXZxJS4hMH2Pw1TwgOkzweAP9dzZh3HP4VIGGzcp21wqQZdjgGcgrjwwFXCL1TyK2i lw6g== MIME-Version: 1.0 Received: by 10.42.140.4 with SMTP id i4mr12889065icu.18.1344385826363; Tue, 07 Aug 2012 17:30:26 -0700 (PDT) Received: by 10.50.91.135 with HTTP; Tue, 7 Aug 2012 17:30:26 -0700 (PDT) In-Reply-To: References: <501B150C.9080304@raszuk.net> Date: Tue, 7 Aug 2012 20:30:26 -0400 Message-ID: From: Alia Atlas To: Tina TSOU , Edward Crabbe , "robert@raszuk.net" , "irs-discuss@ietf.org" Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [irs-discuss] An idea ... MTR + IRS X-BeenThere: irs-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Aug 2012 00:30:31 -0000 Topology export is definitely under the umbrella of IRS - and we are actively starting to think about the associated requirements and use-cases. Feel free to contribute - on the list or towards drafts! Alia On Tue, Aug 7, 2012 at 6:23 PM, Tina TSOU wrote: > Nitin said topo information export is on the sub-layer under IRS. > > > > Tina > > > > From: irs-discuss-bounces@ietf.org [mailto:irs-discuss-bounces@ietf.org] On > Behalf Of Edward Crabbe > Sent: Tuesday, August 07, 2012 3:20 PM > To: robert@raszuk.net > Cc: irs-discuss@ietf.org > > > Subject: Re: [irs-discuss] An idea ... MTR + IRS > > > > Robert, > > > > If topo information export is in scope (which I believe it is) and PBR route > injection with nh recursion to rib (and thus connected routes) is in scope > (which I'm quite sure it is) then yes, this is in scope. > > > > Although I'm not sure what it has to do with OF /OF controllers? ;P > > On Thu, Aug 2, 2012 at 5:02 PM, Robert Raszuk wrote: > > Hi, > > This morning Scott mentioned that he would like to use IRS to shut down all > protocols and just be able to write to RIB. Now James said that he would > like to get a network topology as "every OpenFlow controller requires this" > > Both connected together resulted in an idea of using multi-topology-routing > where your base topology discovers physical link connectivity graph while > other topologies could be programmed by external entities example: OF > controllers or any other external to routers network intelligence oracles to > deliver actual services ? > > Would that be in scope of IRS effort ? If so what would be the proposed > "write to RIB" set of protocols ? Would you support OF 1.3 even if one would > be happy to lock such topologies only to software/programmable switching > paths ? > > Best rgs, > R. > _______________________________________________ > 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 > Return-Path: 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 2DECB21F85F3 for ; Tue, 7 Aug 2012 15:25:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.005 X-Spam-Level: X-Spam-Status: No, score=-6.005 tagged_above=-999 required=5 tests=[AWL=0.593, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8RpPch07N8Ws for ; Tue, 7 Aug 2012 15:25:37 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 20EDB21F851E for ; Tue, 7 Aug 2012 15:25:37 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml202-edg.china.huawei.com) ([172.18.9.243]) by dfwrg02-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AIP49062; Tue, 07 Aug 2012 14:25:36 -0800 (PST) Received: from DFWEML407-HUB.china.huawei.com (10.193.5.132) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 7 Aug 2012 15:23:39 -0700 Received: from DFWEML513-MBS.china.huawei.com ([169.254.4.5]) by dfweml407-hub.china.huawei.com ([10.193.5.132]) with mapi id 14.01.0323.003; Tue, 7 Aug 2012 15:23:33 -0700 From: Tina TSOU To: Edward Crabbe , "robert@raszuk.net" Thread-Topic: [irs-discuss] An idea ... MTR + IRS Thread-Index: AQHNcQtKYupMqDzFFUKNbFLCjNCRxpdPaLsA//+LZRA= Date: Tue, 7 Aug 2012 22:23:32 +0000 Message-ID: References: <501B150C.9080304@raszuk.net> In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.212.244.126] Content-Type: multipart/alternative; boundary="_000_C0E0A32284495243BDE0AC8A066631A81589DBDCdfweml513mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "irs-discuss@ietf.org" Subject: Re: [irs-discuss] An idea ... MTR + IRS X-BeenThere: irs-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Aug 2012 22:25:38 -0000 --_000_C0E0A32284495243BDE0AC8A066631A81589DBDCdfweml513mbschi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Nitin said topo information export is on the sub-layer under IRS. Tina From: irs-discuss-bounces@ietf.org [mailto:irs-discuss-bounces@ietf.org] On= Behalf Of Edward Crabbe Sent: Tuesday, August 07, 2012 3:20 PM To: robert@raszuk.net Cc: irs-discuss@ietf.org Subject: Re: [irs-discuss] An idea ... MTR + IRS Robert, If topo information export is in scope (which I believe it is) and PBR rout= e injection with nh recursion to rib (and thus connected routes) is in scop= e (which I'm quite sure it is) then yes, this is in scope. Although I'm not sure what it has to do with OF /OF controllers? ;P On Thu, Aug 2, 2012 at 5:02 PM, Robert Raszuk > wrote: Hi, This morning Scott mentioned that he would like to use IRS to shut down all= protocols and just be able to write to RIB. Now James said that he would l= ike to get a network topology as "every OpenFlow controller requires this" Both connected together resulted in an idea of using multi-topology-routing= where your base topology discovers physical link connectivity graph while = other topologies could be programmed by external entities example: OF contr= ollers or any other external to routers network intelligence oracles to del= iver actual services ? Would that be in scope of IRS effort ? If so what would be the proposed "wr= ite to RIB" set of protocols ? Would you support OF 1.3 even if one would b= e happy to lock such topologies only to software/programmable switching pat= hs ? Best rgs, R. _______________________________________________ irs-discuss mailing list irs-discuss@ietf.org https://www.ietf.org/mailman/listinfo/irs-discuss --_000_C0E0A32284495243BDE0AC8A066631A81589DBDCdfweml513mbschi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Nitin said topo informati= on export is on the sub-layer under IRS.

 <= /p>

Tina

 <= /p>

From: irs-disc= uss-bounces@ietf.org [mailto:irs-discuss-bounces@ietf.org] On Behalf Of Edward Crabbe
Sent: Tuesday, August 07, 2012 3:20 PM
To: robert@raszuk.net
Cc: irs-discuss@ietf.org
Subject: Re: [irs-discuss] An idea ... MTR + IRS

 

Robert,

 

If topo information export is in scope (which I beli= eve it is) and PBR route injection with nh recursion to rib (and thus conne= cted routes) is in scope (which I'm quite sure it is) then yes, this is in = scope. 

 

Although I'm not sure= what it has to do with OF /OF controllers? ;P

On Thu, Aug 2, 2012 at 5:02 PM, Robert Raszuk <robert@raszuk.net&= gt; wrote:

Hi,

This morning Scott mentioned that he would like to use IRS to shut down all= protocols and just be able to write to RIB. Now James said that he would l= ike to get a network topology as "every OpenFlow controller requires t= his"

Both connected together resulted in an idea of using multi-topology-routing= where your base topology discovers physical link connectivity graph while = other topologies could be programmed by external entities example: OF contr= ollers or any other external to routers network intelligence oracles to deliver actual services ?

Would that be in scope of IRS effort ? If so what would be the proposed &qu= ot;write to RIB" set of protocols ? Would you support OF 1.3 even if o= ne would be happy to lock such topologies only to software/programmable swi= tching paths ?

Best rgs,
R.
_______________________________________________
irs-discuss mailing list
irs-discuss@ietf.= org
https://www.ietf.org/mailman/listinfo/irs-discuss

 

--_000_C0E0A32284495243BDE0AC8A066631A81589DBDCdfweml513mbschi_-- Return-Path: 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 935A621F8598 for ; Tue, 7 Aug 2012 15:22:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.359 X-Spam-Level: X-Spam-Status: No, score=-6.359 tagged_above=-999 required=5 tests=[AWL=0.240, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zbc8M6G6dnGi for ; Tue, 7 Aug 2012 15:22:52 -0700 (PDT) Received: from exprod7og101.obsmtp.com (exprod7og101.obsmtp.com [64.18.2.155]) by ietfa.amsl.com (Postfix) with ESMTP id DE72821F858E for ; Tue, 7 Aug 2012 15:22:51 -0700 (PDT) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob101.postini.com ([64.18.6.12]) with SMTP ID DSNKUCGVKJQpJO0NEPd6PeufOO7G4tqOZzqj@postini.com; Tue, 07 Aug 2012 15:22:51 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; Tue, 7 Aug 2012 15:22:30 -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; Tue, 7 Aug 2012 15:22:29 -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; Tue, 7 Aug 2012 18:22:28 -0400 From: Thomas Nadeau To: Edward Crabbe , "robert@raszuk.net" Date: Tue, 7 Aug 2012 18:22:28 -0400 Thread-Topic: [irs-discuss] An idea ... MTR + IRS Thread-Index: Ac106yDW0rpjVyedTvSyEf6htA24Hg== Message-ID: In-Reply-To: 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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "irs-discuss@ietf.org" Subject: Re: [irs-discuss] An idea ... MTR + IRS X-BeenThere: irs-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Aug 2012 22:22:52 -0000 I agree. The only related thing is that you can run both on the same box, e= ffectively creating another "hybrid" scenario, or as we like to call it, tr= i-brid. *) --Tom From: Edward Crabbe > Date: Tuesday, August 7, 2012 6:19 PM To: "robert@raszuk.net" > Cc: "irs-discuss@ietf.org" > Subject: Re: [irs-discuss] An idea ... MTR + IRS Robert, If topo information export is in scope (which I believe it is) and PBR rout= e injection with nh recursion to rib (and thus connected routes) is in scop= e (which I'm quite sure it is) then yes, this is in scope. Although I'm not sure what it has to do with OF /OF controllers? ;P On Thu, Aug 2, 2012 at 5:02 PM, Robert Raszuk > wrote: Hi, This morning Scott mentioned that he would like to use IRS to shut down all= protocols and just be able to write to RIB. Now James said that he would l= ike to get a network topology as "every OpenFlow controller requires this" Both connected together resulted in an idea of using multi-topology-routing= where your base topology discovers physical link connectivity graph while = other topologies could be programmed by external entities example: OF contr= ollers or any other external to routers network intelligence oracles to del= iver actual services ? Would that be in scope of IRS effort ? If so what would be the proposed "wr= ite to RIB" set of protocols ? Would you support OF 1.3 even if one would b= e happy to lock such topologies only to software/programmable switching pat= hs ? Best rgs, R. _______________________________________________ irs-discuss mailing list irs-discuss@ietf.org https://www.ietf.org/mailman/listinfo/irs-discuss Return-Path: 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 009ED21F846C for ; Tue, 7 Aug 2012 15:20:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.143 X-Spam-Level: X-Spam-Status: No, score=-102.143 tagged_above=-999 required=5 tests=[AWL=-0.833, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_HTML_USL_OBFU=1.666, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sh-rywN3lmUA for ; Tue, 7 Aug 2012 15:20:22 -0700 (PDT) Received: from mail-gg0-f172.google.com (mail-gg0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 4705211E80D5 for ; Tue, 7 Aug 2012 15:20:22 -0700 (PDT) Received: by ggnc4 with SMTP id c4so151809ggn.31 for ; Tue, 07 Aug 2012 15:20:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=LmskkzfKhlGUCJO8Zdsc9O5JSfmTL/TMCbeT34Ybg3w=; b=Jf11BMH4bl3Y0zet8ObmNk7DdmQh2z+twM+IDxmyD2tidqRsQhJPdGczYPkXfa0QA4 HZveSrKSIuO3m6KAqRbQOHV6PyjTi9X8mpmwHaey/n9xbSVyM2gx1m+WOtqhBBL7xQEv 4VlCM74huV5iyTvcphY4IQLRNO06GTyBqZtjnbzdCInCGdSNzZUxMrLwjfVyK1sSbLK/ lXds/Z2A7P+xJPyLIX92L02zCEf1OrPCA5ymKK8bmkhTfbeCmqSA7blopevDjlGjTD2o o1WqKMi5oBBS4tH7zhbbCmovu+xMTaClrtV/KAr6m54vNo3Z01ZB88uIwK936csCyCEj S0IA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=LmskkzfKhlGUCJO8Zdsc9O5JSfmTL/TMCbeT34Ybg3w=; b=pg1179I4XRTFL0PQpSqcKG7xH4sGCK9Zqx23cHgHaN4ZHa/GGufsb/QTgC8Iqkxh4F RRRoTqSoIcxSnRfWu8ZzGqzvE+s/mytFGPPY5v+J1h1lMzU1FAdjiS8+TVxXnbq+7oqQ CJ7daGLbNMCBH7sWFoMZNguK38XQQXwfkCNvyNeEWDQ28bgPL6HiVuNo4JohKnoYqVbq MaOeYVFUsovAnc3/ZNCe0Xo/dw/uk11JZf/pkTQ+V2pSxin0UY8Zv35wge6/mR8Ho2Sv D3z7ULv8MXK/suR7glY1kPXtETM0L8r0ZEB4kS6lnm2xEv/3et7LfR5NQwSw1bS1XIen nS+w== Received: by 10.42.155.135 with SMTP id u7mr3070309icw.25.1344378021392; Tue, 07 Aug 2012 15:20:21 -0700 (PDT) Received: by 10.42.155.135 with SMTP id u7mr3070300icw.25.1344378021283; Tue, 07 Aug 2012 15:20:21 -0700 (PDT) MIME-Version: 1.0 Received: by 10.50.237.67 with HTTP; Tue, 7 Aug 2012 15:19:40 -0700 (PDT) In-Reply-To: <501B150C.9080304@raszuk.net> References: <501B150C.9080304@raszuk.net> From: Edward Crabbe Date: Tue, 7 Aug 2012 15:19:40 -0700 Message-ID: To: robert@raszuk.net Content-Type: multipart/alternative; boundary=90e6ba6e8c5a67089404c6b46661 X-System-Of-Record: true X-Gm-Message-State: ALoCoQkaQArsv7hdS56qXz/lQw02aFZ4FcRDZnrNYVRE0ai9UpMl0pcWj78Oneaq34IH9JiO/IbNr/mb6UiAxDqxlQHZJQFmOXF4qCWZavllUY3b9fQTv+0E/DyhEsPagxGN2uVxtJ1ORQwHEcrR1yUhCt3Zr3g1ratlzyc0jmKawsvtimPaFjiZDIiWLW1lRWOK2dHak75f Cc: "irs-discuss@ietf.org" Subject: Re: [irs-discuss] An idea ... MTR + IRS X-BeenThere: irs-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Aug 2012 22:20:23 -0000 --90e6ba6e8c5a67089404c6b46661 Content-Type: text/plain; charset=ISO-8859-1 Robert, If topo information export is in scope (which I believe it is) and PBR route injection with nh recursion to rib (and thus connected routes) is in scope (which I'm quite sure it is) then yes, this is in scope. Although I'm not sure what it has to do with OF /OF controllers? ;P On Thu, Aug 2, 2012 at 5:02 PM, Robert Raszuk wrote: > Hi, > > This morning Scott mentioned that he would like to use IRS to shut down > all protocols and just be able to write to RIB. Now James said that he > would like to get a network topology as "every OpenFlow controller requires > this" > > Both connected together resulted in an idea of using > multi-topology-routing where your base topology discovers physical link > connectivity graph while other topologies could be programmed by external > entities example: OF controllers or any other external to routers network > intelligence oracles to deliver actual services ? > > Would that be in scope of IRS effort ? If so what would be the proposed > "write to RIB" set of protocols ? Would you support OF 1.3 even if one > would be happy to lock such topologies only to software/programmable > switching paths ? > > Best rgs, > R. > ______________________________**_________________ > irs-discuss mailing list > irs-discuss@ietf.org > https://www.ietf.org/mailman/**listinfo/irs-discuss > --90e6ba6e8c5a67089404c6b46661 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Robert,

If topo information export is in scope (wh= ich I believe it is) and PBR route injection with nh recursion to rib (and = thus connected routes) is in scope (which I'm quite sure it is) then ye= s, this is in scope.=A0

Although I'm not sure what it has to do with OF /OF cont= rollers? ;P

On Thu, Aug 2, 2012 at 5:02 P= M, Robert Raszuk <robert@raszuk.net> wrote:
Hi,

This morning Scott mentioned that he would like to use IRS to shut down all= protocols and just be able to write to RIB. Now James said that he would l= ike to get a network topology as "every OpenFlow controller requires t= his"

Both connected together resulted in an idea of using multi-topology-routing= where your base topology discovers physical link connectivity graph while = other topologies could be programmed by external entities example: OF contr= ollers or any other external to routers network intelligence oracles to del= iver actual services ?

Would that be in scope of IRS effort ? If so what would be the proposed &qu= ot;write to RIB" set of protocols ? Would you support OF 1.3 even if o= ne would be happy to lock such topologies only to software/programmable swi= tching paths ?

Best rgs,
R.
_______________________________________________
irs-discuss mailing list
irs-discuss@ietf.= org
https://www.ietf.org/mailman/listinfo/irs-discuss

--90e6ba6e8c5a67089404c6b46661-- Return-Path: 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 A320C11E80A6 for ; Tue, 7 Aug 2012 14:00:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e9ICbiQhiG-b for ; Tue, 7 Aug 2012 14:00:18 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 0F44611E809B for ; Tue, 7 Aug 2012 14:00:18 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml202-edg.china.huawei.com) ([172.18.9.243]) by dfwrg02-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AIP44547; Tue, 07 Aug 2012 13:00:17 -0800 (PST) Received: from DFWEML407-HUB.china.huawei.com (10.193.5.132) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 7 Aug 2012 13:58:13 -0700 Received: from DFWEML513-MBS.china.huawei.com ([169.254.4.5]) by dfweml407-hub.china.huawei.com ([10.193.5.132]) with mapi id 14.01.0323.003; Tue, 7 Aug 2012 13:58:07 -0700 From: Lin Han To: "robert@raszuk.net" , "irs-discuss@ietf.org" Thread-Topic: [irs-discuss] An idea ... MTR + IRS Thread-Index: AQHNcQtJpcLUczuvNUyuQHWPVYoeQZdO2l3A Date: Tue, 7 Aug 2012 20:58:06 +0000 Message-ID: <1D30AF33624CDD4A99E8C395069A2A161FE0E9F5@dfweml513-mbs.china.huawei.com> References: <501B150C.9080304@raszuk.net> In-Reply-To: <501B150C.9080304@raszuk.net> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.212.244.2] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [irs-discuss] An idea ... MTR + IRS X-BeenThere: irs-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Aug 2012 21:00:18 -0000 I think the MT will provide the network virtualization which is based on th= e basic topo of the forwarding device. It should belong to either orchestration or application (SDN point of view)= . OF controller should only support OF, no more intelligence such as decisi= on for routing and switching. I don't know if IRS frame work should cover this since IRS frame work has a= lot debatable areas. Lin -----Original Message----- From: irs-discuss-bounces@ietf.org [mailto:irs-discuss-bounces@ietf.org] On= Behalf Of Robert Raszuk Sent: Thursday, August 02, 2012 5:02 PM To: irs-discuss@ietf.org Subject: [irs-discuss] An idea ... MTR + IRS Hi, This morning Scott mentioned that he would like to use IRS to shut down=20 all protocols and just be able to write to RIB. Now James said that he=20 would like to get a network topology as "every OpenFlow controller=20 requires this" Both connected together resulted in an idea of using=20 multi-topology-routing where your base topology discovers physical link=20 connectivity graph while other topologies could be programmed by=20 external entities example: OF controllers or any other external to=20 routers network intelligence oracles to deliver actual services ? Would that be in scope of IRS effort ? If so what would be the proposed=20 "write to RIB" set of protocols ? Would you support OF 1.3 even if one=20 would be happy to lock such topologies only to software/programmable=20 switching paths ? Best rgs, R. _______________________________________________ irs-discuss mailing list irs-discuss@ietf.org https://www.ietf.org/mailman/listinfo/irs-discuss Return-Path: 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 6F3FA21F859A; Tue, 7 Aug 2012 11:34:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.671 X-Spam-Level: X-Spam-Status: No, score=-2.671 tagged_above=-999 required=5 tests=[AWL=0.305, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EYitW0Gt8--0; Tue, 7 Aug 2012 11:34:36 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id CD50E21F8608; Tue, 7 Aug 2012 11:34:35 -0700 (PDT) Received: by obbwc20 with SMTP id wc20so8938530obb.31 for ; Tue, 07 Aug 2012 11:34:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=wR5qESaNP2wvFY5Sv5q0yQJ3gjwL+WoMWfFzRWZ5dhU=; b=LqCBEZWIoLAX/q4K5hQFZTuq5pczqGpMRJBaKVHDBimJ2SUEIFUh+azAQPZTUw+PNf h4V4HJTD7qUIozxZrosGcnYhWC/KcPaS4l+H1zq6r/E+k2bQyK5DwLCDKIIIo04iNsAc ULwP/2BgVgxez176vqpHHWTxUSmCnBeM5NjrCrAso6w8q05GqOS+vwG4WTd1AqVlCnts 9B1VszEZoUmt9Rr0r76lmQMOz6bux5+LXsythAB4a4Hx1PUyoED2gpB7JOTKRwXGQdXD A0KRZsSouKS8Jsp3Ncf5ENX4SyBVjG9Z7rf/w0KIIWgE6w0RbG9FuCi2QU/ab5Wy4mla RcAA== MIME-Version: 1.0 Received: by 10.182.231.6 with SMTP id tc6mr26192898obc.63.1344364468041; Tue, 07 Aug 2012 11:34:28 -0700 (PDT) Sender: yang.r.yang@gmail.com Received: by 10.76.86.136 with HTTP; Tue, 7 Aug 2012 11:34:27 -0700 (PDT) In-Reply-To: <20120807151529.1898F18C0A9@mercury.lcs.mit.edu> References: <20120807151529.1898F18C0A9@mercury.lcs.mit.edu> Date: Tue, 7 Aug 2012 14:34:27 -0400 X-Google-Sender-Auth: uouNH7IXlJxwGkqzpjxeg8MBvqk Message-ID: From: "Y. Richard Yang" To: Noel Chiappa Content-Type: multipart/alternative; boundary=f46d0446312c90f8b604c6b13e5d Cc: idr@ietf.org, alto@ietf.org, irs-discuss@ietf.org Subject: Re: [irs-discuss] About ALTO Vs. BGP-LS X-BeenThere: irs-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Aug 2012 18:34:39 -0000 --f46d0446312c90f8b604c6b13e5d Content-Type: text/plain; charset=ISO-8859-1 On Tue, Aug 7, 2012 at 11:15 AM, Noel Chiappa wrote: > > From: "Y. Richard Yang" > > > Glad that you also like the idea of different levels of details of > the > > network topology. If the ALTO Server is given a detailed topology > > ... we can offer multiple topology operators/aggregators to explore > the > > detailed topology, according to need and policy. > > Too bad we have a routing architecture that deals (as its fundamental > currency) in destination tables, rather than topology - and, in particular, > in a multi-level representation of the toplogy. Then all this stuff would > just fall out naturally. > > It appears to have increasing efforts focusing on building abstractions/network computations based on topology. Hope that it moves somewhere. We are finding more benefits of using topology-based network routing/control, e.g., McNettle (Multi-core Nettle), an SDN controlled being developed here, uses STM to manage topology in a highly concurrent controller and achieves pretty good scalability. > (And if I sound somewhat cranky, perhaps people will forgive me - although > I > expect not that many on this list will know what I'm implicitly referring > to.) > > > > There are studies on representation of multi-level graphs that we can > > try to take advantage of. This can be a subject for the group to > explore. > > There's a PhD thesis which is relevant to this area (since part of it is > about clustering, i.e. in representing an area of the graph without full > detail, one has to decide where to set the boundaries of said part): > > Jacob Hagouel, "Issues in Routing for Large and Dynamic Netoworks", > Columbia University, 1983 > > A lot of it is irrelevant (to me, at least), since it's talking about > distributed path computation (which I have long since concluded is 'buggy > whip' technology), but the clustering, etc, content is good. > Thanks a lot for the pointer. Definitely will read. Richard > > Noel > --f46d0446312c90f8b604c6b13e5d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Tue, Aug 7, 2012 at 11:15 AM, Noel Ch= iappa <jnc@mercury.lcs.mit.edu> wrote:
=A0 =A0 > From: "Y. Richard Yang" <yry@cs.yale.edu>

=A0 =A0 > Glad that you also like the idea of different levels of detail= s of the
=A0 =A0 > network topology. If the ALTO Server is given a detailed topol= ogy
=A0 =A0 > ... we can offer multiple topology operators/aggregators= to explore the
=A0 =A0 > detailed topology, according to need and pol= icy.

Too bad we have a routing architecture that deals (as its fundamental=
currency) in destination tables, rather than topology - and, in particular,=
in a multi-level representation of the toplogy. Then all this stuff would just fall out naturally.

=A0
It appears to have increasing efforts f= ocusing on building abstractions/network
computations based on to= pology. Hope that it moves somewhere. We are finding
more benefit= s of using topology-based network routing/control, e.g., McNettle
(Multi-core Nettle), an SDN controlled being developed here, uses STM = to manage
topology in a highly concurrent controller and achieves= pretty good scalability.

=A0
(And if I sound somewhat cranky, perhaps people will forgive me - although = I
expect not that many on this list will know what I'm implicitly referri= ng to.)


=A0 =A0 > There are studies on representation of multi-level graphs that= we can
=A0 =A0 > try to take advantage of. This can be a subject for the group = to explore.

There's a PhD thesis which is relevant to this area (since part o= f it is
about clustering, i.e. in representing an area of the graph without full detail, one has to decide where to set the boundaries of said part):

=A0 Jacob Hagouel, "Issues in Routing for Large and Dynamic Netoworks&= quot;,
=A0 Columbia University, 1983

A lot of it is irrelevant (to me, at least), since it's talking about distributed path computation (which I have long since concluded is 'bug= gy
whip' technology), but the clustering, etc, content is good.

Thanks a lot for the pointer. Definitely will rea= d.

Richard
=A0

=A0 =A0 =A0 =A0 Noel

--f46d0446312c90f8b604c6b13e5d-- Return-Path: 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 5DD1521F8550; Tue, 7 Aug 2012 08:15:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.27 X-Spam-Level: X-Spam-Status: No, score=-6.27 tagged_above=-999 required=5 tests=[AWL=0.329, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JL2GS3NR3xE5; Tue, 7 Aug 2012 08:15:29 -0700 (PDT) Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by ietfa.amsl.com (Postfix) with ESMTP id 71F7F21F854D; Tue, 7 Aug 2012 08:15:29 -0700 (PDT) Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 1898F18C0A9; Tue, 7 Aug 2012 11:15:29 -0400 (EDT) To: irs-discuss@ietf.org Message-Id: <20120807151529.1898F18C0A9@mercury.lcs.mit.edu> Date: Tue, 7 Aug 2012 11:15:29 -0400 (EDT) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) Cc: idr@ietf.org, alto@ietf.org, jnc@mercury.lcs.mit.edu Subject: Re: [irs-discuss] About ALTO Vs. BGP-LS X-BeenThere: irs-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Aug 2012 15:15:30 -0000 > From: "Y. Richard Yang" > Glad that you also like the idea of different levels of details of the > network topology. If the ALTO Server is given a detailed topology > ... we can offer multiple topology operators/aggregators to explore the > detailed topology, according to need and policy. Too bad we have a routing architecture that deals (as its fundamental currency) in destination tables, rather than topology - and, in particular, in a multi-level representation of the toplogy. Then all this stuff would just fall out naturally. (And if I sound somewhat cranky, perhaps people will forgive me - although I expect not that many on this list will know what I'm implicitly referring to.) > There are studies on representation of multi-level graphs that we can > try to take advantage of. This can be a subject for the group to explore. There's a PhD thesis which is relevant to this area (since part of it is about clustering, i.e. in representing an area of the graph without full detail, one has to decide where to set the boundaries of said part): Jacob Hagouel, "Issues in Routing for Large and Dynamic Netoworks", Columbia University, 1983 A lot of it is irrelevant (to me, at least), since it's talking about distributed path computation (which I have long since concluded is 'buggy whip' technology), but the clustering, etc, content is good. Noel Return-Path: 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 2E8C821F86A4; Tue, 7 Aug 2012 04:17:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.649 X-Spam-Level: X-Spam-Status: No, score=-9.649 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cz0kY+SW9f7W; Tue, 7 Aug 2012 04:17:03 -0700 (PDT) Received: from smail5.alcatel.fr (smail5.alcatel.fr [64.208.49.27]) by ietfa.amsl.com (Postfix) with ESMTP id 4804C21F86A2; Tue, 7 Aug 2012 04:17:03 -0700 (PDT) Received: from FRMRSSXCHHUB02.dc-m.alcatel-lucent.com (FRMRSSXCHHUB02.dc-m.alcatel-lucent.com [135.120.45.62]) by smail5.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id q77BGs5V020020 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 7 Aug 2012 13:16:56 +0200 Received: from [149.204.61.15] (135.120.57.7) by FRMRSSXCHHUB02.dc-m.alcatel-lucent.com (135.120.45.62) with Microsoft SMTP Server (TLS) id 8.3.213.0; Tue, 7 Aug 2012 13:16:55 +0200 Message-ID: <5020F926.707@bell-labs.com> Date: Tue, 7 Aug 2012 13:16:54 +0200 From: Volker Hilt User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: "Y. Richard Yang" References: <501B0D75.4090009@raszuk.net> <7E89A05A-CE4E-4FCF-81AB-8F39B42FBF8E@cisco.com> <501C128D.10809@cs.yale.edu> <501C2047.1000100@bell-labs.com> <501C3999.3080804@cs.yale.edu> In-Reply-To: <501C3999.3080804@cs.yale.edu> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.69 on 155.132.188.13 Cc: idr@ietf.org, robert@raszuk.net, irs-discuss@ietf.org, James Kempf , IETF ALTO , Thomas Nadeau , stefano previdi Subject: Re: [irs-discuss] About ALTO Vs. BGP-LS X-BeenThere: irs-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Aug 2012 11:17:05 -0000 Richard, >> >> I like the idea of enabling an ALTO server to offer different levels >> of details. This will enable a server to tailor responses to the >> specific client. It will add complexity as the ALTO server itself will >> have to maintain the most complex topology it is offering and will >> have to keep this topology up to date. But this is an interesting >> question for discussion in the WG. >> > Glad that you also like the idea of different levels of details of the > network topology. If the ALTO Server is given a detailed topology > (constructed from multiple sources, such as routing feed, LSP feed, > configuration files), we can offer multiple topology > operators/aggregators to explore the detailed topology, according to > need and policy. A simple example operator is level (i.e., hierarchy > such as at the area level), but one might specify other operators (e.g., > fisheye focus). There are studies on representation of multi-level > graphs that we can try to take advantage of. This can be a subject for > the group to explore. > Yes, I agree - this is an interesting area to explore. Another operator could be a view for a specific use, e.g., a view for CDN use. The operator can then populate this view with the desired abstraction level and policy. > We may need to study/collect use cases for multiple level topology. One > interesting example immediately coming to mind is the Abstract Node > concept (specify IP prefix/ASN) used in RSVP-TE. > Indeed. Volker >> On 03.08.2012 11:03, Y. Richard Yang wrote: >>> Hi Stefano, >>> >>> Good post! I added the ALTO mailing list, given the relevance. I hope >>> that this is OK cross posting. >>> >>> First, a few comments on ALTO: >>> >>> View granularity: >>> >>> - ALTO currently defines two abstract network topology data structures: >>> Network Map and Cost Map(s). More link-state oriented maps (graphs), >>> with aggregations and transformations, can be added efficiently to ALTO. >>> Some initial efforts are already on the way (e.g., see the graph >>> representation proposal at page 9: >>> http://www.ietf.org/proceedings/84/slides/slides-84-alto-1.pdf). Hence, >>> I see a natural next-step is for ALTO to provide a link-state view to >>> external entities. >>> >>> - It is a good comment on the level of details that ALTO should >>> delivery. This is a good question for the ALTO working group and the >>> community to discuss. I feel that ALTO should provide multi-levels of >>> granularity of views, and we should discuss in the working group. >>> >>> Pull vs push delivery mechanism: >>> >>> - There are more discussions on adding the incremental update in ALTO. >>> Multiple mechanisms have been discussed. I feel that it is the right >>> direction for ALTO. >>> >>> Now let me understand the deployment model of BGP-LS. Your explanation >>> on the issues of acquiring routing state is excellent. Let me start by >>> understanding more details on the deployment model of BGP-LS inside a >>> network: >>> >>> - A set N_igp of BGP-LS instances are deployed to collect IGP info. You >>> need multiple instances because IGP needs direct connectivity >>> (adjacency). Each instance here receives (potentially multiple) IGP >>> updates and streams (relays) to an another (remote) entity, which I >>> assume is a master BGP-LS instance. So each of these N_igp instances is >>> IGP-in and BGP-LS out. This appears to be shown in Figure 1 of >>> draft-gredler-idr-ls-distribution. >>> >>> - A set N_egp of BGP-LS instances are deployed to collect BGP feeds. You >>> also may need multiple instances because the network does not want to >>> see aggregated states but raw states. These instances will feed to the >>> master BGP-LS as well. >>> >>> - The master BGP-LS aggregates the multiple BGP-LS ins (and maybe some >>> direct IGP/EGP ins) and pushes (after policy) to other BGP-LS peers to >>> use: for example, an ALTO Server transforms/aggregates the feed to >>> generate ALTO views (maps and graphs), and an PCE uses the feed to >>> maintain its TED. One could even imagine that ALTO builds a detailed TED >>> and feeds to PCE, but this beyond the scope of this discussion. The >>> master BGP-LS is BGP-LS in and BGP-LS out. It is also possible that the >>> master BGP-LS does not push to any other entities and simply maintains >>> an internal DB for others to query. >>> >>> Do I understand it correctly? >>> >>> Now, we can take a look at more specifics of BGP-LS. >>> >>> A first perspective is the semantics of the content. If the objective is >>> to solve the aforementioned deployment issue, then an alternative >>> solution is to introduce a simple LS update tunneling protocol, where a >>> link-state proxy forwards LS messages to a collector. The current design >>> of BGP-LS starts with such a feeling (i.e., an NLRI starts with the >>> Protocol ID, which indicates it is from IS-IS level 1 IS-IS level 2, >>> OSPF, etc). However, the protocol appears to (try to) go beyond simple >>> tunneling and introduces a common LS schema, by converting/filtering >>> individual IGP LS messages to some common format. I feel that it can be >>> helpful to first specify the schema (LS data model) instead of the >>> specific encoding. For example, OSPF specifies LS Age, and this is >>> filtered. (Please correct me if I missed it). On the other hand, one can >>> think that some Age info can be helpful for one to understand the >>> "freshness" of the LS. A problem studied in database is heterogeneous >>> databases, to merge multiple data sources (IS-IS, OSPF, etc) to a single >>> schema, and there can be many problems. If there is such a study, please >>> do share a pointer. >>> >>> A second perspective is using BGP as the transport. What key features >>> from BGP do we really need (yes, weak-typed TLV encoding offers a lot of >>> flexibility)? What features of BGP do we not need (e.g., BGP is a >>> routing protocol and hence builds in features to handle convergence such >>> as dampening)? What may be missing (e.g., a capability of pull or >>> filtering of push). I feel that these issues should be discussed. If >>> they have already been discussed, please do share a pointer, as I am >>> definitely a new comer. >>> >>> Thanks! >>> >>> Richard >>> >>> On 8/2/12 11:54 PM, stefano previdi wrote: >>>> All, >>>> >>>> as co-author of both BGP-LS and ALTO drafts, I'd try to clarify a few >>>> things: >>>> >>>> ALTO has been designed in order to deliver to applications (through >>>> http/json): >>>> >>>> 1. two maps representing the network topology in an abstracted view >>>> (or set of views through multiple maps). The map does not include >>>> the details of a link-state database and therefore have little use >>>> for any element that would need to retrieve from the network the >>>> detailed/complete network layer topology, for example: link >>>> addresses or link BW resources, etc. IOW: ALTO maps do not have >>>> the granularity of a link-state database and ALTO protocol is not >>>> designed to deliver such details. >>>> >>>> and/or >>>> >>>> 2. Ranking services where a client sends a bunch of IP addresses in >>>> a message and the ALTO server replies by ranking these addresses >>>> based on their topological/network distance (or whatever criteria >>>> the ALTO server has been configured for). This is called: Endpoint >>>> Cost Service. >>>> >>>> When using ALTO maps, and the ALTO protocol being http/pull based, >>>> there's no such concept of unsolicited routing updates. An ALTO >>>> client is typically a browser that will pull the maps from an ALTO >>>> server using http. The ALTO server will make no effort to ensure the >>>> client has the latest view of the topology (i.e.: It's the role of the >>>> client to poll for new maps time to time). >>>> >>>> Now, in order for an ALTO server to deliver Maps or Ranking services, >>>> it needs to build some form of topology and in order to achieve this, >>>> it needs somehow to be fed by either the operator (configuration) or >>>> to receive dynamically topology information from the network (e.g.: >>>> ISIS/OSPF/BGP). >>>> >>>> Here we had two options: >>>> 1. ALTO server to implement ISIS/OSPF/BGP and establish IGP adjacencies >>>> to ABRs or L1L2 routers in each area so to retrieve the LSDB from >>>> each area. In practice I know no SP willing/accepting to open their >>>> IGP to an ALTO server. Also, IGP requires direct connectivity >>>> (adjacency) so from an operation point of view is complex and not >>>> desired. >>>> 2. Use a database distribution protocol running on top of a reliable >>>> transport layer that would allow an ALTO server to connect to a >>>> _single_ and _remote_ Route Reflector (i.e.: no need to be directly >>>> connected) and grab the whole network topology that will be updated >>>> using standard routing protocol mechanisms (i.e.: routing updates) >>>> and that would allow the operator to control (through policies and >>>> filters) what to distribute and to which server. >>>> >>>> Benefits: single (or dual at most for redundancy) connection for >>>> the ALTO server (rather than having a direct adjacency with each >>>> ABR) and, from the operator perspective, single point of >>>> distribution of network topology (easier to apply policies and >>>> control what you deliver). This is what BGP-LS is about. >>>> >>>> BGP-LS defines new AFI/SAFI for a new NLRI and attributes that convey >>>> link-state and, more generically, any type of topology information. >>>> The draft specifies NLRI and attributes that map whatever you can >>>> find in a link-state database. >>>> >>>> We currently have draft-gredler-idr-ls-distribution in the process >>>> (hopefully) to be adopted as WG item in IDR WG (so far we 're getting >>>> good support). We also have 3 implementations of BGP-LS. >>>> >>>> Deployment-wise: BGP-LS is not yet deployed, however, we already have >>>> deployments (I know at least two) where an ALTO server retrieves IP >>>> prefix information from remote BGP RRs (for ipv4). The same scheme >>>> will be used once BGP-LS will be deployed (so to say that it is not >>>> something that we invented after a couple of beers but corresponds to >>>> requirements for delivering network services to upper layers while >>>> still controlling efficiently what you distribute, to whom and in >>>> which form (note that, often, beers are anyway part of the process). >>>> >>>> More information here: >>>> http://tools.ietf.org/html/draft-gredler-idr-ls-distribution-02 >>>> http://tools.ietf.org/html/draft-ietf-alto-protocol-12 >>>> >>>> Hope this helps. >>>> >>>> s. >>>> >>>> >>>> >>>> On Aug 3, 2012, at 1:29 AM, Robert Raszuk wrote: >>>>> Tom, >>>>> >>>>>> I agree that one of the top work items for this effort should be a >>>>>> standardized topology function, and one that is accessible via a >>>>>> non-routing protocol. >>>>> So if the requirement is to have topology export via non-routing >>>>> protocol then I think we should seriously revisit or repackage the >>>>> draft-gredler-idr-ls-distribution-01 which works for for both OSPF >>>>> and ISIS. >>>>> >>>>> However before that let's really understand the requirement why it >>>>> must be exported via non-routing protocol .... Keep in mind that just >>>>> to parse BGP UPDATE messages and retrieve interesting pieces out it >>>>> it requires very little code rather then full BGP implementation. >>>>> >>>>> The particular feature I like about >>>>> draft-gredler-idr-ls-distribution-01 is that it is read-only ;) >>>>> >>>>> R. >>>>> >>>>>> I agree that one of the top work items for this effort should be a >>>>>> standardized topology function, and one that is accessible via a >>>>>> non-routing protocol. While not exactly "low hanging fruit", it is >>>>>> something that (to me) is a clear work item with clear goals that >>>>>> should >>>>>> be tackled straight away. >>>>>> >>>>>> --Tom >>>>>> >>>>>> >>>>>> >>>>>> On 8/2/12 3:24 PM, "James Kempf" wrote: >>>>>> >>>>>>> So after seeing part of Alia's talk this morning (I had to leave in >>>>>>> the >>>>>>> middle unfortunately), I'd like to make a couple suggestions. There >>>>>>> were >>>>>>> a lot of ideas presented in the talk, enough for an entire IETF >>>>>>> Area. I >>>>>>> think to make tangible progress, the work needs to be focussed on a >>>>>>> small >>>>>>> subset that would be of immediate interest and usability. >>>>>>> >>>>>>> There are a couple areas that suggest themselves, but one that >>>>>>> would be >>>>>>> useful in work that I've been involved in is a standardized >>>>>>> format for >>>>>>> network topology representation and a protocol for exchanging it. >>>>>>> The >>>>>>> Onix OpenFlow controller has a network information base with a >>>>>>> specialized format for network topology, and every OpenFlow >>>>>>> controller >>>>>>> requires this. Having a standardized way to represent it might >>>>>>> foster a >>>>>>> common topology database package. Another application is network >>>>>>> management. Every network management system needs some kind of >>>>>>> topology >>>>>>> representation. Finally, though I am not an expert in PCE >>>>>>> construction, >>>>>>> it would seem to me that a PCE would need some kind of topology >>>>>>> representation in order to perform path calculations. Having a >>>>>>> way,for >>>>>>> example, for the OpenFlow controller and the PCE to exchange >>>>>>> topology >>>>>>> information would be really useful. I would say to start with >>>>>>> physical >>>>>>> topology because that is fundamental, but make the format flexible >>>>>>> enough >>>>>>> to support >>>>>>> virtual topology representation. >>>>>>> >>>>>>> jak >>>>>>> _______________________________________________ >>>>>>> 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 >>>>>> >>>>>> >>>>> _______________________________________________ >>>>> 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 >>> >>> _______________________________________________ >>> irs-discuss mailing list >>> irs-discuss@ietf.org >>> https://www.ietf.org/mailman/listinfo/irs-discuss Return-Path: 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 E042421E8089; Mon, 6 Aug 2012 11:39:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.431 X-Spam-Level: X-Spam-Status: No, score=-6.431 tagged_above=-999 required=5 tests=[AWL=0.168, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u8VQcwUaqiFt; Mon, 6 Aug 2012 11:39:38 -0700 (PDT) Received: from exprod7og104.obsmtp.com (exprod7og104.obsmtp.com [64.18.2.161]) by ietfa.amsl.com (Postfix) with ESMTP id 0F3F321E8084; Mon, 6 Aug 2012 11:39:28 -0700 (PDT) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob104.postini.com ([64.18.6.12]) with SMTP ID DSNKUCAPXNE182p+6dL32dx0iHDNKt2VZSPR@postini.com; Mon, 06 Aug 2012 11:39:38 PDT Received: from ubuntu (172.23.6.234) by P-EMHUB01-HQ.jnpr.net (172.24.192.33) with Microsoft SMTP Server id 8.3.213.0; Mon, 6 Aug 2012 11:38:56 -0700 Received: by ubuntu (Postfix, from userid 1000) id 1E44B2B300; Mon, 6 Aug 2012 20:39:11 +0200 (CEST) Date: Mon, 6 Aug 2012 20:39:11 +0200 From: Hannes Gredler To: "Y. Richard Yang" Message-ID: <20120806183910.GC16802@juniper.net> References: <501B0D75.4090009@raszuk.net> <7E89A05A-CE4E-4FCF-81AB-8F39B42FBF8E@cisco.com> <501C128D.10809@cs.yale.edu> <728F9B956B2C48439CA9294B1723B14623756237@dfweml509-mbs.china.huawei.com> <501C1C74.6040006@cs.yale.edu> <728F9B956B2C48439CA9294B1723B146237562DC@dfweml509-mbs.china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: <728F9B956B2C48439CA9294B1723B146237562DC@dfweml509-mbs.china.huawei.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "idr@ietf.org" , James Kempf , Susan Hares , "robert@raszuk.net" , irs-discuss@ietf.org Subject: Re: [irs-discuss] About ALTO Vs. BGP-LS X-BeenThere: irs-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Aug 2012 18:39:39 -0000 richard, [ ... ] | > Now, we can take a look at more specifics of BGP-LS. | > | > A first perspective is the semantics of the content. If the objective is | > to solve the aforementioned deployment issue, then an alternative | > solution is to introduce a simple LS update tunneling protocol, where a | > link-state proxy forwards LS messages to a collector. The current design | > of BGP-LS starts with such a feeling (i.e., an NLRI starts with the | > Protocol ID, which indicates it is from IS-IS level 1 IS-IS level 2, | > OSPF, etc). However, the protocol appears to (try to) go beyond simple | > tunneling and introduces a common LS schema, by converting/filtering | > individual IGP LS messages to some common format. I feel that it can be | > helpful to first specify the schema (LS data model) instead of the | > specific encoding. For example, OSPF specifies LS Age, and this is | > filtered. (Please correct me if I missed it). On the other hand, one can | > think that some Age info can be helpful for one to understand the | > "freshness" of the LS. A problem studied in database is heterogeneous | > databases, to merge multiple data sources (IS-IS, OSPF, etc) to a single | > schema, and there can be many problems. If there is such a study, please | > do share a pointer. one of the base ideas of BGP-LS has been to present a topology in a protocol neutral form. As such it nicely solves the case where more than one IGP (OSPF at the edge, IS-IS in the core) has been deployed. It per does not flood IGP LSAs (including age), but rather the normalized content of those LSAs - i find age information for the topology less interesting as age it is purely for garbage collection. | > A second perspective is using BGP as the transport. What key features | > from BGP do we really need (yes, weak-typed TLV encoding offers a lot of | > flexibility)? What features of BGP do we not need (e.g., BGP is a | > routing protocol and hence builds in features to handle convergence such | > as dampening)? What may be missing (e.g., a capability of pull or | > filtering of push). I feel that these issues should be discussed. wether BGP is a "routing-protocol" per se or not is mildly ;-) controversial debate which we certainly cannot get full agreement by all list participants - so let me present my view on that: the way i see BGP is more as a multipoint (reflectors !) IPC facility where i can publish state for the "universe". to my knowledge there are is no alternative protocol that allows me to distribute state over a generic p2mp distribution graph. so the reason BGP is so attractive as a generic state distribution mechanism is because "its there" and it "works" and it has been abused exacatly because of that by others in the past :-) /hannes Return-Path: 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 0EC6E11E80D7 for ; Mon, 6 Aug 2012 11:15:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.266 X-Spam-Level: X-Spam-Status: No, score=0.266 tagged_above=-999 required=5 tests=[AWL=-1.768, BAYES_40=-0.185, TVD_SPACE_RATIO=2.219] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NKKqUuENxlFC for ; Mon, 6 Aug 2012 11:15:53 -0700 (PDT) Received: from smtp.webfaction.com (mail6.webfaction.com [74.55.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id B52C611E80D2 for ; Mon, 6 Aug 2012 11:15:53 -0700 (PDT) Received: from [192.168.0.124] (c-67-170-243-110.hsd1.ca.comcast.net [67.170.243.110]) by smtp.webfaction.com (Postfix) with ESMTP id 15B3A2124228 for ; Mon, 6 Aug 2012 13:15:53 -0500 (CDT) Message-ID: <502009D4.8070809@grotto-networking.com> Date: Mon, 06 Aug 2012 11:15:48 -0700 From: Greg Bernstein User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: irs-discuss@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Mon, 06 Aug 2012 11:16:23 -0700 Subject: [irs-discuss] subscribe X-BeenThere: irs-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Aug 2012 18:15:54 -0000 -- =================================================== Dr Greg Bernstein, Grotto Networking (510) 573-2237 Return-Path: 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 66A4D21E808E; Mon, 6 Aug 2012 11:10:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.073 X-Spam-Level: X-Spam-Status: No, score=-2.073 tagged_above=-999 required=5 tests=[AWL=-0.075, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_33=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AIG58CXYz1Qd; Mon, 6 Aug 2012 11:09:58 -0700 (PDT) Received: from smtp.webfaction.com (mail6.webfaction.com [74.55.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id E041221E808B; Mon, 6 Aug 2012 11:09:57 -0700 (PDT) Received: from [192.168.0.124] (c-67-170-243-110.hsd1.ca.comcast.net [67.170.243.110]) by smtp.webfaction.com (Postfix) with ESMTP id D14BD2131D37; Mon, 6 Aug 2012 13:09:56 -0500 (CDT) Message-ID: <50200870.3000000@grotto-networking.com> Date: Mon, 06 Aug 2012 11:09:52 -0700 From: Greg Bernstein User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: Alia Atlas References: <501B0D75.4090009@raszuk.net> <7E89A05A-CE4E-4FCF-81AB-8F39B42FBF8E@cisco.com> <501C128D.10809@cs.yale.edu> <501C2047.1000100@bell-labs.com> <501C3999.3080804@cs.yale.edu> In-Reply-To: Content-Type: multipart/alternative; boundary="------------080305080401020808030000" X-Mailman-Approved-At: Mon, 06 Aug 2012 11:10:56 -0700 Cc: idr@ietf.org, Volker Hilt , irs-discuss@ietf.org, James Kempf , IETF ALTO , "Y. Richard Yang" Subject: Re: [irs-discuss] [alto] About ALTO Vs. BGP-LS X-BeenThere: irs-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Aug 2012 18:10:03 -0000 This is a multi-part message in MIME format. --------------080305080401020808030000 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi Alia, one key use case that needs a different level of abstraction is the "large bandwidth" use-case. In the P4P paper Richard Yang and co-authors were able to affect traffic engineering by changing the path costs over time. However in the "large bandwidth" case we need explicit information on bandwidth constraints (http://tools.ietf.org/html/draft-bernstein-alto-large-bandwidth-cases-02). Another dimension to the "abstraction" levels was that of the scope/span of users of the information. Currently ALTO is aimed at open, "Internet" -like environments. However some of the extensions being proposed may apply in more "controlled" or "restricted" environments. Although we are trying to hide network details from the ALTO users there may be cases with particular technology information is important. For example in our "large bandwidth" use-case document we showed how to shared multiple spanning tree instance (MSTI) Ethernet graphs in reduced form for VLAN to MSTI assignment in a data center. We also gave optical (WDM and TDM) examples. Cheers Greg B. On 8/3/2012 4:57 PM, Alia Atlas wrote: > > I strongly agree that we need to start collecting the use-cases for > multiple abstraction levels as well as physical/virtual/private. > > Alia > > On Aug 3, 2012 4:51 PM, "Y. Richard Yang" > wrote: > > Hi Volker, > > On 8/3/12 12:02 PM, Volker Hilt wrote: > > > I believe that the capability to provide a simplified view on > the network topology to an application is a key feature rather > than a bug. Applications that want to have a view on network > topology don't need need a fine grained view on the topology > in most casts and benefit from having an abstracted view. This > will simplify processing for the application and enables > providers to control the exposure of details. > > Agreed. > > We've seen some numbers for topology data sizes in the > incremental updates presentation in the ALTO meeting, which > provide some insights into the amounts of data needed for > different topology sizes. > > I like the idea of enabling an ALTO server to offer different > levels of details. This will enable a server to tailor > responses to the specific client. It will add complexity as > the ALTO server itself will have to maintain the most complex > topology it is offering and will have to keep this topology up > to date. But this is an interesting question for discussion in > the WG. > > Glad that you also like the idea of different levels of details of > the network topology. If the ALTO Server is given a detailed > topology (constructed from multiple sources, such as routing feed, > LSP feed, configuration files), we can offer multiple topology > operators/aggregators to explore the detailed topology, according > to need and policy. A simple example operator is level (i.e., > hierarchy such as at the area level), but one might specify other > operators (e.g., fisheye focus). There are studies on > representation of multi-level graphs that we can try to take > advantage of. This can be a subject for the group to explore. > > We may need to study/collect use cases for multiple level > topology. One interesting example immediately coming to mind is > the Abstract Node concept (specify IP prefix/ASN) used in RSVP-TE. > > Cheers, > > Richard > > Cheers, > > Volker > > > > > > > > On 03.08.2012 11:03, Y. Richard Yang wrote: > > Hi Stefano, > > Good post! I added the ALTO mailing list, given the > relevance. I hope > that this is OK cross posting. > > First, a few comments on ALTO: > > View granularity: > > - ALTO currently defines two abstract network topology > data structures: > Network Map and Cost Map(s). More link-state oriented maps > (graphs), > with aggregations and transformations, can be added > efficiently to ALTO. > Some initial efforts are already on the way (e.g., see the > graph > representation proposal at page 9: > http://www.ietf.org/proceedings/84/slides/slides-84-alto-1.pdf). > Hence, > I see a natural next-step is for ALTO to provide a > link-state view to > external entities. > > - It is a good comment on the level of details that ALTO > should > delivery. This is a good question for the ALTO working > group and the > community to discuss. I feel that ALTO should provide > multi-levels of > granularity of views, and we should discuss in the working > group. > > Pull vs push delivery mechanism: > > - There are more discussions on adding the incremental > update in ALTO. > Multiple mechanisms have been discussed. I feel that it is > the right > direction for ALTO. > > Now let me understand the deployment model of BGP-LS. Your > explanation > on the issues of acquiring routing state is excellent. Let > me start by > understanding more details on the deployment model of > BGP-LS inside a > network: > > - A set N_igp of BGP-LS instances are deployed to collect > IGP info. You > need multiple instances because IGP needs direct connectivity > (adjacency). Each instance here receives (potentially > multiple) IGP > updates and streams (relays) to an another (remote) > entity, which I > assume is a master BGP-LS instance. So each of these N_igp > instances is > IGP-in and BGP-LS out. This appears to be shown in Figure 1 of > draft-gredler-idr-ls-distribution. > > - A set N_egp of BGP-LS instances are deployed to collect > BGP feeds. You > also may need multiple instances because the network does > not want to > see aggregated states but raw states. These instances will > feed to the > master BGP-LS as well. > > - The master BGP-LS aggregates the multiple BGP-LS ins > (and maybe some > direct IGP/EGP ins) and pushes (after policy) to other > BGP-LS peers to > use: for example, an ALTO Server transforms/aggregates the > feed to > generate ALTO views (maps and graphs), and an PCE uses the > feed to > maintain its TED. One could even imagine that ALTO builds > a detailed TED > and feeds to PCE, but this beyond the scope of this > discussion. The > master BGP-LS is BGP-LS in and BGP-LS out. It is also > possible that the > master BGP-LS does not push to any other entities and > simply maintains > an internal DB for others to query. > > Do I understand it correctly? > > Now, we can take a look at more specifics of BGP-LS. > > A first perspective is the semantics of the content. If > the objective is > to solve the aforementioned deployment issue, then an > alternative > solution is to introduce a simple LS update tunneling > protocol, where a > link-state proxy forwards LS messages to a collector. The > current design > of BGP-LS starts with such a feeling (i.e., an NLRI starts > with the > Protocol ID, which indicates it is from IS-IS level 1 > IS-IS level 2, > OSPF, etc). However, the protocol appears to (try to) go > beyond simple > tunneling and introduces a common LS schema, by > converting/filtering > individual IGP LS messages to some common format. I feel > that it can be > helpful to first specify the schema (LS data model) > instead of the > specific encoding. For example, OSPF specifies LS Age, and > this is > filtered. (Please correct me if I missed it). On the other > hand, one can > think that some Age info can be helpful for one to > understand the > "freshness" of the LS. A problem studied in database is > heterogeneous > databases, to merge multiple data sources (IS-IS, OSPF, > etc) to a single > schema, and there can be many problems. If there is such a > study, please > do share a pointer. > > A second perspective is using BGP as the transport. What > key features > from BGP do we really need (yes, weak-typed TLV encoding > offers a lot of > flexibility)? What features of BGP do we not need (e.g., > BGP is a > routing protocol and hence builds in features to handle > convergence such > as dampening)? What may be missing (e.g., a capability of > pull or > filtering of push). I feel that these issues should be > discussed. If > they have already been discussed, please do share a > pointer, as I am > definitely a new comer. > > Thanks! > > Richard > > On 8/2/12 11:54 PM, stefano previdi wrote: > > All, > > as co-author of both BGP-LS and ALTO drafts, I'd try > to clarify a few > things: > > ALTO has been designed in order to deliver to > applications (through > http/json): > > 1. two maps representing the network topology in an > abstracted view > (or set of views through multiple maps). The map does > not include > the details of a link-state database and therefore > have little use > for any element that would need to retrieve from the > network the > detailed/complete network layer topology, for example: > link > addresses or link BW resources, etc. IOW: ALTO maps do > not have > the granularity of a link-state database and ALTO > protocol is not > designed to deliver such details. > > and/or > > 2. Ranking services where a client sends a bunch of IP > addresses in > a message and the ALTO server replies by ranking these > addresses > based on their topological/network distance (or > whatever criteria > the ALTO server has been configured for). This is > called: Endpoint > Cost Service. > > When using ALTO maps, and the ALTO protocol being > http/pull based, > there's no such concept of unsolicited routing > updates. An ALTO > client is typically a browser that will pull the maps > from an ALTO > server using http. The ALTO server will make no effort > to ensure the > client has the latest view of the topology (i.e.: It's > the role of the > client to poll for new maps time to time). > > Now, in order for an ALTO server to deliver Maps or > Ranking services, > it needs to build some form of topology and in order > to achieve this, > it needs somehow to be fed by either the operator > (configuration) or > to receive dynamically topology information from the > network (e.g.: > ISIS/OSPF/BGP). > > Here we had two options: > 1. ALTO server to implement ISIS/OSPF/BGP and > establish IGP adjacencies > to ABRs or L1L2 routers in each area so to retrieve > the LSDB from > each area. In practice I know no SP willing/accepting > to open their > IGP to an ALTO server. Also, IGP requires direct > connectivity > (adjacency) so from an operation point of view is > complex and not > desired. > 2. Use a database distribution protocol running on top > of a reliable > transport layer that would allow an ALTO server to > connect to a > _single_ and _remote_ Route Reflector (i.e.: no need > to be directly > connected) and grab the whole network topology that > will be updated > using standard routing protocol mechanisms (i.e.: > routing updates) > and that would allow the operator to control (through > policies and > filters) what to distribute and to which server. > > Benefits: single (or dual at most for redundancy) > connection for > the ALTO server (rather than having a direct adjacency > with each > ABR) and, from the operator perspective, single point of > distribution of network topology (easier to apply > policies and > control what you deliver). This is what BGP-LS is about. > > BGP-LS defines new AFI/SAFI for a new NLRI and > attributes that convey > link-state and, more generically, any type of topology > information. > The draft specifies NLRI and attributes that map > whatever you can > find in a link-state database. > > We currently have draft-gredler-idr-ls-distribution in > the process > (hopefully) to be adopted as WG item in IDR WG (so far > we 're getting > good support). We also have 3 implementations of BGP-LS. > > Deployment-wise: BGP-LS is not yet deployed, however, > we already have > deployments (I know at least two) where an ALTO server > retrieves IP > prefix information from remote BGP RRs (for ipv4). The > same scheme > will be used once BGP-LS will be deployed (so to say > that it is not > something that we invented after a couple of beers but > corresponds to > requirements for delivering network services to upper > layers while > still controlling efficiently what you distribute, to > whom and in > which form (note that, often, beers are anyway part of > the process). > > More information here: > http://tools.ietf.org/html/draft-gredler-idr-ls-distribution-02 > http://tools.ietf.org/html/draft-ietf-alto-protocol-12 > > Hope this helps. > > s. > > > > On Aug 3, 2012, at 1:29 AM, Robert Raszuk wrote: > > Tom, > > I agree that one of the top work items for > this effort should be a > standardized topology function, and one that > is accessible via a > non-routing protocol. > > So if the requirement is to have topology export > via non-routing > protocol then I think we should seriously revisit > or repackage the > draft-gredler-idr-ls-distribution-01 which works > for for both OSPF > and ISIS. > > However before that let's really understand the > requirement why it > must be exported via non-routing protocol .... > Keep in mind that just > to parse BGP UPDATE messages and retrieve > interesting pieces out it > it requires very little code rather then full BGP > implementation. > > The particular feature I like about > draft-gredler-idr-ls-distribution-01 is that it is > read-only ;) > > R. > > I agree that one of the top work items for > this effort should be a > standardized topology function, and one that > is accessible via a > non-routing protocol. While not exactly "low > hanging fruit", it is > something that (to me) is a clear work item > with clear goals that > should > be tackled straight away. > > --Tom > > > > On 8/2/12 3:24 PM, "James Kempf" > > wrote: > > So after seeing part of Alia's talk this > morning (I had to leave in > the > middle unfortunately), I'd like to make a > couple suggestions. There > were > a lot of ideas presented in the talk, > enough for an entire IETF > Area. I > think to make tangible progress, the work > needs to be focussed on a > small > subset that would be of immediate interest > and usability. > > There are a couple areas that suggest > themselves, but one that > would be > useful in work that I've been involved in > is a standardized format for > network topology representation and a > protocol for exchanging it. The > Onix OpenFlow controller has a network > information base with a > specialized format for network topology, > and every OpenFlow controller > requires this. Having a standardized way > to represent it might > foster a > common topology database package. Another > application is network > management. Every network management > system needs some kind of > topology > representation. Finally, though I am not > an expert in PCE > construction, > it would seem to me that a PCE would need > some kind of topology > representation in order to perform path > calculations. Having a way,for > example, for the OpenFlow controller and > the PCE to exchange topology > information would be really useful. I > would say to start with physical > topology because that is fundamental, but > make the format flexible > enough > to support > virtual topology representation. > > jak > _______________________________________________ > 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 > > > _______________________________________________ > 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 > > > _______________________________________________ > 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 > > > > _______________________________________________ > alto mailing list > alto@ietf.org > https://www.ietf.org/mailman/listinfo/alto -- =================================================== Dr Greg Bernstein, Grotto Networking (510) 573-2237 --------------080305080401020808030000 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Hi Alia, one key use case that needs a different level of abstraction is the "large bandwidth" use-case.  In the P4P paper Richard Yang and co-authors were able to affect traffic engineering by changing the path costs over time.  However in the "large bandwidth" case we need explicit information on bandwidth constraints (http://tools.ietf.org/html/draft-bernstein-alto-large-bandwidth-cases-02).

Another dimension to the "abstraction" levels was that of the scope/span of users of the information.  Currently ALTO is aimed at open, "Internet" -like environments.  However some of the extensions being proposed may apply in more "controlled" or "restricted" environments.

Although we are trying to hide network details from the ALTO users there may be cases with particular technology information is important. For example in our "large bandwidth" use-case document we showed how to shared multiple spanning tree instance (MSTI) Ethernet graphs in reduced form for VLAN to MSTI assignment in a data center.  We also gave  optical (WDM and TDM) examples.

Cheers

Greg B.

On 8/3/2012 4:57 PM, Alia Atlas wrote:

I strongly agree that we need to start collecting the use-cases for multiple abstraction levels as well as physical/virtual/private.

Alia

On Aug 3, 2012 4:51 PM, "Y. Richard Yang" <yry@cs.yale.edu> wrote:
Hi Volker,

On 8/3/12 12:02 PM, Volker Hilt wrote:

I believe that the capability to provide a simplified view on the network topology to an application is a key feature rather than a bug. Applications that want to have a view on network topology don't need need a fine grained view on the topology in most casts and benefit from having an abstracted view. This will simplify processing for the application and enables providers to control the exposure of details.
Agreed.

We've seen some numbers for topology data sizes in the incremental updates presentation in the ALTO meeting, which provide some insights into the amounts of data needed for different topology sizes.

I like the idea of enabling an ALTO server to offer different levels of details. This will enable a server to tailor responses to the specific client. It will add complexity as the ALTO server itself will have to maintain the most complex topology it is offering and will have to keep this topology up to date. But this is an interesting question for discussion in the WG.

Glad that you also like the idea of different levels of details of the network topology. If the ALTO Server is given a detailed topology (constructed from multiple sources, such as routing feed, LSP feed, configuration files), we can offer multiple topology operators/aggregators to explore the detailed topology, according to need and policy. A simple example operator is level (i.e., hierarchy such as at the area level), but one might specify other operators (e.g., fisheye focus). There are studies on representation of multi-level graphs that we can try to take advantage of. This can be a subject for the group to explore.

We may need to study/collect use cases for multiple level topology. One interesting example immediately coming to mind is the Abstract Node concept (specify IP prefix/ASN) used in RSVP-TE.

Cheers,

Richard

Cheers,

Volker







On 03.08.2012 11:03, Y. Richard Yang wrote:
Hi Stefano,

Good post! I added the ALTO mailing list, given the relevance. I hope
that this is OK cross posting.

First, a few comments on ALTO:

View granularity:

- ALTO currently defines two abstract network topology data structures:
Network Map and Cost Map(s). More link-state oriented maps (graphs),
with aggregations and transformations, can be added efficiently to ALTO.
Some initial efforts are already on the way (e.g., see the graph
representation proposal at page 9:
http://www.ietf.org/proceedings/84/slides/slides-84-alto-1.pdf). Hence,
I see a natural next-step is for ALTO to provide a link-state view to
external entities.

- It is a good comment on the level of details that ALTO should
delivery. This is a good question for the ALTO working group and the
community to discuss. I feel that ALTO should provide multi-levels of
granularity of views, and we should discuss in the working group.

Pull vs push delivery mechanism:

- There are more discussions on adding the incremental update in ALTO.
Multiple mechanisms have been discussed. I feel that it is the right
direction for ALTO.

Now let me understand the deployment model of BGP-LS. Your explanation
on the issues of acquiring routing state is excellent. Let me start by
understanding more details on the deployment model of BGP-LS inside a
network:

- A set N_igp of BGP-LS instances are deployed to collect IGP info. You
need multiple instances because IGP needs direct connectivity
(adjacency). Each instance here receives (potentially multiple) IGP
updates and streams (relays) to an another (remote) entity, which I
assume is a master BGP-LS instance. So each of these N_igp instances is
IGP-in and BGP-LS out. This appears to be shown in Figure 1 of
draft-gredler-idr-ls-distribution.

- A set N_egp of BGP-LS instances are deployed to collect BGP feeds. You
also may need multiple instances because the network does not want to
see aggregated states but raw states. These instances will feed to the
master BGP-LS as well.

- The master BGP-LS aggregates the multiple BGP-LS ins (and maybe some
direct IGP/EGP ins) and pushes (after policy) to other BGP-LS peers to
use: for example, an ALTO Server transforms/aggregates the feed to
generate ALTO views (maps and graphs), and an PCE uses the feed to
maintain its TED. One could even imagine that ALTO builds a detailed TED
and feeds to PCE, but this beyond the scope of this discussion. The
master BGP-LS is BGP-LS in and BGP-LS out. It is also possible that the
master BGP-LS does not push to any other entities and simply maintains
an internal DB for others to query.

Do I understand it correctly?

Now, we can take a look at more specifics of BGP-LS.

A first perspective is the semantics of the content. If the objective is
to solve the aforementioned deployment issue, then an alternative
solution is to introduce a simple LS update tunneling protocol, where a
link-state proxy forwards LS messages to a collector. The current design
of BGP-LS starts with such a feeling (i.e., an NLRI starts with the
Protocol ID, which indicates it is from IS-IS level 1 IS-IS level 2,
OSPF, etc). However, the protocol appears to (try to) go beyond simple
tunneling and introduces a common LS schema, by converting/filtering
individual IGP LS messages to some common format. I feel that it can be
helpful to first specify the schema (LS data model) instead of the
specific encoding. For example, OSPF specifies LS Age, and this is
filtered. (Please correct me if I missed it). On the other hand, one can
think that some Age info can be helpful for one to understand the
"freshness" of the LS. A problem studied in database is heterogeneous
databases, to merge multiple data sources (IS-IS, OSPF, etc) to a single
schema, and there can be many problems. If there is such a study, please
do share a pointer.

A second perspective is using BGP as the transport. What key features
from BGP do we really need (yes, weak-typed TLV encoding offers a lot of
flexibility)? What features of BGP do we not need (e.g., BGP is a
routing protocol and hence builds in features to handle convergence such
as dampening)? What may be missing (e.g., a capability of pull or
filtering of push). I feel that these issues should be discussed. If
they have already been discussed, please do share a pointer, as I am
definitely a new comer.

Thanks!

Richard

On 8/2/12 11:54 PM, stefano previdi wrote:
All,

as co-author of both BGP-LS and ALTO drafts, I'd try to clarify a few
things:

ALTO has been designed in order to deliver to applications (through
http/json):

1. two maps representing the network topology in an abstracted view
(or set of views through multiple maps). The map does not include
the details of a link-state database and therefore have little use
for any element that would need to retrieve from the network the
detailed/complete network layer topology, for example: link
addresses or link BW resources, etc. IOW: ALTO maps do not have
the granularity of a link-state database and ALTO protocol is not
designed to deliver such details.

and/or

2. Ranking services where a client sends a bunch of IP addresses in
a message and the ALTO server replies by ranking these addresses
based on their topological/network distance (or whatever criteria
the ALTO server has been configured for). This is called: Endpoint
Cost Service.

When using ALTO maps, and the ALTO protocol being http/pull based,
there's no such concept of unsolicited routing updates. An ALTO
client is typically a browser that will pull the maps from an ALTO
server using http. The ALTO server will make no effort to ensure the
client has the latest view of the topology (i.e.: It's the role of the
client to poll for new maps time to time).

Now, in order for an ALTO server to deliver Maps or Ranking services,
it needs to build some form of topology and in order to achieve this,
it needs somehow to be fed by either the operator (configuration) or
to receive dynamically topology information from the network (e.g.:
ISIS/OSPF/BGP).

Here we had two options:
1. ALTO server to implement ISIS/OSPF/BGP and establish IGP adjacencies
to ABRs or L1L2 routers in each area so to retrieve the LSDB from
each area. In practice I know no SP willing/accepting to open their
IGP to an ALTO server. Also, IGP requires direct connectivity
(adjacency) so from an operation point of view is complex and not
desired.
2. Use a database distribution protocol running on top of a reliable
transport layer that would allow an ALTO server to connect to a
_single_ and _remote_ Route Reflector (i.e.: no need to be directly
connected) and grab the whole network topology that will be updated
using standard routing protocol mechanisms (i.e.: routing updates)
and that would allow the operator to control (through policies and
filters) what to distribute and to which server.

Benefits: single (or dual at most for redundancy) connection for
the ALTO server (rather than having a direct adjacency with each
ABR) and, from the operator perspective, single point of
distribution of network topology (easier to apply policies and
control what you deliver). This is what BGP-LS is about.

BGP-LS defines new AFI/SAFI for a new NLRI and attributes that convey
link-state and, more generically, any type of topology information.
The draft specifies NLRI and attributes that map whatever you can
find in a link-state database.

We currently have draft-gredler-idr-ls-distribution in the process
(hopefully) to be adopted as WG item in IDR WG (so far we 're getting
good support). We also have 3 implementations of BGP-LS.

Deployment-wise: BGP-LS is not yet deployed, however, we already have
deployments (I know at least two) where an ALTO server retrieves IP
prefix information from remote BGP RRs (for ipv4). The same scheme
will be used once BGP-LS will be deployed (so to say that it is not
something that we invented after a couple of beers but corresponds to
requirements for delivering network services to upper layers while
still controlling efficiently what you distribute, to whom and in
which form (note that, often, beers are anyway part of the process).

More information here:
http://tools.ietf.org/html/draft-gredler-idr-ls-distribution-02
http://tools.ietf.org/html/draft-ietf-alto-protocol-12

Hope this helps.

s.



On Aug 3, 2012, at 1:29 AM, Robert Raszuk wrote:
Tom,

I agree that one of the top work items for this effort should be a
standardized topology function, and one that is accessible via a
non-routing protocol.
So if the requirement is to have topology export via non-routing
protocol then I think we should seriously revisit or repackage the
draft-gredler-idr-ls-distribution-01 which works for for both OSPF
and ISIS.

However before that let's really understand the requirement why it
must be exported via non-routing protocol .... Keep in mind that just
to parse BGP UPDATE messages and retrieve interesting pieces out it
it requires very little code rather then full BGP implementation.

The particular feature I like about
draft-gredler-idr-ls-distribution-01 is that it is read-only ;)

R.

I agree that one of the top work items for this effort should be a
standardized topology function, and one that is accessible via a
non-routing protocol. While not exactly "low hanging fruit", it is
something that (to me) is a clear work item with clear goals that
should
be tackled straight away.

--Tom



On 8/2/12 3:24 PM, "James Kempf" <james.kempf@ericsson.com> wrote:

So after seeing part of Alia's talk this morning (I had to leave in
the
middle unfortunately), I'd like to make a couple suggestions. There
were
a lot of ideas presented in the talk, enough for an entire IETF
Area. I
think to make tangible progress, the work needs to be focussed on a
small
subset that would be of immediate interest and usability.

There are a couple areas that suggest themselves, but one that
would be
useful in work that I've been involved in is a standardized format for
network topology representation and a protocol for exchanging it. The
Onix OpenFlow controller has a network information base with a
specialized format for network topology, and every OpenFlow controller
requires this. Having a standardized way to represent it might
foster a
common topology database package. Another application is network
management. Every network management system needs some kind of
topology
representation. Finally, though I am not an expert in PCE
construction,
it would seem to me that a PCE would need some kind of topology
representation in order to perform path calculations. Having a way,for
example, for the OpenFlow controller and the PCE to exchange topology
information would be really useful. I would say to start with physical
topology because that is fundamental, but make the format flexible
enough
to support
virtual topology representation.

jak
_______________________________________________
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


_______________________________________________
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

_______________________________________________
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


_______________________________________________
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto



-- 
===================================================
Dr Greg Bernstein, Grotto Networking (510) 573-2237
--------------080305080401020808030000-- Return-Path: 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 DE07411E80A2; Mon, 6 Aug 2012 10:49:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.092 X-Spam-Level: X-Spam-Status: No, score=-2.092 tagged_above=-999 required=5 tests=[AWL=-0.094, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_33=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aMXjSk6SWPJS; Mon, 6 Aug 2012 10:49:44 -0700 (PDT) Received: from smtp.webfaction.com (mail6.webfaction.com [74.55.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 4336111E808A; Mon, 6 Aug 2012 10:49:44 -0700 (PDT) Received: from [192.168.0.124] (c-67-170-243-110.hsd1.ca.comcast.net [67.170.243.110]) by smtp.webfaction.com (Postfix) with ESMTP id 030F22105505; Mon, 6 Aug 2012 12:49:42 -0500 (CDT) Message-ID: <502003B2.5010605@grotto-networking.com> Date: Mon, 06 Aug 2012 10:49:38 -0700 From: Greg Bernstein User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: "Y. Richard Yang" References: <501B0D75.4090009@raszuk.net> <7E89A05A-CE4E-4FCF-81AB-8F39B42FBF8E@cisco.com> <501C128D.10809@cs.yale.edu> <728F9B956B2C48439CA9294B1723B14623756237@dfweml509-mbs.china.huawei.com> <501C1C74.6040006@cs.yale.edu> In-Reply-To: <501C1C74.6040006@cs.yale.edu> Content-Type: multipart/alternative; boundary="------------090209040004060208090600" X-Mailman-Approved-At: Mon, 06 Aug 2012 11:10:56 -0700 Cc: idr@ietf.org, James Kempf , IETF ALTO , "irs-discuss@ietf.org" Subject: Re: [irs-discuss] [alto] About ALTO Vs. BGP-LS X-BeenThere: irs-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Aug 2012 17:49:47 -0000 This is a multi-part message in MIME format. --------------090209040004060208090600 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi Richard, Stefano, et. al. thanks for the explanations and pointers to the BGP-LS draft. This helps avoid any confusion that BGP-LS is in competition with ALTO. BGP-LS (http://tools.ietf.org/html/draft-gredler-idr-ls-distribution-02) could be used to feed topology/path information to ALTO servers or path computation elements (PCE). As part of that process it would collect link state information from IGPs and possibly abstract it. One partial point of confusion for me as a non-BGP speaker ;-) was in the BGP-LS abstract which stated "In a number of environments, */a component external to a network/* is called upon to perform computations based on the network topology and current state of the connections within the network, including traffic engineering information." or "This document describes a mechanism by which links state and traffic engineering information can be collected from networks and *shared with external components* using the BGP routing protocol." I always considered PCE clients and servers as being within the network (working with privileged or sensitive network information) and an ALTO server as abstracting that information for use by network clients. I guess by "external" to the network meaning was external to the "data plane". I also noticed some parallels with our ALTO large bandwidth use-case/modeling work (section 6 of http://tools.ietf.org/html/draft-bernstein-alto-large-bandwidth-cases-02) and BGP-LS. In particular we both seem to want graph and path abstractions. For path abstractions (aggregation) we needed (due to bandwidth constraints) model a path as one or more abstract links with appropriate properties. It seems a similar situation would hold when trying to aggregate paths with SRLG properties. These similarities make sense since both drafts are concerned with sharing information about the network in an aggregated/abstract form. Best Regards Greg B. On 8/3/2012 11:46 AM, Y. Richard Yang wrote: > Hi, > > Sue suggested that I forward this email to idr for more discussions. > > Thanks. > > Richard > > On 8/3/12 11:24 AM, Susan Hares wrote: >> Richard: >> >> Could you cross-post this note to the idr@ietf.org list. The BGP-LS >> draft is being considered for WG adoption. I think this perspective >> would help the idr WG. >> >> Thank you, >> >> Sue >> >> -----Original Message----- >> From: irs-discuss-bounces@ietf.org >> [mailto:irs-discuss-bounces@ietf.org] On Behalf Of Y. Richard Yang >> Sent: Friday, August 03, 2012 11:04 AM >> To: stefano previdi >> Cc: Thomas Nadeau; James Kempf; IETF ALTO; robert@raszuk.net; >> irs-discuss@ietf.org >> Subject: Re: [irs-discuss] About ALTO Vs. BGP-LS >> >> Hi Stefano, >> >> Good post! I added the ALTO mailing list, given the relevance. I hope >> that this is OK cross posting. >> >> First, a few comments on ALTO: >> >> View granularity: >> >> - ALTO currently defines two abstract network topology data structures: >> Network Map and Cost Map(s). More link-state oriented maps (graphs), >> with aggregations and transformations, can be added efficiently to ALTO. >> Some initial efforts are already on the way (e.g., see the graph >> representation proposal at page 9: >> http://www.ietf.org/proceedings/84/slides/slides-84-alto-1.pdf). Hence, >> I see a natural next-step is for ALTO to provide a link-state view to >> external entities. >> >> - It is a good comment on the level of details that ALTO should >> deliver. This is a good question for the ALTO working group and the >> community to discuss. I feel that ALTO should provide multi-levels of >> granularity of views, and we should discuss in the working group. >> >> Pull vs push delivery mechanism: >> >> - There are more discussions on adding the incremental update in ALTO. >> Multiple mechanisms have been discussed. I feel that it is the right >> direction for ALTO. >> >> Now let me understand the deployment model of BGP-LS. Your explanation >> on the issues of acquiring routing state is excellent. Let me start by >> understanding more details on the deployment model of BGP-LS inside a >> network: >> >> - A set N_igp of BGP-LS instances are deployed to collect IGP info. You >> need multiple instances because IGP needs direct connectivity >> (adjacency). Each instance here receives (potentially multiple) IGP >> updates and streams (relays) to an another (remote) entity, which I >> assume is a master BGP-LS instance. So each of these N_igp instances is >> IGP-in and BGP-LS out. This appears to be shown in Figure 1 of >> draft-gredler-idr-ls-distribution. >> >> - A set N_egp of BGP-LS instances are deployed to collect BGP feeds. You >> also may need multiple instances because the network does not want to >> see aggregated states but raw states. These instances will feed to the >> master BGP-LS as well. >> >> - The master BGP-LS aggregates the multiple BGP-LS ins (and maybe some >> direct IGP/EGP ins) and pushes (after policy) to other BGP-LS peers to >> use: for example, an ALTO Server transforms/aggregates the feed to >> generate ALTO views (maps and graphs), and an PCE uses the feed to >> maintain its TED. One could even imagine that ALTO builds a detailed TED >> and feeds to PCE, but this beyond the scope of this discussion. The >> master BGP-LS is BGP-LS in and BGP-LS out. It is also possible that the >> master BGP-LS does not push to any other entities and simply maintains >> an internal DB for others to query. >> >> Do I understand it correctly? >> >> Now, we can take a look at more specifics of BGP-LS. >> >> A first perspective is the semantics of the content. If the objective is >> to solve the aforementioned deployment issue, then an alternative >> solution is to introduce a simple LS update tunneling protocol, where a >> link-state proxy forwards LS messages to a collector. The current design >> of BGP-LS starts with such a feeling (i.e., an NLRI starts with the >> Protocol ID, which indicates it is from IS-IS level 1 IS-IS level 2, >> OSPF, etc). However, the protocol appears to (try to) go beyond simple >> tunneling and introduces a common LS schema, by converting/filtering >> individual IGP LS messages to some common format. I feel that it can be >> helpful to first specify the schema (LS data model) instead of the >> specific encoding. For example, OSPF specifies LS Age, and this is >> filtered. (Please correct me if I missed it). On the other hand, one can >> think that some Age info can be helpful for one to understand the >> "freshness" of the LS. A problem studied in database is heterogeneous >> databases, to merge multiple data sources (IS-IS, OSPF, etc) to a single >> schema, and there can be many problems. If there is such a study, please >> do share a pointer. >> >> A second perspective is using BGP as the transport. What key features >> from BGP do we really need (yes, weak-typed TLV encoding offers a lot of >> flexibility)? What features of BGP do we not need (e.g., BGP is a >> routing protocol and hence builds in features to handle convergence such >> as dampening)? What may be missing (e.g., a capability of pull or >> filtering of push). I feel that these issues should be discussed. If >> they have already been discussed, please do share a pointer, as I am >> definitely a new comer. >> >> Thanks! >> >> Richard >> >> On 8/2/12 11:54 PM, stefano previdi wrote: >>> All, >>> >>> as co-author of both BGP-LS and ALTO drafts, I'd try to clarify a few >>> things: >>> >>> ALTO has been designed in order to deliver to applications (through >>> http/json): >>> >>> 1. two maps representing the network topology in an abstracted view >>> (or set of views through multiple maps). The map does not include >>> the details of a link-state database and therefore have little use >>> for any element that would need to retrieve from the network the >>> detailed/complete network layer topology, for example: link >>> addresses or link BW resources, etc. IOW: ALTO maps do not have >>> the granularity of a link-state database and ALTO protocol is not >>> designed to deliver such details. >>> >>> and/or >>> >>> 2. Ranking services where a client sends a bunch of IP addresses in >>> a message and the ALTO server replies by ranking these addresses >>> based on their topological/network distance (or whatever criteria >>> the ALTO server has been configured for). This is called: Endpoint >>> Cost Service. >>> >>> When using ALTO maps, and the ALTO protocol being http/pull based, >>> there's no such concept of unsolicited routing updates. An ALTO >>> client is typically a browser that will pull the maps from an ALTO >>> server using http. The ALTO server will make no effort to ensure the >>> client has the latest view of the topology (i.e.: It's the role of the >>> client to poll for new maps time to time). >>> >>> Now, in order for an ALTO server to deliver Maps or Ranking services, >>> it needs to build some form of topology and in order to achieve this, >>> it needs somehow to be fed by either the operator (configuration) or >>> to receive dynamically topology information from the network (e.g.: >>> ISIS/OSPF/BGP). >>> >>> Here we had two options: >>> 1. ALTO server to implement ISIS/OSPF/BGP and establish IGP adjacencies >>> to ABRs or L1L2 routers in each area so to retrieve the LSDB from >>> each area. In practice I know no SP willing/accepting to open >>> their >>> IGP to an ALTO server. Also, IGP requires direct connectivity >>> (adjacency) so from an operation point of view is complex and not >>> desired. >>> 2. Use a database distribution protocol running on top of a reliable >>> transport layer that would allow an ALTO server to connect to a >>> _single_ and _remote_ Route Reflector (i.e.: no need to be >>> directly >>> connected) and grab the whole network topology that will be >>> updated >>> using standard routing protocol mechanisms (i.e.: routing updates) >>> and that would allow the operator to control (through policies and >>> filters) what to distribute and to which server. >>> >>> Benefits: single (or dual at most for redundancy) connection for >>> the ALTO server (rather than having a direct adjacency with each >>> ABR) and, from the operator perspective, single point of >>> distribution of network topology (easier to apply policies and >>> control what you deliver). This is what BGP-LS is about. >>> >>> BGP-LS defines new AFI/SAFI for a new NLRI and attributes that convey >>> link-state and, more generically, any type of topology information. >>> The draft specifies NLRI and attributes that map whatever you can >>> find in a link-state database. >>> >>> We currently have draft-gredler-idr-ls-distribution in the process >>> (hopefully) to be adopted as WG item in IDR WG (so far we 're getting >>> good support). We also have 3 implementations of BGP-LS. >>> >>> Deployment-wise: BGP-LS is not yet deployed, however, we already have >>> deployments (I know at least two) where an ALTO server retrieves IP >>> prefix information from remote BGP RRs (for ipv4). The same scheme >>> will be used once BGP-LS will be deployed (so to say that it is not >>> something that we invented after a couple of beers but corresponds to >>> requirements for delivering network services to upper layers while >>> still controlling efficiently what you distribute, to whom and in >>> which form (note that, often, beers are anyway part of the process). >>> >>> More information here: >>> http://tools.ietf.org/html/draft-gredler-idr-ls-distribution-02 >>> http://tools.ietf.org/html/draft-ietf-alto-protocol-12 >>> >>> Hope this helps. >>> >>> s. >>> >>> >>> >>> On Aug 3, 2012, at 1:29 AM, Robert Raszuk wrote: >>>> Tom, >>>> >>>>> I agree that one of the top work items for this effort should be a >>>>> standardized topology function, and one that is accessible via a >>>>> non-routing protocol. >>>> So if the requirement is to have topology export via non-routing >>>> protocol then I think we should seriously revisit or repackage the >>>> draft-gredler-idr-ls-distribution-01 which works for for both OSPF >>>> and ISIS. >>>> >>>> However before that let's really understand the requirement why it >>>> must be exported via non-routing protocol .... Keep in mind that >>>> just to parse BGP UPDATE messages and retrieve interesting pieces >>>> out it it requires very little code rather then full BGP >>>> implementation. >>>> >>>> The particular feature I like about >>>> draft-gredler-idr-ls-distribution-01 is that it is read-only ;) >>>> >>>> R. >>>> >>>>> I agree that one of the top work items for this effort should >>>>> be a >>>>> standardized topology function, and one that is accessible via a >>>>> non-routing protocol. While not exactly "low hanging fruit", it is >>>>> something that (to me) is a clear work item with clear goals that >>>>> should >>>>> be tackled straight away. >>>>> >>>>> --Tom >>>>> >>>>> >>>>> >>>>> On 8/2/12 3:24 PM, "James Kempf" wrote: >>>>> >>>>>> So after seeing part of Alia's talk this morning (I had to leave >>>>>> in the >>>>>> middle unfortunately), I'd like to make a couple suggestions. >>>>>> There were >>>>>> a lot of ideas presented in the talk, enough for an entire IETF >>>>>> Area. I >>>>>> think to make tangible progress, the work needs to be focussed on >>>>>> a small >>>>>> subset that would be of immediate interest and usability. >>>>>> >>>>>> There are a couple areas that suggest themselves, but one that >>>>>> would be >>>>>> useful in work that I've been involved in is a standardized >>>>>> format for >>>>>> network topology representation and a protocol for exchanging it. >>>>>> The >>>>>> Onix OpenFlow controller has a network information base with a >>>>>> specialized format for network topology, and every OpenFlow >>>>>> controller >>>>>> requires this. Having a standardized way to represent it might >>>>>> foster a >>>>>> common topology database package. Another application is network >>>>>> management. Every network management system needs some kind of >>>>>> topology >>>>>> representation. Finally, though I am not an expert in PCE >>>>>> construction, >>>>>> it would seem to me that a PCE would need some kind of topology >>>>>> representation in order to perform path calculations. Having a >>>>>> way,for >>>>>> example, for the OpenFlow controller and the PCE to exchange >>>>>> topology >>>>>> information would be really useful. I would say to start with >>>>>> physical >>>>>> topology because that is fundamental, but make the format >>>>>> flexible enough >>>>>> to support >>>>>> virtual topology representation. >>>>>> >>>>>> jak >>>>>> _______________________________________________ >>>>>> 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 >>>>> >>>>> >>>> _______________________________________________ >>>> 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 >> _______________________________________________ >> irs-discuss mailing list >> irs-discuss@ietf.org >> https://www.ietf.org/mailman/listinfo/irs-discuss > > _______________________________________________ > alto mailing list > alto@ietf.org > https://www.ietf.org/mailman/listinfo/alto > > -- =================================================== Dr Greg Bernstein, Grotto Networking (510) 573-2237 --------------090209040004060208090600 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Hi Richard, Stefano, et. al. thanks for the explanations and pointers to the BGP-LS draft. This helps avoid any confusion that BGP-LS is in competition with ALTO.

BGP-LS (http://tools.ietf.org/html/draft-gredler-idr-ls-distribution-02) could be used to feed topology/path information to ALTO servers or path computation elements (PCE).  As part of that process it would collect link state information from IGPs and possibly abstract it.

One partial point of confusion for me as a non-BGP speaker ;-)   was in the BGP-LS abstract which stated "In a number of environments, a component external to a network is called upon to perform computations based on the network topology and current state of the connections within the network, including traffic engineering information."  or  "This document describes a mechanism by which links state and traffic engineering information can be collected from networks and shared with external components using the BGP routing protocol."
I always considered PCE clients and servers as being within the network (working with privileged or sensitive network information) and an ALTO server as abstracting that information for use by network clients.  I guess by "external" to the network meaning was external to the "data plane".

I also noticed some parallels with our ALTO large bandwidth use-case/modeling work (section 6 of http://tools.ietf.org/html/draft-bernstein-alto-large-bandwidth-cases-02) and BGP-LS. In particular we both seem to want graph and path abstractions.  For path abstractions (aggregation) we needed (due to bandwidth constraints) model a path as one or more abstract links with appropriate properties.  It seems a similar situation would hold when trying to aggregate paths with SRLG properties.  These similarities make sense since both drafts are concerned with sharing information about the network in an aggregated/abstract form.

Best Regards
Greg B.

 
On 8/3/2012 11:46 AM, Y. Richard Yang wrote:
Hi,

Sue suggested that I forward this email to idr for more discussions.

Thanks.

Richard

On 8/3/12 11:24 AM, Susan Hares wrote:
Richard:

Could you cross-post this note to the idr@ietf.org list. The BGP-LS draft is being considered for WG adoption. I think this perspective would help the idr WG.

Thank you,

Sue

-----Original Message-----
From: irs-discuss-bounces@ietf.org [mailto:irs-discuss-bounces@ietf.org] On Behalf Of Y. Richard Yang
Sent: Friday, August 03, 2012 11:04 AM
To: stefano previdi
Cc: Thomas Nadeau; James Kempf; IETF ALTO; robert@raszuk.net; irs-discuss@ietf.org
Subject: Re: [irs-discuss] About ALTO Vs. BGP-LS

Hi Stefano,

Good post! I added the ALTO mailing list, given the relevance. I hope
that this is OK cross posting.

First, a few comments on ALTO:

View granularity:

- ALTO currently defines two abstract network topology data structures:
Network Map and Cost Map(s). More link-state oriented maps (graphs),
with aggregations and transformations, can be added efficiently to ALTO.
Some initial efforts are already on the way (e.g., see the graph
representation proposal at page 9:
http://www.ietf.org/proceedings/84/slides/slides-84-alto-1.pdf). Hence,
I see a natural next-step is for ALTO to provide a link-state view to
external entities.

- It is a good comment on the level of details that ALTO should
deliver. This is a good question for the ALTO working group and the
community to discuss. I feel that ALTO should provide multi-levels of
granularity of views, and we should discuss in the working group.

Pull vs push delivery mechanism:

- There are more discussions on adding the incremental update in ALTO.
Multiple mechanisms have been discussed. I feel that it is the right
direction for ALTO.

Now let me understand the deployment model of BGP-LS. Your explanation
on the issues of acquiring routing state is excellent. Let me start by
understanding more details on the deployment model of BGP-LS inside a
network:

- A set N_igp of BGP-LS instances are deployed to collect IGP info. You
need multiple instances because IGP needs direct connectivity
(adjacency). Each instance here receives (potentially multiple) IGP
updates and streams (relays) to an another (remote) entity, which I
assume is a master BGP-LS instance. So each of these N_igp instances is
IGP-in and BGP-LS out. This appears to be shown in Figure 1 of
draft-gredler-idr-ls-distribution.

- A set N_egp of BGP-LS instances are deployed to collect BGP feeds. You
also may need multiple instances because the network does not want to
see aggregated states but raw states. These instances will feed to the
master BGP-LS as well.

- The master BGP-LS aggregates the multiple BGP-LS ins (and maybe some
direct IGP/EGP ins) and pushes (after policy) to other BGP-LS peers to
use: for example, an ALTO Server transforms/aggregates the feed to
generate ALTO views (maps and graphs), and an PCE uses the feed to
maintain its TED. One could even imagine that ALTO builds a detailed TED
and feeds to PCE, but this beyond the scope of this discussion. The
master BGP-LS is BGP-LS in and BGP-LS out. It is also possible that the
master BGP-LS does not push to any other entities and simply maintains
an internal DB for others to query.

Do I understand it correctly?

Now, we can take a look at more specifics of BGP-LS.

A first perspective is the semantics of the content. If the objective is
to solve the aforementioned deployment issue, then an alternative
solution is to introduce a simple LS update tunneling protocol, where a
link-state proxy forwards LS messages to a collector. The current design
of BGP-LS starts with such a feeling (i.e., an NLRI starts with the
Protocol ID, which indicates it is from IS-IS level 1 IS-IS level 2,
OSPF, etc).  However, the protocol appears to (try to) go beyond simple
tunneling and introduces a common LS schema, by converting/filtering
individual IGP LS messages to some common format. I feel that it can be
helpful to first specify the schema (LS data model) instead of the
specific encoding. For example, OSPF specifies LS Age, and this is
filtered. (Please correct me if I missed it). On the other hand, one can
think that some Age info can be helpful for one to understand the
"freshness" of the LS. A problem studied in database is heterogeneous
databases, to merge multiple data sources (IS-IS, OSPF, etc) to a single
schema, and there can be many problems. If there is such a study, please
do share a pointer.

A second perspective is using BGP as the transport. What key features
from BGP do we really need (yes, weak-typed TLV encoding offers a lot of
flexibility)? What features of BGP do we not need (e.g., BGP is a
routing protocol and hence builds in features to handle convergence such
as dampening)? What may be missing (e.g., a capability of pull or
filtering of push). I feel that these issues should be discussed. If
they have already been discussed, please do share a pointer, as I am
definitely a new comer.

Thanks!

Richard

On 8/2/12 11:54 PM, stefano previdi wrote:
All,

as co-author of both BGP-LS and ALTO drafts, I'd try to clarify a few
things:

ALTO has been designed in order to deliver to applications (through
http/json):

1. two maps representing the network topology in an abstracted view
     (or set of views through multiple maps). The map does not include
     the details of a link-state database and therefore have little use
     for any element that would need to retrieve from the network the
     detailed/complete network layer topology, for example: link
     addresses or link BW resources, etc. IOW: ALTO maps do not have
     the granularity of a link-state database and ALTO protocol is not
     designed to deliver such details.

and/or

2. Ranking services where a client sends a bunch of IP addresses in
     a message and the ALTO server replies by ranking these addresses
     based on their topological/network distance (or whatever criteria
     the ALTO server has been configured for). This is called: Endpoint
     Cost Service.

When using ALTO maps, and the ALTO protocol being http/pull based,
there's no such concept of unsolicited routing updates. An ALTO
client is typically a browser that will pull the maps from an ALTO
server using http. The ALTO server will make no effort to ensure the
client has the latest view of the topology (i.e.: It's the role of the
client to poll for new maps time to time).

Now, in order for an ALTO server to deliver Maps or Ranking services,
it needs to build some form of topology and in order to achieve this,
it needs somehow to be fed by either the operator (configuration) or
to receive dynamically topology information from the network (e.g.:
ISIS/OSPF/BGP).

Here we had two options:
1. ALTO server to implement ISIS/OSPF/BGP and establish IGP adjacencies
     to ABRs or L1L2 routers in each area so to retrieve the LSDB from
     each area. In practice I know no SP willing/accepting to open their
     IGP to an ALTO server. Also, IGP requires direct connectivity
     (adjacency) so from an operation point of view is complex and not
     desired.
2. Use a database distribution protocol running on top of a reliable
     transport layer that would allow an ALTO server to connect to a
     _single_ and _remote_ Route Reflector (i.e.: no need to be directly
     connected) and grab the whole network topology that will be updated
     using standard routing protocol mechanisms (i.e.: routing updates)
     and that would allow the operator to control (through policies and
     filters) what to distribute and to which server.

     Benefits: single (or dual at most for redundancy) connection for
     the ALTO server (rather than having a direct adjacency with each
     ABR) and, from the operator perspective, single point of
     distribution of network topology (easier to apply policies and
     control what you deliver). This is what BGP-LS is about.

BGP-LS defines new AFI/SAFI for a new NLRI and attributes that convey
link-state and, more generically, any type of topology information.
The draft specifies NLRI and attributes that map whatever you can
find in a link-state database.

We currently have draft-gredler-idr-ls-distribution in the process
(hopefully) to be adopted as WG item in IDR WG (so far we 're getting
good support). We also have 3 implementations of BGP-LS.

Deployment-wise: BGP-LS is not yet deployed, however, we already have
deployments (I know at least two) where an ALTO server retrieves IP
prefix information from remote BGP RRs (for ipv4). The same scheme
will be used once BGP-LS will be deployed (so to say that it is not
something that we invented after a couple of beers but corresponds to
requirements for delivering network services to upper layers while
still controlling efficiently what you distribute, to whom and in
which form (note that, often, beers are anyway part of the process).

More information here:
http://tools.ietf.org/html/draft-gredler-idr-ls-distribution-02
http://tools.ietf.org/html/draft-ietf-alto-protocol-12

Hope this helps.

s.



On Aug 3, 2012, at 1:29 AM, Robert Raszuk wrote:
Tom,

I agree that one of the top work items for this effort should be a
standardized topology function, and one that is accessible via a
non-routing protocol.
So if the requirement is to have topology export via non-routing protocol then I think we should seriously revisit or repackage the draft-gredler-idr-ls-distribution-01 which works for for both OSPF and ISIS.

However before that let's really understand the requirement why it must be exported via non-routing protocol .... Keep in mind that just to parse BGP UPDATE messages and retrieve interesting pieces out it it requires very little code rather then full BGP implementation.

The particular feature I like about draft-gredler-idr-ls-distribution-01 is that it is read-only ;)

R.

    I agree that one of the top work items for this effort should be a
standardized topology function, and one that is accessible via a
non-routing protocol.  While not exactly "low hanging fruit", it is
something that (to me) is a clear work item with clear goals that should
be tackled straight away.

    --Tom



On 8/2/12 3:24 PM, "James Kempf" <james.kempf@ericsson.com> wrote:

So after seeing part of Alia's talk this morning (I had to leave in the
middle unfortunately), I'd like to make a couple suggestions. There were
a lot of ideas presented in the talk, enough for an entire IETF Area. I
think to make tangible progress, the work needs to be focussed on a small
subset that would be of immediate interest and usability.

There are a couple areas that suggest themselves, but one that would be
useful in work that I've been involved in is a standardized format for
network topology representation and a protocol for exchanging it. The
Onix OpenFlow controller has a network information base with a
specialized format for network topology, and every OpenFlow controller
requires this. Having a standardized way to represent it might foster a
common topology database package. Another application is network
management. Every network management system needs some kind of topology
representation. Finally, though I am not an expert in PCE construction,
it would seem to me that a PCE would need some kind of topology
representation in order to perform path calculations. Having a way,for
example, for the OpenFlow controller and the PCE to exchange topology
information would be really useful.  I would say to start with physical
topology because that is fundamental, but make the format flexible enough
to support
virtual topology representation.

            jak
_______________________________________________
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


_______________________________________________
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
_______________________________________________
irs-discuss mailing list
irs-discuss@ietf.org
https://www.ietf.org/mailman/listinfo/irs-discuss

_______________________________________________
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto 




-- 
===================================================
Dr Greg Bernstein, Grotto Networking (510) 573-2237
--------------090209040004060208090600-- Return-Path: 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 B4FB021F8DAB; Fri, 3 Aug 2012 16:57:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.45 X-Spam-Level: X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[AWL=-1.118, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_LOW=-1, SARE_HTML_USL_OBFU=1.666] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S3Qx6q1RsQr0; Fri, 3 Aug 2012 16:57:08 -0700 (PDT) Received: from mail-gg0-f172.google.com (mail-gg0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 6759B21F8D20; Fri, 3 Aug 2012 16:57:08 -0700 (PDT) Received: by ggnc4 with SMTP id c4so1563428ggn.31 for ; Fri, 03 Aug 2012 16:57:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=I8UdNKB+tzrwSGda7KkdpJXpW88WSKVjDkdJcVcvY2w=; b=YIjSNYBBgAf7zAQaSuGho7VbNYaYYqXio2Qv7NGq+RpBFxR4Ah03J/ldmw6Wy3vfnS vnmDbtn/JPxX7M+1owgPTurquZ8WbF3cciogRJbCf+NxY7YbfRj0KNpLS+wVOQELJdyl 3Y8lx6i5hC3R3YkRp5E8rAmbC/R+ijGSY4Iqdur8FRQT342+clWYZQyG8G+XRFQMjmtD 21G//YNMqlTn+SMO84vo0Pg7+IHWgiwkK2ibGKvgFXEbm3k7raDLKZUp0NtqdZ3wxPCU ifbQCTvLeL+Dz2qdkRhxPP4cVuUU8HIXdqdeHG0XpCVbdK4JX+ok2B1nmMLaxAE4Ll8o cogg== MIME-Version: 1.0 Received: by 10.42.61.16 with SMTP id s16mr4770807ich.7.1344038227496; Fri, 03 Aug 2012 16:57:07 -0700 (PDT) Received: by 10.50.34.169 with HTTP; Fri, 3 Aug 2012 16:57:07 -0700 (PDT) Received: by 10.50.34.169 with HTTP; Fri, 3 Aug 2012 16:57:07 -0700 (PDT) In-Reply-To: <501C3999.3080804@cs.yale.edu> References: <501B0D75.4090009@raszuk.net> <7E89A05A-CE4E-4FCF-81AB-8F39B42FBF8E@cisco.com> <501C128D.10809@cs.yale.edu> <501C2047.1000100@bell-labs.com> <501C3999.3080804@cs.yale.edu> Date: Fri, 3 Aug 2012 19:57:07 -0400 Message-ID: From: Alia Atlas To: "Y. Richard Yang" Content-Type: multipart/alternative; boundary=20cf301cc2e21d4fbf04c6654988 Cc: idr@ietf.org, Volker Hilt , robert@raszuk.net, irs-discuss@ietf.org, James Kempf , IETF ALTO , Thomas Nadeau , stefano previdi Subject: Re: [irs-discuss] About ALTO Vs. BGP-LS X-BeenThere: irs-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Aug 2012 23:57:10 -0000 --20cf301cc2e21d4fbf04c6654988 Content-Type: text/plain; charset=ISO-8859-1 I strongly agree that we need to start collecting the use-cases for multiple abstraction levels as well as physical/virtual/private. Alia On Aug 3, 2012 4:51 PM, "Y. Richard Yang" wrote: > Hi Volker, > > On 8/3/12 12:02 PM, Volker Hilt wrote: > >> >> I believe that the capability to provide a simplified view on the network >> topology to an application is a key feature rather than a bug. Applications >> that want to have a view on network topology don't need need a fine grained >> view on the topology in most casts and benefit from having an abstracted >> view. This will simplify processing for the application and enables >> providers to control the exposure of details. >> > Agreed. > > We've seen some numbers for topology data sizes in the incremental >> updates presentation in the ALTO meeting, which provide some insights into >> the amounts of data needed for different topology sizes. >> >> I like the idea of enabling an ALTO server to offer different levels of >> details. This will enable a server to tailor responses to the specific >> client. It will add complexity as the ALTO server itself will have to >> maintain the most complex topology it is offering and will have to keep >> this topology up to date. But this is an interesting question for >> discussion in the WG. >> >> Glad that you also like the idea of different levels of details of the > network topology. If the ALTO Server is given a detailed topology > (constructed from multiple sources, such as routing feed, LSP feed, > configuration files), we can offer multiple topology operators/aggregators > to explore the detailed topology, according to need and policy. A simple > example operator is level (i.e., hierarchy such as at the area level), but > one might specify other operators (e.g., fisheye focus). There are studies > on representation of multi-level graphs that we can try to take advantage > of. This can be a subject for the group to explore. > > We may need to study/collect use cases for multiple level topology. One > interesting example immediately coming to mind is the Abstract Node concept > (specify IP prefix/ASN) used in RSVP-TE. > > Cheers, > > Richard > > Cheers, >> >> Volker >> >> >> >> >> >> >> >> On 03.08.2012 11:03, Y. Richard Yang wrote: >> >>> Hi Stefano, >>> >>> Good post! I added the ALTO mailing list, given the relevance. I hope >>> that this is OK cross posting. >>> >>> First, a few comments on ALTO: >>> >>> View granularity: >>> >>> - ALTO currently defines two abstract network topology data structures: >>> Network Map and Cost Map(s). More link-state oriented maps (graphs), >>> with aggregations and transformations, can be added efficiently to ALTO. >>> Some initial efforts are already on the way (e.g., see the graph >>> representation proposal at page 9: >>> http://www.ietf.org/**proceedings/84/slides/slides-**84-alto-1.pdf). >>> Hence, >>> I see a natural next-step is for ALTO to provide a link-state view to >>> external entities. >>> >>> - It is a good comment on the level of details that ALTO should >>> delivery. This is a good question for the ALTO working group and the >>> community to discuss. I feel that ALTO should provide multi-levels of >>> granularity of views, and we should discuss in the working group. >>> >>> Pull vs push delivery mechanism: >>> >>> - There are more discussions on adding the incremental update in ALTO. >>> Multiple mechanisms have been discussed. I feel that it is the right >>> direction for ALTO. >>> >>> Now let me understand the deployment model of BGP-LS. Your explanation >>> on the issues of acquiring routing state is excellent. Let me start by >>> understanding more details on the deployment model of BGP-LS inside a >>> network: >>> >>> - A set N_igp of BGP-LS instances are deployed to collect IGP info. You >>> need multiple instances because IGP needs direct connectivity >>> (adjacency). Each instance here receives (potentially multiple) IGP >>> updates and streams (relays) to an another (remote) entity, which I >>> assume is a master BGP-LS instance. So each of these N_igp instances is >>> IGP-in and BGP-LS out. This appears to be shown in Figure 1 of >>> draft-gredler-idr-ls-**distribution. >>> >>> - A set N_egp of BGP-LS instances are deployed to collect BGP feeds. You >>> also may need multiple instances because the network does not want to >>> see aggregated states but raw states. These instances will feed to the >>> master BGP-LS as well. >>> >>> - The master BGP-LS aggregates the multiple BGP-LS ins (and maybe some >>> direct IGP/EGP ins) and pushes (after policy) to other BGP-LS peers to >>> use: for example, an ALTO Server transforms/aggregates the feed to >>> generate ALTO views (maps and graphs), and an PCE uses the feed to >>> maintain its TED. One could even imagine that ALTO builds a detailed TED >>> and feeds to PCE, but this beyond the scope of this discussion. The >>> master BGP-LS is BGP-LS in and BGP-LS out. It is also possible that the >>> master BGP-LS does not push to any other entities and simply maintains >>> an internal DB for others to query. >>> >>> Do I understand it correctly? >>> >>> Now, we can take a look at more specifics of BGP-LS. >>> >>> A first perspective is the semantics of the content. If the objective is >>> to solve the aforementioned deployment issue, then an alternative >>> solution is to introduce a simple LS update tunneling protocol, where a >>> link-state proxy forwards LS messages to a collector. The current design >>> of BGP-LS starts with such a feeling (i.e., an NLRI starts with the >>> Protocol ID, which indicates it is from IS-IS level 1 IS-IS level 2, >>> OSPF, etc). However, the protocol appears to (try to) go beyond simple >>> tunneling and introduces a common LS schema, by converting/filtering >>> individual IGP LS messages to some common format. I feel that it can be >>> helpful to first specify the schema (LS data model) instead of the >>> specific encoding. For example, OSPF specifies LS Age, and this is >>> filtered. (Please correct me if I missed it). On the other hand, one can >>> think that some Age info can be helpful for one to understand the >>> "freshness" of the LS. A problem studied in database is heterogeneous >>> databases, to merge multiple data sources (IS-IS, OSPF, etc) to a single >>> schema, and there can be many problems. If there is such a study, please >>> do share a pointer. >>> >>> A second perspective is using BGP as the transport. What key features >>> from BGP do we really need (yes, weak-typed TLV encoding offers a lot of >>> flexibility)? What features of BGP do we not need (e.g., BGP is a >>> routing protocol and hence builds in features to handle convergence such >>> as dampening)? What may be missing (e.g., a capability of pull or >>> filtering of push). I feel that these issues should be discussed. If >>> they have already been discussed, please do share a pointer, as I am >>> definitely a new comer. >>> >>> Thanks! >>> >>> Richard >>> >>> On 8/2/12 11:54 PM, stefano previdi wrote: >>> >>>> All, >>>> >>>> as co-author of both BGP-LS and ALTO drafts, I'd try to clarify a few >>>> things: >>>> >>>> ALTO has been designed in order to deliver to applications (through >>>> http/json): >>>> >>>> 1. two maps representing the network topology in an abstracted view >>>> (or set of views through multiple maps). The map does not include >>>> the details of a link-state database and therefore have little use >>>> for any element that would need to retrieve from the network the >>>> detailed/complete network layer topology, for example: link >>>> addresses or link BW resources, etc. IOW: ALTO maps do not have >>>> the granularity of a link-state database and ALTO protocol is not >>>> designed to deliver such details. >>>> >>>> and/or >>>> >>>> 2. Ranking services where a client sends a bunch of IP addresses in >>>> a message and the ALTO server replies by ranking these addresses >>>> based on their topological/network distance (or whatever criteria >>>> the ALTO server has been configured for). This is called: Endpoint >>>> Cost Service. >>>> >>>> When using ALTO maps, and the ALTO protocol being http/pull based, >>>> there's no such concept of unsolicited routing updates. An ALTO >>>> client is typically a browser that will pull the maps from an ALTO >>>> server using http. The ALTO server will make no effort to ensure the >>>> client has the latest view of the topology (i.e.: It's the role of the >>>> client to poll for new maps time to time). >>>> >>>> Now, in order for an ALTO server to deliver Maps or Ranking services, >>>> it needs to build some form of topology and in order to achieve this, >>>> it needs somehow to be fed by either the operator (configuration) or >>>> to receive dynamically topology information from the network (e.g.: >>>> ISIS/OSPF/BGP). >>>> >>>> Here we had two options: >>>> 1. ALTO server to implement ISIS/OSPF/BGP and establish IGP adjacencies >>>> to ABRs or L1L2 routers in each area so to retrieve the LSDB from >>>> each area. In practice I know no SP willing/accepting to open their >>>> IGP to an ALTO server. Also, IGP requires direct connectivity >>>> (adjacency) so from an operation point of view is complex and not >>>> desired. >>>> 2. Use a database distribution protocol running on top of a reliable >>>> transport layer that would allow an ALTO server to connect to a >>>> _single_ and _remote_ Route Reflector (i.e.: no need to be directly >>>> connected) and grab the whole network topology that will be updated >>>> using standard routing protocol mechanisms (i.e.: routing updates) >>>> and that would allow the operator to control (through policies and >>>> filters) what to distribute and to which server. >>>> >>>> Benefits: single (or dual at most for redundancy) connection for >>>> the ALTO server (rather than having a direct adjacency with each >>>> ABR) and, from the operator perspective, single point of >>>> distribution of network topology (easier to apply policies and >>>> control what you deliver). This is what BGP-LS is about. >>>> >>>> BGP-LS defines new AFI/SAFI for a new NLRI and attributes that convey >>>> link-state and, more generically, any type of topology information. >>>> The draft specifies NLRI and attributes that map whatever you can >>>> find in a link-state database. >>>> >>>> We currently have draft-gredler-idr-ls-**distribution in the process >>>> (hopefully) to be adopted as WG item in IDR WG (so far we 're getting >>>> good support). We also have 3 implementations of BGP-LS. >>>> >>>> Deployment-wise: BGP-LS is not yet deployed, however, we already have >>>> deployments (I know at least two) where an ALTO server retrieves IP >>>> prefix information from remote BGP RRs (for ipv4). The same scheme >>>> will be used once BGP-LS will be deployed (so to say that it is not >>>> something that we invented after a couple of beers but corresponds to >>>> requirements for delivering network services to upper layers while >>>> still controlling efficiently what you distribute, to whom and in >>>> which form (note that, often, beers are anyway part of the process). >>>> >>>> More information here: >>>> http://tools.ietf.org/html/**draft-gredler-idr-ls-**distribution-02 >>>> http://tools.ietf.org/html/**draft-ietf-alto-protocol-12 >>>> >>>> Hope this helps. >>>> >>>> s. >>>> >>>> >>>> >>>> On Aug 3, 2012, at 1:29 AM, Robert Raszuk wrote: >>>> >>>>> Tom, >>>>> >>>>> I agree that one of the top work items for this effort should be a >>>>>> standardized topology function, and one that is accessible via a >>>>>> non-routing protocol. >>>>>> >>>>> So if the requirement is to have topology export via non-routing >>>>> protocol then I think we should seriously revisit or repackage the >>>>> draft-gredler-idr-ls-**distribution-01 which works for for both OSPF >>>>> and ISIS. >>>>> >>>>> However before that let's really understand the requirement why it >>>>> must be exported via non-routing protocol .... Keep in mind that just >>>>> to parse BGP UPDATE messages and retrieve interesting pieces out it >>>>> it requires very little code rather then full BGP implementation. >>>>> >>>>> The particular feature I like about >>>>> draft-gredler-idr-ls-**distribution-01 is that it is read-only ;) >>>>> >>>>> R. >>>>> >>>>> I agree that one of the top work items for this effort should be a >>>>>> standardized topology function, and one that is accessible via a >>>>>> non-routing protocol. While not exactly "low hanging fruit", it is >>>>>> something that (to me) is a clear work item with clear goals that >>>>>> should >>>>>> be tackled straight away. >>>>>> >>>>>> --Tom >>>>>> >>>>>> >>>>>> >>>>>> On 8/2/12 3:24 PM, "James Kempf" wrote: >>>>>> >>>>>> So after seeing part of Alia's talk this morning (I had to leave in >>>>>>> the >>>>>>> middle unfortunately), I'd like to make a couple suggestions. There >>>>>>> were >>>>>>> a lot of ideas presented in the talk, enough for an entire IETF >>>>>>> Area. I >>>>>>> think to make tangible progress, the work needs to be focussed on a >>>>>>> small >>>>>>> subset that would be of immediate interest and usability. >>>>>>> >>>>>>> There are a couple areas that suggest themselves, but one that >>>>>>> would be >>>>>>> useful in work that I've been involved in is a standardized format >>>>>>> for >>>>>>> network topology representation and a protocol for exchanging it. The >>>>>>> Onix OpenFlow controller has a network information base with a >>>>>>> specialized format for network topology, and every OpenFlow >>>>>>> controller >>>>>>> requires this. Having a standardized way to represent it might >>>>>>> foster a >>>>>>> common topology database package. Another application is network >>>>>>> management. Every network management system needs some kind of >>>>>>> topology >>>>>>> representation. Finally, though I am not an expert in PCE >>>>>>> construction, >>>>>>> it would seem to me that a PCE would need some kind of topology >>>>>>> representation in order to perform path calculations. Having a >>>>>>> way,for >>>>>>> example, for the OpenFlow controller and the PCE to exchange topology >>>>>>> information would be really useful. I would say to start with >>>>>>> physical >>>>>>> topology because that is fundamental, but make the format flexible >>>>>>> enough >>>>>>> to support >>>>>>> virtual topology representation. >>>>>>> >>>>>>> jak >>>>>>> ______________________________**_________________ >>>>>>> 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 >>>>>> >>>>>> >>>>>> ______________________________**_________________ >>>>> 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 >>>> >>> >>> ______________________________**_________________ >>> 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 > --20cf301cc2e21d4fbf04c6654988 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

I strongly agree that we need to start collecting the use-cases for mult= iple abstraction levels as well as physical/virtual/private.

Alia

On Aug 3, 2012 4:51 PM, "Y. Richard Yang&qu= ot; <yry@cs.yale.edu> wrote:
Hi Volker,

On 8/3/12 12:02 PM, Volker Hilt wrote:

I believe that the capability to provide a simplified view on the network t= opology to an application is a key feature rather than a bug. Applications = that want to have a view on network topology don't need need a fine gra= ined view on the topology in most casts and benefit from having an abstract= ed view. This will simplify processing for the application and enables prov= iders to control the exposure of details.
Agreed.

We've seen some numbers for topology data sizes in the incremental upda= tes presentation in the ALTO meeting, which provide some insights into the = amounts of data needed for different topology sizes.

I like the idea of enabling an ALTO server to offer different levels of det= ails. This will enable a server to tailor responses to the specific client.= It will add complexity as the ALTO server itself will have to maintain the= most complex topology it is offering and will have to keep this topology u= p to date. But this is an interesting question for discussion in the WG.
Glad that you also like the idea of different levels of details of the netw= ork topology. If the ALTO Server is given a detailed topology (constructed = from multiple sources, such as routing feed, LSP feed, configuration files)= , we can offer multiple topology operators/aggregators to explore the detai= led topology, according to need and policy. A simple example operator is le= vel (i.e., hierarchy such as at the area level), but one might specify othe= r operators (e.g., fisheye focus). There are studies on representation of m= ulti-level graphs that we can try to take advantage of. This can be a subje= ct for the group to explore.

We may need to study/collect use cases for multiple level topology. One int= eresting example immediately coming to mind is the Abstract Node concept (s= pecify IP prefix/ASN) used in RSVP-TE.

Cheers,

Richard

Cheers,

Volker







On 03.08.2012 11:03, Y. Richard Yang wrote:
Hi Stefano,

Good post! I added the ALTO mailing list, given the relevance. I hope
that this is OK cross posting.

First, a few comments on ALTO:

View granularity:

- ALTO currently defines two abstract network topology data structures:
Network Map and Cost Map(s). More link-state oriented maps (graphs),
with aggregations and transformations, can be added efficiently to ALTO. Some initial efforts are already on the way (e.g., see the graph
representation proposal at page 9:
http://www.ietf.org/proceedings/84/slides/slides-<= u>84-alto-1.pdf). Hence,
I see a natural next-step is for ALTO to provide a link-state view to
external entities.

- It is a good comment on the level of details that ALTO should
delivery. This is a good question for the ALTO working group and the
community to discuss. I feel that ALTO should provide multi-levels of
granularity of views, and we should discuss in the working group.

Pull vs push delivery mechanism:

- There are more discussions on adding the incremental update in ALTO.
Multiple mechanisms have been discussed. I feel that it is the right
direction for ALTO.

Now let me understand the deployment model of BGP-LS. Your explanation
on the issues of acquiring routing state is excellent. Let me start by
understanding more details on the deployment model of BGP-LS inside a
network:

- A set N_igp of BGP-LS instances are deployed to collect IGP info. You
need multiple instances because IGP needs direct connectivity
(adjacency). Each instance here receives (potentially multiple) IGP
updates and streams (relays) to an another (remote) entity, which I
assume is a master BGP-LS instance. So each of these N_igp instances is
IGP-in and BGP-LS out. This appears to be shown in Figure 1 of
draft-gredler-idr-ls-distribution.

- A set N_egp of BGP-LS instances are deployed to collect BGP feeds. You also may need multiple instances because the network does not want to
see aggregated states but raw states. These instances will feed to the
master BGP-LS as well.

- The master BGP-LS aggregates the multiple BGP-LS ins (and maybe some
direct IGP/EGP ins) and pushes (after policy) to other BGP-LS peers to
use: for example, an ALTO Server transforms/aggregates the feed to
generate ALTO views (maps and graphs), and an PCE uses the feed to
maintain its TED. One could even imagine that ALTO builds a detailed TED and feeds to PCE, but this beyond the scope of this discussion. The
master BGP-LS is BGP-LS in and BGP-LS out. It is also possible that the
master BGP-LS does not push to any other entities and simply maintains
an internal DB for others to query.

Do I understand it correctly?

Now, we can take a look at more specifics of BGP-LS.

A first perspective is the semantics of the content. If the objective is to solve the aforementioned deployment issue, then an alternative
solution is to introduce a simple LS update tunneling protocol, where a
link-state proxy forwards LS messages to a collector. The current design of BGP-LS starts with such a feeling (i.e., an NLRI starts with the
Protocol ID, which indicates it is from IS-IS level 1 IS-IS level 2,
OSPF, etc). However, the protocol appears to (try to) go beyond simple
tunneling and introduces a common LS schema, by converting/filtering
individual IGP LS messages to some common format. I feel that it can be
helpful to first specify the schema (LS data model) instead of the
specific encoding. For example, OSPF specifies LS Age, and this is
filtered. (Please correct me if I missed it). On the other hand, one can think that some Age info can be helpful for one to understand the
"freshness" of the LS. A problem studied in database is heterogen= eous
databases, to merge multiple data sources (IS-IS, OSPF, etc) to a single schema, and there can be many problems. If there is such a study, please do share a pointer.

A second perspective is using BGP as the transport. What key features
from BGP do we really need (yes, weak-typed TLV encoding offers a lot of flexibility)? What features of BGP do we not need (e.g., BGP is a
routing protocol and hence builds in features to handle convergence such as dampening)? What may be missing (e.g., a capability of pull or
filtering of push). I feel that these issues should be discussed. If
they have already been discussed, please do share a pointer, as I am
definitely a new comer.

Thanks!

Richard

On 8/2/12 11:54 PM, stefano previdi wrote:
All,

as co-author of both BGP-LS and ALTO drafts, I'd try to clarify a few things:

ALTO has been designed in order to deliver to applications (through
http/json):

1. two maps representing the network topology in an abstracted view
(or set of views through multiple maps). The map does not include
the details of a link-state database and therefore have little use
for any element that would need to retrieve from the network the
detailed/complete network layer topology, for example: link
addresses or link BW resources, etc. IOW: ALTO maps do not have
the granularity of a link-state database and ALTO protocol is not
designed to deliver such details.

and/or

2. Ranking services where a client sends a bunch of IP addresses in
a message and the ALTO server replies by ranking these addresses
based on their topological/network distance (or whatever criteria
the ALTO server has been configured for). This is called: Endpoint
Cost Service.

When using ALTO maps, and the ALTO protocol being http/pull based,
there's no such concept of unsolicited routing updates. An ALTO
client is typically a browser that will pull the maps from an ALTO
server using http. The ALTO server will make no effort to ensure the
client has the latest view of the topology (i.e.: It's the role of the<= br> client to poll for new maps time to time).

Now, in order for an ALTO server to deliver Maps or Ranking services,
it needs to build some form of topology and in order to achieve this,
it needs somehow to be fed by either the operator (configuration) or
to receive dynamically topology information from the network (e.g.:
ISIS/OSPF/BGP).

Here we had two options:
1. ALTO server to implement ISIS/OSPF/BGP and establish IGP adjacencies
to ABRs or L1L2 routers in each area so to retrieve the LSDB from
each area. In practice I know no SP willing/accepting to open their
IGP to an ALTO server. Also, IGP requires direct connectivity
(adjacency) so from an operation point of view is complex and not
desired.
2. Use a database distribution protocol running on top of a reliable
transport layer that would allow an ALTO server to connect to a
_single_ and _remote_ Route Reflector (i.e.: no need to be directly
connected) and grab the whole network topology that will be updated
using standard routing protocol mechanisms (i.e.: routing updates)
and that would allow the operator to control (through policies and
filters) what to distribute and to which server.

Benefits: single (or dual at most for redundancy) connection for
the ALTO server (rather than having a direct adjacency with each
ABR) and, from the operator perspective, single point of
distribution of network topology (easier to apply policies and
control what you deliver). This is what BGP-LS is about.

BGP-LS defines new AFI/SAFI for a new NLRI and attributes that convey
link-state and, more generically, any type of topology information.
The draft specifies NLRI and attributes that map whatever you can
find in a link-state database.

We currently have draft-gredler-idr-ls-distribution in the process (hopefully) to be adopted as WG item in IDR WG (so far we 're getting good support). We also have 3 implementations of BGP-LS.

Deployment-wise: BGP-LS is not yet deployed, however, we already have
deployments (I know at least two) where an ALTO server retrieves IP
prefix information from remote BGP RRs (for ipv4). The same scheme
will be used once BGP-LS will be deployed (so to say that it is not
something that we invented after a couple of beers but corresponds to
requirements for delivering network services to upper layers while
still controlling efficiently what you distribute, to whom and in
which form (note that, often, beers are anyway part of the process).

More information here:
http://tools.ietf.org/html/draft-gredler-idr-ls-<= u>distribution-02
http://tools.ietf.org/html/draft-ietf-alto-protocol-12

Hope this helps.

s.



On Aug 3, 2012, at 1:29 AM, Robert Raszuk wrote:
Tom,

I agree that one of the top work items for this effort should be a
standardized topology function, and one that is accessible via a
non-routing protocol.
So if the requirement is to have topology export via non-routing
protocol then I think we should seriously revisit or repackage the
draft-gredler-idr-ls-distribution-01 which works for for both OSPF and ISIS.

However before that let's really understand the requirement why it
must be exported via non-routing protocol .... Keep in mind that just
to parse BGP UPDATE messages and retrieve interesting pieces out it
it requires very little code rather then full BGP implementation.

The particular feature I like about
draft-gredler-idr-ls-distribution-01 is that it is read-only ;)

R.

I agree that one of the top work items for this effort should be a
standardized topology function, and one that is accessible via a
non-routing protocol. While not exactly "low hanging fruit", it i= s
something that (to me) is a clear work item with clear goals that
should
be tackled straight away.

--Tom



On 8/2/12 3:24 PM, "James Kempf" <james.kempf@ericsson.com> wrote:
So after seeing part of Alia's talk this morning (I had to leave in
the
middle unfortunately), I'd like to make a couple suggestions. There
were
a lot of ideas presented in the talk, enough for an entire IETF
Area. I
think to make tangible progress, the work needs to be focussed on a
small
subset that would be of immediate interest and usability.

There are a couple areas that suggest themselves, but one that
would be
useful in work that I've been involved in is a standardized format for<= br> network topology representation and a protocol for exchanging it. The
Onix OpenFlow controller has a network information base with a
specialized format for network topology, and every OpenFlow controller
requires this. Having a standardized way to represent it might
foster a
common topology database package. Another application is network
management. Every network management system needs some kind of
topology
representation. Finally, though I am not an expert in PCE
construction,
it would seem to me that a PCE would need some kind of topology
representation in order to perform path calculations. Having a way,for
example, for the OpenFlow controller and the PCE to exchange topology
information would be really useful. I would say to start with physical
topology because that is fundamental, but make the format flexible
enough
to support
virtual topology representation.

jak
_______________________________________________
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


_______________________________________________
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

_______________________________________________
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
--20cf301cc2e21d4fbf04c6654988-- Return-Path: 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 0738D21E808F; Fri, 3 Aug 2012 13:50:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, J_CHICKENPOX_33=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 30E0G8cduim9; Fri, 3 Aug 2012 13:50:40 -0700 (PDT) Received: from vm-emlprdomr-02.its.yale.edu (vm-emlprdomr-02.its.yale.edu [130.132.50.143]) by ietfa.amsl.com (Postfix) with ESMTP id E464821E808E; Fri, 3 Aug 2012 13:50:39 -0700 (PDT) Received: from Faculty-Supports-MacBook-Pro-2.local ([128.36.46.193]) (authenticated bits=0) by vm-emlprdomr-02.its.yale.edu (8.14.4/8.14.4) with ESMTP id q73KoXle019706 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 3 Aug 2012 16:50:33 -0400 Message-ID: <501C3999.3080804@cs.yale.edu> Date: Fri, 03 Aug 2012 13:50:33 -0700 From: "Y. Richard Yang" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: Volker Hilt References: <501B0D75.4090009@raszuk.net> <7E89A05A-CE4E-4FCF-81AB-8F39B42FBF8E@cisco.com> <501C128D.10809@cs.yale.edu> <501C2047.1000100@bell-labs.com> In-Reply-To: <501C2047.1000100@bell-labs.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.71 on 130.132.50.143 Cc: idr@ietf.org, robert@raszuk.net, irs-discuss@ietf.org, James Kempf , IETF ALTO , Thomas Nadeau , "Y. Richard Yang" , stefano previdi Subject: Re: [irs-discuss] About ALTO Vs. BGP-LS X-BeenThere: irs-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Aug 2012 20:50:42 -0000 Hi Volker, On 8/3/12 12:02 PM, Volker Hilt wrote: > > I believe that the capability to provide a simplified view on the > network topology to an application is a key feature rather than a bug. > Applications that want to have a view on network topology don't need > need a fine grained view on the topology in most casts and benefit > from having an abstracted view. This will simplify processing for the > application and enables providers to control the exposure of details. Agreed. > We've seen some numbers for topology data sizes in the incremental > updates presentation in the ALTO meeting, which provide some insights > into the amounts of data needed for different topology sizes. > > I like the idea of enabling an ALTO server to offer different levels > of details. This will enable a server to tailor responses to the > specific client. It will add complexity as the ALTO server itself will > have to maintain the most complex topology it is offering and will > have to keep this topology up to date. But this is an interesting > question for discussion in the WG. > Glad that you also like the idea of different levels of details of the network topology. If the ALTO Server is given a detailed topology (constructed from multiple sources, such as routing feed, LSP feed, configuration files), we can offer multiple topology operators/aggregators to explore the detailed topology, according to need and policy. A simple example operator is level (i.e., hierarchy such as at the area level), but one might specify other operators (e.g., fisheye focus). There are studies on representation of multi-level graphs that we can try to take advantage of. This can be a subject for the group to explore. We may need to study/collect use cases for multiple level topology. One interesting example immediately coming to mind is the Abstract Node concept (specify IP prefix/ASN) used in RSVP-TE. Cheers, Richard > Cheers, > > Volker > > > > > > > > On 03.08.2012 11:03, Y. Richard Yang wrote: >> Hi Stefano, >> >> Good post! I added the ALTO mailing list, given the relevance. I hope >> that this is OK cross posting. >> >> First, a few comments on ALTO: >> >> View granularity: >> >> - ALTO currently defines two abstract network topology data structures: >> Network Map and Cost Map(s). More link-state oriented maps (graphs), >> with aggregations and transformations, can be added efficiently to ALTO. >> Some initial efforts are already on the way (e.g., see the graph >> representation proposal at page 9: >> http://www.ietf.org/proceedings/84/slides/slides-84-alto-1.pdf). Hence, >> I see a natural next-step is for ALTO to provide a link-state view to >> external entities. >> >> - It is a good comment on the level of details that ALTO should >> delivery. This is a good question for the ALTO working group and the >> community to discuss. I feel that ALTO should provide multi-levels of >> granularity of views, and we should discuss in the working group. >> >> Pull vs push delivery mechanism: >> >> - There are more discussions on adding the incremental update in ALTO. >> Multiple mechanisms have been discussed. I feel that it is the right >> direction for ALTO. >> >> Now let me understand the deployment model of BGP-LS. Your explanation >> on the issues of acquiring routing state is excellent. Let me start by >> understanding more details on the deployment model of BGP-LS inside a >> network: >> >> - A set N_igp of BGP-LS instances are deployed to collect IGP info. You >> need multiple instances because IGP needs direct connectivity >> (adjacency). Each instance here receives (potentially multiple) IGP >> updates and streams (relays) to an another (remote) entity, which I >> assume is a master BGP-LS instance. So each of these N_igp instances is >> IGP-in and BGP-LS out. This appears to be shown in Figure 1 of >> draft-gredler-idr-ls-distribution. >> >> - A set N_egp of BGP-LS instances are deployed to collect BGP feeds. You >> also may need multiple instances because the network does not want to >> see aggregated states but raw states. These instances will feed to the >> master BGP-LS as well. >> >> - The master BGP-LS aggregates the multiple BGP-LS ins (and maybe some >> direct IGP/EGP ins) and pushes (after policy) to other BGP-LS peers to >> use: for example, an ALTO Server transforms/aggregates the feed to >> generate ALTO views (maps and graphs), and an PCE uses the feed to >> maintain its TED. One could even imagine that ALTO builds a detailed TED >> and feeds to PCE, but this beyond the scope of this discussion. The >> master BGP-LS is BGP-LS in and BGP-LS out. It is also possible that the >> master BGP-LS does not push to any other entities and simply maintains >> an internal DB for others to query. >> >> Do I understand it correctly? >> >> Now, we can take a look at more specifics of BGP-LS. >> >> A first perspective is the semantics of the content. If the objective is >> to solve the aforementioned deployment issue, then an alternative >> solution is to introduce a simple LS update tunneling protocol, where a >> link-state proxy forwards LS messages to a collector. The current design >> of BGP-LS starts with such a feeling (i.e., an NLRI starts with the >> Protocol ID, which indicates it is from IS-IS level 1 IS-IS level 2, >> OSPF, etc). However, the protocol appears to (try to) go beyond simple >> tunneling and introduces a common LS schema, by converting/filtering >> individual IGP LS messages to some common format. I feel that it can be >> helpful to first specify the schema (LS data model) instead of the >> specific encoding. For example, OSPF specifies LS Age, and this is >> filtered. (Please correct me if I missed it). On the other hand, one can >> think that some Age info can be helpful for one to understand the >> "freshness" of the LS. A problem studied in database is heterogeneous >> databases, to merge multiple data sources (IS-IS, OSPF, etc) to a single >> schema, and there can be many problems. If there is such a study, please >> do share a pointer. >> >> A second perspective is using BGP as the transport. What key features >> from BGP do we really need (yes, weak-typed TLV encoding offers a lot of >> flexibility)? What features of BGP do we not need (e.g., BGP is a >> routing protocol and hence builds in features to handle convergence such >> as dampening)? What may be missing (e.g., a capability of pull or >> filtering of push). I feel that these issues should be discussed. If >> they have already been discussed, please do share a pointer, as I am >> definitely a new comer. >> >> Thanks! >> >> Richard >> >> On 8/2/12 11:54 PM, stefano previdi wrote: >>> All, >>> >>> as co-author of both BGP-LS and ALTO drafts, I'd try to clarify a few >>> things: >>> >>> ALTO has been designed in order to deliver to applications (through >>> http/json): >>> >>> 1. two maps representing the network topology in an abstracted view >>> (or set of views through multiple maps). The map does not include >>> the details of a link-state database and therefore have little use >>> for any element that would need to retrieve from the network the >>> detailed/complete network layer topology, for example: link >>> addresses or link BW resources, etc. IOW: ALTO maps do not have >>> the granularity of a link-state database and ALTO protocol is not >>> designed to deliver such details. >>> >>> and/or >>> >>> 2. Ranking services where a client sends a bunch of IP addresses in >>> a message and the ALTO server replies by ranking these addresses >>> based on their topological/network distance (or whatever criteria >>> the ALTO server has been configured for). This is called: Endpoint >>> Cost Service. >>> >>> When using ALTO maps, and the ALTO protocol being http/pull based, >>> there's no such concept of unsolicited routing updates. An ALTO >>> client is typically a browser that will pull the maps from an ALTO >>> server using http. The ALTO server will make no effort to ensure the >>> client has the latest view of the topology (i.e.: It's the role of the >>> client to poll for new maps time to time). >>> >>> Now, in order for an ALTO server to deliver Maps or Ranking services, >>> it needs to build some form of topology and in order to achieve this, >>> it needs somehow to be fed by either the operator (configuration) or >>> to receive dynamically topology information from the network (e.g.: >>> ISIS/OSPF/BGP). >>> >>> Here we had two options: >>> 1. ALTO server to implement ISIS/OSPF/BGP and establish IGP adjacencies >>> to ABRs or L1L2 routers in each area so to retrieve the LSDB from >>> each area. In practice I know no SP willing/accepting to open their >>> IGP to an ALTO server. Also, IGP requires direct connectivity >>> (adjacency) so from an operation point of view is complex and not >>> desired. >>> 2. Use a database distribution protocol running on top of a reliable >>> transport layer that would allow an ALTO server to connect to a >>> _single_ and _remote_ Route Reflector (i.e.: no need to be directly >>> connected) and grab the whole network topology that will be updated >>> using standard routing protocol mechanisms (i.e.: routing updates) >>> and that would allow the operator to control (through policies and >>> filters) what to distribute and to which server. >>> >>> Benefits: single (or dual at most for redundancy) connection for >>> the ALTO server (rather than having a direct adjacency with each >>> ABR) and, from the operator perspective, single point of >>> distribution of network topology (easier to apply policies and >>> control what you deliver). This is what BGP-LS is about. >>> >>> BGP-LS defines new AFI/SAFI for a new NLRI and attributes that convey >>> link-state and, more generically, any type of topology information. >>> The draft specifies NLRI and attributes that map whatever you can >>> find in a link-state database. >>> >>> We currently have draft-gredler-idr-ls-distribution in the process >>> (hopefully) to be adopted as WG item in IDR WG (so far we 're getting >>> good support). We also have 3 implementations of BGP-LS. >>> >>> Deployment-wise: BGP-LS is not yet deployed, however, we already have >>> deployments (I know at least two) where an ALTO server retrieves IP >>> prefix information from remote BGP RRs (for ipv4). The same scheme >>> will be used once BGP-LS will be deployed (so to say that it is not >>> something that we invented after a couple of beers but corresponds to >>> requirements for delivering network services to upper layers while >>> still controlling efficiently what you distribute, to whom and in >>> which form (note that, often, beers are anyway part of the process). >>> >>> More information here: >>> http://tools.ietf.org/html/draft-gredler-idr-ls-distribution-02 >>> http://tools.ietf.org/html/draft-ietf-alto-protocol-12 >>> >>> Hope this helps. >>> >>> s. >>> >>> >>> >>> On Aug 3, 2012, at 1:29 AM, Robert Raszuk wrote: >>>> Tom, >>>> >>>>> I agree that one of the top work items for this effort should be a >>>>> standardized topology function, and one that is accessible via a >>>>> non-routing protocol. >>>> So if the requirement is to have topology export via non-routing >>>> protocol then I think we should seriously revisit or repackage the >>>> draft-gredler-idr-ls-distribution-01 which works for for both OSPF >>>> and ISIS. >>>> >>>> However before that let's really understand the requirement why it >>>> must be exported via non-routing protocol .... Keep in mind that just >>>> to parse BGP UPDATE messages and retrieve interesting pieces out it >>>> it requires very little code rather then full BGP implementation. >>>> >>>> The particular feature I like about >>>> draft-gredler-idr-ls-distribution-01 is that it is read-only ;) >>>> >>>> R. >>>> >>>>> I agree that one of the top work items for this effort should be a >>>>> standardized topology function, and one that is accessible via a >>>>> non-routing protocol. While not exactly "low hanging fruit", it is >>>>> something that (to me) is a clear work item with clear goals that >>>>> should >>>>> be tackled straight away. >>>>> >>>>> --Tom >>>>> >>>>> >>>>> >>>>> On 8/2/12 3:24 PM, "James Kempf" wrote: >>>>> >>>>>> So after seeing part of Alia's talk this morning (I had to leave in >>>>>> the >>>>>> middle unfortunately), I'd like to make a couple suggestions. There >>>>>> were >>>>>> a lot of ideas presented in the talk, enough for an entire IETF >>>>>> Area. I >>>>>> think to make tangible progress, the work needs to be focussed on a >>>>>> small >>>>>> subset that would be of immediate interest and usability. >>>>>> >>>>>> There are a couple areas that suggest themselves, but one that >>>>>> would be >>>>>> useful in work that I've been involved in is a standardized >>>>>> format for >>>>>> network topology representation and a protocol for exchanging it. >>>>>> The >>>>>> Onix OpenFlow controller has a network information base with a >>>>>> specialized format for network topology, and every OpenFlow >>>>>> controller >>>>>> requires this. Having a standardized way to represent it might >>>>>> foster a >>>>>> common topology database package. Another application is network >>>>>> management. Every network management system needs some kind of >>>>>> topology >>>>>> representation. Finally, though I am not an expert in PCE >>>>>> construction, >>>>>> it would seem to me that a PCE would need some kind of topology >>>>>> representation in order to perform path calculations. Having a >>>>>> way,for >>>>>> example, for the OpenFlow controller and the PCE to exchange >>>>>> topology >>>>>> information would be really useful. I would say to start with >>>>>> physical >>>>>> topology because that is fundamental, but make the format flexible >>>>>> enough >>>>>> to support >>>>>> virtual topology representation. >>>>>> >>>>>> jak >>>>>> _______________________________________________ >>>>>> 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 >>>>> >>>>> >>>> _______________________________________________ >>>> 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 >> >> _______________________________________________ >> irs-discuss mailing list >> irs-discuss@ietf.org >> https://www.ietf.org/mailman/listinfo/irs-discuss Return-Path: 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 2FD3A21F8D92; Fri, 3 Aug 2012 12:02:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.149 X-Spam-Level: X-Spam-Status: No, score=-9.149 tagged_above=-999 required=5 tests=[AWL=0.500, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UTvxvKrgdBt2; Fri, 3 Aug 2012 12:02:48 -0700 (PDT) Received: from smail2.alcatel.fr (smail2.alcatel.fr [64.208.49.57]) by ietfa.amsl.com (Postfix) with ESMTP id 9AB0721F8D69; Fri, 3 Aug 2012 12:02:48 -0700 (PDT) Received: from FRMRSSXCHHUB03.dc-m.alcatel-lucent.com (FRMRSSXCHHUB03.dc-m.alcatel-lucent.com [135.120.45.63]) by smail2.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id q73J2dWc022752 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 3 Aug 2012 21:02:41 +0200 Received: from US70UWXCHHUB01.zam.alcatel-lucent.com (135.5.2.48) by FRMRSSXCHHUB03.dc-m.alcatel-lucent.com (135.120.45.63) with Microsoft SMTP Server (TLS) id 8.3.213.0; Fri, 3 Aug 2012 21:02:39 +0200 Received: from [135.244.144.209] (135.5.27.12) by US70UWXCHHUB01.zam.alcatel-lucent.com (135.5.2.48) with Microsoft SMTP Server (TLS) id 14.2.247.3; Fri, 3 Aug 2012 15:02:38 -0400 Message-ID: <501C2047.1000100@bell-labs.com> Date: Fri, 3 Aug 2012 12:02:31 -0700 From: Volker Hilt User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: "Y. Richard Yang" References: <501B0D75.4090009@raszuk.net> <7E89A05A-CE4E-4FCF-81AB-8F39B42FBF8E@cisco.com> <501C128D.10809@cs.yale.edu> In-Reply-To: <501C128D.10809@cs.yale.edu> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [135.5.27.12] X-Scanned-By: MIMEDefang 2.69 on 155.132.188.80 Cc: idr@ietf.org, robert@raszuk.net, irs-discuss@ietf.org, James Kempf , IETF ALTO , Thomas Nadeau , stefano previdi Subject: Re: [irs-discuss] About ALTO Vs. BGP-LS X-BeenThere: irs-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Aug 2012 19:02:50 -0000 Stefano, Richard, great discussion. I believe that the capability to provide a simplified view on the network topology to an application is a key feature rather than a bug. Applications that want to have a view on network topology don't need need a fine grained view on the topology in most casts and benefit from having an abstracted view. This will simplify processing for the application and enables providers to control the exposure of details. We've seen some numbers for topology data sizes in the incremental updates presentation in the ALTO meeting, which provide some insights into the amounts of data needed for different topology sizes. I like the idea of enabling an ALTO server to offer different levels of details. This will enable a server to tailor responses to the specific client. It will add complexity as the ALTO server itself will have to maintain the most complex topology it is offering and will have to keep this topology up to date. But this is an interesting question for discussion in the WG. Cheers, Volker On 03.08.2012 11:03, Y. Richard Yang wrote: > Hi Stefano, > > Good post! I added the ALTO mailing list, given the relevance. I hope > that this is OK cross posting. > > First, a few comments on ALTO: > > View granularity: > > - ALTO currently defines two abstract network topology data structures: > Network Map and Cost Map(s). More link-state oriented maps (graphs), > with aggregations and transformations, can be added efficiently to ALTO. > Some initial efforts are already on the way (e.g., see the graph > representation proposal at page 9: > http://www.ietf.org/proceedings/84/slides/slides-84-alto-1.pdf). Hence, > I see a natural next-step is for ALTO to provide a link-state view to > external entities. > > - It is a good comment on the level of details that ALTO should > delivery. This is a good question for the ALTO working group and the > community to discuss. I feel that ALTO should provide multi-levels of > granularity of views, and we should discuss in the working group. > > Pull vs push delivery mechanism: > > - There are more discussions on adding the incremental update in ALTO. > Multiple mechanisms have been discussed. I feel that it is the right > direction for ALTO. > > Now let me understand the deployment model of BGP-LS. Your explanation > on the issues of acquiring routing state is excellent. Let me start by > understanding more details on the deployment model of BGP-LS inside a > network: > > - A set N_igp of BGP-LS instances are deployed to collect IGP info. You > need multiple instances because IGP needs direct connectivity > (adjacency). Each instance here receives (potentially multiple) IGP > updates and streams (relays) to an another (remote) entity, which I > assume is a master BGP-LS instance. So each of these N_igp instances is > IGP-in and BGP-LS out. This appears to be shown in Figure 1 of > draft-gredler-idr-ls-distribution. > > - A set N_egp of BGP-LS instances are deployed to collect BGP feeds. You > also may need multiple instances because the network does not want to > see aggregated states but raw states. These instances will feed to the > master BGP-LS as well. > > - The master BGP-LS aggregates the multiple BGP-LS ins (and maybe some > direct IGP/EGP ins) and pushes (after policy) to other BGP-LS peers to > use: for example, an ALTO Server transforms/aggregates the feed to > generate ALTO views (maps and graphs), and an PCE uses the feed to > maintain its TED. One could even imagine that ALTO builds a detailed TED > and feeds to PCE, but this beyond the scope of this discussion. The > master BGP-LS is BGP-LS in and BGP-LS out. It is also possible that the > master BGP-LS does not push to any other entities and simply maintains > an internal DB for others to query. > > Do I understand it correctly? > > Now, we can take a look at more specifics of BGP-LS. > > A first perspective is the semantics of the content. If the objective is > to solve the aforementioned deployment issue, then an alternative > solution is to introduce a simple LS update tunneling protocol, where a > link-state proxy forwards LS messages to a collector. The current design > of BGP-LS starts with such a feeling (i.e., an NLRI starts with the > Protocol ID, which indicates it is from IS-IS level 1 IS-IS level 2, > OSPF, etc). However, the protocol appears to (try to) go beyond simple > tunneling and introduces a common LS schema, by converting/filtering > individual IGP LS messages to some common format. I feel that it can be > helpful to first specify the schema (LS data model) instead of the > specific encoding. For example, OSPF specifies LS Age, and this is > filtered. (Please correct me if I missed it). On the other hand, one can > think that some Age info can be helpful for one to understand the > "freshness" of the LS. A problem studied in database is heterogeneous > databases, to merge multiple data sources (IS-IS, OSPF, etc) to a single > schema, and there can be many problems. If there is such a study, please > do share a pointer. > > A second perspective is using BGP as the transport. What key features > from BGP do we really need (yes, weak-typed TLV encoding offers a lot of > flexibility)? What features of BGP do we not need (e.g., BGP is a > routing protocol and hence builds in features to handle convergence such > as dampening)? What may be missing (e.g., a capability of pull or > filtering of push). I feel that these issues should be discussed. If > they have already been discussed, please do share a pointer, as I am > definitely a new comer. > > Thanks! > > Richard > > On 8/2/12 11:54 PM, stefano previdi wrote: >> All, >> >> as co-author of both BGP-LS and ALTO drafts, I'd try to clarify a few >> things: >> >> ALTO has been designed in order to deliver to applications (through >> http/json): >> >> 1. two maps representing the network topology in an abstracted view >> (or set of views through multiple maps). The map does not include >> the details of a link-state database and therefore have little use >> for any element that would need to retrieve from the network the >> detailed/complete network layer topology, for example: link >> addresses or link BW resources, etc. IOW: ALTO maps do not have >> the granularity of a link-state database and ALTO protocol is not >> designed to deliver such details. >> >> and/or >> >> 2. Ranking services where a client sends a bunch of IP addresses in >> a message and the ALTO server replies by ranking these addresses >> based on their topological/network distance (or whatever criteria >> the ALTO server has been configured for). This is called: Endpoint >> Cost Service. >> >> When using ALTO maps, and the ALTO protocol being http/pull based, >> there's no such concept of unsolicited routing updates. An ALTO >> client is typically a browser that will pull the maps from an ALTO >> server using http. The ALTO server will make no effort to ensure the >> client has the latest view of the topology (i.e.: It's the role of the >> client to poll for new maps time to time). >> >> Now, in order for an ALTO server to deliver Maps or Ranking services, >> it needs to build some form of topology and in order to achieve this, >> it needs somehow to be fed by either the operator (configuration) or >> to receive dynamically topology information from the network (e.g.: >> ISIS/OSPF/BGP). >> >> Here we had two options: >> 1. ALTO server to implement ISIS/OSPF/BGP and establish IGP adjacencies >> to ABRs or L1L2 routers in each area so to retrieve the LSDB from >> each area. In practice I know no SP willing/accepting to open their >> IGP to an ALTO server. Also, IGP requires direct connectivity >> (adjacency) so from an operation point of view is complex and not >> desired. >> 2. Use a database distribution protocol running on top of a reliable >> transport layer that would allow an ALTO server to connect to a >> _single_ and _remote_ Route Reflector (i.e.: no need to be directly >> connected) and grab the whole network topology that will be updated >> using standard routing protocol mechanisms (i.e.: routing updates) >> and that would allow the operator to control (through policies and >> filters) what to distribute and to which server. >> >> Benefits: single (or dual at most for redundancy) connection for >> the ALTO server (rather than having a direct adjacency with each >> ABR) and, from the operator perspective, single point of >> distribution of network topology (easier to apply policies and >> control what you deliver). This is what BGP-LS is about. >> >> BGP-LS defines new AFI/SAFI for a new NLRI and attributes that convey >> link-state and, more generically, any type of topology information. >> The draft specifies NLRI and attributes that map whatever you can >> find in a link-state database. >> >> We currently have draft-gredler-idr-ls-distribution in the process >> (hopefully) to be adopted as WG item in IDR WG (so far we 're getting >> good support). We also have 3 implementations of BGP-LS. >> >> Deployment-wise: BGP-LS is not yet deployed, however, we already have >> deployments (I know at least two) where an ALTO server retrieves IP >> prefix information from remote BGP RRs (for ipv4). The same scheme >> will be used once BGP-LS will be deployed (so to say that it is not >> something that we invented after a couple of beers but corresponds to >> requirements for delivering network services to upper layers while >> still controlling efficiently what you distribute, to whom and in >> which form (note that, often, beers are anyway part of the process). >> >> More information here: >> http://tools.ietf.org/html/draft-gredler-idr-ls-distribution-02 >> http://tools.ietf.org/html/draft-ietf-alto-protocol-12 >> >> Hope this helps. >> >> s. >> >> >> >> On Aug 3, 2012, at 1:29 AM, Robert Raszuk wrote: >>> Tom, >>> >>>> I agree that one of the top work items for this effort should be a >>>> standardized topology function, and one that is accessible via a >>>> non-routing protocol. >>> So if the requirement is to have topology export via non-routing >>> protocol then I think we should seriously revisit or repackage the >>> draft-gredler-idr-ls-distribution-01 which works for for both OSPF >>> and ISIS. >>> >>> However before that let's really understand the requirement why it >>> must be exported via non-routing protocol .... Keep in mind that just >>> to parse BGP UPDATE messages and retrieve interesting pieces out it >>> it requires very little code rather then full BGP implementation. >>> >>> The particular feature I like about >>> draft-gredler-idr-ls-distribution-01 is that it is read-only ;) >>> >>> R. >>> >>>> I agree that one of the top work items for this effort should be a >>>> standardized topology function, and one that is accessible via a >>>> non-routing protocol. While not exactly "low hanging fruit", it is >>>> something that (to me) is a clear work item with clear goals that >>>> should >>>> be tackled straight away. >>>> >>>> --Tom >>>> >>>> >>>> >>>> On 8/2/12 3:24 PM, "James Kempf" wrote: >>>> >>>>> So after seeing part of Alia's talk this morning (I had to leave in >>>>> the >>>>> middle unfortunately), I'd like to make a couple suggestions. There >>>>> were >>>>> a lot of ideas presented in the talk, enough for an entire IETF >>>>> Area. I >>>>> think to make tangible progress, the work needs to be focussed on a >>>>> small >>>>> subset that would be of immediate interest and usability. >>>>> >>>>> There are a couple areas that suggest themselves, but one that >>>>> would be >>>>> useful in work that I've been involved in is a standardized format for >>>>> network topology representation and a protocol for exchanging it. The >>>>> Onix OpenFlow controller has a network information base with a >>>>> specialized format for network topology, and every OpenFlow controller >>>>> requires this. Having a standardized way to represent it might >>>>> foster a >>>>> common topology database package. Another application is network >>>>> management. Every network management system needs some kind of >>>>> topology >>>>> representation. Finally, though I am not an expert in PCE >>>>> construction, >>>>> it would seem to me that a PCE would need some kind of topology >>>>> representation in order to perform path calculations. Having a way,for >>>>> example, for the OpenFlow controller and the PCE to exchange topology >>>>> information would be really useful. I would say to start with physical >>>>> topology because that is fundamental, but make the format flexible >>>>> enough >>>>> to support >>>>> virtual topology representation. >>>>> >>>>> jak >>>>> _______________________________________________ >>>>> 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 >>>> >>>> >>> _______________________________________________ >>> 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 > > _______________________________________________ > irs-discuss mailing list > irs-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/irs-discuss Return-Path: 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 92B2F21F8E3C; Fri, 3 Aug 2012 11:46:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_33=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j6zV8hZmuJQ0; Fri, 3 Aug 2012 11:46:23 -0700 (PDT) Received: from vm-emlprdomr-02.its.yale.edu (vm-emlprdomr-02.its.yale.edu [130.132.50.143]) by ietfa.amsl.com (Postfix) with ESMTP id 0F14921F8E3A; Fri, 3 Aug 2012 11:46:22 -0700 (PDT) Received: from Faculty-Supports-MacBook-Pro-2.local ([128.36.46.193]) (authenticated bits=0) by vm-emlprdomr-02.its.yale.edu (8.14.4/8.14.4) with ESMTP id q73IkDeo016975 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 3 Aug 2012 14:46:13 -0400 Message-ID: <501C1C74.6040006@cs.yale.edu> Date: Fri, 03 Aug 2012 11:46:12 -0700 From: "Y. Richard Yang" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: Susan Hares , idr@ietf.org References: <501B0D75.4090009@raszuk.net> <7E89A05A-CE4E-4FCF-81AB-8F39B42FBF8E@cisco.com> <501C128D.10809@cs.yale.edu> <728F9B956B2C48439CA9294B1723B14623756237@dfweml509-mbs.china.huawei.com> In-Reply-To: <728F9B956B2C48439CA9294B1723B14623756237@dfweml509-mbs.china.huawei.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.71 on 130.132.50.143 Cc: "robert@raszuk.net" , "irs-discuss@ietf.org" , James Kempf , IETF ALTO , Thomas Nadeau , "Y. Richard Yang" , stefano previdi Subject: Re: [irs-discuss] About ALTO Vs. BGP-LS X-BeenThere: irs-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Aug 2012 18:46:24 -0000 Hi, Sue suggested that I forward this email to idr for more discussions. Thanks. Richard On 8/3/12 11:24 AM, Susan Hares wrote: > Richard: > > Could you cross-post this note to the idr@ietf.org list. The BGP-LS draft is being considered for WG adoption. I think this perspective would help the idr WG. > > Thank you, > > Sue > > -----Original Message----- > From: irs-discuss-bounces@ietf.org [mailto:irs-discuss-bounces@ietf.org] On Behalf Of Y. Richard Yang > Sent: Friday, August 03, 2012 11:04 AM > To: stefano previdi > Cc: Thomas Nadeau; James Kempf; IETF ALTO; robert@raszuk.net; irs-discuss@ietf.org > Subject: Re: [irs-discuss] About ALTO Vs. BGP-LS > > Hi Stefano, > > Good post! I added the ALTO mailing list, given the relevance. I hope > that this is OK cross posting. > > First, a few comments on ALTO: > > View granularity: > > - ALTO currently defines two abstract network topology data structures: > Network Map and Cost Map(s). More link-state oriented maps (graphs), > with aggregations and transformations, can be added efficiently to ALTO. > Some initial efforts are already on the way (e.g., see the graph > representation proposal at page 9: > http://www.ietf.org/proceedings/84/slides/slides-84-alto-1.pdf). Hence, > I see a natural next-step is for ALTO to provide a link-state view to > external entities. > > - It is a good comment on the level of details that ALTO should > deliver. This is a good question for the ALTO working group and the > community to discuss. I feel that ALTO should provide multi-levels of > granularity of views, and we should discuss in the working group. > > Pull vs push delivery mechanism: > > - There are more discussions on adding the incremental update in ALTO. > Multiple mechanisms have been discussed. I feel that it is the right > direction for ALTO. > > Now let me understand the deployment model of BGP-LS. Your explanation > on the issues of acquiring routing state is excellent. Let me start by > understanding more details on the deployment model of BGP-LS inside a > network: > > - A set N_igp of BGP-LS instances are deployed to collect IGP info. You > need multiple instances because IGP needs direct connectivity > (adjacency). Each instance here receives (potentially multiple) IGP > updates and streams (relays) to an another (remote) entity, which I > assume is a master BGP-LS instance. So each of these N_igp instances is > IGP-in and BGP-LS out. This appears to be shown in Figure 1 of > draft-gredler-idr-ls-distribution. > > - A set N_egp of BGP-LS instances are deployed to collect BGP feeds. You > also may need multiple instances because the network does not want to > see aggregated states but raw states. These instances will feed to the > master BGP-LS as well. > > - The master BGP-LS aggregates the multiple BGP-LS ins (and maybe some > direct IGP/EGP ins) and pushes (after policy) to other BGP-LS peers to > use: for example, an ALTO Server transforms/aggregates the feed to > generate ALTO views (maps and graphs), and an PCE uses the feed to > maintain its TED. One could even imagine that ALTO builds a detailed TED > and feeds to PCE, but this beyond the scope of this discussion. The > master BGP-LS is BGP-LS in and BGP-LS out. It is also possible that the > master BGP-LS does not push to any other entities and simply maintains > an internal DB for others to query. > > Do I understand it correctly? > > Now, we can take a look at more specifics of BGP-LS. > > A first perspective is the semantics of the content. If the objective is > to solve the aforementioned deployment issue, then an alternative > solution is to introduce a simple LS update tunneling protocol, where a > link-state proxy forwards LS messages to a collector. The current design > of BGP-LS starts with such a feeling (i.e., an NLRI starts with the > Protocol ID, which indicates it is from IS-IS level 1 IS-IS level 2, > OSPF, etc). However, the protocol appears to (try to) go beyond simple > tunneling and introduces a common LS schema, by converting/filtering > individual IGP LS messages to some common format. I feel that it can be > helpful to first specify the schema (LS data model) instead of the > specific encoding. For example, OSPF specifies LS Age, and this is > filtered. (Please correct me if I missed it). On the other hand, one can > think that some Age info can be helpful for one to understand the > "freshness" of the LS. A problem studied in database is heterogeneous > databases, to merge multiple data sources (IS-IS, OSPF, etc) to a single > schema, and there can be many problems. If there is such a study, please > do share a pointer. > > A second perspective is using BGP as the transport. What key features > from BGP do we really need (yes, weak-typed TLV encoding offers a lot of > flexibility)? What features of BGP do we not need (e.g., BGP is a > routing protocol and hence builds in features to handle convergence such > as dampening)? What may be missing (e.g., a capability of pull or > filtering of push). I feel that these issues should be discussed. If > they have already been discussed, please do share a pointer, as I am > definitely a new comer. > > Thanks! > > Richard > > On 8/2/12 11:54 PM, stefano previdi wrote: >> All, >> >> as co-author of both BGP-LS and ALTO drafts, I'd try to clarify a few >> things: >> >> ALTO has been designed in order to deliver to applications (through >> http/json): >> >> 1. two maps representing the network topology in an abstracted view >> (or set of views through multiple maps). The map does not include >> the details of a link-state database and therefore have little use >> for any element that would need to retrieve from the network the >> detailed/complete network layer topology, for example: link >> addresses or link BW resources, etc. IOW: ALTO maps do not have >> the granularity of a link-state database and ALTO protocol is not >> designed to deliver such details. >> >> and/or >> >> 2. Ranking services where a client sends a bunch of IP addresses in >> a message and the ALTO server replies by ranking these addresses >> based on their topological/network distance (or whatever criteria >> the ALTO server has been configured for). This is called: Endpoint >> Cost Service. >> >> When using ALTO maps, and the ALTO protocol being http/pull based, >> there's no such concept of unsolicited routing updates. An ALTO >> client is typically a browser that will pull the maps from an ALTO >> server using http. The ALTO server will make no effort to ensure the >> client has the latest view of the topology (i.e.: It's the role of the >> client to poll for new maps time to time). >> >> Now, in order for an ALTO server to deliver Maps or Ranking services, >> it needs to build some form of topology and in order to achieve this, >> it needs somehow to be fed by either the operator (configuration) or >> to receive dynamically topology information from the network (e.g.: >> ISIS/OSPF/BGP). >> >> Here we had two options: >> 1. ALTO server to implement ISIS/OSPF/BGP and establish IGP adjacencies >> to ABRs or L1L2 routers in each area so to retrieve the LSDB from >> each area. In practice I know no SP willing/accepting to open their >> IGP to an ALTO server. Also, IGP requires direct connectivity >> (adjacency) so from an operation point of view is complex and not >> desired. >> 2. Use a database distribution protocol running on top of a reliable >> transport layer that would allow an ALTO server to connect to a >> _single_ and _remote_ Route Reflector (i.e.: no need to be directly >> connected) and grab the whole network topology that will be updated >> using standard routing protocol mechanisms (i.e.: routing updates) >> and that would allow the operator to control (through policies and >> filters) what to distribute and to which server. >> >> Benefits: single (or dual at most for redundancy) connection for >> the ALTO server (rather than having a direct adjacency with each >> ABR) and, from the operator perspective, single point of >> distribution of network topology (easier to apply policies and >> control what you deliver). This is what BGP-LS is about. >> >> BGP-LS defines new AFI/SAFI for a new NLRI and attributes that convey >> link-state and, more generically, any type of topology information. >> The draft specifies NLRI and attributes that map whatever you can >> find in a link-state database. >> >> We currently have draft-gredler-idr-ls-distribution in the process >> (hopefully) to be adopted as WG item in IDR WG (so far we 're getting >> good support). We also have 3 implementations of BGP-LS. >> >> Deployment-wise: BGP-LS is not yet deployed, however, we already have >> deployments (I know at least two) where an ALTO server retrieves IP >> prefix information from remote BGP RRs (for ipv4). The same scheme >> will be used once BGP-LS will be deployed (so to say that it is not >> something that we invented after a couple of beers but corresponds to >> requirements for delivering network services to upper layers while >> still controlling efficiently what you distribute, to whom and in >> which form (note that, often, beers are anyway part of the process). >> >> More information here: >> http://tools.ietf.org/html/draft-gredler-idr-ls-distribution-02 >> http://tools.ietf.org/html/draft-ietf-alto-protocol-12 >> >> Hope this helps. >> >> s. >> >> >> >> On Aug 3, 2012, at 1:29 AM, Robert Raszuk wrote: >>> Tom, >>> >>>> I agree that one of the top work items for this effort should be a >>>> standardized topology function, and one that is accessible via a >>>> non-routing protocol. >>> So if the requirement is to have topology export via non-routing protocol then I think we should seriously revisit or repackage the draft-gredler-idr-ls-distribution-01 which works for for both OSPF and ISIS. >>> >>> However before that let's really understand the requirement why it must be exported via non-routing protocol .... Keep in mind that just to parse BGP UPDATE messages and retrieve interesting pieces out it it requires very little code rather then full BGP implementation. >>> >>> The particular feature I like about draft-gredler-idr-ls-distribution-01 is that it is read-only ;) >>> >>> R. >>> >>>> I agree that one of the top work items for this effort should be a >>>> standardized topology function, and one that is accessible via a >>>> non-routing protocol. While not exactly "low hanging fruit", it is >>>> something that (to me) is a clear work item with clear goals that should >>>> be tackled straight away. >>>> >>>> --Tom >>>> >>>> >>>> >>>> On 8/2/12 3:24 PM, "James Kempf" wrote: >>>> >>>>> So after seeing part of Alia's talk this morning (I had to leave in the >>>>> middle unfortunately), I'd like to make a couple suggestions. There were >>>>> a lot of ideas presented in the talk, enough for an entire IETF Area. I >>>>> think to make tangible progress, the work needs to be focussed on a small >>>>> subset that would be of immediate interest and usability. >>>>> >>>>> There are a couple areas that suggest themselves, but one that would be >>>>> useful in work that I've been involved in is a standardized format for >>>>> network topology representation and a protocol for exchanging it. The >>>>> Onix OpenFlow controller has a network information base with a >>>>> specialized format for network topology, and every OpenFlow controller >>>>> requires this. Having a standardized way to represent it might foster a >>>>> common topology database package. Another application is network >>>>> management. Every network management system needs some kind of topology >>>>> representation. Finally, though I am not an expert in PCE construction, >>>>> it would seem to me that a PCE would need some kind of topology >>>>> representation in order to perform path calculations. Having a way,for >>>>> example, for the OpenFlow controller and the PCE to exchange topology >>>>> information would be really useful. I would say to start with physical >>>>> topology because that is fundamental, but make the format flexible enough >>>>> to support >>>>> virtual topology representation. >>>>> >>>>> jak >>>>> _______________________________________________ >>>>> 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 >>>> >>>> >>> _______________________________________________ >>> 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 > _______________________________________________ > irs-discuss mailing list > irs-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/irs-discuss Return-Path: 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 D9A7F21F8E4B; Fri, 3 Aug 2012 11:26:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.871 X-Spam-Level: X-Spam-Status: No, score=-4.871 tagged_above=-999 required=5 tests=[AWL=1.128, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YTwEnOo-vavb; Fri, 3 Aug 2012 11:26:15 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 68DF721F8DEB; Fri, 3 Aug 2012 11:26:15 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml201-edg.china.huawei.com) ([172.18.9.243]) by dfwrg02-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AIM52309; Fri, 03 Aug 2012 10:26:15 -0800 (PST) Received: from DFWEML404-HUB.china.huawei.com (10.193.5.203) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 3 Aug 2012 11:24:27 -0700 Received: from dfweml509-mbs.china.huawei.com ([169.254.12.123]) by dfweml404-hub.china.huawei.com ([10.193.5.203]) with mapi id 14.01.0323.003; Fri, 3 Aug 2012 11:24:31 -0700 From: Susan Hares To: "Y. Richard Yang" , stefano previdi Thread-Topic: [irs-discuss] About ALTO Vs. BGP-LS Thread-Index: AQHNcaJp5nxIKpJMfkeuWhP2sbTgaZdIY11w Date: Fri, 3 Aug 2012 18:24:30 +0000 Message-ID: <728F9B956B2C48439CA9294B1723B14623756237@dfweml509-mbs.china.huawei.com> References: <501B0D75.4090009@raszuk.net> <7E89A05A-CE4E-4FCF-81AB-8F39B42FBF8E@cisco.com> <501C128D.10809@cs.yale.edu> In-Reply-To: <501C128D.10809@cs.yale.edu> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.212.245.217] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: Thomas Nadeau , James Kempf , IETF ALTO , "robert@raszuk.net" , "irs-discuss@ietf.org" Subject: Re: [irs-discuss] About ALTO Vs. BGP-LS X-BeenThere: irs-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Aug 2012 18:26:17 -0000 Richard: Could you cross-post this note to the idr@ietf.org list. The BGP-LS draft i= s being considered for WG adoption. I think this perspective would help the= idr WG.=20 Thank you,=20 Sue=20 -----Original Message----- From: irs-discuss-bounces@ietf.org [mailto:irs-discuss-bounces@ietf.org] On= Behalf Of Y. Richard Yang Sent: Friday, August 03, 2012 11:04 AM To: stefano previdi Cc: Thomas Nadeau; James Kempf; IETF ALTO; robert@raszuk.net; irs-discuss@i= etf.org Subject: Re: [irs-discuss] About ALTO Vs. BGP-LS Hi Stefano, Good post! I added the ALTO mailing list, given the relevance. I hope=20 that this is OK cross posting. First, a few comments on ALTO: View granularity: - ALTO currently defines two abstract network topology data structures:=20 Network Map and Cost Map(s). More link-state oriented maps (graphs),=20 with aggregations and transformations, can be added efficiently to ALTO.=20 Some initial efforts are already on the way (e.g., see the graph=20 representation proposal at page 9:=20 http://www.ietf.org/proceedings/84/slides/slides-84-alto-1.pdf). Hence,=20 I see a natural next-step is for ALTO to provide a link-state view to=20 external entities. - It is a good comment on the level of details that ALTO should=20 delivery. This is a good question for the ALTO working group and the=20 community to discuss. I feel that ALTO should provide multi-levels of=20 granularity of views, and we should discuss in the working group. Pull vs push delivery mechanism: - There are more discussions on adding the incremental update in ALTO.=20 Multiple mechanisms have been discussed. I feel that it is the right=20 direction for ALTO. Now let me understand the deployment model of BGP-LS. Your explanation=20 on the issues of acquiring routing state is excellent. Let me start by=20 understanding more details on the deployment model of BGP-LS inside a=20 network: - A set N_igp of BGP-LS instances are deployed to collect IGP info. You=20 need multiple instances because IGP needs direct connectivity=20 (adjacency). Each instance here receives (potentially multiple) IGP=20 updates and streams (relays) to an another (remote) entity, which I=20 assume is a master BGP-LS instance. So each of these N_igp instances is=20 IGP-in and BGP-LS out. This appears to be shown in Figure 1 of=20 draft-gredler-idr-ls-distribution. - A set N_egp of BGP-LS instances are deployed to collect BGP feeds. You=20 also may need multiple instances because the network does not want to=20 see aggregated states but raw states. These instances will feed to the=20 master BGP-LS as well. - The master BGP-LS aggregates the multiple BGP-LS ins (and maybe some=20 direct IGP/EGP ins) and pushes (after policy) to other BGP-LS peers to=20 use: for example, an ALTO Server transforms/aggregates the feed to=20 generate ALTO views (maps and graphs), and an PCE uses the feed to=20 maintain its TED. One could even imagine that ALTO builds a detailed TED=20 and feeds to PCE, but this beyond the scope of this discussion. The=20 master BGP-LS is BGP-LS in and BGP-LS out. It is also possible that the=20 master BGP-LS does not push to any other entities and simply maintains=20 an internal DB for others to query. Do I understand it correctly? Now, we can take a look at more specifics of BGP-LS. A first perspective is the semantics of the content. If the objective is=20 to solve the aforementioned deployment issue, then an alternative=20 solution is to introduce a simple LS update tunneling protocol, where a=20 link-state proxy forwards LS messages to a collector. The current design=20 of BGP-LS starts with such a feeling (i.e., an NLRI starts with the=20 Protocol ID, which indicates it is from IS-IS level 1 IS-IS level 2,=20 OSPF, etc). However, the protocol appears to (try to) go beyond simple=20 tunneling and introduces a common LS schema, by converting/filtering=20 individual IGP LS messages to some common format. I feel that it can be=20 helpful to first specify the schema (LS data model) instead of the=20 specific encoding. For example, OSPF specifies LS Age, and this is=20 filtered. (Please correct me if I missed it). On the other hand, one can=20 think that some Age info can be helpful for one to understand the=20 "freshness" of the LS. A problem studied in database is heterogeneous=20 databases, to merge multiple data sources (IS-IS, OSPF, etc) to a single=20 schema, and there can be many problems. If there is such a study, please=20 do share a pointer. A second perspective is using BGP as the transport. What key features=20 from BGP do we really need (yes, weak-typed TLV encoding offers a lot of=20 flexibility)? What features of BGP do we not need (e.g., BGP is a=20 routing protocol and hence builds in features to handle convergence such=20 as dampening)? What may be missing (e.g., a capability of pull or=20 filtering of push). I feel that these issues should be discussed. If=20 they have already been discussed, please do share a pointer, as I am=20 definitely a new comer. Thanks! Richard On 8/2/12 11:54 PM, stefano previdi wrote: > All, > > as co-author of both BGP-LS and ALTO drafts, I'd try to clarify a few > things: > > ALTO has been designed in order to deliver to applications (through > http/json): > > 1. two maps representing the network topology in an abstracted view > (or set of views through multiple maps). The map does not include > the details of a link-state database and therefore have little use > for any element that would need to retrieve from the network the > detailed/complete network layer topology, for example: link > addresses or link BW resources, etc. IOW: ALTO maps do not have > the granularity of a link-state database and ALTO protocol is not > designed to deliver such details. > > and/or > > 2. Ranking services where a client sends a bunch of IP addresses in > a message and the ALTO server replies by ranking these addresses > based on their topological/network distance (or whatever criteria > the ALTO server has been configured for). This is called: Endpoint > Cost Service. > > When using ALTO maps, and the ALTO protocol being http/pull based, > there's no such concept of unsolicited routing updates. An ALTO > client is typically a browser that will pull the maps from an ALTO > server using http. The ALTO server will make no effort to ensure the > client has the latest view of the topology (i.e.: It's the role of the > client to poll for new maps time to time). > > Now, in order for an ALTO server to deliver Maps or Ranking services, > it needs to build some form of topology and in order to achieve this, > it needs somehow to be fed by either the operator (configuration) or > to receive dynamically topology information from the network (e.g.: > ISIS/OSPF/BGP). > > Here we had two options: > 1. ALTO server to implement ISIS/OSPF/BGP and establish IGP adjacencies > to ABRs or L1L2 routers in each area so to retrieve the LSDB from > each area. In practice I know no SP willing/accepting to open their > IGP to an ALTO server. Also, IGP requires direct connectivity > (adjacency) so from an operation point of view is complex and not > desired. > 2. Use a database distribution protocol running on top of a reliable > transport layer that would allow an ALTO server to connect to a > _single_ and _remote_ Route Reflector (i.e.: no need to be directly > connected) and grab the whole network topology that will be updated > using standard routing protocol mechanisms (i.e.: routing updates) > and that would allow the operator to control (through policies and > filters) what to distribute and to which server. > > Benefits: single (or dual at most for redundancy) connection for > the ALTO server (rather than having a direct adjacency with each > ABR) and, from the operator perspective, single point of > distribution of network topology (easier to apply policies and > control what you deliver). This is what BGP-LS is about. > > BGP-LS defines new AFI/SAFI for a new NLRI and attributes that convey > link-state and, more generically, any type of topology information. > The draft specifies NLRI and attributes that map whatever you can > find in a link-state database. > > We currently have draft-gredler-idr-ls-distribution in the process > (hopefully) to be adopted as WG item in IDR WG (so far we 're getting > good support). We also have 3 implementations of BGP-LS. > > Deployment-wise: BGP-LS is not yet deployed, however, we already have > deployments (I know at least two) where an ALTO server retrieves IP > prefix information from remote BGP RRs (for ipv4). The same scheme > will be used once BGP-LS will be deployed (so to say that it is not > something that we invented after a couple of beers but corresponds to > requirements for delivering network services to upper layers while > still controlling efficiently what you distribute, to whom and in > which form (note that, often, beers are anyway part of the process). > > More information here: > http://tools.ietf.org/html/draft-gredler-idr-ls-distribution-02 > http://tools.ietf.org/html/draft-ietf-alto-protocol-12 > > Hope this helps. > > s. > > > > On Aug 3, 2012, at 1:29 AM, Robert Raszuk wrote: >> Tom, >> >>> I agree that one of the top work items for this effort should be a >>> standardized topology function, and one that is accessible via a >>> non-routing protocol. >> So if the requirement is to have topology export via non-routing protoco= l then I think we should seriously revisit or repackage the draft-gredler-i= dr-ls-distribution-01 which works for for both OSPF and ISIS. >> >> However before that let's really understand the requirement why it must = be exported via non-routing protocol .... Keep in mind that just to parse B= GP UPDATE messages and retrieve interesting pieces out it it requires very = little code rather then full BGP implementation. >> >> The particular feature I like about draft-gredler-idr-ls-distribution-01= is that it is read-only ;) >> >> R. >> >>> I agree that one of the top work items for this effort should be a >>> standardized topology function, and one that is accessible via a >>> non-routing protocol. While not exactly "low hanging fruit", it is >>> something that (to me) is a clear work item with clear goals that shoul= d >>> be tackled straight away. >>> >>> --Tom >>> >>> >>> >>> On 8/2/12 3:24 PM, "James Kempf" wrote: >>> >>>> So after seeing part of Alia's talk this morning (I had to leave in th= e >>>> middle unfortunately), I'd like to make a couple suggestions. There we= re >>>> a lot of ideas presented in the talk, enough for an entire IETF Area. = I >>>> think to make tangible progress, the work needs to be focussed on a sm= all >>>> subset that would be of immediate interest and usability. >>>> >>>> There are a couple areas that suggest themselves, but one that would b= e >>>> useful in work that I've been involved in is a standardized format for >>>> network topology representation and a protocol for exchanging it. The >>>> Onix OpenFlow controller has a network information base with a >>>> specialized format for network topology, and every OpenFlow controller >>>> requires this. Having a standardized way to represent it might foster = a >>>> common topology database package. Another application is network >>>> management. Every network management system needs some kind of topolog= y >>>> representation. Finally, though I am not an expert in PCE construction= , >>>> it would seem to me that a PCE would need some kind of topology >>>> representation in order to perform path calculations. Having a way,for >>>> example, for the OpenFlow controller and the PCE to exchange topology >>>> information would be really useful. I would say to start with physica= l >>>> topology because that is fundamental, but make the format flexible eno= ugh >>>> to support >>>> virtual topology representation. >>>> >>>> jak >>>> _______________________________________________ >>>> 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 >>> >>> >> _______________________________________________ >> 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 _______________________________________________ irs-discuss mailing list irs-discuss@ietf.org https://www.ietf.org/mailman/listinfo/irs-discuss Return-Path: 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 2E1A421F8E43 for ; Fri, 3 Aug 2012 11:22:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.583 X-Spam-Level: X-Spam-Status: No, score=-3.583 tagged_above=-999 required=5 tests=[AWL=0.016, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YRlZdgtJLoZJ for ; Fri, 3 Aug 2012 11:22:56 -0700 (PDT) Received: from mail-gh0-f172.google.com (mail-gh0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id DD66921F8E3F for ; Fri, 3 Aug 2012 11:22:55 -0700 (PDT) Received: by ghbg16 with SMTP id g16so1290950ghb.31 for ; Fri, 03 Aug 2012 11:22:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=IHWoii1eI8DtJRfQmuqrBIRuWY0C7mUK8GFxZ823IB8=; b=aJrYHAoBQcCMZCTgRsfTBNMwbij9LCGqhwep7Yrex71riC0zrRIHd+zkOzZZB6F2lw TnvmGj83k5h9SRtMMMWoCkt8H9mWpUPZOxDtw6UuClBIVUVad1cDFIj9HLjm+CDZwYQo ZpY7vLq2u2CRHr8VNlZQU2OM+c+yWO2f+VyFGueVZ19Ra94CMbSV/ldFJprnEDTXdBY5 kR0kqhnnOvHf8gKK2Hec5X3pyAAJUsNbbrbC+ZS6yLpgYofvngIfk/SMH+cQnslgVNeX er98b8SRII2BxXBf58pFJQPjowSeusKAB7XH3kbESK6XR+Wpe4PA8EGlSNLscPwlhxWc XTGQ== MIME-Version: 1.0 Received: by 10.50.213.1 with SMTP id no1mr4817781igc.71.1344018174839; Fri, 03 Aug 2012 11:22:54 -0700 (PDT) Received: by 10.50.34.169 with HTTP; Fri, 3 Aug 2012 11:22:54 -0700 (PDT) In-Reply-To: References: Date: Fri, 3 Aug 2012 14:22:54 -0400 Message-ID: From: Alia Atlas To: "Jan Medved (jmedved)" Content-Type: text/plain; charset=ISO-8859-1 Cc: Thomas Nadeau , James Kempf , "robert@raszuk.net" , "irs-discuss@ietf.org" Subject: Re: [irs-discuss] Suggestions for IRS Way Forward X-BeenThere: irs-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Aug 2012 18:22:58 -0000 Jan, I think that the topology data-model for IRS would not be confined to what can be learned from a single router. It could be partially populated from a single router. An application can talk to multiple routers to learn the topology; in the same way an application could need to install static routes at multiple routers. A topology-server could talk to as many devices (routers, databases, etc) as necessary to completely fill out the topology data-model. An area that would be quite fruitful to discuss is the multiple abstraction layers as well as, perhaps, some of the physical layers and attributes that would be good to include. I'd really like to get some productive brainstorming done on use-cases related to the topology data-model. I think we might be able to just have a single use-cases and requirements draft in this area - but we'll have to see how large that gets. I know that many of us are quite eager to get to the topology data-model and how it would be populated (and BGP-LS is probably a good way for some of the information), but getting on the same page as far as use-cases and requirements (while quietly writing data-models in the background for sanity-checking) seems like a good first step to me. Alia On Fri, Aug 3, 2012 at 1:33 AM, Jan Medved (jmedved) wrote: > Tom, > > On 8/2/12 4:42 PM, "Thomas Nadeau" wrote: > >> >> >>On 8/2/12 4:29 PM, "Robert Raszuk" wrote: >> >>>Tom, >>> >>> > I agree that one of the top work items for this effort should be a >>> > standardized topology function, and one that is accessible via a >>> > non-routing protocol. >>> >>>So if the requirement is to have topology export via non-routing >>>protocol then I think we should seriously revisit or repackage the >>>draft-gredler-idr-ls-distribution-01 which works for for both OSPF and >>>ISIS. >> >> Cool. >> >> >>>However before that let's really understand the requirement why it must >>>be exported via non-routing protocol .... Keep in mind that just to >>>parse BGP UPDATE messages and retrieve interesting pieces out it it >>>requires very little code rather then full BGP implementation. > > Agreed. > >> >> That seemed to be one of the agreements that came out of the session >>today. > > Can you give more background? > > I don't think it's as straightforward. BGP-LS implements a network-wide > model (data schema), while the scope of IRS is a single node (IMO as it > should be). A node's local IGP and BGP databases do not provide the view > of the entire network topology. To get the whole topology, multiple > routers need to be queried, and the topology needs to be 'stitched' > together. This can either be done in an external node (an ALTO Server, for > example), or in a router. > > If the 'stitching' is done in an external server, would it mean that the > scope of IRS is extended to entities other than routers? > > If the 'stitching' is done at a router, then the router would have to > collect the topology data from other routers - using BGP-LS, for example > ;-) The topology export would then basically have to provide access to the > BGP-LS database through some adaptation function. I wonder what's the gain > in this case... > >> >> --Tom >> > > Thanks, > Jan > >> >>> > > _______________________________________________ > irs-discuss mailing list > irs-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/irs-discuss Return-Path: 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 0A47621F8DE2 for ; Fri, 3 Aug 2012 11:16:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.291 X-Spam-Level: X-Spam-Status: No, score=-3.291 tagged_above=-999 required=5 tests=[AWL=-0.292, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T8d5I8FB8B6u for ; Fri, 3 Aug 2012 11:16:22 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 82B8F21F8DD5 for ; Fri, 3 Aug 2012 11:16:22 -0700 (PDT) Received: by yenm6 with SMTP id m6so841890yen.31 for ; Fri, 03 Aug 2012 11:16:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=3aX7FvIYUZrhxoC6g7rDOAfzn7U4b53cULUseBycNWQ=; b=UOBf02tzd+8DH4A5tmHkrF0yLUqGFbcVChbKhzRqvM841RS/K4WK3cfxIa4aD1nIER eZ0UBNrLDNJ3BpFrB1xnx6LRGuxxJoW20Vtj+K1rfHLqHz5Q/cVMgR/RKo8HPfbiunN8 UcsGgVh1ipAHMAr2Jy4RqvF3T7DK4ul8zU3Rm6JqoVHcaPeT9hp/5CPVu4Akh9mCTwKs dvcrtk2eTYR/NjVZT9vZK/wJ3Qzeoc85k7HGW15+vF7o3jOXM375L5N7+gEG3kxEHeuj h7pJWKbkMUtsgi2Q6TYROy0/hBvR6wrNrqpQN8Ue9bVIcz9bd6FMIC1rf/sk9816h9+5 YZZg== MIME-Version: 1.0 Received: by 10.50.213.98 with SMTP id nr2mr4780049igc.71.1344017781382; Fri, 03 Aug 2012 11:16:21 -0700 (PDT) Received: by 10.50.34.169 with HTTP; Fri, 3 Aug 2012 11:16:21 -0700 (PDT) In-Reply-To: <728F9B956B2C48439CA9294B1723B146237561FB@dfweml509-mbs.china.huawei.com> References: <728F9B956B2C48439CA9294B1723B14623755FD2@dfweml509-mbs.china.huawei.com> <728F9B956B2C48439CA9294B1723B146237561FB@dfweml509-mbs.china.huawei.com> Date: Fri, 3 Aug 2012 14:16:21 -0400 Message-ID: From: Alia Atlas To: Susan Hares Content-Type: text/plain; charset=ISO-8859-1 Cc: James Kempf , "Jan Medved \(jmedved\)" , "robert@raszuk.net" , "irs-discuss@ietf.org" Subject: Re: [irs-discuss] Suggestions for IRS Way Forward X-BeenThere: irs-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Aug 2012 18:16:24 -0000 Just a reminder that while BGP-LS is certainly of interest for IRS, more focused discussion on it for now probably belongs on the IDR mailing list... What would be great to discuss here are the use-cases that aren't satisfied by BGP-LS... Alia On Fri, Aug 3, 2012 at 2:09 PM, Susan Hares wrote: > Jan: > > The real question about this data is the operational questions and aids? For example, > > a) Did the implementations allow ISIS topology to be easily put in this new BGP draft, > b) Do the implementations have filters to prevent this new BGP AFI/SAFI being put in v4/v6 AFI/SAFI BGPs, > c) Is it wise to run both in the same process? Or should it be recommended to have two processes? > d) Have implementers or Service providers tried a test case about putting the ISIS topology into the base protocol. > f) What type of special failure cases can the RR have? > > Summary... It's possible, but do implementations have knobs (in any form) to prevent disaster. > > Sue > > > -----Original Message----- > From: Jan Medved (jmedved) [mailto:jmedved@cisco.com] > Sent: Thursday, August 02, 2012 9:11 PM > To: Susan Hares; James Kempf; robert@raszuk.net > Cc: irs-discuss@ietf.org > Subject: Re: [irs-discuss] Suggestions for IRS Way Forward > > Sue, > > On 8/2/12 6:15 PM, "Susan Hares" wrote: > >>James: >> >>BGP and ISIS may have overkill - or it may be just right. Realize - this >>information does not come for free. > > Agreed. > > It costs to extract the topology information from the router, and it costs > to process it a the client. A routing protocol is a good low cost > interface to get topology data out of a router, since routing is one of > the things that routers are optimized for. > > Now, if a client does not want to listen to BGP Updates (which is not that > difficult to implement, as Robert pointed out), we can have an > intermediary, such an ALTO Server, which will receive routing protocol > updates and provide the topology to clients in an easier-to-digest format. > >> >>You are running BGP sessions across the network passing this information. >>All of the routers must be configured and instrumented separately from >>the regular BGP. ISIS uploaded into these BGP sessions and distributed. > > Not necessarily. In a single-area IGP, a single BGP-LS speaker listening > to IGP updates can retrieve the IGP topology for the whole network. Other > BGP Speakers in the network do not need to be BGP-LS enabled at all. > > If we want to retrieve a complete topology of a multi-area IGP network, > there must be an IGP listener in each IGP area. If a client wants to use > BGP-LS to retrieve the IGP topology from the network, it can set up a > BGP-LS session to each of the IGP listeners (in each area). Alternatively, > we can use a Route Reflector to collect the topology data from all BGP-LS > Speakers; then, the client only needs to establish a single session to the > Route Reflector. Also, the Route Reflector can service multiple clients. > Note that in this case there too is only a small set of routers than need > to be BGP-LS enabled. > > Basically, we leverage existing BGP mechanisms to collect the topology > data from the entire network. We can leverage an existing Route Reflector, > or we can dedicate a Route Reflector just for BGP-LS. Talking to multiple > operators, they prefer the latter option. > >> >>Please ask the authors about the details of their implementations. > > Sure, if more details are required, we'll be glad to discuss :-) > >> >>Sue >> > Thanks, > Jan > >> >>-----Original Message----- >>From: James Kempf [mailto:james.kempf@ericsson.com] >>Sent: Thursday, August 02, 2012 4:53 PM >>To: Susan Hares; robert@raszuk.net >>Cc: irs-discuss@ietf.org >>Subject: RE: [irs-discuss] Suggestions for IRS Way Forward >> >>I'll have to take a look at draft-grendler, I am not familiar with it. >> >>The particular use cases I'm interested in are NMS and OpenFlow >>controller type applications where some centralized entity wants >>information on the topology for managing the elements in a way that >>allows policies to be expressed over the network as a whole and >>translated into specific element management polices by the controller/NMS >>system. The topology data base must be populated somehow, obviously, but >>I assume that would be part of the work (perhaps draft-grendler describes >>this). The physical topology won't be exported outside an operator's >>domain since managing the physical infrastructure is under the purview of >>the operator. If the topology database supports expressing virtual >>topologies (which I believe it should) the operator could expose virtual >>topologies to the customers of the virtual networks, and allow them the >>ability to manage their virtual slices. >> >>Make sense? >> >> jak >> >>> -----Original Message----- >>> From: Susan Hares [mailto:susan.hares@huawei.com] >>> Sent: Thursday, August 02, 2012 4:30 PM >>> To: robert@raszuk.net; James Kempf >>> Cc: irs-discuss@ietf.org >>> Subject: RE: [irs-discuss] Suggestions for IRS Way Forward >>> >>> James: >>> >>> This is the full detailed routes. However, will every ISP >>> share it's ISIS topology. >>> >>> Sue >>> >>> -----Original Message----- >>> From: irs-discuss-bounces@ietf.org >>> [mailto:irs-discuss-bounces@ietf.org] On Behalf Of Robert Raszuk >>> Sent: Thursday, August 02, 2012 4:21 PM >>> To: James Kempf >>> Cc: irs-discuss@ietf.org >>> Subject: Re: [irs-discuss] Suggestions for IRS Way Forward >>> >>> Hi James, >>> >>> On the topic of topology export it is my understanding that >>> we do already have a solution which in fact even authors of >>> IRS framework support and are putting under their umbrella. >>> >>> That is: >>> http://tools.ietf.org/html/draft-gredler-idr-ls-distribution-01 >>> >>> The draft as standards track document defines the topology >>> export standard in form of link and node NLRIs with bunch of TLVs. >>> >>> So the key aspect would be to see what is missing and if >>> something is missing in the space of topology export to >>> evaluate if this solution by principle can be extended to >>> accommodate it. >>> >>> Best, >>> R. >>> >>> >>> > So after seeing part of Alia's talk this morning (I had to leave in >>> > the middle unfortunately), I'd like to make a couple suggestions. >>> > There were a lot of ideas presented in the talk, enough for >>> an entire >>> > IETF Area. I think to make tangible progress, the work needs to be >>> > focussed on a small subset that would be of immediate interest and >>> > usability. >>> > >>> > There are a couple areas that suggest themselves, but one >>> that would >>> > be useful in work that I've been involved in is a >>> standardized format >>> > for network topology representation and a protocol for >>> exchanging it. >>> > The Onix OpenFlow controller has a network information base with a >>> > specialized format for network topology, and every OpenFlow >>> controller >>> > requires this. Having a standardized way to represent it >>> might foster >>> > a common topology database package. Another application is network >>> > management. Every network management system needs some kind of >>> > topology representation. Finally, though I am not an expert in PCE >>> > construction, it would seem to me that a PCE would need >>> some kind of >>> > topology representation in order to perform path >>> calculations. Having >>> > a way,for example, for the OpenFlow controller and the PCE >>> to exchange >>> > topology information would be really useful. >>> > I would say to start with physical topology because that is >>> > fundamental, but make the format flexible enough to support virtual >>> > topology representation. >>> > >>> > jak _______________________________________________ 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 >>> >>_______________________________________________ >>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 Return-Path: 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 445E021F8E01 for ; Fri, 3 Aug 2012 11:11:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.824 X-Spam-Level: X-Spam-Status: No, score=-4.824 tagged_above=-999 required=5 tests=[AWL=1.175, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nokEW+jVcrMY for ; Fri, 3 Aug 2012 11:11:24 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 20AB321F8DF4 for ; Fri, 3 Aug 2012 11:11:24 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml201-edg.china.huawei.com) ([172.18.9.243]) by dfwrg02-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AIM51503; Fri, 03 Aug 2012 10:11:23 -0800 (PST) Received: from DFWEML405-HUB.china.huawei.com (10.193.5.102) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 3 Aug 2012 11:09:44 -0700 Received: from dfweml509-mbs.china.huawei.com ([169.254.12.123]) by dfweml405-hub.china.huawei.com ([10.193.5.102]) with mapi id 14.01.0323.003; Fri, 3 Aug 2012 11:09:46 -0700 From: Susan Hares To: "Jan Medved (jmedved)" , James Kempf , "robert@raszuk.net" Thread-Topic: [irs-discuss] Suggestions for IRS Way Forward Thread-Index: Ac1w/aRFxquJYy0LSJCFfpb4MILlegAQnpmAAA6KuUAAHGUKYAA4c07g//02DgD//5nzQA== Date: Fri, 3 Aug 2012 18:09:46 +0000 Message-ID: <728F9B956B2C48439CA9294B1723B146237561FB@dfweml509-mbs.china.huawei.com> References: <728F9B956B2C48439CA9294B1723B14623755FD2@dfweml509-mbs.china.huawei.com> In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.212.245.217] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "irs-discuss@ietf.org" Subject: Re: [irs-discuss] Suggestions for IRS Way Forward X-BeenThere: irs-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Aug 2012 18:11:25 -0000 Jan: The real question about this data is the operational questions and aids? Fo= r example,=20 a) Did the implementations allow ISIS topology to be easily put in this new= BGP draft, b) Do the implementations have filters to prevent this new BGP AFI/SAFI bei= ng put in v4/v6 AFI/SAFI BGPs, c) Is it wise to run both in the same process? Or should it be recommended = to have two processes?=20 d) Have implementers or Service providers tried a test case about putting t= he ISIS topology into the base protocol.=20 f) What type of special failure cases can the RR have?=20 Summary... It's possible, but do implementations have knobs (in any form) t= o prevent disaster. =20 Sue=20 -----Original Message----- From: Jan Medved (jmedved) [mailto:jmedved@cisco.com]=20 Sent: Thursday, August 02, 2012 9:11 PM To: Susan Hares; James Kempf; robert@raszuk.net Cc: irs-discuss@ietf.org Subject: Re: [irs-discuss] Suggestions for IRS Way Forward Sue, On 8/2/12 6:15 PM, "Susan Hares" wrote: >James: > >BGP and ISIS may have overkill - or it may be just right. Realize - this >information does not come for free. Agreed.=20 It costs to extract the topology information from the router, and it costs to process it a the client. A routing protocol is a good low cost interface to get topology data out of a router, since routing is one of the things that routers are optimized for. Now, if a client does not want to listen to BGP Updates (which is not that difficult to implement, as Robert pointed out), we can have an intermediary, such an ALTO Server, which will receive routing protocol updates and provide the topology to clients in an easier-to-digest format. > >You are running BGP sessions across the network passing this information. >All of the routers must be configured and instrumented separately from >the regular BGP. ISIS uploaded into these BGP sessions and distributed. Not necessarily. In a single-area IGP, a single BGP-LS speaker listening to IGP updates can retrieve the IGP topology for the whole network. Other BGP Speakers in the network do not need to be BGP-LS enabled at all. If we want to retrieve a complete topology of a multi-area IGP network, there must be an IGP listener in each IGP area. If a client wants to use BGP-LS to retrieve the IGP topology from the network, it can set up a BGP-LS session to each of the IGP listeners (in each area). Alternatively, we can use a Route Reflector to collect the topology data from all BGP-LS Speakers; then, the client only needs to establish a single session to the Route Reflector. Also, the Route Reflector can service multiple clients. Note that in this case there too is only a small set of routers than need to be BGP-LS enabled. Basically, we leverage existing BGP mechanisms to collect the topology data from the entire network. We can leverage an existing Route Reflector, or we can dedicate a Route Reflector just for BGP-LS. Talking to multiple operators, they prefer the latter option. > >Please ask the authors about the details of their implementations. Sure, if more details are required, we'll be glad to discuss :-) > >Sue=20 > Thanks, Jan > >-----Original Message----- >From: James Kempf [mailto:james.kempf@ericsson.com] >Sent: Thursday, August 02, 2012 4:53 PM >To: Susan Hares; robert@raszuk.net >Cc: irs-discuss@ietf.org >Subject: RE: [irs-discuss] Suggestions for IRS Way Forward > >I'll have to take a look at draft-grendler, I am not familiar with it. > >The particular use cases I'm interested in are NMS and OpenFlow >controller type applications where some centralized entity wants >information on the topology for managing the elements in a way that >allows policies to be expressed over the network as a whole and >translated into specific element management polices by the controller/NMS >system. The topology data base must be populated somehow, obviously, but >I assume that would be part of the work (perhaps draft-grendler describes >this). The physical topology won't be exported outside an operator's >domain since managing the physical infrastructure is under the purview of >the operator. If the topology database supports expressing virtual >topologies (which I believe it should) the operator could expose virtual >topologies to the customers of the virtual networks, and allow them the >ability to manage their virtual slices. > >Make sense? > > jak =20 > >> -----Original Message----- >> From: Susan Hares [mailto:susan.hares@huawei.com] >> Sent: Thursday, August 02, 2012 4:30 PM >> To: robert@raszuk.net; James Kempf >> Cc: irs-discuss@ietf.org >> Subject: RE: [irs-discuss] Suggestions for IRS Way Forward >>=20 >> James: >>=20 >> This is the full detailed routes. However, will every ISP >> share it's ISIS topology. >>=20 >> Sue=20 >>=20 >> -----Original Message----- >> From: irs-discuss-bounces@ietf.org >> [mailto:irs-discuss-bounces@ietf.org] On Behalf Of Robert Raszuk >> Sent: Thursday, August 02, 2012 4:21 PM >> To: James Kempf >> Cc: irs-discuss@ietf.org >> Subject: Re: [irs-discuss] Suggestions for IRS Way Forward >>=20 >> Hi James, >>=20 >> On the topic of topology export it is my understanding that >> we do already have a solution which in fact even authors of >> IRS framework support and are putting under their umbrella. >>=20 >> That is:=20 >> http://tools.ietf.org/html/draft-gredler-idr-ls-distribution-01 >>=20 >> The draft as standards track document defines the topology >> export standard in form of link and node NLRIs with bunch of TLVs. >>=20 >> So the key aspect would be to see what is missing and if >> something is missing in the space of topology export to >> evaluate if this solution by principle can be extended to >> accommodate it. >>=20 >> Best, >> R. >>=20 >>=20 >> > So after seeing part of Alia's talk this morning (I had to leave in >> > the middle unfortunately), I'd like to make a couple suggestions. >> > There were a lot of ideas presented in the talk, enough for >> an entire=20 >> > IETF Area. I think to make tangible progress, the work needs to be >> > focussed on a small subset that would be of immediate interest and >> > usability. >> > >> > There are a couple areas that suggest themselves, but one >> that would=20 >> > be useful in work that I've been involved in is a >> standardized format >> > for network topology representation and a protocol for >> exchanging it. >> > The Onix OpenFlow controller has a network information base with a >> > specialized format for network topology, and every OpenFlow >> controller=20 >> > requires this. Having a standardized way to represent it >> might foster=20 >> > a common topology database package. Another application is network >> > management. Every network management system needs some kind of >> > topology representation. Finally, though I am not an expert in PCE >> > construction, it would seem to me that a PCE would need >> some kind of=20 >> > topology representation in order to perform path >> calculations. Having >> > a way,for example, for the OpenFlow controller and the PCE >> to exchange=20 >> > topology information would be really useful. >> > I would say to start with physical topology because that is >> > fundamental, but make the format flexible enough to support virtual >> > topology representation. >> > >> > jak _______________________________________________ irs-discuss >> > mailing list irs-discuss@ietf.org >> > https://www.ietf.org/mailman/listinfo/irs-discuss >> > >> > >>=20 >> _______________________________________________ >> irs-discuss mailing list >> irs-discuss@ietf.org >> https://www.ietf.org/mailman/listinfo/irs-discuss >>=20 >_______________________________________________ >irs-discuss mailing list >irs-discuss@ietf.org >https://www.ietf.org/mailman/listinfo/irs-discuss Return-Path: 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 3575521F8D7B; Fri, 3 Aug 2012 11:04:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_33=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qMIAISQrmDym; Fri, 3 Aug 2012 11:04:11 -0700 (PDT) Received: from vm-emlprdomr-06.its.yale.edu (vm-emlprdomr-06.its.yale.edu [130.132.50.147]) by ietfa.amsl.com (Postfix) with ESMTP id A9FFC21F8D7D; Fri, 3 Aug 2012 11:04:04 -0700 (PDT) Received: from Faculty-Supports-MacBook-Pro-2.local ([128.36.46.193]) (authenticated bits=0) by vm-emlprdomr-06.its.yale.edu (8.14.4/8.14.4) with ESMTP id q73I3vJD030038 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 3 Aug 2012 14:03:59 -0400 Message-ID: <501C128D.10809@cs.yale.edu> Date: Fri, 03 Aug 2012 11:03:57 -0700 From: "Y. Richard Yang" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: stefano previdi References: <501B0D75.4090009@raszuk.net> <7E89A05A-CE4E-4FCF-81AB-8F39B42FBF8E@cisco.com> In-Reply-To: <7E89A05A-CE4E-4FCF-81AB-8F39B42FBF8E@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.71 on 130.132.50.147 Cc: Thomas Nadeau , James Kempf , IETF ALTO , robert@raszuk.net, irs-discuss@ietf.org Subject: Re: [irs-discuss] About ALTO Vs. BGP-LS X-BeenThere: irs-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Aug 2012 18:04:13 -0000 Hi Stefano, Good post! I added the ALTO mailing list, given the relevance. I hope that this is OK cross posting. First, a few comments on ALTO: View granularity: - ALTO currently defines two abstract network topology data structures: Network Map and Cost Map(s). More link-state oriented maps (graphs), with aggregations and transformations, can be added efficiently to ALTO. Some initial efforts are already on the way (e.g., see the graph representation proposal at page 9: http://www.ietf.org/proceedings/84/slides/slides-84-alto-1.pdf). Hence, I see a natural next-step is for ALTO to provide a link-state view to external entities. - It is a good comment on the level of details that ALTO should delivery. This is a good question for the ALTO working group and the community to discuss. I feel that ALTO should provide multi-levels of granularity of views, and we should discuss in the working group. Pull vs push delivery mechanism: - There are more discussions on adding the incremental update in ALTO. Multiple mechanisms have been discussed. I feel that it is the right direction for ALTO. Now let me understand the deployment model of BGP-LS. Your explanation on the issues of acquiring routing state is excellent. Let me start by understanding more details on the deployment model of BGP-LS inside a network: - A set N_igp of BGP-LS instances are deployed to collect IGP info. You need multiple instances because IGP needs direct connectivity (adjacency). Each instance here receives (potentially multiple) IGP updates and streams (relays) to an another (remote) entity, which I assume is a master BGP-LS instance. So each of these N_igp instances is IGP-in and BGP-LS out. This appears to be shown in Figure 1 of draft-gredler-idr-ls-distribution. - A set N_egp of BGP-LS instances are deployed to collect BGP feeds. You also may need multiple instances because the network does not want to see aggregated states but raw states. These instances will feed to the master BGP-LS as well. - The master BGP-LS aggregates the multiple BGP-LS ins (and maybe some direct IGP/EGP ins) and pushes (after policy) to other BGP-LS peers to use: for example, an ALTO Server transforms/aggregates the feed to generate ALTO views (maps and graphs), and an PCE uses the feed to maintain its TED. One could even imagine that ALTO builds a detailed TED and feeds to PCE, but this beyond the scope of this discussion. The master BGP-LS is BGP-LS in and BGP-LS out. It is also possible that the master BGP-LS does not push to any other entities and simply maintains an internal DB for others to query. Do I understand it correctly? Now, we can take a look at more specifics of BGP-LS. A first perspective is the semantics of the content. If the objective is to solve the aforementioned deployment issue, then an alternative solution is to introduce a simple LS update tunneling protocol, where a link-state proxy forwards LS messages to a collector. The current design of BGP-LS starts with such a feeling (i.e., an NLRI starts with the Protocol ID, which indicates it is from IS-IS level 1 IS-IS level 2, OSPF, etc). However, the protocol appears to (try to) go beyond simple tunneling and introduces a common LS schema, by converting/filtering individual IGP LS messages to some common format. I feel that it can be helpful to first specify the schema (LS data model) instead of the specific encoding. For example, OSPF specifies LS Age, and this is filtered. (Please correct me if I missed it). On the other hand, one can think that some Age info can be helpful for one to understand the "freshness" of the LS. A problem studied in database is heterogeneous databases, to merge multiple data sources (IS-IS, OSPF, etc) to a single schema, and there can be many problems. If there is such a study, please do share a pointer. A second perspective is using BGP as the transport. What key features from BGP do we really need (yes, weak-typed TLV encoding offers a lot of flexibility)? What features of BGP do we not need (e.g., BGP is a routing protocol and hence builds in features to handle convergence such as dampening)? What may be missing (e.g., a capability of pull or filtering of push). I feel that these issues should be discussed. If they have already been discussed, please do share a pointer, as I am definitely a new comer. Thanks! Richard On 8/2/12 11:54 PM, stefano previdi wrote: > All, > > as co-author of both BGP-LS and ALTO drafts, I'd try to clarify a few > things: > > ALTO has been designed in order to deliver to applications (through > http/json): > > 1. two maps representing the network topology in an abstracted view > (or set of views through multiple maps). The map does not include > the details of a link-state database and therefore have little use > for any element that would need to retrieve from the network the > detailed/complete network layer topology, for example: link > addresses or link BW resources, etc. IOW: ALTO maps do not have > the granularity of a link-state database and ALTO protocol is not > designed to deliver such details. > > and/or > > 2. Ranking services where a client sends a bunch of IP addresses in > a message and the ALTO server replies by ranking these addresses > based on their topological/network distance (or whatever criteria > the ALTO server has been configured for). This is called: Endpoint > Cost Service. > > When using ALTO maps, and the ALTO protocol being http/pull based, > there's no such concept of unsolicited routing updates. An ALTO > client is typically a browser that will pull the maps from an ALTO > server using http. The ALTO server will make no effort to ensure the > client has the latest view of the topology (i.e.: It's the role of the > client to poll for new maps time to time). > > Now, in order for an ALTO server to deliver Maps or Ranking services, > it needs to build some form of topology and in order to achieve this, > it needs somehow to be fed by either the operator (configuration) or > to receive dynamically topology information from the network (e.g.: > ISIS/OSPF/BGP). > > Here we had two options: > 1. ALTO server to implement ISIS/OSPF/BGP and establish IGP adjacencies > to ABRs or L1L2 routers in each area so to retrieve the LSDB from > each area. In practice I know no SP willing/accepting to open their > IGP to an ALTO server. Also, IGP requires direct connectivity > (adjacency) so from an operation point of view is complex and not > desired. > 2. Use a database distribution protocol running on top of a reliable > transport layer that would allow an ALTO server to connect to a > _single_ and _remote_ Route Reflector (i.e.: no need to be directly > connected) and grab the whole network topology that will be updated > using standard routing protocol mechanisms (i.e.: routing updates) > and that would allow the operator to control (through policies and > filters) what to distribute and to which server. > > Benefits: single (or dual at most for redundancy) connection for > the ALTO server (rather than having a direct adjacency with each > ABR) and, from the operator perspective, single point of > distribution of network topology (easier to apply policies and > control what you deliver). This is what BGP-LS is about. > > BGP-LS defines new AFI/SAFI for a new NLRI and attributes that convey > link-state and, more generically, any type of topology information. > The draft specifies NLRI and attributes that map whatever you can > find in a link-state database. > > We currently have draft-gredler-idr-ls-distribution in the process > (hopefully) to be adopted as WG item in IDR WG (so far we 're getting > good support). We also have 3 implementations of BGP-LS. > > Deployment-wise: BGP-LS is not yet deployed, however, we already have > deployments (I know at least two) where an ALTO server retrieves IP > prefix information from remote BGP RRs (for ipv4). The same scheme > will be used once BGP-LS will be deployed (so to say that it is not > something that we invented after a couple of beers but corresponds to > requirements for delivering network services to upper layers while > still controlling efficiently what you distribute, to whom and in > which form (note that, often, beers are anyway part of the process). > > More information here: > http://tools.ietf.org/html/draft-gredler-idr-ls-distribution-02 > http://tools.ietf.org/html/draft-ietf-alto-protocol-12 > > Hope this helps. > > s. > > > > On Aug 3, 2012, at 1:29 AM, Robert Raszuk wrote: >> Tom, >> >>> I agree that one of the top work items for this effort should be a >>> standardized topology function, and one that is accessible via a >>> non-routing protocol. >> So if the requirement is to have topology export via non-routing protocol then I think we should seriously revisit or repackage the draft-gredler-idr-ls-distribution-01 which works for for both OSPF and ISIS. >> >> However before that let's really understand the requirement why it must be exported via non-routing protocol .... Keep in mind that just to parse BGP UPDATE messages and retrieve interesting pieces out it it requires very little code rather then full BGP implementation. >> >> The particular feature I like about draft-gredler-idr-ls-distribution-01 is that it is read-only ;) >> >> R. >> >>> I agree that one of the top work items for this effort should be a >>> standardized topology function, and one that is accessible via a >>> non-routing protocol. While not exactly "low hanging fruit", it is >>> something that (to me) is a clear work item with clear goals that should >>> be tackled straight away. >>> >>> --Tom >>> >>> >>> >>> On 8/2/12 3:24 PM, "James Kempf" wrote: >>> >>>> So after seeing part of Alia's talk this morning (I had to leave in the >>>> middle unfortunately), I'd like to make a couple suggestions. There were >>>> a lot of ideas presented in the talk, enough for an entire IETF Area. I >>>> think to make tangible progress, the work needs to be focussed on a small >>>> subset that would be of immediate interest and usability. >>>> >>>> There are a couple areas that suggest themselves, but one that would be >>>> useful in work that I've been involved in is a standardized format for >>>> network topology representation and a protocol for exchanging it. The >>>> Onix OpenFlow controller has a network information base with a >>>> specialized format for network topology, and every OpenFlow controller >>>> requires this. Having a standardized way to represent it might foster a >>>> common topology database package. Another application is network >>>> management. Every network management system needs some kind of topology >>>> representation. Finally, though I am not an expert in PCE construction, >>>> it would seem to me that a PCE would need some kind of topology >>>> representation in order to perform path calculations. Having a way,for >>>> example, for the OpenFlow controller and the PCE to exchange topology >>>> information would be really useful. I would say to start with physical >>>> topology because that is fundamental, but make the format flexible enough >>>> to support >>>> virtual topology representation. >>>> >>>> jak >>>> _______________________________________________ >>>> 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 >>> >>> >> _______________________________________________ >> 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 Return-Path: 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 30CFA11E809B for ; Thu, 2 Aug 2012 23:54:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.585 X-Spam-Level: X-Spam-Status: No, score=-110.585 tagged_above=-999 required=5 tests=[AWL=-0.586, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R8d-EalDQMBA for ; Thu, 2 Aug 2012 23:54:21 -0700 (PDT) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id CCD2211E809A for ; Thu, 2 Aug 2012 23:54:20 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from stew-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q736sIYX024491 for ; Fri, 3 Aug 2012 08:54:19 +0200 (CEST) Received: from dhcp-10-55-81-188.cisco.com (dhcp-10-55-81-188.cisco.com [10.55.81.188]) by stew-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q736sG51026004; Fri, 3 Aug 2012 08:54:16 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: stefano previdi In-Reply-To: <501B0D75.4090009@raszuk.net> Date: Fri, 3 Aug 2012 08:54:16 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <7E89A05A-CE4E-4FCF-81AB-8F39B42FBF8E@cisco.com> References: <501B0D75.4090009@raszuk.net> To: irs-discuss@ietf.org X-Mailer: Apple Mail (2.1278) Cc: Thomas Nadeau , James Kempf , robert@raszuk.net Subject: [irs-discuss] About ALTO Vs. BGP-LS X-BeenThere: irs-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Aug 2012 06:54:22 -0000 All,=20 as co-author of both BGP-LS and ALTO drafts, I'd try to clarify a few=20 things: ALTO has been designed in order to deliver to applications (through=20 http/json): 1. two maps representing the network topology in an abstracted view=20 (or set of views through multiple maps). The map does not include=20 the details of a link-state database and therefore have little use=20 for any element that would need to retrieve from the network the=20 detailed/complete network layer topology, for example: link=20 addresses or link BW resources, etc. IOW: ALTO maps do not have=20 the granularity of a link-state database and ALTO protocol is not=20 designed to deliver such details. and/or 2. Ranking services where a client sends a bunch of IP addresses in=20 a message and the ALTO server replies by ranking these addresses=20 based on their topological/network distance (or whatever criteria=20 the ALTO server has been configured for). This is called: Endpoint=20 Cost Service. When using ALTO maps, and the ALTO protocol being http/pull based,=20 there's no such concept of unsolicited routing updates. An ALTO=20 client is typically a browser that will pull the maps from an ALTO=20 server using http. The ALTO server will make no effort to ensure the=20 client has the latest view of the topology (i.e.: It's the role of the=20= client to poll for new maps time to time). Now, in order for an ALTO server to deliver Maps or Ranking services,=20 it needs to build some form of topology and in order to achieve this,=20 it needs somehow to be fed by either the operator (configuration) or=20 to receive dynamically topology information from the network (e.g.:=20 ISIS/OSPF/BGP). Here we had two options: 1. ALTO server to implement ISIS/OSPF/BGP and establish IGP adjacencies=20= to ABRs or L1L2 routers in each area so to retrieve the LSDB from=20 each area. In practice I know no SP willing/accepting to open their=20= IGP to an ALTO server. Also, IGP requires direct connectivity=20 (adjacency) so from an operation point of view is complex and not=20 desired. 2. Use a database distribution protocol running on top of a reliable=20 transport layer that would allow an ALTO server to connect to a=20 _single_ and _remote_ Route Reflector (i.e.: no need to be directly=20= connected) and grab the whole network topology that will be updated=20= using standard routing protocol mechanisms (i.e.: routing updates) and that would allow the operator to control (through policies and=20 filters) what to distribute and to which server. Benefits: single (or dual at most for redundancy) connection for=20 the ALTO server (rather than having a direct adjacency with each=20 ABR) and, from the operator perspective, single point of=20 distribution of network topology (easier to apply policies and=20 control what you deliver). This is what BGP-LS is about.=20 BGP-LS defines new AFI/SAFI for a new NLRI and attributes that convey=20 link-state and, more generically, any type of topology information.=20 The draft specifies NLRI and attributes that map whatever you can=20 find in a link-state database. We currently have draft-gredler-idr-ls-distribution in the process=20 (hopefully) to be adopted as WG item in IDR WG (so far we 're getting=20 good support). We also have 3 implementations of BGP-LS. Deployment-wise: BGP-LS is not yet deployed, however, we already have=20 deployments (I know at least two) where an ALTO server retrieves IP=20 prefix information from remote BGP RRs (for ipv4). The same scheme=20 will be used once BGP-LS will be deployed (so to say that it is not=20 something that we invented after a couple of beers but corresponds to=20 requirements for delivering network services to upper layers while=20 still controlling efficiently what you distribute, to whom and in=20 which form (note that, often, beers are anyway part of the process). More information here: http://tools.ietf.org/html/draft-gredler-idr-ls-distribution-02 http://tools.ietf.org/html/draft-ietf-alto-protocol-12 Hope this helps. s. On Aug 3, 2012, at 1:29 AM, Robert Raszuk wrote: > Tom, >=20 > > I agree that one of the top work items for this effort should be a > > standardized topology function, and one that is accessible via a > > non-routing protocol. >=20 > So if the requirement is to have topology export via non-routing = protocol then I think we should seriously revisit or repackage the = draft-gredler-idr-ls-distribution-01 which works for for both OSPF and = ISIS. >=20 > However before that let's really understand the requirement why it = must be exported via non-routing protocol .... Keep in mind that just to = parse BGP UPDATE messages and retrieve interesting pieces out it it = requires very little code rather then full BGP implementation. >=20 > The particular feature I like about = draft-gredler-idr-ls-distribution-01 is that it is read-only ;) >=20 > R. >=20 >>=20 >> I agree that one of the top work items for this effort should be = a >> standardized topology function, and one that is accessible via a >> non-routing protocol. While not exactly "low hanging fruit", it is >> something that (to me) is a clear work item with clear goals that = should >> be tackled straight away. >>=20 >> --Tom >>=20 >>=20 >>=20 >> On 8/2/12 3:24 PM, "James Kempf" wrote: >>=20 >>> So after seeing part of Alia's talk this morning (I had to leave in = the >>> middle unfortunately), I'd like to make a couple suggestions. There = were >>> a lot of ideas presented in the talk, enough for an entire IETF = Area. I >>> think to make tangible progress, the work needs to be focussed on a = small >>> subset that would be of immediate interest and usability. >>>=20 >>> There are a couple areas that suggest themselves, but one that would = be >>> useful in work that I've been involved in is a standardized format = for >>> network topology representation and a protocol for exchanging it. = The >>> Onix OpenFlow controller has a network information base with a >>> specialized format for network topology, and every OpenFlow = controller >>> requires this. Having a standardized way to represent it might = foster a >>> common topology database package. Another application is network >>> management. Every network management system needs some kind of = topology >>> representation. Finally, though I am not an expert in PCE = construction, >>> it would seem to me that a PCE would need some kind of topology >>> representation in order to perform path calculations. Having a = way,for >>> example, for the OpenFlow controller and the PCE to exchange = topology >>> information would be really useful. I would say to start with = physical >>> topology because that is fundamental, but make the format flexible = enough >>> to support >>> virtual topology representation. >>>=20 >>> jak >>> _______________________________________________ >>> irs-discuss mailing list >>> irs-discuss@ietf.org >>> https://www.ietf.org/mailman/listinfo/irs-discuss >>=20 >> _______________________________________________ >> irs-discuss mailing list >> irs-discuss@ietf.org >> https://www.ietf.org/mailman/listinfo/irs-discuss >>=20 >>=20 >=20 > _______________________________________________ > irs-discuss mailing list > irs-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/irs-discuss >=20 Return-Path: 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 DCFB311E80B8 for ; Thu, 2 Aug 2012 22:33:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.299 X-Spam-Level: X-Spam-Status: No, score=-10.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pFXVk9QqNDPU for ; Thu, 2 Aug 2012 22:33:51 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 1FB4A11E809C for ; Thu, 2 Aug 2012 22:33:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jmedved@cisco.com; l=1946; q=dns/txt; s=iport; t=1343972031; x=1345181631; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=YVFSK8zcogvz2r7wzpJlfvKNpg4QL/WwmfBWthbz8NQ=; b=b7/FR6Yca26ejenci5QZxi3mkBN7IY1RuhM6W8i/X2d0jq3GGj/Lk5K5 1UaDQIw9Tp8stOIqP0Dv3cFYpmchIDWLwYq/4wEqpgQ4QJQBmQYWLIrL6 TR4LuzE9JT7MMLnP8ckk9TczDeGYnlrp0V5dD1mlt1LJY2kFNHRKZK/fs k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAL5hG1CtJXHB/2dsb2JhbABFuSaBB4IgAQEBAwESAScyCgMSAQgOCh5CJQEBBAENBSKFb4F2Bp0QoDaSSwOVSI4ngWaCX4Ff X-IronPort-AV: E=Sophos;i="4.77,705,1336348800"; d="scan'208";a="108096833" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-8.cisco.com with ESMTP; 03 Aug 2012 05:33:50 +0000 Received: from xhc-rcd-x08.cisco.com (xhc-rcd-x08.cisco.com [173.37.183.82]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id q735XoSw006026 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 3 Aug 2012 05:33:50 GMT Received: from xmb-aln-x10.cisco.com ([169.254.5.159]) by xhc-rcd-x08.cisco.com ([173.37.183.82]) with mapi id 14.02.0298.004; Fri, 3 Aug 2012 00:33:49 -0500 From: "Jan Medved (jmedved)" To: Thomas Nadeau , "robert@raszuk.net" Thread-Topic: [irs-discuss] Suggestions for IRS Way Forward Thread-Index: Ac1w/aRFxquJYy0LSJCFfpb4MILlegAKtm6AAAIJPoAAAHJKAP//7L0A Date: Fri, 3 Aug 2012 05:33:49 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 x-originating-ip: [10.27.7.163] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19082.002 x-tm-as-result: No--28.978300-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: James Kempf , "irs-discuss@ietf.org" Subject: Re: [irs-discuss] Suggestions for IRS Way Forward X-BeenThere: irs-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Aug 2012 05:33:52 -0000 Tom, On 8/2/12 4:42 PM, "Thomas Nadeau" wrote: > > >On 8/2/12 4:29 PM, "Robert Raszuk" wrote: > >>Tom, >> >> > I agree that one of the top work items for this effort should be a >> > standardized topology function, and one that is accessible via a >> > non-routing protocol. >> >>So if the requirement is to have topology export via non-routing >>protocol then I think we should seriously revisit or repackage the >>draft-gredler-idr-ls-distribution-01 which works for for both OSPF and >>ISIS. > > Cool. > > >>However before that let's really understand the requirement why it must >>be exported via non-routing protocol .... Keep in mind that just to >>parse BGP UPDATE messages and retrieve interesting pieces out it it >>requires very little code rather then full BGP implementation. Agreed. > > That seemed to be one of the agreements that came out of the session >today. Can you give more background? I don't think it's as straightforward. BGP-LS implements a network-wide model (data schema), while the scope of IRS is a single node (IMO as it should be). A node's local IGP and BGP databases do not provide the view of the entire network topology. To get the whole topology, multiple routers need to be queried, and the topology needs to be 'stitched' together. This can either be done in an external node (an ALTO Server, for example), or in a router. If the 'stitching' is done in an external server, would it mean that the scope of IRS is extended to entities other than routers? If the 'stitching' is done at a router, then the router would have to collect the topology data from other routers - using BGP-LS, for example ;-) The topology export would then basically have to provide access to the BGP-LS database through some adaptation function. I wonder what's the gain in this case... =20 > > --Tom > Thanks, Jan > >> Return-Path: 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 621C511E80E8 for ; Thu, 2 Aug 2012 21:11:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.999 X-Spam-Level: X-Spam-Status: No, score=-9.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Czq8Cz57v4Lw for ; Thu, 2 Aug 2012 21:11:16 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 57E0911E80B8 for ; Thu, 2 Aug 2012 21:11:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jmedved@cisco.com; l=7021; q=dns/txt; s=iport; t=1343967076; x=1345176676; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=9akfyrEkfxeeu1fpL1gupQVp0zHyPojfsWVp6Rjjxi4=; b=FU8FzVkf82PK4ya0oQly+TpkelgEDawo9xzOwLaWhLqnHxbTMQiCEczT oLtjBR76DK2CnkzRLWVgRXoPcdm+k8cJBmWEM/n8Go5Beoj+E0/n6UnK5 HRiKPh4QTCscG7VEGJsbfi/g6TqFBnAD1NKauXlFEQbk/8uHYm9V9Bv6y Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAL9OG1CtJXG//2dsb2JhbABFuSeBB4IgAQEBBAEBAQ8BJzEDCwwGAQgRBAEBHwkuCxQJCAEBBAENBRsHh2sLnQOgO4tHhwQDlUiBFI0TgWaCXw X-IronPort-AV: E=Sophos;i="4.77,704,1336348800"; d="scan'208";a="108083076" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-8.cisco.com with ESMTP; 03 Aug 2012 04:11:15 +0000 Received: from xhc-rcd-x03.cisco.com (xhc-rcd-x03.cisco.com [173.37.183.77]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id q734BFwo003460 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 3 Aug 2012 04:11:15 GMT Received: from xmb-aln-x10.cisco.com ([169.254.5.159]) by xhc-rcd-x03.cisco.com ([173.37.183.77]) with mapi id 14.02.0298.004; Thu, 2 Aug 2012 23:11:15 -0500 From: "Jan Medved (jmedved)" To: Susan Hares , James Kempf , "robert@raszuk.net" Thread-Topic: [irs-discuss] Suggestions for IRS Way Forward Thread-Index: Ac1w/aRFxquJYy0LSJCFfpb4MILlegAMbbeAAABTTAAAAM9GgAAC4oGA//+7pIA= Date: Fri, 3 Aug 2012 04:11:14 +0000 Message-ID: In-Reply-To: <728F9B956B2C48439CA9294B1723B14623755FD2@dfweml509-mbs.china.huawei.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 x-originating-ip: [10.27.7.163] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19078.004 x-tm-as-result: No--33.493700-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "irs-discuss@ietf.org" Subject: Re: [irs-discuss] Suggestions for IRS Way Forward X-BeenThere: irs-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Aug 2012 04:11:21 -0000 Sue, On 8/2/12 6:15 PM, "Susan Hares" wrote: >James: > >BGP and ISIS may have overkill - or it may be just right. Realize - this >information does not come for free. Agreed.=20 It costs to extract the topology information from the router, and it costs to process it a the client. A routing protocol is a good low cost interface to get topology data out of a router, since routing is one of the things that routers are optimized for. Now, if a client does not want to listen to BGP Updates (which is not that difficult to implement, as Robert pointed out), we can have an intermediary, such an ALTO Server, which will receive routing protocol updates and provide the topology to clients in an easier-to-digest format. > >You are running BGP sessions across the network passing this information. >All of the routers must be configured and instrumented separately from >the regular BGP. ISIS uploaded into these BGP sessions and distributed. Not necessarily. In a single-area IGP, a single BGP-LS speaker listening to IGP updates can retrieve the IGP topology for the whole network. Other BGP Speakers in the network do not need to be BGP-LS enabled at all. If we want to retrieve a complete topology of a multi-area IGP network, there must be an IGP listener in each IGP area. If a client wants to use BGP-LS to retrieve the IGP topology from the network, it can set up a BGP-LS session to each of the IGP listeners (in each area). Alternatively, we can use a Route Reflector to collect the topology data from all BGP-LS Speakers; then, the client only needs to establish a single session to the Route Reflector. Also, the Route Reflector can service multiple clients. Note that in this case there too is only a small set of routers than need to be BGP-LS enabled. Basically, we leverage existing BGP mechanisms to collect the topology data from the entire network. We can leverage an existing Route Reflector, or we can dedicate a Route Reflector just for BGP-LS. Talking to multiple operators, they prefer the latter option. > >Please ask the authors about the details of their implementations. Sure, if more details are required, we'll be glad to discuss :-) > >Sue=20 > Thanks, Jan > >-----Original Message----- >From: James Kempf [mailto:james.kempf@ericsson.com] >Sent: Thursday, August 02, 2012 4:53 PM >To: Susan Hares; robert@raszuk.net >Cc: irs-discuss@ietf.org >Subject: RE: [irs-discuss] Suggestions for IRS Way Forward > >I'll have to take a look at draft-grendler, I am not familiar with it. > >The particular use cases I'm interested in are NMS and OpenFlow >controller type applications where some centralized entity wants >information on the topology for managing the elements in a way that >allows policies to be expressed over the network as a whole and >translated into specific element management polices by the controller/NMS >system. The topology data base must be populated somehow, obviously, but >I assume that would be part of the work (perhaps draft-grendler describes >this). The physical topology won't be exported outside an operator's >domain since managing the physical infrastructure is under the purview of >the operator. If the topology database supports expressing virtual >topologies (which I believe it should) the operator could expose virtual >topologies to the customers of the virtual networks, and allow them the >ability to manage their virtual slices. > >Make sense? > > jak =20 > >> -----Original Message----- >> From: Susan Hares [mailto:susan.hares@huawei.com] >> Sent: Thursday, August 02, 2012 4:30 PM >> To: robert@raszuk.net; James Kempf >> Cc: irs-discuss@ietf.org >> Subject: RE: [irs-discuss] Suggestions for IRS Way Forward >>=20 >> James: >>=20 >> This is the full detailed routes. However, will every ISP >> share it's ISIS topology. >>=20 >> Sue=20 >>=20 >> -----Original Message----- >> From: irs-discuss-bounces@ietf.org >> [mailto:irs-discuss-bounces@ietf.org] On Behalf Of Robert Raszuk >> Sent: Thursday, August 02, 2012 4:21 PM >> To: James Kempf >> Cc: irs-discuss@ietf.org >> Subject: Re: [irs-discuss] Suggestions for IRS Way Forward >>=20 >> Hi James, >>=20 >> On the topic of topology export it is my understanding that >> we do already have a solution which in fact even authors of >> IRS framework support and are putting under their umbrella. >>=20 >> That is:=20 >> http://tools.ietf.org/html/draft-gredler-idr-ls-distribution-01 >>=20 >> The draft as standards track document defines the topology >> export standard in form of link and node NLRIs with bunch of TLVs. >>=20 >> So the key aspect would be to see what is missing and if >> something is missing in the space of topology export to >> evaluate if this solution by principle can be extended to >> accommodate it. >>=20 >> Best, >> R. >>=20 >>=20 >> > So after seeing part of Alia's talk this morning (I had to leave in >> > the middle unfortunately), I'd like to make a couple suggestions. >> > There were a lot of ideas presented in the talk, enough for >> an entire=20 >> > IETF Area. I think to make tangible progress, the work needs to be >> > focussed on a small subset that would be of immediate interest and >> > usability. >> > >> > There are a couple areas that suggest themselves, but one >> that would=20 >> > be useful in work that I've been involved in is a >> standardized format >> > for network topology representation and a protocol for >> exchanging it. >> > The Onix OpenFlow controller has a network information base with a >> > specialized format for network topology, and every OpenFlow >> controller=20 >> > requires this. Having a standardized way to represent it >> might foster=20 >> > a common topology database package. Another application is network >> > management. Every network management system needs some kind of >> > topology representation. Finally, though I am not an expert in PCE >> > construction, it would seem to me that a PCE would need >> some kind of=20 >> > topology representation in order to perform path >> calculations. Having >> > a way,for example, for the OpenFlow controller and the PCE >> to exchange=20 >> > topology information would be really useful. >> > I would say to start with physical topology because that is >> > fundamental, but make the format flexible enough to support virtual >> > topology representation. >> > >> > jak _______________________________________________ irs-discuss >> > mailing list irs-discuss@ietf.org >> > https://www.ietf.org/mailman/listinfo/irs-discuss >> > >> > >>=20 >> _______________________________________________ >> irs-discuss mailing list >> irs-discuss@ietf.org >> https://www.ietf.org/mailman/listinfo/irs-discuss >>=20 >_______________________________________________ >irs-discuss mailing list >irs-discuss@ietf.org >https://www.ietf.org/mailman/listinfo/irs-discuss Return-Path: 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 7525811E80A6 for ; Thu, 2 Aug 2012 18:17:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.772 X-Spam-Level: X-Spam-Status: No, score=-4.772 tagged_above=-999 required=5 tests=[AWL=1.227, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t0l-cZFiHnQh for ; Thu, 2 Aug 2012 18:17:49 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 34C9D11E8072 for ; Thu, 2 Aug 2012 18:17:49 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml202-edg.china.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AIQ44300; Thu, 02 Aug 2012 17:17:44 -0800 (PST) Received: from DFWEML404-HUB.china.huawei.com (10.193.5.203) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 2 Aug 2012 18:16:00 -0700 Received: from dfweml509-mbs.china.huawei.com ([169.254.12.123]) by dfweml404-hub.china.huawei.com ([10.193.5.203]) with mapi id 14.01.0323.003; Thu, 2 Aug 2012 18:15:54 -0700 From: Susan Hares To: James Kempf , "robert@raszuk.net" Thread-Topic: [irs-discuss] Suggestions for IRS Way Forward Thread-Index: Ac1w/aRFxquJYy0LSJCFfpb4MILlegAQnpmAAA6KuUAAHGUKYAA4c07g Date: Fri, 3 Aug 2012 01:15:53 +0000 Message-ID: <728F9B956B2C48439CA9294B1723B14623755FD2@dfweml509-mbs.china.huawei.com> References: <501B0B4F.7020609@raszuk.net> <728F9B956B2C48439CA9294B1723B14623755E64@dfweml509-mbs.china.huawei.com> In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.212.245.215] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "irs-discuss@ietf.org" Subject: Re: [irs-discuss] Suggestions for IRS Way Forward X-BeenThere: irs-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Aug 2012 01:17:50 -0000 James: BGP and ISIS may have overkill - or it may be just right. Realize - this i= nformation does not come for free.=20 You are running BGP sessions across the network passing this information. A= ll of the routers must be configured and instrumented separately from the r= egular BGP. ISIS uploaded into these BGP sessions and distributed. =20 Please ask the authors about the details of their implementations.=20 Sue=20 -----Original Message----- From: James Kempf [mailto:james.kempf@ericsson.com]=20 Sent: Thursday, August 02, 2012 4:53 PM To: Susan Hares; robert@raszuk.net Cc: irs-discuss@ietf.org Subject: RE: [irs-discuss] Suggestions for IRS Way Forward I'll have to take a look at draft-grendler, I am not familiar with it. The particular use cases I'm interested in are NMS and OpenFlow controller = type applications where some centralized entity wants information on the to= pology for managing the elements in a way that allows policies to be expres= sed over the network as a whole and translated into specific element manage= ment polices by the controller/NMS system. The topology data base must be p= opulated somehow, obviously, but I assume that would be part of the work (p= erhaps draft-grendler describes this). The physical topology won't be expor= ted outside an operator's domain since managing the physical infrastructure= is under the purview of the operator. If the topology database supports ex= pressing virtual topologies (which I believe it should) the operator could = expose virtual topologies to the customers of the virtual networks, and all= ow them the ability to manage their virtual slices. Make sense? jak =20 > -----Original Message----- > From: Susan Hares [mailto:susan.hares@huawei.com]=20 > Sent: Thursday, August 02, 2012 4:30 PM > To: robert@raszuk.net; James Kempf > Cc: irs-discuss@ietf.org > Subject: RE: [irs-discuss] Suggestions for IRS Way Forward >=20 > James: >=20 > This is the full detailed routes. However, will every ISP=20 > share it's ISIS topology. >=20 > Sue=20 >=20 > -----Original Message----- > From: irs-discuss-bounces@ietf.org=20 > [mailto:irs-discuss-bounces@ietf.org] On Behalf Of Robert Raszuk > Sent: Thursday, August 02, 2012 4:21 PM > To: James Kempf > Cc: irs-discuss@ietf.org > Subject: Re: [irs-discuss] Suggestions for IRS Way Forward >=20 > Hi James, >=20 > On the topic of topology export it is my understanding that=20 > we do already have a solution which in fact even authors of=20 > IRS framework support and are putting under their umbrella. >=20 > That is:=20 > http://tools.ietf.org/html/draft-gredler-idr-ls-distribution-01 >=20 > The draft as standards track document defines the topology=20 > export standard in form of link and node NLRIs with bunch of TLVs. >=20 > So the key aspect would be to see what is missing and if=20 > something is missing in the space of topology export to=20 > evaluate if this solution by principle can be extended to=20 > accommodate it. >=20 > Best, > R. >=20 >=20 > > So after seeing part of Alia's talk this morning (I had to leave in=20 > > the middle unfortunately), I'd like to make a couple suggestions. > > There were a lot of ideas presented in the talk, enough for=20 > an entire=20 > > IETF Area. I think to make tangible progress, the work needs to be=20 > > focussed on a small subset that would be of immediate interest and=20 > > usability. > > > > There are a couple areas that suggest themselves, but one=20 > that would=20 > > be useful in work that I've been involved in is a=20 > standardized format=20 > > for network topology representation and a protocol for=20 > exchanging it. > > The Onix OpenFlow controller has a network information base with a=20 > > specialized format for network topology, and every OpenFlow=20 > controller=20 > > requires this. Having a standardized way to represent it=20 > might foster=20 > > a common topology database package. Another application is network=20 > > management. Every network management system needs some kind of=20 > > topology representation. Finally, though I am not an expert in PCE=20 > > construction, it would seem to me that a PCE would need=20 > some kind of=20 > > topology representation in order to perform path=20 > calculations. Having=20 > > a way,for example, for the OpenFlow controller and the PCE=20 > to exchange=20 > > topology information would be really useful. > > I would say to start with physical topology because that is=20 > > fundamental, but make the format flexible enough to support virtual=20 > > topology representation. > > > > jak _______________________________________________ irs-discuss=20 > > mailing list irs-discuss@ietf.org=20 > > https://www.ietf.org/mailman/listinfo/irs-discuss > > > > >=20 > _______________________________________________ > irs-discuss mailing list > irs-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/irs-discuss >=20 Return-Path: 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 DE10C11E8125 for ; Thu, 2 Aug 2012 17:02:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.313 X-Spam-Level: X-Spam-Status: No, score=-2.313 tagged_above=-999 required=5 tests=[AWL=0.286, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ipYigKR2C7ox for ; Thu, 2 Aug 2012 17:02:21 -0700 (PDT) Received: from mail1310.opentransfer.com (mail1310.opentransfer.com [76.162.254.103]) by ietfa.amsl.com (Postfix) with ESMTP id 3162511E8120 for ; Thu, 2 Aug 2012 17:02:21 -0700 (PDT) Received: (qmail 11559 invoked by uid 399); 3 Aug 2012 00:02:20 -0000 Received: from unknown (HELO ?130.129.17.10?) (pbs:robert@raszuk.net@130.129.17.10) by mail1310.opentransfer.com with ESMTPM; 3 Aug 2012 00:02:20 -0000 X-Originating-IP: 130.129.17.10 Message-ID: <501B150C.9080304@raszuk.net> Date: Fri, 03 Aug 2012 02:02:20 +0200 From: Robert Raszuk User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: "irs-discuss@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [irs-discuss] An idea ... MTR + IRS X-BeenThere: irs-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: robert@raszuk.net List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Aug 2012 00:02:22 -0000 Hi, This morning Scott mentioned that he would like to use IRS to shut down all protocols and just be able to write to RIB. Now James said that he would like to get a network topology as "every OpenFlow controller requires this" Both connected together resulted in an idea of using multi-topology-routing where your base topology discovers physical link connectivity graph while other topologies could be programmed by external entities example: OF controllers or any other external to routers network intelligence oracles to deliver actual services ? Would that be in scope of IRS effort ? If so what would be the proposed "write to RIB" set of protocols ? Would you support OF 1.3 even if one would be happy to lock such topologies only to software/programmable switching paths ? Best rgs, R. Return-Path: 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 04DBD11E8129 for ; Thu, 2 Aug 2012 16:53:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.931 X-Spam-Level: X-Spam-Status: No, score=-5.931 tagged_above=-999 required=5 tests=[AWL=0.068, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vr+2IlTQusAQ for ; Thu, 2 Aug 2012 16:53:27 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id 347F111E8087 for ; Thu, 2 Aug 2012 16:53:27 -0700 (PDT) Received: from eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id q72NrNVK031666; Thu, 2 Aug 2012 18:53:24 -0500 Received: from EUSAACMS0703.eamcs.ericsson.se ([169.254.1.135]) by eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) with mapi; Thu, 2 Aug 2012 19:53:18 -0400 From: James Kempf To: Susan Hares , "robert@raszuk.net" Date: Thu, 2 Aug 2012 19:53:17 -0400 Thread-Topic: [irs-discuss] Suggestions for IRS Way Forward Thread-Index: Ac1w/aRFxquJYy0LSJCFfpb4MILlegAQnpmAAA6KuUAAHGUKYA== Message-ID: References: <501B0B4F.7020609@raszuk.net> <728F9B956B2C48439CA9294B1723B14623755E64@dfweml509-mbs.china.huawei.com> In-Reply-To: <728F9B956B2C48439CA9294B1723B14623755E64@dfweml509-mbs.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "irs-discuss@ietf.org" Subject: Re: [irs-discuss] Suggestions for IRS Way Forward X-BeenThere: irs-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2012 23:53:28 -0000 I'll have to take a look at draft-grendler, I am not familiar with it. The particular use cases I'm interested in are NMS and OpenFlow controller = type applications where some centralized entity wants information on the to= pology for managing the elements in a way that allows policies to be expres= sed over the network as a whole and translated into specific element manage= ment polices by the controller/NMS system. The topology data base must be p= opulated somehow, obviously, but I assume that would be part of the work (p= erhaps draft-grendler describes this). The physical topology won't be expor= ted outside an operator's domain since managing the physical infrastructure= is under the purview of the operator. If the topology database supports ex= pressing virtual topologies (which I believe it should) the operator could = expose virtual topologies to the customers of the virtual networks, and all= ow them the ability to manage their virtual slices. Make sense? jak =20 > -----Original Message----- > From: Susan Hares [mailto:susan.hares@huawei.com]=20 > Sent: Thursday, August 02, 2012 4:30 PM > To: robert@raszuk.net; James Kempf > Cc: irs-discuss@ietf.org > Subject: RE: [irs-discuss] Suggestions for IRS Way Forward >=20 > James: >=20 > This is the full detailed routes. However, will every ISP=20 > share it's ISIS topology. >=20 > Sue=20 >=20 > -----Original Message----- > From: irs-discuss-bounces@ietf.org=20 > [mailto:irs-discuss-bounces@ietf.org] On Behalf Of Robert Raszuk > Sent: Thursday, August 02, 2012 4:21 PM > To: James Kempf > Cc: irs-discuss@ietf.org > Subject: Re: [irs-discuss] Suggestions for IRS Way Forward >=20 > Hi James, >=20 > On the topic of topology export it is my understanding that=20 > we do already have a solution which in fact even authors of=20 > IRS framework support and are putting under their umbrella. >=20 > That is:=20 > http://tools.ietf.org/html/draft-gredler-idr-ls-distribution-01 >=20 > The draft as standards track document defines the topology=20 > export standard in form of link and node NLRIs with bunch of TLVs. >=20 > So the key aspect would be to see what is missing and if=20 > something is missing in the space of topology export to=20 > evaluate if this solution by principle can be extended to=20 > accommodate it. >=20 > Best, > R. >=20 >=20 > > So after seeing part of Alia's talk this morning (I had to leave in=20 > > the middle unfortunately), I'd like to make a couple suggestions. > > There were a lot of ideas presented in the talk, enough for=20 > an entire=20 > > IETF Area. I think to make tangible progress, the work needs to be=20 > > focussed on a small subset that would be of immediate interest and=20 > > usability. > > > > There are a couple areas that suggest themselves, but one=20 > that would=20 > > be useful in work that I've been involved in is a=20 > standardized format=20 > > for network topology representation and a protocol for=20 > exchanging it. > > The Onix OpenFlow controller has a network information base with a=20 > > specialized format for network topology, and every OpenFlow=20 > controller=20 > > requires this. Having a standardized way to represent it=20 > might foster=20 > > a common topology database package. Another application is network=20 > > management. Every network management system needs some kind of=20 > > topology representation. Finally, though I am not an expert in PCE=20 > > construction, it would seem to me that a PCE would need=20 > some kind of=20 > > topology representation in order to perform path=20 > calculations. Having=20 > > a way,for example, for the OpenFlow controller and the PCE=20 > to exchange=20 > > topology information would be really useful. > > I would say to start with physical topology because that is=20 > > fundamental, but make the format flexible enough to support virtual=20 > > topology representation. > > > > jak _______________________________________________ irs-discuss=20 > > mailing list irs-discuss@ietf.org=20 > > https://www.ietf.org/mailman/listinfo/irs-discuss > > > > >=20 > _______________________________________________ > irs-discuss mailing list > irs-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/irs-discuss > = Return-Path: 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 224B521E8044 for ; Thu, 2 Aug 2012 16:43:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.136 X-Spam-Level: X-Spam-Status: No, score=-6.136 tagged_above=-999 required=5 tests=[AWL=-0.137, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CPJlrB+1fTYq for ; Thu, 2 Aug 2012 16:43:47 -0700 (PDT) Received: from exprod7og110.obsmtp.com (exprod7og110.obsmtp.com [64.18.2.173]) by ietfa.amsl.com (Postfix) with ESMTP id 2DB0821E8039 for ; Thu, 2 Aug 2012 16:43:44 -0700 (PDT) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob110.postini.com ([64.18.6.12]) with SMTP ID DSNKUBsQr5E1a3WOR1F/HZISqAXA+/cspWCh@postini.com; Thu, 02 Aug 2012 16:43:47 PDT Received: from p-emfe01-wf.jnpr.net (172.28.145.24) by P-EMHUB03-HQ.jnpr.net (172.24.192.37) with Microsoft SMTP Server (TLS) id 8.3.213.0; Thu, 2 Aug 2012 16:42:48 -0700 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe01-wf.jnpr.net ([fe80::d0d1:653d:5b91:a123%11]) with mapi; Thu, 2 Aug 2012 19:42:47 -0400 From: Thomas Nadeau To: "robert@raszuk.net" Date: Thu, 2 Aug 2012 19:42:44 -0400 Thread-Topic: [irs-discuss] Suggestions for IRS Way Forward Thread-Index: Ac1xCISzxvl/7EpdQQK61LY8mq628g== Message-ID: In-Reply-To: <501B0D75.4090009@raszuk.net> 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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: James Kempf , "irs-discuss@ietf.org" Subject: Re: [irs-discuss] Suggestions for IRS Way Forward X-BeenThere: irs-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2012 23:43:48 -0000 On 8/2/12 4:29 PM, "Robert Raszuk" wrote: >Tom, > > > I agree that one of the top work items for this effort should be a > > standardized topology function, and one that is accessible via a > > non-routing protocol. > >So if the requirement is to have topology export via non-routing >protocol then I think we should seriously revisit or repackage the >draft-gredler-idr-ls-distribution-01 which works for for both OSPF and >ISIS. Cool. >However before that let's really understand the requirement why it must >be exported via non-routing protocol .... Keep in mind that just to >parse BGP UPDATE messages and retrieve interesting pieces out it it >requires very little code rather then full BGP implementation. That seemed to be one of the agreements that came out of the session today. --Tom > >The particular feature I like about draft-gredler-idr-ls-distribution-01 >is that it is read-only ;) > >R. > >> >> I agree that one of the top work items for this effort should be a >> standardized topology function, and one that is accessible via a >> non-routing protocol. While not exactly "low hanging fruit", it is >> something that (to me) is a clear work item with clear goals that should >> be tackled straight away. >> >> --Tom >> >> >> >> On 8/2/12 3:24 PM, "James Kempf" wrote: >> >>> So after seeing part of Alia's talk this morning (I had to leave in the >>> middle unfortunately), I'd like to make a couple suggestions. There >>>were >>> a lot of ideas presented in the talk, enough for an entire IETF Area. I >>> think to make tangible progress, the work needs to be focussed on a >>>small >>> subset that would be of immediate interest and usability. >>> >>> There are a couple areas that suggest themselves, but one that would be >>> useful in work that I've been involved in is a standardized format for >>> network topology representation and a protocol for exchanging it. The >>> Onix OpenFlow controller has a network information base with a >>> specialized format for network topology, and every OpenFlow controller >>> requires this. Having a standardized way to represent it might foster a >>> common topology database package. Another application is network >>> management. Every network management system needs some kind of topology >>> representation. Finally, though I am not an expert in PCE construction, >>> it would seem to me that a PCE would need some kind of topology >>> representation in order to perform path calculations. Having a way,for >>> example, for the OpenFlow controller and the PCE to exchange topology >>> information would be really useful. I would say to start with physical >>> topology because that is fundamental, but make the format flexible >>>enough >>> to support >>> virtual topology representation. >>> >>> jak >>> _______________________________________________ >>> 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 >> >> > Return-Path: 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 262BF21E804D for ; Thu, 2 Aug 2012 16:41:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.003 X-Spam-Level: X-Spam-Status: No, score=-5.003 tagged_above=-999 required=5 tests=[AWL=1.595, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KLJfvID7RUsG for ; Thu, 2 Aug 2012 16:41:07 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id EB13621E8047 for ; Thu, 2 Aug 2012 16:41:06 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml201-edg.china.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AIQ40181; Thu, 02 Aug 2012 15:41:06 -0800 (PST) Received: from DFWEML404-HUB.china.huawei.com (10.193.5.203) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 2 Aug 2012 16:39:00 -0700 Received: from dfweml509-mbs.china.huawei.com ([169.254.12.123]) by dfweml404-hub.china.huawei.com ([10.193.5.203]) with mapi id 14.01.0323.003; Thu, 2 Aug 2012 16:39:01 -0700 From: Susan Hares To: Ping Pan , Pedro Roque Marques Thread-Topic: [irs-discuss] if-map example Thread-Index: AQHNcNnIiF79ROak+U+G1tfOU3wVPpdHgGuAgAAMzQCAAASdgP//nBDQ Date: Thu, 2 Aug 2012 23:39:01 +0000 Message-ID: <728F9B956B2C48439CA9294B1723B14623755EAF@dfweml509-mbs.china.huawei.com> References: <632FAE8B-8CC5-4701-BB42-1C4EACE372D5@gmail.com> <443803C3-E36B-48C1-947D-8AEB19BE94C1@gmail.com> In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.212.245.215] Content-Type: multipart/alternative; boundary="_000_728F9B956B2C48439CA9294B1723B14623755EAFdfweml509mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "irs-discuss@ietf.org" Subject: Re: [irs-discuss] if-map example X-BeenThere: irs-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2012 23:41:08 -0000 --_000_728F9B956B2C48439CA9294B1723B14623755EAFdfweml509mbschi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 UGluZyBhbmQgcGVkcm86DQoNCldoYXTigJlzIG5pY2UgaGVyZSBpcyB0aGlzIGlzIGFuIGludGVy ZXN0aW5nIHByb3Zpc2lvbmluZyBzY2hlbWEuICBEaWQgeW91IGhhdmUgcHJvZHVjdGlvbiBjb2Rl IG9yIHJvdWdoIGNvZGUgdGhhdCB5b3UgdHJpZWQgdGhpcyB3aXRoPw0KDQpTdWUNCg0KRnJvbTog aXJzLWRpc2N1c3MtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOmlycy1kaXNjdXNzLWJvdW5jZXNA aWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBQaW5nIFBhbg0KU2VudDogVGh1cnNkYXksIEF1Z3VzdCAw MiwgMjAxMiAzOjM1IFBNDQpUbzogUGVkcm8gUm9xdWUgTWFycXVlcw0KQ2M6IGlycy1kaXNjdXNz QGlldGYub3JnDQpTdWJqZWN0OiBSZTogW2lycy1kaXNjdXNzXSBpZi1tYXAgZXhhbXBsZQ0KDQpB bmQgdGhpcyBjYW4gYmUgZXh0ZW5kZWQgdG8gYXBwbHkgbW9yZSB0aGFuIEwzVlBOLi4uDQpPbiBU aHUsIEF1ZyAyLCAyMDEyIGF0IDM6MTggUE0sIFBlZHJvIFJvcXVlIE1hcnF1ZXMgPHBlZHJvLnIu bWFycXVlc0BnbWFpbC5jb208bWFpbHRvOnBlZHJvLnIubWFycXVlc0BnbWFpbC5jb20+PiB3cm90 ZToNCkFzIGFuIGFkZGl0aW9uYWwgZXhhbXBsZSwgdGhlIGZvbGxvd2luZyBkb2N1bWVudCBkZXNj cmliZXMgYSBzY2hlbWEgdGhhdCBjYW4gYmUgdXNlZCB0byBwcm92aXNpb24gYSBWUE4gKHdoaWNo IGlzIGltcGxlbWVudGVkIGJ5IG1hbnkgUEVzIGFzIGluZGl2aWR1YWwgVlJGcykuDQpodHRwOi8v ZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LW1hcnF1ZXMtbDN2cG4tc2NoZW1hDQoNClRo ZSBkb2N1bWVudCBpcyBzdGlsbCBpbiBpdHMgZWFybHkgc3RhZ2VzLg0KDQpUaGUgcHJvYmxlbXMg dGhhdCBjYW4gYmUgc29sdmVkIGJ5IHN1Y2ggYSBzY2hlbWEgaXMgdG8gYmUgYWJsZSB0bywgZm9y IGluc3RhbmNlOg0KMSkgUXVlcnkgdGhlIE1BUCBkYXRhYmFzZSBmb3IgYWxsIFBFcyB3aGVyZSBh IHNwZWNpZmljIFZQTiBpcyBwcmVzZW50Lg0KMikgRW5zdXJlIHRoYXQgdGhlIFZSRnMgYXNzb2Np YXRlZCB3aXRoIGEgc3BlY2lmaWMgVlBOIGNvbnNpc3RlbnRseSBpbXBsZW1lbnQgdGhlIHNhbWUg cG9saWN5Lg0KDQpUaGVzZSBhcmUgYm90aCBleGFtcGxlcyBvZiBmdW5jdGlvbmFsaXR5IHRoYXQg c3BhbnMgdGhlIG5ldHdvcmsgcmF0aGVyIHRoYW4gYmUgbG9jYWxpemVkIHRvIGEgc3BlY2lmaWMg cm91dGVyL3N3aXRjaC9hcHBsaWFuY2UuDQoNCg0KT24gQXVnIDIsIDIwMTIsIGF0IDI6MzIgUE0s IFBpbmcgUGFuIHdyb3RlOg0KDQoNCkFmdGVyIHBsYXlpbmcgYXJvdW5kIHdpdGggYSBidW5jaCBv ZiBvdGhlciBzY2hlbWVzLCB0aGlzIGluZGVlZCBpcyBvbmUgb2YgdGhlIGJldHRlciBvbmVzIHRv IHVzZSBhcyB0aGUgYmFzZS4NCg0KUGluZw0KT24gVGh1LCBBdWcgMiwgMjAxMiBhdCAxMTowNyBB TSwgUGVkcm8gUm9xdWUgTWFycXVlcyA8cGVkcm8uci5tYXJxdWVzQGdtYWlsLmNvbTxtYWlsdG86 cGVkcm8uci5tYXJxdWVzQGdtYWlsLmNvbT4+IHdyb3RlOg0KQXMgaSBwb2ludGVkIG91dCBpbiB0 aGUgUlQgYXJlYSBtZWV0aW5nLCBpIGJlbGlldmUgdGhhdCBJRi1NQVAgaXMgYSBzdWNjZXNzZnVs IGV4YW1wbGUgb2Ygd2hhdCBjYW4gYmUgYWNoaWV2ZWQgYnkgbmV0d29yay13aWRlIHNjaGVtYXMg KHZzIG5ldHdvcmsgZWxlbWVudCBzY2hlbWFzKS4NCg0KVGhlIGN1cnJlbnQgc3BlYyBpcyBhdDoN Cmh0dHA6Ly93d3cudHJ1c3RlZGNvbXB1dGluZ2dyb3VwLm9yZy9maWxlcy9yZXNvdXJjZV9maWxl cy8yODg4Q0FEOS0xQTRCLUIyOTQtRDBFRDk1NzEyQjEyMUZFRi9UTkNfSUZNQVBfdjJfMXIxNS5w ZGYNCg0KaWYtbWFwLm9yZzxodHRwOi8vaWYtbWFwLm9yZy8+IGhhcyBsb3RzIG9mIG1hdGVyaWFs IG9uIHRoZSB1c2UgY2FzZXMuDQoNCkFzIHBlciBteSBjb21tZW50IG9uIHRoZSBtaWMsIGknZCBs aWtlIHRvIGVuY291cmFnZSB0aGUgSVJTIHRvIGZvY3VzIG9uIGRhdGEgc2NoZW1hcyB0aGF0IGRl c2NyaWJlIG5ldHdvcmsgc3RhdGUuDQoNCnRoYW5rIHlvdSwNCiAgUGVkcm8uDQpfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KaXJzLWRpc2N1c3MgbWFpbGlu ZyBsaXN0DQppcnMtZGlzY3Vzc0BpZXRmLm9yZzxtYWlsdG86aXJzLWRpc2N1c3NAaWV0Zi5vcmc+ DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lycy1kaXNjdXNzDQoNCg0K DQo= --_000_728F9B956B2C48439CA9294B1723B14623755EAFdfweml509mbschi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2 IDQgMyA1IDQgNCAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBs aS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9t Oi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJv bWFuIiwic2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnNwYW4u RW1haWxTdHlsZTE3DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFt aWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVm YXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTt9DQpAcGFnZSBXb3JkU2VjdGlvbjEN Cgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30N CmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0t W2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRt YXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4N CjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRh PSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJv ZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0i V29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEIj5QaW5nIGFuZCBwZWRybzo8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPldoYXTigJlz IG5pY2UgaGVyZSBpcyB0aGlzIGlzIGFuIGludGVyZXN0aW5nIHByb3Zpc2lvbmluZyBzY2hlbWEu Jm5ic3A7IERpZCB5b3UgaGF2ZSBwcm9kdWN0aW9uIGNvZGUgb3Igcm91Z2ggY29kZSB0aGF0IHlv dSB0cmllZCB0aGlzIHdpdGg/PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5TdWU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG NDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5v bmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAw aW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsi PkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IGlycy1kaXNjdXNz LWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzppcnMtZGlzY3Vzcy1ib3VuY2VzQGlldGYub3JnXQ0K PGI+T24gQmVoYWxmIE9mIDwvYj5QaW5nIFBhbjxicj4NCjxiPlNlbnQ6PC9iPiBUaHVyc2RheSwg QXVndXN0IDAyLCAyMDEyIDM6MzUgUE08YnI+DQo8Yj5Ubzo8L2I+IFBlZHJvIFJvcXVlIE1hcnF1 ZXM8YnI+DQo8Yj5DYzo8L2I+IGlycy1kaXNjdXNzQGlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8 L2I+IFJlOiBbaXJzLWRpc2N1c3NdIGlmLW1hcCBleGFtcGxlPG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+QW5kIHRoaXMg Y2FuIGJlIGV4dGVuZGVkIHRvIGFwcGx5IG1vcmUgdGhhbiBMM1ZQTi4uLjxvOnA+PC9vOnA+PC9w Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIFRodSwgQXVnIDIsIDIwMTIgYXQgMzox OCBQTSwgUGVkcm8gUm9xdWUgTWFycXVlcyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnBlZHJvLnIubWFy cXVlc0BnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj5wZWRyby5yLm1hcnF1ZXNAZ21haWwuY29t PC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPkFzIGFuIGFkZGl0aW9uYWwgZXhhbXBsZSwgdGhlIGZvbGxvd2luZyBkb2N1bWVu dCBkZXNjcmliZXMgYSBzY2hlbWEgdGhhdCBjYW4gYmUgdXNlZCB0byBwcm92aXNpb24gYSBWUE4g KHdoaWNoIGlzIGltcGxlbWVudGVkIGJ5IG1hbnkgUEVzIGFzIGluZGl2aWR1YWwgVlJGcykuPG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxhIGhyZWY9Imh0dHA6 Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtbWFycXVlcy1sM3Zwbi1zY2hlbWEiIHRh cmdldD0iX2JsYW5rIj5odHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LW1hcnF1 ZXMtbDN2cG4tc2NoZW1hPC9hPjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+VGhlIGRvY3VtZW50IGlzIHN0aWxsIGluIGl0cyBlYXJseSBzdGFnZXMuPG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoZSBwcm9i bGVtcyB0aGF0IGNhbiBiZSBzb2x2ZWQgYnkgc3VjaCBhIHNjaGVtYSBpcyB0byBiZSBhYmxlIHRv LCBmb3IgaW5zdGFuY2U6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj4xKSBRdWVyeSB0aGUgTUFQIGRhdGFiYXNlIGZvciBhbGwgUEVzIHdoZXJlIGEg c3BlY2lmaWMgVlBOIGlzIHByZXNlbnQuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj4yKSBFbnN1cmUgdGhhdCB0aGUgVlJGcyBhc3NvY2lhdGVkIHdp dGggYSBzcGVjaWZpYyBWUE4gY29uc2lzdGVudGx5IGltcGxlbWVudCB0aGUgc2FtZSBwb2xpY3ku PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRo ZXNlIGFyZSBib3RoIGV4YW1wbGVzIG9mIGZ1bmN0aW9uYWxpdHkgdGhhdCBzcGFucyB0aGUgbmV0 d29yayByYXRoZXIgdGhhbiBiZSBsb2NhbGl6ZWQgdG8gYSBzcGVjaWZpYyByb3V0ZXIvc3dpdGNo L2FwcGxpYW5jZS48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi Pk9uIEF1ZyAyLCAyMDEyLCBhdCAyOjMyIFBNLCBQaW5nIFBhbiB3cm90ZTo8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KPGJyPg0KPG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5BZnRlciBwbGF5aW5nIGFyb3VuZCB3aXRoIGEgYnVu Y2ggb2Ygb3RoZXIgc2NoZW1lcywgdGhpcyBpbmRlZWQgaXMgb25lIG9mIHRoZSBiZXR0ZXIgb25l cyB0byB1c2UgYXMgdGhlIGJhc2UuPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPlBpbmc8bzpwPjwvbzpwPjwv cD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBUaHUsIEF1ZyAyLCAyMDEyIGF0IDEx OjA3IEFNLCBQZWRybyBSb3F1ZSBNYXJxdWVzICZsdDs8YSBocmVmPSJtYWlsdG86cGVkcm8uci5t YXJxdWVzQGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnBlZHJvLnIubWFycXVlc0BnbWFpbC5j b208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkFz IGkgcG9pbnRlZCBvdXQgaW4gdGhlIFJUIGFyZWEgbWVldGluZywgaSBiZWxpZXZlIHRoYXQgSUYt TUFQIGlzIGEgc3VjY2Vzc2Z1bCBleGFtcGxlIG9mIHdoYXQgY2FuIGJlIGFjaGlldmVkIGJ5IG5l dHdvcmstd2lkZSBzY2hlbWFzICh2cyBuZXR3b3JrIGVsZW1lbnQgc2NoZW1hcykuPGJyPg0KPGJy Pg0KVGhlIGN1cnJlbnQgc3BlYyBpcyBhdDo8YnI+DQo8YSBocmVmPSJodHRwOi8vd3d3LnRydXN0 ZWRjb21wdXRpbmdncm91cC5vcmcvZmlsZXMvcmVzb3VyY2VfZmlsZXMvMjg4OENBRDktMUE0Qi1C Mjk0LUQwRUQ5NTcxMkIxMjFGRUYvVE5DX0lGTUFQX3YyXzFyMTUucGRmIiB0YXJnZXQ9Il9ibGFu ayI+aHR0cDovL3d3dy50cnVzdGVkY29tcHV0aW5nZ3JvdXAub3JnL2ZpbGVzL3Jlc291cmNlX2Zp bGVzLzI4ODhDQUQ5LTFBNEItQjI5NC1EMEVEOTU3MTJCMTIxRkVGL1ROQ19JRk1BUF92Ml8xcjE1 LnBkZjwvYT48YnI+DQo8YnI+DQo8YSBocmVmPSJodHRwOi8vaWYtbWFwLm9yZy8iIHRhcmdldD0i X2JsYW5rIj5pZi1tYXAub3JnPC9hPiBoYXMgbG90cyBvZiBtYXRlcmlhbCBvbiB0aGUgdXNlIGNh c2VzLjxicj4NCjxicj4NCkFzIHBlciBteSBjb21tZW50IG9uIHRoZSBtaWMsIGknZCBsaWtlIHRv IGVuY291cmFnZSB0aGUgSVJTIHRvIGZvY3VzIG9uIGRhdGEgc2NoZW1hcyB0aGF0IGRlc2NyaWJl IG5ldHdvcmsgc3RhdGUuPGJyPg0KPGJyPg0KdGhhbmsgeW91LDxicj4NCiZuYnNwOyBQZWRyby48 YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4N Cmlycy1kaXNjdXNzIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzppcnMtZGlzY3Vz c0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPmlycy1kaXNjdXNzQGlldGYub3JnPC9hPjxicj4N CjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaXJzLWRpc2N1 c3MiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L2lycy1kaXNjdXNzPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_728F9B956B2C48439CA9294B1723B14623755EAFdfweml509mbschi_-- Return-Path: 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 CA43C11E80F0 for ; Thu, 2 Aug 2012 16:38:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.641 X-Spam-Level: X-Spam-Status: No, score=-4.641 tagged_above=-999 required=5 tests=[AWL=1.358, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZPelfvO4IVZU for ; Thu, 2 Aug 2012 16:38:41 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 1E30311E8072 for ; Thu, 2 Aug 2012 16:38:41 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml202-edg.china.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AIQ40065; Thu, 02 Aug 2012 15:38:40 -0800 (PST) Received: from DFWEML406-HUB.china.huawei.com (10.193.5.131) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 2 Aug 2012 16:37:04 -0700 Received: from dfweml509-mbs.china.huawei.com ([169.254.12.123]) by dfweml406-hub.china.huawei.com ([10.193.5.131]) with mapi id 14.01.0323.003; Thu, 2 Aug 2012 16:36:58 -0700 From: Susan Hares To: Thomas Nadeau , James Kempf , "irs-discuss@ietf.org" Thread-Topic: [irs-discuss] Suggestions for IRS Way Forward Thread-Index: Ac1w/aRFxquJYy0LSJCFfpb4MILlegAO51CAAA0BS4D//6fIgIAAc/XQ Date: Thu, 2 Aug 2012 23:36:57 +0000 Message-ID: <728F9B956B2C48439CA9294B1723B14623755EA0@dfweml509-mbs.china.huawei.com> References: <728F9B956B2C48439CA9294B1723B14623755E3C@dfweml509-mbs.china.huawei.com> In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.212.245.215] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [irs-discuss] Suggestions for IRS Way Forward X-BeenThere: irs-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2012 23:38:41 -0000 Tom: Knowing authors of these drafts, this is true. They believe there is more t= o do. They proposed initial work and provide running code to test the ideas= .=20 Love to hear about where you think the holes are in each of these protocols= .=20 Sue=20 -----Original Message----- From: Thomas Nadeau [mailto:tnadeau@juniper.net]=20 Sent: Thursday, August 02, 2012 4:28 PM To: Susan Hares; James Kempf; irs-discuss@ietf.org Subject: Re: [irs-discuss] Suggestions for IRS Way Forward On 8/2/12 4:21 PM, "Susan Hares" wrote: >Tom: > >So, is ALTO, PCE, Yang modules with topology in scope. I think those are very good and important components yes. >Are you stating that we do not re-inventing the ALTO functions topology >(see previous note)? I'd definitely prefer to not reinvent those functions unless there are good reasons to do so. However, as Alia explained during the meeting, they are incomplete. --Tom >=20 > >Sue=20 > >-----Original Message----- >From: irs-discuss-bounces@ietf.org [mailto:irs-discuss-bounces@ietf.org] >On Behalf Of Thomas Nadeau >Sent: Thursday, August 02, 2012 3:32 PM >To: James Kempf; irs-discuss@ietf.org >Subject: Re: [irs-discuss] Suggestions for IRS Way Forward > > > I agree that one of the top work items for this effort should be a >standardized topology function, and one that is accessible via a >non-routing protocol. While not exactly "low hanging fruit", it is >something that (to me) is a clear work item with clear goals that should >be tackled straight away. > > --Tom > > > >On 8/2/12 3:24 PM, "James Kempf" wrote: > >>So after seeing part of Alia's talk this morning (I had to leave in the >>middle unfortunately), I'd like to make a couple suggestions. There were >>a lot of ideas presented in the talk, enough for an entire IETF Area. I >>think to make tangible progress, the work needs to be focussed on a small >>subset that would be of immediate interest and usability. >> >>There are a couple areas that suggest themselves, but one that would be >>useful in work that I've been involved in is a standardized format for >>network topology representation and a protocol for exchanging it. The >>Onix OpenFlow controller has a network information base with a >>specialized format for network topology, and every OpenFlow controller >>requires this. Having a standardized way to represent it might foster a >>common topology database package. Another application is network >>management. Every network management system needs some kind of topology >>representation. Finally, though I am not an expert in PCE construction, >>it would seem to me that a PCE would need some kind of topology >>representation in order to perform path calculations. Having a way,for >>example, for the OpenFlow controller and the PCE to exchange topology >>information would be really useful. I would say to start with physical >>topology because that is fundamental, but make the format flexible enough >>to support=20 >> virtual topology representation. >> >> jak >>_______________________________________________ >>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 Return-Path: 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 3941011E8150 for ; Thu, 2 Aug 2012 16:33:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.573 X-Spam-Level: X-Spam-Status: No, score=-4.573 tagged_above=-999 required=5 tests=[AWL=1.426, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RRQIQP8M0YyG for ; Thu, 2 Aug 2012 16:33:55 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 541E911E8129 for ; Thu, 2 Aug 2012 16:33:55 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml202-edg.china.huawei.com) ([172.18.9.243]) by dfwrg02-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AIJ41914; Thu, 02 Aug 2012 15:33:55 -0800 (PST) Received: from DFWEML408-HUB.china.huawei.com (10.193.5.134) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 2 Aug 2012 16:30:08 -0700 Received: from dfweml509-mbs.china.huawei.com ([169.254.12.123]) by dfweml408-hub.china.huawei.com ([10.193.5.134]) with mapi id 14.01.0323.003; Thu, 2 Aug 2012 16:30:06 -0700 From: Susan Hares To: "robert@raszuk.net" , James Kempf Thread-Topic: [irs-discuss] Suggestions for IRS Way Forward Thread-Index: Ac1w/aRFxquJYy0LSJCFfpb4MILlegAQnpmAAA6KuUA= Date: Thu, 2 Aug 2012 23:30:06 +0000 Message-ID: <728F9B956B2C48439CA9294B1723B14623755E64@dfweml509-mbs.china.huawei.com> References: <501B0B4F.7020609@raszuk.net> In-Reply-To: <501B0B4F.7020609@raszuk.net> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.212.245.215] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "irs-discuss@ietf.org" Subject: Re: [irs-discuss] Suggestions for IRS Way Forward X-BeenThere: irs-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2012 23:33:56 -0000 James: This is the full detailed routes. However, will every ISP share it's ISIS = topology. Sue=20 -----Original Message----- From: irs-discuss-bounces@ietf.org [mailto:irs-discuss-bounces@ietf.org] On= Behalf Of Robert Raszuk Sent: Thursday, August 02, 2012 4:21 PM To: James Kempf Cc: irs-discuss@ietf.org Subject: Re: [irs-discuss] Suggestions for IRS Way Forward Hi James, On the topic of topology export it is my understanding that we do=20 already have a solution which in fact even authors of IRS framework=20 support and are putting under their umbrella. That is: http://tools.ietf.org/html/draft-gredler-idr-ls-distribution-01 The draft as standards track document defines the topology export=20 standard in form of link and node NLRIs with bunch of TLVs. So the key aspect would be to see what is missing and if something is=20 missing in the space of topology export to evaluate if this solution by=20 principle can be extended to accommodate it. Best, R. > So after seeing part of Alia's talk this morning (I had to leave in > the middle unfortunately), I'd like to make a couple suggestions. > There were a lot of ideas presented in the talk, enough for an entire > IETF Area. I think to make tangible progress, the work needs to be > focussed on a small subset that would be of immediate interest and > usability. > > There are a couple areas that suggest themselves, but one that would > be useful in work that I've been involved in is a standardized format > for network topology representation and a protocol for exchanging it. > The Onix OpenFlow controller has a network information base with a > specialized format for network topology, and every OpenFlow > controller requires this. Having a standardized way to represent it > might foster a common topology database package. Another application > is network management. Every network management system needs some > kind of topology representation. Finally, though I am not an expert > in PCE construction, it would seem to me that a PCE would need some > kind of topology representation in order to perform path > calculations. Having a way,for example, for the OpenFlow controller > and the PCE to exchange topology information would be really useful. > I would say to start with physical topology because that is > fundamental, but make the format flexible enough to support virtual > topology representation. > > jak _______________________________________________ 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 Return-Path: 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 2444011E81CE for ; Thu, 2 Aug 2012 16:29:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.014 X-Spam-Level: X-Spam-Status: No, score=-2.014 tagged_above=-999 required=5 tests=[AWL=-0.015, BAYES_00=-2.599, J_CHICKENPOX_33=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eANkJW8Er3wH for ; Thu, 2 Aug 2012 16:29:58 -0700 (PDT) Received: from mail1310.opentransfer.com (mail1310.opentransfer.com [76.162.254.103]) by ietfa.amsl.com (Postfix) with ESMTP id 6557911E8169 for ; Thu, 2 Aug 2012 16:29:58 -0700 (PDT) Received: (qmail 7307 invoked by uid 399); 2 Aug 2012 23:29:57 -0000 Received: from unknown (HELO ?130.129.17.10?) (pbs:robert@raszuk.net@130.129.17.10) by mail1310.opentransfer.com with ESMTPM; 2 Aug 2012 23:29:57 -0000 X-Originating-IP: 130.129.17.10 Message-ID: <501B0D75.4090009@raszuk.net> Date: Fri, 03 Aug 2012 01:29:57 +0200 From: Robert Raszuk User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: Thomas Nadeau References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: James Kempf , "irs-discuss@ietf.org" Subject: Re: [irs-discuss] Suggestions for IRS Way Forward X-BeenThere: irs-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: robert@raszuk.net List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2012 23:29:59 -0000 Tom, > I agree that one of the top work items for this effort should be a > standardized topology function, and one that is accessible via a > non-routing protocol. So if the requirement is to have topology export via non-routing protocol then I think we should seriously revisit or repackage the draft-gredler-idr-ls-distribution-01 which works for for both OSPF and ISIS. However before that let's really understand the requirement why it must be exported via non-routing protocol .... Keep in mind that just to parse BGP UPDATE messages and retrieve interesting pieces out it it requires very little code rather then full BGP implementation. The particular feature I like about draft-gredler-idr-ls-distribution-01 is that it is read-only ;) R. > > I agree that one of the top work items for this effort should be a > standardized topology function, and one that is accessible via a > non-routing protocol. While not exactly "low hanging fruit", it is > something that (to me) is a clear work item with clear goals that should > be tackled straight away. > > --Tom > > > > On 8/2/12 3:24 PM, "James Kempf" wrote: > >> So after seeing part of Alia's talk this morning (I had to leave in the >> middle unfortunately), I'd like to make a couple suggestions. There were >> a lot of ideas presented in the talk, enough for an entire IETF Area. I >> think to make tangible progress, the work needs to be focussed on a small >> subset that would be of immediate interest and usability. >> >> There are a couple areas that suggest themselves, but one that would be >> useful in work that I've been involved in is a standardized format for >> network topology representation and a protocol for exchanging it. The >> Onix OpenFlow controller has a network information base with a >> specialized format for network topology, and every OpenFlow controller >> requires this. Having a standardized way to represent it might foster a >> common topology database package. Another application is network >> management. Every network management system needs some kind of topology >> representation. Finally, though I am not an expert in PCE construction, >> it would seem to me that a PCE would need some kind of topology >> representation in order to perform path calculations. Having a way,for >> example, for the OpenFlow controller and the PCE to exchange topology >> information would be really useful. I would say to start with physical >> topology because that is fundamental, but make the format flexible enough >> to support >> virtual topology representation. >> >> jak >> _______________________________________________ >> 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 > > Return-Path: 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 4B19511E81E1 for ; Thu, 2 Aug 2012 16:29:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.59 X-Spam-Level: X-Spam-Status: No, score=-3.59 tagged_above=-999 required=5 tests=[AWL=0.009, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zqvHSXc-zH3Q for ; Thu, 2 Aug 2012 16:29:39 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id F06F611E8169 for ; Thu, 2 Aug 2012 16:29:38 -0700 (PDT) Received: by yenq13 with SMTP id q13so117326yen.31 for ; Thu, 02 Aug 2012 16:29:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=pzZ7mgaaHJ3gijrqafIbUkfgT2iTOdVJGA+75kMFJTo=; b=Ga2meWEv9filGJiDrgwwYi8iVRJ4e/Y0X9D+Rd5tQDmIXIp9Q6QoZvmqxIU6ZWQA2C 8o7eejP4C7lBKR1jGZavoEgPL4/wRsbO+kZ76thaYbbYUVTZgWa91tO7hpUxTrIUQ4cu q5pA2fLeYXkwiDpsacYu0dc8q+jnTvylDxRuZVsKg6Ekknae3IuCXkrdZEnfqkfxLXUU j0nmb/xeVcuvmTP04OKULHgs2hvuCbPxHVjGSM4NTVmx/HEHX1gct4w05tzkmrnWUdtf laZlPeTOGsaR9ebuPb7RNM5O7UrjIGrgcFLLBwLBzjPRTdX34zi4Pi+kxGLjzAjny1Wm BJIw== MIME-Version: 1.0 Received: by 10.50.104.228 with SMTP id gh4mr6458529igb.71.1343950177940; Thu, 02 Aug 2012 16:29:37 -0700 (PDT) Received: by 10.50.34.169 with HTTP; Thu, 2 Aug 2012 16:29:37 -0700 (PDT) In-Reply-To: <632FAE8B-8CC5-4701-BB42-1C4EACE372D5@gmail.com> References: <632FAE8B-8CC5-4701-BB42-1C4EACE372D5@gmail.com> Date: Thu, 2 Aug 2012 19:29:37 -0400 Message-ID: From: Alia Atlas To: Pedro Roque Marques Content-Type: text/plain; charset=ISO-8859-1 Cc: irs-discuss@ietf.org Subject: Re: [irs-discuss] if-map example X-BeenThere: irs-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2012 23:29:41 -0000 Pedro, Thanks for sending out the references. I'll definitely take a look. Alia On Thu, Aug 2, 2012 at 2:07 PM, Pedro Roque Marques wrote: > As i pointed out in the RT area meeting, i believe that IF-MAP is a successful example of what can be achieved by network-wide schemas (vs network element schemas). > > The current spec is at: > http://www.trustedcomputinggroup.org/files/resource_files/2888CAD9-1A4B-B294-D0ED95712B121FEF/TNC_IFMAP_v2_1r15.pdf > > if-map.org has lots of material on the use cases. > > As per my comment on the mic, i'd like to encourage the IRS to focus on data schemas that describe network state. > > thank you, > Pedro. > _______________________________________________ > irs-discuss mailing list > irs-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/irs-discuss Return-Path: 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 4FE4D11E81D9 for ; Thu, 2 Aug 2012 16:28:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.141 X-Spam-Level: X-Spam-Status: No, score=-6.141 tagged_above=-999 required=5 tests=[AWL=-0.142, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zs4E-wthz-DM for ; Thu, 2 Aug 2012 16:28:45 -0700 (PDT) Received: from exprod7og114.obsmtp.com (exprod7og114.obsmtp.com [64.18.2.215]) by ietfa.amsl.com (Postfix) with ESMTP id A5D0711E81CE for ; Thu, 2 Aug 2012 16:28:42 -0700 (PDT) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob114.postini.com ([64.18.6.12]) with SMTP ID DSNKUBsNKtAPyayyTxEgwgyfY7RCROBwd6kw@postini.com; Thu, 02 Aug 2012 16:28:45 PDT Received: from p-emfe02-wf.jnpr.net (172.28.145.25) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server (TLS) id 8.3.213.0; Thu, 2 Aug 2012 16:28:19 -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; Thu, 2 Aug 2012 19:28:18 -0400 From: Thomas Nadeau To: Susan Hares , James Kempf , "irs-discuss@ietf.org" Date: Thu, 2 Aug 2012 19:28:17 -0400 Thread-Topic: [irs-discuss] Suggestions for IRS Way Forward Thread-Index: Ac1xBn8k1PtUa5tzQXmxFFokax+68A== Message-ID: In-Reply-To: <728F9B956B2C48439CA9294B1723B14623755E3C@dfweml509-mbs.china.huawei.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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [irs-discuss] Suggestions for IRS Way Forward X-BeenThere: irs-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2012 23:28:46 -0000 On 8/2/12 4:21 PM, "Susan Hares" wrote: >Tom: > >So, is ALTO, PCE, Yang modules with topology in scope. I think those are very good and important components yes. >Are you stating that we do not re-inventing the ALTO functions topology >(see previous note)? I'd definitely prefer to not reinvent those functions unless there are good reasons to do so. However, as Alia explained during the meeting, they are incomplete. --Tom >=20 > >Sue=20 > >-----Original Message----- >From: irs-discuss-bounces@ietf.org [mailto:irs-discuss-bounces@ietf.org] >On Behalf Of Thomas Nadeau >Sent: Thursday, August 02, 2012 3:32 PM >To: James Kempf; irs-discuss@ietf.org >Subject: Re: [irs-discuss] Suggestions for IRS Way Forward > > > I agree that one of the top work items for this effort should be a >standardized topology function, and one that is accessible via a >non-routing protocol. While not exactly "low hanging fruit", it is >something that (to me) is a clear work item with clear goals that should >be tackled straight away. > > --Tom > > > >On 8/2/12 3:24 PM, "James Kempf" wrote: > >>So after seeing part of Alia's talk this morning (I had to leave in the >>middle unfortunately), I'd like to make a couple suggestions. There were >>a lot of ideas presented in the talk, enough for an entire IETF Area. I >>think to make tangible progress, the work needs to be focussed on a small >>subset that would be of immediate interest and usability. >> >>There are a couple areas that suggest themselves, but one that would be >>useful in work that I've been involved in is a standardized format for >>network topology representation and a protocol for exchanging it. The >>Onix OpenFlow controller has a network information base with a >>specialized format for network topology, and every OpenFlow controller >>requires this. Having a standardized way to represent it might foster a >>common topology database package. Another application is network >>management. Every network management system needs some kind of topology >>representation. Finally, though I am not an expert in PCE construction, >>it would seem to me that a PCE would need some kind of topology >>representation in order to perform path calculations. Having a way,for >>example, for the OpenFlow controller and the PCE to exchange topology >>information would be really useful. I would say to start with physical >>topology because that is fundamental, but make the format flexible enough >>to support=20 >> virtual topology representation. >> >> jak >>_______________________________________________ >>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 Return-Path: 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 E445011E819F for ; Thu, 2 Aug 2012 16:25:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.782 X-Spam-Level: X-Spam-Status: No, score=-4.782 tagged_above=-999 required=5 tests=[AWL=1.816, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4m2N8Rqx9L8Z for ; Thu, 2 Aug 2012 16:25:14 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 5034C11E8179 for ; Thu, 2 Aug 2012 16:25:14 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml202-edg.china.huawei.com) ([172.18.9.243]) by dfwrg02-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AIJ41499; Thu, 02 Aug 2012 15:25:14 -0800 (PST) Received: from DFWEML407-HUB.china.huawei.com (10.193.5.132) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 2 Aug 2012 16:22:27 -0700 Received: from dfweml509-mbs.china.huawei.com ([169.254.12.123]) by dfweml407-hub.china.huawei.com ([10.193.5.132]) with mapi id 14.01.0323.003; Thu, 2 Aug 2012 16:22:20 -0700 From: Susan Hares To: "irs-discuss@ietf.org" Thread-Topic: Dave Meyer's reference Thread-Index: Ac1xBamEPT9nIiBNRzuqnrjWB6ch1w== Date: Thu, 2 Aug 2012 23:22:20 +0000 Message-ID: <728F9B956B2C48439CA9294B1723B14623755E48@dfweml509-mbs.china.huawei.com> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.212.245.215] Content-Type: multipart/alternative; boundary="_000_728F9B956B2C48439CA9294B1723B14623755E48dfweml509mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: [irs-discuss] Dave Meyer's reference X-BeenThere: irs-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2012 23:25:15 -0000 --_000_728F9B956B2C48439CA9294B1723B14623755E48dfweml509mbschi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dave Meyer - or anyone else Does anyone a pointer to the work Dave referenced during the IRS meeting? = Or does the note taker have information? Thanks, Sue --_000_728F9B956B2C48439CA9294B1723B14623755E48dfweml509mbschi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dave Meyer – or anyone else

 

Does anyone a pointer to the work Dave referenced du= ring the IRS meeting?  Or does the note taker have information?

 

Thanks,

 

Sue

--_000_728F9B956B2C48439CA9294B1723B14623755E48dfweml509mbschi_-- Return-Path: 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 E9C7E21E80AB for ; Thu, 2 Aug 2012 16:23:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.398 X-Spam-Level: X-Spam-Status: No, score=-4.398 tagged_above=-999 required=5 tests=[AWL=1.601, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 09GdZgWAl-ER for ; Thu, 2 Aug 2012 16:23:56 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 3050B21E80A0 for ; Thu, 2 Aug 2012 16:23:56 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml202-edg.china.huawei.com) ([172.18.9.243]) by dfwrg02-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AIJ41433; Thu, 02 Aug 2012 15:23:55 -0800 (PST) Received: from DFWEML408-HUB.china.huawei.com (10.193.5.134) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 2 Aug 2012 16:21:18 -0700 Received: from dfweml509-mbs.china.huawei.com ([169.254.12.123]) by dfweml408-hub.china.huawei.com ([10.193.5.134]) with mapi id 14.01.0323.003; Thu, 2 Aug 2012 16:21:14 -0700 From: Susan Hares To: Thomas Nadeau , James Kempf , "irs-discuss@ietf.org" Thread-Topic: [irs-discuss] Suggestions for IRS Way Forward Thread-Index: Ac1w/aRFxquJYy0LSJCFfpb4MILlegAO51CAAA0BS4A= Date: Thu, 2 Aug 2012 23:21:14 +0000 Message-ID: <728F9B956B2C48439CA9294B1723B14623755E3C@dfweml509-mbs.china.huawei.com> References: In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.212.245.215] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [irs-discuss] Suggestions for IRS Way Forward X-BeenThere: irs-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2012 23:23:57 -0000 Tom: So, is ALTO, PCE, Yang modules with topology in scope. Are you stating that we do not re-inventing the ALTO functions topology (se= e previous note)?=20 Sue=20 -----Original Message----- From: irs-discuss-bounces@ietf.org [mailto:irs-discuss-bounces@ietf.org] On= Behalf Of Thomas Nadeau Sent: Thursday, August 02, 2012 3:32 PM To: James Kempf; irs-discuss@ietf.org Subject: Re: [irs-discuss] Suggestions for IRS Way Forward I agree that one of the top work items for this effort should be a standardized topology function, and one that is accessible via a non-routing protocol. While not exactly "low hanging fruit", it is something that (to me) is a clear work item with clear goals that should be tackled straight away. --Tom On 8/2/12 3:24 PM, "James Kempf" wrote: >So after seeing part of Alia's talk this morning (I had to leave in the >middle unfortunately), I'd like to make a couple suggestions. There were >a lot of ideas presented in the talk, enough for an entire IETF Area. I >think to make tangible progress, the work needs to be focussed on a small >subset that would be of immediate interest and usability. > >There are a couple areas that suggest themselves, but one that would be >useful in work that I've been involved in is a standardized format for >network topology representation and a protocol for exchanging it. The >Onix OpenFlow controller has a network information base with a >specialized format for network topology, and every OpenFlow controller >requires this. Having a standardized way to represent it might foster a >common topology database package. Another application is network >management. Every network management system needs some kind of topology >representation. Finally, though I am not an expert in PCE construction, >it would seem to me that a PCE would need some kind of topology >representation in order to perform path calculations. Having a way,for >example, for the OpenFlow controller and the PCE to exchange topology >information would be really useful. I would say to start with physical >topology because that is fundamental, but make the format flexible enough >to support=20 > virtual topology representation. > > jak >_______________________________________________ >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 Return-Path: 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 2AF0421E80A0 for ; Thu, 2 Aug 2012 16:20:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.015 X-Spam-Level: X-Spam-Status: No, score=-2.015 tagged_above=-999 required=5 tests=[AWL=-0.016, BAYES_00=-2.599, J_CHICKENPOX_33=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sq-wnDJKGt3X for ; Thu, 2 Aug 2012 16:20:49 -0700 (PDT) Received: from mail1310.opentransfer.com (mail1310.opentransfer.com [76.162.254.103]) by ietfa.amsl.com (Postfix) with ESMTP id 9C7EB21E8096 for ; Thu, 2 Aug 2012 16:20:48 -0700 (PDT) Received: (qmail 28545 invoked by uid 399); 2 Aug 2012 23:20:48 -0000 Received: from unknown (HELO ?130.129.17.10?) (pbs:robert@raszuk.net@130.129.17.10) by mail1310.opentransfer.com with ESMTPM; 2 Aug 2012 23:20:48 -0000 X-Originating-IP: 130.129.17.10 Message-ID: <501B0B4F.7020609@raszuk.net> Date: Fri, 03 Aug 2012 01:20:47 +0200 From: Robert Raszuk User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: James Kempf References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "irs-discuss@ietf.org" Subject: Re: [irs-discuss] Suggestions for IRS Way Forward X-BeenThere: irs-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: robert@raszuk.net List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2012 23:20:50 -0000 Hi James, On the topic of topology export it is my understanding that we do already have a solution which in fact even authors of IRS framework support and are putting under their umbrella. That is: http://tools.ietf.org/html/draft-gredler-idr-ls-distribution-01 The draft as standards track document defines the topology export standard in form of link and node NLRIs with bunch of TLVs. So the key aspect would be to see what is missing and if something is missing in the space of topology export to evaluate if this solution by principle can be extended to accommodate it. Best, R. > So after seeing part of Alia's talk this morning (I had to leave in > the middle unfortunately), I'd like to make a couple suggestions. > There were a lot of ideas presented in the talk, enough for an entire > IETF Area. I think to make tangible progress, the work needs to be > focussed on a small subset that would be of immediate interest and > usability. > > There are a couple areas that suggest themselves, but one that would > be useful in work that I've been involved in is a standardized format > for network topology representation and a protocol for exchanging it. > The Onix OpenFlow controller has a network information base with a > specialized format for network topology, and every OpenFlow > controller requires this. Having a standardized way to represent it > might foster a common topology database package. Another application > is network management. Every network management system needs some > kind of topology representation. Finally, though I am not an expert > in PCE construction, it would seem to me that a PCE would need some > kind of topology representation in order to perform path > calculations. Having a way,for example, for the OpenFlow controller > and the PCE to exchange topology information would be really useful. > I would say to start with physical topology because that is > fundamental, but make the format flexible enough to support virtual > topology representation. > > jak _______________________________________________ irs-discuss > mailing list irs-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/irs-discuss > > Return-Path: 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 7FC5D21E804A for ; Thu, 2 Aug 2012 16:17:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.304 X-Spam-Level: X-Spam-Status: No, score=-4.304 tagged_above=-999 required=5 tests=[AWL=1.695, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wJYnNmxp4sjr for ; Thu, 2 Aug 2012 16:17:42 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id D383221E8039 for ; Thu, 2 Aug 2012 16:17:41 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml202-edg.china.huawei.com) ([172.18.9.243]) by dfwrg02-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AIJ41138; Thu, 02 Aug 2012 15:17:41 -0800 (PST) Received: from DFWEML403-HUB.china.huawei.com (10.193.5.151) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 2 Aug 2012 16:15:58 -0700 Received: from dfweml509-mbs.china.huawei.com ([169.254.12.123]) by dfweml403-hub.china.huawei.com ([10.193.5.151]) with mapi id 14.01.0323.003; Thu, 2 Aug 2012 16:15:55 -0700 From: Susan Hares To: James Kempf , "irs-discuss@ietf.org" Thread-Topic: Suggestions for IRS Way Forward Thread-Index: Ac1w/aRFxquJYy0LSJCFfpb4MILlegABYztA Date: Thu, 2 Aug 2012 23:15:55 +0000 Message-ID: <728F9B956B2C48439CA9294B1723B14623755DFD@dfweml509-mbs.china.huawei.com> References: In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.212.245.215] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [irs-discuss] Suggestions for IRS Way Forward X-BeenThere: irs-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2012 23:17:42 -0000 James: How would your network topology representation differ from the ALTO-EXT doc= ument - such as=20 http://tools.ietf.org/pdf/draft-lee-alto-app-net-info-exchange-00.pdf I'm sure there are many other topology set of information.=20 There is the just dumping isis into BGP.=20 draft-gredler-idr-ls-distribution-02 And the reported ONIX OpenFlow Controller (see below)=20 Or the PCE domain sequence http://tools.ietf.org/pdf/draft-ietf-pce-pcep-domain-sequence-01.pdf What do you want for topologies - or do you want a choice?=20 What exactly do you mean by topologies? And what's the use case?=20 Sue=20 -----Original Message----- From: irs-discuss-bounces@ietf.org [mailto:irs-discuss-bounces@ietf.org] On= Behalf Of James Kempf Sent: Thursday, August 02, 2012 3:25 PM To: irs-discuss@ietf.org Subject: [irs-discuss] Suggestions for IRS Way Forward So after seeing part of Alia's talk this morning (I had to leave in the mid= dle unfortunately), I'd like to make a couple suggestions. There were a lot= of ideas presented in the talk, enough for an entire IETF Area. I think to= make tangible progress, the work needs to be focussed on a small subset th= at would be of immediate interest and usability.=20 There are a couple areas that suggest themselves, but one that would be use= ful in work that I've been involved in is a standardized format for network= topology representation and a protocol for exchanging it. The Onix OpenFlo= w controller has a network information base with a specialized format for n= etwork topology, and every OpenFlow controller requires this. Having a stan= dardized way to represent it might foster a common topology database packag= e. Another application is network management. Every network management syst= em needs some kind of topology representation. Finally, though I am not an = expert in PCE construction, it would seem to me that a PCE would need some = kind of topology representation in order to perform path calculations. Havi= ng a way,for example, for the OpenFlow controller and the PCE to exchange t= opology information would be really useful. I would say to start with phys= ical topology because that is fundamental, but make the format flexible eno= ugh to support=20 virtual topology representation. jak _______________________________________________ irs-discuss mailing list irs-discuss@ietf.org https://www.ietf.org/mailman/listinfo/irs-discuss Return-Path: 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 7BCE621F8B88 for ; Thu, 2 Aug 2012 15:36:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.976 X-Spam-Level: X-Spam-Status: No, score=-5.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6h+F5J5IL8sf for ; Thu, 2 Aug 2012 15:36:03 -0700 (PDT) Received: from exprod7og111.obsmtp.com (exprod7og111.obsmtp.com [64.18.2.175]) by ietfa.amsl.com (Postfix) with SMTP id 40C6C21F8B6F for ; Thu, 2 Aug 2012 15:36:01 -0700 (PDT) Received: from mail-yw0-f52.google.com ([209.85.213.52]) (using TLSv1) by exprod7ob111.postini.com ([64.18.6.12]) with SMTP ID DSNKUBsA0HRJpbE+XRKOUN+m5Et14uh0iI1i@postini.com; Thu, 02 Aug 2012 15:36:01 PDT Received: by mail-yw0-f52.google.com with SMTP id p61so65528yhp.25 for ; Thu, 02 Aug 2012 15:36:00 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=VbNF75kNcxAVkuMJGwXhAeumzPzv8km/Jqud4OhPwcY=; b=JwwBvhtaOSULbu6n5W8PGyR771+hXGHr+5rQFZRulsGJrq0M0rVZ4aPAHDPP6Q6Bvl DWLfkZFnC8glF6n+QFkemfrkkMFEUXpxvD7Nx1fxv4HSaFxgTbUIe4KG+bgniqFGKEr6 9t3sJWUt2VdjKgnGs7bFXYEytgE4/edv42Y76ome5dJ5GufvG90vzVhoapSv00eWFqcf u/Lay3zQe0DpwLcdCF3k6Xz0grTEJKNO7YB6P6bB/8KZncVeKwX1T3dn4ZAOyJRHsYZT Noc9JAmwnJAaNd9/zNgoKj7IUiFuPXJkKHdgB0tuCPV39zTfLW5Reszt2CcvD1MZYGQG X4bw== Received: by 10.101.6.24 with SMTP id j24mr7158212ani.5.1343946960666; Thu, 02 Aug 2012 15:36:00 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by mx.google.com with ESMTPS id v8sm13173229yhi.15.2012.08.02.15.35.59 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 02 Aug 2012 15:36:00 -0700 (PDT) Received: by yhq56 with SMTP id 56so60961yhq.31 for ; Thu, 02 Aug 2012 15:35:59 -0700 (PDT) Received: by 10.42.119.76 with SMTP id a12mr385336icr.2.1343946959547; Thu, 02 Aug 2012 15:35:59 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.11.225 with HTTP; Thu, 2 Aug 2012 15:35:19 -0700 (PDT) In-Reply-To: <443803C3-E36B-48C1-947D-8AEB19BE94C1@gmail.com> References: <632FAE8B-8CC5-4701-BB42-1C4EACE372D5@gmail.com> <443803C3-E36B-48C1-947D-8AEB19BE94C1@gmail.com> From: Ping Pan Date: Thu, 2 Aug 2012 15:35:19 -0700 Message-ID: To: Pedro Roque Marques Content-Type: multipart/alternative; boundary=20cf30223d5d1eede204c65009d3 X-Gm-Message-State: ALoCoQkyjRG6+PAgdxoC7vJuuhv/xWhAcDxmAbardnuDN2MOoY+ZlYSNFKmnPztXDKhvVtRCiCWD Cc: irs-discuss@ietf.org Subject: Re: [irs-discuss] if-map example X-BeenThere: irs-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2012 22:36:04 -0000 --20cf30223d5d1eede204c65009d3 Content-Type: text/plain; charset=UTF-8 And this can be extended to apply more than L3VPN... On Thu, Aug 2, 2012 at 3:18 PM, Pedro Roque Marques < pedro.r.marques@gmail.com> wrote: > As an additional example, the following document describes a schema that > can be used to provision a VPN (which is implemented by many PEs as > individual VRFs). > http://datatracker.ietf.org/doc/draft-marques-l3vpn-schema > > The document is still in its early stages. > > The problems that can be solved by such a schema is to be able to, for > instance: > 1) Query the MAP database for all PEs where a specific VPN is present. > 2) Ensure that the VRFs associated with a specific VPN consistently > implement the same policy. > > These are both examples of functionality that spans the network rather > than be localized to a specific router/switch/appliance. > > > On Aug 2, 2012, at 2:32 PM, Ping Pan wrote: > > After playing around with a bunch of other schemes, this indeed is one of > the better ones to use as the base. > > Ping > > On Thu, Aug 2, 2012 at 11:07 AM, Pedro Roque Marques < > pedro.r.marques@gmail.com> wrote: > >> As i pointed out in the RT area meeting, i believe that IF-MAP is a >> successful example of what can be achieved by network-wide schemas (vs >> network element schemas). >> >> The current spec is at: >> >> http://www.trustedcomputinggroup.org/files/resource_files/2888CAD9-1A4B-B294-D0ED95712B121FEF/TNC_IFMAP_v2_1r15.pdf >> >> if-map.org has lots of material on the use cases. >> >> As per my comment on the mic, i'd like to encourage the IRS to focus on >> data schemas that describe network state. >> >> thank you, >> Pedro. >> _______________________________________________ >> irs-discuss mailing list >> irs-discuss@ietf.org >> https://www.ietf.org/mailman/listinfo/irs-discuss >> > > > --20cf30223d5d1eede204c65009d3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable And this can be extended to apply more than L3VPN...

On Thu, Aug 2, 2012 at 3:18 PM, Pedro Roque Marques <pedro.r.marques@gmail.com> wrote:
As = an additional example, the following document describes a schema that can b= e used to provision a VPN (which is implemented by many PEs as individual V= RFs).
http://datatracker.ietf.org/doc/draft-marques-l3vpn-schema

The document is still in its early stages.

The problems that can be solved by such a schema is to be able t= o, for instance:
1) Query the MAP database for all PEs where a sp= ecific VPN is present.
2) Ensure that the VRFs associated with a = specific VPN consistently implement the same policy.

These are both examples of functionality that spans the= network rather than be localized to a specific router/switch/appliance.


On Aug 2, 2012, at 2:32 PM, Ping= Pan wrote:

After playing around with a bunch of other sc= hemes, this indeed is one of the better ones to use as the base.

--20cf30223d5d1eede204c65009d3-- Return-Path: 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 A4F0F21E8090 for ; Thu, 2 Aug 2012 15:32:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.148 X-Spam-Level: X-Spam-Status: No, score=-6.148 tagged_above=-999 required=5 tests=[AWL=-0.149, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U80M5ssBrqRz for ; Thu, 2 Aug 2012 15:32:50 -0700 (PDT) Received: from exprod7og106.obsmtp.com (exprod7og106.obsmtp.com [64.18.2.165]) by ietfa.amsl.com (Postfix) with ESMTP id BE07821F88D0 for ; Thu, 2 Aug 2012 15:32:49 -0700 (PDT) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob106.postini.com ([64.18.6.12]) with SMTP ID DSNKUBsADhZQhPOMSxNgFepv9iIWO/V09VLh@postini.com; Thu, 02 Aug 2012 15:32:49 PDT Received: from P-CLDFE02-HQ.jnpr.net (172.24.192.60) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server (TLS) id 8.3.213.0; Thu, 2 Aug 2012 15:31:43 -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; Thu, 2 Aug 2012 15:31:42 -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; Thu, 2 Aug 2012 18:31:41 -0400 From: Thomas Nadeau To: James Kempf , "irs-discuss@ietf.org" Date: Thu, 2 Aug 2012 18:31:39 -0400 Thread-Topic: [irs-discuss] Suggestions for IRS Way Forward Thread-Index: Ac1w/pYI59DZzyFrQpK27UZd91PG0Q== Message-ID: In-Reply-To: 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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [irs-discuss] Suggestions for IRS Way Forward X-BeenThere: irs-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2012 22:32:50 -0000 I agree that one of the top work items for this effort should be a standardized topology function, and one that is accessible via a non-routing protocol. While not exactly "low hanging fruit", it is something that (to me) is a clear work item with clear goals that should be tackled straight away. --Tom On 8/2/12 3:24 PM, "James Kempf" wrote: >So after seeing part of Alia's talk this morning (I had to leave in the >middle unfortunately), I'd like to make a couple suggestions. There were >a lot of ideas presented in the talk, enough for an entire IETF Area. I >think to make tangible progress, the work needs to be focussed on a small >subset that would be of immediate interest and usability. > >There are a couple areas that suggest themselves, but one that would be >useful in work that I've been involved in is a standardized format for >network topology representation and a protocol for exchanging it. The >Onix OpenFlow controller has a network information base with a >specialized format for network topology, and every OpenFlow controller >requires this. Having a standardized way to represent it might foster a >common topology database package. Another application is network >management. Every network management system needs some kind of topology >representation. Finally, though I am not an expert in PCE construction, >it would seem to me that a PCE would need some kind of topology >representation in order to perform path calculations. Having a way,for >example, for the OpenFlow controller and the PCE to exchange topology >information would be really useful. I would say to start with physical >topology because that is fundamental, but make the format flexible enough >to support=20 > virtual topology representation. > > jak >_______________________________________________ >irs-discuss mailing list >irs-discuss@ietf.org >https://www.ietf.org/mailman/listinfo/irs-discuss Return-Path: 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 A1F2A11E8176 for ; Thu, 2 Aug 2012 15:29:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p9nJJvhA2xbv for ; Thu, 2 Aug 2012 15:29:48 -0700 (PDT) Received: from mail-gg0-f172.google.com (mail-gg0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 5280D11E80E1 for ; Thu, 2 Aug 2012 15:29:48 -0700 (PDT) Received: by ggnc4 with SMTP id c4so62699ggn.31 for ; Thu, 02 Aug 2012 15:29:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=24aIJ/dvqKJLT5Z8e59HZ/ZeQRXlIByx62Rp+v02Nqo=; b=mphe0Rt+JqDzWy/jjpXQwJ9CzRwdfR25fwjcIP1Hb7L0vEG/USPRdTW1WO+84N2/fp H5DtUgPR6Cf50qCA7qOR79Ktpdi0VSuO0nKwB8DqfoXt2h8gAIgFcvK2EGnrUbmyJjat AuP8OR/pe61r64TlEyOYSIvhlOtTRJaAVZa3bRd9IiLuFOtQqwtWfUABuHTSotKEKVz2 h3NzKllt1CKkIilebI2otIn0aAun/8jHjsS7w6ZmUOa8rRTM1CQ5UlwPnsG113igPLFh f3R/uXZ8ZghMWab6gTM2xSvw1qucTk06ZNZSpv933IMrh9XnIPzc6vrzu+s6fHLE78EG J6lA== MIME-Version: 1.0 Received: by 10.50.104.228 with SMTP id gh4mr6209982igb.71.1343946587321; Thu, 02 Aug 2012 15:29:47 -0700 (PDT) Received: by 10.50.34.169 with HTTP; Thu, 2 Aug 2012 15:29:47 -0700 (PDT) In-Reply-To: References: Date: Thu, 2 Aug 2012 18:29:47 -0400 Message-ID: From: Alia Atlas To: James Kempf Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "irs-discuss@ietf.org" Subject: Re: [irs-discuss] Suggestions for IRS Way Forward X-BeenThere: irs-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2012 22:29:49 -0000 James, Thanks for the feedback. I certainly agree that the topology data-model should be an early focus and deliverable. At the end of my talk this morning, I did try to describe how to scope the work so as to keep it within reasonable bounds to make work. A way of focusing the work, I think, is to discuss and agree on a few key use-cases that we want to facilitate. I fully expect that at least one of those use-cases will depend on the topology data-model. Alia On Thu, Aug 2, 2012 at 6:24 PM, James Kempf wrot= e: > So after seeing part of Alia's talk this morning (I had to leave in the m= iddle unfortunately), I'd like to make a couple suggestions. There were a l= ot of ideas presented in the talk, enough for an entire IETF Area. I think = to make tangible progress, the work needs to be focussed on a small subset = that would be of immediate interest and usability. > > There are a couple areas that suggest themselves, but one that would be u= seful in work that I've been involved in is a standardized format for netwo= rk topology representation and a protocol for exchanging it. The Onix OpenF= low controller has a network information base with a specialized format for= network topology, and every OpenFlow controller requires this. Having a st= andardized way to represent it might foster a common topology database pack= age. Another application is network management. Every network management sy= stem needs some kind of topology representation. Finally, though I am not a= n expert in PCE construction, it would seem to me that a PCE would need som= e kind of topology representation in order to perform path calculations. Ha= ving a way,for example, for the OpenFlow controller and the PCE to exchange= topology information would be really useful. I would say to start with ph= ysical topology because that is fundamental, but make the format flexible e= nough to support > virtual topology representation. > > jak > _______________________________________________ > irs-discuss mailing list > irs-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/irs-discuss Return-Path: 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 787B511E8105 for ; Thu, 2 Aug 2012 15:24:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.926 X-Spam-Level: X-Spam-Status: No, score=-5.926 tagged_above=-999 required=5 tests=[AWL=0.073, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8-yPeKYsnosI for ; Thu, 2 Aug 2012 15:24:59 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id DACFD11E813F for ; Thu, 2 Aug 2012 15:24:58 -0700 (PDT) Received: from eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id q72MOuqi022929 for ; Thu, 2 Aug 2012 17:24:58 -0500 Received: from EUSAACMS0703.eamcs.ericsson.se ([169.254.1.135]) by eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) with mapi; Thu, 2 Aug 2012 18:24:55 -0400 From: James Kempf To: "irs-discuss@ietf.org" Date: Thu, 2 Aug 2012 18:24:54 -0400 Thread-Topic: Suggestions for IRS Way Forward Thread-Index: Ac1w/aRFxquJYy0LSJCFfpb4MILleg== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [irs-discuss] Suggestions for IRS Way Forward X-BeenThere: irs-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2012 22:24:59 -0000 So after seeing part of Alia's talk this morning (I had to leave in the mid= dle unfortunately), I'd like to make a couple suggestions. There were a lot= of ideas presented in the talk, enough for an entire IETF Area. I think to= make tangible progress, the work needs to be focussed on a small subset th= at would be of immediate interest and usability.=20 There are a couple areas that suggest themselves, but one that would be use= ful in work that I've been involved in is a standardized format for network= topology representation and a protocol for exchanging it. The Onix OpenFlo= w controller has a network information base with a specialized format for n= etwork topology, and every OpenFlow controller requires this. Having a stan= dardized way to represent it might foster a common topology database packag= e. Another application is network management. Every network management syst= em needs some kind of topology representation. Finally, though I am not an = expert in PCE construction, it would seem to me that a PCE would need some = kind of topology representation in order to perform path calculations. Havi= ng a way,for example, for the OpenFlow controller and the PCE to exchange t= opology information would be really useful. I would say to start with phys= ical topology because that is fundamental, but make the format flexible eno= ugh to support virtual topology representation. jak= Return-Path: 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 EEA7121E80C9 for ; Thu, 2 Aug 2012 15:18:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IGfhPsdXtEsf for ; Thu, 2 Aug 2012 15:18:43 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 09ABC21E80CA for ; Thu, 2 Aug 2012 15:18:42 -0700 (PDT) Received: by yenq13 with SMTP id q13so52338yen.31 for ; Thu, 02 Aug 2012 15:18:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer; bh=YRHSuZEUxRsQwU1ZsLST4wMcjMdm5bol+0fZ20Wy66E=; b=eItGidbbCXOtZmDUsuZTQxyIqXsjiAyrrLbBj4U4BvANSaWWeF88/z4Z6ZuJMA6iU0 1OTOZQ6Ah323nHVZtV5bQcJ2AHoNRzUrCktYzjodhBu6Rave0PNhxW60iTyG3aTaY/K8 ltYtq6VS/XOr//734jmJWp95jepNadmp2YBVZK21AvlSJ/ceXSrrV0pu4nsE9m/qHi0m 9ZY7zkm8ST5Uvexnps2mjNl8XIZ+u15/KyiQLSPW//rCjAGTf03pYFgpUxQeJoJUn2KA qotTzDUl3yUdx8qBenZS7QorhmHiGDDvCvb4fzNpzEsFqFUmzF750r4Qim5NAMBktaf3 9mAA== Received: by 10.50.188.201 with SMTP id gc9mr6309962igc.44.1343945922061; Thu, 02 Aug 2012 15:18:42 -0700 (PDT) Received: from ?IPv6:2001:df8::16:34c3:251a:4e51:754e? ([2001:df8:0:16:34c3:251a:4e51:754e]) by mx.google.com with ESMTPS id c3sm16247191iga.8.2012.08.02.15.18.40 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 02 Aug 2012 15:18:41 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: multipart/alternative; boundary="Apple-Mail=_CA5C9F41-5E30-475F-99B1-B04343980483" From: Pedro Roque Marques In-Reply-To: Date: Thu, 2 Aug 2012 15:18:48 -0700 Message-Id: <443803C3-E36B-48C1-947D-8AEB19BE94C1@gmail.com> References: <632FAE8B-8CC5-4701-BB42-1C4EACE372D5@gmail.com> To: Ping Pan X-Mailer: Apple Mail (2.1278) Cc: irs-discuss@ietf.org Subject: Re: [irs-discuss] if-map example X-BeenThere: irs-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2012 22:18:44 -0000 --Apple-Mail=_CA5C9F41-5E30-475F-99B1-B04343980483 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii As an additional example, the following document describes a schema that = can be used to provision a VPN (which is implemented by many PEs as = individual VRFs). http://datatracker.ietf.org/doc/draft-marques-l3vpn-schema The document is still in its early stages. The problems that can be solved by such a schema is to be able to, for = instance: 1) Query the MAP database for all PEs where a specific VPN is present. 2) Ensure that the VRFs associated with a specific VPN consistently = implement the same policy. These are both examples of functionality that spans the network rather = than be localized to a specific router/switch/appliance. On Aug 2, 2012, at 2:32 PM, Ping Pan wrote: > After playing around with a bunch of other schemes, this indeed is one = of the better ones to use as the base. >=20 > Ping >=20 > On Thu, Aug 2, 2012 at 11:07 AM, Pedro Roque Marques = wrote: > As i pointed out in the RT area meeting, i believe that IF-MAP is a = successful example of what can be achieved by network-wide schemas (vs = network element schemas). >=20 > The current spec is at: > = http://www.trustedcomputinggroup.org/files/resource_files/2888CAD9-1A4B-B2= 94-D0ED95712B121FEF/TNC_IFMAP_v2_1r15.pdf >=20 > if-map.org has lots of material on the use cases. >=20 > As per my comment on the mic, i'd like to encourage the IRS to focus = on data schemas that describe network state. >=20 > thank you, > Pedro. > _______________________________________________ > irs-discuss mailing list > irs-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/irs-discuss >=20 --Apple-Mail=_CA5C9F41-5E30-475F-99B1-B04343980483 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii http:/= /datatracker.ietf.org/doc/draft-marques-l3vpn-schema

The document is still in its early = stages.

The problems that can be solved by such = a schema is to be able to, for instance:
1) Query the MAP = database for all PEs where a specific VPN is present.
2) = Ensure that the VRFs associated with a specific VPN consistently = implement the same policy.

These are both = examples of functionality that spans the network rather than be = localized to a specific = router/switch/appliance.

On Aug 2, 2012, at 2:32 = PM, Ping Pan wrote:

After = playing around with a bunch of other schemes, this indeed is one of the = better ones to use as the base.

Ping

On Thu, Aug 2, 2012 at 11:07 AM, Pedro Roque = Marques <pedro.r.marques@gmail.com> wrote:
As i pointed out in = the RT area meeting, i believe that IF-MAP is a successful example of = what can be achieved by network-wide schemas (vs network element = schemas).

The current spec is at:
http://www.trustedcomputinggroup.org/files/resource_file= s/2888CAD9-1A4B-B294-D0ED95712B121FEF/TNC_IFMAP_v2_1r15.pdf

if-map.org has lots = of material on the use cases.

As per my comment on the mic, i'd like to encourage the IRS to focus on = data schemas that describe network state.

thank you,
  Pedro.
_______________________________________________
irs-discuss mailing list
irs-discuss@ietf.org
https://www.ietf.org/mailman/listinfo/irs-discuss


= --Apple-Mail=_CA5C9F41-5E30-475F-99B1-B04343980483-- Return-Path: 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 CFB9C11E80F5 for ; Thu, 2 Aug 2012 14:33:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.976 X-Spam-Level: X-Spam-Status: No, score=-5.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cj-c2-H3RnEb for ; Thu, 2 Aug 2012 14:33:43 -0700 (PDT) Received: from exprod7og106.obsmtp.com (exprod7og106.obsmtp.com [64.18.2.165]) by ietfa.amsl.com (Postfix) with SMTP id 9164E11E80A2 for ; Thu, 2 Aug 2012 14:33:42 -0700 (PDT) Received: from mail-yx0-f174.google.com ([209.85.213.174]) (using TLSv1) by exprod7ob106.postini.com ([64.18.6.12]) with SMTP ID DSNKUBryNpCmjhrRLB9m+ykg59nEiVq3ZXBZ@postini.com; Thu, 02 Aug 2012 14:33:42 PDT Received: by yenl2 with SMTP id l2so4274yen.33 for ; Thu, 02 Aug 2012 14:33:41 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=VhGU4yVPrQsgp1DgVku+/nUq5+CAhXrk18kVAwi2JMk=; b=Wnlde1bKD+diJ806uBTtbv42BK6xkr/cZUZg2DkMc4i2AafX48GA43TCPaw3iDLG60 QdcF44QlCzC6lkMKP+EnQgQ/y029VfkM7Jb+QKezz4fzsEcFmuUFrToHpIST/zfc1o+x R+E4azc+6+Wx79CwsbbW0iEWOz/Sog7j0Va9iR6afrgbdgda5pg6mWJfwX1hA9CBuF+1 Ax3aO+U5+xN4/PoryBTD6VotbT7yVTRme/x9C/tBHhy1HnL5wJtieTuncCU4I4JQghq4 /aQtzlc9jBLAhP2bealCLpbux2S2Spzxp0HI/46pBZmgZsJsPseLIAYIWXjtwvBxOII1 mN9A== Received: by 10.101.139.5 with SMTP id r5mr7078164ann.37.1343943221402; Thu, 02 Aug 2012 14:33:41 -0700 (PDT) Received: from mail-gh0-f172.google.com (mail-gh0-f172.google.com [209.85.160.172]) by mx.google.com with ESMTPS id j10sm6643093anl.20.2012.08.02.14.33.40 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 02 Aug 2012 14:33:40 -0700 (PDT) Received: by ghbg16 with SMTP id g16so2353ghb.31 for ; Thu, 02 Aug 2012 14:33:39 -0700 (PDT) Received: by 10.50.94.196 with SMTP id de4mr6200847igb.17.1343943219383; Thu, 02 Aug 2012 14:33:39 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.11.225 with HTTP; Thu, 2 Aug 2012 14:32:59 -0700 (PDT) In-Reply-To: <632FAE8B-8CC5-4701-BB42-1C4EACE372D5@gmail.com> References: <632FAE8B-8CC5-4701-BB42-1C4EACE372D5@gmail.com> From: Ping Pan Date: Thu, 2 Aug 2012 14:32:59 -0700 Message-ID: To: Pedro Roque Marques Content-Type: multipart/alternative; boundary=e89a8f234c07308de804c64f2a2f X-Gm-Message-State: ALoCoQk96dZ8a0iYNa86YQH9P2Sm1/p6Mqe/SmzOOmFh1sJ1UQJqJFjdXQ7g/cXdlft0CNX7IFwT Cc: irs-discuss@ietf.org Subject: Re: [irs-discuss] if-map example X-BeenThere: irs-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2012 21:33:44 -0000 --e89a8f234c07308de804c64f2a2f Content-Type: text/plain; charset=UTF-8 After playing around with a bunch of other schemes, this indeed is one of the better ones to use as the base. Ping On Thu, Aug 2, 2012 at 11:07 AM, Pedro Roque Marques < pedro.r.marques@gmail.com> wrote: > As i pointed out in the RT area meeting, i believe that IF-MAP is a > successful example of what can be achieved by network-wide schemas (vs > network element schemas). > > The current spec is at: > > http://www.trustedcomputinggroup.org/files/resource_files/2888CAD9-1A4B-B294-D0ED95712B121FEF/TNC_IFMAP_v2_1r15.pdf > > if-map.org has lots of material on the use cases. > > As per my comment on the mic, i'd like to encourage the IRS to focus on > data schemas that describe network state. > > thank you, > Pedro. > _______________________________________________ > irs-discuss mailing list > irs-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/irs-discuss > --e89a8f234c07308de804c64f2a2f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable After playing around with a bunch of other schemes, this indeed is one of t= he better ones to use as the base.

Ping

On Thu, Aug 2, 2012 at 11:07 AM, Pedro Roque Marques <pedro.r.marques@gmail.com> wrote:
As i pointed out in the RT area meeting, i b= elieve that IF-MAP is a successful example of what can be achieved by netwo= rk-wide schemas (vs network element schemas).

The current spec is at:
http= ://www.trustedcomputinggroup.org/files/resource_files/2888CAD9-1A4B-B294-D0= ED95712B121FEF/TNC_IFMAP_v2_1r15.pdf

if-map.org has lots of = material on the use cases.

As per my comment on the mic, i'd like to encourage the IRS to focus on= data schemas that describe network state.

thank you,
=C2=A0 Pedro.
_______________________________________________
irs-discuss mailing list
irs-discuss@ietf.org
https://www.ietf.org/mailman/listinfo/irs-discuss

--e89a8f234c07308de804c64f2a2f-- Return-Path: 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 3CB9811E8125 for ; Thu, 2 Aug 2012 13:23:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.441 X-Spam-Level: X-Spam-Status: No, score=-6.441 tagged_above=-999 required=5 tests=[AWL=0.158, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yO+NGw2x7B3Y for ; Thu, 2 Aug 2012 13:22:59 -0700 (PDT) Received: from exprod7og122.obsmtp.com (exprod7og122.obsmtp.com [64.18.2.22]) by ietfa.amsl.com (Postfix) with ESMTP id 3359511E8072 for ; Thu, 2 Aug 2012 13:22:59 -0700 (PDT) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob122.postini.com ([64.18.6.12]) with SMTP ID DSNKUBrhoiOGIDUf/rKJWGQycmaLVWyMUqer@postini.com; Thu, 02 Aug 2012 13:22:59 PDT Received: from p-emfe02-wf.jnpr.net (172.28.145.25) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server (TLS) id 8.3.213.0; Thu, 2 Aug 2012 13:21:27 -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; Thu, 2 Aug 2012 16:21:26 -0400 From: Thomas Nadeau To: Thomas Nadeau , Ning So , "irs-discuss@ietf.org" Date: Thu, 2 Aug 2012 16:21:16 -0400 Thread-Topic: [irs-discuss] irs-discuss Digest, Vol 2, Issue 3 Thread-Index: Ac1w7GQu+/l0HLoORGGVSUWddxGqhQ== Message-ID: In-Reply-To: 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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [irs-discuss] irs-discuss Digest, Vol 2, Issue 3 X-BeenThere: irs-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2012 20:23:02 -0000 Apologies for the typo: http://www.lucidvision.com/draft-ward-irs-framework-00e.pptx On 8/2/12 1:03 PM, "Thomas Nadeau" wrote: > > Apologies, they appear to not be there. In the meantime, you can >find >them here: > >http://www.lucidvision.com/draft-ward-irs-framework-00d.ppt > > >On 8/2/12 11:23 AM, "Thomas Nadeau" wrote: > >>They are at the bottom of the routing area meeting page: >> >>https://datatracker.ietf.org/meeting/84/agenda/rtgarea/ >> >>From: Ning So > >>Reply-To: Ning So > >>Date: Thursday, August 2, 2012 10:46 AM >>To: "irs-discuss@ietf.org" >>> >>Subject: Re: [irs-discuss] irs-discuss Digest, Vol 2, Issue 3 >> >>All, >> >>Is Alia's presentation loaded anywhere? It's not on the meeting agenda >>page. >> >>Ning >> >>From: "irs-discuss-request@ietf.org" >>> >>To: irs-discuss@ietf.org >>Sent: Thursday, August 2, 2012 1:20 AM >>Subject: irs-discuss Digest, Vol 2, Issue 3 >> >>----- Forwarded Message ----- >> >>If you have received this digest without all the individual message >>attachments you will need to update your digest options in your list >>subscription. To do so, go to >> >>https://www.ietf.org/mailman/listinfo/irs-discuss >> >>Click the 'Unsubscribe or edit options' button, log in, and set "Get >>MIME or Plain Text Digests?" to MIME. You can set this option >>globally for all the list digests you receive at this point. >> >> >> >>Send irs-discuss mailing list submissions to >> irs-discuss@ietf.org >> >>To subscribe or unsubscribe via the World Wide Web, visit >> https://www.ietf.org/mailman/listinfo/irs-discuss >>or, via email, send a message with subject or body 'help' to >> irs-discuss-request@ietf.org >> >>You can reach the person managing the list at >> irs-discuss-owner@ietf.org >> >>When replying, please edit your Subject line so it is more specific >>than "Re: Contents of irs-discuss digest..." >> >>Today's Topics: >> >> 1. Re: I-D Action: draft-ward-irs-framework-00.txt (Alia Atlas) >> 2. Re: I-D Action: draft-ward-irs-framework-00.txt (Joel M. Halpern) >> 3. Re: IRS Problem Statement Posted (Susan Hares) >> 4. Re: Thoughts on draft-ward-irs-framework (Russ White) >>Thanks! >> >>On Wed, Aug 1, 2012 at 6:54 PM, Susan Hares >>> wrote: >>> Alia: >>> >>> I'll try to create a bibliography of things people should read. It >>>will be mid-next week since I'm away from my home library on the SDN >>>topic. >>> >>> Sue >>> >>> -----Original Message----- >>> From: Alia Atlas [mailto:akatlas@gmail.com] >>> Sent: Wednesday, August 01, 2012 3:51 PM >>> To: Susan Hares >>> Cc: Joel M. Halpern; irs-discuss@ietf.org >>> Subject: Re: [irs-discuss] I-D Action: draft-ward-irs-framework-00.txt >>> >>> Sue, >>> >>> I look forward to talking with you more off-line on the policy and >>> local-pref research and issues. If you have suggestions on good >>> background research to read, by all means send it to the list so >>> others can get up to speed as well. >>> >>> On the atomic transaction semantics question, let's get a bit further >>> into the use-cases and framework - and then have a focused discussion. >>> I'm not opposed to it forever or if it is necessary - just would like >>> to thoroughly analyze if it is a real requirement. >>> >>> Do others have opinions and perspective on this? >>> >>> Alia >>> >>> On Wed, Aug 1, 2012 at 1:58 PM, Susan Hares >>>> wrote: >>>> Alia: >>>> >>>> The hierarchical of interfaces (To routing system) is one of the areas >>>>that requires prioritization. The prioritization must be able to handle >>>>"preempt me", "after you", and "after me". >>>> >>>> It is also key to understand that irs system must handle >>>>multi-interfaces struggles at the lowest layer. You need to look at >>>>the MIF WG (+/-) for some of the struggles of mobility. >>>> >>>> -----Original Message----- >>>> From: Alia Atlas [mailto:akatlas@gmail.com] >>>> Sent: Monday, July 30, 2012 6:33 PM >>>> To: Susan Hares >>>> Cc: Joel M. Halpern; irs-discuss@ietf.org >>>> Subject: Re: [irs-discuss] I-D Action: draft-ward-irs-framework-00.txt >>>> >>>> Hi Sue, >>>> >>>> On Mon, Jul 30, 2012 at 9:16 PM, Susan Hares >>>>> wrote: >>>>> Joel and irs-folks: >>>>> >>>>> +1 on Joel. >>>>> >>>>> Beyond your comments, the requirement prioritization of the >>>>>interworking of these interfaces is not clearly delineated in this >>>>>work. This type of prioritization and sequencing is key to >>>>>multi-interfaces operation on the monitoring, configuration or >>>>>insertion of information into the depth. >>>> >>>> [Alia] Can you further clarify, maybe with an example, which aspect >>>> you are thinking of? Do you mean the ability of an application to >>>> access multiple sub-interfaces? The interaction of operations >>>> requested by differerent applications? >>>> >>>>> In addition, if you are going to do configuration with >>>>>roll-forward/roll-back - you need a transaction based processing. >>>> >>>> [Alia] I'm pretty sure that I avoided the word "transaction" in both >>>> drafts. That was deliberate. Of course, we can have a discussion >>>> about whether or not some form of transactions might be desirable. I >>>> am concerned about their potentially heavy-weight nature. >>>> >>>>> Therefore, you've skipped even requiring the hard problems. >>>> >>>> [Alia] Can I optimistically pretend that means that the requirements >>>> we do have don't seem too hard? For the responsiveness and throughput >>>> goals, I've put a stake in the ground to avoid transaction-based >>>> semantics. Naturally, the hordes can run over that stake, if >>>> necessary. >>>> >>>> [Sue]: The requirements are necessary even if they are hard. >>>> >>>> [Alia] For the interaction between different layers of sub-interfaces, >>>> I've been assuming that we'll define the interactions between the >>>> layers based on how they are generally done. For instance, perhaps we >>>> standardize the idea of preference value - and then the RIB can pick >>>> the best route based upon those preferences. For interaction between >>>> different applications, I think there's a mixture of >>>> authorization/authentication to get right plus a good set of events >>>> that an application could register for. >>>> >>>> [Sue]: As someone who has lived with "local pref" in BGP for a long >>>>time, there is a bit more to unwrap in the statement. However, it >>>>breaks down to prioritization that is pre-set by preferences. >>>> >>>> The policy issues behind the local-pref setting have been studied by >>>>the BGP policy community. This is substantial good work on this from >>>>the academic researchers, vendors, and operator. Griffins, Rexford, >>>>Bush, Feamster, ..... and lots others are much better on the theory >>>>than I am. >>>> >>>>> Is this just the -00.draft? >>>> >>>> [Alia] Certainly, I expect that we'll uncover more requirements as we >>>> go along. As I said, some of this is initially setting parts out of >>>> scope. >>>> >>>> ---> Scope =3D=3D good. Setting scope allows us to pick a piece of th= is >>>>work and standardize it for interoperability. >>>> >>>> Alia >>>> >>>>> Sue >>>>> >>>>> >>>>> >>>>> -----Original Message----- >>>>> From: >>>>>irs-discuss-bounces@ietf.org >>>>>[mailto:irs-discuss-bounces@ietf.org>>>>r >>>>>g>] On Behalf Of Joel M. Halpern >>>>> Sent: Monday, July 30, 2012 3:15 PM >>>>> To: irs-discuss@ietf.org >>>>> Subject: Re: [irs-discuss] I-D Action: >>>>>draft-ward-irs-framework-00.txt >>>>> >>>>> I am finding this document quite confusing. >>>>> >>>>> The primary confusion is that the document first says that it is >>>>>about >>>>> information that can not be manipulated with existing systems, and >>>>>then >>>>> proceeds to give a list of use cases all of which can be manipulated >>>>> with existing systems at a suitable degree of abstraction. >>>>> >>>>> As a lesser confusion, the document says that "streaming" is >>>>>important, >>>>> but then describes "streaming" as "fast, interactive access." That >>>>>is >>>>> not streaming. And depending upon what one means by interactive, >>>>>plenty >>>>> of systems provide "fest, interactive access." I realize the >>>>>document >>>>> later goes on tot talk about speed and frequency of state updates. >>>>>But >>>>> that section simply reasserts the earlier terms withotu better >>>>> description or justification. >>>>> >>>>> Yours, >>>>> Joel >>>>> >>>>> On 7/30/2012 2:08 PM, >>>>>internet-drafts@ietf.org wrote: >>>>>> >>>>>> A New Internet-Draft is available from the on-line Internet-Drafts >>>>>>directories. >>>>>> >>>>>> >>>>>> Title : Interface to the Routing System Framework >>>>>> Author(s) : Alia Atlas >>>>>> Thomas Nadeau >>>>>> Dave Ward >>>>>> Filename : draft-ward-irs-framework-00.txt >>>>>> Pages : 21 >>>>>> Date : 2012-07-30 >>>>>> >>>>>> Abstract: >>>>>> This document describes a framework for a standard, programmatic >>>>>> interface for full-duplex, streaming state transfer in and out of >>>>>>the >>>>>> Internet's routing system. It lists the information that might >>>>>>be >>>>>> exchanged over the interface, and describes the uses of an >>>>>>interface >>>>>> to the Internet routing system. >>>>>> >>>>> _______________________________________________ >>>>> 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 >> >>With regard to transaction issues, we discussed this extensively when >>doing ForCES. We concluded that the answer we needed was "yes and no". >> That is, the protocol has mechanisms which can be used for >>transactional integrity, including integrity across interactions with >>multiple FEs. However, the protocol does not require the CE to use >>those mechanisms. In fact, if it does not even want explicit acks (the >>messages go over TCP), it can defer that until it gets to a good "please >>confirm" point. >>And in the efforts to use this later, having this range of options has >>been useful. >> >>Yours, >>Joel >> >>On 8/1/2012 6:51 PM, Alia Atlas wrote: >>> Sue, >>> >>> I look forward to talking with you more off-line on the policy and >>> local-pref research and issues. If you have suggestions on good >>> background research to read, by all means send it to the list so >>> others can get up to speed as well. >>> >>> On the atomic transaction semantics question, let's get a bit further >>> into the use-cases and framework - and then have a focused discussion. >>> I'm not opposed to it forever or if it is necessary - just would like >>> to thoroughly analyze if it is a real requirement. >>> >>> Do others have opinions and perspective on this? >>> >>> Alia >>> >>> On Wed, Aug 1, 2012 at 1:58 PM, Susan Hares >>>> wrote: >>>> Alia: >>>> >>>> The hierarchical of interfaces (To routing system) is one of the areas >>>>that requires prioritization. The prioritization must be able to handle >>>>"preempt me", "after you", and "after me". >>>> >>>> It is also key to understand that irs system must handle >>>>multi-interfaces struggles at the lowest layer. You need to look at >>>>the MIF WG (+/-) for some of the struggles of mobility. >>>> >>>> -----Original Message----- >>>> From: Alia Atlas [mailto:akatlas@gmail.com] >>>> Sent: Monday, July 30, 2012 6:33 PM >>>> To: Susan Hares >>>> Cc: Joel M. Halpern; irs-discuss@ietf.org >>>> Subject: Re: [irs-discuss] I-D Action: draft-ward-irs-framework-00.txt >>>> >>>> Hi Sue, >>>> >>>> On Mon, Jul 30, 2012 at 9:16 PM, Susan Hares >>>>> wrote: >>>>> Joel and irs-folks: >>>>> >>>>> +1 on Joel. >>>>> >>>>> Beyond your comments, the requirement prioritization of the >>>>>interworking of these interfaces is not clearly delineated in this >>>>>work. This type of prioritization and sequencing is key to >>>>>multi-interfaces operation on the monitoring, configuration or >>>>>insertion of information into the depth. >>>> >>>> [Alia] Can you further clarify, maybe with an example, which aspect >>>> you are thinking of? Do you mean the ability of an application to >>>> access multiple sub-interfaces? The interaction of operations >>>> requested by differerent applications? >>>> >>>>> In addition, if you are going to do configuration with >>>>>roll-forward/roll-back - you need a transaction based processing. >>>> >>>> [Alia] I'm pretty sure that I avoided the word "transaction" in both >>>> drafts. That was deliberate. Of course, we can have a discussion >>>> about whether or not some form of transactions might be desirable. I >>>> am concerned about their potentially heavy-weight nature. >>>> >>>>> Therefore, you've skipped even requiring the hard problems. >>>> >>>> [Alia] Can I optimistically pretend that means that the requirements >>>> we do have don't seem too hard? For the responsiveness and throughput >>>> goals, I've put a stake in the ground to avoid transaction-based >>>> semantics. Naturally, the hordes can run over that stake, if >>>> necessary. >>>> >>>> [Sue]: The requirements are necessary even if they are hard. >>>> >>>> [Alia] For the interaction between different layers of sub-interfaces, >>>> I've been assuming that we'll define the interactions between the >>>> layers based on how they are generally done. For instance, perhaps we >>>> standardize the idea of preference value - and then the RIB can pick >>>> the best route based upon those preferences. For interaction between >>>> different applications, I think there's a mixture of >>>> authorization/authentication to get right plus a good set of events >>>> that an application could register for. >>>> >>>> [Sue]: As someone who has lived with "local pref" in BGP for a long >>>>time, there is a bit more to unwrap in the statement. However, it >>>>breaks down to prioritization that is pre-set by preferences. >>>> >>>> The policy issues behind the local-pref setting have been studied by >>>>the BGP policy community. This is substantial good work on this from >>>>the academic researchers, vendors, and operator. Griffins, Rexford, >>>>Bush, Feamster, ..... and lots others are much better on the theory >>>>than I am. >>>> >>>>> Is this just the -00.draft? >>>> >>>> [Alia] Certainly, I expect that we'll uncover more requirements as we >>>> go along. As I said, some of this is initially setting parts out of >>>> scope. >>>> >>>> ---> Scope =3D=3D good. Setting scope allows us to pick a piece of th= is >>>>work and standardize it for interoperability. >>>> >>>> Alia >>>> >>>>> Sue >>>>> >>>>> >>>>> >>>>> -----Original Message----- >>>>> From: >>>>>irs-discuss-bounces@ietf.org >>>>>[mailto:irs-discuss-bounces@ietf.org>>>>r >>>>>g>] On Behalf Of Joel M. Halpern >>>>> Sent: Monday, July 30, 2012 3:15 PM >>>>> To: irs-discuss@ietf.org >>>>> Subject: Re: [irs-discuss] I-D Action: >>>>>draft-ward-irs-framework-00.txt >>>>> >>>>> I am finding this document quite confusing. >>>>> >>>>> The primary confusion is that the document first says that it is >>>>>about >>>>> information that can not be manipulated with existing systems, and >>>>>then >>>>> proceeds to give a list of use cases all of which can be manipulated >>>>> with existing systems at a suitable degree of abstraction. >>>>> >>>>> As a lesser confusion, the document says that "streaming" is >>>>>important, >>>>> but then describes "streaming" as "fast, interactive access." That >>>>>is >>>>> not streaming. And depending upon what one means by interactive, >>>>>plenty >>>>> of systems provide "fest, interactive access." I realize the >>>>>document >>>>> later goes on tot talk about speed and frequency of state updates. >>>>>But >>>>> that section simply reasserts the earlier terms withotu better >>>>> description or justification. >>>>> >>>>> Yours, >>>>> Joel >>>>> >>>>> On 7/30/2012 2:08 PM, >>>>>internet-drafts@ietf.org wrote: >>>>>> >>>>>> A New Internet-Draft is available from the on-line Internet-Drafts >>>>>>directories. >>>>>> >>>>>> >>>>>> Title : Interface to the Routing System Framework >>>>>> Author(s) : Alia Atlas >>>>>> Thomas Nadeau >>>>>> Dave Ward >>>>>> Filename : draft-ward-irs-framework-00.txt >>>>>> Pages : 21 >>>>>> Date : 2012-07-30 >>>>>> >>>>>> Abstract: >>>>>> This document describes a framework for a standard, >>>>>>programmatic >>>>>> interface for full-duplex, streaming state transfer in and out >>>>>>of the >>>>>> Internet's routing system. It lists the information that might >>>>>>be >>>>>> exchanged over the interface, and describes the uses of an >>>>>>interface >>>>>> to the Internet routing system. >>>>>> >>>>> _______________________________________________ >>>>> 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 >>> >> >>Alia: >> >>I'm going to check with a colleague who has been doing lots of model work >>to see if he's got a better. More later. >> >>Sue >> >>-----Original Message----- >>From: Alia Atlas [mailto:akatlas@gmail.com] >>Sent: Wednesday, August 01, 2012 3:41 PM >>To: Susan Hares >>Cc: Nitin Bahadur; James Kempf; Thomas Nadeau; >>irs-discuss@ietf.org >>Subject: Re: [irs-discuss] IRS Problem Statement Posted >> >>Sue, >> >>In this case, I was thinking of "translating" from a "higher >>abstraction layer" to a "lower abstraction layer". >> >>Do you have a better/different term to suggest? I agree that clarity >>of terminology is important. >> >>Alia >> >>On Wed, Aug 1, 2012 at 2:03 PM, Susan Hares >>> wrote: >>> Alia: >>> >>> +1 on abstraction + filters (abstract/detail) IRS fits at the routing >>>control. >>> >>> The real question about translation is what the translation is doing. >>>Is it translating one thing to another at the same layer of abstraction >>>(e.g., Spanish/English, Ascii/ebcdic) or is it doing abstraction/detail >>>change. >>> >>> I define translation as the same layer of abstraction. Some people >>>suggest translation =3D abstract/detailing. We first need a common way = to >>>talk about the difference. >>> >>> Sue >>> >>> By the way --- I'm thrilled about the pace of the discussion. >>> >>> >>> -----Original Message----- >>> From: Alia Atlas [mailto:akatlas@gmail.com] >>> Sent: Monday, July 30, 2012 6:40 PM >>> To: Susan Hares >>> Cc: Nitin Bahadur; James Kempf; Thomas Nadeau; >>>irs-discuss@ietf.org >>> Subject: Re: [irs-discuss] IRS Problem Statement Posted >>> >>> Sue, >>> >>> I certainly agree that we want IRS to have the ability to express >>> information at different abstraction layers and filtered on request. >>> >>> There may still be a gap between the "network OS abstractions" and IRS >>> sub-interfaces; I'd be surprised if there weren't. IRS is to provide >>> the bottom-up control strings. >>> >>> IMHO, it's reasonable to have an entity that manages the translation. >>> For instance, one doesn't need a PCE-equiv in every application - nor >>> in every router; that might be an entity in between. >>> >>> The quantity of information is part of why explicit filtering and >>> hopefully abstraction layers should be built into the data-models. >>> >>> Alia >>> >>> On Mon, Jul 30, 2012 at 9:24 PM, Susan Hares >>>> wrote: >>>> Nitin: >>>> >>>> Exposing some network intelligence can either be done in detail or in >>>>some amount of summarization. >>>> If you are doing detail, you have bandwidth issues. If you are doing >>>>summarization or opacity, you are talking about layers of information. >>>> >>>> Apps need to find out what they need to get. They do not need all the >>>>details - just the fact they can get from point A to Point B (or for >>>>multi-cast B/C/D). They need to where they can go to date other >>>>applications. They need a match-maker for the application who >>>>determine where the applications shall flow. Now, if they are smart - >>>>like people going out to eat - they pick several ways go to eat >>>>traffic. >>>> >>>> The network orchestration then serves to be the paths to the place to >>>>eat. This can either be distributed or centralized. >>>> >>>> If we have an Interface to routing, it need to have a two-layer >>>>concept of exposing information. >>>> >>>> Sue Hares >>>> >>>> -----Original Message----- >>>> From: >>>>irs-discuss-bounces@ietf.org >>>>[mailto:irs-discuss-bounces@ietf.org>>>g >>>>>] On Behalf Of Nitin Bahadur >>>> Sent: Monday, July 30, 2012 3:33 PM >>>> To: James Kempf; Thomas Nadeau; >>>>irs-discuss@ietf.org >>>> Subject: Re: [irs-discuss] IRS Problem Statement Posted >>>> >>>> Hi James, >>>> >>>> This is not about splitting control plane and forwarding plane. It is >>>>about exposing network intelligence in the network elements to an >>>>external controller. >>>> And it is about allowing an external controller to use that >>>>information for enabling network-aware apps. And it is about allowing >>>>apps to influence the >>>> network element's RIB (not the FIB directly). >>>> >>>> Streaming is essential to allow for operations at scale...and avoid a >>>>request/response gated mechanism. >>>> >>>> Hope that helps. >>>> >>>> Thanks >>>> Nitin >>>> >>>> On 7/30/12 3:11 PM, "James Kempf" >>>>> wrote: >>>> >>>> I don't understand why streaming is specified in this draft. And I >>>>don't understand why this draft isn't put in the Forces framework. >>>>Forces is a framework explicitedly designed for device to controller >>>>communication. Its major drawback it that it is a framework with a hole >>>>in the middle, in that there are no specified devices. This draft would >>>>fill that hole. >>>> >>>> I don't think it is necessary to have a problem statement for router >>>>state update. Forces has already established that splitting the control >>>>plane into a separate device is, in some cases, an attractive design >>>>option. So I think this should be submitted to the Forces working >>>>group, or, at least, recast in the Forces framework. >>>> >>>> jak >>>> >>>>> -----Original Message----- >>>>> From: >>>>>irs-discuss-bounces@ietf.org >>>>> >>>>>[mailto:irs-discuss-bounces@ietf.org>>>>r >>>>>g>] On Behalf Of Thomas Nadeau >>>>> Sent: Monday, July 30, 2012 11:18 AM >>>>> To: irs-discuss@ietf.org >>>>> Subject: [irs-discuss] IRS Problem Statement Posted >>>>> >>>>> >>>>> >>>>> Please review and discuss. >>>>> >>>>> Thanks, >>>>> >>>>> Tom, Alia, Ward >>>>> >>>>> >>>>> http://lucidvision.com/draft-atlas-irs-problem-statement-00.txt >>>>> >>>>> >>>>> _______________________________________________ >>>>> 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 >>>> >>>> _______________________________________________ >>>> 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 >> >> >>> Sue: Use cases are key. The clarity of the use cases will guide us. >>>Please send USE cases. >> >>Here are three I just threw together. We can talk about refining these >>tomorrow, if you like... My fingers got tired before my brain did. :-) >> >>Russ >> >>=3D=3D >>Optimized Exit Use Case >> >>Assume you have a network where there are two possible exit points >>towards any set of destinations. The cost of using these links varies by >>time, and the quality of the links is highly variable, but not >>necessarily related to the actual load the local network is putting on >>them (in other words, these are oversubscribed links shared with other >>parallel networks or customers with unpredictable traffic patterns). >>What you'd like to do is to use the lowest cost link until the quality >>of the link reaches a specific level, and then switch to the higher cost >>link. The point at which this link switch might occur may vary based on >>time of day, because the RTO on specific traffic levels varies by the >>time of day as well. >> >>So you have a problem with multiple variables: link quality (apparently >>random from your perspective), link cost (varies by time of day), return >>on investment (varies by time of day). Combined with this you have >>multiple exit points, and you must draw traffic from an inside network >>as efficiently as possible to the best exit point, as determined by >>these various factors. >> >>The only well defined way to resolve this problem is to feed the >>variables to an off router controller, calculate the best exit point on >>some periodic basis, and then feed this information back into the >>routing table. All solutions that can solve this problem today use route >>injection into BGP, static route injection, or some other means to >>direct traffic --difficult and error prone mechanisms. All of these >>solutions also draw traffic only along links between the edge routers >>themselves to put traffic on the best possible outbound link. >> >>With IRS, the best path could be calculated using any number of custom >>written mechanisms, and the routes injected into the right places in the >>network to effect the most efficient drawing of traffic to the best exit >>point. Changes in the network environment could quickly cause traffic to >>be shifted to alternate exit points when circumstances dictate. >> >>=3D=3D >>Denial of Service >> >>FlowSpec is designed to allow an AS to push a filter upstream, with the >>ultimate goal being to block the source of DDoS and other attacks as >>close to the origin of those attacks as possible. There are some >>situations, however, where you would prefer to block an attack at all >>edges, or throughout an entire local network. For instance, you might >>want to block the forwarding of traffic within your network while you >>are pushing FlowSpec updates upstream to block the traffic closer to the >>source, or you might be dealing with an attack originating from multiple >>points within your own network. >> >>While these responses are possible with standard routing, there is a >>strong case to be made that routing information should not be mixed with >>security response information within the routing domain (within an AS). >>Mixing these two types of information can make network management more >>difficult, and slow down the repair of a network during large scale >>failures. It would be simpler to have a single controller in a network >>tied to the various attack detection mechanisms that could directly >>install the correct routing information to pull all attack traffic to a >>central location, or to simply route the traffic to a null interface. >> >>An related use is that of pulling unknown traffic through specific >>devices for analysis. A network operator may not want to drive all >>traffic through traffic analysis devices simply because of cost and >>quality of service degredation. A network operator could use IRS to >>directly modify the routing tables on devices in the path of unknown or >>possibly dangerous flows so this traffic is pulled through the correct >>monitoring and analysis devices. >> >>=3D=3D >>Remote Service Routing >> >>In hub and spoke overlay networks, there is always an issue with >>balancing between the information held in the spoke routing table, >>optimal routing through the network underlying the overlay, and >>mobility. Most solutions in this space use some form of centralized >>route server that acts as a directory of all reachable destinations and >>next hops, a protocol by which spoke devices and this route server >>communicate, and caches at the remote sites. >> >>An IRS solution would use the same elements, but with a different >>control plane. Remote sites would register (or advertise through some >>standard routing protocol, such as BGP), the reachable destinations at >>each site, along with the address of the router (or other device) used >>to reach that destination. These would, as always, be stored in a route >>server (or several redundant route servers) at a central location. >> >>When a remote site sends a set of packets to the central location that >>are eventually destined to some other remote site, the central location >>can forward this traffic, but at the same time simply directly insert >>the correct routing information into the remote site's routing table. If >>the location of the destination changes, the route server can directly >>modify the routing information at the remote site as needed. >>An interesting aspect of this solution is that no new and specialized >>protocols are needed between the remote sites and the centralized route >>server(s). Normal routing protocols can be used to notify the >>centralized route server(s) of modifications in reachability >>information, and the route server(s) can respond as needed, based on >>local algorithms optimized for a particular application or network. For >>instance, short lived flows might be allowed to simply pass through the >>hub site with no reaction, while longer lived flows might warrant a >>specific route to be installed in the remote router. Algorithms can also >>be developed that would optimize traffic flow through the overlay, and >>also to remove routing entries from remote devices when they are no >>longer needed based on far greater intelligence than simple non-use for >>some period of time. >> >>=3D=3D >> >> >>_______________________________________________ >>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 > >_______________________________________________ >irs-discuss mailing list >irs-discuss@ietf.org >https://www.ietf.org/mailman/listinfo/irs-discuss Return-Path: 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 D3DE411E8186 for ; Thu, 2 Aug 2012 13:04:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.433 X-Spam-Level: X-Spam-Status: No, score=-6.433 tagged_above=-999 required=5 tests=[AWL=0.166, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7TNq6oeaFj5U for ; Thu, 2 Aug 2012 13:04:28 -0700 (PDT) Received: from exprod7og114.obsmtp.com (exprod7og114.obsmtp.com [64.18.2.215]) by ietfa.amsl.com (Postfix) with ESMTP id 0BC3211E8118 for ; Thu, 2 Aug 2012 13:04:27 -0700 (PDT) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob114.postini.com ([64.18.6.12]) with SMTP ID DSNKUBrdSuMnni0w+kpZZPR6v39g9mHNNDaf@postini.com; Thu, 02 Aug 2012 13:04:28 PDT Received: from P-CLDFE02-HQ.jnpr.net (172.24.192.60) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server (TLS) id 8.3.213.0; Thu, 2 Aug 2012 13:04:17 -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; Thu, 2 Aug 2012 13:04:15 -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; Thu, 2 Aug 2012 16:03:55 -0400 From: Thomas Nadeau To: Ning So , "irs-discuss@ietf.org" Date: Thu, 2 Aug 2012 16:03:49 -0400 Thread-Topic: [irs-discuss] irs-discuss Digest, Vol 2, Issue 3 Thread-Index: Ac1w6fJXeQP/ldO2QNKpD5Mb4K++3g== Message-ID: In-Reply-To: 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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [irs-discuss] irs-discuss Digest, Vol 2, Issue 3 X-BeenThere: irs-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2012 20:04:31 -0000 Apologies, they appear to not be there. In the meantime, you can f= ind them here: http://www.lucidvision.com/draft-ward-irs-framework-00d.ppt On 8/2/12 11:23 AM, "Thomas Nadeau" wrote: >They are at the bottom of the routing area meeting page: > >https://datatracker.ietf.org/meeting/84/agenda/rtgarea/ > >From: Ning So > >Reply-To: Ning So > >Date: Thursday, August 2, 2012 10:46 AM >To: "irs-discuss@ietf.org" >> >Subject: Re: [irs-discuss] irs-discuss Digest, Vol 2, Issue 3 > >All, > >Is Alia's presentation loaded anywhere? It's not on the meeting agenda >page. > >Ning > >From: "irs-discuss-request@ietf.org" >> >To: irs-discuss@ietf.org >Sent: Thursday, August 2, 2012 1:20 AM >Subject: irs-discuss Digest, Vol 2, Issue 3 > >----- Forwarded Message ----- > >If you have received this digest without all the individual message >attachments you will need to update your digest options in your list >subscription. To do so, go to > >https://www.ietf.org/mailman/listinfo/irs-discuss > >Click the 'Unsubscribe or edit options' button, log in, and set "Get >MIME or Plain Text Digests?" to MIME. You can set this option >globally for all the list digests you receive at this point. > > > >Send irs-discuss mailing list submissions to > irs-discuss@ietf.org > >To subscribe or unsubscribe via the World Wide Web, visit > https://www.ietf.org/mailman/listinfo/irs-discuss >or, via email, send a message with subject or body 'help' to > irs-discuss-request@ietf.org > >You can reach the person managing the list at > irs-discuss-owner@ietf.org > >When replying, please edit your Subject line so it is more specific >than "Re: Contents of irs-discuss digest..." > >Today's Topics: > > 1. Re: I-D Action: draft-ward-irs-framework-00.txt (Alia Atlas) > 2. Re: I-D Action: draft-ward-irs-framework-00.txt (Joel M. Halpern) > 3. Re: IRS Problem Statement Posted (Susan Hares) > 4. Re: Thoughts on draft-ward-irs-framework (Russ White) >Thanks! > >On Wed, Aug 1, 2012 at 6:54 PM, Susan Hares >> wrote: >> Alia: >> >> I'll try to create a bibliography of things people should read. It >>will be mid-next week since I'm away from my home library on the SDN >>topic. >> >> Sue >> >> -----Original Message----- >> From: Alia Atlas [mailto:akatlas@gmail.com] >> Sent: Wednesday, August 01, 2012 3:51 PM >> To: Susan Hares >> Cc: Joel M. Halpern; irs-discuss@ietf.org >> Subject: Re: [irs-discuss] I-D Action: draft-ward-irs-framework-00.txt >> >> Sue, >> >> I look forward to talking with you more off-line on the policy and >> local-pref research and issues. If you have suggestions on good >> background research to read, by all means send it to the list so >> others can get up to speed as well. >> >> On the atomic transaction semantics question, let's get a bit further >> into the use-cases and framework - and then have a focused discussion. >> I'm not opposed to it forever or if it is necessary - just would like >> to thoroughly analyze if it is a real requirement. >> >> Do others have opinions and perspective on this? >> >> Alia >> >> On Wed, Aug 1, 2012 at 1:58 PM, Susan Hares >>> wrote: >>> Alia: >>> >>> The hierarchical of interfaces (To routing system) is one of the areas >>>that requires prioritization. The prioritization must be able to handle >>>"preempt me", "after you", and "after me". >>> >>> It is also key to understand that irs system must handle >>>multi-interfaces struggles at the lowest layer. You need to look at >>>the MIF WG (+/-) for some of the struggles of mobility. >>> >>> -----Original Message----- >>> From: Alia Atlas [mailto:akatlas@gmail.com] >>> Sent: Monday, July 30, 2012 6:33 PM >>> To: Susan Hares >>> Cc: Joel M. Halpern; irs-discuss@ietf.org >>> Subject: Re: [irs-discuss] I-D Action: draft-ward-irs-framework-00.txt >>> >>> Hi Sue, >>> >>> On Mon, Jul 30, 2012 at 9:16 PM, Susan Hares >>>> wrote: >>>> Joel and irs-folks: >>>> >>>> +1 on Joel. >>>> >>>> Beyond your comments, the requirement prioritization of the >>>>interworking of these interfaces is not clearly delineated in this >>>>work. This type of prioritization and sequencing is key to >>>>multi-interfaces operation on the monitoring, configuration or >>>>insertion of information into the depth. >>> >>> [Alia] Can you further clarify, maybe with an example, which aspect >>> you are thinking of? Do you mean the ability of an application to >>> access multiple sub-interfaces? The interaction of operations >>> requested by differerent applications? >>> >>>> In addition, if you are going to do configuration with >>>>roll-forward/roll-back - you need a transaction based processing. >>> >>> [Alia] I'm pretty sure that I avoided the word "transaction" in both >>> drafts. That was deliberate. Of course, we can have a discussion >>> about whether or not some form of transactions might be desirable. I >>> am concerned about their potentially heavy-weight nature. >>> >>>> Therefore, you've skipped even requiring the hard problems. >>> >>> [Alia] Can I optimistically pretend that means that the requirements >>> we do have don't seem too hard? For the responsiveness and throughput >>> goals, I've put a stake in the ground to avoid transaction-based >>> semantics. Naturally, the hordes can run over that stake, if >>> necessary. >>> >>> [Sue]: The requirements are necessary even if they are hard. >>> >>> [Alia] For the interaction between different layers of sub-interfaces, >>> I've been assuming that we'll define the interactions between the >>> layers based on how they are generally done. For instance, perhaps we >>> standardize the idea of preference value - and then the RIB can pick >>> the best route based upon those preferences. For interaction between >>> different applications, I think there's a mixture of >>> authorization/authentication to get right plus a good set of events >>> that an application could register for. >>> >>> [Sue]: As someone who has lived with "local pref" in BGP for a long >>>time, there is a bit more to unwrap in the statement. However, it >>>breaks down to prioritization that is pre-set by preferences. >>> >>> The policy issues behind the local-pref setting have been studied by >>>the BGP policy community. This is substantial good work on this from >>>the academic researchers, vendors, and operator. Griffins, Rexford, >>>Bush, Feamster, ..... and lots others are much better on the theory >>>than I am. >>> >>>> Is this just the -00.draft? >>> >>> [Alia] Certainly, I expect that we'll uncover more requirements as we >>> go along. As I said, some of this is initially setting parts out of >>> scope. >>> >>> ---> Scope =3D=3D good. Setting scope allows us to pick a piece of thi= s >>>work and standardize it for interoperability. >>> >>> Alia >>> >>>> Sue >>>> >>>> >>>> >>>> -----Original Message----- >>>> From: >>>>irs-discuss-bounces@ietf.org >>>>[mailto:irs-discuss-bounces@ietf.org>>>g>] On Behalf Of Joel M. Halpern >>>> Sent: Monday, July 30, 2012 3:15 PM >>>> To: irs-discuss@ietf.org >>>> Subject: Re: [irs-discuss] I-D Action: draft-ward-irs-framework-00.txt >>>> >>>> I am finding this document quite confusing. >>>> >>>> The primary confusion is that the document first says that it is about >>>> information that can not be manipulated with existing systems, and >>>>then >>>> proceeds to give a list of use cases all of which can be manipulated >>>> with existing systems at a suitable degree of abstraction. >>>> >>>> As a lesser confusion, the document says that "streaming" is >>>>important, >>>> but then describes "streaming" as "fast, interactive access." That is >>>> not streaming. And depending upon what one means by interactive, >>>>plenty >>>> of systems provide "fest, interactive access." I realize the document >>>> later goes on tot talk about speed and frequency of state updates. >>>>But >>>> that section simply reasserts the earlier terms withotu better >>>> description or justification. >>>> >>>> Yours, >>>> Joel >>>> >>>> On 7/30/2012 2:08 PM, >>>>internet-drafts@ietf.org wrote: >>>>> >>>>> A New Internet-Draft is available from the on-line Internet-Drafts >>>>>directories. >>>>> >>>>> >>>>> Title : Interface to the Routing System Framework >>>>> Author(s) : Alia Atlas >>>>> Thomas Nadeau >>>>> Dave Ward >>>>> Filename : draft-ward-irs-framework-00.txt >>>>> Pages : 21 >>>>> Date : 2012-07-30 >>>>> >>>>> Abstract: >>>>> This document describes a framework for a standard, programmatic >>>>> interface for full-duplex, streaming state transfer in and out of >>>>>the >>>>> Internet's routing system. It lists the information that might be >>>>> exchanged over the interface, and describes the uses of an >>>>>interface >>>>> to the Internet routing system. >>>>> >>>> _______________________________________________ >>>> 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 > >With regard to transaction issues, we discussed this extensively when >doing ForCES. We concluded that the answer we needed was "yes and no". > That is, the protocol has mechanisms which can be used for >transactional integrity, including integrity across interactions with >multiple FEs. However, the protocol does not require the CE to use >those mechanisms. In fact, if it does not even want explicit acks (the >messages go over TCP), it can defer that until it gets to a good "please >confirm" point. >And in the efforts to use this later, having this range of options has >been useful. > >Yours, >Joel > >On 8/1/2012 6:51 PM, Alia Atlas wrote: >> Sue, >> >> I look forward to talking with you more off-line on the policy and >> local-pref research and issues. If you have suggestions on good >> background research to read, by all means send it to the list so >> others can get up to speed as well. >> >> On the atomic transaction semantics question, let's get a bit further >> into the use-cases and framework - and then have a focused discussion. >> I'm not opposed to it forever or if it is necessary - just would like >> to thoroughly analyze if it is a real requirement. >> >> Do others have opinions and perspective on this? >> >> Alia >> >> On Wed, Aug 1, 2012 at 1:58 PM, Susan Hares >>> wrote: >>> Alia: >>> >>> The hierarchical of interfaces (To routing system) is one of the areas >>>that requires prioritization. The prioritization must be able to handle >>>"preempt me", "after you", and "after me". >>> >>> It is also key to understand that irs system must handle >>>multi-interfaces struggles at the lowest layer. You need to look at >>>the MIF WG (+/-) for some of the struggles of mobility. >>> >>> -----Original Message----- >>> From: Alia Atlas [mailto:akatlas@gmail.com] >>> Sent: Monday, July 30, 2012 6:33 PM >>> To: Susan Hares >>> Cc: Joel M. Halpern; irs-discuss@ietf.org >>> Subject: Re: [irs-discuss] I-D Action: draft-ward-irs-framework-00.txt >>> >>> Hi Sue, >>> >>> On Mon, Jul 30, 2012 at 9:16 PM, Susan Hares >>>> wrote: >>>> Joel and irs-folks: >>>> >>>> +1 on Joel. >>>> >>>> Beyond your comments, the requirement prioritization of the >>>>interworking of these interfaces is not clearly delineated in this >>>>work. This type of prioritization and sequencing is key to >>>>multi-interfaces operation on the monitoring, configuration or >>>>insertion of information into the depth. >>> >>> [Alia] Can you further clarify, maybe with an example, which aspect >>> you are thinking of? Do you mean the ability of an application to >>> access multiple sub-interfaces? The interaction of operations >>> requested by differerent applications? >>> >>>> In addition, if you are going to do configuration with >>>>roll-forward/roll-back - you need a transaction based processing. >>> >>> [Alia] I'm pretty sure that I avoided the word "transaction" in both >>> drafts. That was deliberate. Of course, we can have a discussion >>> about whether or not some form of transactions might be desirable. I >>> am concerned about their potentially heavy-weight nature. >>> >>>> Therefore, you've skipped even requiring the hard problems. >>> >>> [Alia] Can I optimistically pretend that means that the requirements >>> we do have don't seem too hard? For the responsiveness and throughput >>> goals, I've put a stake in the ground to avoid transaction-based >>> semantics. Naturally, the hordes can run over that stake, if >>> necessary. >>> >>> [Sue]: The requirements are necessary even if they are hard. >>> >>> [Alia] For the interaction between different layers of sub-interfaces, >>> I've been assuming that we'll define the interactions between the >>> layers based on how they are generally done. For instance, perhaps we >>> standardize the idea of preference value - and then the RIB can pick >>> the best route based upon those preferences. For interaction between >>> different applications, I think there's a mixture of >>> authorization/authentication to get right plus a good set of events >>> that an application could register for. >>> >>> [Sue]: As someone who has lived with "local pref" in BGP for a long >>>time, there is a bit more to unwrap in the statement. However, it >>>breaks down to prioritization that is pre-set by preferences. >>> >>> The policy issues behind the local-pref setting have been studied by >>>the BGP policy community. This is substantial good work on this from >>>the academic researchers, vendors, and operator. Griffins, Rexford, >>>Bush, Feamster, ..... and lots others are much better on the theory >>>than I am. >>> >>>> Is this just the -00.draft? >>> >>> [Alia] Certainly, I expect that we'll uncover more requirements as we >>> go along. As I said, some of this is initially setting parts out of >>> scope. >>> >>> ---> Scope =3D=3D good. Setting scope allows us to pick a piece of thi= s >>>work and standardize it for interoperability. >>> >>> Alia >>> >>>> Sue >>>> >>>> >>>> >>>> -----Original Message----- >>>> From: >>>>irs-discuss-bounces@ietf.org >>>>[mailto:irs-discuss-bounces@ietf.org>>>g>] On Behalf Of Joel M. Halpern >>>> Sent: Monday, July 30, 2012 3:15 PM >>>> To: irs-discuss@ietf.org >>>> Subject: Re: [irs-discuss] I-D Action: draft-ward-irs-framework-00.txt >>>> >>>> I am finding this document quite confusing. >>>> >>>> The primary confusion is that the document first says that it is about >>>> information that can not be manipulated with existing systems, and >>>>then >>>> proceeds to give a list of use cases all of which can be manipulated >>>> with existing systems at a suitable degree of abstraction. >>>> >>>> As a lesser confusion, the document says that "streaming" is >>>>important, >>>> but then describes "streaming" as "fast, interactive access." That is >>>> not streaming. And depending upon what one means by interactive, >>>>plenty >>>> of systems provide "fest, interactive access." I realize the document >>>> later goes on tot talk about speed and frequency of state updates. >>>>But >>>> that section simply reasserts the earlier terms withotu better >>>> description or justification. >>>> >>>> Yours, >>>> Joel >>>> >>>> On 7/30/2012 2:08 PM, >>>>internet-drafts@ietf.org wrote: >>>>> >>>>> A New Internet-Draft is available from the on-line Internet-Drafts >>>>>directories. >>>>> >>>>> >>>>> Title : Interface to the Routing System Framework >>>>> Author(s) : Alia Atlas >>>>> Thomas Nadeau >>>>> Dave Ward >>>>> Filename : draft-ward-irs-framework-00.txt >>>>> Pages : 21 >>>>> Date : 2012-07-30 >>>>> >>>>> Abstract: >>>>> This document describes a framework for a standard, programmatic >>>>> interface for full-duplex, streaming state transfer in and out >>>>>of the >>>>> Internet's routing system. It lists the information that might >>>>>be >>>>> exchanged over the interface, and describes the uses of an >>>>>interface >>>>> to the Internet routing system. >>>>> >>>> _______________________________________________ >>>> 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 >> > >Alia: > >I'm going to check with a colleague who has been doing lots of model work >to see if he's got a better. More later. > >Sue > >-----Original Message----- >From: Alia Atlas [mailto:akatlas@gmail.com] >Sent: Wednesday, August 01, 2012 3:41 PM >To: Susan Hares >Cc: Nitin Bahadur; James Kempf; Thomas Nadeau; >irs-discuss@ietf.org >Subject: Re: [irs-discuss] IRS Problem Statement Posted > >Sue, > >In this case, I was thinking of "translating" from a "higher >abstraction layer" to a "lower abstraction layer". > >Do you have a better/different term to suggest? I agree that clarity >of terminology is important. > >Alia > >On Wed, Aug 1, 2012 at 2:03 PM, Susan Hares >> wrote: >> Alia: >> >> +1 on abstraction + filters (abstract/detail) IRS fits at the routing >>control. >> >> The real question about translation is what the translation is doing. >>Is it translating one thing to another at the same layer of abstraction >>(e.g., Spanish/English, Ascii/ebcdic) or is it doing abstraction/detail >>change. >> >> I define translation as the same layer of abstraction. Some people >>suggest translation =3D abstract/detailing. We first need a common way t= o >>talk about the difference. >> >> Sue >> >> By the way --- I'm thrilled about the pace of the discussion. >> >> >> -----Original Message----- >> From: Alia Atlas [mailto:akatlas@gmail.com] >> Sent: Monday, July 30, 2012 6:40 PM >> To: Susan Hares >> Cc: Nitin Bahadur; James Kempf; Thomas Nadeau; >>irs-discuss@ietf.org >> Subject: Re: [irs-discuss] IRS Problem Statement Posted >> >> Sue, >> >> I certainly agree that we want IRS to have the ability to express >> information at different abstraction layers and filtered on request. >> >> There may still be a gap between the "network OS abstractions" and IRS >> sub-interfaces; I'd be surprised if there weren't. IRS is to provide >> the bottom-up control strings. >> >> IMHO, it's reasonable to have an entity that manages the translation. >> For instance, one doesn't need a PCE-equiv in every application - nor >> in every router; that might be an entity in between. >> >> The quantity of information is part of why explicit filtering and >> hopefully abstraction layers should be built into the data-models. >> >> Alia >> >> On Mon, Jul 30, 2012 at 9:24 PM, Susan Hares >>> wrote: >>> Nitin: >>> >>> Exposing some network intelligence can either be done in detail or in >>>some amount of summarization. >>> If you are doing detail, you have bandwidth issues. If you are doing >>>summarization or opacity, you are talking about layers of information. >>> >>> Apps need to find out what they need to get. They do not need all the >>>details - just the fact they can get from point A to Point B (or for >>>multi-cast B/C/D). They need to where they can go to date other >>>applications. They need a match-maker for the application who >>>determine where the applications shall flow. Now, if they are smart - >>>like people going out to eat - they pick several ways go to eat traffic. >>> >>> The network orchestration then serves to be the paths to the place to >>>eat. This can either be distributed or centralized. >>> >>> If we have an Interface to routing, it need to have a two-layer >>>concept of exposing information. >>> >>> Sue Hares >>> >>> -----Original Message----- >>> From: >>>irs-discuss-bounces@ietf.org >>>[mailto:irs-discuss-bounces@ietf.org>>>] On Behalf Of Nitin Bahadur >>> Sent: Monday, July 30, 2012 3:33 PM >>> To: James Kempf; Thomas Nadeau; >>>irs-discuss@ietf.org >>> Subject: Re: [irs-discuss] IRS Problem Statement Posted >>> >>> Hi James, >>> >>> This is not about splitting control plane and forwarding plane. It is >>>about exposing network intelligence in the network elements to an >>>external controller. >>> And it is about allowing an external controller to use that >>>information for enabling network-aware apps. And it is about allowing >>>apps to influence the >>> network element's RIB (not the FIB directly). >>> >>> Streaming is essential to allow for operations at scale...and avoid a >>>request/response gated mechanism. >>> >>> Hope that helps. >>> >>> Thanks >>> Nitin >>> >>> On 7/30/12 3:11 PM, "James Kempf" >>>> wrote: >>> >>> I don't understand why streaming is specified in this draft. And I >>>don't understand why this draft isn't put in the Forces framework. >>>Forces is a framework explicitedly designed for device to controller >>>communication. Its major drawback it that it is a framework with a hole >>>in the middle, in that there are no specified devices. This draft would >>>fill that hole. >>> >>> I don't think it is necessary to have a problem statement for router >>>state update. Forces has already established that splitting the control >>>plane into a separate device is, in some cases, an attractive design >>>option. So I think this should be submitted to the Forces working >>>group, or, at least, recast in the Forces framework. >>> >>> jak >>> >>>> -----Original Message----- >>>> From: >>>>irs-discuss-bounces@ietf.org >>>> >>>>[mailto:irs-discuss-bounces@ietf.org>>>g>] On Behalf Of Thomas Nadeau >>>> Sent: Monday, July 30, 2012 11:18 AM >>>> To: irs-discuss@ietf.org >>>> Subject: [irs-discuss] IRS Problem Statement Posted >>>> >>>> >>>> >>>> Please review and discuss. >>>> >>>> Thanks, >>>> >>>> Tom, Alia, Ward >>>> >>>> >>>> http://lucidvision.com/draft-atlas-irs-problem-statement-00.txt >>>> >>>> >>>> _______________________________________________ >>>> 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 >>> >>> _______________________________________________ >>> 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 > > >> Sue: Use cases are key. The clarity of the use cases will guide us. >>Please send USE cases. > >Here are three I just threw together. We can talk about refining these >tomorrow, if you like... My fingers got tired before my brain did. :-) > >Russ > >=3D=3D >Optimized Exit Use Case > >Assume you have a network where there are two possible exit points >towards any set of destinations. The cost of using these links varies by >time, and the quality of the links is highly variable, but not >necessarily related to the actual load the local network is putting on >them (in other words, these are oversubscribed links shared with other >parallel networks or customers with unpredictable traffic patterns). >What you'd like to do is to use the lowest cost link until the quality >of the link reaches a specific level, and then switch to the higher cost >link. The point at which this link switch might occur may vary based on >time of day, because the RTO on specific traffic levels varies by the >time of day as well. > >So you have a problem with multiple variables: link quality (apparently >random from your perspective), link cost (varies by time of day), return >on investment (varies by time of day). Combined with this you have >multiple exit points, and you must draw traffic from an inside network >as efficiently as possible to the best exit point, as determined by >these various factors. > >The only well defined way to resolve this problem is to feed the >variables to an off router controller, calculate the best exit point on >some periodic basis, and then feed this information back into the >routing table. All solutions that can solve this problem today use route >injection into BGP, static route injection, or some other means to >direct traffic --difficult and error prone mechanisms. All of these >solutions also draw traffic only along links between the edge routers >themselves to put traffic on the best possible outbound link. > >With IRS, the best path could be calculated using any number of custom >written mechanisms, and the routes injected into the right places in the >network to effect the most efficient drawing of traffic to the best exit >point. Changes in the network environment could quickly cause traffic to >be shifted to alternate exit points when circumstances dictate. > >=3D=3D >Denial of Service > >FlowSpec is designed to allow an AS to push a filter upstream, with the >ultimate goal being to block the source of DDoS and other attacks as >close to the origin of those attacks as possible. There are some >situations, however, where you would prefer to block an attack at all >edges, or throughout an entire local network. For instance, you might >want to block the forwarding of traffic within your network while you >are pushing FlowSpec updates upstream to block the traffic closer to the >source, or you might be dealing with an attack originating from multiple >points within your own network. > >While these responses are possible with standard routing, there is a >strong case to be made that routing information should not be mixed with >security response information within the routing domain (within an AS). >Mixing these two types of information can make network management more >difficult, and slow down the repair of a network during large scale >failures. It would be simpler to have a single controller in a network >tied to the various attack detection mechanisms that could directly >install the correct routing information to pull all attack traffic to a >central location, or to simply route the traffic to a null interface. > >An related use is that of pulling unknown traffic through specific >devices for analysis. A network operator may not want to drive all >traffic through traffic analysis devices simply because of cost and >quality of service degredation. A network operator could use IRS to >directly modify the routing tables on devices in the path of unknown or >possibly dangerous flows so this traffic is pulled through the correct >monitoring and analysis devices. > >=3D=3D >Remote Service Routing > >In hub and spoke overlay networks, there is always an issue with >balancing between the information held in the spoke routing table, >optimal routing through the network underlying the overlay, and >mobility. Most solutions in this space use some form of centralized >route server that acts as a directory of all reachable destinations and >next hops, a protocol by which spoke devices and this route server >communicate, and caches at the remote sites. > >An IRS solution would use the same elements, but with a different >control plane. Remote sites would register (or advertise through some >standard routing protocol, such as BGP), the reachable destinations at >each site, along with the address of the router (or other device) used >to reach that destination. These would, as always, be stored in a route >server (or several redundant route servers) at a central location. > >When a remote site sends a set of packets to the central location that >are eventually destined to some other remote site, the central location >can forward this traffic, but at the same time simply directly insert >the correct routing information into the remote site's routing table. If >the location of the destination changes, the route server can directly >modify the routing information at the remote site as needed. >An interesting aspect of this solution is that no new and specialized >protocols are needed between the remote sites and the centralized route >server(s). Normal routing protocols can be used to notify the >centralized route server(s) of modifications in reachability >information, and the route server(s) can respond as needed, based on >local algorithms optimized for a particular application or network. For >instance, short lived flows might be allowed to simply pass through the >hub site with no reaction, while longer lived flows might warrant a >specific route to be installed in the remote router. Algorithms can also >be developed that would optimize traffic flow through the overlay, and >also to remove routing entries from remote devices when they are no >longer needed based on far greater intelligence than simple non-use for >some period of time. > >=3D=3D > > >_______________________________________________ >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 Return-Path: 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 DB09321E8122 for ; Thu, 2 Aug 2012 11:25:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.425 X-Spam-Level: X-Spam-Status: No, score=-6.425 tagged_above=-999 required=5 tests=[AWL=0.174, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lKQv+a-2vGrJ for ; Thu, 2 Aug 2012 11:25:02 -0700 (PDT) Received: from exprod7og101.obsmtp.com (exprod7og101.obsmtp.com [64.18.2.155]) by ietfa.amsl.com (Postfix) with ESMTP id 241A621E811E for ; Thu, 2 Aug 2012 11:25:01 -0700 (PDT) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob101.postini.com ([64.18.6.12]) with SMTP ID DSNKUBrF/Gc4dNl+g/8Y/2sbDj69nuWxj2bw@postini.com; Thu, 02 Aug 2012 11:25:01 PDT Received: from p-emfe01-wf.jnpr.net (172.28.145.24) by P-EMHUB02-HQ.jnpr.net (172.24.192.36) with Microsoft SMTP Server (TLS) id 8.3.213.0; Thu, 2 Aug 2012 11:24:35 -0700 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe01-wf.jnpr.net ([fe80::d0d1:653d:5b91:a123%11]) with mapi; Thu, 2 Aug 2012 14:23:50 -0400 From: Thomas Nadeau To: Ning So , "irs-discuss@ietf.org" Date: Thu, 2 Aug 2012 14:23:46 -0400 Thread-Topic: [irs-discuss] irs-discuss Digest, Vol 2, Issue 3 Thread-Index: Ac1w2/Ys909h/DV8T1GXxfgp+gmO+Q== Message-ID: In-Reply-To: <1343929587.64917.YahooMailNeo@web84520.mail.ne1.yahoo.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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [irs-discuss] irs-discuss Digest, Vol 2, Issue 3 X-BeenThere: irs-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2012 18:25:05 -0000 They are at the bottom of the routing area meeting page: https://datatracker.ietf.org/meeting/84/agenda/rtgarea/ From: Ning So > Reply-To: Ning So > Date: Thursday, August 2, 2012 10:46 AM To: "irs-discuss@ietf.org" > Subject: Re: [irs-discuss] irs-discuss Digest, Vol 2, Issue 3 All, Is Alia's presentation loaded anywhere? It's not on the meeting agenda pag= e. Ning From: "irs-discuss-request@ietf.org" <= irs-discuss-request@ietf.org> To: irs-discuss@ietf.org Sent: Thursday, August 2, 2012 1:20 AM Subject: irs-discuss Digest, Vol 2, Issue 3 ----- Forwarded Message ----- If you have received this digest without all the individual message attachments you will need to update your digest options in your list subscription. To do so, go to https://www.ietf.org/mailman/listinfo/irs-discuss Click the 'Unsubscribe or edit options' button, log in, and set "Get MIME or Plain Text Digests?" to MIME. You can set this option globally for all the list digests you receive at this point. Send irs-discuss mailing list submissions to irs-discuss@ietf.org To subscribe or unsubscribe via the World Wide Web, visit https://www.ietf.org/mailman/listinfo/irs-discuss or, via email, send a message with subject or body 'help' to irs-discuss-request@ietf.org You can reach the person managing the list at irs-discuss-owner@ietf.org When replying, please edit your Subject line so it is more specific than "Re: Contents of irs-discuss digest..." Today's Topics: 1. Re: I-D Action: draft-ward-irs-framework-00.txt (Alia Atlas) 2. Re: I-D Action: draft-ward-irs-framework-00.txt (Joel M. Halpern) 3. Re: IRS Problem Statement Posted (Susan Hares) 4. Re: Thoughts on draft-ward-irs-framework (Russ White) Thanks! On Wed, Aug 1, 2012 at 6:54 PM, Susan Hares > wrote: > Alia: > > I'll try to create a bibliography of things people should read. It will = be mid-next week since I'm away from my home library on the SDN topic. > > Sue > > -----Original Message----- > From: Alia Atlas [mailto:akatlas@gmail.com] > Sent: Wednesday, August 01, 2012 3:51 PM > To: Susan Hares > Cc: Joel M. Halpern; irs-discuss@ietf.org > Subject: Re: [irs-discuss] I-D Action: draft-ward-irs-framework-00.txt > > Sue, > > I look forward to talking with you more off-line on the policy and > local-pref research and issues. If you have suggestions on good > background research to read, by all means send it to the list so > others can get up to speed as well. > > On the atomic transaction semantics question, let's get a bit further > into the use-cases and framework - and then have a focused discussion. > I'm not opposed to it forever or if it is necessary - just would like > to thoroughly analyze if it is a real requirement. > > Do others have opinions and perspective on this? > > Alia > > On Wed, Aug 1, 2012 at 1:58 PM, Susan Hares > wrote: >> Alia: >> >> The hierarchical of interfaces (To routing system) is one of the areas t= hat requires prioritization. The prioritization must be able to handle "pre= empt me", "after you", and "after me". >> >> It is also key to understand that irs system must handle multi-interface= s struggles at the lowest layer. You need to look at the MIF WG (+/-) for = some of the struggles of mobility. >> >> -----Original Message----- >> From: Alia Atlas [mailto:akatlas@gmail.com] >> Sent: Monday, July 30, 2012 6:33 PM >> To: Susan Hares >> Cc: Joel M. Halpern; irs-discuss@ietf.org >> Subject: Re: [irs-discuss] I-D Action: draft-ward-irs-framework-00.txt >> >> Hi Sue, >> >> On Mon, Jul 30, 2012 at 9:16 PM, Susan Hares > wrote: >>> Joel and irs-folks: >>> >>> +1 on Joel. >>> >>> Beyond your comments, the requirement prioritization of the interworki= ng of these interfaces is not clearly delineated in this work. This type of= prioritization and sequencing is key to multi-interfaces operation on the = monitoring, configuration or insertion of information into the depth. >> >> [Alia] Can you further clarify, maybe with an example, which aspect >> you are thinking of? Do you mean the ability of an application to >> access multiple sub-interfaces? The interaction of operations >> requested by differerent applications? >> >>> In addition, if you are going to do configuration with roll-forward/rol= l-back - you need a transaction based processing. >> >> [Alia] I'm pretty sure that I avoided the word "transaction" in both >> drafts. That was deliberate. Of course, we can have a discussion >> about whether or not some form of transactions might be desirable. I >> am concerned about their potentially heavy-weight nature. >> >>> Therefore, you've skipped even requiring the hard problems. >> >> [Alia] Can I optimistically pretend that means that the requirements >> we do have don't seem too hard? For the responsiveness and throughput >> goals, I've put a stake in the ground to avoid transaction-based >> semantics. Naturally, the hordes can run over that stake, if >> necessary. >> >> [Sue]: The requirements are necessary even if they are hard. >> >> [Alia] For the interaction between different layers of sub-interfaces, >> I've been assuming that we'll define the interactions between the >> layers based on how they are generally done. For instance, perhaps we >> standardize the idea of preference value - and then the RIB can pick >> the best route based upon those preferences. For interaction between >> different applications, I think there's a mixture of >> authorization/authentication to get right plus a good set of events >> that an application could register for. >> >> [Sue]: As someone who has lived with "local pref" in BGP for a long time= , there is a bit more to unwrap in the statement. However, it breaks down = to prioritization that is pre-set by preferences. >> >> The policy issues behind the local-pref setting have been studied by the= BGP policy community. This is substantial good work on this from the acade= mic researchers, vendors, and operator. Griffins, Rexford, Bush, Feamster, = ..... and lots others are much better on the theory than I am. >> >>> Is this just the -00.draft? >> >> [Alia] Certainly, I expect that we'll uncover more requirements as we >> go along. As I said, some of this is initially setting parts out of >> scope. >> >> ---> Scope =3D=3D good. Setting scope allows us to pick a piece of this= work and standardize it for interoperability. >> >> Alia >> >>> Sue >>> >>> >>> >>> -----Original Message----- >>> From: irs-discuss-bounces@ietf.org= [mailto:irs-discuss-bounces@ietf.org]= On Behalf Of Joel M. Halpern >>> Sent: Monday, July 30, 2012 3:15 PM >>> To: irs-discuss@ietf.org >>> Subject: Re: [irs-discuss] I-D Action: draft-ward-irs-framework-00.txt >>> >>> I am finding this document quite confusing. >>> >>> The primary confusion is that the document first says that it is about >>> information that can not be manipulated with existing systems, and then >>> proceeds to give a list of use cases all of which can be manipulated >>> with existing systems at a suitable degree of abstraction. >>> >>> As a lesser confusion, the document says that "streaming" is important, >>> but then describes "streaming" as "fast, interactive access." That is >>> not streaming. And depending upon what one means by interactive, plent= y >>> of systems provide "fest, interactive access." I realize the document >>> later goes on tot talk about speed and frequency of state updates. But >>> that section simply reasserts the earlier terms withotu better >>> description or justification. >>> >>> Yours, >>> Joel >>> >>> On 7/30/2012 2:08 PM, internet-drafts@ietf.org wrote: >>>> >>>> A New Internet-Draft is available from the on-line Internet-Drafts dir= ectories. >>>> >>>> >>>> Title : Interface to the Routing System Framework >>>> Author(s) : Alia Atlas >>>> Thomas Nadeau >>>> Dave Ward >>>> Filename : draft-ward-irs-framework-00.txt >>>> Pages : 21 >>>> Date : 2012-07-30 >>>> >>>> Abstract: >>>> This document describes a framework for a standard, programmatic >>>> interface for full-duplex, streaming state transfer in and out of t= he >>>> Internet's routing system. It lists the information that might be >>>> exchanged over the interface, and describes the uses of an interfac= e >>>> to the Internet routing system. >>>> >>> _______________________________________________ >>> 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 With regard to transaction issues, we discussed this extensively when doing ForCES. We concluded that the answer we needed was "yes and no". That is, the protocol has mechanisms which can be used for transactional integrity, including integrity across interactions with multiple FEs. However, the protocol does not require the CE to use those mechanisms. In fact, if it does not even want explicit acks (the messages go over TCP), it can defer that until it gets to a good "please confirm" point. And in the efforts to use this later, having this range of options has been useful. Yours, Joel On 8/1/2012 6:51 PM, Alia Atlas wrote: > Sue, > > I look forward to talking with you more off-line on the policy and > local-pref research and issues. If you have suggestions on good > background research to read, by all means send it to the list so > others can get up to speed as well. > > On the atomic transaction semantics question, let's get a bit further > into the use-cases and framework - and then have a focused discussion. > I'm not opposed to it forever or if it is necessary - just would like > to thoroughly analyze if it is a real requirement. > > Do others have opinions and perspective on this? > > Alia > > On Wed, Aug 1, 2012 at 1:58 PM, Susan Hares > wrote: >> Alia: >> >> The hierarchical of interfaces (To routing system) is one of the areas t= hat requires prioritization. The prioritization must be able to handle "pre= empt me", "after you", and "after me". >> >> It is also key to understand that irs system must handle multi-interface= s struggles at the lowest layer. You need to look at the MIF WG (+/-) for = some of the struggles of mobility. >> >> -----Original Message----- >> From: Alia Atlas [mailto:akatlas@gmail.com] >> Sent: Monday, July 30, 2012 6:33 PM >> To: Susan Hares >> Cc: Joel M. Halpern; irs-discuss@ietf.org >> Subject: Re: [irs-discuss] I-D Action: draft-ward-irs-framework-00.txt >> >> Hi Sue, >> >> On Mon, Jul 30, 2012 at 9:16 PM, Susan Hares > wrote: >>> Joel and irs-folks: >>> >>> +1 on Joel. >>> >>> Beyond your comments, the requirement prioritization of the interworki= ng of these interfaces is not clearly delineated in this work. This type of= prioritization and sequencing is key to multi-interfaces operation on the = monitoring, configuration or insertion of information into the depth. >> >> [Alia] Can you further clarify, maybe with an example, which aspect >> you are thinking of? Do you mean the ability of an application to >> access multiple sub-interfaces? The interaction of operations >> requested by differerent applications? >> >>> In addition, if you are going to do configuration with roll-forward/rol= l-back - you need a transaction based processing. >> >> [Alia] I'm pretty sure that I avoided the word "transaction" in both >> drafts. That was deliberate. Of course, we can have a discussion >> about whether or not some form of transactions might be desirable. I >> am concerned about their potentially heavy-weight nature. >> >>> Therefore, you've skipped even requiring the hard problems. >> >> [Alia] Can I optimistically pretend that means that the requirements >> we do have don't seem too hard? For the responsiveness and throughput >> goals, I've put a stake in the ground to avoid transaction-based >> semantics. Naturally, the hordes can run over that stake, if >> necessary. >> >> [Sue]: The requirements are necessary even if they are hard. >> >> [Alia] For the interaction between different layers of sub-interfaces, >> I've been assuming that we'll define the interactions between the >> layers based on how they are generally done. For instance, perhaps we >> standardize the idea of preference value - and then the RIB can pick >> the best route based upon those preferences. For interaction between >> different applications, I think there's a mixture of >> authorization/authentication to get right plus a good set of events >> that an application could register for. >> >> [Sue]: As someone who has lived with "local pref" in BGP for a long time= , there is a bit more to unwrap in the statement. However, it breaks down = to prioritization that is pre-set by preferences. >> >> The policy issues behind the local-pref setting have been studied by the= BGP policy community. This is substantial good work on this from the acade= mic researchers, vendors, and operator. Griffins, Rexford, Bush, Feamster, = ..... and lots others are much better on the theory than I am. >> >>> Is this just the -00.draft? >> >> [Alia] Certainly, I expect that we'll uncover more requirements as we >> go along. As I said, some of this is initially setting parts out of >> scope. >> >> ---> Scope =3D=3D good. Setting scope allows us to pick a piece of this= work and standardize it for interoperability. >> >> Alia >> >>> Sue >>> >>> >>> >>> -----Original Message----- >>> From: irs-discuss-bounces@ietf.org= [mailto:irs-discuss-bounces@ietf.org]= On Behalf Of Joel M. Halpern >>> Sent: Monday, July 30, 2012 3:15 PM >>> To: irs-discuss@ietf.org >>> Subject: Re: [irs-discuss] I-D Action: draft-ward-irs-framework-00.txt >>> >>> I am finding this document quite confusing. >>> >>> The primary confusion is that the document first says that it is about >>> information that can not be manipulated with existing systems, and then >>> proceeds to give a list of use cases all of which can be manipulated >>> with existing systems at a suitable degree of abstraction. >>> >>> As a lesser confusion, the document says that "streaming" is important, >>> but then describes "streaming" as "fast, interactive access." That is >>> not streaming. And depending upon what one means by interactive, plent= y >>> of systems provide "fest, interactive access." I realize the document >>> later goes on tot talk about speed and frequency of state updates. But >>> that section simply reasserts the earlier terms withotu better >>> description or justification. >>> >>> Yours, >>> Joel >>> >>> On 7/30/2012 2:08 PM, internet-drafts@ietf.org wrote: >>>> >>>> A New Internet-Draft is available from the on-line Internet-Drafts dir= ectories. >>>> >>>> >>>> Title : Interface to the Routing System Framework >>>> Author(s) : Alia Atlas >>>> Thomas Nadeau >>>> Dave Ward >>>> Filename : draft-ward-irs-framework-00.txt >>>> Pages : 21 >>>> Date : 2012-07-30 >>>> >>>> Abstract: >>>> This document describes a framework for a standard, programmatic >>>> interface for full-duplex, streaming state transfer in and out of= the >>>> Internet's routing system. It lists the information that might b= e >>>> exchanged over the interface, and describes the uses of an interf= ace >>>> to the Internet routing system. >>>> >>> _______________________________________________ >>> 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 > Alia: I'm going to check with a colleague who has been doing lots of model work t= o see if he's got a better. More later. Sue -----Original Message----- From: Alia Atlas [mailto:akatlas@gmail.com] Sent: Wednesday, August 01, 2012 3:41 PM To: Susan Hares Cc: Nitin Bahadur; James Kempf; Thomas Nadeau; irs-discuss@ietf.org Subject: Re: [irs-discuss] IRS Problem Statement Posted Sue, In this case, I was thinking of "translating" from a "higher abstraction layer" to a "lower abstraction layer". Do you have a better/different term to suggest? I agree that clarity of terminology is important. Alia On Wed, Aug 1, 2012 at 2:03 PM, Susan Hares > wrote: > Alia: > > +1 on abstraction + filters (abstract/detail) IRS fits at the routing con= trol. > > The real question about translation is what the translation is doing. Is= it translating one thing to another at the same layer of abstraction (e.g.= , Spanish/English, Ascii/ebcdic) or is it doing abstraction/detail change. > > I define translation as the same layer of abstraction. Some people sugge= st translation =3D abstract/detailing. We first need a common way to talk = about the difference. > > Sue > > By the way --- I'm thrilled about the pace of the discussion. > > > -----Original Message----- > From: Alia Atlas [mailto:akatlas@gmail.com] > Sent: Monday, July 30, 2012 6:40 PM > To: Susan Hares > Cc: Nitin Bahadur; James Kempf; Thomas Nadeau; irs-discuss@ietf.org > Subject: Re: [irs-discuss] IRS Problem Statement Posted > > Sue, > > I certainly agree that we want IRS to have the ability to express > information at different abstraction layers and filtered on request. > > There may still be a gap between the "network OS abstractions" and IRS > sub-interfaces; I'd be surprised if there weren't. IRS is to provide > the bottom-up control strings. > > IMHO, it's reasonable to have an entity that manages the translation. > For instance, one doesn't need a PCE-equiv in every application - nor > in every router; that might be an entity in between. > > The quantity of information is part of why explicit filtering and > hopefully abstraction layers should be built into the data-models. > > Alia > > On Mon, Jul 30, 2012 at 9:24 PM, Susan Hares > wrote: >> Nitin: >> >> Exposing some network intelligence can either be done in detail or in so= me amount of summarization. >> If you are doing detail, you have bandwidth issues. If you are doing sum= marization or opacity, you are talking about layers of information. >> >> Apps need to find out what they need to get. They do not need all the de= tails - just the fact they can get from point A to Point B (or for multi-ca= st B/C/D). They need to where they can go to date other applications. They= need a match-maker for the application who determine where the application= s shall flow. Now, if they are smart - like people going out to eat - they= pick several ways go to eat traffic. >> >> The network orchestration then serves to be the paths to the place to ea= t. This can either be distributed or centralized. >> >> If we have an Interface to routing, it need to have a two-layer concept = of exposing information. >> >> Sue Hares >> >> -----Original Message----- >> From: irs-discuss-bounces@ietf.org = [mailto:irs-discuss-bounces@ietf.org] = On Behalf Of Nitin Bahadur >> Sent: Monday, July 30, 2012 3:33 PM >> To: James Kempf; Thomas Nadeau; irs-discuss@ietf.org >> Subject: Re: [irs-discuss] IRS Problem Statement Posted >> >> Hi James, >> >> This is not about splitting control plane and forwarding plane. It is ab= out exposing network intelligence in the network elements to an external co= ntroller. >> And it is about allowing an external controller to use that information = for enabling network-aware apps. And it is about allowing apps to influence= the >> network element's RIB (not the FIB directly). >> >> Streaming is essential to allow for operations at scale...and avoid a re= quest/response gated mechanism. >> >> Hope that helps. >> >> Thanks >> Nitin >> >> On 7/30/12 3:11 PM, "James Kempf" > wrote: >> >> I don't understand why streaming is specified in this draft. And I don't= understand why this draft isn't put in the Forces framework. Forces is a f= ramework explicitedly designed for device to controller communication. Its = major drawback it that it is a framework with a hole in the middle, in that= there are no specified devices. This draft would fill that hole. >> >> I don't think it is necessary to have a problem statement for router sta= te update. Forces has already established that splitting the control plane = into a separate device is, in some cases, an attractive design option. So I= think this should be submitted to the Forces working group, or, at least, = recast in the Forces framework. >> >> jak >> >>> -----Original Message----- >>> From: irs-discuss-bounces@ietf.org >>> [mailto:irs-discuss-bounces@ietf.org] On Behalf Of Thomas Nadeau >>> Sent: Monday, July 30, 2012 11:18 AM >>> To: irs-discuss@ietf.org >>> Subject: [irs-discuss] IRS Problem Statement Posted >>> >>> >>> >>> Please review and discuss. >>> >>> Thanks, >>> >>> Tom, Alia, Ward >>> >>> >>> http://lucidvision.com/draft-atlas-irs-problem-statement-00.txt >>> >>> >>> _______________________________________________ >>> 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 >> >> _______________________________________________ >> 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 > Sue: Use cases are key. The clarity of the use cases will guide us. Ple= ase send USE cases. Here are three I just threw together. We can talk about refining these tomorrow, if you like... My fingers got tired before my brain did. :-) Russ =3D=3D Optimized Exit Use Case Assume you have a network where there are two possible exit points towards any set of destinations. The cost of using these links varies by time, and the quality of the links is highly variable, but not necessarily related to the actual load the local network is putting on them (in other words, these are oversubscribed links shared with other parallel networks or customers with unpredictable traffic patterns). What you'd like to do is to use the lowest cost link until the quality of the link reaches a specific level, and then switch to the higher cost link. The point at which this link switch might occur may vary based on time of day, because the RTO on specific traffic levels varies by the time of day as well. So you have a problem with multiple variables: link quality (apparently random from your perspective), link cost (varies by time of day), return on investment (varies by time of day). Combined with this you have multiple exit points, and you must draw traffic from an inside network as efficiently as possible to the best exit point, as determined by these various factors. The only well defined way to resolve this problem is to feed the variables to an off router controller, calculate the best exit point on some periodic basis, and then feed this information back into the routing table. All solutions that can solve this problem today use route injection into BGP, static route injection, or some other means to direct traffic --difficult and error prone mechanisms. All of these solutions also draw traffic only along links between the edge routers themselves to put traffic on the best possible outbound link. With IRS, the best path could be calculated using any number of custom written mechanisms, and the routes injected into the right places in the network to effect the most efficient drawing of traffic to the best exit point. Changes in the network environment could quickly cause traffic to be shifted to alternate exit points when circumstances dictate. =3D=3D Denial of Service FlowSpec is designed to allow an AS to push a filter upstream, with the ultimate goal being to block the source of DDoS and other attacks as close to the origin of those attacks as possible. There are some situations, however, where you would prefer to block an attack at all edges, or throughout an entire local network. For instance, you might want to block the forwarding of traffic within your network while you are pushing FlowSpec updates upstream to block the traffic closer to the source, or you might be dealing with an attack originating from multiple points within your own network. While these responses are possible with standard routing, there is a strong case to be made that routing information should not be mixed with security response information within the routing domain (within an AS). Mixing these two types of information can make network management more difficult, and slow down the repair of a network during large scale failures. It would be simpler to have a single controller in a network tied to the various attack detection mechanisms that could directly install the correct routing information to pull all attack traffic to a central location, or to simply route the traffic to a null interface. An related use is that of pulling unknown traffic through specific devices for analysis. A network operator may not want to drive all traffic through traffic analysis devices simply because of cost and quality of service degredation. A network operator could use IRS to directly modify the routing tables on devices in the path of unknown or possibly dangerous flows so this traffic is pulled through the correct monitoring and analysis devices. =3D=3D Remote Service Routing In hub and spoke overlay networks, there is always an issue with balancing between the information held in the spoke routing table, optimal routing through the network underlying the overlay, and mobility. Most solutions in this space use some form of centralized route server that acts as a directory of all reachable destinations and next hops, a protocol by which spoke devices and this route server communicate, and caches at the remote sites. An IRS solution would use the same elements, but with a different control plane. Remote sites would register (or advertise through some standard routing protocol, such as BGP), the reachable destinations at each site, along with the address of the router (or other device) used to reach that destination. These would, as always, be stored in a route server (or several redundant route servers) at a central location. When a remote site sends a set of packets to the central location that are eventually destined to some other remote site, the central location can forward this traffic, but at the same time simply directly insert the correct routing information into the remote site's routing table. If the location of the destination changes, the route server can directly modify the routing information at the remote site as needed. An interesting aspect of this solution is that no new and specialized protocols are needed between the remote sites and the centralized route server(s). Normal routing protocols can be used to notify the centralized route server(s) of modifications in reachability information, and the route server(s) can respond as needed, based on local algorithms optimized for a particular application or network. For instance, short lived flows might be allowed to simply pass through the hub site with no reaction, while longer lived flows might warrant a specific route to be installed in the remote router. Algorithms can also be developed that would optimize traffic flow through the overlay, and also to remove routing entries from remote devices when they are no longer needed based on far greater intelligence than simple non-use for some period of time. =3D=3D _______________________________________________ irs-discuss mailing list irs-discuss@ietf.org https://www.ietf.org/mailman/listinfo/irs-discuss Return-Path: 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 B9F9921E811E for ; Thu, 2 Aug 2012 11:23:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.416 X-Spam-Level: X-Spam-Status: No, score=-6.416 tagged_above=-999 required=5 tests=[AWL=0.183, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7K9873kCPnbk for ; Thu, 2 Aug 2012 11:23:43 -0700 (PDT) Received: from exprod7og104.obsmtp.com (exprod7og104.obsmtp.com [64.18.2.161]) by ietfa.amsl.com (Postfix) with ESMTP id BBE4821E811D for ; Thu, 2 Aug 2012 11:23:42 -0700 (PDT) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob104.postini.com ([64.18.6.12]) with SMTP ID DSNKUBrFpwmhAejOIzODpuIgDdRD3Fm+2oKk@postini.com; Thu, 02 Aug 2012 11:23:42 PDT Received: from P-CLDFE02-HQ.jnpr.net (172.24.192.60) by P-EMHUB02-HQ.jnpr.net (172.24.192.36) with Microsoft SMTP Server (TLS) id 8.3.213.0; Thu, 2 Aug 2012 11:22:48 -0700 Received: from p-emfe01-wf.jnpr.net (172.28.145.24) by p-cldfe02-hq.jnpr.net (172.24.192.60) with Microsoft SMTP Server (TLS) id 14.1.355.2; Thu, 2 Aug 2012 11:22:39 -0700 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe01-wf.jnpr.net ([fe80::d0d1:653d:5b91:a123%11]) with mapi; Thu, 2 Aug 2012 14:22:26 -0400 From: Thomas Nadeau To: "robert@raszuk.net" , Alia Atlas Date: Thu, 2 Aug 2012 14:22:23 -0400 Thread-Topic: [irs-discuss] Clarification questions ... Thread-Index: Ac1w28PnyGE/wlA8QxK5VMSsvpGK7A== Message-ID: In-Reply-To: <501ABCCC.4060908@raszuk.net> 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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "irs-discuss@ietf.org" Subject: Re: [irs-discuss] Clarification questions ... X-BeenThere: irs-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2012 18:23:44 -0000 On 8/2/12 10:45 AM, "Robert Raszuk" wrote: >Q1: > >I have seen a framework slide showing IRS Agent withing the router. > >I would like to clarify if you are going to have such IRS Agent in each >router participating in given (maybe new) service in the AS ? How many >IRS clients your envision ? > >Is the model of 1000s of IRS agents talking to 10s of IRS clients as >example ? That=B9s been a bit of confusion. The "agent" is the IRS interface on the router. You could certainly have more htan one, but your implementation would have to coordinate internally to make sure they can work together. In the slides, its a logical representation. Similarly, the "client" component, is in the simple case, just the lib you import into the application that understands the protocol; its not necessarily a stand-alone thing. > >Q2: > >Is data currently distributed by routing protocols explicitly prohibited >to be also distributed by IRS overlay and send to the routers by TBD IRS >channel ? I think that is a reasonable question to ask. I personally see it as being valid to do both. --Tom > >Thx a lot ! >R. >_______________________________________________ >irs-discuss mailing list >irs-discuss@ietf.org >https://www.ietf.org/mailman/listinfo/irs-discuss Return-Path: 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 98A3C11E81EB for ; Thu, 2 Aug 2012 11:07:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mCQATnI7PNU8 for ; Thu, 2 Aug 2012 11:07:38 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8899111E81E6 for ; Thu, 2 Aug 2012 11:07:36 -0700 (PDT) Received: by obbwc20 with SMTP id wc20so16107557obb.31 for ; Thu, 02 Aug 2012 11:07:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:content-transfer-encoding:subject:date:message-id :to:mime-version:x-mailer; bh=kwjnTjgQxUGbKFfeCvt2lLJFHw/Kaj18RVmwJ0xYU1o=; b=qQ02KaVou4lI0PX9RBU9ZPXWBV9kpWNBaDZLF2rcWgMgI5JP0Q5wE8sb7s+HsLDjR5 fJ6GwOPhNUWa6XQdRAkzm0381HsUICwKPuHfcqA0WxWAqxyOhtQhmcv2TsoQuEEAuJE4 frJ05Y0KLUWniqbCnqKGO7JeBd8ZaebyA7DcRnuVasuRIqhchR0xnOaCD0FWCklCsBOo Lnb7SaRAyWtfdB2Wr8ehHgIyFxnAXMIWM95ioRiCsOCJojlcI1fhVo469vPR/41dpaOL p1q1RgfpIG+STlT3nzE1kNWHGayvawkFmjRcYbUTADIUXsjkeynTKckORvpYn1sHa9nw 7OhA== Received: by 10.182.50.103 with SMTP id b7mr38768492obo.15.1343930854495; Thu, 02 Aug 2012 11:07:34 -0700 (PDT) Received: from dhcp-1436.meeting.ietf.org (dhcp-1436.meeting.ietf.org. [130.129.20.54]) by mx.google.com with ESMTPS id l10sm5122420oeb.13.2012.08.02.11.07.33 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 02 Aug 2012 11:07:34 -0700 (PDT) From: Pedro Roque Marques Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Thu, 2 Aug 2012 11:07:40 -0700 Message-Id: <632FAE8B-8CC5-4701-BB42-1C4EACE372D5@gmail.com> To: irs-discuss@ietf.org Mime-Version: 1.0 (Apple Message framework v1278) X-Mailer: Apple Mail (2.1278) Subject: [irs-discuss] if-map example X-BeenThere: irs-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2012 18:07:39 -0000 As i pointed out in the RT area meeting, i believe that IF-MAP is a = successful example of what can be achieved by network-wide schemas (vs = network element schemas). The current spec is at: = http://www.trustedcomputinggroup.org/files/resource_files/2888CAD9-1A4B-B2= 94-D0ED95712B121FEF/TNC_IFMAP_v2_1r15.pdf if-map.org has lots of material on the use cases. As per my comment on the mic, i'd like to encourage the IRS to focus on = data schemas that describe network state. thank you, Pedro.= Return-Path: 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 605F211E81B2 for ; Thu, 2 Aug 2012 10:53:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.021 X-Spam-Level: X-Spam-Status: No, score=-6.021 tagged_above=-999 required=5 tests=[AWL=0.228, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1dvFYaHINa+I for ; Thu, 2 Aug 2012 10:53:03 -0700 (PDT) Received: from p-mail1.rd.francetelecom.com (p-mail1.rd.francetelecom.com [195.101.245.15]) by ietfa.amsl.com (Postfix) with ESMTP id 40B6911E81D3 for ; Thu, 2 Aug 2012 10:53:02 -0700 (PDT) Received: from p-mail1.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 0CE3B7D4001; Thu, 2 Aug 2012 19:53:01 +0200 (CEST) Received: from ftrdsmtp2.rd.francetelecom.fr (unknown [10.192.128.47]) by p-mail1.rd.francetelecom.com (Postfix) with ESMTP id ECD4E410018; Thu, 2 Aug 2012 19:53:00 +0200 (CEST) Received: from ftrdmel10.rd.francetelecom.fr ([10.192.128.44]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Thu, 2 Aug 2012 19:53:00 +0200 Received: from [10.193.116.28] ([10.193.116.28]) by ftrdmel10.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Thu, 2 Aug 2012 19:52:59 +0200 Message-ID: <501ABE7A.3070205@orange.com> Date: Thu, 02 Aug 2012 19:52:58 +0200 From: Julien Meuric Organization: France Telecom User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:14.0) Gecko/20120714 Thunderbird/14.0 MIME-Version: 1.0 To: Ning So References: <1343929587.64917.YahooMailNeo@web84520.mail.ne1.yahoo.com> In-Reply-To: <1343929587.64917.YahooMailNeo@web84520.mail.ne1.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 02 Aug 2012 17:52:59.0775 (UTC) FILETIME=[A7B810F0:01CD70D7] Cc: "irs-discuss@ietf.org" Subject: Re: [irs-discuss] irs-discuss Digest, Vol 2, Issue 3 X-BeenThere: irs-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2012 17:53:06 -0000 http://www.ietf.org/proceedings/84/slides/slides-84-rtgarea-3.pptx (from https://datatracker.ietf.org/meeting/84/materials.html) Julien Le 02/08/2012 19:46, Ning So a écrit : > All, > Is Alia's presentation loaded anywhere? It's not on the meeting > agenda page. > Ning > > *From:* "irs-discuss-request@ietf.org" > *To:* irs-discuss@ietf.org > *Sent:* Thursday, August 2, 2012 1:20 AM > *Subject:* irs-discuss Digest, Vol 2, Issue 3 > > ----- Forwarded Message ----- > > If you have received this digest without all the individual message > attachments you will need to update your digest options in your list > subscription. To do so, go to > > https://www.ietf.org/mailman/listinfo/irs-discuss > > Click the 'Unsubscribe or edit options' button, log in, and set "Get > MIME or Plain Text Digests?" to MIME. You can set this option > globally for all the list digests you receive at this point. > > > > Send irs-discuss mailing list submissions to > irs-discuss@ietf.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://www.ietf.org/mailman/listinfo/irs-discuss > or, via email, send a message with subject or body 'help' to > irs-discuss-request@ietf.org > > You can reach the person managing the list at > irs-discuss-owner@ietf.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of irs-discuss digest..." > > Today's Topics: > > 1. Re: I-D Action: draft-ward-irs-framework-00.txt (Alia Atlas) > 2. Re: I-D Action: draft-ward-irs-framework-00.txt (Joel M. Halpern) > 3. Re: IRS Problem Statement Posted (Susan Hares) > 4. Re: Thoughts on draft-ward-irs-framework (Russ White) > Thanks! > > On Wed, Aug 1, 2012 at 6:54 PM, Susan Hares > wrote: > > Alia: > > > > I'll try to create a bibliography of things people should read. It > will be mid-next week since I'm away from my home library on the SDN > topic. > > > > Sue > > > > -----Original Message----- > > From: Alia Atlas [mailto:akatlas@gmail.com ] > > Sent: Wednesday, August 01, 2012 3:51 PM > > To: Susan Hares > > Cc: Joel M. Halpern; irs-discuss@ietf.org > > Subject: Re: [irs-discuss] I-D Action: draft-ward-irs-framework-00.txt > > > > Sue, > > > > I look forward to talking with you more off-line on the policy and > > local-pref research and issues. If you have suggestions on good > > background research to read, by all means send it to the list so > > others can get up to speed as well. > > > > On the atomic transaction semantics question, let's get a bit further > > into the use-cases and framework - and then have a focused discussion. > > I'm not opposed to it forever or if it is necessary - just would like > > to thoroughly analyze if it is a real requirement. > > > > Do others have opinions and perspective on this? > > > > Alia > > > > On Wed, Aug 1, 2012 at 1:58 PM, Susan Hares > wrote: > >> Alia: > >> > >> The hierarchical of interfaces (To routing system) is one of the > areas that requires prioritization. The prioritization must be able to > handle "preempt me", "after you", and "after me". > >> > >> It is also key to understand that irs system must handle > multi-interfaces struggles at the lowest layer. You need to look at > the MIF WG (+/-) for some of the struggles of mobility. > >> > >> -----Original Message----- > >> From: Alia Atlas [mailto:akatlas@gmail.com ] > >> Sent: Monday, July 30, 2012 6:33 PM > >> To: Susan Hares > >> Cc: Joel M. Halpern; irs-discuss@ietf.org > >> Subject: Re: [irs-discuss] I-D Action: draft-ward-irs-framework-00.txt > >> > >> Hi Sue, > >> > >> On Mon, Jul 30, 2012 at 9:16 PM, Susan Hares > > wrote: > >>> Joel and irs-folks: > >>> > >>> +1 on Joel. > >>> > >>> Beyond your comments, the requirement prioritization of the > interworking of these interfaces is not clearly delineated in this > work. This type of prioritization and sequencing is key to > multi-interfaces operation on the monitoring, configuration or > insertion of information into the depth. > >> > >> [Alia] Can you further clarify, maybe with an example, which aspect > >> you are thinking of? Do you mean the ability of an application to > >> access multiple sub-interfaces? The interaction of operations > >> requested by differerent applications? > >> > >>> In addition, if you are going to do configuration with > roll-forward/roll-back - you need a transaction based processing. > >> > >> [Alia] I'm pretty sure that I avoided the word "transaction" in both > >> drafts. That was deliberate. Of course, we can have a discussion > >> about whether or not some form of transactions might be desirable. I > >> am concerned about their potentially heavy-weight nature. > >> > >>> Therefore, you've skipped even requiring the hard problems. > >> > >> [Alia] Can I optimistically pretend that means that the requirements > >> we do have don't seem too hard? For the responsiveness and throughput > >> goals, I've put a stake in the ground to avoid transaction-based > >> semantics. Naturally, the hordes can run over that stake, if > >> necessary. > >> > >> [Sue]: The requirements are necessary even if they are hard. > >> > >> [Alia] For the interaction between different layers of sub-interfaces, > >> I've been assuming that we'll define the interactions between the > >> layers based on how they are generally done. For instance, perhaps we > >> standardize the idea of preference value - and then the RIB can pick > >> the best route based upon those preferences. For interaction between > >> different applications, I think there's a mixture of > >> authorization/authentication to get right plus a good set of events > >> that an application could register for. > >> > >> [Sue]: As someone who has lived with "local pref" in BGP for a long > time, there is a bit more to unwrap in the statement. However, it > breaks down to prioritization that is pre-set by preferences. > >> > >> The policy issues behind the local-pref setting have been studied > by the BGP policy community. This is substantial good work on this > from the academic researchers, vendors, and operator. Griffins, > Rexford, Bush, Feamster, ..... and lots others are much better on the > theory than I am. > >> > >>> Is this just the -00.draft? > >> > >> [Alia] Certainly, I expect that we'll uncover more requirements as we > >> go along. As I said, some of this is initially setting parts out of > >> scope. > >> > >> ---> Scope == good. Setting scope allows us to pick a piece of > this work and standardize it for interoperability. > >> > >> Alia > >> > >>> Sue > >>> > >>> > >>> > >>> -----Original Message----- > >>> From: irs-discuss-bounces@ietf.org > > [mailto:irs-discuss-bounces@ietf.org > ] On Behalf Of Joel M. Halpern > >>> Sent: Monday, July 30, 2012 3:15 PM > >>> To: irs-discuss@ietf.org > >>> Subject: Re: [irs-discuss] I-D Action: draft-ward-irs-framework-00.txt > >>> > >>> I am finding this document quite confusing. > >>> > >>> The primary confusion is that the document first says that it is about > >>> information that can not be manipulated with existing systems, and > then > >>> proceeds to give a list of use cases all of which can be manipulated > >>> with existing systems at a suitable degree of abstraction. > >>> > >>> As a lesser confusion, the document says that "streaming" is > important, > >>> but then describes "streaming" as "fast, interactive access." That is > >>> not streaming. And depending upon what one means by interactive, > plenty > >>> of systems provide "fest, interactive access." I realize the document > >>> later goes on tot talk about speed and frequency of state > updates. But > >>> that section simply reasserts the earlier terms withotu better > >>> description or justification. > >>> > >>> Yours, > >>> Joel > >>> > >>> On 7/30/2012 2:08 PM, internet-drafts@ietf.org > wrote: > >>>> > >>>> A New Internet-Draft is available from the on-line > Internet-Drafts directories. > >>>> > >>>> > >>>> Title : Interface to the Routing System Framework > >>>> Author(s) : Alia Atlas > >>>> Thomas Nadeau > >>>> Dave Ward > >>>> Filename : draft-ward-irs-framework-00.txt > >>>> Pages : 21 > >>>> Date : 2012-07-30 > >>>> > >>>> Abstract: > >>>> This document describes a framework for a standard, programmatic > >>>> interface for full-duplex, streaming state transfer in and out > of the > >>>> Internet's routing system. It lists the information that might be > >>>> exchanged over the interface, and describes the uses of an > interface > >>>> to the Internet routing system. > >>>> > >>> _______________________________________________ > >>> 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 > > With regard to transaction issues, we discussed this extensively when > doing ForCES. We concluded that the answer we needed was "yes and no". > That is, the protocol has mechanisms which can be used for > transactional integrity, including integrity across interactions with > multiple FEs. However, the protocol does not require the CE to use > those mechanisms. In fact, if it does not even want explicit acks (the > messages go over TCP), it can defer that until it gets to a good "please > confirm" point. > And in the efforts to use this later, having this range of options has > been useful. > > Yours, > Joel > > On 8/1/2012 6:51 PM, Alia Atlas wrote: > > Sue, > > > > I look forward to talking with you more off-line on the policy and > > local-pref research and issues. If you have suggestions on good > > background research to read, by all means send it to the list so > > others can get up to speed as well. > > > > On the atomic transaction semantics question, let's get a bit further > > into the use-cases and framework - and then have a focused discussion. > > I'm not opposed to it forever or if it is necessary - just would like > > to thoroughly analyze if it is a real requirement. > > > > Do others have opinions and perspective on this? > > > > Alia > > > > On Wed, Aug 1, 2012 at 1:58 PM, Susan Hares > wrote: > >> Alia: > >> > >> The hierarchical of interfaces (To routing system) is one of the > areas that requires prioritization. The prioritization must be able to > handle "preempt me", "after you", and "after me". > >> > >> It is also key to understand that irs system must handle > multi-interfaces struggles at the lowest layer. You need to look at > the MIF WG (+/-) for some of the struggles of mobility. > >> > >> -----Original Message----- > >> From: Alia Atlas [mailto:akatlas@gmail.com ] > >> Sent: Monday, July 30, 2012 6:33 PM > >> To: Susan Hares > >> Cc: Joel M. Halpern; irs-discuss@ietf.org > >> Subject: Re: [irs-discuss] I-D Action: draft-ward-irs-framework-00.txt > >> > >> Hi Sue, > >> > >> On Mon, Jul 30, 2012 at 9:16 PM, Susan Hares > > wrote: > >>> Joel and irs-folks: > >>> > >>> +1 on Joel. > >>> > >>> Beyond your comments, the requirement prioritization of the > interworking of these interfaces is not clearly delineated in this > work. This type of prioritization and sequencing is key to > multi-interfaces operation on the monitoring, configuration or > insertion of information into the depth. > >> > >> [Alia] Can you further clarify, maybe with an example, which aspect > >> you are thinking of? Do you mean the ability of an application to > >> access multiple sub-interfaces? The interaction of operations > >> requested by differerent applications? > >> > >>> In addition, if you are going to do configuration with > roll-forward/roll-back - you need a transaction based processing. > >> > >> [Alia] I'm pretty sure that I avoided the word "transaction" in both > >> drafts. That was deliberate. Of course, we can have a discussion > >> about whether or not some form of transactions might be desirable. I > >> am concerned about their potentially heavy-weight nature. > >> > >>> Therefore, you've skipped even requiring the hard problems. > >> > >> [Alia] Can I optimistically pretend that means that the requirements > >> we do have don't seem too hard? For the responsiveness and throughput > >> goals, I've put a stake in the ground to avoid transaction-based > >> semantics. Naturally, the hordes can run over that stake, if > >> necessary. > >> > >> [Sue]: The requirements are necessary even if they are hard. > >> > >> [Alia] For the interaction between different layers of sub-interfaces, > >> I've been assuming that we'll define the interactions between the > >> layers based on how they are generally done. For instance, perhaps we > >> standardize the idea of preference value - and then the RIB can pick > >> the best route based upon those preferences. For interaction between > >> different applications, I think there's a mixture of > >> authorization/authentication to get right plus a good set of events > >> that an application could register for. > >> > >> [Sue]: As someone who has lived with "local pref" in BGP for a long > time, there is a bit more to unwrap in the statement. However, it > breaks down to prioritization that is pre-set by preferences. > >> > >> The policy issues behind the local-pref setting have been studied > by the BGP policy community. This is substantial good work on this > from the academic researchers, vendors, and operator. Griffins, > Rexford, Bush, Feamster, ..... and lots others are much better on the > theory than I am. > >> > >>> Is this just the -00.draft? > >> > >> [Alia] Certainly, I expect that we'll uncover more requirements as we > >> go along. As I said, some of this is initially setting parts out of > >> scope. > >> > >> ---> Scope == good. Setting scope allows us to pick a piece of > this work and standardize it for interoperability. > >> > >> Alia > >> > >>> Sue > >>> > >>> > >>> > >>> -----Original Message----- > >>> From: irs-discuss-bounces@ietf.org > > [mailto:irs-discuss-bounces@ietf.org > ] On Behalf Of Joel M. Halpern > >>> Sent: Monday, July 30, 2012 3:15 PM > >>> To: irs-discuss@ietf.org > >>> Subject: Re: [irs-discuss] I-D Action: draft-ward-irs-framework-00.txt > >>> > >>> I am finding this document quite confusing. > >>> > >>> The primary confusion is that the document first says that it is about > >>> information that can not be manipulated with existing systems, and > then > >>> proceeds to give a list of use cases all of which can be manipulated > >>> with existing systems at a suitable degree of abstraction. > >>> > >>> As a lesser confusion, the document says that "streaming" is > important, > >>> but then describes "streaming" as "fast, interactive access." That is > >>> not streaming. And depending upon what one means by interactive, > plenty > >>> of systems provide "fest, interactive access." I realize the document > >>> later goes on tot talk about speed and frequency of state > updates. But > >>> that section simply reasserts the earlier terms withotu better > >>> description or justification. > >>> > >>> Yours, > >>> Joel > >>> > >>> On 7/30/2012 2:08 PM, internet-drafts@ietf.org > wrote: > >>>> > >>>> A New Internet-Draft is available from the on-line > Internet-Drafts directories. > >>>> > >>>> > >>>> Title : Interface to the Routing System Framework > >>>> Author(s) : Alia Atlas > >>>> Thomas Nadeau > >>>> Dave Ward > >>>> Filename : draft-ward-irs-framework-00.txt > >>>> Pages : 21 > >>>> Date : 2012-07-30 > >>>> > >>>> Abstract: > >>>> This document describes a framework for a standard, programmatic > >>>> interface for full-duplex, streaming state transfer in and > out of the > >>>> Internet's routing system. It lists the information that > might be > >>>> exchanged over the interface, and describes the uses of an > interface > >>>> to the Internet routing system. > >>>> > >>> _______________________________________________ > >>> 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 > > > > Alia: > > I'm going to check with a colleague who has been doing lots of model > work to see if he's got a better. More later. > > Sue > > -----Original Message----- > From: Alia Atlas [mailto:akatlas@gmail.com ] > Sent: Wednesday, August 01, 2012 3:41 PM > To: Susan Hares > Cc: Nitin Bahadur; James Kempf; Thomas Nadeau; irs-discuss@ietf.org > > Subject: Re: [irs-discuss] IRS Problem Statement Posted > > Sue, > > In this case, I was thinking of "translating" from a "higher > abstraction layer" to a "lower abstraction layer". > > Do you have a better/different term to suggest? I agree that clarity > of terminology is important. > > Alia > > On Wed, Aug 1, 2012 at 2:03 PM, Susan Hares > wrote: > > Alia: > > > > +1 on abstraction + filters (abstract/detail) IRS fits at the > routing control. > > > > The real question about translation is what the translation is > doing. Is it translating one thing to another at the same layer of > abstraction (e.g., Spanish/English, Ascii/ebcdic) or is it doing > abstraction/detail change. > > > > I define translation as the same layer of abstraction. Some people > suggest translation = abstract/detailing. We first need a common way > to talk about the difference. > > > > Sue > > > > By the way --- I'm thrilled about the pace of the discussion. > > > > > > -----Original Message----- > > From: Alia Atlas [mailto:akatlas@gmail.com ] > > Sent: Monday, July 30, 2012 6:40 PM > > To: Susan Hares > > Cc: Nitin Bahadur; James Kempf; Thomas Nadeau; irs-discuss@ietf.org > > > Subject: Re: [irs-discuss] IRS Problem Statement Posted > > > > Sue, > > > > I certainly agree that we want IRS to have the ability to express > > information at different abstraction layers and filtered on request. > > > > There may still be a gap between the "network OS abstractions" and IRS > > sub-interfaces; I'd be surprised if there weren't. IRS is to provide > > the bottom-up control strings. > > > > IMHO, it's reasonable to have an entity that manages the translation. > > For instance, one doesn't need a PCE-equiv in every application - nor > > in every router; that might be an entity in between. > > > > The quantity of information is part of why explicit filtering and > > hopefully abstraction layers should be built into the data-models. > > > > Alia > > > > On Mon, Jul 30, 2012 at 9:24 PM, Susan Hares > wrote: > >> Nitin: > >> > >> Exposing some network intelligence can either be done in detail or > in some amount of summarization. > >> If you are doing detail, you have bandwidth issues. If you are > doing summarization or opacity, you are talking about layers of > information. > >> > >> Apps need to find out what they need to get. They do not need all > the details - just the fact they can get from point A to Point B (or > for multi-cast B/C/D). They need to where they can go to date other > applications. They need a match-maker for the application who > determine where the applications shall flow. Now, if they are smart - > like people going out to eat - they pick several ways go to eat traffic. > >> > >> The network orchestration then serves to be the paths to the place > to eat. This can either be distributed or centralized. > >> > >> If we have an Interface to routing, it need to have a two-layer > concept of exposing information. > >> > >> Sue Hares > >> > >> -----Original Message----- > >> From: irs-discuss-bounces@ietf.org > > [mailto:irs-discuss-bounces@ietf.org > ] On Behalf Of Nitin Bahadur > >> Sent: Monday, July 30, 2012 3:33 PM > >> To: James Kempf; Thomas Nadeau; irs-discuss@ietf.org > > >> Subject: Re: [irs-discuss] IRS Problem Statement Posted > >> > >> Hi James, > >> > >> This is not about splitting control plane and forwarding plane. It > is about exposing network intelligence in the network elements to an > external controller. > >> And it is about allowing an external controller to use that > information for enabling network-aware apps. And it is about allowing > apps to influence the > >> network element's RIB (not the FIB directly). > >> > >> Streaming is essential to allow for operations at scale...and avoid > a request/response gated mechanism. > >> > >> Hope that helps. > >> > >> Thanks > >> Nitin > >> > >> On 7/30/12 3:11 PM, "James Kempf" > wrote: > >> > >> I don't understand why streaming is specified in this draft. And I > don't understand why this draft isn't put in the Forces framework. > Forces is a framework explicitedly designed for device to controller > communication. Its major drawback it that it is a framework with a > hole in the middle, in that there are no specified devices. This draft > would fill that hole. > >> > >> I don't think it is necessary to have a problem statement for > router state update. Forces has already established that splitting the > control plane into a separate device is, in some cases, an attractive > design option. So I think this should be submitted to the Forces > working group, or, at least, recast in the Forces framework. > >> > >> jak > >> > >>> -----Original Message----- > >>> From: irs-discuss-bounces@ietf.org > > >>> [mailto:irs-discuss-bounces@ietf.org > ] On Behalf Of Thomas Nadeau > >>> Sent: Monday, July 30, 2012 11:18 AM > >>> To: irs-discuss@ietf.org > >>> Subject: [irs-discuss] IRS Problem Statement Posted > >>> > >>> > >>> > >>> Please review and discuss. > >>> > >>> Thanks, > >>> > >>> Tom, Alia, Ward > >>> > >>> > >>> http://lucidvision.com/draft-atlas-irs-problem-statement-00.txt > >>> > >>> > >>> _______________________________________________ > >>> 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 > >> > >> _______________________________________________ > >> 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 > > > > Sue: Use cases are key. The clarity of the use cases will guide > us. Please send USE cases. > > Here are three I just threw together. We can talk about refining these > tomorrow, if you like... My fingers got tired before my brain did. :-) > > Russ > > == > Optimized Exit Use Case > > Assume you have a network where there are two possible exit points > towards any set of destinations. The cost of using these links varies by > time, and the quality of the links is highly variable, but not > necessarily related to the actual load the local network is putting on > them (in other words, these are oversubscribed links shared with other > parallel networks or customers with unpredictable traffic patterns). > What you'd like to do is to use the lowest cost link until the quality > of the link reaches a specific level, and then switch to the higher cost > link. The point at which this link switch might occur may vary based on > time of day, because the RTO on specific traffic levels varies by the > time of day as well. > > So you have a problem with multiple variables: link quality (apparently > random from your perspective), link cost (varies by time of day), return > on investment (varies by time of day). Combined with this you have > multiple exit points, and you must draw traffic from an inside network > as efficiently as possible to the best exit point, as determined by > these various factors. > > The only well defined way to resolve this problem is to feed the > variables to an off router controller, calculate the best exit point on > some periodic basis, and then feed this information back into the > routing table. All solutions that can solve this problem today use route > injection into BGP, static route injection, or some other means to > direct traffic --difficult and error prone mechanisms. All of these > solutions also draw traffic only along links between the edge routers > themselves to put traffic on the best possible outbound link. > > With IRS, the best path could be calculated using any number of custom > written mechanisms, and the routes injected into the right places in the > network to effect the most efficient drawing of traffic to the best exit > point. Changes in the network environment could quickly cause traffic to > be shifted to alternate exit points when circumstances dictate. > > == > Denial of Service > > FlowSpec is designed to allow an AS to push a filter upstream, with the > ultimate goal being to block the source of DDoS and other attacks as > close to the origin of those attacks as possible. There are some > situations, however, where you would prefer to block an attack at all > edges, or throughout an entire local network. For instance, you might > want to block the forwarding of traffic within your network while you > are pushing FlowSpec updates upstream to block the traffic closer to the > source, or you might be dealing with an attack originating from multiple > points within your own network. > > While these responses are possible with standard routing, there is a > strong case to be made that routing information should not be mixed with > security response information within the routing domain (within an AS). > Mixing these two types of information can make network management more > difficult, and slow down the repair of a network during large scale > failures. It would be simpler to have a single controller in a network > tied to the various attack detection mechanisms that could directly > install the correct routing information to pull all attack traffic to a > central location, or to simply route the traffic to a null interface. > > An related use is that of pulling unknown traffic through specific > devices for analysis. A network operator may not want to drive all > traffic through traffic analysis devices simply because of cost and > quality of service degredation. A network operator could use IRS to > directly modify the routing tables on devices in the path of unknown or > possibly dangerous flows so this traffic is pulled through the correct > monitoring and analysis devices. > > == > Remote Service Routing > > In hub and spoke overlay networks, there is always an issue with > balancing between the information held in the spoke routing table, > optimal routing through the network underlying the overlay, and > mobility. Most solutions in this space use some form of centralized > route server that acts as a directory of all reachable destinations and > next hops, a protocol by which spoke devices and this route server > communicate, and caches at the remote sites. > > An IRS solution would use the same elements, but with a different > control plane. Remote sites would register (or advertise through some > standard routing protocol, such as BGP), the reachable destinations at > each site, along with the address of the router (or other device) used > to reach that destination. These would, as always, be stored in a route > server (or several redundant route servers) at a central location. > > When a remote site sends a set of packets to the central location that > are eventually destined to some other remote site, the central location > can forward this traffic, but at the same time simply directly insert > the correct routing information into the remote site's routing table. If > the location of the destination changes, the route server can directly > modify the routing information at the remote site as needed. > An interesting aspect of this solution is that no new and specialized > protocols are needed between the remote sites and the centralized route > server(s). Normal routing protocols can be used to notify the > centralized route server(s) of modifications in reachability > information, and the route server(s) can respond as needed, based on > local algorithms optimized for a particular application or network. For > instance, short lived flows might be allowed to simply pass through the > hub site with no reaction, while longer lived flows might warrant a > specific route to be installed in the remote router. Algorithms can also > be developed that would optimize traffic flow through the overlay, and > also to remove routing entries from remote devices when they are no > longer needed based on far greater intelligence than simple non-use for > some period of time. > > == > > > _______________________________________________ > 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 Return-Path: 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 9C26921E8044 for ; Thu, 2 Aug 2012 10:46:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Knh35qFLa9zL for ; Thu, 2 Aug 2012 10:46:28 -0700 (PDT) Received: from nm5-vm0.access.bullet.mail.sp2.yahoo.com (nm5-vm0.access.bullet.mail.sp2.yahoo.com [98.139.44.112]) by ietfa.amsl.com (Postfix) with SMTP id B7FD821E803F for ; Thu, 2 Aug 2012 10:46:28 -0700 (PDT) Received: from [98.139.44.102] by nm5.access.bullet.mail.sp2.yahoo.com with NNFMP; 02 Aug 2012 17:46:28 -0000 Received: from [98.139.44.85] by tm7.access.bullet.mail.sp2.yahoo.com with NNFMP; 02 Aug 2012 17:46:28 -0000 Received: from [127.0.0.1] by omp1022.access.mail.sp2.yahoo.com with NNFMP; 02 Aug 2012 17:46:28 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 451292.52781.bm@omp1022.access.mail.sp2.yahoo.com Received: (qmail 80776 invoked by uid 60001); 2 Aug 2012 17:46:27 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1343929587; bh=jwX5ELJvGKGQAT4seysqyR+iAeBlxEjjBJjyQM4Y9t0=; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=m/PHT0No4T9zg1opqZJp+RRtm3/CTbvGpooZUzKq2MSrys7auQMCDrlS3HWUjNty41V7UywJEknfNbnKg1xx3T5+TtWtq4LJKpFWdykT8RTQ3kW9MVv7w1EHlCiHKMWq4D4K+Xs1hRf9EsmaBktbhe6txBPl0jJf0tfRmX7qH3Q= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=Wdj4zBZAukeJAL2LFXi6s33nI/tXw1xoV+U3fgx0llS2bT6q9kM6X5uXQbtFti4kYkDUWlX+YC7E852BMgviqSifwPh9esWWxrozLWvhul5c6d5zXtjuSFlJl7ybQr4qbBIJEhRhZa2zpecJCpr5Lgr6muiCw4bFAnKH/C3R+k4=; X-YMail-OSG: KtALoc8VM1kWtRJQkygYqMx4lMtIVFWMyzkvMiuvpUtCTvn 4aMfNw5BbizvfoQnQL9kmTT4aJoIFvDblk0Ot8b2PQYArO1MiZnIJTBNQ0GZ v7r5OtZLC8nqdU.aekeR89J.nCy8N9DwKeMgpw09_RaHYLDRrjIyRnrbipXr dqoMc1R2jsKDMTBPuarjknuYmZ8PKNGgsLCrX75ypISELJsCzFNe6P7.xsxM VKNUMl2ZNE73yGm.r7zI33y9ZGNfQ8QvvAw5b127FaDpU.LeJdn2PlJir1Qa gm_tClBpWxRwTHsynOsOh2Hp.Pa61dG_Loo..9_UkHMGSuXZg8ESR1evDaMu w9zpdYcambPcPrjXSqNVtpsPpGSURuvZJhDdFzGfkLcJjX0eDBMb0vu9A0sH xSBRvktfxO3lLy6o4wUat._zXCcoZf5VJQvDxaEGW15YpEpN.VQkqGRY7Yb6 zpXQOlZ.L9pz5C52CIATKPkYUxbRi6p69cxeh1w-- Received: from [199.202.45.45] by web84520.mail.ne1.yahoo.com via HTTP; Thu, 02 Aug 2012 10:46:27 PDT X-Mailer: YahooMailWebService/0.8.120.356233 References: Message-ID: <1343929587.64917.YahooMailNeo@web84520.mail.ne1.yahoo.com> Date: Thu, 2 Aug 2012 10:46:27 -0700 (PDT) From: Ning So To: "irs-discuss@ietf.org" In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="683666909-50796147-1343929587=:64917" Subject: Re: [irs-discuss] irs-discuss Digest, Vol 2, Issue 3 X-BeenThere: irs-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Ning So List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2012 17:46:32 -0000 --683666909-50796147-1343929587=:64917 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable All,=0A=A0=0AIs Alia's presentation loaded anywhere?=A0 It's not on the mee= ting agenda page.=0A=A0=0ANing=0A=0A=0A________________________________=0AF= rom: "irs-discuss-request@ietf.org" =0ATo: ir= s-discuss@ietf.org =0ASent: Thursday, August 2, 2012 1:20 AM=0ASubject: irs= -discuss Digest, Vol 2, Issue 3=0A=0A----- Forwarded Message -----=0A=0AIf = you have received this digest without all the individual message=0Aattachme= nts you will need to update your digest options in your list=0Asubscription= .=A0 To do so, go to =0A=0Ahttps://www.ietf.org/mailman/listinfo/irs-discus= s=0A=0AClick the 'Unsubscribe or edit options' button, log in, and set "Get= =0AMIME or Plain Text Digests?" to MIME.=A0 You can set this option=0Agloba= lly for all the list digests you receive at this point.=0A=0A=0A=0ASend irs= -discuss mailing list submissions to=0A=A0=A0=A0 irs-discuss@ietf.org=0A=0A= To subscribe or unsubscribe via the World Wide Web, visit=0A=A0=A0=A0 https= ://www.ietf.org/mailman/listinfo/irs-discuss=0Aor, via email, send a messag= e with subject or body 'help' to=0A=A0=A0=A0 irs-discuss-request@ietf.org= =0A=0AYou can reach the person managing the list at=0A=A0=A0=A0 irs-discuss= -owner@ietf.org=0A=0AWhen replying, please edit your Subject line so it is = more specific=0Athan "Re: Contents of irs-discuss digest..."=0A=0AToday's T= opics:=0A=0A=A0 1. Re: I-D Action: draft-ward-irs-framework-00.txt (Alia At= las)=0A=A0 2. Re: I-D Action: draft-ward-irs-framework-00.txt (Joel M. Halp= ern)=0A=A0 3. Re: IRS Problem Statement Posted (Susan Hares)=0A=A0 4. Re: T= houghts on draft-ward-irs-framework (Russ White)=0AThanks!=0A=0AOn Wed, Aug= 1, 2012 at 6:54 PM, Susan Hares wrote:=0A> Alia:= =0A>=0A> I'll try to create a bibliography of things people should read.=A0= It will be mid-next week since I'm away from my home library on the SDN to= pic.=0A>=0A> Sue=0A>=0A> -----Original Message-----=0A> From: Alia Atlas [m= ailto:akatlas@gmail.com]=0A> Sent: Wednesday, August 01, 2012 3:51 PM=0A> T= o: Susan Hares=0A> Cc: Joel M. Halpern; irs-discuss@ietf.org=0A> Subject: R= e: [irs-discuss] I-D Action: draft-ward-irs-framework-00.txt=0A>=0A> Sue,= =0A>=0A> I look forward to talking with you more off-line on the policy and= =0A> local-pref research and issues.=A0 If you have suggestions on good=0A>= background research to read, by all means send it to the list so=0A> other= s can get up to speed as well.=0A>=0A> On the atomic transaction semantics = question, let's get a bit further=0A> into the use-cases and framework - an= d then have a focused discussion.=0A>=A0 I'm not opposed to it forever or i= f it is necessary - just would like=0A> to thoroughly analyze if it is a re= al requirement.=0A>=0A> Do others have opinions and perspective on this?=0A= >=0A> Alia=0A>=0A> On Wed, Aug 1, 2012 at 1:58 PM, Susan Hares wrote:=0A>> Alia:=0A>>=0A>> The hierarchical of interfaces (To= routing system) is one of the areas that requires prioritization. The prio= ritization must be able to handle "preempt me", "after you", and "after me"= .=0A>>=0A>> It is also key to understand that irs system must handle multi-= interfaces struggles at the lowest layer.=A0 You need to look at the MIF WG= (+/-) for some of the struggles of mobility.=0A>>=0A>> -----Original Messa= ge-----=0A>> From: Alia Atlas [mailto:akatlas@gmail.com]=0A>> Sent: Monday,= July 30, 2012 6:33 PM=0A>> To: Susan Hares=0A>> Cc: Joel M. Halpern; irs-d= iscuss@ietf.org=0A>> Subject: Re: [irs-discuss] I-D Action: draft-ward-irs-= framework-00.txt=0A>>=0A>> Hi Sue,=0A>>=0A>> On Mon, Jul 30, 2012 at 9:16 P= M, Susan Hares wrote:=0A>>> Joel and irs-folks:=0A= >>>=0A>>> +1 on Joel.=0A>>>=0A>>>=A0 Beyond your comments, the requirement = prioritization of the interworking of these interfaces is not clearly delin= eated in this work. This type of prioritization and sequencing is key to mu= lti-interfaces operation on the monitoring, configuration or insertion of i= nformation into the depth.=0A>>=0A>> [Alia] Can you further clarify, maybe = with an example, which aspect=0A>> you are thinking of?=A0 Do you mean the = ability of an application to=0A>> access multiple sub-interfaces?=A0 The in= teraction of operations=0A>> requested by differerent applications?=0A>>=0A= >>> In addition, if you are going to do configuration with roll-forward/rol= l-back - you need a transaction based processing.=0A>>=0A>> [Alia] I'm pret= ty sure that I avoided the word "transaction" in both=0A>> drafts.=A0 That = was deliberate.=A0 Of course, we can have a discussion=0A>> about whether o= r not some form of transactions might be desirable.=A0 I=0A>> am concerned = about their potentially heavy-weight nature.=0A>>=0A>>> Therefore, you've s= kipped even requiring the hard problems.=0A>>=0A>> [Alia] Can I optimistica= lly pretend that means that the requirements=0A>> we do have don't seem too= hard?=A0 For the responsiveness and throughput=0A>> goals, I've put a stak= e in the ground to avoid transaction-based=0A>> semantics.=A0 Naturally, th= e hordes can run over that stake, if=0A>> necessary.=0A>>=0A>> [Sue]: The r= equirements are necessary even if they are hard.=0A>>=0A>> [Alia] For the i= nteraction between different layers of sub-interfaces,=0A>> I've been assum= ing that we'll define the interactions between the=0A>> layers based on how= they are generally done.=A0 For instance, perhaps we=0A>> standardize the = idea of preference value - and then the RIB can pick=0A>> the best route ba= sed upon those preferences.=A0 For interaction between=0A>> different appli= cations, I think there's a mixture of=0A>> authorization/authentication to = get right plus a good set of events=0A>> that an application could register= for.=0A>>=0A>> [Sue]: As someone who has lived with "local pref" in BGP fo= r a long time, there is a bit more to unwrap in the statement.=A0 However, = it breaks down to prioritization that is pre-set by preferences.=0A>>=0A>> = The policy issues behind the local-pref setting have been studied by the BG= P policy community. This is substantial good work on this from the academic= researchers, vendors, and operator. Griffins, Rexford, Bush, Feamster, ...= .. and lots others are much better on the theory than I am.=0A>>=0A>>> Is t= his just the -00.draft?=0A>>=0A>> [Alia] Certainly, I expect that we'll unc= over more requirements as we=0A>> go along.=A0 As I said, some of this is i= nitially setting parts=A0 out of=0A>> scope.=0A>>=0A>> ---> Scope =3D=3D go= od.=A0 Setting scope allows us to pick a piece of this work and standardize= it for interoperability.=0A>>=0A>> Alia=0A>>=0A>>> Sue=0A>>>=0A>>>=0A>>>= =0A>>> -----Original Message-----=0A>>> From: irs-discuss-bounces@ietf.org = [mailto:irs-discuss-bounces@ietf.org] On Behalf Of Joel M. Halpern=0A>>> Se= nt: Monday, July 30, 2012 3:15 PM=0A>>> To: irs-discuss@ietf.org=0A>>> Subj= ect: Re: [irs-discuss] I-D Action: draft-ward-irs-framework-00.txt=0A>>>=0A= >>> I am finding this document quite confusing.=0A>>>=0A>>> The primary con= fusion is that the document first says that it is about=0A>>> information t= hat can not be manipulated with existing systems, and then=0A>>> proceeds t= o give a list of use cases all of which can be manipulated=0A>>> with exist= ing systems at a suitable degree of abstraction.=0A>>>=0A>>> As a lesser co= nfusion, the document says that "streaming" is important,=0A>>> but then de= scribes "streaming" as "fast, interactive access."=A0 That is=0A>>> not str= eaming.=A0 And depending upon what one means by interactive, plenty=0A>>> o= f systems provide "fest, interactive access."=A0 I realize the document=0A>= >> later goes on tot talk about speed and frequency of state updates.=A0 Bu= t=0A>>> that section simply reasserts the earlier terms withotu better=0A>>= > description or justification.=0A>>>=0A>>> Yours,=0A>>> Joel=0A>>>=0A>>> O= n 7/30/2012 2:08 PM, internet-drafts@ietf.org wrote:=0A>>>>=0A>>>> A New In= ternet-Draft is available from the on-line Internet-Drafts directories.=0A>= >>>=0A>>>>=0A>>>>=A0 =A0 =A0 Title=A0 =A0 =A0 =A0 =A0 : Interface to the Ro= uting System Framework=0A>>>>=A0 =A0 =A0 Author(s)=A0 =A0 =A0 : Alia Atlas= =0A>>>>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Thomas Nadea= u=0A>>>>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Dave Ward= =0A>>>>=A0 =A0 =A0 Filename=A0 =A0 =A0 =A0 : draft-ward-irs-framework-00.tx= t=0A>>>>=A0 =A0 =A0 Pages=A0 =A0 =A0 =A0 =A0 : 21=0A>>>>=A0 =A0 =A0 Date=A0= =A0 =A0 =A0 =A0 =A0 : 2012-07-30=0A>>>>=0A>>>> Abstract:=0A>>>>=A0 =A0 Thi= s document describes a framework for a standard, programmatic=0A>>>>=A0 =A0= interface for full-duplex, streaming state transfer in and out of the=0A>>= >>=A0 =A0 Internet's routing system.=A0 It lists the information that might= be=0A>>>>=A0 =A0 exchanged over the interface, and describes the uses of a= n interface=0A>>>>=A0 =A0 to the Internet routing system.=0A>>>>=0A>>> ____= ___________________________________________=0A>>> irs-discuss mailing list= =0A>>> irs-discuss@ietf.org=0A>>> https://www.ietf.org/mailman/listinfo/irs= -discuss=0A>>> _______________________________________________=0A>>> irs-di= scuss mailing list=0A>>> irs-discuss@ietf.org=0A>>> https://www.ietf.org/ma= ilman/listinfo/irs-discuss=0A=0AWith regard to transaction issues, we discu= ssed this extensively when =0Adoing ForCES.=A0 We concluded that the answer= we needed was "yes and no". =0A=A0 That is, the protocol has mechanisms wh= ich can be used for =0Atransactional integrity, including integrity across = interactions with =0Amultiple FEs.=A0 However, the protocol does not requir= e the CE to use =0Athose mechanisms.=A0 In fact, if it does not even want e= xplicit acks (the =0Amessages go over TCP), it can defer that until it gets= to a good "please =0Aconfirm" point.=0AAnd in the efforts to use this late= r, having this range of options has =0Abeen useful.=0A=0AYours,=0AJoel=0A= =0AOn 8/1/2012 6:51 PM, Alia Atlas wrote:=0A> Sue,=0A>=0A> I look forward t= o talking with you more off-line on the policy and=0A> local-pref research = and issues.=A0 If you have suggestions on good=0A> background research to r= ead, by all means send it to the list so=0A> others can get up to speed as = well.=0A>=0A> On the atomic transaction semantics question, let's get a bit= further=0A> into the use-cases and framework - and then have a focused dis= cussion.=0A>=A0 I'm not opposed to it forever or if it is necessary - just = would like=0A> to thoroughly analyze if it is a real requirement.=0A>=0A> D= o others have opinions and perspective on this?=0A>=0A> Alia=0A>=0A> On Wed= , Aug 1, 2012 at 1:58 PM, Susan Hares wrote:=0A>> = Alia:=0A>>=0A>> The hierarchical of interfaces (To routing system) is one o= f the areas that requires prioritization. The prioritization must be able t= o handle "preempt me", "after you", and "after me".=0A>>=0A>> It is also ke= y to understand that irs system must handle multi-interfaces struggles at t= he lowest layer.=A0 You need to look at the MIF WG (+/-) for some of the st= ruggles of mobility.=0A>>=0A>> -----Original Message-----=0A>> From: Alia A= tlas [mailto:akatlas@gmail.com]=0A>> Sent: Monday, July 30, 2012 6:33 PM=0A= >> To: Susan Hares=0A>> Cc: Joel M. Halpern; irs-discuss@ietf.org=0A>> Subj= ect: Re: [irs-discuss] I-D Action: draft-ward-irs-framework-00.txt=0A>>=0A>= > Hi Sue,=0A>>=0A>> On Mon, Jul 30, 2012 at 9:16 PM, Susan Hares wrote:=0A>>> Joel and irs-folks:=0A>>>=0A>>> +1 on Joel.=0A>= >>=0A>>>=A0 Beyond your comments, the requirement prioritization of the int= erworking of these interfaces is not clearly delineated in this work. This = type of prioritization and sequencing is key to multi-interfaces operation = on the monitoring, configuration or insertion of information into the depth= .=0A>>=0A>> [Alia] Can you further clarify, maybe with an example, which as= pect=0A>> you are thinking of?=A0 Do you mean the ability of an application= to=0A>> access multiple sub-interfaces?=A0 The interaction of operations= =0A>> requested by differerent applications?=0A>>=0A>>> In addition, if you= are going to do configuration with roll-forward/roll-back - you need a tra= nsaction based processing.=0A>>=0A>> [Alia] I'm pretty sure that I avoided = the word "transaction" in both=0A>> drafts.=A0 That was deliberate.=A0 Of c= ourse, we can have a discussion=0A>> about whether or not some form of tran= sactions might be desirable.=A0 I=0A>> am concerned about their potentially= heavy-weight nature.=0A>>=0A>>> Therefore, you've skipped even requiring t= he hard problems.=0A>>=0A>> [Alia] Can I optimistically pretend that means = that the requirements=0A>> we do have don't seem too hard?=A0 For the respo= nsiveness and throughput=0A>> goals, I've put a stake in the ground to avoi= d transaction-based=0A>> semantics.=A0 Naturally, the hordes can run over t= hat stake, if=0A>> necessary.=0A>>=0A>> [Sue]: The requirements are necessa= ry even if they are hard.=0A>>=0A>> [Alia] For the interaction between diff= erent layers of sub-interfaces,=0A>> I've been assuming that we'll define t= he interactions between the=0A>> layers based on how they are generally don= e.=A0 For instance, perhaps we=0A>> standardize the idea of preference valu= e - and then the RIB can pick=0A>> the best route based upon those preferen= ces.=A0 For interaction between=0A>> different applications, I think there'= s a mixture of=0A>> authorization/authentication to get right plus a good s= et of events=0A>> that an application could register for.=0A>>=0A>> [Sue]: = As someone who has lived with "local pref" in BGP for a long time, there is= a bit more to unwrap in the statement.=A0 However, it breaks down to prior= itization that is pre-set by preferences.=0A>>=0A>> The policy issues behin= d the local-pref setting have been studied by the BGP policy community. Thi= s is substantial good work on this from the academic researchers, vendors, = and operator. Griffins, Rexford, Bush, Feamster, ..... and lots others are = much better on the theory than I am.=0A>>=0A>>> Is this just the -00.draft?= =0A>>=0A>> [Alia] Certainly, I expect that we'll uncover more requirements = as we=0A>> go along.=A0 As I said, some of this is initially setting parts= =A0 out of=0A>> scope.=0A>>=0A>> ---> Scope =3D=3D good.=A0 Setting scope a= llows us to pick a piece of this work and standardize it for interoperabili= ty.=0A>>=0A>> Alia=0A>>=0A>>> Sue=0A>>>=0A>>>=0A>>>=0A>>> -----Original Mes= sage-----=0A>>> From: irs-discuss-bounces@ietf.org [mailto:irs-discuss-boun= ces@ietf.org] On Behalf Of Joel M. Halpern=0A>>> Sent: Monday, July 30, 201= 2 3:15 PM=0A>>> To: irs-discuss@ietf.org=0A>>> Subject: Re: [irs-discuss] I= -D Action: draft-ward-irs-framework-00.txt=0A>>>=0A>>> I am finding this do= cument quite confusing.=0A>>>=0A>>> The primary confusion is that the docum= ent first says that it is about=0A>>> information that can not be manipulat= ed with existing systems, and then=0A>>> proceeds to give a list of use cas= es all of which can be manipulated=0A>>> with existing systems at a suitabl= e degree of abstraction.=0A>>>=0A>>> As a lesser confusion, the document sa= ys that "streaming" is important,=0A>>> but then describes "streaming" as "= fast, interactive access."=A0 That is=0A>>> not streaming.=A0 And depending= upon what one means by interactive, plenty=0A>>> of systems provide "fest,= interactive access."=A0 I realize the document=0A>>> later goes on tot tal= k about speed and frequency of state updates.=A0 But=0A>>> that section sim= ply reasserts the earlier terms withotu better=0A>>> description or justifi= cation.=0A>>>=0A>>> Yours,=0A>>> Joel=0A>>>=0A>>> On 7/30/2012 2:08 PM, int= ernet-drafts@ietf.org wrote:=0A>>>>=0A>>>> A New Internet-Draft is availabl= e from the on-line Internet-Drafts directories.=0A>>>>=0A>>>>=0A>>>>=A0 =A0= =A0 =A0 Title=A0 =A0 =A0 =A0 =A0 : Interface to the Routing System Framewo= rk=0A>>>>=A0 =A0 =A0 =A0 Author(s)=A0 =A0 =A0 : Alia Atlas=0A>>>>=A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Thomas Nadeau=0A>>>>=A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Dave Ward=0A>>>>=A0 =A0 = =A0 =A0 Filename=A0 =A0 =A0 =A0 : draft-ward-irs-framework-00.txt=0A>>>>=A0= =A0 =A0 =A0 Pages=A0 =A0 =A0 =A0 =A0 : 21=0A>>>>=A0 =A0 =A0 =A0 Date=A0 = =A0 =A0 =A0 =A0 =A0 : 2012-07-30=0A>>>>=0A>>>> Abstract:=0A>>>>=A0 =A0 =A0 = This document describes a framework for a standard, programmatic=0A>>>>=A0 = =A0 =A0 interface for full-duplex, streaming state transfer in and out of t= he=0A>>>>=A0 =A0 =A0 Internet's routing system.=A0 It lists the information= that might be=0A>>>>=A0 =A0 =A0 exchanged over the interface, and describe= s the uses of an interface=0A>>>>=A0 =A0 =A0 to the Internet routing system= .=0A>>>>=0A>>> _______________________________________________=0A>>> irs-di= scuss mailing list=0A>>> irs-discuss@ietf.org=0A>>> https://www.ietf.org/ma= ilman/listinfo/irs-discuss=0A>>> __________________________________________= _____=0A>>> irs-discuss mailing list=0A>>> irs-discuss@ietf.org=0A>>> https= ://www.ietf.org/mailman/listinfo/irs-discuss=0A>=0A=0AAlia:=0A=0AI'm going = to check with a colleague who has been doing lots of model work to see if h= e's got a better.=A0 More later.=0A=0ASue =0A=0A-----Original Message-----= =0AFrom: Alia Atlas [mailto:akatlas@gmail.com] =0ASent: Wednesday, August 0= 1, 2012 3:41 PM=0ATo: Susan Hares=0ACc: Nitin Bahadur; James Kempf; Thomas = Nadeau; irs-discuss@ietf.org=0ASubject: Re: [irs-discuss] IRS Problem State= ment Posted=0A=0ASue,=0A=0AIn this case, I was thinking of "translating" fr= om a "higher=0Aabstraction layer" to a "lower abstraction layer".=0A=0ADo y= ou have a better/different term to suggest?=A0 I agree that clarity=0Aof te= rminology is important.=0A=0AAlia=0A=0AOn Wed, Aug 1, 2012 at 2:03 PM, Susa= n Hares wrote:=0A> Alia:=0A>=0A> +1 on abstraction= + filters (abstract/detail) IRS fits at the routing control.=0A>=0A> The r= eal question about translation is what the translation is doing.=A0 Is it t= ranslating one thing to another at the same layer of abstraction (e.g., Spa= nish/English, Ascii/ebcdic) or is it doing abstraction/detail change.=0A>= =0A> I define translation as the same layer of abstraction.=A0 Some people = suggest translation =3D abstract/detailing.=A0 We first need a common way t= o talk about the difference.=0A>=0A> Sue=0A>=0A> By the way --- I'm thrille= d about the pace of the discussion.=0A>=0A>=0A> -----Original Message-----= =0A> From: Alia Atlas [mailto:akatlas@gmail.com]=0A> Sent: Monday, July 30,= 2012 6:40 PM=0A> To: Susan Hares=0A> Cc: Nitin Bahadur; James Kempf; Thoma= s Nadeau; irs-discuss@ietf.org=0A> Subject: Re: [irs-discuss] IRS Problem S= tatement Posted=0A>=0A> Sue,=0A>=0A> I certainly agree that we want IRS to = have the ability to express=0A> information at different abstraction layers= and filtered on request.=0A>=0A> There may still be a gap between the "net= work OS abstractions" and IRS=0A> sub-interfaces; I'd be surprised if there= weren't.=A0 IRS is to provide=0A> the bottom-up control strings.=0A>=0A> I= MHO, it's reasonable to have an entity that manages the translation.=0A> Fo= r instance, one doesn't need a PCE-equiv in every application - nor=0A> in = every router; that might be an entity in between.=0A>=0A> The quantity of i= nformation is part of why explicit filtering and=0A> hopefully abstraction = layers should be built into the data-models.=0A>=0A> Alia=0A>=0A> On Mon, J= ul 30, 2012 at 9:24 PM, Susan Hares wrote:=0A>> Ni= tin:=0A>>=0A>> Exposing some network intelligence can either be done in det= ail or in some amount of summarization.=0A>> If you are doing detail, you h= ave bandwidth issues. If you are doing summarization or opacity, you are ta= lking about layers of information.=0A>>=0A>> Apps need to find out what the= y need to get. They do not need all the details - just the fact they can ge= t from point A to Point B (or for multi-cast B/C/D). They need to where the= y can go to date other applications.=A0 They need a match-maker for the app= lication who determine where the applications shall flow.=A0 Now, if they a= re smart - like people going out to eat - they pick several ways go to eat = traffic.=0A>>=0A>> The network orchestration then serves to be the paths to= the place to eat.=A0 This can either be distributed or centralized.=0A>>= =0A>> If we have an Interface to routing, it need to have a two-layer conce= pt of exposing information.=0A>>=0A>> Sue Hares=0A>>=0A>> -----Original Mes= sage-----=0A>> From: irs-discuss-bounces@ietf.org [mailto:irs-discuss-bounc= es@ietf.org] On Behalf Of Nitin Bahadur=0A>> Sent: Monday, July 30, 2012 3:= 33 PM=0A>> To: James Kempf; Thomas Nadeau; irs-discuss@ietf.org=0A>> Subjec= t: Re: [irs-discuss] IRS Problem Statement Posted=0A>>=0A>> Hi James,=0A>>= =0A>> This is not about splitting control plane and forwarding plane. It is= about exposing network intelligence in the network elements to an external= controller.=0A>> And it is about allowing an external controller to use th= at information for enabling network-aware apps. And it is about allowing ap= ps to influence the=0A>> network element's RIB (not the FIB directly).=0A>>= =0A>> Streaming is essential to allow for operations at scale...and avoid a= request/response gated mechanism.=0A>>=0A>> Hope that helps.=0A>>=0A>> Tha= nks=0A>> Nitin=0A>>=0A>> On 7/30/12 3:11 PM, "James Kempf" wrote:=0A>>=0A>> I don't understand why streaming is specified i= n this draft. And I don't understand why this draft isn't put in the Forces= framework. Forces is a framework explicitedly designed for device to contr= oller communication. Its major drawback it that it is a framework with a ho= le in the middle, in that there are no specified devices. This draft would = fill that hole.=0A>>=0A>> I don't think it is necessary to have a problem s= tatement for router state update. Forces has already established that split= ting the control plane into a separate device is, in some cases, an attract= ive design option. So I think this should be submitted to the Forces workin= g group, or, at least, recast in the Forces framework.=0A>>=0A>>=A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 jak=0A>>=0A>>> -----Original Message-----=0A>>> From: = irs-discuss-bounces@ietf.org=0A>>> [mailto:irs-discuss-bounces@ietf.org] On= Behalf Of Thomas Nadeau=0A>>> Sent: Monday, July 30, 2012 11:18 AM=0A>>> T= o: irs-discuss@ietf.org=0A>>> Subject: [irs-discuss] IRS Problem Statement = Posted=0A>>>=0A>>>=0A>>>=0A>>> Please review and discuss.=0A>>>=0A>>> Thank= s,=0A>>>=0A>>> Tom, Alia, Ward=0A>>>=0A>>>=0A>>> http://lucidvision.com/dra= ft-atlas-irs-problem-statement-00.txt=0A>>>=0A>>>=0A>>> ___________________= ____________________________=0A>>> irs-discuss mailing list=0A>>> irs-discu= ss@ietf.org=0A>>> https://www.ietf.org/mailman/listinfo/irs-discuss=0A>>>= =0A>> _______________________________________________=0A>> irs-discuss mail= ing list=0A>> irs-discuss@ietf.org=0A>> https://www.ietf.org/mailman/listin= fo/irs-discuss=0A>>=0A>> _______________________________________________=0A= >> irs-discuss mailing list=0A>> irs-discuss@ietf.org=0A>> https://www.ietf= .org/mailman/listinfo/irs-discuss=0A>> ____________________________________= ___________=0A>> irs-discuss mailing list=0A>> irs-discuss@ietf.org=0A>> ht= tps://www.ietf.org/mailman/listinfo/irs-discuss=0A=0A=0A> Sue: Use cases ar= e key.=A0 The clarity of the use cases will guide us.=A0 Please send USE ca= ses.=0A=0AHere are three I just threw together. We can talk about refining = these=0Atomorrow, if you like... My fingers got tired before my brain did. = :-)=0A=0ARuss=0A=0A=3D=3D=0AOptimized Exit Use Case=0A=0AAssume you have a = network where there are two possible exit points=0Atowards any set of desti= nations. The cost of using these links varies by=0Atime, and the quality of= the links is highly variable, but not=0Anecessarily related to the actual = load the local network is putting on=0Athem (in other words, these are over= subscribed links shared with other=0Aparallel networks or customers with un= predictable traffic patterns).=0AWhat you'd like to do is to use the lowest= cost link until the quality=0Aof the link reaches a specific level, and th= en switch to the higher cost=0Alink. The point at which this link switch mi= ght occur may vary based on=0Atime of day, because the RTO on specific traf= fic levels varies by the=0Atime of day as well.=0A=0ASo you have a problem = with multiple variables: link quality (apparently=0Arandom from your perspe= ctive), link cost (varies by time of day), return=0Aon investment (varies b= y time of day). Combined with this you have=0Amultiple exit points, and you= must draw traffic from an inside network=0Aas efficiently as possible to t= he best exit point, as determined by=0Athese various factors.=0A=0AThe only= well defined way to resolve this problem is to feed the=0Avariables to an = off router controller, calculate the best exit point on=0Asome periodic bas= is, and then feed this information back into the=0Arouting table. All solut= ions that can solve this problem today use route=0Ainjection into BGP, stat= ic route injection, or some other means to=0Adirect traffic --difficult and= error prone mechanisms. All of these=0Asolutions also draw traffic only al= ong links between the edge routers=0Athemselves to put traffic on the best = possible outbound link.=0A=0AWith IRS, the best path could be calculated us= ing any number of custom=0Awritten mechanisms, and the routes injected into= the right places in the=0Anetwork to effect the most efficient drawing of = traffic to the best exit=0Apoint. Changes in the network environment could = quickly cause traffic to=0Abe shifted to alternate exit points when circums= tances dictate.=0A=0A=3D=3D=0ADenial of Service=0A=0AFlowSpec is designed t= o allow an AS to push a filter upstream, with the=0Aultimate goal being to = block the source of DDoS and other attacks as=0Aclose to the origin of thos= e attacks as possible. There are some=0Asituations, however, where you woul= d prefer to block an attack at all=0Aedges, or throughout an entire local n= etwork. For instance, you might=0Awant to block the forwarding of traffic w= ithin your network while you=0Aare pushing FlowSpec updates upstream to blo= ck the traffic closer to the=0Asource, or you might be dealing with an atta= ck originating from multiple=0Apoints within your own network.=0A=0AWhile t= hese responses are possible with standard routing, there is a=0Astrong case= to be made that routing information should not be mixed with=0Asecurity re= sponse information within the routing domain (within an AS).=0AMixing these= two types of information can make network management more=0Adifficult, and= slow down the repair of a network during large scale=0Afailures. It would = be simpler to have a single controller in a network=0Atied to the various a= ttack detection mechanisms that could directly=0Ainstall the correct routin= g information to pull all attack traffic to a=0Acentral location, or to sim= ply route the traffic to a null interface.=0A=0AAn related use is that of p= ulling unknown traffic through specific=0Adevices for analysis. A network o= perator may not want to drive all=0Atraffic through traffic analysis device= s simply because of cost and=0Aquality of service degredation. A network op= erator could use IRS to=0Adirectly modify the routing tables on devices in = the path of unknown or=0Apossibly dangerous flows so this traffic is pulled= through the correct=0Amonitoring and analysis devices.=0A=0A=3D=3D=0ARemot= e Service Routing=0A=0AIn hub and spoke overlay networks, there is always a= n issue with=0Abalancing between the information held in the spoke routing = table,=0Aoptimal routing through the network underlying the overlay, and=0A= mobility. Most solutions in this space use some form of centralized=0Aroute= server that acts as a directory of all reachable destinations and=0Anext h= ops, a protocol by which spoke devices and this route server=0Acommunicate,= and caches at the remote sites.=0A=0AAn IRS solution would use the same el= ements, but with a different=0Acontrol plane. Remote sites would register (= or advertise through some=0Astandard routing protocol, such as BGP), the re= achable destinations at=0Aeach site, along with the address of the router (= or other device) used=0Ato reach that destination. These would, as always, = be stored in a route=0Aserver (or several redundant route servers) at a cen= tral location.=0A=0AWhen a remote site sends a set of packets to the centra= l location that=0Aare eventually destined to some other remote site, the ce= ntral location=0Acan forward this traffic, but at the same time simply dire= ctly insert=0Athe correct routing information into the remote site's routin= g table. If=0Athe location of the destination changes, the route server can= directly=0Amodify the routing information at the remote site as needed.=0A= An interesting aspect of this solution is that no new and specialized=0Apro= tocols are needed between the remote sites and the centralized route=0Aserv= er(s). Normal routing protocols can be used to notify the=0Acentralized rou= te server(s) of modifications in reachability=0Ainformation, and the route = server(s) can respond as needed, based on=0Alocal algorithms optimized for = a particular application or network. For=0Ainstance, short lived flows migh= t be allowed to simply pass through the=0Ahub site with no reaction, while = longer lived flows might warrant a=0Aspecific route to be installed in the = remote router. Algorithms can also=0Abe developed that would optimize traff= ic flow through the overlay, and=0Aalso to remove routing entries from remo= te devices when they are no=0Alonger needed based on far greater intelligen= ce than simple non-use for=0Asome period of time.=0A=0A=3D=3D=0A=0A=0A_____= __________________________________________=0Airs-discuss mailing list=0Airs= -discuss@ietf.org=0Ahttps://www.ietf.org/mailman/listinfo/irs-discuss --683666909-50796147-1343929587=:64917 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
All,
 
Is Alia's presentati= on loaded anywhere?  It's not on the meeting agenda page.
 
Ning

From:= "irs-discuss-request@ietf.org" <irs-discuss-request@ietf.org= >
To: irs-discuss@iet= f.org
Sent: Thursday, A= ugust 2, 2012 1:20 AM
Subject: irs-discuss Digest, Vol 2, Issue 3

----- Forward= ed Message -----

If you have received this digest without all the in= dividual message
attachments you will need to update your digest options= in your list
subscription.  To do so, go to

https://www.ietf.org/mailman/listinfo/irs-discuss

Click the 'Un= subscribe or edit options' button, log in, and set "Get
MIME or Plain Te= xt Digests?" to MIME.  You can set this option
globally for all the= list digests you receive at this point.



Send irs-discuss ma= iling list submissions to
    irs-discuss@ietf.org

To subscribe or unsubscribe via the World Wide Web, visit
&nbs= p;   https://www.ietf.org/mailman/listinfo/irs-discuss
= or, via email, send a message with subject or body 'help' to
  = ;  irs-discuss-request@ietf.org

You ca= n reach the person managing the list at
    irs= -discuss-owner@ietf.org

When replying, please edit your Subject = line so it is more specific
than "Re: Contents of irs-discuss digest..."=

Today's Topics:

  1. Re: I-D Action: draft-ward-irs-fra= mework-00.txt (Alia Atlas)
  2. Re: I-D Action: draft-ward-irs-fram= ework-00.txt (Joel M. Halpern)
  3. Re: IRS Problem Statement Poste= d (Susan Hares)
  4. Re: Thoughts on draft-ward-irs-framework (Russ= White)
Thanks!

On Wed, Aug 1, 2012 at 6:54 PM, Susan Hares <<= A href=3D"mailto:susan.hares@huawei.com" ymailto=3D"mailto:susan.hares@huaw= ei.com">susan.hares@huawei.com> wrote:
> Alia:
>
>= I'll try to create a bibliography of things people should read.  It w= ill be mid-next week since I'm away from my home library on the SDN topic.
>
> Sue
>
> -----Original Message-----
&= gt; From: Alia Atlas [mailto:akatlas@gmail.com]
> Sent: Wednesda= y, August 01, 2012 3:51 PM
> To: Susan Hares
> Cc: Joel M. Halp= ern; irs-discuss@ietf.org
> Subject: Re: [irs-discuss] I-D A= ction: draft-ward-irs-framework-00.txt
>
> Sue,
>
>= I look forward to talking with you more off-line on the policy and
>= local-pref research and issues.  If you have suggestions on good
&= gt; background research to read, by all means send it to the list so
>= ; others can get up to speed as well.
>
> On the atomic transac= tion semantics question, let's get a bit further
> into the use-cases= and framework - and then have a focused discussion.
>  I'm not opposed to it forever or if it is necessary - just would like
> to t= horoughly analyze if it is a real requirement.
>
> Do others ha= ve opinions and perspective on this?
>
> Alia
>
> O= n Wed, Aug 1, 2012 at 1:58 PM, Susan Hares <susan.hares@huawei.= com> wrote:
>> Alia:
>>
>> The hierarchic= al of interfaces (To routing system) is one of the areas that requires prio= ritization. The prioritization must be able to handle "preempt me", "after = you", and "after me".
>>
>> It is also key to understand = that irs system must handle multi-interfaces struggles at the lowest layer.=   You need to look at the MIF WG (+/-) for some of the struggles of mo= bility.
>>
>> -----Original Message-----
>> From= : Alia Atlas [mailto:akatlas@gmail.com]
>> Se= nt: Monday, July 30, 2012 6:33 PM
>> To: Susan Hares
>> C= c: Joel M. Halpern; irs-discuss@ietf.org
>> Subject: Re: = [irs-discuss] I-D Action: draft-ward-irs-framework-00.txt
>>
&g= t;> Hi Sue,
>>
>> On Mon, Jul 30, 2012 at 9:16 PM, Sus= an Hares <susan.hares@huawei.com> wrote:
>>>= Joel and irs-folks:
>>>
>>> +1 on Joel.
>>= ;>
>>>  Beyond your comments, the requirement prioritiz= ation of the interworking of these interfaces is not clearly delineated in = this work. This type of prioritization and sequencing is key to multi-inter= faces operation on the monitoring, configuration or insertion of informatio= n into the depth.
>>
>> [Alia] Can you further clarify, ma= ybe with an example, which aspect
>> you are thinking of?  Do= you mean the ability of an application to
>> access multiple sub-= interfaces?  The interaction of operations
>> requested by di= ffererent applications?
>>
>>> In addition, if you are= going to do configuration with roll-forward/roll-back - you need a transac= tion based processing.
>>
>> [Alia] I'm pretty sure that = I avoided the word "transaction" in both
>> drafts.  That was= deliberate.  Of course, we can have a discussion
>> about wh= ether or not some form of transactions might be desirable.  I
>&= gt; am concerned about their potentially heavy-weight nature.
>>>>> Therefore, you've skipped even requiring the hard problems.<= BR>>>
>> [Alia] Can I optimistically pretend that means that the requirements
>> we do have don't seem too hard?&nb= sp; For the responsiveness and throughput
>> goals, I've put a sta= ke in the ground to avoid transaction-based
>> semantics.  Na= turally, the hordes can run over that stake, if
>> necessary.
&= gt;>
>> [Sue]: The requirements are necessary even if they are = hard.
>>
>> [Alia] For the interaction between different = layers of sub-interfaces,
>> I've been assuming that we'll define = the interactions between the
>> layers based on how they are gener= ally done.  For instance, perhaps we
>> standardize the idea = of preference value - and then the RIB can pick
>> the best route = based upon those preferences.  For interaction between
>> dif= ferent applications, I think there's a mixture of
>> authorization= /authentication to get right plus a good set of events
>> that an application could register for.
>>
>> [Sue]: As = someone who has lived with "local pref" in BGP for a long time, there is a = bit more to unwrap in the statement.  However, it breaks down to prior= itization that is pre-set by preferences.
>>
>> The polic= y issues behind the local-pref setting have been studied by the BGP policy = community. This is substantial good work on this from the academic research= ers, vendors, and operator. Griffins, Rexford, Bush, Feamster, ..... and lo= ts others are much better on the theory than I am.
>>
>>&= gt; Is this just the -00.draft?
>>
>> [Alia] Certainly, I= expect that we'll uncover more requirements as we
>> go along.&nb= sp; As I said, some of this is initially setting parts  out of
>= > scope.
>>
>> ---> Scope =3D=3D good.  Settin= g scope allows us to pick a piece of this work and standardize it for interoperability.
>>
>> Alia
>>
>>>= Sue
>>>
>>>
>>>
>>> -----O= riginal Message-----
>>> From: irs-discuss= -bounces@ietf.org [mailto:irs-discuss-bounces@ietf= .org] On Behalf Of Joel M. Halpern
>>> Sent: Monday, July 3= 0, 2012 3:15 PM
>>> To: irs-discuss@ietf.org
>&g= t;> Subject: Re: [irs-discuss] I-D Action: draft-ward-irs-framework-00.t= xt
>>>
>>> I am finding this document quite confusi= ng.
>>>
>>> The primary confusion is that the docum= ent first says that it is about
>>> information that can not be manipulated with existing systems, and then
>>> proceeds to gi= ve a list of use cases all of which can be manipulated
>>> with= existing systems at a suitable degree of abstraction.
>>>
&= gt;>> As a lesser confusion, the document says that "streaming" is im= portant,
>>> but then describes "streaming" as "fast, interacti= ve access."  That is
>>> not streaming.  And dependin= g upon what one means by interactive, plenty
>>> of systems pro= vide "fest, interactive access."  I realize the document
>>&g= t; later goes on tot talk about speed and frequency of state updates. = But
>>> that section simply reasserts the earlier terms withot= u better
>>> description or justification.
>>>
&= gt;>> Yours,
>>> Joel
>>>
>>> On = 7/30/2012 2:08 PM, internet-drafts@ietf.org w= rote:
>>>>
>>>> A New Internet-Draft is avail= able from the on-line Internet-Drafts directories.
>>>>
&= gt;>>>
>>>>      Title    =       : Interface to the Routing System Framework
>>= ;>>      Author(s)      : Alia Atlas>>>>                &n= bsp;           Thomas Nadeau
>>>>&n= bsp;                     =       Dave Ward
>>>>      File= name        : draft-ward-irs-framework-00.txt
>&g= t;>>      Pages          : 21=
>>>>      Date            : 2012-07-30
>>>>
>>>> = Abstract:
>>>>    This document describes a framew= ork for a standard, programmatic
>>>>    interface= for full-duplex, streaming state transfer in and out of the
>>>= ;>    Internet's routing system.  It lists the informatio= n that might be
>>>>    exchanged over the interfa= ce, and describes the uses of an interface
>>>>   = to the Internet routing system.
>>>>
>>> ______= _________________________________________
>>> irs-discuss maili= ng list
>>> irs-discuss@ietf.org
>>> ht= tps://www.ietf.org/mailman/listinfo/irs-discuss
>>> _______________________________________________
>>> irs-discus= s mailing list
>>> irs-discuss@ietf.org
>>>= ; https://www.ietf.org/mailman/listinfo/irs-discuss

With rega= rd to transaction issues, we discussed this extensively when
doing ForC= ES.  We concluded that the answer we needed was "yes and no".
&nbs= p; That is, the protocol has mechanisms which can be used for
transacti= onal integrity, including integrity across interactions with
multiple F= Es.  However, the protocol does not require the CE to use
those me= chanisms.  In fact, if it does not even want explicit acks (the
me= ssages go over TCP), it can defer that until it gets to a good "please
= confirm" point.
And in the efforts to use this later, having this range of options has
been useful.

Yours,
Joel

On 8/1/2012 6= :51 PM, Alia Atlas wrote:
> Sue,
>
> I look forward to ta= lking with you more off-line on the policy and
> local-pref research = and issues.  If you have suggestions on good
> background resear= ch to read, by all means send it to the list so
> others can get up t= o speed as well.
>
> On the atomic transaction semantics questi= on, let's get a bit further
> into the use-cases and framework - and = then have a focused discussion.
>  I'm not opposed to it forever= or if it is necessary - just would like
> to thoroughly analyze if i= t is a real requirement.
>
> Do others have opinions and perspe= ctive on this?
>
> Alia
>
> On Wed, Aug 1, 2012 at = 1:58 PM, Susan Hares <susan.hares@huawei.com> wrote:
>> Alia:
>>
>> The hierarchical of inter= faces (To routing system) is one of the areas that requires prioritization.= The prioritization must be able to handle "preempt me", "after you", and "= after me".
>>
>> It is also key to understand that irs sy= stem must handle multi-interfaces struggles at the lowest layer.  You = need to look at the MIF WG (+/-) for some of the struggles of mobility.
= >>
>> -----Original Message-----
>> From: Alia Atla= s [mailto:akatlas@gmail.com]
>> Sent: Monday, July 30, 2012 6:3= 3 PM
>> To: Susan Hares
>> Cc: Joel M. Halpern; ir= s-discuss@ietf.org
>> Subject: Re: [irs-discuss] I-D Action: d= raft-ward-irs-framework-00.txt
>>
>> Hi Sue,
>>
>> On Mon, Jul 30, 2012 at 9:16 PM, Susan Hares = <susan.hares@huawei.com> wrote:
>>> Joel and= irs-folks:
>>>
>>> +1 on Joel.
>>>
= >>>  Beyond your comments, the requirement prioritization of = the interworking of these interfaces is not clearly delineated in this work= . This type of prioritization and sequencing is key to multi-interfaces ope= ration on the monitoring, configuration or insertion of information into th= e depth.
>>
>> [Alia] Can you further clarify, maybe with= an example, which aspect
>> you are thinking of?  Do you mea= n the ability of an application to
>> access multiple sub-interfac= es?  The interaction of operations
>> requested by differeren= t applications?
>>
>>> In addition, if you are going to do configuration with roll-forward/roll-back - you need a transac= tion based processing.
>>
>> [Alia] I'm pretty sure that = I avoided the word "transaction" in both
>> drafts.  That was= deliberate.  Of course, we can have a discussion
>> about wh= ether or not some form of transactions might be desirable.  I
>&= gt; am concerned about their potentially heavy-weight nature.
>>>>> Therefore, you've skipped even requiring the hard problems.<= BR>>>
>> [Alia] Can I optimistically pretend that means that= the requirements
>> we do have don't seem too hard?  For the= responsiveness and throughput
>> goals, I've put a stake in the g= round to avoid transaction-based
>> semantics.  Naturally, th= e hordes can run over that stake, if
>> necessary.
>>
= >> [Sue]: The requirements are necessary even if they are hard.
>>
>> [Alia] For the interaction between different= layers of sub-interfaces,
>> I've been assuming that we'll define= the interactions between the
>> layers based on how they are gene= rally done.  For instance, perhaps we
>> standardize the idea= of preference value - and then the RIB can pick
>> the best route= based upon those preferences.  For interaction between
>> di= fferent applications, I think there's a mixture of
>> authorizatio= n/authentication to get right plus a good set of events
>> that an= application could register for.
>>
>> [Sue]: As someone = who has lived with "local pref" in BGP for a long time, there is a bit more= to unwrap in the statement.  However, it breaks down to prioritizatio= n that is pre-set by preferences.
>>
>> The policy issues= behind the local-pref setting have been studied by the BGP policy community. This is substantial good work on this from the academic researc= hers, vendors, and operator. Griffins, Rexford, Bush, Feamster, ..... and l= ots others are much better on the theory than I am.
>>
>>= > Is this just the -00.draft?
>>
>> [Alia] Certainly, = I expect that we'll uncover more requirements as we
>> go along.&n= bsp; As I said, some of this is initially setting parts  out of
>= ;> scope.
>>
>> ---> Scope =3D=3D good.  Setti= ng scope allows us to pick a piece of this work and standardize it for inte= roperability.
>>
>> Alia
>>
>>> Sue<= BR>>>>
>>>
>>>
>>> -----Origin= al Message-----
>>> From: irs-discuss-boun= ces@ietf.org [mailto:irs-discuss-bounces@ietf.o= rg] On Behalf Of Joel M. Halpern
>>> Sent: Monday, July 30,= 2012 3:15 PM
>>> To: irs-discuss@ietf.org
>>= > Subject: Re: [irs-discuss] I-D Action: draft-ward-irs-framework-00.txt=
>>>
>>> I am finding this document quite confusing= .
>>>
>>> The primary confusion is that the documen= t first says that it is about
>>> information that can not be m= anipulated with existing systems, and then
>>> proceeds to give= a list of use cases all of which can be manipulated
>>> with e= xisting systems at a suitable degree of abstraction.
>>>
>= ;>> As a lesser confusion, the document says that "streaming" is impo= rtant,
>>> but then describes "streaming" as "fast, interactive access."  That is
>>> not streaming.  An= d depending upon what one means by interactive, plenty
>>> of s= ystems provide "fest, interactive access."  I realize the document
= >>> later goes on tot talk about speed and frequency of state upda= tes.  But
>>> that section simply reasserts the earlier te= rms withotu better
>>> description or justification.
>>= ;>
>>> Yours,
>>> Joel
>>>
>&g= t;> On 7/30/2012 2:08 PM, internet-drafts@ietf.org wrot= e:
>>>>
>>>> A New Internet-Draft is availabl= e from the on-line Internet-Drafts directories.
>>>>
>= >>>
>>>>        Title  &nb= sp;       : Interface to the Routing System Framework
>>>>        Author(s)  &= nbsp;   : Alia Atlas
>>>>        &n= bsp;                   Thomas = Nadeau
>>>>              =               Dave Ward
>>>&= gt;        Filename        : draft-= ward-irs-framework-00.txt
>>>>        Pa= ges          : 21
>>>>   =     Date            : 2012-07-30>>>>
>>>> Abstract:
>>>>  =     This document describes a framework for a standard, programma= tic
>>>>      interface for full-duplex, stre= aming state transfer in and out of the
>>>>      Internet's routing system.  It lists the information th= at might be
>>>>      exchanged over the inte= rface, and describes the uses of an interface
>>>>  &nb= sp;   to the Internet routing system.
>>>>
>>&= gt; _______________________________________________
>>> irs-dis= cuss mailing list
>>> irs-discuss@ietf.org
>>= > https://www.ietf.org/mailman/listinfo/irs-discuss
>>= > _______________________________________________
>>> irs-di= scuss mailing list
>>> irs-discuss@ietf.org
>>= ;> https://www.ietf.org/mailman/listinfo/irs-discuss
&= gt;

Alia:

I'm going to check with a colleague who has been do= ing lots of model work to see if he's got a better.  More later.
Sue

-----Original Message-----
From: Alia Atlas [mailto:akatlas= @gmail.com]
Sent: Wednesday, August 01, 2012 3:41 PM
To: Susan H= ares
Cc: Nitin Bahadur; James Kempf; Thomas Nadeau; irs-discuss@iet= f.org
Subject: Re: [irs-discuss] IRS Problem Statement Posted
Sue,

In this case, I was thinking of "translating" from a "higherabstraction layer" to a "lower abstraction layer".

Do you have a b= etter/different term to suggest?  I agree that clarity
of terminolo= gy is important.

Alia

On Wed, Aug 1, 2012 at 2:03 PM, Susan Hares <susan.hares@huawei.com> wrote:
> Alia:
= >
> +1 on abstraction + filters (abstract/detail) IRS fits at the = routing control.
>
> The real question about translation is wha= t the translation is doing.  Is it translating one thing to another at= the same layer of abstraction (e.g., Spanish/English, Ascii/ebcdic) or is = it doing abstraction/detail change.
>
> I define translation as= the same layer of abstraction.  Some people suggest translation =3D a= bstract/detailing.  We first need a common way to talk about the diffe= rence.
>
> Sue
>
> By the way --- I'm thrilled abou= t the pace of the discussion.
>
>
> -----Original Message= -----
> From: Alia Atlas [mailto:akatlas@gmail.com]
> Sent: Monday, July 30, 2012 6:40 PM
> To: Susan Hares
> Cc: Nitin Ba= hadur; James Kempf; Thomas Nadeau; irs-discuss@ietf.org
> Su= bject: Re: [irs-discuss] IRS Problem Statement Posted
>
> Sue,<= BR>>
> I certainly agree that we want IRS to have the ability to e= xpress
> information at different abstraction layers and filtered on = request.
>
> There may still be a gap between the "network OS a= bstractions" and IRS
> sub-interfaces; I'd be surprised if there were= n't.  IRS is to provide
> the bottom-up control strings.
>=
> IMHO, it's reasonable to have an entity that manages the translati= on.
> For instance, one doesn't need a PCE-equiv in every application= - nor
> in every router; that might be an entity in between.
>=
> The quantity of information is part of why explicit filtering and
> hopefully abstraction layers should be built into the data-mod= els.
>
> Alia
>
> On Mon, Jul 30, 2012 at 9:24 PM, = Susan Hares <susan.hares@huawei.com> wrote:
>> = Nitin:
>>
>> Exposing some network intelligence can eithe= r be done in detail or in some amount of summarization.
>> If you = are doing detail, you have bandwidth issues. If you are doing summarization= or opacity, you are talking about layers of information.
>>
&g= t;> Apps need to find out what they need to get. They do not need all th= e details - just the fact they can get from point A to Point B (or for mult= i-cast B/C/D). They need to where they can go to date other applications.&n= bsp; They need a match-maker for the application who determine where the ap= plications shall flow.  Now, if they are smart - like people going out to eat - they pick several ways go to eat traffic.
>>
>= > The network orchestration then serves to be the paths to the place to = eat.  This can either be distributed or centralized.
>>
&g= t;> If we have an Interface to routing, it need to have a two-layer conc= ept of exposing information.
>>
>> Sue Hares
>><= BR>>> -----Original Message-----
>> From: irs-discuss-bounces@ietf.org [mailto:irs-discus= s-bounces@ietf.org] On Behalf Of Nitin Bahadur
>> Sent: Monday= , July 30, 2012 3:33 PM
>> To: James Kempf; Thomas Nadeau; ir= s-discuss@ietf.org
>> Subject: Re: [irs-discuss] IRS Problem Statement Posted
>>
>> Hi James,
>>
>>= This is not about splitting control plane and forwarding plane. It is abou= t exposing network intelligence in the network elements to an external cont= roller.
>> And it is about allowing an external controller to use = that information for enabling network-aware apps. And it is about allowing = apps to influence the
>> network element's RIB (not the FIB direct= ly).
>>
>> Streaming is essential to allow for operations= at scale...and avoid a request/response gated mechanism.
>>
&g= t;> Hope that helps.
>>
>> Thanks
>> Nitin>>
>> On 7/30/12 3:11 PM, "James Kempf" <ja= mes.kempf@ericsson.com> wrote:
>>
>> I don't under= stand why streaming is specified in this draft. And I don't understand why this draft isn't put in the Forces framework. Forces is a framework ex= plicitedly designed for device to controller communication. Its major drawb= ack it that it is a framework with a hole in the middle, in that there are = no specified devices. This draft would fill that hole.
>>
>&= gt; I don't think it is necessary to have a problem statement for router st= ate update. Forces has already established that splitting the control plane= into a separate device is, in some cases, an attractive design option. So = I think this should be submitted to the Forces working group, or, at least,= recast in the Forces framework.
>>
>>     = ;           jak
>>
>>> -----O= riginal Message-----
>>> From: irs-discuss= -bounces@ietf.org
>>> [mailto:irs-discuss-bounces@ietf.org] On Behalf Of Thomas Na= deau
>>> Sent: Monday, July 30, 2012 11:18 AM
>>> T= o: irs-discuss@ietf.org
>>> Subject: [irs-discuss] IRS= Problem Statement Posted
>>>
>>>
>>>>>> Please review and discuss.
>>>
>>> T= hanks,
>>>
>>> Tom, Alia, Ward
>>>
&= gt;>>
>>> http://lucidvision.com/draft-a= tlas-irs-problem-statement-00.txt
>>>
>>>
&g= t;>> _______________________________________________
>>> = irs-discuss mailing list
>>> irs-discuss@ietf.org
>&g= t;> https://www.ietf.org/mailman/listinfo/irs-discuss
>>= >
>> _______________________________________________
>>= ; irs-discuss mailing list
>> irs-discuss@ietf.org
>= ;> https://www.ietf.org/mailman/listinfo/irs-discuss
>>=
>> _______________________________________________
>> ir= s-discuss mailing list
>> irs-discuss@ietf.org
>>= ; https://www.ietf.org/mailman/listinfo/irs-discuss
>> _______________________________________________
>> irs-discuss ma= iling list
>> irs-discuss@ietf.org
>> https:/= /www.ietf.org/mailman/listinfo/irs-discuss


> Sue: Use cas= es are key.  The clarity of the use cases will guide us.  Please = send USE cases.

Here are three I just threw together. We can talk ab= out refining these
tomorrow, if you like... My fingers got tired before = my brain did. :-)

Russ

=3D=3D
Optimized Exit Use Case
<= BR>Assume you have a network where there are two possible exit points
to= wards any set of destinations. The cost of using these links varies by
t= ime, and the quality of the links is highly variable, but not
necessaril= y related to the actual load the local network is putting on
them (in ot= her words, these are oversubscribed links shared with other
parallel networ= ks or customers with unpredictable traffic patterns).
What you'd like to= do is to use the lowest cost link until the quality
of the link reaches= a specific level, and then switch to the higher cost
link. The point at= which this link switch might occur may vary based on
time of day, becau= se the RTO on specific traffic levels varies by the
time of day as well.=

So you have a problem with multiple variables: link quality (appare= ntly
random from your perspective), link cost (varies by time of day), r= eturn
on investment (varies by time of day). Combined with this you have=
multiple exit points, and you must draw traffic from an inside network<= BR>as efficiently as possible to the best exit point, as determined by
t= hese various factors.

The only well defined way to resolve this prob= lem is to feed the
variables to an off router controller, calculate the best exit point on
some periodic basis, and then feed thi= s information back into the
routing table. All solutions that can solve = this problem today use route
injection into BGP, static route injection,= or some other means to
direct traffic --difficult and error prone mecha= nisms. All of these
solutions also draw traffic only along links between= the edge routers
themselves to put traffic on the best possible outboun= d link.

With IRS, the best path could be calculated using any number= of custom
written mechanisms, and the routes injected into the right pl= aces in the
network to effect the most efficient drawing of traffic to t= he best exit
point. Changes in the network environment could quickly cau= se traffic to
be shifted to alternate exit points when circumstances dic= tate.

=3D=3D
Denial of Service

FlowSpec is designed to all= ow an AS to push a filter upstream, with the
ultimate goal being to block the source of DDoS and other attacks as
close to the origin of th= ose attacks as possible. There are some
situations, however, where you w= ould prefer to block an attack at all
edges, or throughout an entire loc= al network. For instance, you might
want to block the forwarding of traf= fic within your network while you
are pushing FlowSpec updates upstream = to block the traffic closer to the
source, or you might be dealing with = an attack originating from multiple
points within your own network.
<= BR>While these responses are possible with standard routing, there is a
= strong case to be made that routing information should not be mixed withsecurity response information within the routing domain (within an AS).Mixing these two types of information can make network management more
= difficult, and slow down the repair of a network during large scale
fail= ures. It would be simpler to have a single controller in a network
tied to the various attack detection mechanisms that could dire= ctly
install the correct routing information to pull all attack traffic = to a
central location, or to simply route the traffic to a null interfac= e.

An related use is that of pulling unknown traffic through specifi= c
devices for analysis. A network operator may not want to drive all
= traffic through traffic analysis devices simply because of cost and
qual= ity of service degredation. A network operator could use IRS to
directly= modify the routing tables on devices in the path of unknown or
possibly= dangerous flows so this traffic is pulled through the correct
monitorin= g and analysis devices.

=3D=3D
Remote Service Routing

In h= ub and spoke overlay networks, there is always an issue with
balancing b= etween the information held in the spoke routing table,
optimal routing = through the network underlying the overlay, and
mobility. Most solutions in this space use some form of centralized
route server that = acts as a directory of all reachable destinations and
next hops, a proto= col by which spoke devices and this route server
communicate, and caches= at the remote sites.

An IRS solution would use the same elements, b= ut with a different
control plane. Remote sites would register (or adver= tise through some
standard routing protocol, such as BGP), the reachable= destinations at
each site, along with the address of the router (or oth= er device) used
to reach that destination. These would, as always, be st= ored in a route
server (or several redundant route servers) at a central= location.

When a remote site sends a set of packets to the central = location that
are eventually destined to some other remote site, the cen= tral location
can forward this traffic, but at the same time simply dire= ctly insert
the correct routing information into the remote site's routing table. If
the location of the destination changes, the r= oute server can directly
modify the routing information at the remote si= te as needed.
An interesting aspect of this solution is that no new and = specialized
protocols are needed between the remote sites and the centra= lized route
server(s). Normal routing protocols can be used to notify th= e
centralized route server(s) of modifications in reachability
inform= ation, and the route server(s) can respond as needed, based on
local alg= orithms optimized for a particular application or network. For
instance,= short lived flows might be allowed to simply pass through the
hub site = with no reaction, while longer lived flows might warrant a
specific rout= e to be installed in the remote router. Algorithms can also
be developed= that would optimize traffic flow through the overlay, and
also to remov= e routing entries from remote devices when they are no
longer needed based on far greater intelligence than simple non-use for
some p= eriod of time.

=3D=3D


___________________________________= ____________
irs-discuss mailing list
irs-discuss@ietf.orghttps://www.ietf.org/mailman/listinfo/irs-discuss


--683666909-50796147-1343929587=:64917-- Return-Path: 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 6E41E11E81B0 for ; Thu, 2 Aug 2012 10:45:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.227 X-Spam-Level: X-Spam-Status: No, score=-2.227 tagged_above=-999 required=5 tests=[AWL=0.372, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ADln4wIMlvjs for ; Thu, 2 Aug 2012 10:45:50 -0700 (PDT) Received: from mail1310.opentransfer.com (mail1310.opentransfer.com [76.162.254.103]) by ietfa.amsl.com (Postfix) with ESMTP id 9FA5211E81AF for ; Thu, 2 Aug 2012 10:45:49 -0700 (PDT) Received: (qmail 1245 invoked by uid 399); 2 Aug 2012 17:45:49 -0000 Received: from unknown (HELO ?130.129.17.10?) (pbs:robert@raszuk.net@130.129.17.10) by mail1310.opentransfer.com with ESMTPM; 2 Aug 2012 17:45:49 -0000 X-Originating-IP: 130.129.17.10 Message-ID: <501ABCCC.4060908@raszuk.net> Date: Thu, 02 Aug 2012 19:45:48 +0200 From: Robert Raszuk User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: Alia Atlas References: <50187B55.407@riw.us> <728F9B956B2C48439CA9294B1723B1462375556A@dfweml509-mbs.china.huawei.com> <501A0E22.4000200@riw.us> <9365BFF8-B750-4691-867F-B0C8277BF817@lucidvision.com> In-Reply-To: <9365BFF8-B750-4691-867F-B0C8277BF817@lucidvision.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: irs-discuss@ietf.org Subject: [irs-discuss] Clarification questions ... X-BeenThere: irs-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: robert@raszuk.net List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2012 17:45:50 -0000 Q1: I have seen a framework slide showing IRS Agent withing the router. I would like to clarify if you are going to have such IRS Agent in each router participating in given (maybe new) service in the AS ? How many IRS clients your envision ? Is the model of 1000s of IRS agents talking to 10s of IRS clients as example ? Q2: Is data currently distributed by routing protocols explicitly prohibited to be also distributed by IRS overlay and send to the routers by TBD IRS channel ? Thx a lot ! R. Return-Path: 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 41A6721E8044 for ; Thu, 2 Aug 2012 09:24:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mkXRXJ7rgaec for ; Thu, 2 Aug 2012 09:24:47 -0700 (PDT) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id D62D421E804A for ; Thu, 2 Aug 2012 09:24:46 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by lucidvision.com (Postfix) with ESMTP id 31238220D7DA; Thu, 2 Aug 2012 12:24:46 -0400 (EDT) X-Virus-Scanned: amavisd-new at www.lucidvision.com Received: from lucidvision.com ([127.0.0.1]) by localhost (static-72-71-250-34.cncdnh.fios.verizon.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pDimjTEUvlxp; Thu, 2 Aug 2012 12:24:46 -0400 (EDT) Received: from tnadeau-sslvpn-nc.jnpr.net (natint3.juniper.net [66.129.224.36]) by lucidvision.com (Postfix) with ESMTP id 69CDE220D7D6; Thu, 2 Aug 2012 12:24:45 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1485\)) From: Thomas Nadeau In-Reply-To: <501A0E22.4000200@riw.us> Date: Thu, 2 Aug 2012 09:24:43 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <9365BFF8-B750-4691-867F-B0C8277BF817@lucidvision.com> References: <50187B55.407@riw.us> <728F9B956B2C48439CA9294B1723B1462375556A@dfweml509-mbs.china.huawei.com> <501A0E22.4000200@riw.us> To: Russ White X-Mailer: Apple Mail (2.1485) Cc: irs-discuss@ietf.org Subject: Re: [irs-discuss] Thoughts on draft-ward-irs-framework X-BeenThere: irs-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2012 16:24:48 -0000 =09 Russ, These are very cool. Thanks for posting them. It would be great = to get these into draft form and online. 8) --Tom =09 On Aug 1, 2012:10:20 PM, at 10:20 PM, Russ White wrote: >=20 >> Sue: Use cases are key. The clarity of the use cases will guide us. = Please send USE cases. >=20 > Here are three I just threw together. We can talk about refining these > tomorrow, if you like... My fingers got tired before my brain did. :-) >=20 > Russ >=20 > =3D=3D > Optimized Exit Use Case >=20 > Assume you have a network where there are two possible exit points > towards any set of destinations. The cost of using these links varies = by > time, and the quality of the links is highly variable, but not > necessarily related to the actual load the local network is putting on > them (in other words, these are oversubscribed links shared with other > parallel networks or customers with unpredictable traffic patterns). > What you'd like to do is to use the lowest cost link until the quality > of the link reaches a specific level, and then switch to the higher = cost > link. The point at which this link switch might occur may vary based = on > time of day, because the RTO on specific traffic levels varies by the > time of day as well. >=20 > So you have a problem with multiple variables: link quality = (apparently > random from your perspective), link cost (varies by time of day), = return > on investment (varies by time of day). Combined with this you have > multiple exit points, and you must draw traffic from an inside network > as efficiently as possible to the best exit point, as determined by > these various factors. >=20 > The only well defined way to resolve this problem is to feed the > variables to an off router controller, calculate the best exit point = on > some periodic basis, and then feed this information back into the > routing table. All solutions that can solve this problem today use = route > injection into BGP, static route injection, or some other means to > direct traffic --difficult and error prone mechanisms. All of these > solutions also draw traffic only along links between the edge routers > themselves to put traffic on the best possible outbound link. >=20 > With IRS, the best path could be calculated using any number of custom > written mechanisms, and the routes injected into the right places in = the > network to effect the most efficient drawing of traffic to the best = exit > point. Changes in the network environment could quickly cause traffic = to > be shifted to alternate exit points when circumstances dictate. >=20 > =3D=3D > Denial of Service >=20 > FlowSpec is designed to allow an AS to push a filter upstream, with = the > ultimate goal being to block the source of DDoS and other attacks as > close to the origin of those attacks as possible. There are some > situations, however, where you would prefer to block an attack at all > edges, or throughout an entire local network. For instance, you might > want to block the forwarding of traffic within your network while you > are pushing FlowSpec updates upstream to block the traffic closer to = the > source, or you might be dealing with an attack originating from = multiple > points within your own network. >=20 > While these responses are possible with standard routing, there is a > strong case to be made that routing information should not be mixed = with > security response information within the routing domain (within an = AS). > Mixing these two types of information can make network management more > difficult, and slow down the repair of a network during large scale > failures. It would be simpler to have a single controller in a network > tied to the various attack detection mechanisms that could directly > install the correct routing information to pull all attack traffic to = a > central location, or to simply route the traffic to a null interface. >=20 > An related use is that of pulling unknown traffic through specific > devices for analysis. A network operator may not want to drive all > traffic through traffic analysis devices simply because of cost and > quality of service degredation. A network operator could use IRS to > directly modify the routing tables on devices in the path of unknown = or > possibly dangerous flows so this traffic is pulled through the correct > monitoring and analysis devices. >=20 > =3D=3D > Remote Service Routing >=20 > In hub and spoke overlay networks, there is always an issue with > balancing between the information held in the spoke routing table, > optimal routing through the network underlying the overlay, and > mobility. Most solutions in this space use some form of centralized > route server that acts as a directory of all reachable destinations = and > next hops, a protocol by which spoke devices and this route server > communicate, and caches at the remote sites. >=20 > An IRS solution would use the same elements, but with a different > control plane. Remote sites would register (or advertise through some > standard routing protocol, such as BGP), the reachable destinations at > each site, along with the address of the router (or other device) used > to reach that destination. These would, as always, be stored in a = route > server (or several redundant route servers) at a central location. >=20 > When a remote site sends a set of packets to the central location that > are eventually destined to some other remote site, the central = location > can forward this traffic, but at the same time simply directly insert > the correct routing information into the remote site's routing table. = If > the location of the destination changes, the route server can directly > modify the routing information at the remote site as needed. > An interesting aspect of this solution is that no new and specialized > protocols are needed between the remote sites and the centralized = route > server(s). Normal routing protocols can be used to notify the > centralized route server(s) of modifications in reachability > information, and the route server(s) can respond as needed, based on > local algorithms optimized for a particular application or network. = For > instance, short lived flows might be allowed to simply pass through = the > hub site with no reaction, while longer lived flows might warrant a > specific route to be installed in the remote router. Algorithms can = also > be developed that would optimize traffic flow through the overlay, and > also to remove routing entries from remote devices when they are no > longer needed based on far greater intelligence than simple non-use = for > some period of time. >=20 > =3D=3D > _______________________________________________ > irs-discuss mailing list > irs-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/irs-discuss >=20 Return-Path: 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 8B12F11E80BA for ; Wed, 1 Aug 2012 22:30:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WVHXUQoRvI-H for ; Wed, 1 Aug 2012 22:30:55 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id ABFFD11E809A for ; Wed, 1 Aug 2012 22:30:55 -0700 (PDT) Received: by yhq56 with SMTP id 56so8888977yhq.31 for ; Wed, 01 Aug 2012 22:30:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=h9dpP5/SJ41KDvz6nOQ3GLEibbAv1I1SY05gE/NjjpI=; b=v0VPQ39YYHaCrg5QZLhNI5iRjKYy6DQeIQXDOf5GFas96CmqIYieHopWZs9A4cwI9S VjvtMXEt5wQj6NQ4WJa+1wE62Tu9UVzl+jFZ1g99SYpCxMWZmXSDPyhxoyjvfqyEZq4/ t+/ClfyLpIfThvBA0S2J/XAKhFtLtR0qp5CiIX8y/V61INOXnVTb5BnliM9Eb4DCPSgz 10hQU5JOZZJUy2rNhWA575bQSGXEB+d6YONgYoNopO7Gvy/Y7Bh1nYqcuhwDLF4Q6mxx mE/GieYEkldi8FEWelRd0POR+x5CX8MhettK97vcPpuETzzgJRHxtn8ngTCahufly9f1 2VYA== MIME-Version: 1.0 Received: by 10.50.179.3 with SMTP id dc3mr1383239igc.18.1343885454986; Wed, 01 Aug 2012 22:30:54 -0700 (PDT) Received: by 10.50.34.169 with HTTP; Wed, 1 Aug 2012 22:30:54 -0700 (PDT) In-Reply-To: <501A0F6E.8010508@riw.us> References: <50187B55.407@riw.us> <728F9B956B2C48439CA9294B1723B1462375556A@dfweml509-mbs.china.huawei.com> <501A0F6E.8010508@riw.us> Date: Thu, 2 Aug 2012 01:30:54 -0400 Message-ID: From: Alia Atlas To: Russ White Content-Type: text/plain; charset=ISO-8859-1 Cc: Susan Hares , "irs-discuss@ietf.org" Subject: Re: [irs-discuss] Thoughts on draft-ward-irs-framework X-BeenThere: irs-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2012 05:30:56 -0000 K - so the idea of the IRS sub-interface to the RIB being semantically similar to another routing process sounds like an initially useful way of describing it - but we're going to want to qualify out what that means in terms of interactions and into the appropriate description & models. Alia On Thu, Aug 2, 2012 at 1:26 AM, Russ White wrote: > >> ----> [Russ]: +1 - This Offboard controller processing aligns with the ONF view of SDN. And it has been done in practice for 10+ years. However as you know, the timing between the calculation and download to HW is important. > > If we just insert the information into "yet another process" parallel > with the already existing routing processes on the hardware, I think we > shunt aside the problems with insertion speed, etc. Routes installed in > this "off board interface routing process" would be handled just like > routes learned through other sources. Any improvements in the speed of > route insertion from, say, OSPF running on the box would be reflected in > speed improvements for IRS. IMHO, this is a huge win overall. > >> One >> difference, though, is the idea that different static routes installed >> by IRS may want to have different preference values. > > All the implementations I've worked with have the ability to install > routes from a single process with different preferences. If no > preference is specifically stated, the process' preference is used. > Specific per route preferences override these, though --see, for > instance, the EIGRP distance command in IOS. I suspect all > implementations have the ability to handle this sort of thing in the API > between each routing process and the RIB, but it's just not used a lot. > > :-) > > Russ > _______________________________________________ > irs-discuss mailing list > irs-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/irs-discuss Return-Path: 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 4FBA721F8A0A for ; Wed, 1 Aug 2012 22:25:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iZR-1qUGJYFF for ; Wed, 1 Aug 2012 22:25:58 -0700 (PDT) Received: from da31.namelessnet.net (da31.namelessnet.net [74.124.205.66]) by ietfa.amsl.com (Postfix) with ESMTP id CA36821F8A09 for ; Wed, 1 Aug 2012 22:25:58 -0700 (PDT) Received: from dhcp-4151.meeting.ietf.org ([130.129.65.81]) by da31.namelessnet.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.77) (envelope-from ) id 1Swnv4-0003lT-Ku; Wed, 01 Aug 2012 22:25:58 -0700 Message-ID: <501A0F6E.8010508@riw.us> Date: Thu, 02 Aug 2012 01:26:06 -0400 From: Russ White User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: Susan Hares References: <50187B55.407@riw.us> <728F9B956B2C48439CA9294B1723B1462375556A@dfweml509-mbs.china.huawei.com> In-Reply-To: <728F9B956B2C48439CA9294B1723B1462375556A@dfweml509-mbs.china.huawei.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Antivirus-Scanner: Seems clean. You should still use an Antivirus Scanner Cc: "irs-discuss@ietf.org" Subject: Re: [irs-discuss] Thoughts on draft-ward-irs-framework X-BeenThere: irs-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2012 05:25:59 -0000 > ----> [Russ]: +1 - This Offboard controller processing aligns with the ONF view of SDN. And it has been done in practice for 10+ years. However as you know, the timing between the calculation and download to HW is important. If we just insert the information into "yet another process" parallel with the already existing routing processes on the hardware, I think we shunt aside the problems with insertion speed, etc. Routes installed in this "off board interface routing process" would be handled just like routes learned through other sources. Any improvements in the speed of route insertion from, say, OSPF running on the box would be reflected in speed improvements for IRS. IMHO, this is a huge win overall. > One > difference, though, is the idea that different static routes installed > by IRS may want to have different preference values. All the implementations I've worked with have the ability to install routes from a single process with different preferences. If no preference is specifically stated, the process' preference is used. Specific per route preferences override these, though --see, for instance, the EIGRP distance command in IOS. I suspect all implementations have the ability to handle this sort of thing in the API between each routing process and the RIB, but it's just not used a lot. :-) Russ Return-Path: 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 EC07A11E80E3 for ; Wed, 1 Aug 2012 22:20:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XznAuVAxpDcb for ; Wed, 1 Aug 2012 22:20:31 -0700 (PDT) Received: from da31.namelessnet.net (da31.namelessnet.net [74.124.205.66]) by ietfa.amsl.com (Postfix) with ESMTP id 2923111E80D9 for ; Wed, 1 Aug 2012 22:20:31 -0700 (PDT) Received: from dhcp-4151.meeting.ietf.org ([130.129.65.81]) by da31.namelessnet.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.77) (envelope-from ) id 1Swnpm-0003ay-4H; Wed, 01 Aug 2012 22:20:30 -0700 Message-ID: <501A0E22.4000200@riw.us> Date: Thu, 02 Aug 2012 01:20:34 -0400 From: Russ White User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: Susan Hares References: <50187B55.407@riw.us> <728F9B956B2C48439CA9294B1723B1462375556A@dfweml509-mbs.china.huawei.com> In-Reply-To: <728F9B956B2C48439CA9294B1723B1462375556A@dfweml509-mbs.china.huawei.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Antivirus-Scanner: Seems clean. You should still use an Antivirus Scanner Cc: "irs-discuss@ietf.org" Subject: Re: [irs-discuss] Thoughts on draft-ward-irs-framework X-BeenThere: irs-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2012 05:20:33 -0000 > Sue: Use cases are key. The clarity of the use cases will guide us. Please send USE cases. Here are three I just threw together. We can talk about refining these tomorrow, if you like... My fingers got tired before my brain did. :-) Russ == Optimized Exit Use Case Assume you have a network where there are two possible exit points towards any set of destinations. The cost of using these links varies by time, and the quality of the links is highly variable, but not necessarily related to the actual load the local network is putting on them (in other words, these are oversubscribed links shared with other parallel networks or customers with unpredictable traffic patterns). What you'd like to do is to use the lowest cost link until the quality of the link reaches a specific level, and then switch to the higher cost link. The point at which this link switch might occur may vary based on time of day, because the RTO on specific traffic levels varies by the time of day as well. So you have a problem with multiple variables: link quality (apparently random from your perspective), link cost (varies by time of day), return on investment (varies by time of day). Combined with this you have multiple exit points, and you must draw traffic from an inside network as efficiently as possible to the best exit point, as determined by these various factors. The only well defined way to resolve this problem is to feed the variables to an off router controller, calculate the best exit point on some periodic basis, and then feed this information back into the routing table. All solutions that can solve this problem today use route injection into BGP, static route injection, or some other means to direct traffic --difficult and error prone mechanisms. All of these solutions also draw traffic only along links between the edge routers themselves to put traffic on the best possible outbound link. With IRS, the best path could be calculated using any number of custom written mechanisms, and the routes injected into the right places in the network to effect the most efficient drawing of traffic to the best exit point. Changes in the network environment could quickly cause traffic to be shifted to alternate exit points when circumstances dictate. == Denial of Service FlowSpec is designed to allow an AS to push a filter upstream, with the ultimate goal being to block the source of DDoS and other attacks as close to the origin of those attacks as possible. There are some situations, however, where you would prefer to block an attack at all edges, or throughout an entire local network. For instance, you might want to block the forwarding of traffic within your network while you are pushing FlowSpec updates upstream to block the traffic closer to the source, or you might be dealing with an attack originating from multiple points within your own network. While these responses are possible with standard routing, there is a strong case to be made that routing information should not be mixed with security response information within the routing domain (within an AS). Mixing these two types of information can make network management more difficult, and slow down the repair of a network during large scale failures. It would be simpler to have a single controller in a network tied to the various attack detection mechanisms that could directly install the correct routing information to pull all attack traffic to a central location, or to simply route the traffic to a null interface. An related use is that of pulling unknown traffic through specific devices for analysis. A network operator may not want to drive all traffic through traffic analysis devices simply because of cost and quality of service degredation. A network operator could use IRS to directly modify the routing tables on devices in the path of unknown or possibly dangerous flows so this traffic is pulled through the correct monitoring and analysis devices. == Remote Service Routing In hub and spoke overlay networks, there is always an issue with balancing between the information held in the spoke routing table, optimal routing through the network underlying the overlay, and mobility. Most solutions in this space use some form of centralized route server that acts as a directory of all reachable destinations and next hops, a protocol by which spoke devices and this route server communicate, and caches at the remote sites. An IRS solution would use the same elements, but with a different control plane. Remote sites would register (or advertise through some standard routing protocol, such as BGP), the reachable destinations at each site, along with the address of the router (or other device) used to reach that destination. These would, as always, be stored in a route server (or several redundant route servers) at a central location. When a remote site sends a set of packets to the central location that are eventually destined to some other remote site, the central location can forward this traffic, but at the same time simply directly insert the correct routing information into the remote site's routing table. If the location of the destination changes, the route server can directly modify the routing information at the remote site as needed. An interesting aspect of this solution is that no new and specialized protocols are needed between the remote sites and the centralized route server(s). Normal routing protocols can be used to notify the centralized route server(s) of modifications in reachability information, and the route server(s) can respond as needed, based on local algorithms optimized for a particular application or network. For instance, short lived flows might be allowed to simply pass through the hub site with no reaction, while longer lived flows might warrant a specific route to be installed in the remote router. Algorithms can also be developed that would optimize traffic flow through the overlay, and also to remove routing entries from remote devices when they are no longer needed based on far greater intelligence than simple non-use for some period of time. == Return-Path: 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 0E9AC11E83C8 for ; Wed, 1 Aug 2012 16:22:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.48 X-Spam-Level: X-Spam-Status: No, score=-4.48 tagged_above=-999 required=5 tests=[AWL=2.119, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kwPRxjV2Hj+H for ; Wed, 1 Aug 2012 16:22:55 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id BB21711E83B3 for ; Wed, 1 Aug 2012 16:22:54 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml202-edg.china.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AIP58227; Wed, 01 Aug 2012 15:22:54 -0800 (PST) Received: from DFWEML404-HUB.china.huawei.com (10.193.5.203) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 1 Aug 2012 16:21:01 -0700 Received: from dfweml509-mbs.china.huawei.com ([169.254.12.123]) by dfweml404-hub.china.huawei.com ([10.193.5.203]) with mapi id 14.01.0323.003; Wed, 1 Aug 2012 16:20:56 -0700 From: Susan Hares To: Alia Atlas Thread-Topic: [irs-discuss] IRS Problem Statement Posted Thread-Index: Ac1uf6vUr0RoAYPERve+GHr5XPQ6JgAIAMEAAADmuywABbPeIAAPeoSAAEN3KtAAGt02AAAOph+g Date: Wed, 1 Aug 2012 23:20:55 +0000 Message-ID: <728F9B956B2C48439CA9294B1723B14623755735@dfweml509-mbs.china.huawei.com> References: <728F9B956B2C48439CA9294B1723B14623754A18@dfweml509-mbs.china.huawei.com> <728F9B956B2C48439CA9294B1723B146237553E6@dfweml509-mbs.china.huawei.com> In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.212.245.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: Thomas Nadeau , Nitin Bahadur , James Kempf , "irs-discuss@ietf.org" Subject: Re: [irs-discuss] IRS Problem Statement Posted X-BeenThere: irs-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Aug 2012 23:22:56 -0000 Alia: I'm going to check with a colleague who has been doing lots of model work t= o see if he's got a better. More later. Sue=20 -----Original Message----- From: Alia Atlas [mailto:akatlas@gmail.com]=20 Sent: Wednesday, August 01, 2012 3:41 PM To: Susan Hares Cc: Nitin Bahadur; James Kempf; Thomas Nadeau; irs-discuss@ietf.org Subject: Re: [irs-discuss] IRS Problem Statement Posted Sue, In this case, I was thinking of "translating" from a "higher abstraction layer" to a "lower abstraction layer". Do you have a better/different term to suggest? I agree that clarity of terminology is important. Alia On Wed, Aug 1, 2012 at 2:03 PM, Susan Hares wrote: > Alia: > > +1 on abstraction + filters (abstract/detail) IRS fits at the routing con= trol. > > The real question about translation is what the translation is doing. Is= it translating one thing to another at the same layer of abstraction (e.g.= , Spanish/English, Ascii/ebcdic) or is it doing abstraction/detail change. > > I define translation as the same layer of abstraction. Some people sugge= st translation =3D abstract/detailing. We first need a common way to talk = about the difference. > > Sue > > By the way --- I'm thrilled about the pace of the discussion. > > > -----Original Message----- > From: Alia Atlas [mailto:akatlas@gmail.com] > Sent: Monday, July 30, 2012 6:40 PM > To: Susan Hares > Cc: Nitin Bahadur; James Kempf; Thomas Nadeau; irs-discuss@ietf.org > Subject: Re: [irs-discuss] IRS Problem Statement Posted > > Sue, > > I certainly agree that we want IRS to have the ability to express > information at different abstraction layers and filtered on request. > > There may still be a gap between the "network OS abstractions" and IRS > sub-interfaces; I'd be surprised if there weren't. IRS is to provide > the bottom-up control strings. > > IMHO, it's reasonable to have an entity that manages the translation. > For instance, one doesn't need a PCE-equiv in every application - nor > in every router; that might be an entity in between. > > The quantity of information is part of why explicit filtering and > hopefully abstraction layers should be built into the data-models. > > Alia > > On Mon, Jul 30, 2012 at 9:24 PM, Susan Hares wro= te: >> Nitin: >> >> Exposing some network intelligence can either be done in detail or in so= me amount of summarization. >> If you are doing detail, you have bandwidth issues. If you are doing sum= marization or opacity, you are talking about layers of information. >> >> Apps need to find out what they need to get. They do not need all the de= tails - just the fact they can get from point A to Point B (or for multi-ca= st B/C/D). They need to where they can go to date other applications. They= need a match-maker for the application who determine where the application= s shall flow. Now, if they are smart - like people going out to eat - they= pick several ways go to eat traffic. >> >> The network orchestration then serves to be the paths to the place to ea= t. This can either be distributed or centralized. >> >> If we have an Interface to routing, it need to have a two-layer concept = of exposing information. >> >> Sue Hares >> >> -----Original Message----- >> From: irs-discuss-bounces@ietf.org [mailto:irs-discuss-bounces@ietf.org]= On Behalf Of Nitin Bahadur >> Sent: Monday, July 30, 2012 3:33 PM >> To: James Kempf; Thomas Nadeau; irs-discuss@ietf.org >> Subject: Re: [irs-discuss] IRS Problem Statement Posted >> >> Hi James, >> >> This is not about splitting control plane and forwarding plane. It is ab= out exposing network intelligence in the network elements to an external co= ntroller. >> And it is about allowing an external controller to use that information = for enabling network-aware apps. And it is about allowing apps to influence= the >> network element's RIB (not the FIB directly). >> >> Streaming is essential to allow for operations at scale...and avoid a re= quest/response gated mechanism. >> >> Hope that helps. >> >> Thanks >> Nitin >> >> On 7/30/12 3:11 PM, "James Kempf" wrote: >> >> I don't understand why streaming is specified in this draft. And I don't= understand why this draft isn't put in the Forces framework. Forces is a f= ramework explicitedly designed for device to controller communication. Its = major drawback it that it is a framework with a hole in the middle, in that= there are no specified devices. This draft would fill that hole. >> >> I don't think it is necessary to have a problem statement for router sta= te update. Forces has already established that splitting the control plane = into a separate device is, in some cases, an attractive design option. So I= think this should be submitted to the Forces working group, or, at least, = recast in the Forces framework. >> >> jak >> >>> -----Original Message----- >>> From: irs-discuss-bounces@ietf.org >>> [mailto:irs-discuss-bounces@ietf.org] On Behalf Of Thomas Nadeau >>> Sent: Monday, July 30, 2012 11:18 AM >>> To: irs-discuss@ietf.org >>> Subject: [irs-discuss] IRS Problem Statement Posted >>> >>> >>> >>> Please review and discuss. >>> >>> Thanks, >>> >>> Tom, Alia, Ward >>> >>> >>> http://lucidvision.com/draft-atlas-irs-problem-statement-00.txt >>> >>> >>> _______________________________________________ >>> 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 >> >> _______________________________________________ >> 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 Return-Path: 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 6CB5311E8131 for ; Wed, 1 Aug 2012 16:01:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.265 X-Spam-Level: X-Spam-Status: No, score=-102.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KBcNiCJC5N96 for ; Wed, 1 Aug 2012 16:01:13 -0700 (PDT) Received: from morbo.mail.tigertech.net (morbo.mail.tigertech.net [67.131.251.54]) by ietfa.amsl.com (Postfix) with ESMTP id 7E4C611E811E for ; Wed, 1 Aug 2012 16:01:13 -0700 (PDT) Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) by morbo.tigertech.net (Postfix) with ESMTP id 33F445585B1 for ; Wed, 1 Aug 2012 16:01:13 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id A434443074; Wed, 1 Aug 2012 16:01:12 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at c2.tigertech.net Received: from [130.129.32.82] (dhcp-2052.meeting.ietf.org [130.129.32.82]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailc2.tigertech.net (Postfix) with ESMTPSA id 413424306F; Wed, 1 Aug 2012 16:01:12 -0700 (PDT) Message-ID: <5019B533.3050806@joelhalpern.com> Date: Wed, 01 Aug 2012 19:01:07 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: Alia Atlas References: <20120730180849.1235.96769.idtracker@ietfa.amsl.com> <50170758.3030908@joelhalpern.com> <728F9B956B2C48439CA9294B1723B14623754A03@dfweml509-mbs.china.huawei.com> <728F9B956B2C48439CA9294B1723B146237553BF@dfweml509-mbs.china.huawei.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Susan Hares , "irs-discuss@ietf.org" Subject: Re: [irs-discuss] I-D Action: draft-ward-irs-framework-00.txt X-BeenThere: irs-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Aug 2012 23:01:14 -0000 With regard to transaction issues, we discussed this extensively when doing ForCES. We concluded that the answer we needed was "yes and no". That is, the protocol has mechanisms which can be used for transactional integrity, including integrity across interactions with multiple FEs. However, the protocol does not require the CE to use those mechanisms. In fact, if it does not even want explicit acks (the messages go over TCP), it can defer that until it gets to a good "please confirm" point. And in the efforts to use this later, having this range of options has been useful. Yours, Joel On 8/1/2012 6:51 PM, Alia Atlas wrote: > Sue, > > I look forward to talking with you more off-line on the policy and > local-pref research and issues. If you have suggestions on good > background research to read, by all means send it to the list so > others can get up to speed as well. > > On the atomic transaction semantics question, let's get a bit further > into the use-cases and framework - and then have a focused discussion. > I'm not opposed to it forever or if it is necessary - just would like > to thoroughly analyze if it is a real requirement. > > Do others have opinions and perspective on this? > > Alia > > On Wed, Aug 1, 2012 at 1:58 PM, Susan Hares wrote: >> Alia: >> >> The hierarchical of interfaces (To routing system) is one of the areas that requires prioritization. The prioritization must be able to handle "preempt me", "after you", and "after me". >> >> It is also key to understand that irs system must handle multi-interfaces struggles at the lowest layer. You need to look at the MIF WG (+/-) for some of the struggles of mobility. >> >> -----Original Message----- >> From: Alia Atlas [mailto:akatlas@gmail.com] >> Sent: Monday, July 30, 2012 6:33 PM >> To: Susan Hares >> Cc: Joel M. Halpern; irs-discuss@ietf.org >> Subject: Re: [irs-discuss] I-D Action: draft-ward-irs-framework-00.txt >> >> Hi Sue, >> >> On Mon, Jul 30, 2012 at 9:16 PM, Susan Hares wrote: >>> Joel and irs-folks: >>> >>> +1 on Joel. >>> >>> Beyond your comments, the requirement prioritization of the interworking of these interfaces is not clearly delineated in this work. This type of prioritization and sequencing is key to multi-interfaces operation on the monitoring, configuration or insertion of information into the depth. >> >> [Alia] Can you further clarify, maybe with an example, which aspect >> you are thinking of? Do you mean the ability of an application to >> access multiple sub-interfaces? The interaction of operations >> requested by differerent applications? >> >>> In addition, if you are going to do configuration with roll-forward/roll-back - you need a transaction based processing. >> >> [Alia] I'm pretty sure that I avoided the word "transaction" in both >> drafts. That was deliberate. Of course, we can have a discussion >> about whether or not some form of transactions might be desirable. I >> am concerned about their potentially heavy-weight nature. >> >>> Therefore, you've skipped even requiring the hard problems. >> >> [Alia] Can I optimistically pretend that means that the requirements >> we do have don't seem too hard? For the responsiveness and throughput >> goals, I've put a stake in the ground to avoid transaction-based >> semantics. Naturally, the hordes can run over that stake, if >> necessary. >> >> [Sue]: The requirements are necessary even if they are hard. >> >> [Alia] For the interaction between different layers of sub-interfaces, >> I've been assuming that we'll define the interactions between the >> layers based on how they are generally done. For instance, perhaps we >> standardize the idea of preference value - and then the RIB can pick >> the best route based upon those preferences. For interaction between >> different applications, I think there's a mixture of >> authorization/authentication to get right plus a good set of events >> that an application could register for. >> >> [Sue]: As someone who has lived with "local pref" in BGP for a long time, there is a bit more to unwrap in the statement. However, it breaks down to prioritization that is pre-set by preferences. >> >> The policy issues behind the local-pref setting have been studied by the BGP policy community. This is substantial good work on this from the academic researchers, vendors, and operator. Griffins, Rexford, Bush, Feamster, ..... and lots others are much better on the theory than I am. >> >>> Is this just the -00.draft? >> >> [Alia] Certainly, I expect that we'll uncover more requirements as we >> go along. As I said, some of this is initially setting parts out of >> scope. >> >> ---> Scope == good. Setting scope allows us to pick a piece of this work and standardize it for interoperability. >> >> Alia >> >>> Sue >>> >>> >>> >>> -----Original Message----- >>> From: irs-discuss-bounces@ietf.org [mailto:irs-discuss-bounces@ietf.org] On Behalf Of Joel M. Halpern >>> Sent: Monday, July 30, 2012 3:15 PM >>> To: irs-discuss@ietf.org >>> Subject: Re: [irs-discuss] I-D Action: draft-ward-irs-framework-00.txt >>> >>> I am finding this document quite confusing. >>> >>> The primary confusion is that the document first says that it is about >>> information that can not be manipulated with existing systems, and then >>> proceeds to give a list of use cases all of which can be manipulated >>> with existing systems at a suitable degree of abstraction. >>> >>> As a lesser confusion, the document says that "streaming" is important, >>> but then describes "streaming" as "fast, interactive access." That is >>> not streaming. And depending upon what one means by interactive, plenty >>> of systems provide "fest, interactive access." I realize the document >>> later goes on tot talk about speed and frequency of state updates. But >>> that section simply reasserts the earlier terms withotu better >>> description or justification. >>> >>> Yours, >>> Joel >>> >>> On 7/30/2012 2:08 PM, internet-drafts@ietf.org wrote: >>>> >>>> A New Internet-Draft is available from the on-line Internet-Drafts directories. >>>> >>>> >>>> Title : Interface to the Routing System Framework >>>> Author(s) : Alia Atlas >>>> Thomas Nadeau >>>> Dave Ward >>>> Filename : draft-ward-irs-framework-00.txt >>>> Pages : 21 >>>> Date : 2012-07-30 >>>> >>>> Abstract: >>>> This document describes a framework for a standard, programmatic >>>> interface for full-duplex, streaming state transfer in and out of the >>>> Internet's routing system. It lists the information that might be >>>> exchanged over the interface, and describes the uses of an interface >>>> to the Internet routing system. >>>> >>> _______________________________________________ >>> 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 > Return-Path: 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 4552711E8131 for ; Wed, 1 Aug 2012 15:58:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c1ZBjsPmjeBC for ; Wed, 1 Aug 2012 15:58:55 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 266FA11E8125 for ; Wed, 1 Aug 2012 15:58:55 -0700 (PDT) Received: by yhq56 with SMTP id 56so8544286yhq.31 for ; Wed, 01 Aug 2012 15:58:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=tbPvvziESIjyu/YOO/PWChNH2mc9FGk8ZFIaoqsLtOo=; b=DBUFdyQ9VHazVlgp220anZ1WRuhIG867uEaKq3iYGpbWNbUKVnS1dGc4pB7lo7qp8u hSj8lWx42SGPYPYWsoviBvZfUs+MXGPzV6G0iGouNCYBNP6gNfDqWqmp/GJZzaO2Cr7u fRFspu4PQ8+9IJuR0unB0zZEBjStaRBj/OYIFU1jy0ROAospBPk38wudi4z0g6HH9FD0 HJNmTXITItWQ3Ge4pVs75XdP4SBPj/4BsiG76fknVanc7k6K3HVxQpckUTE94BNokSmv KkQ0dKw5BdxgH1NkrOZPGU4dukxhvMPCTiAfyD9EnRL7vz0hPParxv2rpAehA/lLLXdl 7aLg== MIME-Version: 1.0 Received: by 10.50.104.228 with SMTP id gh4mr5363997igb.71.1343861934050; Wed, 01 Aug 2012 15:58:54 -0700 (PDT) Received: by 10.50.34.169 with HTTP; Wed, 1 Aug 2012 15:58:54 -0700 (PDT) In-Reply-To: <728F9B956B2C48439CA9294B1723B146237556AB@dfweml509-mbs.china.huawei.com> References: <20120730180849.1235.96769.idtracker@ietfa.amsl.com> <50170758.3030908@joelhalpern.com> <728F9B956B2C48439CA9294B1723B14623754A03@dfweml509-mbs.china.huawei.com> <728F9B956B2C48439CA9294B1723B146237553BF@dfweml509-mbs.china.huawei.com> <728F9B956B2C48439CA9294B1723B146237556AB@dfweml509-mbs.china.huawei.com> Date: Wed, 1 Aug 2012 18:58:54 -0400 Message-ID: From: Alia Atlas To: Susan Hares Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "Joel M. Halpern" , "irs-discuss@ietf.org" Subject: Re: [irs-discuss] I-D Action: draft-ward-irs-framework-00.txt X-BeenThere: irs-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Aug 2012 22:58:56 -0000 Thanks! On Wed, Aug 1, 2012 at 6:54 PM, Susan Hares wrote: > Alia: > > I'll try to create a bibliography of things people should read. It will = be mid-next week since I'm away from my home library on the SDN topic. > > Sue > > -----Original Message----- > From: Alia Atlas [mailto:akatlas@gmail.com] > Sent: Wednesday, August 01, 2012 3:51 PM > To: Susan Hares > Cc: Joel M. Halpern; irs-discuss@ietf.org > Subject: Re: [irs-discuss] I-D Action: draft-ward-irs-framework-00.txt > > Sue, > > I look forward to talking with you more off-line on the policy and > local-pref research and issues. If you have suggestions on good > background research to read, by all means send it to the list so > others can get up to speed as well. > > On the atomic transaction semantics question, let's get a bit further > into the use-cases and framework - and then have a focused discussion. > I'm not opposed to it forever or if it is necessary - just would like > to thoroughly analyze if it is a real requirement. > > Do others have opinions and perspective on this? > > Alia > > On Wed, Aug 1, 2012 at 1:58 PM, Susan Hares wrot= e: >> Alia: >> >> The hierarchical of interfaces (To routing system) is one of the areas t= hat requires prioritization. The prioritization must be able to handle "pre= empt me", "after you", and "after me". >> >> It is also key to understand that irs system must handle multi-interface= s struggles at the lowest layer. You need to look at the MIF WG (+/-) for = some of the struggles of mobility. >> >> -----Original Message----- >> From: Alia Atlas [mailto:akatlas@gmail.com] >> Sent: Monday, July 30, 2012 6:33 PM >> To: Susan Hares >> Cc: Joel M. Halpern; irs-discuss@ietf.org >> Subject: Re: [irs-discuss] I-D Action: draft-ward-irs-framework-00.txt >> >> Hi Sue, >> >> On Mon, Jul 30, 2012 at 9:16 PM, Susan Hares wr= ote: >>> Joel and irs-folks: >>> >>> +1 on Joel. >>> >>> Beyond your comments, the requirement prioritization of the interworki= ng of these interfaces is not clearly delineated in this work. This type of= prioritization and sequencing is key to multi-interfaces operation on the = monitoring, configuration or insertion of information into the depth. >> >> [Alia] Can you further clarify, maybe with an example, which aspect >> you are thinking of? Do you mean the ability of an application to >> access multiple sub-interfaces? The interaction of operations >> requested by differerent applications? >> >>> In addition, if you are going to do configuration with roll-forward/rol= l-back - you need a transaction based processing. >> >> [Alia] I'm pretty sure that I avoided the word "transaction" in both >> drafts. That was deliberate. Of course, we can have a discussion >> about whether or not some form of transactions might be desirable. I >> am concerned about their potentially heavy-weight nature. >> >>> Therefore, you've skipped even requiring the hard problems. >> >> [Alia] Can I optimistically pretend that means that the requirements >> we do have don't seem too hard? For the responsiveness and throughput >> goals, I've put a stake in the ground to avoid transaction-based >> semantics. Naturally, the hordes can run over that stake, if >> necessary. >> >> [Sue]: The requirements are necessary even if they are hard. >> >> [Alia] For the interaction between different layers of sub-interfaces, >> I've been assuming that we'll define the interactions between the >> layers based on how they are generally done. For instance, perhaps we >> standardize the idea of preference value - and then the RIB can pick >> the best route based upon those preferences. For interaction between >> different applications, I think there's a mixture of >> authorization/authentication to get right plus a good set of events >> that an application could register for. >> >> [Sue]: As someone who has lived with "local pref" in BGP for a long time= , there is a bit more to unwrap in the statement. However, it breaks down = to prioritization that is pre-set by preferences. >> >> The policy issues behind the local-pref setting have been studied by the= BGP policy community. This is substantial good work on this from the acade= mic researchers, vendors, and operator. Griffins, Rexford, Bush, Feamster, = ..... and lots others are much better on the theory than I am. >> >>> Is this just the -00.draft? >> >> [Alia] Certainly, I expect that we'll uncover more requirements as we >> go along. As I said, some of this is initially setting parts out of >> scope. >> >> ---> Scope =3D=3D good. Setting scope allows us to pick a piece of this= work and standardize it for interoperability. >> >> Alia >> >>> Sue >>> >>> >>> >>> -----Original Message----- >>> From: irs-discuss-bounces@ietf.org [mailto:irs-discuss-bounces@ietf.org= ] On Behalf Of Joel M. Halpern >>> Sent: Monday, July 30, 2012 3:15 PM >>> To: irs-discuss@ietf.org >>> Subject: Re: [irs-discuss] I-D Action: draft-ward-irs-framework-00.txt >>> >>> I am finding this document quite confusing. >>> >>> The primary confusion is that the document first says that it is about >>> information that can not be manipulated with existing systems, and then >>> proceeds to give a list of use cases all of which can be manipulated >>> with existing systems at a suitable degree of abstraction. >>> >>> As a lesser confusion, the document says that "streaming" is important, >>> but then describes "streaming" as "fast, interactive access." That is >>> not streaming. And depending upon what one means by interactive, plent= y >>> of systems provide "fest, interactive access." I realize the document >>> later goes on tot talk about speed and frequency of state updates. Bu= t >>> that section simply reasserts the earlier terms withotu better >>> description or justification. >>> >>> Yours, >>> Joel >>> >>> On 7/30/2012 2:08 PM, internet-drafts@ietf.org wrote: >>>> >>>> A New Internet-Draft is available from the on-line Internet-Drafts dir= ectories. >>>> >>>> >>>> Title : Interface to the Routing System Framework >>>> Author(s) : Alia Atlas >>>> Thomas Nadeau >>>> Dave Ward >>>> Filename : draft-ward-irs-framework-00.txt >>>> Pages : 21 >>>> Date : 2012-07-30 >>>> >>>> Abstract: >>>> This document describes a framework for a standard, programmatic >>>> interface for full-duplex, streaming state transfer in and out of = the >>>> Internet's routing system. It lists the information that might be >>>> exchanged over the interface, and describes the uses of an interfa= ce >>>> to the Internet routing system. >>>> >>> _______________________________________________ >>> 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 Return-Path: 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 291E411E8117 for ; Wed, 1 Aug 2012 15:57:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.338 X-Spam-Level: X-Spam-Status: No, score=-4.338 tagged_above=-999 required=5 tests=[AWL=2.261, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DVxQhsK6gkFT for ; Wed, 1 Aug 2012 15:57:40 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 114F011E80BA for ; Wed, 1 Aug 2012 15:57:40 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml202-edg.china.huawei.com) ([172.18.9.243]) by dfwrg02-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AII58881; Wed, 01 Aug 2012 14:57:39 -0800 (PST) Received: from DFWEML408-HUB.china.huawei.com (10.193.5.134) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 1 Aug 2012 15:54:57 -0700 Received: from dfweml509-mbs.china.huawei.com ([169.254.12.123]) by dfweml408-hub.china.huawei.com ([10.193.5.134]) with mapi id 14.01.0323.003; Wed, 1 Aug 2012 15:54:55 -0700 From: Susan Hares To: Alia Atlas Thread-Topic: [irs-discuss] I-D Action: draft-ward-irs-framework-00.txt Thread-Index: AQHNbqDE0RghEMqjhk+pxE1DLzQQ1JdClGzAgAB8jgCAAh3/0IAA2WwA//+LWhA= Date: Wed, 1 Aug 2012 22:54:54 +0000 Message-ID: <728F9B956B2C48439CA9294B1723B146237556AB@dfweml509-mbs.china.huawei.com> References: <20120730180849.1235.96769.idtracker@ietfa.amsl.com> <50170758.3030908@joelhalpern.com> <728F9B956B2C48439CA9294B1723B14623754A03@dfweml509-mbs.china.huawei.com> <728F9B956B2C48439CA9294B1723B146237553BF@dfweml509-mbs.china.huawei.com> In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.212.246.58] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "Joel M. Halpern" , "irs-discuss@ietf.org" Subject: Re: [irs-discuss] I-D Action: draft-ward-irs-framework-00.txt X-BeenThere: irs-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Aug 2012 22:57:41 -0000 Alia: I'll try to create a bibliography of things people should read. It will be= mid-next week since I'm away from my home library on the SDN topic. Sue=20 -----Original Message----- From: Alia Atlas [mailto:akatlas@gmail.com]=20 Sent: Wednesday, August 01, 2012 3:51 PM To: Susan Hares Cc: Joel M. Halpern; irs-discuss@ietf.org Subject: Re: [irs-discuss] I-D Action: draft-ward-irs-framework-00.txt Sue, I look forward to talking with you more off-line on the policy and local-pref research and issues. If you have suggestions on good background research to read, by all means send it to the list so others can get up to speed as well. On the atomic transaction semantics question, let's get a bit further into the use-cases and framework - and then have a focused discussion. I'm not opposed to it forever or if it is necessary - just would like to thoroughly analyze if it is a real requirement. Do others have opinions and perspective on this? Alia On Wed, Aug 1, 2012 at 1:58 PM, Susan Hares wrote: > Alia: > > The hierarchical of interfaces (To routing system) is one of the areas th= at requires prioritization. The prioritization must be able to handle "pree= mpt me", "after you", and "after me". > > It is also key to understand that irs system must handle multi-interfaces= struggles at the lowest layer. You need to look at the MIF WG (+/-) for s= ome of the struggles of mobility. > > -----Original Message----- > From: Alia Atlas [mailto:akatlas@gmail.com] > Sent: Monday, July 30, 2012 6:33 PM > To: Susan Hares > Cc: Joel M. Halpern; irs-discuss@ietf.org > Subject: Re: [irs-discuss] I-D Action: draft-ward-irs-framework-00.txt > > Hi Sue, > > On Mon, Jul 30, 2012 at 9:16 PM, Susan Hares wro= te: >> Joel and irs-folks: >> >> +1 on Joel. >> >> Beyond your comments, the requirement prioritization of the interworkin= g of these interfaces is not clearly delineated in this work. This type of = prioritization and sequencing is key to multi-interfaces operation on the m= onitoring, configuration or insertion of information into the depth. > > [Alia] Can you further clarify, maybe with an example, which aspect > you are thinking of? Do you mean the ability of an application to > access multiple sub-interfaces? The interaction of operations > requested by differerent applications? > >> In addition, if you are going to do configuration with roll-forward/roll= -back - you need a transaction based processing. > > [Alia] I'm pretty sure that I avoided the word "transaction" in both > drafts. That was deliberate. Of course, we can have a discussion > about whether or not some form of transactions might be desirable. I > am concerned about their potentially heavy-weight nature. > >> Therefore, you've skipped even requiring the hard problems. > > [Alia] Can I optimistically pretend that means that the requirements > we do have don't seem too hard? For the responsiveness and throughput > goals, I've put a stake in the ground to avoid transaction-based > semantics. Naturally, the hordes can run over that stake, if > necessary. > > [Sue]: The requirements are necessary even if they are hard. > > [Alia] For the interaction between different layers of sub-interfaces, > I've been assuming that we'll define the interactions between the > layers based on how they are generally done. For instance, perhaps we > standardize the idea of preference value - and then the RIB can pick > the best route based upon those preferences. For interaction between > different applications, I think there's a mixture of > authorization/authentication to get right plus a good set of events > that an application could register for. > > [Sue]: As someone who has lived with "local pref" in BGP for a long time,= there is a bit more to unwrap in the statement. However, it breaks down t= o prioritization that is pre-set by preferences. > > The policy issues behind the local-pref setting have been studied by the = BGP policy community. This is substantial good work on this from the academ= ic researchers, vendors, and operator. Griffins, Rexford, Bush, Feamster, .= .... and lots others are much better on the theory than I am. > >> Is this just the -00.draft? > > [Alia] Certainly, I expect that we'll uncover more requirements as we > go along. As I said, some of this is initially setting parts out of > scope. > > ---> Scope =3D=3D good. Setting scope allows us to pick a piece of this = work and standardize it for interoperability. > > Alia > >> Sue >> >> >> >> -----Original Message----- >> From: irs-discuss-bounces@ietf.org [mailto:irs-discuss-bounces@ietf.org]= On Behalf Of Joel M. Halpern >> Sent: Monday, July 30, 2012 3:15 PM >> To: irs-discuss@ietf.org >> Subject: Re: [irs-discuss] I-D Action: draft-ward-irs-framework-00.txt >> >> I am finding this document quite confusing. >> >> The primary confusion is that the document first says that it is about >> information that can not be manipulated with existing systems, and then >> proceeds to give a list of use cases all of which can be manipulated >> with existing systems at a suitable degree of abstraction. >> >> As a lesser confusion, the document says that "streaming" is important, >> but then describes "streaming" as "fast, interactive access." That is >> not streaming. And depending upon what one means by interactive, plenty >> of systems provide "fest, interactive access." I realize the document >> later goes on tot talk about speed and frequency of state updates. But >> that section simply reasserts the earlier terms withotu better >> description or justification. >> >> Yours, >> Joel >> >> On 7/30/2012 2:08 PM, internet-drafts@ietf.org wrote: >>> >>> A New Internet-Draft is available from the on-line Internet-Drafts dire= ctories. >>> >>> >>> Title : Interface to the Routing System Framework >>> Author(s) : Alia Atlas >>> Thomas Nadeau >>> Dave Ward >>> Filename : draft-ward-irs-framework-00.txt >>> Pages : 21 >>> Date : 2012-07-30 >>> >>> Abstract: >>> This document describes a framework for a standard, programmatic >>> interface for full-duplex, streaming state transfer in and out of t= he >>> Internet's routing system. It lists the information that might be >>> exchanged over the interface, and describes the uses of an interfac= e >>> to the Internet routing system. >>> >> _______________________________________________ >> 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 Return-Path: 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 36B9E11E8131 for ; Wed, 1 Aug 2012 15:51:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R0WcIDpA-WPZ for ; Wed, 1 Aug 2012 15:51:16 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id C412A11E811D for ; Wed, 1 Aug 2012 15:51:15 -0700 (PDT) Received: by yenq13 with SMTP id q13so8544889yen.31 for ; Wed, 01 Aug 2012 15:51:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=1w+3Qnk6yisGvyAmJkGR2olpmqItrNwK0R9JC1t9KMU=; b=PBRPZkVNARvP0CQFxL59Pyx6jPwlsUrEKUq1RKrO+EEvU1FmuPowTyyvkDBUCvkME7 XM/EJCmPcAeQt0yircqHmqllCLY4cEyn+nJmktjTBn3EqjnkAJP8vxFdrfjt+bZR3yd9 VWysmJxYJqbKYv5ZSCYk2Dz4QUZw+Tn4cET7dmM83FiP8zdTORMtADkxYOKqefnTKqJJ 7j7tMo2kxCxJI7BdE7t5hcJuZ7y8bbkDo9smVy2EarYmGzq8QQAtxp9U1g2Wb9hw+ieF SPhBC6sK9mJgxXJmaxr0V67xTzKPea7fycMcqTci3IKU+MHBxWVq59L3PvUfu2Xfhkqp Mi3A== MIME-Version: 1.0 Received: by 10.50.236.4 with SMTP id uq4mr6963395igc.18.1343861474957; Wed, 01 Aug 2012 15:51:14 -0700 (PDT) Received: by 10.50.34.169 with HTTP; Wed, 1 Aug 2012 15:51:14 -0700 (PDT) In-Reply-To: <728F9B956B2C48439CA9294B1723B146237553BF@dfweml509-mbs.china.huawei.com> References: <20120730180849.1235.96769.idtracker@ietfa.amsl.com> <50170758.3030908@joelhalpern.com> <728F9B956B2C48439CA9294B1723B14623754A03@dfweml509-mbs.china.huawei.com> <728F9B956B2C48439CA9294B1723B146237553BF@dfweml509-mbs.china.huawei.com> Date: Wed, 1 Aug 2012 18:51:14 -0400 Message-ID: From: Alia Atlas To: Susan Hares Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "Joel M. Halpern" , "irs-discuss@ietf.org" Subject: Re: [irs-discuss] I-D Action: draft-ward-irs-framework-00.txt X-BeenThere: irs-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Aug 2012 22:51:17 -0000 Sue, I look forward to talking with you more off-line on the policy and local-pref research and issues. If you have suggestions on good background research to read, by all means send it to the list so others can get up to speed as well. On the atomic transaction semantics question, let's get a bit further into the use-cases and framework - and then have a focused discussion. I'm not opposed to it forever or if it is necessary - just would like to thoroughly analyze if it is a real requirement. Do others have opinions and perspective on this? Alia On Wed, Aug 1, 2012 at 1:58 PM, Susan Hares wrote: > Alia: > > The hierarchical of interfaces (To routing system) is one of the areas th= at requires prioritization. The prioritization must be able to handle "pree= mpt me", "after you", and "after me". > > It is also key to understand that irs system must handle multi-interfaces= struggles at the lowest layer. You need to look at the MIF WG (+/-) for s= ome of the struggles of mobility. > > -----Original Message----- > From: Alia Atlas [mailto:akatlas@gmail.com] > Sent: Monday, July 30, 2012 6:33 PM > To: Susan Hares > Cc: Joel M. Halpern; irs-discuss@ietf.org > Subject: Re: [irs-discuss] I-D Action: draft-ward-irs-framework-00.txt > > Hi Sue, > > On Mon, Jul 30, 2012 at 9:16 PM, Susan Hares wro= te: >> Joel and irs-folks: >> >> +1 on Joel. >> >> Beyond your comments, the requirement prioritization of the interworkin= g of these interfaces is not clearly delineated in this work. This type of = prioritization and sequencing is key to multi-interfaces operation on the m= onitoring, configuration or insertion of information into the depth. > > [Alia] Can you further clarify, maybe with an example, which aspect > you are thinking of? Do you mean the ability of an application to > access multiple sub-interfaces? The interaction of operations > requested by differerent applications? > >> In addition, if you are going to do configuration with roll-forward/roll= -back - you need a transaction based processing. > > [Alia] I'm pretty sure that I avoided the word "transaction" in both > drafts. That was deliberate. Of course, we can have a discussion > about whether or not some form of transactions might be desirable. I > am concerned about their potentially heavy-weight nature. > >> Therefore, you've skipped even requiring the hard problems. > > [Alia] Can I optimistically pretend that means that the requirements > we do have don't seem too hard? For the responsiveness and throughput > goals, I've put a stake in the ground to avoid transaction-based > semantics. Naturally, the hordes can run over that stake, if > necessary. > > [Sue]: The requirements are necessary even if they are hard. > > [Alia] For the interaction between different layers of sub-interfaces, > I've been assuming that we'll define the interactions between the > layers based on how they are generally done. For instance, perhaps we > standardize the idea of preference value - and then the RIB can pick > the best route based upon those preferences. For interaction between > different applications, I think there's a mixture of > authorization/authentication to get right plus a good set of events > that an application could register for. > > [Sue]: As someone who has lived with "local pref" in BGP for a long time,= there is a bit more to unwrap in the statement. However, it breaks down t= o prioritization that is pre-set by preferences. > > The policy issues behind the local-pref setting have been studied by the = BGP policy community. This is substantial good work on this from the academ= ic researchers, vendors, and operator. Griffins, Rexford, Bush, Feamster, .= .... and lots others are much better on the theory than I am. > >> Is this just the -00.draft? > > [Alia] Certainly, I expect that we'll uncover more requirements as we > go along. As I said, some of this is initially setting parts out of > scope. > > ---> Scope =3D=3D good. Setting scope allows us to pick a piece of this = work and standardize it for interoperability. > > Alia > >> Sue >> >> >> >> -----Original Message----- >> From: irs-discuss-bounces@ietf.org [mailto:irs-discuss-bounces@ietf.org]= On Behalf Of Joel M. Halpern >> Sent: Monday, July 30, 2012 3:15 PM >> To: irs-discuss@ietf.org >> Subject: Re: [irs-discuss] I-D Action: draft-ward-irs-framework-00.txt >> >> I am finding this document quite confusing. >> >> The primary confusion is that the document first says that it is about >> information that can not be manipulated with existing systems, and then >> proceeds to give a list of use cases all of which can be manipulated >> with existing systems at a suitable degree of abstraction. >> >> As a lesser confusion, the document says that "streaming" is important, >> but then describes "streaming" as "fast, interactive access." That is >> not streaming. And depending upon what one means by interactive, plenty >> of systems provide "fest, interactive access." I realize the document >> later goes on tot talk about speed and frequency of state updates. But >> that section simply reasserts the earlier terms withotu better >> description or justification. >> >> Yours, >> Joel >> >> On 7/30/2012 2:08 PM, internet-drafts@ietf.org wrote: >>> >>> A New Internet-Draft is available from the on-line Internet-Drafts dire= ctories. >>> >>> >>> Title : Interface to the Routing System Framework >>> Author(s) : Alia Atlas >>> Thomas Nadeau >>> Dave Ward >>> Filename : draft-ward-irs-framework-00.txt >>> Pages : 21 >>> Date : 2012-07-30 >>> >>> Abstract: >>> This document describes a framework for a standard, programmatic >>> interface for full-duplex, streaming state transfer in and out of t= he >>> Internet's routing system. It lists the information that might be >>> exchanged over the interface, and describes the uses of an interfac= e >>> to the Internet routing system. >>> >> _______________________________________________ >> 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 Return-Path: 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 F390811E811E for ; Wed, 1 Aug 2012 15:40:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jyJE33yPKYP0 for ; Wed, 1 Aug 2012 15:40:34 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 0E88811E8117 for ; Wed, 1 Aug 2012 15:40:33 -0700 (PDT) Received: by yhq56 with SMTP id 56so8526073yhq.31 for ; Wed, 01 Aug 2012 15:40:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=jpuZk9gjUxk836dHDpJF//Q8qAL5DgU4+KvDqr4NQSM=; b=a7E4/DKm9W/PMCRJqvpUlO8aBowcXq8Cufix3IFrnkNrSR/fkPds6iZXbh6U6gBFHL wfxjsfeBCtShloGYIZcDoZrxDD2TJA8O5XRVdNw8fL/COqJcxa+bAIWwCQWk3IArqBZ5 80LiUHR5ihkSwnvvIZP80j3QNTw7x4whzK39vCl2Ko2axCIe1JOiMq54HvO5VtRHkYPw 1jE8G1mjHxf3D14sL5s4gVIi2aEt5exa8Zl6fhwIsEA2V7Ch1fyZt9TVkUlU7+vYxAZw +wx8wEw471OyMNj/Yiq/tlnQZa4kGhMdVClCBVYrDOwlgyLXxpO/wlotxjTuNJ/4twhg pFbw== MIME-Version: 1.0 Received: by 10.50.213.98 with SMTP id nr2mr6564852igc.71.1343860832922; Wed, 01 Aug 2012 15:40:32 -0700 (PDT) Received: by 10.50.34.169 with HTTP; Wed, 1 Aug 2012 15:40:32 -0700 (PDT) In-Reply-To: <728F9B956B2C48439CA9294B1723B146237553E6@dfweml509-mbs.china.huawei.com> References: <728F9B956B2C48439CA9294B1723B14623754A18@dfweml509-mbs.china.huawei.com> <728F9B956B2C48439CA9294B1723B146237553E6@dfweml509-mbs.china.huawei.com> Date: Wed, 1 Aug 2012 18:40:32 -0400 Message-ID: From: Alia Atlas To: Susan Hares Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Thomas Nadeau , Nitin Bahadur , James Kempf , "irs-discuss@ietf.org" Subject: Re: [irs-discuss] IRS Problem Statement Posted X-BeenThere: irs-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Aug 2012 22:40:35 -0000 Sue, In this case, I was thinking of "translating" from a "higher abstraction layer" to a "lower abstraction layer". Do you have a better/different term to suggest? I agree that clarity of terminology is important. Alia On Wed, Aug 1, 2012 at 2:03 PM, Susan Hares wrote: > Alia: > > +1 on abstraction + filters (abstract/detail) IRS fits at the routing con= trol. > > The real question about translation is what the translation is doing. Is= it translating one thing to another at the same layer of abstraction (e.g.= , Spanish/English, Ascii/ebcdic) or is it doing abstraction/detail change. > > I define translation as the same layer of abstraction. Some people sugge= st translation =3D abstract/detailing. We first need a common way to talk = about the difference. > > Sue > > By the way --- I'm thrilled about the pace of the discussion. > > > -----Original Message----- > From: Alia Atlas [mailto:akatlas@gmail.com] > Sent: Monday, July 30, 2012 6:40 PM > To: Susan Hares > Cc: Nitin Bahadur; James Kempf; Thomas Nadeau; irs-discuss@ietf.org > Subject: Re: [irs-discuss] IRS Problem Statement Posted > > Sue, > > I certainly agree that we want IRS to have the ability to express > information at different abstraction layers and filtered on request. > > There may still be a gap between the "network OS abstractions" and IRS > sub-interfaces; I'd be surprised if there weren't. IRS is to provide > the bottom-up control strings. > > IMHO, it's reasonable to have an entity that manages the translation. > For instance, one doesn't need a PCE-equiv in every application - nor > in every router; that might be an entity in between. > > The quantity of information is part of why explicit filtering and > hopefully abstraction layers should be built into the data-models. > > Alia > > On Mon, Jul 30, 2012 at 9:24 PM, Susan Hares wro= te: >> Nitin: >> >> Exposing some network intelligence can either be done in detail or in so= me amount of summarization. >> If you are doing detail, you have bandwidth issues. If you are doing sum= marization or opacity, you are talking about layers of information. >> >> Apps need to find out what they need to get. They do not need all the de= tails - just the fact they can get from point A to Point B (or for multi-ca= st B/C/D). They need to where they can go to date other applications. They= need a match-maker for the application who determine where the application= s shall flow. Now, if they are smart - like people going out to eat - they= pick several ways go to eat traffic. >> >> The network orchestration then serves to be the paths to the place to ea= t. This can either be distributed or centralized. >> >> If we have an Interface to routing, it need to have a two-layer concept = of exposing information. >> >> Sue Hares >> >> -----Original Message----- >> From: irs-discuss-bounces@ietf.org [mailto:irs-discuss-bounces@ietf.org]= On Behalf Of Nitin Bahadur >> Sent: Monday, July 30, 2012 3:33 PM >> To: James Kempf; Thomas Nadeau; irs-discuss@ietf.org >> Subject: Re: [irs-discuss] IRS Problem Statement Posted >> >> Hi James, >> >> This is not about splitting control plane and forwarding plane. It is ab= out exposing network intelligence in the network elements to an external co= ntroller. >> And it is about allowing an external controller to use that information = for enabling network-aware apps. And it is about allowing apps to influence= the >> network element's RIB (not the FIB directly). >> >> Streaming is essential to allow for operations at scale...and avoid a re= quest/response gated mechanism. >> >> Hope that helps. >> >> Thanks >> Nitin >> >> On 7/30/12 3:11 PM, "James Kempf" wrote: >> >> I don't understand why streaming is specified in this draft. And I don't= understand why this draft isn't put in the Forces framework. Forces is a f= ramework explicitedly designed for device to controller communication. Its = major drawback it that it is a framework with a hole in the middle, in that= there are no specified devices. This draft would fill that hole. >> >> I don't think it is necessary to have a problem statement for router sta= te update. Forces has already established that splitting the control plane = into a separate device is, in some cases, an attractive design option. So I= think this should be submitted to the Forces working group, or, at least, = recast in the Forces framework. >> >> jak >> >>> -----Original Message----- >>> From: irs-discuss-bounces@ietf.org >>> [mailto:irs-discuss-bounces@ietf.org] On Behalf Of Thomas Nadeau >>> Sent: Monday, July 30, 2012 11:18 AM >>> To: irs-discuss@ietf.org >>> Subject: [irs-discuss] IRS Problem Statement Posted >>> >>> >>> >>> Please review and discuss. >>> >>> Thanks, >>> >>> Tom, Alia, Ward >>> >>> >>> http://lucidvision.com/draft-atlas-irs-problem-statement-00.txt >>> >>> >>> _______________________________________________ >>> 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 >> >> _______________________________________________ >> 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 Return-Path: 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 7AC6511E809B for ; Wed, 1 Aug 2012 12:40:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.177 X-Spam-Level: X-Spam-Status: No, score=-4.177 tagged_above=-999 required=5 tests=[AWL=2.422, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DvaExfIaw+8Q for ; Wed, 1 Aug 2012 12:40:48 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 8955011E80A3 for ; Wed, 1 Aug 2012 12:40:48 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml202-edg.china.huawei.com) ([172.18.9.243]) by dfwrg02-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AII48369; Wed, 01 Aug 2012 11:40:48 -0800 (PST) Received: from DFWEML408-HUB.china.huawei.com (10.193.5.134) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 1 Aug 2012 12:38:06 -0700 Received: from dfweml509-mbs.china.huawei.com ([169.254.12.123]) by dfweml408-hub.china.huawei.com ([10.193.5.134]) with mapi id 14.01.0323.003; Wed, 1 Aug 2012 12:38:00 -0700 From: Susan Hares To: Russ White , "irs-discuss@ietf.org" Thread-Topic: [irs-discuss] Thoughts on draft-ward-irs-framework Thread-Index: AQHNb36MjASCLFSBKk6d1/vhypXJiJdFQeBA Date: Wed, 1 Aug 2012 19:38:00 +0000 Message-ID: <728F9B956B2C48439CA9294B1723B1462375556A@dfweml509-mbs.china.huawei.com> References: <50187B55.407@riw.us> In-Reply-To: <50187B55.407@riw.us> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.212.245.173] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [irs-discuss] Thoughts on draft-ward-irs-framework X-BeenThere: irs-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Aug 2012 19:40:49 -0000 Russ:=20 -----Original Message----- From: irs-discuss-bounces@ietf.org [mailto:irs-discuss-bounces@ietf.org] On= Behalf Of Russ White Sent: Tuesday, July 31, 2012 5:42 PM To: irs-discuss@ietf.org Subject: [irs-discuss] Thoughts on draft-ward-irs-framework This framework is well put together, but I'd like to make a couple of suggestions/comments/put some ideas forward. 1. I think the draft struggles somewhat with describing something that's already in all routers today because it's attempting to describe an interface into the RIB that's somehow separate, or stands beside, the existing interfaces into the RIB. I would gently suggest that describing this entire idea as an "off board routing process," much like a BGP process on an existing implementation, might clarify things a bit, and make the model easier to understand. Consider --any given routing process already installs routes into the routing table, including the concept of preference. BGP routing processes, specifically, also have import and export capabilities into various VRFs. All routing processes also have redistribution capabilities. What if you modeled this entire thing as two types of "off board routing processes," one that only imports data from the RIB for northbound consumption (topology information), and one that interacts with the RIB like any other routing process would for southbound control as well as northbound consumption? ----> [Russ]: +1 - This Offboard controller processing aligns with the ONF = view of SDN. And it has been done in practice for 10+ years. However as yo= u know, the timing between the calculation and download to HW is important.= =20 It's going to be much easier to interact with the other routing protocols on the box without a lot of "special pleading" if IRS is a process that's peer to BGP, OSPF, IS-IS, et al. Take the instance of link down notifications --all the implementations I know of process link downs in the RIB, and the RIB then notifies the routing protocol... If you're hooking into the RIB locally, then, you need to hook into link down detection specifically and intentionally. If IRS is a routing process, the RIB will notify the northbound interface as a matter of course in processing link down notifications. I hope that makes sense, but I'm glad to sit and discuss if it doesn't. 2. There needs to be a way to mark routes inserted in the RIB with a process ID of some sort. This would come naturally if the entire IRS idea were to put an "off board routing process" on the box that interacts with existing on board processes (see #1 above), but as the draft stands, there's no way to insert a process id into the RIB. This is crucial for redistribution, and I suspect redistribution is going to be a huge problem to address in the long term, since the routes injected by IRS, however they're injected, will need to interact with the dynamic protocols running on the box. [Sue] See our work on Route servers (1990-1995) and current work - for an e= xample. This is what I mentioned above.=20 3. There are a ton of other possible use cases, if more are needed/wanted to support the reasoning behind the draft. Choosing the optimal exit from any given edge (OER in cisco lingo), a superset of Flowspec to combat DDoS is another (mentioned tangentially, but not as a use case), live/live is another (packet replication and choosing the best of two identical streams) --and there are others... Some of these might actually be more interesting use cases than are currently described in the draft. More if I get the chance to reread it in a little more depth later. Sue: Use cases are key. The clarity of the use cases will guide us. Pleas= e send USE cases. Russ --=20 <>< riwhite@verisign.com russw@riw.us _______________________________________________ irs-discuss mailing list irs-discuss@ietf.org https://www.ietf.org/mailman/listinfo/irs-discuss Return-Path: 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 36C1911E81CE for ; Wed, 1 Aug 2012 11:09:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.99 X-Spam-Level: X-Spam-Status: No, score=-3.99 tagged_above=-999 required=5 tests=[AWL=2.609, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WGMB0SQIKAnr for ; Wed, 1 Aug 2012 11:09:32 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 14FF511E8190 for ; Wed, 1 Aug 2012 11:09:32 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml201-edg.china.huawei.com) ([172.18.9.243]) by dfwrg02-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AII43146; Wed, 01 Aug 2012 10:09:31 -0800 (PST) Received: from DFWEML407-HUB.china.huawei.com (10.193.5.132) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 1 Aug 2012 11:06:50 -0700 Received: from dfweml509-mbs.china.huawei.com ([169.254.12.123]) by dfweml407-hub.china.huawei.com ([10.193.5.132]) with mapi id 14.01.0323.003; Wed, 1 Aug 2012 11:06:52 -0700 From: Susan Hares To: Nitin Bahadur Thread-Topic: [irs-discuss] IRS Problem Statement Posted Thread-Index: Ac1uf6vUr0RoAYPERve+GHr5XPQ6JgAIAMEAAADmuywABbPeIAAPdliAAEN0YNA= Date: Wed, 1 Aug 2012 18:06:51 +0000 Message-ID: <728F9B956B2C48439CA9294B1723B146237553F5@dfweml509-mbs.china.huawei.com> References: <728F9B956B2C48439CA9294B1723B14623754A18@dfweml509-mbs.china.huawei.com> In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.212.245.173] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: Thomas Nadeau , James Kempf , "irs-discuss@ietf.org" Subject: Re: [irs-discuss] IRS Problem Statement Posted X-BeenThere: irs-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Aug 2012 18:09:33 -0000 Nitin: Thanks for the agreement. The real challenge is how to fit the middleware = into the needs of application and network layer. Framework, architecture, = design steps have fascinating challenges that build on the 30+ years of dis= tributed and centralized networking algorithms.=20 Two things often forgotten in these models are security and mobility. In t= he DC & VM-aware world, we cannot skips these two items.=20 As a side note, John Day in Patterns of Networking - suggests that all of = networking can be viewed as middleware. For in the end - we are multiplexin= g application traffic over some media. Networks exist to provide service t= o applications. =20 Sue=20 [love this discussion!] -----Original Message----- From: Nitin Bahadur [mailto:nitinb@juniper.net]=20 Sent: Monday, July 30, 2012 6:39 PM To: Susan Hares Cc: James Kempf; Thomas Nadeau; irs-discuss@ietf.org Subject: Re: [irs-discuss] IRS Problem Statement Posted Hi Susan, You've expressed my thoughts very succinctly. I fully agree with all yo= u said. IRS is nothing but a middleware IMO.=20 An orchestrator has 3 layers: The top layer exposes the northbound Apis to apps - I want a path from A to= B with a constrain on low latency. That's all the app should need to say. The bottom layer fetches topology, stats and other data from network elemen= ts and programs the network elements. And the middle layer is the business layer that takes user input from north= bound Apis, takes input from bottom layer; munches on the data and converts= it into rules for the bottom layer to program. So IRS needs to define interfaces for both the lower layer and the upper la= yer. Thanks Nitin On Jul 30, 2012, at 6:27 PM, "Susan Hares" wrote: > Nitin:=20 >=20 > Exposing some network intelligence can either be done in detail or in som= e amount of summarization.=20 > If you are doing detail, you have bandwidth issues. If you are doing summ= arization or opacity, you are talking about layers of information.=20 >=20 > Apps need to find out what they need to get. They do not need all the det= ails - just the fact they can get from point A to Point B (or for multi-cas= t B/C/D). They need to where they can go to date other applications. They = need a match-maker for the application who determine where the applications= shall flow. Now, if they are smart - like people going out to eat - they = pick several ways go to eat traffic. =20 >=20 > The network orchestration then serves to be the paths to the place to eat= . This can either be distributed or centralized. =20 >=20 > If we have an Interface to routing, it need to have a two-layer concept o= f exposing information. =20 >=20 > Sue Hares=20 >=20 > -----Original Message----- > From: irs-discuss-bounces@ietf.org [mailto:irs-discuss-bounces@ietf.org] = On Behalf Of Nitin Bahadur > Sent: Monday, July 30, 2012 3:33 PM > To: James Kempf; Thomas Nadeau; irs-discuss@ietf.org > Subject: Re: [irs-discuss] IRS Problem Statement Posted >=20 > Hi James, >=20 > This is not about splitting control plane and forwarding plane. It is abo= ut exposing network intelligence in the network elements to an external con= troller. > And it is about allowing an external controller to use that information f= or enabling network-aware apps. And it is about allowing apps to influence = the > network element's RIB (not the FIB directly). >=20 > Streaming is essential to allow for operations at scale...and avoid a req= uest/response gated mechanism. >=20 > Hope that helps. >=20 > Thanks > Nitin >=20 > On 7/30/12 3:11 PM, "James Kempf" wrote: >=20 > I don't understand why streaming is specified in this draft. And I don't = understand why this draft isn't put in the Forces framework. Forces is a fr= amework explicitedly designed for device to controller communication. Its m= ajor drawback it that it is a framework with a hole in the middle, in that = there are no specified devices. This draft would fill that hole. >=20 > I don't think it is necessary to have a problem statement for router stat= e update. Forces has already established that splitting the control plane i= nto a separate device is, in some cases, an attractive design option. So I = think this should be submitted to the Forces working group, or, at least, r= ecast in the Forces framework. >=20 > jak >=20 >> -----Original Message----- >> From: irs-discuss-bounces@ietf.org >> [mailto:irs-discuss-bounces@ietf.org] On Behalf Of Thomas Nadeau >> Sent: Monday, July 30, 2012 11:18 AM >> To: irs-discuss@ietf.org >> Subject: [irs-discuss] IRS Problem Statement Posted >>=20 >>=20 >>=20 >> Please review and discuss. >>=20 >> Thanks, >>=20 >> Tom, Alia, Ward >>=20 >>=20 >> http://lucidvision.com/draft-atlas-irs-problem-statement-00.txt >>=20 >>=20 >> _______________________________________________ >> irs-discuss mailing list >> irs-discuss@ietf.org >> https://www.ietf.org/mailman/listinfo/irs-discuss >>=20 > _______________________________________________ > irs-discuss mailing list > irs-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/irs-discuss >=20 > _______________________________________________ > irs-discuss mailing list > irs-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/irs-discuss Return-Path: 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 CC02611E80EC for ; Wed, 1 Aug 2012 11:05:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.773 X-Spam-Level: X-Spam-Status: No, score=-3.773 tagged_above=-999 required=5 tests=[AWL=2.826, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gsbrFhfzr8Xt for ; Wed, 1 Aug 2012 11:05:52 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id E4B2121F87E2 for ; Wed, 1 Aug 2012 11:05:51 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml201-edg.china.huawei.com) ([172.18.9.243]) by dfwrg02-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AII42980; Wed, 01 Aug 2012 10:05:51 -0800 (PST) Received: from DFWEML404-HUB.china.huawei.com (10.193.5.203) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 1 Aug 2012 11:03:23 -0700 Received: from dfweml509-mbs.china.huawei.com ([169.254.12.123]) by dfweml404-hub.china.huawei.com ([10.193.5.203]) with mapi id 14.01.0323.003; Wed, 1 Aug 2012 11:03:23 -0700 From: Susan Hares To: Alia Atlas Thread-Topic: [irs-discuss] IRS Problem Statement Posted Thread-Index: Ac1uf6vUr0RoAYPERve+GHr5XPQ6JgAIAMEAAADmuywABbPeIAAPeoSAAEN3KtA= Date: Wed, 1 Aug 2012 18:03:22 +0000 Message-ID: <728F9B956B2C48439CA9294B1723B146237553E6@dfweml509-mbs.china.huawei.com> References: <728F9B956B2C48439CA9294B1723B14623754A18@dfweml509-mbs.china.huawei.com> In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.212.245.173] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: Thomas Nadeau , Nitin Bahadur , James Kempf , "irs-discuss@ietf.org" Subject: Re: [irs-discuss] IRS Problem Statement Posted X-BeenThere: irs-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Aug 2012 18:05:55 -0000 Alia: +1 on abstraction + filters (abstract/detail) IRS fits at the routing contr= ol. =20 The real question about translation is what the translation is doing. Is i= t translating one thing to another at the same layer of abstraction (e.g., = Spanish/English, Ascii/ebcdic) or is it doing abstraction/detail change.=20 I define translation as the same layer of abstraction. Some people suggest= translation =3D abstract/detailing. We first need a common way to talk ab= out the difference.=20 Sue By the way --- I'm thrilled about the pace of the discussion.=20 =20 -----Original Message----- From: Alia Atlas [mailto:akatlas@gmail.com]=20 Sent: Monday, July 30, 2012 6:40 PM To: Susan Hares Cc: Nitin Bahadur; James Kempf; Thomas Nadeau; irs-discuss@ietf.org Subject: Re: [irs-discuss] IRS Problem Statement Posted Sue, I certainly agree that we want IRS to have the ability to express information at different abstraction layers and filtered on request. There may still be a gap between the "network OS abstractions" and IRS sub-interfaces; I'd be surprised if there weren't. IRS is to provide the bottom-up control strings. IMHO, it's reasonable to have an entity that manages the translation. For instance, one doesn't need a PCE-equiv in every application - nor in every router; that might be an entity in between. The quantity of information is part of why explicit filtering and hopefully abstraction layers should be built into the data-models. Alia On Mon, Jul 30, 2012 at 9:24 PM, Susan Hares wrote= : > Nitin: > > Exposing some network intelligence can either be done in detail or in som= e amount of summarization. > If you are doing detail, you have bandwidth issues. If you are doing summ= arization or opacity, you are talking about layers of information. > > Apps need to find out what they need to get. They do not need all the det= ails - just the fact they can get from point A to Point B (or for multi-cas= t B/C/D). They need to where they can go to date other applications. They = need a match-maker for the application who determine where the applications= shall flow. Now, if they are smart - like people going out to eat - they = pick several ways go to eat traffic. > > The network orchestration then serves to be the paths to the place to eat= . This can either be distributed or centralized. > > If we have an Interface to routing, it need to have a two-layer concept o= f exposing information. > > Sue Hares > > -----Original Message----- > From: irs-discuss-bounces@ietf.org [mailto:irs-discuss-bounces@ietf.org] = On Behalf Of Nitin Bahadur > Sent: Monday, July 30, 2012 3:33 PM > To: James Kempf; Thomas Nadeau; irs-discuss@ietf.org > Subject: Re: [irs-discuss] IRS Problem Statement Posted > > Hi James, > > This is not about splitting control plane and forwarding plane. It is abo= ut exposing network intelligence in the network elements to an external con= troller. > And it is about allowing an external controller to use that information f= or enabling network-aware apps. And it is about allowing apps to influence = the > network element's RIB (not the FIB directly). > > Streaming is essential to allow for operations at scale...and avoid a req= uest/response gated mechanism. > > Hope that helps. > > Thanks > Nitin > > On 7/30/12 3:11 PM, "James Kempf" wrote: > > I don't understand why streaming is specified in this draft. And I don't = understand why this draft isn't put in the Forces framework. Forces is a fr= amework explicitedly designed for device to controller communication. Its m= ajor drawback it that it is a framework with a hole in the middle, in that = there are no specified devices. This draft would fill that hole. > > I don't think it is necessary to have a problem statement for router stat= e update. Forces has already established that splitting the control plane i= nto a separate device is, in some cases, an attractive design option. So I = think this should be submitted to the Forces working group, or, at least, r= ecast in the Forces framework. > > jak > >> -----Original Message----- >> From: irs-discuss-bounces@ietf.org >> [mailto:irs-discuss-bounces@ietf.org] On Behalf Of Thomas Nadeau >> Sent: Monday, July 30, 2012 11:18 AM >> To: irs-discuss@ietf.org >> Subject: [irs-discuss] IRS Problem Statement Posted >> >> >> >> Please review and discuss. >> >> Thanks, >> >> Tom, Alia, Ward >> >> >> http://lucidvision.com/draft-atlas-irs-problem-statement-00.txt >> >> >> _______________________________________________ >> 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 > > _______________________________________________ > 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 Return-Path: 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 8C4B221F8818 for ; Wed, 1 Aug 2012 11:00:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.516 X-Spam-Level: X-Spam-Status: No, score=-3.516 tagged_above=-999 required=5 tests=[AWL=3.083, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U0zKZrwGChKO for ; Wed, 1 Aug 2012 11:00:32 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 4364B11E8318 for ; Wed, 1 Aug 2012 11:00:32 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml202-edg.china.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AIP41066; Wed, 01 Aug 2012 10:00:32 -0800 (PST) Received: from DFWEML403-HUB.china.huawei.com (10.193.5.151) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 1 Aug 2012 10:58:13 -0700 Received: from dfweml509-mbs.china.huawei.com ([169.254.12.123]) by dfweml403-hub.china.huawei.com ([10.193.5.151]) with mapi id 14.01.0323.003; Wed, 1 Aug 2012 10:58:09 -0700 From: Susan Hares To: Alia Atlas Thread-Topic: [irs-discuss] I-D Action: draft-ward-irs-framework-00.txt Thread-Index: AQHNbqDE0RghEMqjhk+pxE1DLzQQ1JdClGzAgAB8jgCAAh3/0A== Date: Wed, 1 Aug 2012 17:58:09 +0000 Message-ID: <728F9B956B2C48439CA9294B1723B146237553BF@dfweml509-mbs.china.huawei.com> References: <20120730180849.1235.96769.idtracker@ietfa.amsl.com> <50170758.3030908@joelhalpern.com> <728F9B956B2C48439CA9294B1723B14623754A03@dfweml509-mbs.china.huawei.com> In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.212.245.173] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "Joel M. Halpern" , "irs-discuss@ietf.org" Subject: Re: [irs-discuss] I-D Action: draft-ward-irs-framework-00.txt X-BeenThere: irs-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Aug 2012 18:00:34 -0000 Alia: The hierarchical of interfaces (To routing system) is one of the areas that= requires prioritization. The prioritization must be able to handle "preemp= t me", "after you", and "after me". =20 It is also key to understand that irs system must handle multi-interfaces s= truggles at the lowest layer. You need to look at the MIF WG (+/-) for som= e of the struggles of mobility.=20 -----Original Message----- From: Alia Atlas [mailto:akatlas@gmail.com]=20 Sent: Monday, July 30, 2012 6:33 PM To: Susan Hares Cc: Joel M. Halpern; irs-discuss@ietf.org Subject: Re: [irs-discuss] I-D Action: draft-ward-irs-framework-00.txt Hi Sue, On Mon, Jul 30, 2012 at 9:16 PM, Susan Hares wrote= : > Joel and irs-folks: > > +1 on Joel. > > Beyond your comments, the requirement prioritization of the interworking= of these interfaces is not clearly delineated in this work. This type of p= rioritization and sequencing is key to multi-interfaces operation on the mo= nitoring, configuration or insertion of information into the depth. [Alia] Can you further clarify, maybe with an example, which aspect you are thinking of? Do you mean the ability of an application to access multiple sub-interfaces? The interaction of operations requested by differerent applications? > In addition, if you are going to do configuration with roll-forward/roll-= back - you need a transaction based processing. [Alia] I'm pretty sure that I avoided the word "transaction" in both drafts. That was deliberate. Of course, we can have a discussion about whether or not some form of transactions might be desirable. I am concerned about their potentially heavy-weight nature. > Therefore, you've skipped even requiring the hard problems. [Alia] Can I optimistically pretend that means that the requirements we do have don't seem too hard? For the responsiveness and throughput goals, I've put a stake in the ground to avoid transaction-based semantics. Naturally, the hordes can run over that stake, if necessary. [Sue]: The requirements are necessary even if they are hard. =20 [Alia] For the interaction between different layers of sub-interfaces, I've been assuming that we'll define the interactions between the layers based on how they are generally done. For instance, perhaps we standardize the idea of preference value - and then the RIB can pick the best route based upon those preferences. For interaction between different applications, I think there's a mixture of authorization/authentication to get right plus a good set of events that an application could register for. [Sue]: As someone who has lived with "local pref" in BGP for a long time, t= here is a bit more to unwrap in the statement. However, it breaks down to = prioritization that is pre-set by preferences. The policy issues behind the local-pref setting have been studied by the BG= P policy community. This is substantial good work on this from the academic= researchers, vendors, and operator. Griffins, Rexford, Bush, Feamster, ...= .. and lots others are much better on the theory than I am. =20 > Is this just the -00.draft? [Alia] Certainly, I expect that we'll uncover more requirements as we go along. As I said, some of this is initially setting parts out of scope. ---> Scope =3D=3D good. Setting scope allows us to pick a piece of this wo= rk and standardize it for interoperability. Alia > Sue > > > > -----Original Message----- > From: irs-discuss-bounces@ietf.org [mailto:irs-discuss-bounces@ietf.org] = On Behalf Of Joel M. Halpern > Sent: Monday, July 30, 2012 3:15 PM > To: irs-discuss@ietf.org > Subject: Re: [irs-discuss] I-D Action: draft-ward-irs-framework-00.txt > > I am finding this document quite confusing. > > The primary confusion is that the document first says that it is about > information that can not be manipulated with existing systems, and then > proceeds to give a list of use cases all of which can be manipulated > with existing systems at a suitable degree of abstraction. > > As a lesser confusion, the document says that "streaming" is important, > but then describes "streaming" as "fast, interactive access." That is > not streaming. And depending upon what one means by interactive, plenty > of systems provide "fest, interactive access." I realize the document > later goes on tot talk about speed and frequency of state updates. But > that section simply reasserts the earlier terms withotu better > description or justification. > > Yours, > Joel > > On 7/30/2012 2:08 PM, internet-drafts@ietf.org wrote: >> >> A New Internet-Draft is available from the on-line Internet-Drafts direc= tories. >> >> >> Title : Interface to the Routing System Framework >> Author(s) : Alia Atlas >> Thomas Nadeau >> Dave Ward >> Filename : draft-ward-irs-framework-00.txt >> Pages : 21 >> Date : 2012-07-30 >> >> Abstract: >> This document describes a framework for a standard, programmatic >> interface for full-duplex, streaming state transfer in and out of th= e >> Internet's routing system. It lists the information that might be >> exchanged over the interface, and describes the uses of an interface >> to the Internet routing system. >> > _______________________________________________ > 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 Return-Path: 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 7361A21F8DAB for ; Wed, 1 Aug 2012 06:52:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vJjw79pCzycR for ; Wed, 1 Aug 2012 06:52:26 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 3913321F8DA1 for ; Wed, 1 Aug 2012 06:52:26 -0700 (PDT) Received: by yenq13 with SMTP id q13so7909256yen.31 for ; Wed, 01 Aug 2012 06:52:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=QMI7uA9QkecjjIzL7i0+Sv3mZuFfpRgkanZxo6fV3m0=; b=JCah07KRupy279stmbSbkC9MMHffjCrtpJ4v++B+z6mAQ96/Vnd5qt2YyOwWWYw+Kz 3JFCCSd34O9iXlr4gzuKv0cA0MOBHnFVKtFCxcKWdaLViPMnBginGC4iSCJVVqVwYdlZ fMonhATXGtTKWeAoD/SjZJQfG5a3Q8W1OOHf8pg5bhFTG/l5yxGHtWjb/+X97ZiSwwoY 2EY5xQrt+xIshjlSkhU9gErOMu5jzss7yvjejU83bCa7ghdLzki89Eusz67Xdj+1uKk5 z4FpyWzgF0ZZvhTbwjI7CnQUfa+gouf2nDng1f8Y57n5MfQ4k2/cDd/QTZn5M14mKo+N sx1A== MIME-Version: 1.0 Received: by 10.50.237.72 with SMTP id va8mr5322312igc.17.1343829141700; Wed, 01 Aug 2012 06:52:21 -0700 (PDT) Received: by 10.50.34.169 with HTTP; Wed, 1 Aug 2012 06:52:21 -0700 (PDT) In-Reply-To: <50187B55.407@riw.us> References: <50187B55.407@riw.us> Date: Wed, 1 Aug 2012 09:52:21 -0400 Message-ID: From: Alia Atlas To: Russ White Content-Type: text/plain; charset=ISO-8859-1 Cc: irs-discuss@ietf.org Subject: Re: [irs-discuss] Thoughts on draft-ward-irs-framework X-BeenThere: irs-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Aug 2012 13:52:27 -0000 Hi Russ, Thanks for the good suggestions and comments. I do agree that an internal representation for the IRS as it interacts with the RIB and learning events is basically as "another routing process" and those are the general semantics to describe. One difference, though, is the idea that different static routes installed by IRS may want to have different preference values. I also think that describing the IRS sub-interface for installing static routes in such a fashion would provide the necessary process id tag for origin in the RIB. If more detail is needed, then that can give a correct path to query. I do think these aspects are more on the internal implementation side than on the data-model or information-model side. As much as they are useful to describe the desired interactions, I think they are good to capture. On use-cases, I would be delighted to have your thoughts on examples written down, even in email to the list. What is in the framework draft is explicitly not the motivating use-cases, but just some instances of what is possible with the described IRS sub-interfaces. If there is sufficient interest in IRS, I think that one of the first focuses needs to be identifying a few (2-4) vertical use-cases with feedback loops (topology, events, measurements up as well as installed state down) that we can use to drive the data-model definitions and desired functionality. Thanks, Alia On Tue, Jul 31, 2012 at 8:41 PM, Russ White wrote: > > This framework is well put together, but I'd like to make a couple of > suggestions/comments/put some ideas forward. > > 1. I think the draft struggles somewhat with describing something that's > already in all routers today because it's attempting to describe an > interface into the RIB that's somehow separate, or stands beside, the > existing interfaces into the RIB. I would gently suggest that describing > this entire idea as an "off board routing process," much like a BGP > process on an existing implementation, might clarify things a bit, and > make the model easier to understand. > > Consider --any given routing process already installs routes into the > routing table, including the concept of preference. BGP routing > processes, specifically, also have import and export capabilities into > various VRFs. All routing processes also have redistribution capabilities. > > What if you modeled this entire thing as two types of "off board routing > processes," one that only imports data from the RIB for northbound > consumption (topology information), and one that interacts with the RIB > like any other routing process would for southbound control as well as > northbound consumption? > > It's going to be much easier to interact with the other routing > protocols on the box without a lot of "special pleading" if IRS is a > process that's peer to BGP, OSPF, IS-IS, et al. Take the instance of > link down notifications --all the implementations I know of process link > downs in the RIB, and the RIB then notifies the routing protocol... If > you're hooking into the RIB locally, then, you need to hook into link > down detection specifically and intentionally. If IRS is a routing > process, the RIB will notify the northbound interface as a matter of > course in processing link down notifications. > > I hope that makes sense, but I'm glad to sit and discuss if it doesn't. > > 2. There needs to be a way to mark routes inserted in the RIB with a > process ID of some sort. This would come naturally if the entire IRS > idea were to put an "off board routing process" on the box that > interacts with existing on board processes (see #1 above), but as the > draft stands, there's no way to insert a process id into the RIB. This > is crucial for redistribution, and I suspect redistribution is going to > be a huge problem to address in the long term, since the routes injected > by IRS, however they're injected, will need to interact with the dynamic > protocols running on the box. > > 3. There are a ton of other possible use cases, if more are > needed/wanted to support the reasoning behind the draft. Choosing the > optimal exit from any given edge (OER in cisco lingo), a superset of > Flowspec to combat DDoS is another (mentioned tangentially, but not as a > use case), live/live is another (packet replication and choosing the > best of two identical streams) --and there are others... Some of these > might actually be more interesting use cases than are currently > described in the draft. > > More if I get the chance to reread it in a little more depth later. > > HTH > > Russ > > -- > <>< > riwhite@verisign.com > russw@riw.us > _______________________________________________ > irs-discuss mailing list > irs-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/irs-discuss
On Thu, Aug 30, 2012 at 4:16 PM, Dutta, Pranjal K (Pra= njal) <pranjal.dutta@alcatel-lucent.com> wrot= e:

That doesn=92t talk about cen= tralized SPF, does it ?

=A0

=A0

http://t= ools.ietf.org/html/draft-ietf-pce-stateful-pce-01<= /font>

On Thu, Aug 30, 2012 at 4:09 PM, Dutta, Pranjal K (Pranjal) <pranjal.dutta@alcatel-lucent.com> wrote:

=91operational model=92 =3D I= ETF draft that describes the use case.

=91large=92 =3D 40K LSAs, 500= IGP nodes.

=A0

From: Edward Cra= bbe [mailto:edc@google.= com]
Sent: Thursday, August 30, 2= 012 2:44 PM


To: Dutta, Pranjal K (Pranjal)

Cc:<= font face=3D"Tahoma"> Alia Atlas; UTTARO= , JAMES; Shah, Himanshu; irs-discuss@ietf.org


Subject: Re: [irs-discuss] I= RS comments

=A0

please define 'operational model' ( and 'large' :) . =A0

On Thu, Aug 30, 2012 at 1:40 PM, Dutta, Pranjal K (Pranjal) <pranjal.dutta@alcatel-lucent.com> wrote:

Hi,

=A0=A0=A0=A0=A0=A0=A0=A0 I be= lieve that=92s 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 convergenc= e of large number of flows efficiently.

=A0

Thanks,<= u>

Pranjal<= u>

=A0

From: Edward Cra= bbe [mailto:edc@google.= com]
Sent: Thursday, August 30, 2= 012 11:59 AM
To: Alia Atlas
Cc: Dutta, Pranjal K (Pranjal); UTTARO, JAMES; Shah, Himanshu; irs-discuss@ietf.org


Subject: Re: [irs-discuss] I= RS comments

=A0

Alia;

=A0

If there is=A0

=A0

a) a mechanism for installing routes, pbr or otherwise, which recurse to directly connected nexthops

b) a mechanism for gathering topological information

=A0

then you've inherently enabled centralized spf.=A0

=A0

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. =A0Clearly 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 comp= utation
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)
<p= ranjal.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 g= et 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") whenev= er there is a change. The application would compute SPF on behalf of each rout= er (LSDB). The result of the compute would be pushed by application to each Ro= uter (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 ser= ver 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 ar= e high. This leads to higher time lag on inconsistency between application SP= F compute and FIB update. It's almost like the classic "slow peering= " issues with TCP like protocols - the high performance peer is slowed down b= y low performance peer.
>
> Static route interface is good thing because it is a state that persis= ts longer.
>
> IGPs may be deployed in very dynamic environments where tight coupling= is desirable between SPF compute and FIB update. In scaled environments the is= sue 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

=A0

=A0

=A0