Hi,
On 23/06/2016 16:47, Susan Hares wrote:
Juergen and Robert:
I will use the following for Ephemeral-REQ-03.
Ephemeral-REQ-03: Ephemeral state must be able to utilized temporary
operational state (e.g. MPLS LSP-ID or a BGP IN-RIB) as a
constraints.
That is the original text. Am I correct in assuming that you meant this
text instead?:
Ephemeral-REQ-03: Ephemeral state must be able to utilize operational state
(e.g. MPLS LSP-ID or BGP In-RIB) as a constraint.
If so, this proposed text is OK with me.
On Ephemeral-REQ-04,
Ephemeral-REQ-04: Ephemeral state MAY refer to non-ephemeral state
for purposes of implementing constraints.
Non-ephemeral state is both configuration state (config true), and
operational state (config false).
I believe these are two different requirements.
Yes. Given that REQ-03 covers using operational state as a constraint,
then would it be sufficient to word REQ-04 as:
Ephemeral-REQ-04: Ephemeral state MAY refer to non-ephemeral configuration
for purposes of implementing constraints.
Or perhaps to relate it more closely to REQ-03, as:
Ephemeral-REQ-03: Ephemeral state must be able to utilize non-ephemeral
configuration as a constraint.
Or is this missing something out?
Thanks,
Rob
Sue
-----Original Message-----
From: i2rs [mailto:i2rs-boun...@ietf.org] On Behalf Of Juergen Schoenwaelder
Sent: Thursday, June 23, 2016 11:42 AM
To: Robert Wilton
Cc: i2rs@ietf.org
Subject: Re: [i2rs] comments on draft-ietf-i2rs-ephemeral-state-10
On Thu, Jun 23, 2016 at 03:12:50PM +0100, Robert Wilton wrote:
Hi,
On 23/06/2016 13:02, Juergen Schoenwaelder wrote:
Hi,
here are few comments on the latest version.
Ephemeral-REQ-03: Ephemeral state must be able to utilized temporary
operational state (e.g. MPLS LSP-ID or a BGP IN-RIB) as a
constraints.
I am not sure what 'must be able to utilized temporary operational
state as constraints' means. The text in the parenthesis does not
help me understand this better. Did you want to say something like:
'Ephemeral configuration state may have constraints that refer to
operational state'? I am using 'ephemeral configuration state' since
this is used in other places (although sometimes worded slightly
different).
I asked a similar question in the I2RS interim meeting yesterday, I
think that Sue's spoken explanation of the requirement was effectively:
Ephemeral-REQ-03: Ephemeral state may have constraints that refer
to operational state, this includes potentially fast changing or
short lived operational state nodes, such as MPLS LSP-ID or a BGP
IN-RIB.
Perhaps this wording is more clear?
Yes, this is clearer. One question of course is what is expected to happen
if constraints are becoming false due to (fast) operational state changes,
that is, what the expected consequence of this is.
Ephemeral-REQ-04: Ephemeral state MAY refer to non-ephemeral state
for purposes of implementing constraints.
Hm, now I wonder whether this is just a special case of
Ephemeral-REQ-03 and if so it is not clear why we need this as a
separate requirement. If this is not the case but something
different, then likely my interpretation of Ephemeral-REQ-03 is wrong.
I think that ephemeral state could also use configuration nodes as a
constraint, so it isn't just operational state covered by REQ-3.
Well, the Ephemeral-REQ-04 text says 'non-ephemeral state' - if your
interpretation is correct than this phrase is wrong or possibly misleading.
/js
_______________________________________________
i2rs mailing list
i2rs@ietf.org
https://www.ietf.org/mailman/listinfo/i2rs
