On 7/20/16 07:59, Juergen Schoenwaelder wrote:
The text I comment to says "individual ephemeral configuration
changes" - I was not able to infer from this that it was supposed to
imply "individual I2RS clients".
I agree with both you and Joel. "Individual" should apply to clients,
but we need to have something that ties priority to local config.
What about:
Req-07: Local configuration MUST have a priority that is comparable with
individual I2RS client priorities for making changes. This priority
will determine whether local configuration changes or individual
ephemeral configuration changes take precedence as described in RFC7921.
The I2RS protocol MUST support his mechanism.
Joe
/js
On Wed, Jul 20, 2016 at 01:41:26PM +0200, jmh.direct wrote:
The reason I referred to individual I2RS clients is that different clients have different
priorities. The previous text referred to "ephemeral priority" which needed
clarification.
I referred to changes because the only time priority is relevant is when
something changes.
And the proposed new text loses the emphasis on associating a priority with
local config.
Yours,Joel
Sent via the Samsung Galaxy S® 6, an AT&T 4G LTE smartphone
-------- Original message --------From: Juergen Schoenwaelder <[email protected]> Date:
7/20/16 1:19 PM (GMT+01:00) To: Susan Hares <[email protected]> Cc: "'Joel M. Halpern'"
<[email protected]>, 'Joe Clarke' <[email protected]>, 'Russ White' <[email protected]>,
[email protected] 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:
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.
On Wed, Jul 20, 2016 at 06:49:27AM -0400, Susan Hares wrote:
I'm fine with this revision. Anyone else wish to change this version?
Sue
-----Original Message-----
From: i2rs [mailto:[email protected]] On Behalf Of Joel M. Halpern
Sent: Wednesday, July 20, 2016 5:25 AM
To: Joe Clarke; Susan Hares; 'Russ White'; [email protected]
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:
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
--
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/>
_______________________________________________
i2rs mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/i2rs
_______________________________________________
i2rs mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/i2rs
