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

From: Joe Clarke <[email-masked]>
Date: Mon, 18 Jul 2016 10:07:47 -0400

As I stated at the mic today, I think the way REQ-07 is written is a bit 
broad.  This was evidently the intent, but I have a proposal.

Can we not treat "local config" (e.g., CLI changes) as an I2RS client 
with its own I2RS priority?  If all players (I2RS and local config) play 
with the same priority concept, then one can easily control what gets 
precedence.

For example, if I want to temporarily overlay ephemeral-provided changes 
with local config, I could increase the local config priority.  When I'm 
done with that, I set the priority back.  By default, the local config 
priority would be the lowest value to allow for ephemeral changes to 
take precedence.

I do not think this will have a negative impact on topology as I have 
read it, but if this doesn't make sense in some use cases, the priority 
could be ignored.

Hopefully I've described this well so that it makes sense.

Joe

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 18 Jul 2016 17:31:33 +0200

On Mon, Jul 18, 2016 at 10:07:47AM -0400, Joe Clarke wrote:
> 
> Can we not treat "local config" (e.g., CLI changes) as an I2RS client with
> its own I2RS priority?  If all players (I2RS and local config) play with the
> same priority concept, then one can easily control what gets precedence.
>

I think NETCONF implementations often link the CLI to the <running>
datastore (as long as we are talking about "local eventually persistent
 config").

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: "Susan Hares" <[email-masked]>
Date: Mon, 18 Jul 2016 13:39:49 -0400

Joe: 

We discussed  "treating "local config" (e.g., CLI changes) as an I2RS client
with its own I2RS priority" in order so that priority concept can resolve
conflict.  REQ-07 is a bit broader because we tagged this to the two "Knobs"
that section 6.3.1 described.  (see below) in the IETF architecture
document.   If you think the priority concept can provide the support for
the two switches and use case below, could you describe it on the list. 

Your point is the last remaining point. 

Sue 
===============================

Section 6.3.1
=============
   The policy settings in the architecture is: 

Knob 1: Ephemeral configuration overwrites Local Configuration.
Knob 2: Update of Local Configuration value supersedes and
      overwrites the ephemeral configuration.

                           Existence                              Updates
                          Policy Knob 1                       Policy Knob 2
Situation 
                       ===================     ==================
   Router A     ephemeral has                     ephemeral  has
Ephemeral  is active 
                         priority                                 priority .

   Router B    Local Configuration            Local Configuration
Ephemeral is recorded in Agent,  
                       has priority                           has priority
but not used.  Can be turned on by 
	
turning knob 1 to "ephemeral has priority". 

   Router C    ephemeral has priority      Local Configuration
Nightly configuration overwrite 
 
Ephemeral.          

-----Original Message-----
From: i2rs [mailto:[email-masked]] On Behalf Of Joe Clarke
Sent: Monday, July 18, 2016 10:08 AM
To: [email-masked]
Subject: [i2rs] Comments on Ephemeral-REQ-07 (local config vs. ephemeral)

For example, if I want to temporarily overlay ephemeral-provided changes
with local config, I could increase the local config priority.  When I'm
done with that, I set the priority back.  By default, the local config
priority would be the lowest value to allow for ephemeral changes to take
precedence.

I do not think this will have a negative impact on topology as I have read
it, but if this doesn't make sense in some use cases, the priority could be
ignored.

Joe

_______________________________________________
i2rs mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/i2rs

---

From: Joe Clarke <[email-masked]>
Date: Mon, 18 Jul 2016 17:57:38 -0400

> the two switches and use case below, could you describe it on the list.

The architecture uses the term "overwrite," but I think at least in some 
cases we mean, "overlay."  Anyway, I'll explain using the architecture 
terms.

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.

When I turn I2RS "on", the priority of local config drops to the lowest 
priority (let's say 1, again to be concrete).

Okay, that's knob 1.

Now in the case of knob 2, I want to allow local config to win 
sometimes.  In the example in the architecture, I may want to overwrite 
ephemeral config every night at 11 pm.  In this case, I can increase the 
priority of local config to be higher than the last ephemeral I2RS 
client write, thus overwriting that change.

Again, this allows local config to behave like an I2RS client respective 
to the priority.

Joe

---

From: "Russ White" <[email-masked]>
Date: Wed, 20 Jul 2016 02:09:08 -0400

(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

---

From: "Susan Hares" <[email-masked]>
Date: Wed, 20 Jul 2016 02:18:38 -0400

<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? 

Sue 

-----Original Message-----
From: Russ White [mailto:[email-masked]] 
Sent: Wednesday, July 20, 2016 2:09 AM
To: 'Joe Clarke'; 'Susan Hares'; [email-masked]
Subject: RE: [i2rs] Comments on Ephemeral-REQ-07 (local config vs.
ephemeral)

(wg chair hat off) --

(e.g., CLI)
switch.  If I
off.  In
highest
ephemeral

-r

---

From: "Russ White" <[email-masked]>
Date: Wed, 20 Jul 2016 02:25:38 -0400

> implementations MUST be able to provide a mechanism to choose which
> takes precedence. The I2RS Protocol MUST be able to support this
> mechanisms.

This is good -- thanks Sue.

:-)

Russ

---

From: Joe Clarke <[email-masked]>
Date: Wed, 20 Jul 2016 03:40:17 -0400

> precedence. The I2RS Protocol MUST be able to support this mechanisms.

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

---

From: "Susan Hares" <[email-masked]>
Date: Wed, 20 Jul 2016 03:42:02 -0400

Joe: 
Yes - you are correct.  Can you help me state this requirement -07 better? 

Sue 

-----Original Message-----
From: Joe Clarke [mailto:[email-masked]] 
Sent: Wednesday, July 20, 2016 3:40 AM
To: Susan Hares; 'Russ White'; [email-masked]
Subject: Re: [i2rs] Comments on Ephemeral-REQ-07 (local config vs.
ephemeral)

On 7/20/16 02:18, Susan Hares wrote:
> 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.

Joe

> 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 --
>
> 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
>
>

---

From: Joe Clarke <[email-masked]>
Date: Wed, 20 Jul 2016 04:05:25 -0400

> 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

---

From: "Robert Wilton -X (rwilton - ENSOFT LIMITED at Cisco)" <[email-masked]>
Date: Wed, 20 Jul 2016 09:10:16 +0000

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.

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 ----

What about:

Joe

---

From: Joe Clarke <[email-masked]>
Date: Wed, 20 Jul 2016 05:18:22 -0400

On 7/20/16 05:10, Robert Wilton -X (rwilton - ENSOFT LIMITED at Cisco) 
wrote:
> 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.

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
>
>

---

From: Joe Clarke <[email-masked]>
Date: Wed, 20 Jul 2016 05:30:31 -0400

On 7/20/16 05:24, Joel M. Halpern wrote:
> That wording may well lead readers to think that Ephemeral
> configuration, considered as a whole, has a priority.  Since that is not
> true, I would like to further refine this.  How about:
>
> Req-07: Local configuration MUST have a priority that is comparable with
> the I2RS Agent priority for making changes.  This priority will
> determine whether local configuration changes or individual ephemeral
> configuration changes take precedence.  The I2RS protocol MUST support
> his mechanism.

I think you mean I2RS client priority?  But otherwise, I like the text.

Joe

>
> Yours,
> Joel
>
> On 7/20/16 4:05 AM, Joe Clarke wrote:

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 20 Jul 2016 05:24:50 -0400

Yours,
Joel

---

From: Joe Clarke <[email-masked]>
Date: Wed, 20 Jul 2016 05:36:15 -0400

On 7/20/16 05:31, Joel M. Halpern wrote:
> Thanks Joe.  Yes, I meant I2RS CLIENT priority, not agent priority.

Sounds like that is what we're going to kick back to the list (i.e., 
your text s/agent/client/).  Thanks, Joel.

Joe

> Yours,
> Joel
>
> On 7/20/16 5:30 AM, Joe Clarke wrote:

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 20 Jul 2016 05:31:43 -0400

---

From: Andy Bierman <[email-masked]>
Date: Wed, 20 Jul 2016 02:37:51 -0700

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-masked]> wrote:

