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_--