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

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 <andy@yumaworks.com>
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_1Bw915A@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 <jclarke@cisco.com> 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:jclarke@cisco.com]
>>>> Sent: Wednesday, July 20, 2016 3:40 AM
>>>> To: Susan Hares; 'Russ White'; i2rs@ietf.org
>>>> 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:7riw77@gmail.com]
>>>>> Sent: Wednesday, July 20, 2016 2:09 AM
>>>>> To: 'Joe Clarke'; 'Susan Hares'; i2rs@ietf.org
>>>>> 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
>>> i2rs@ietf.org
>>> https://www.ietf.org/mailman/listinfo/i2rs
>>>
>>
>> _______________________________________________
>> i2rs mailing list
>> i2rs@ietf.org
>> https://www.ietf.org/mailman/listinfo/i2rs
>>