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

["Joel M. Halpern" <[e-mail]>]

Thanks Sue.  Just to confirm, I agree that there is no need to change 
the requirement.
Yours,
Joel

On 7/28/16 7:10 PM, Susan Hares wrote:
> Joel:
>
> You are 100% on the following points.
>
> 1) The requirements do not mandate re-evaluation after a client's priority
> changes.
> 2) The requirements do not made storing the client-ID indirectly.
> 3) Requirements permit re-evaluation of local config with relative priority,
> but do not
>
> Yasuhiro pointed out what would happen if there was no re-evaluation.
> Implementations may - as I did,  chose to re-evaluate priority compared to
> the local configure.
>
> I believe that implementation experience will provide us with insights on
> scaling.   I am providing initial coding structures, but I have not run the
> code with 5K, 10K or 100K results to see what happens.  As an implementer, I
> am just providing information.
>
> As WG Chair, I am not recommending we change the requirements.   We had a
> lengthy discussion that came to this conclusion.   I am allowing over the
> weekend in case someone wants to comment before we do the final 1 week WG LC
> for changed text.
>
> Sue Hares
> -----Original Message-----
> From: i2rs [mailto:[e-mail]] On Behalf Of Joel M. Halpern
> Sent: Thursday, July 28, 2016 6:40 PM
> To: Susan Hares; 'Yasuhiro Ohara'; [e-mail]
> Cc: [e-mail]; [e-mail]; [e-mail]; [e-mail]
> Subject: Re: [i2rs] Comments on Ephemeral-REQ-07 (local config vs.
> ephemeral)
>
> As a minor point, and assuming I have understood the quesiton, I do not
> believe the requirements mandate re-evaluation.
>
> As far as I can tell, we have specified that the priority is that in use at
> the time of application of the I2RS request.
> And we have permitted the priority to be stored as anb indirect through the
> client ID, but we have not required that.
>
> Thus, an implementation which chooses to use the indirection may shift the
> priority associated with an operation.
>
> It seems to me that this permits reevaluation of relative priority compared
> with local config.  But does not require it.
> And that is the only re-evaluation that is permitted, as there is nothing
> else to compare with.
>
> Yours,
> Joel
>
> On 7/28/16 4:52 PM, Susan Hares wrote:
>> Yasuhiro:
>>
>> <developer hat on>
>> In my developer hat, I agree with you and Andy.
>>
>> As an Implementer I have created a mechanism that will easily
>> re-evaluate queue a re-evaluation of all routes which client priority
> changes.
>>
>> Here's the back structure:
>>
>> Per connection :
>>
>>   Session-id - pointer to structure which has
>> 	1) customer pointer --> customer-id, priority, opaque id
>>            (this is part of a list of clients ordered by customer id,
>> followed by priority)
>>              2) transport pointer ---> transport ID (src
>> IP/src-port/dst
>> IP/dst-port)
>>              3) last rcv action  info -->  seq #, function
> (read/write/rpc)
>> 	4) last response  info --> (read rsp, write rsp, rpc response,
>>               5) notification- seq #, function,
>>
>> Client 1 could have:
>>      Client-1, 5, xyz
>>  And have a priority change (due to AAA) to
>>      Client-1, 3, zzz
>>
>> My client  table would have
>>           Pointer 1 - Local config, 5, null
>>           Pointer 2 - client-1, 8, xyz
>>           Pointer 3 - client-1, 3, zzz
>>           Pointer 4 - client 3, 6,  bbb'
>>
>> My transport table
>>
>>
>> My session ID table would have
>>    Entry 1: Customer pointer - pointer 1
>>                  Transport-pointer - null
>>                   Last action info - null
>>                   Last response info -   null
>>                   Last notification -     null
>>
>>    Entry 2:  Customer pointer - pointer 2
>>                    Transport pointer - transport-pointer-1
>>                    Last receive action info - 5, write
>>                    Last response info - 5, write-rsp
>>                    Last notification -   1, notify-rpc
>>
>>    Entry 3:  Customer pointer - pointer 3
>>                    Transport pointer - transport-pointer-1
>>                    Last action info - 6, write
>>                    Last response info -  6 write-response
>>                    Last notification -   3, notify write
>>
>>    Entry 4:  Customer pointer - pointer 4
>>                    Transport pointer - transport-pointer-2
>>                    Last receive action info - null
>>                    Last response - null
>>                    Last notify - null
>>
>>
>> Each route has:
>>    Route (A)
>>         ---> session-id pointer
>>         --->  rt_rtc - route change structure
>>                  ---> which has pointer to session ID of client
>> requesting change.
>>
>> If the session-id changes because the customer-id changes, then a
>> background process walks the route  list comparing customer-pointer,
>> and new customer-pointer.  If it find a new customer pointer, then it
>> places a rt_rtc request structure into the route, and links the route to a
>> change structure.   If we have  10,000 routes associated with a client,
>> then the background process changes the  routes in groups - until all
>> routes on are processed.
>>
>> [A million routes could be handled by the I2RS route updates, but the
>> processing time would exceed the time for a simple BGP -  so I think
>> this is not the target for I2RS].
>>
>> While this background process is running, if a new route write (rpc or
>> write) for a specific route comes - then the route processes the
>> comparison with client route.
>> The rt_rtc change structure would record two changes:
>>  a) the initial routes change to new priority
>>  b) the new routes change via a client-3 for route-id with a higher
>> priority,
>>      then the new route change takes precedence.
>>
>> The I2RS agent, can respond to the I2RS client-3 that the write succeeds.
>> 1) To Entry 4 would add a write sequence #1, response #1] ,
>> 2) to Entry 2 Notify (sequence #4) to client-1 that its write has been
>> overwritten by a higher priority client
>>
>> I agree that if you do not re-process the routes associated with an
>> I2RS client, the priority values are out of sync and some comparison
>> fail that should have succeeded.
>>
>> I disagree with the WG decision to not process priority changes to
>> individual routes.  If people wanted to indicate that the processing
>> of the priority change did not  need to be immediately, I think the
> background
>> process works.   If this is what the WG meant, then I think this is
>> reasonable.
>>
>> One thing the text says, is that ephemeral routes are compared with a
>> priority, and then ephemeral is compared against Local Configuration.
> Your
>> assignment illustrates the point, so I did not correct it.
>>
>> <developer hat off>
>>
>> <WG chair hat on>
>> The WG had a long discussion, and came to agreement on not processing
>> past routes.
>> However, I am raising the issue for until 8/1/2016 when I will start a
>> 1 week WG LC on the changes put in ephemeral state.
>> Russ White will judge this WG LC since I am a co-author on the
>> ephemeral state draft.
>> <WG hat off>
>>
>> Sue
>> -----Original Message-----
>> From: i2rs [mailto:[e-mail]] On Behalf Of Yasuhiro Ohara
>> Sent: Wednesday, July 20, 2016 7:12 AM
>> To: [e-mail]
>> Cc: [e-mail]; [e-mail]; [e-mail];
>> [e-mail]; [e-mail]
>> Subject: 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.
>> [Sue: I agree with this point.  My solution processes the priority
>> change. ]
>>
>> 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.
>> [Sue: I agree with  you.]
>>
>> 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
>>
>> [Sue: I have listed created a list of clients.  See my methodology
>> above. ]
>>
>> Then all the client have to do to change his priority is to let the
>> agent know that the change of priority 8->3.
>>
>> [Sue: You have to know which routes are associated with the client.
>> If the client changes the priority, then you have to re-evaluate it.
>> If you are gathering a set of changes per route from multiple clients
>> or from multiple writes, then the route changes structure could be
>> useful.
>>
>> 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.
>> [Sue: Here, we never assumed that the client would send the different
>> priority.  We assumed this priority came from AAA changing the priority.
>> Therefore, the real challenge is the processing of the change in
>> priority per route. ]
>>
>> I may be missing the context totally... sorry in the case.
>> [Sue:  90% correct, the only thing not aligned with my answer is the
>> client ID priority is changed by AAA (radius, diameter or some other AAA
> process).
>>
>> Best regards,
>> Yasu
>>
>> Thank you for the question.
>>
>> From: Andy Bierman <[e-mail]>
>> 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=[e-mail]>
>>
>>> 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 XperiaT 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
>>>>
>>
>> _______________________________________________
>> i2rs mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/i2rs
>>
>> _______________________________________________
>> i2rs mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/i2rs
>>
>
> _______________________________________________
> i2rs mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/i2rs
>
> _______________________________________________
> i2rs mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/i2rs
>