Re: [irs-discuss] IRS comments

Alia Atlas <akatlas@gmail.com> Mon, 13 August 2012 12:41 UTC

Return-Path: <akatlas@gmail.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 6E99C21F8705 for <irs-discuss@ietfa.amsl.com>; Mon, 13 Aug 2012 05:41:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.562
X-Spam-Level:
X-Spam-Status: No, score=-3.562 tagged_above=-999 required=5 tests=[AWL=0.037, BAYES_00=-2.599, 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 59hv6E4dbJ1k for <irs-discuss@ietfa.amsl.com>; Mon, 13 Aug 2012 05:41:29 -0700 (PDT)
Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8994021F8702 for <irs-discuss@ietf.org>; Mon, 13 Aug 2012 05:41:29 -0700 (PDT)
Received: by yenm5 with SMTP id m5so3411432yen.31 for <irs-discuss@ietf.org>; Mon, 13 Aug 2012 05:41:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=o3rBvhJ2pCEHGz5bpAgsn9PUnKC6FYv3WkzJs0sk4j8=; b=dG9PTmgo8Su0BvzoGVNLf9Okn38LScDE9ILnQooLxJS048BlAT5Yx/9Wa+aosrQHT2 SkbRNdJ6NKyhd2RFkaSaEJLiChXAdtIj+pCoT8vsgVG67cCbT9dRTCzBGy/wdc8jMBH1 2FLMhQWp2UbBfIX3eCP4mppvBlIFTBGXBpXwLrbD+3KMMdJQmv6+HtduYAgAp/M6geqs hz1a1b/egVeSxnW++REUXiHHwIcY6Kl3ecxlq+neq4WJPGUCZxdMQQfMlsyzH+RqwoMt 5/r/6OD5a1/ItyxJNs6e56IOJH6RipmsZQebedY/CR2Ny0yjJWOE+ky1+ix3DmmaY8Jv jH/g==
MIME-Version: 1.0
Received: by 10.50.183.200 with SMTP id eo8mr5253072igc.63.1344861688822; Mon, 13 Aug 2012 05:41:28 -0700 (PDT)
Received: by 10.50.91.135 with HTTP; Mon, 13 Aug 2012 05:41:28 -0700 (PDT)
In-Reply-To: <CAG=JvvjVhGsVcSzEFxDKKfNckQxgQiWeezWvwpcoAOSgOP--Nw@mail.gmail.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>
Date: Mon, 13 Aug 2012 08:41:28 -0400
Message-ID: <CAG4d1rd_p6x_+PsHWtsYU=oOCT-GnmnZNL+MHcJf4NEG5boP7A@mail.gmail.com>
From: Alia Atlas <akatlas@gmail.com>
To: Scott Whyte <swhyte@google.com>
Content-Type: text/plain; charset="ISO-8859-1"
Cc: Thomas Nadeau <tnadeau@juniper.net>, Gert Grammel <ggrammel@juniper.net>, Alia Atlas <akatlas@juniper.net>, Lenny Giuliano <lenny@juniper.net>, 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: Mon, 13 Aug 2012 12:41:30 -0000

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