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:[email protected]] Sent: Wednesday, July 20, 2016 5:38 AM To: Joe Clarke Cc: Robert Wilton -X (rwilton - ENSOFT LIMITED at Cisco); Susan Hares; Russ White; [email protected] 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 <[email protected]> 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:[email protected]] Sent: Wednesday, July 20, 2016 3:40 AM To: Susan Hares; 'Russ White'; [email protected] 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:[email protected]] Sent: Wednesday, July 20, 2016 2:09 AM To: 'Joe Clarke'; 'Susan Hares'; [email protected] 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 [email protected] https://www.ietf.org/mailman/listinfo/i2rs _______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
_______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