> i,

> client.  Clients don't have a per-data node priority.  They have an overall
> priority.
>

---

From: "Susan Hares" <[email-masked]>
Date: Wed, 20 Jul 2016 06:49:27 -0400

I'm fine with this revision.  Anyone else wish to change this version? 

Sue 

-----Original Message-----
From: i2rs [mailto:[email-masked]] On Behalf Of Joel M. Halpern
Sent: Wednesday, July 20, 2016 5:25 AM
To: Joe Clarke; Susan Hares; 'Russ White'; [email-masked]
Subject: Re: [i2rs] Comments on Ephemeral-REQ-07 (local config vs.
ephemeral)

That wording may well lead readers to think that Ephemeral configuration,
considered as a whole, has a priority.  Since that is not true, I would like
to further refine this.  How about:

Req-07: Local configuration MUST have a priority that is comparable with the
I2RS Agent priority for making changes.  This priority will determine
whether local configuration changes or individual ephemeral configuration
changes take precedence.  The I2RS protocol MUST support his mechanism.

Yours,
Joel

On 7/20/16 4:05 AM, Joe Clarke wrote:
> configuration or local configuration take precedence.  The I2RS 
> protocol MUST support this mechanism.
>
>>> 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.
>>> opens the door to all sorts of strange behavior. Say I have two 
>>> items thus --
>>>
>>> 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.
>>>

