Re: [i2rs] Comments on Ephemeral-REQ-07 (local config vs. ephemeral)

["Susan Hares" <[e-mail]>]

Andy: 

 

What we indicated is that because the client-id is linked to only one priority at a time, that the implementation could just keep the client id.   The basic principle is still the comparison of priority ideas.    In the code, you will need to a have a link between the element and the client id/priority. 

 

In my implementation of a I2RS RIB, I create a structure that store client-ID and opaque information (call it store-id (SID)).  

 

Route-entry à SID-#1.  

If SID changes, then you could change all the routes linked to SID.   I agree that one way to handle a change to the priority associated with a clients would be re-evaluate the routes associated with the SID.  The WG’s discussion 9 months ago, was to specify that if client priority changed that the implementation would not be required to process past.  (It could re-evaluate, but it was not required.). 

 

So.. your scenario is correct. 

 

 

Sue 

 

 

From: Andy Bierman [mailto:[e-mail]] 
Sent: Wednesday, July 20, 2016 5:38 AM
To: Joe Clarke
Cc: Robert Wilton -X (rwilton - ENSOFT LIMITED at Cisco); Susan Hares; Russ White; [e-mail]
Subject: Re: [i2rs] Comments on Ephemeral-REQ-07 (local config vs. ephemeral)

 

Hi,

 

the text in REQ-07 does not say anything about client identity,

but Sue's comments in the NETCONF WG meeting indicate

that the client ID is saved, not the priority.

 

This does not seem to work if client priority can change.

If priority is changed, then it seems that all the overlays affected

need to be adjusted so the operational state reflects the new priority.

 

It seems to me that I2RS will require per-node storage of a

client ID and a priority to prevent this re-evaluation.

However, if the operator changes a client-ID priority they probably

want all the nodes re-evaluated.  This applies to ephemeral-only,

not just local config vs. ephemeral.

 

 

Andy

 

 

On Wed, Jul 20, 2016 at 2:18 AM, Joe Clarke <[e-mail]> wrote:

On 7/20/16 05:10, Robert Wilton -X (rwilton - ENSOFT LIMITED at Cisco) wrote:

Hi,

Sorry, but I can't make the I2RS meeting because I'm presenting at the
end of NETCONF.

I've spoken to Sue and understand that the requirement isn't changing
here - just the text to describe it.

I think that I'm OK with this new text.

One suggestion: Possibly It might help if the text made it clear that
the priotiy resolution applies to the complete set of ephemeral config
vs the complete set of local config. I.e. the requirement is not asking
for priority resolution between the two config sets on a per datanode basis.


Yes, I had assumed that in my text, but I agree, this should be clear.
i,

 

Functionally, in my head, I imagine local config to act like an I2RS client.  Clients don't have a per-data node priority.  They have an overall priority.

Is this consistent with what you're stating here?

Joe


But I strongly support getting the requirements draft completed, and
hence I suspect that whatever text that you agree in the 2nd I2RS
meeting will be fine.

Thanks,
Rob


Sent from my Xperia™ tablet

---- Joe Clarke (jclarke) wrote ----

On 7/20/16 03:42, Susan Hares wrote:

Joe:
Yes - you are correct.  Can you help me state this requirement -07 better?


What about:

Ephemeral-REQ-07: Ephemeral configuration and local configuration MUST
each have a priority.  This priority will determine whether ephemeral
configuration or local configuration take precedence.  The I2RS protocol
MUST support this mechanism.

Is this clear and correct enough?

Joe


Sue

-----Original Message-----
From: Joe Clarke [mailto:[e-mail]]
Sent: Wednesday, July 20, 2016 3:40 AM
To: Susan Hares; 'Russ White'; [e-mail]
Subject: Re: [i2rs] Comments on Ephemeral-REQ-07 (local config vs.
ephemeral)

On 7/20/16 02:18, Susan Hares wrote:

<WG hat off> <author hat on>

Here's text that might replace it:

Ephemeral-REQ-07: Ephemeral configuration state MUST be able to set a
priority on local configuration and ephemeral state.  Based on this
priority implementations MUST be able to provide a mechanism to choose
which takes precedence. The I2RS Protocol MUST be able to support this

mechanisms.


Any thoughts?


I'm a bit confused by the first sentence.  I think what you're stating is
that both ephemeral and local configurations MUST have a priority.
This priority will determine whether ephemeral configuration or local
configuration take precedence.  The I2RS protocol MUST support this
mechanism.

Am I correct in my interpretation?

Joe


Sue

-----Original Message-----
From: Russ White [mailto:[e-mail]]
Sent: Wednesday, July 20, 2016 2:09 AM
To: 'Joe Clarke'; 'Susan Hares'; [e-mail]
Subject: RE: [i2rs] Comments on Ephemeral-REQ-07 (local config vs.
ephemeral)


(wg chair hat off) --

I think the idea of extending I2RS priority to local config operators

(e.g., CLI)

will still work.  Let's take knob 1.  Knob 1 is kind of like the
on/off

switch.  If I

don't want I2RS to have any effect on operational state, I'd have
this

off.  In

the I2RS priority case, by default my local config could will have
the

highest

priority (let's say that's 255 to make it concrete).  In this case no

ephemeral

config can win.


I wanted to extend Joe's remarks a bit... On reflection, I actually
think having priority + "this wins" bits is rather confusing, and
opens the door to all sorts of strange behavior. Say I have two items
thus --

Local config item -- priority 100
I2RS config item -- priority 200, don't overwrite bit set

If the higher priority is supposed to win, then which item should the
operator find in the resulting running config? Should it be the I2RS
version, because the priority is higher, or the local config, because
the "don't overwrite" bit is set? There doesn't seem to be any clear
way to interpret such a situation.

It's better to have a single "thing" that determines which
configuration among many wins, rather than two.

-r



 


_______________________________________________
i2rs mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/i2rs


_______________________________________________
i2rs mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/i2rs