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:[email protected]] On Behalf Of Joel M. Halpern
Sent: Thursday, July 28, 2016 6:40 PM
To: Susan Hares; 'Yasuhiro Ohara'; [email protected]
Cc: [email protected]; [email protected]; [email protected]; [email protected]
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:[email protected]] On Behalf Of Yasuhiro Ohara
Sent: Wednesday, July 20, 2016 7:12 AM
To: [email protected]
Cc: [email protected]; [email protected]; [email protected];
[email protected]; [email protected]
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 <[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 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:[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
_______________________________________________
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