---

From: Yasuhiro Ohara <[email-masked]>
Date: Wed, 20 Jul 2016 13:12:14 +0200 (CEST)

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-masked]>
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=[email-masked]>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 20 Jul 2016 13:19:15 +0200

What is the purpose of the word 'individual' in the sentence? Why does
it talk about 'changes'? Isn't it simply the data that takes
precedence? Or is the idea to have this linked to changes of data,
i.e., how a change was carried out?

I actually find the text related to this in RFC 7921 more helpful
since RFC 7921 provides more insight that priority is associated
with an I2RS client. Perhaps Req-07 should just say:

  Req-07: The I2RS protocol MUST support a priority mechanism to
  resolve any possible conflicts with local configuration as described
  in RFC 7921.

This way we avoid having multiple definitions that may interact in
weird ways. (This might also apply to other requirements where perhaps
a simple pointer to RFC 7921 would be easier and safer than attempts
to reformulate things.)

/js

PS: I do not want to further complicate things so please feel free
    to ignore this.

---

From: "Susan Hares" <[email-masked]>
Date: Wed, 20 Jul 2016 07:27:12 -0400

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-masked]] 
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-masked]
Subject: Re: [i2rs] Comments on Ephemeral-REQ-07 (local config vs. ephemeral)

Hi,

 

Andy

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.

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.

Joe

Thanks,
Rob

---- Joe Clarke (jclarke) wrote ----

Joe:

What about:

Joe

Sue

-----Original Message-----
From: Joe Clarke [mailto:[email-masked]]
Sent: Wednesday, July 20, 2016 3:40 AM
To: Susan Hares; 'Russ White'; [email-masked]
Subject: Re: [i2rs] Comments on Ephemeral-REQ-07 (local config vs.
ephemeral)

mechanisms.

Any thoughts?

Joe

Sue

-----Original Message-----
From: Russ White [mailto:[email-masked]]
Sent: Wednesday, July 20, 2016 2:09 AM
To: 'Joe Clarke'; 'Susan Hares'; [email-masked]
Subject: RE: [i2rs] Comments on Ephemeral-REQ-07 (local config vs.
ephemeral)

(wg chair hat off) --

