Subject: [i2rs] Clarifications on draft-ietf-i2rs-ephemeral-state section 3

From: Robert Wilton <[email-masked]>
Date: Mon, 20 Jun 2016 16:30:57 +0100

Hi Jeff, Susan,

In one of the discussions that I had with Juergen regarding datastores 
he indicated the refined datastore architecture that I was proposing 
wasn't in keeping with the current ephemeral datastore ideas on I2RS, 
hence I'm trying to catch up.

I have a few clarifying questions on sections 3.2 of 
draft-ietf-i2rs-ephemeral-state that you might be able to help with me 
please.  I've only just signed up the IR2S, so apologies if these 
questions have already been asked/answered.

Section 3.1. Persistence, paragraph 1 is stated as:

    Ephemeral-REQ-01: I2RS requires ephemeral state; i.e. state that does
    not persist across reboots.  If state must be restored, it should be
    done solely by replay actions from the I2RS client via the I2RS
    agent.  Ephemeral state may consist of ephemeral configuration or
    ephemeral operational state, or both.

This text makes it clear that "Ephemeral state" consists of both 
"ephemeral config" and/or "ephemeral operation state".

Ephemeral-REQ-03 is stated as:

    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.

Q1. Am I right in understanding that both ephemeral config and ephemeral 
operational state independently have the requirement that they have to 
rely on regular operational state as a constraint?

Q2. What is expected to happen if the operational state changes such 
that the constraint no longer hold for a ephemeral node? Should that 
node be removed, or just stop taking effect?  Or expressed differently: 
could ephemeral config be regarded as being conditionally applied on a 
constraint?

Ephemeral-REQ-04 is stated as:

    Ephemeral-REQ-04: Ephemeral state MAY refer to non-ephemeral state
    for purposes of implementing constraints.  The designer of ephemeral
    state modules are advised that such constraints may impact the speed
    of processing ephemeral state commits and should avoid them when
    speed is essential.

Q3. I think that REQ-03 may already answer this, but to avoid any 
confusion: Does this mean that ephemeral config nodes may refer to 
non-ephemeral operational state nodes?

Thanks,
Rob

---

From: Susan Hares <[email-masked]>
Date: Wed, 22 Jun 2016 17:33:09 -0400

Robert:
Responses below.

Sent via the Samsung Galaxy Note5, an AT&T 4G LTE smartphone-------- Original message --------From: Robert Wilton <[email-masked]> Date: 6/20/2016  11:30 AM  (GMT-05:00) To: [email-masked], [email-masked], [email-masked] Subject: [i2rs] Clarifications on draft-ietf-i2rs-ephemeral-state section 3 

    Hi Jeff, Susan,
    In one of the discussions that I had with Juergen regarding
      datastores he indicated the refined datastore architecture that I
      was proposing wasn't in keeping with the current ephemeral
      datastore ideas on I2RS, hence I'm trying to catch up.

    I have a few clarifying questions on sections 3.2 of
      draft-ietf-i2rs-ephemeral-state that you might be able to help
      with me please.  I've only just signed up the IR2S, so apologies
      if these questions have already been asked/answered.

    Section 3.1. Persistence, paragraph 1 is stated as:
       Ephemeral-REQ-01: I2RS requires ephemeral state; i.e. state that does
   not persist across reboots.  If state must be restored, it should be
   done solely by replay actions from the I2RS client via the I2RS
   agent.  Ephemeral state may consist of ephemeral configuration or
   ephemeral operational state, or both.
    This text makes it clear that "Ephemeral state" consists of both
      "ephemeral config" and/or "ephemeral operation state".
    Ephemeral-REQ-03 is stated as:
       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.
    Q1. Am I right in understanding that both ephemeral config and
      ephemeral operational state independently have the requirement
      that they have to rely on regular operational state as a
      constraint? 

    Sue: it depends on the data model.  For the I2RS data models, the i2rs rib and i2rs fb-rib do depend on the configuration and operational state of interfaces.For the i2rs topology models, the l3 topology model depends on the operational state of ospf,is-is and static configuration, and some interface srate.  Some interface state may be virtual interfaces or virtual termination points.  The  l2 topology model has dependencies on layer 2 protocols and interface state.  In the topology model there can be static configuration that augments the operational state by creating virtual topologies or tunnels.
    Q2. What is expected to happen if the operational state changes
      such that the constraint no longer hold for a ephemeral node? 
      Should that node be removed, or just stop taking effect?  Or
      expressed differently: could ephemeral config be regarded as being
      conditionally applied on a constraintSue: if the constraints the no longer allows the ephemeral state to be valid, the the i2rs agent sends a notification to the i2rs clients to and removes the invalid state.  The i2rs client can try to fix this state by other action  (e.g. configure something else or remove other state.)
    Ephemeral-REQ-04 is stated as:

    Yes.  An example is the reference to interface configuration or interface operational stateLet me know if you have more questions.

    Thanks
      Rob
    Glad to answer any questions.
    
Sue