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

[Susan Hares <[e-mail]>]

Robert:
Responses below.




Sent via the Samsung Galaxy Note5, an AT&T 4G LTE smartphone-------- Original message --------From: Robert Wilton <[e-mail]> Date: 6/20/2016  11:30 AM  (GMT-05:00) To: [e-mail], [e-mail], [e-mail] 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:

    
       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?

    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