(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

ephemeral

config can win.

-r

---

From: "Susan Hares" <[email-masked]>
Date: Wed, 20 Jul 2016 07:31:32 -0400

Juergen:

I am open to this version of the text.  However, I will let Joel and Joe
comment on what they'd like to see.   

Sue 

-----Original Message-----
From: Juergen Schoenwaelder [mailto:[email-masked]] 
Sent: Wednesday, July 20, 2016 7:19 AM
To: Susan Hares
Cc: 'Joel M. Halpern'; 'Joe Clarke'; 'Russ White'; [email-masked]
Subject: Re: [i2rs] Comments on Ephemeral-REQ-07 (local config vs.
ephemeral)

What is the purpose of the word 'individual' in the sentence? Why does it
talk about 'changes'? Isn't it simply the data that takes precedence? Or is
the idea to have this linked to changes of data, i.e., how a change was
carried out?

I actually find the text related to this in RFC 7921 more helpful since RFC
7921 provides more insight that priority is associated with an I2RS client.
Perhaps Req-07 should just say:

This way we avoid having multiple definitions that may interact in weird
ways. (This might also apply to other requirements where perhaps a simple
pointer to RFC 7921 would be easier and safer than attempts to reformulate
things.)

/js

On Wed, Jul 20, 2016 at 06:49:27AM -0400, Susan Hares wrote:
> configuration, considered as a whole, has a priority.  Since that is 
> not true, I would like to further refine this.  How about:
> 
> Req-07: Local configuration MUST have a priority that is comparable 
> with the I2RS Agent priority for making changes.  This priority will 
> configuration changes take precedence.  The I2RS protocol MUST support his
mechanism.
> > 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.
> >
> >>> 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?
> >>
> >> This priority will determine whether ephemeral configuration or 
> >> local configuration take precedence.  The I2RS protocol MUST 
> >> support this mechanism.
> >>
> >>> 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 --
> >>>
> >>> 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.
> >>>

---

From: Robert Wilton <[email-masked]>
Date: Thu, 21 Jul 2016 10:47:43 +0200

> Is this consistent with what you're stating here?
It wasn't.  In fact, even after speaking with Sue I was misunderstanding 
the requirement.

I previously thought that the requirement was either:
    "all local config" is higher priority than "all ephemeral config" or 
vice versa.

But I now understand that the requirement is on a per client basis. E.g. 
some clients may override the local config whereas others do not.

Now I understand the actual requirement, the recent text that you posted 
to the I2RS alias looks good to me.

Thanks,
Rob

>>> stating is
> .

---

From: "Susan Hares" <[email-masked]>
Date: Thu, 28 Jul 2016 16:52:02 -0400

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-masked]] On Behalf Of Yasuhiro Ohara
Sent: Wednesday, July 20, 2016 7:12 AM
To: [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked];
[email-masked]

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

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.]

[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-masked]>
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=[email-masked]>

> 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.
> 
> It seems to me that I2RS will require per-node storage of a client ID 
> and a priority to prevent this re-evaluation.
> want all the nodes re-evaluated.  This applies to ephemeral-only, not 
> just local config vs. ephemeral.
> 
> 
> Andy
> 
> 
>>> I've spoken to Sue and understand that the requirement isn't 
>>> changing here - just the text to describe it.
>>>
>>> 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.
>>>
>>
>>> Sent from my XperiaT tablet
>>>
priority.

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 28 Jul 2016 18:39:51 -0400

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

---

From: "Susan Hares" <[email-masked]>
Date: Thu, 28 Jul 2016 19:10:09 -0400

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-masked]] On Behalf Of Joel M. Halpern
Sent: Thursday, July 28, 2016 6:40 PM
To: Susan Hares; 'Yasuhiro Ohara'; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [i2rs] Comments on Ephemeral-REQ-07 (local config vs.
ephemeral)

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:
> As an Implementer I have created a mechanism that will easily 
> re-evaluate queue a re-evaluation of all routes which client priority
changes.
>                  ---> 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 
> then the background process changes the  routes in groups - until all 
> routes on are processed.
>
> processing time would exceed the time for a simple BGP -  so I think 
> this is not the target for I2RS].
>
> write) for a specific route comes - then the route processes the 
> comparison with client route.
> 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.
>
> individual routes.  If people wanted to indicate that the processing 
> of the priority change did not  need to be immediately, I think the
background
> 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
> Cc: [email-masked]; [email-masked]; [email-masked]; 
> [email-masked]; [email-masked]
> I couldn't read all the draft yet so I may be missing something 
> important, please correct me then.
>
> 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
>
> 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.
> 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.
> 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.
> Therefore, the real challenge is the processing of the change in 
> priority per route. ]
>
> [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).
>>>> 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.
>>>>
>>>
>>>> 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
>>>>
>>>>
>>>> ephemeral configuration or local configuration take precedence.  
>>>> The I2RS protocol MUST support this mechanism.
>>>>
>>>>>> mechanism to choose which takes precedence. The I2RS Protocol 
>>>>>> MUST be able to support this
>>>>>>
>>>>> mechanisms.
>>>>>
>>>>>>
>>>>>> Any thoughts?
>>>>>>
>>>>>
>>>>>> Local config item -- priority 100 I2RS config item -- priority 
>>>>>> 200, don't overwrite bit set
>>>>>>

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 28 Jul 2016 19:20:02 -0400

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