Re: [irs-discuss] Rough Draft IRS Charter

Thomas Nadeau <tnadeau@lucidvision.com> Sun, 04 November 2012 18:53 UTC

Return-Path: <tnadeau@lucidvision.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 3ED2721F8473 for <irs-discuss@ietfa.amsl.com>; Sun, 4 Nov 2012 10:53:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.203
X-Spam-Level:
X-Spam-Status: No, score=-1.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id do7Qvnvel5vN for <irs-discuss@ietfa.amsl.com>; Sun, 4 Nov 2012 10:53:19 -0800 (PST)
Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id 8824C21F846D for <irs-discuss@ietf.org>; Sun, 4 Nov 2012 10:53:19 -0800 (PST)
Received: from [10.79.162.178] (mobile-198-228-204-137.mycingular.net [198.228.204.137]) by lucidvision.com (Postfix) with ESMTP id DA67E230C628; Sun, 4 Nov 2012 13:53:17 -0500 (EST)
References: <DF7F294AF4153D498141CBEFADB17704C7EC9FE484@EMBX01-WF.jnpr.net> <5085874F.1090806@riw.us> <62CCD4C52ACDAD4481149BD5D8A72FD30251A9F9@CH1PRD0510MB355.namprd05.prod.outlook.com>
Mime-Version: 1.0 (1.0)
In-Reply-To: <62CCD4C52ACDAD4481149BD5D8A72FD30251A9F9@CH1PRD0510MB355.namprd05.prod.outlook.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Message-Id: <BA7E86E9-93DA-4647-80EE-1347B53C3F31@lucidvision.com>
X-Mailer: iPhone Mail (10A523)
From: Thomas Nadeau <tnadeau@lucidvision.com>
Date: Sun, 4 Nov 2012 13:53:13 -0500
To: Ross Callon <rcallon@juniper.net>
Cc: Russ White <russw@riw.us>, "irs-discuss@ietf.org" <irs-discuss@ietf.org>
Subject: Re: [irs-discuss] Rough Draft IRS Charter
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: Sun, 04 Nov 2012 18:53:20 -0000

On Nov 4, 2012, at 1:40 PM, Ross Callon <rcallon@juniper.net> wrote:

> Speaking only for myself as an individual: 
> 
> I agree that this paragraph of the draft WG charter is a problem. For one thing the definition of "Slow Path" and "Fast Path" are not clear, and overlap with implementation issues as well as other issues. 
> 
> One option would be to just drop this paragraph. To me the charter hangs together fine without it. 

I personally do not find it offensive, but if it clears things up, let's loose it.

> 
> One alternative: Do we want to say something along the lines of "whatever solutions are selected by the WG will not preclude "fast path" low-overhead access to the routing system"? This would encourage the WG to think about what is needed to allow low-overhead access to data in the routers (both setting and reading), but would not in the charter specify what actually needs to be done to allow this. 

I don't like the language of "will not preclude".  it's a bit of a double negative to me. something like "will seek to reuse or develop a protocol that achieves the requirements of low-overhead, etc...  seems more flexible and precise to me at the same time.

Tom 

> 
> Ross
> 
> -----Original Message-----
> From: irs-discuss-bounces@ietf.org [mailto:irs-discuss-bounces@ietf.org] On Behalf Of Russ White
> Sent: Monday, October 22, 2012 1:50 PM
> To: irs-discuss@ietf.org
> Subject: Re: [irs-discuss] Rough Draft IRS Charter
> 
> 
> I think this has already been brought up on the list once before, but
> I'd just like to repeat my concerns on it:
> 
> ==
> Thus, the IRS is a "fast path" that can be used to program routing and
> policy state in a router using operational paradigms familiar to
> operators of traditional distributed devices. This differs from the
> programmatic "slow state" that is commonly a device's configuration
> interface because those mechanisms impose many transactional mechanisms
> and requirements, that may slow down the interaction.
> ==
> 
> Describing the CLI or other existing interfaces as the "slow path," and
> the proposed as the "fast path," is problematic. First, it implies that
> there is a specific path already available into all control plane
> devices, and that single path is "too slow," for some meaning of "too
> slow." Second, it implies, from the start, that we need new path, rather
> than a possible structure around existing paths that we can use to make
> sense of the routing system as a whole.
> 
> I think 2a needs to be better defined so it doesn't overlap with 2c, or
> 2c needs to be made a part of 2a in some way (?).
> 
> Thanks!
> 
> Russ
> 
> 
> 
> -- 
> <><
> riwhite@verisign.com
> russw@riw.us
> _______________________________________________
> 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
>