Re: [irs-discuss] IRS comments

"Dutta, Pranjal K (Pranjal)" <pranjal.dutta@alcatel-lucent.com> Thu, 16 August 2012 04:30 UTC

Return-Path: <pranjal.dutta@alcatel-lucent.com>
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 <irs-discuss@ietfa.amsl.com>; 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 <irs-discuss@ietfa.amsl.com>; 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 <irs-discuss@ietf.org>; 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)" <pranjal.dutta@alcatel-lucent.com>
To: "Shah, Himanshu" <hshah@ciena.com>, "UTTARO, JAMES" <ju1738@att.com>, Alia Atlas <akatlas@gmail.com>
Date: Thu, 16 Aug 2012 10:00:19 +0530
Thread-Topic: [irs-discuss] IRS comments
Thread-Index: Ac15UPmWZFj3YBmsT9Smjrge48ksHAATypTAAFoVXoAAAUAUgAABZOIAAAKyOQAAAEVwAAADS7QAAAAO5wAAADV/gAAByQUAAAfLkAAAAdXVgAAGmN5wAAiugSAADB62sA==
Message-ID: <C584046466ED224CA92C1BC3313B963E09F22C5413@INBANSXCHMBSA3.in.alcatel-lucent.com>
References: <812700A304640D4292205D5E83FC59E1061C211D@p-embx01-eq.jnpr.net> <CAG=JvvjYk_E6+Qdidyyjc5oDss9HeA2aq2pt5ciQeX06fuiWsQ@mail.gmail.com> <CAG4d1reLL2_4KRb6yseJK9WTB47YzumMBGdu+UwcOWXxmE0M8Q@mail.gmail.com> <CAG=JvvjVhGsVcSzEFxDKKfNckQxgQiWeezWvwpcoAOSgOP--Nw@mail.gmail.com> <CAG4d1rd_p6x_+PsHWtsYU=oOCT-GnmnZNL+MHcJf4NEG5boP7A@mail.gmail.com> <B37E6A2CE5957F4E83C1D9845A0FFE38014A33BC4A@MDWEXGMB02.ciena.com> <CAG4d1reWGjUU-z=9Gx_MvetAWF6wM8oUMpQRc9hxOg1MU37X_w@mail.gmail.com> <A3C4E51A53661B4EBEE7C5F5E6FCDEB5025AB94FE6D2@USEXCHANGE.corp.extremenetworks.com> <CAG4d1rfD8_0WgzRqH-OVAxfn1RYNfY_ynwkcmqN3MBYyrn5TnQ@mail.gmail.com> <3512BB31280C39448A9880F61DD54CEB09C07E@xmb-aln-x09.cisco.com> <CAG4d1rcvk1RmRmrpCwiAGx9s0v3X9aPECdeF1Wz7WSuYwzdFKA@mail.gmail.com> <CACKN6JH8eiYty3QOZ+E5Nt0wO3nYn87yB3pKixJK-3dnaOXfLQ@mail.gmail.com> <CACKN6JFMZqOnHU=vEkx8WxwSLjg5MYY=-VoJ7uOt8SAzvbAT6Q@mail.gmail.com> <A3C4E51A53661B4EBEE7C5F5E6FCDEB5025AB94FE847@USEXCHANGE.corp.extremenetworks.com> <B37E6A2CE5957F4E83C1D9845A0FFE38014A33C0A0@MDWEXGMB02.ciena.com> <CAG4d1rehfWk-HX27eysze8zdDzjNk4h4wwj2zV6_WJWxoNxY8Q@mail.gmail.com> <B37E6A2CE5957F4E83C1D9845A0FFE38014A33C26F@MDWEXGMB02.ciena.com> <B17A6910EEDD1F45980687268941550FB7B7B6@MISOUT7MSGUSR9I.ITServices.sbc.com> <B37E6A2CE5957F4E83C1D9845A0FFE38014A33C2BD@MDWEXGMB02.ciena.com>
In-Reply-To: <B37E6A2CE5957F4E83C1D9845A0FFE38014A33C2BD@MDWEXGMB02.ciena.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
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" <irs-discuss@ietf.org>
Subject: Re: [irs-discuss] IRS comments
X-BeenThere: irs-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Interface to The Internet Routing System \(IRS\)" <irs-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/irs-discuss>, <mailto:irs-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/irs-discuss>
List-Post: <mailto:irs-discuss@ietf.org>
List-Help: <mailto:irs-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/irs-discuss>, <mailto:irs-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 16 Aug 2012 04:30:32 -0000

I think I may be missing something basic here. If access to both RIB (injecting 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 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 precedence 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 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 <hshah@ciena.com> 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 <edc@google.com> 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 <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 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) <dlake@cisco.com>
> 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 <hshah@ciena.com> 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 <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 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
_______________________________________________
irs-discuss mailing list
irs-discuss@ietf.org
https://www.ietf.org/mailman/listinfo/irs-discuss