I think I tend to agree with Andy. I couldn't read all the draft yet so I may be missing something important, please correct me then.
First, I think we definitely is going to need the re-evaluation of all routes when the client priority changes. (I think this is against the WG's discussion today) Given that the priority of Local-config: 5 and of Client-A: 8, suppose we have: A.B.C.D/M nexthop Y, by Client-A, priority 8 (best) A.B.C.D/M nexthop X, by Local-config, priority 5 then Client-A changed its priority to 3. If we don't re-evaluate: A.B.C.D/M nexthop Y, by Client-A, priority 3 (best) A.B.C.D/M nexthop X, by Local-config, priority 5 which is very odd situation to me. With re-evaluation: A.B.C.D/M nexthop X, by Local-config, priority 5 (best) A.B.C.D/M nexthop Y, by Client-A, priority 3 I think this should be the correct behavior. Similar things happen if we have Client-B with priority 6. I think we should have the list of clients in the agent. Client-A: priority 8 Client-B: priority 6 Then all the client have to do to change his priority is to let the agent know that the change of priority 8->3. That will be way much less from the huge traffic that we would be needed to change when millions of routes are related to the Client-A. I may be missing the context totally... sorry in the case. Best regards, Yasu From: Andy Bierman <[email protected]> Subject: Re: [i2rs] Comments on Ephemeral-REQ-07 (local config vs. ephemeral) Date: Wed, 20 Jul 2016 02:37:51 -0700 Message-ID: <CABCOCHRA1_ZGChup9UT=nampx2gpd88e6mtw8mbxb9_1bw9...@mail.gmail.com> > 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
