Subject: [i2rs] Question on opstate/ephemeral update

From: Joe Clarke <[email-masked]>
Date: Wed, 16 Nov 2016 01:56:26 -0500

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

---

From: "Susan Hares" <[email-masked]>
Date: Wed, 16 Nov 2016 16:10:59 -0500

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:[email-masked]] On Behalf Of Joe Clarke
Sent: Wednesday, November 16, 2016 1:56 AM
To: [email-masked]
Subject: [i2rs] Question on opstate/ephemeral update

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
[email-masked]
https://www.ietf.org/mailman/listinfo/i2rs

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 16 Nov 2016 20:21:28 -0500

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

---

From: "Susan Hares" <[email-masked]>
Date: Wed, 16 Nov 2016 23:21:48 -0500

Joel: 

My description is one 1 way to implement 3.4.   -Resolve the multi-write
conflict via client priorities.   Then install configuration into node using
the data store priorities (config = priority 3, ephemeral = priority 4, dhcp
= priority 2).  

Your way is to assign the priorities so it is a complete scheme.    Common
algebra techniques indicates these are the same.  Let's see what happens
when we implemented both ways. 

Cheers, 

Seu 

-----Original Message-----
From: i2rs [mailto:[email-masked]] On Behalf Of Joel M. Halpern
Sent: Wednesday, November 16, 2016 8:21 PM
To: Susan Hares; 'Joe Clarke'; [email-masked]
Subject: Re: [i2rs] Question on opstate/ephemeral update

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.

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
> Dhcp takes precedence (wins) over intended configuration - so dhcp 
> received configurations are installed.  Ephemeral state wins over dhcp
values.
> that the I2RS agent will handle the resolution of multiple client 
> writes using priorities.
>
> 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?

---

From: Joe Clarke <[email-masked]>
Date: Thu, 17 Nov 2016 21:14:59 -0500

> configurations are installed.  Ephemeral state wins over dhcp values.

This makes sense (as does Joel's description).  In particular, what Joel 
says, "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 [sic]."

My comments were simply to state that in your presentation, the slides 
didn't indicate how priority would work.  Kent came to the mic to say 
that priority resolution would be worked out outside of the <applied> DS 
(indicating to me that the I2RS agent would take the "winning" change 
from two competing clients into <applied>).

I want to make sure we can have the same priority space applied to all 
DS actors.

Joe