Re: [irs-discuss] IRS comments

Alia Atlas <akatlas@gmail.com> Sat, 11 August 2012 00:16 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 7407B21F8497 for <irs-discuss@ietfa.amsl.com>; Fri, 10 Aug 2012 17:16:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.56
X-Spam-Level:
X-Spam-Status: No, score=-3.56 tagged_above=-999 required=5 tests=[AWL=0.039, 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 DHMfJK1rkhgY for <irs-discuss@ietfa.amsl.com>; Fri, 10 Aug 2012 17:16:47 -0700 (PDT)
Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id A2B5021F8496 for <irs-discuss@ietf.org>; Fri, 10 Aug 2012 17:16:47 -0700 (PDT)
Received: by obbwc20 with SMTP id wc20so3419322obb.31 for <irs-discuss@ietf.org>; Fri, 10 Aug 2012 17:16:47 -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=5atY3wOxRR3P1fluIXKjA5FHTzKhVGlKkaACldyIMnE=; b=LytlLg0Z/nHDEabo1yv2JKgBhkEqK9MXepsVR3FIJpNWmpbttCuOWdrjK4aUyKPS9G GMyXq7Pb5kMW4yFwjiGTeuBkNyOgK1tJyosNWT0QnHumYycR+IR6w42FoiiVHcmHRDG9 BGM8tQuB26gmJzK5KK0JlsAR6W3GcnnBa7zr+bUA9wtYGw3n1s0+ofC/e5bJVY/Zuv08 +yWYSyB5SK1TkMbRFQpgMO1eFvCS5j+YbaBGyJHBbDYG981wFd07CpMm8d8RjwvYWW8/ V3ccRitAYgbhxpVd7eRiyp1QM2PhtwXp+z2En6S0AdVLGpRCmWDN8tvm4lGo9yDjy6X7 S20g==
MIME-Version: 1.0
Received: by 10.50.213.106 with SMTP id nr10mr916362igc.58.1344644206845; Fri, 10 Aug 2012 17:16:46 -0700 (PDT)
Received: by 10.50.91.135 with HTTP; Fri, 10 Aug 2012 17:16:46 -0700 (PDT)
In-Reply-To: <CAG=JvvjYk_E6+Qdidyyjc5oDss9HeA2aq2pt5ciQeX06fuiWsQ@mail.gmail.com>
References: <812700A304640D4292205D5E83FC59E1061C211D@p-embx01-eq.jnpr.net> <CAG=JvvjYk_E6+Qdidyyjc5oDss9HeA2aq2pt5ciQeX06fuiWsQ@mail.gmail.com>
Date: Fri, 10 Aug 2012 20:16:46 -0400
Message-ID: <CAG4d1reLL2_4KRb6yseJK9WTB47YzumMBGdu+UwcOWXxmE0M8Q@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: Sat, 11 Aug 2012 00:16:48 -0000

Scott,

In your example, the control plane would mostly move off the device;
it still exists.  Dave Meyer asked if IRS would work to communicate
with routing if it were off the device.  I'd be curious to hear
people's thoughts on that.  My initial take is that IRS's
sub-interfaces should be useful regardless - but we need a good use
case describing that and it would, of course, depend on the
architectural model that moved the routing off the device.

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.

Do you have a particular architectural model that you're thinking of
for having the control plane off the device?  It's something I've
talked with various folks about - but have yet to see anything
convincing written down that addresses most of the issues - from link
verification and MTU to OAM and resiliency and interactions between
off-device control-plane controllers/orchestrators.


Alia

On Fri, Aug 10, 2012 at 7:22 PM, Scott Whyte <swhyte@google.com> wrote:
> On Mon, Jul 30, 2012 at 6:40 PM, Gert Grammel <ggrammel@juniper.net> wrote:
>> Tom,
>>
>> It is confusing to understand whether IRS belongs to a new network management plane or if it's more of a control plane extension. The draft wisely avoids this classification.
>> To me IRS appears to be a completely different beast which should best be  characterized as 'Network Programming Plane' NPP.
>> It neither aims to do full provisioning (as a management plane would do) nor aims to replace routing (as a control plane would do).
>
> Alia's presentation has a diagram with a direct link between the IRS
> Agent and the RIB Manager; thus it does seem to replace routing.
>
>> Hence we better name the baby NPP -- thereby avoiding any linkage to taxation.
>
> If none of my switching nodes speak any kind of legacy control plane
> protocol, yet IRS remains stuffing 500,000 static routes into each
> (thus programming the network), NPP only makes sense to me if it
> subsumes the legacy control plane, not co-exists with it as I
> understand your taxonomy.
>
> -Scott
>
>>
>>
>> Gert
>>
>>
>>
>>
>> ----- Original Message -----
>> From: irs-discuss-bounces@ietf.org <irs-discuss-bounces@ietf.org>
>> To: Lenny Giuliano; Alia Atlas
>> Cc: irs-discuss@ietf.org <irs-discuss@ietf.org>
>> Sent: Tue Jul 31 01:50:40 2012
>> Subject: Re: [irs-discuss] IRS comments
>>
>>
>> [Re-adding IRS]
>>
>>         Thank you for reviewing and the comments. We will incorporate the edits
>> in the next rev.
>>
>>         --Tom
>>
>>
>> On 7/30/12 5:04 PM, "Lenny Giuliano" <lenny@juniper.net> wrote:
>>
>>>
>>>Minor points:
>>>
>>>-section 4, para 2, 3rd sentence, "Howeve,r"
>>>
>>>-4.1.3 "There is no bidirectional programmatic interface to add, modify,
>>>    remove or read state from the multicast RIB."
>>>       -How is this unique to mcast?  Couldn't you say the same thing
>>>       about unicast?
>>>
>>>-4.1.3 "The multicast state added need not match to well-known protocol
>>>    installed state.  For instance, traffic received on an specified set,
>>>    or all, interfaces that is destined to a particular prefix from all
>>>    sources or a particular prefix could be subject to the specified
>>>    replication."
>>>       -Not clear to me at all what this para is saying.
>>>
>>>-"IRS"- you may want to select a different acronym that isn't related to
>>>something as unpopular as taxation (something we learned with AMT).
>>>Maybe
>>>RSI instead...
>>>
>>>Overall, I found the doc to be clearly written and straightforward.
>>>Sounds like Openflow for routers.  Not sure if it's intentional that you
>>>didn't mention Openflow, but it did seem like an elephant in the room as
>>>I
>>>was reading thru.  Also, I did wonder what was new and novel here, as
>>>this
>>>sounded like our SDK which has been around for years.
>>>
>>>
>>>-Lenny
>>
>> _______________________________________________
>> 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
>
>
>
> --
> panem et circenses - a winning strategy for over 2000 years!
> _______________________________________________
> irs-discuss mailing list
> irs-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/irs-discuss