Re: [i2rs] Question on opstate/ephemeral update

"Joel M. Halpern" <jmh@joelhalpern.com> Thu, 17 November 2016 01:21 UTC

Return-Path: <jmh@joelhalpern.com>
X-Original-To: i2rs@ietfa.amsl.com
Delivered-To: i2rs@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB6E11295E8 for <i2rs@ietfa.amsl.com>; Wed, 16 Nov 2016 17:21:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.702
X-Spam-Level:
X-Spam-Status: No, score=-2.702 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e6xCurkoTuNk for <i2rs@ietfa.amsl.com>; Wed, 16 Nov 2016 17:21:23 -0800 (PST)
Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9DCD51295D8 for <i2rs@ietf.org>; Wed, 16 Nov 2016 17:21:23 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 8EFBB240F47; Wed, 16 Nov 2016 17:21:23 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=1.tigertech; t=1479345683; bh=kyizf5/kW8D00IGG3bi8e9UgqQ1qb1wPcoYRuTPRYUY=; h=Subject:To:References:From:Date:In-Reply-To:From; b=Fzs0cKn50/ezl8Vpt9zNAq2pxLIifVPanMB6Ce/claLjPYorpfK4DPsS7haa2kP23 rvX1e22p2on2MkvenivKITeUNjzqNgFvglqwQjT+fvDXLi/S8IsR+nqAoRkXJvg3x9 j+AhNGZHLS1+lbDvvmyF8q/abIGLg1pr+FkS3B6k=
X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net
Received: from dhcp-93c0.meeting.ietf.org (dhcp-93c0.meeting.ietf.org [31.133.147.192]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id BEA75240C78; Wed, 16 Nov 2016 17:21:22 -0800 (PST)
To: Susan Hares <shares@ndzh.com>, 'Joe Clarke' <jclarke@cisco.com>, i2rs@ietf.org
References: <8419df8b-4861-edb7-0a66-c2c123148727@cisco.com> <015201d2404d$ef173260$cd459720$@ndzh.com>
From: "Joel M. Halpern" <jmh@joelhalpern.com>
Message-ID: <d17fc9d5-3f94-a50c-817b-a1abeb30b094@joelhalpern.com>
Date: Wed, 16 Nov 2016 20:21:28 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:45.0) Gecko/20100101 Thunderbird/45.4.0
MIME-Version: 1.0
In-Reply-To: <015201d2404d$ef173260$cd459720$@ndzh.com>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/i2rs/mRhDoVx2cwmHpzwgAo1UUK8AIjQ>
Subject: Re: [i2rs] Question on opstate/ephemeral update
X-BeenThere: i2rs@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "Interface to The Internet Routing System \(IRS\)" <i2rs.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/i2rs>, <mailto:i2rs-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/i2rs/>
List-Post: <mailto:i2rs@ietf.org>
List-Help: <mailto:i2rs-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/i2rs>, <mailto:i2rs-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 17 Nov 2016 01:21:25 -0000

My read of the ephemeral state requirements in this regard (3.4) was 
that we are simply assigning Intended Conifg and the specific other 
cynamic control protocols priorities in the same space we are using for 
deciding between I2RS clients in the case of conflict.

So if I2RS Clients have priorities ranging from min+2 to Max-2, then 
assuming higher is better, to get the result in your first example, one 
would set intended to min-1 and dhcp to min-2.
And the reverse for your second example.

As an operator, one could assign ones clients priorities in various 
ranges, and arrange the dhcp and intended config priorities at other 
points to get more complex results.
And of course, one could set dhcp to max+1 and intended config to max+2 
to max I2RS yield to all the others, and intended config take precedence 
over everything.

Yours,
Joel

On 11/16/16 4:10 PM, Susan Hares wrote:
> Joe:
>
> I've updated the examples in the yang document.  Here's my understanding
> with priorities (see ephemeral state requirements) with highest priority
> winning.
>
> Set
> Intended configuration priority = 2
> Dhcp configuration priority = 1
> Ephemeral state = 3
>
> Dhcp - would never update things, and I2RS would win over intended
> configuration.
>
> Set
> Intended configuration priority = 1
> Dhcp configuration priority = 2
> Ephemeral state = 3
>
> Dhcp takes precedence (wins) over intended configuration - so dhcp received
> configurations are installed.  Ephemeral state wins over dhcp values.
>
> Does this make sense?
>
> Sue
>
> -----Original Message-----
> From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Joe Clarke
> Sent: Wednesday, November 16, 2016 1:56 AM
> To: i2rs@ietf.org
> Subject: [i2rs] Question on opstate/ephemeral update
>
> Given the tight timing of the meeting, I don't want to derail things.
> If we have time, I'll raise this at the mic.
>
> But I do have a question on slide 2 of
> https://www.ietf.org/proceedings/97/slides/slides-97-i2rs-i2rs-opstate-and-e
> phemeral-00.pdf
> .  I see DHCP along side the [I2RS] control plane DSes.  I understand that
> the I2RS agent will handle the resolution of multiple client writes using
> priorities.
>
> But how does that play with DHCP or local config?  In our ephemeral
> requirements draft we say that local config (<intended> in this drawing)
> would have a priority.  And that in the <applied> state the device would
> have to resolve the local priorities with the "winning" config from the I2RS
> agent.  But then DHCP writes a route.  How will that be handled?
>
> I would like some clarity with respect to our priority requirements in the
> ephemeral state draft.
>
> Joe
>
> _______________________________________________
> i2rs mailing list
> i2rs@ietf.org
> https://www.ietf.org/mailman/listinfo/i2rs
>
> _______________________________________________
> i2rs mailing list
> i2rs@ietf.org
> https://www.ietf.org/mailman/listinfo/i2rs
>