MIME-Version: 1.0
In-Reply-To: <B37E6A2CE5957F4E83C1D9845A0FFE38014A33BC4A@MDWEXGMB02.ciena.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>
Date: Wed, 15 Aug 2012 09:07:39 -0400
Message-ID: <CAG4d1reWGjUU-z=9Gx_MvetAWF6wM8oUMpQRc9hxOg1MU37X_w@mail.gmail.com>
From: Alia Atlas <akatlas@gmail.com>
To: "Shah, Himanshu" <hshah@ciena.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: Gert Grammel <ggrammel@juniper.net>,
 "irs-discuss@ietf.org" <irs-discuss@ietf.org>,
 Lenny Giuliano <lenny@juniper.net>, Thomas Nadeau <tnadeau@juniper.net>,
 Alia Atlas <akatlas@juniper.net>, Scott Whyte <swhyte@google.com>
Subject: Re: [irs-discuss] IRS comments
Precedence: list

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 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 <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 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