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