Re: [irs-discuss] IRS comments

"David Lake (dlake)" <dlake@cisco.com> Wed, 15 August 2012 17:11 UTC

Return-Path: <dlake@cisco.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 8FA1F21F8794 for <irs-discuss@ietfa.amsl.com>; 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 <irs-discuss@ietfa.amsl.com>; 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 <irs-discuss@ietf.org>; 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)" <dlake@cisco.com>
To: Alia Atlas <akatlas@gmail.com>
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> <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>
In-Reply-To: <CAG4d1rcvk1RmRmrpCwiAGx9s0v3X9aPECdeF1Wz7WSuYwzdFKA@mail.gmail.com>
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 <ostokes@extremenetworks.com>, "irs-discuss@ietf.org" <irs-discuss@ietf.org>
Subject: Re: [irs-discuss] IRS comments
X-BeenThere: irs-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Interface to The Internet Routing System \(IRS\)" <irs-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/irs-discuss>, <mailto:irs-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/irs-discuss>
List-Post: <mailto:irs-discuss@ietf.org>
List-Help: <mailto:irs-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/irs-discuss>, <mailto:irs-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: 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 these 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 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 application providers - what will be key is to ensure that the primitives provided to/from the application are relevant and in terms that an application provider 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 protocol 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] 
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 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