Subject: [I2rs-proto-dt] FW: Join WebEx meeting in progress: i2rs protocol design team

From: "Susan Hares" <[email-masked]>
Date: Fri, 18 Sep 2015 09:47:21 -0400

Hi all: 

This is the design team meeting number.   I will be on-line to discuss next-steps for 20 minutes.    Andy and Kent were going to work up text.   I’ve not seen any text from Andy or Kent.   My next steps are to work begin to work on text? 

Any  thoughts? 

Sue 

From: I2RS Working Group [mailto:[email-masked]] 
Sent: Friday, September 18, 2015 9:44 AM
To: [email-masked]
Subject: Join WebEx meeting in progress: i2rs protocol design team

Hello, 

My WebEx meeting is in progress. 

Join me now from a browser, phone, or video conferencing system or application.

i2rs protocol design team 

Friday, September 18, 2015 

9:43 am  |  Eastern Daylight Time (New York, GMT-04:00)  |  1 hr 

 <https://ietf.webex.com/ietf/e.php?MTID=mc24852d4ea59aea3246ff757cf85255d> Join WebEx meeting 

Meeting number: 

645 703 803 

Meeting password:

proto.fun

Join by phone

1-877-668-4493 Call-in toll free number (US/Canada)

1-650-479-3208 Call-in toll number (US/Canada)

Access code: 645 703 803

 <http://www.webex.com/pdf/tollfree_restrictions.pdf> Toll-free calling restrictions

Can't join the meeting?  <https://ietf.webex.com/ietf/mc> Contact support. 

IMPORTANT NOTICE: Please note that this WebEx service allows audio and other information sent during the session to be recorded, which may be discoverable in a legal matter. By joining this session, you automatically consent to such recordings. If you do not consent to being recorded, discuss your concerns with the host or do not join the session.

---

From: Andy Bierman <[email-masked]>
Date: Fri, 18 Sep 2015 08:11:49 -0700

Hi,

I have asked Kent to be the lead author on this draft,
but he does not have time.  I think a routing person should
be the main author.

The mechanics of editing an ephemeral datastore are somewhat
straight-forward. The overlap of priority-based dependencies
can cause problems.  Detecting those problems so nobody ever
puts a bad edit in the server will be extremely complicated and
the I2RS server could slow down 1000X just to validate all these
corner-cases.

IMO it would be better if a routing person laid out the best operational
options for routing,
and then a YANG expert can find the most optimal way to do that.

Andy

On Fri, Sep 18, 2015 at 6:47 AM, Susan Hares <[email-masked]> wrote:

> Hi all:
>
>
>
> This is the design team meeting number.   I will be on-line to discuss
> next-steps for 20 minutes.    Andy and Kent were going to work up text.
> I’ve not seen any text from Andy or Kent.   My next steps are to work begin
> to work on text?
>
>
>
> Any  thoughts?
>
>
>
> Sue
>
>
>
> *From:* I2RS Working Group [mailto:[email-masked]]
> *Sent:* Friday, September 18, 2015 9:44 AM
> *To:* [email-masked]
> *Subject:* Join WebEx meeting in progress: i2rs protocol design team
>
>
>
> Hello,
>
> *i2rs protocol design team*
>
> *Join WebEx meeting*
> <https://ietf.webex.com/ietf/e.php?MTID=mc24852d4ea59aea3246ff757cf85255d>
>
>
>
> Meeting number:
>
> 645 703 803
>
> Meeting password:
>
> proto.fun
>
>
>
>
>
>
>
> *Join by phone*
>
> *1-877-668-4493* Call-in toll free number (US/Canada)
>
> *1-650-479-3208* Call-in toll number (US/Canada)
>
> Access code: 645 703 803
>
> Toll-free calling restrictions
> <http://www.webex.com/pdf/tollfree_restrictions.pdf>
>
>
>
>
>
>
>
> Can't join the meeting? Contact support. <https://ietf.webex.com/ietf/mc>
>
>
>
>
>
>
>
> IMPORTANT NOTICE: Please note that this WebEx service allows audio and
> other information sent during the session to be recorded, which may be
> discoverable in a legal matter. By joining this session, you automatically
> consent to such recordings. If you do not consent to being recorded,
> discuss your concerns with the host or do not join the session.
>
>
>
> _______________________________________________
> I2rs-proto-dt mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/i2rs-proto-dt
>
>

---

From: "Susan Hares" <[email-masked]>
Date: Fri, 18 Sep 2015 11:49:10 -0400

Andy:

I understand that Kent is very busy.  I proposed that I start off draft and hand it over to another one of the routing I2RS authors.   I will send out a draft early next week. 

Sue 

From: I2rs-proto-dt [mailto:[email-masked]] On Behalf Of Andy Bierman
Sent: Friday, September 18, 2015 11:12 AM
To: Susan Hares
Cc: [email-masked]
Subject: Re: [I2rs-proto-dt] FW: Join WebEx meeting in progress: i2rs protocol design team

Hi,

be the main author.

the I2RS server could slow down 1000X just to validate all these corner-cases.

IMO it would be better if a routing person laid out the best operational options for routing,

 

Andy

Hi all: 

Any  thoughts? 

Sue 

Hello, 

 

 

Meeting number: 

645 703 803 

Meeting password:

proto.fun

Join by phone

Access code: 645 703 803

---

From: Andy Bierman <[email-masked]>
Date: Fri, 18 Sep 2015 09:52:25 -0700

Hi,

Here are the notes I have for the draft Kent and I were starting.
It is probably controversial, but perhaps useful for discussing some
details.

On document structure:
-------------------------------

1) Intro
2) Definition of intended config, applied config and
derived state for NETCONF/RESTCONF
3) Definition of ephemeral datastore for NETCONF/RESTCONF
4) YANG "ephemeral" statement
5) NETCONF protocol extensions for the ephemeral datastore
    -- defined as a NETCONF capability
6) RESTCONF protocol extensions for the ephemeral datastore
   -- defined as RESTCONF protocol capability

Notes on technical details
------------------------------------

 1) ephemeral datastore is never locked

 2) ephemeral datastore treated as N client panes
      - server picks how many clients it supports
      - multi-head support is optional since max-clients allowed to be 1;

  3) each client has a unique priority

   container i2rs-clients {
       leaf max-clients {
          config false;
          mandatory true;
          type uint32 {
            range "1 .. max";
          }
       }
       list i2rs-client {
          key name;
          unique priority;
          leaf name { ... }
          leaf priority { ... }
       }
    }

   If a client is not present in the i2rs-client list, then the worst
priority
   value is assigned

   The best possible priority needs to be reserved for the system, or the
    protocol has to make a special case of system-set data

  4) each client writes into its own pane so there is no conflict
     within a pane;  Difference is really what the server retains from
     a partial or failed edit.  Should be OK to save nothing or save all
(caching)

  5) a partial operation is one where some subset of the written data
      is not applied because of better priority for that node;  Only allowed
      if the error-option is stop-on-error or continue-on-error

   --> NETCONF stop-on-error and continue-on-error are not going
        to work.  There is no mandated processing order for edits
        Perhaps I2RS can force some processing order to support partial
edits
        IMO, all-or-nothing is the only option that is interoperable.

    -->  NETCONF has no way of reporting which edits were accepted and which
          were rejected, for partial operations. Perhaps I2RS can add new
error
         handling response data

    (BTW, all of this was removed from NETCONF (RFC 6241) because it was
    too complicated, and nobody implemented it because it was too
complicated.
    I2RS WG should take note of that).

  6) caching is optional; a server may retain the pane for each client;
      if not supported then the pane never contains unaccepted data;
      i.e. the server will return an error and not retain the edit that
caused
      the error; caching allows the server to apply lower priority data
      when higher priority data is removed

Not sure if examples should be in a separate appendix of mixed into
the normative text (like YANG RFC)

Andy

On Fri, Sep 18, 2015 at 8:49 AM, Susan Hares <[email-masked]> wrote:

> Andy:
>
>
>
> I understand that Kent is very busy.  I proposed that I start off draft
> and hand it over to another one of the routing I2RS authors.   I will send
> out a draft early next week.
>
>
>
> Sue
>
>
>
> *From:* I2rs-proto-dt [mailto:[email-masked]] *On Behalf
> Of *Andy Bierman
> *Sent:* Friday, September 18, 2015 11:12 AM
> *To:* Susan Hares
> *Cc:* [email-masked]
> *Subject:* Re: [I2rs-proto-dt] FW: Join WebEx meeting in progress: i2rs
> protocol design team
>
>
>
> Hi,
>
>
>

---

From: "Susan Hares" <[email-masked]>
Date: Fri, 18 Sep 2015 12:55:31 -0400

Andy: 

Thank you for the outline.  This will help. I will finish a kick start draft and turn this over to another author who will help you.  

Sue 

From: I2rs-proto-dt [mailto:[email-masked]] On Behalf Of Andy Bierman
Sent: Friday, September 18, 2015 12:52 PM
To: Susan Hares
Cc: [email-masked]
Subject: Re: [I2rs-proto-dt] FW: Join WebEx meeting in progress: i2rs protocol design team

Hi,

details.

 

On document structure:

1) Intro

   container i2rs-clients {

       leaf max-clients {

          config false;

          mandatory true;

          type uint32 {

            range "1 .. max";

          }

       }

       list i2rs-client {

          key name;

          unique priority;

          leaf name { ... }

          leaf priority { ... }

       }

    }

   If a client is not present in the i2rs-client list, then the worst priority

   value is assigned

     a partial or failed edit.  Should be OK to save nothing or save all (caching)

        Perhaps I2RS can force some processing order to support partial edits

          were rejected, for partial operations. Perhaps I2RS can add new error

         handling response data

    too complicated, and nobody implemented it because it was too complicated.

      i.e. the server will return an error and not retain the edit that caused

 

Andy

 

Andy:

Sue 

Hi,

be the main author.

 

Andy

Hi all: 

Any  thoughts? 

Sue 

Hello, 

 

 

Meeting number: 

645 703 803 

Meeting password:

proto.fun

Join by phone

Access code: 645 703 803

---

From: Dean Bogdanovic <[email-masked]>
Date: Sat, 19 Sep 2015 11:21:05 +0100

Andy,

Thank you for writing this and have few questions

Where will be the ephemeral datastore defined? I’m hearing discussions about ephemeral dat store is several places and it doesn’t sound people have a common understanding of it. As side commend, I agree what you wrote down as high level layout on it.

What edits are allowed in the ephemeral data store. Should those be syntactically correct or syntacticly and semantically?

Dean

> On Sep 18, 2015, at 5:52 PM, Andy Bierman <[email-masked]> wrote:
> 
> Hi,
> 
> On Fri, Sep 18, 2015 at 8:49 AM, Susan Hares <[email-masked] <mailto:[email-masked]>> wrote:
> Andy:
> 
>  
> 
> From: I2rs-proto-dt [mailto:[email-masked] <mailto:[email-masked]>] On Behalf Of Andy Bierman
> Cc: [email-masked] <mailto:[email-masked]>
> On Fri, Sep 18, 2015 at 6:47 AM, Susan Hares <[email-masked] <mailto:[email-masked]>> wrote:
> 
> Hi all:
> 
>  
> 
> From: I2RS Working Group [mailto:[email-masked] <mailto:[email-masked]>] 
> To: [email-masked] <mailto:[email-masked]>
> Join WebEx meeting  <https://ietf.webex.com/ietf/e.php?MTID=mc24852d4ea59aea3246ff757cf85255d>
>  
> 
> Meeting number:
> 
> 645 703 803 
> 
> Meeting password:
> 
> proto.fun
> 
>  
> 
>  
> 
>  
> 
> Join by phone
> 
> Toll-free calling restrictions <http://www.webex.com/pdf/tollfree_restrictions.pdf>
>  
> 
>  
> 
>  
> 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/i2rs-proto-dt <https://www.ietf.org/mailman/listinfo/i2rs-proto-dt>
>  
> 
>

---

From: Andy Bierman <[email-masked]>
Date: Sat, 19 Sep 2015 07:28:35 -0700

On Sat, Sep 19, 2015 at 3:21 AM, Dean Bogdanovic <[email-masked]> wrote:

> Where will be the ephemeral datastore defined? I’m hearing discussions
> about ephemeral dat store is several places and it doesn’t sound people
> have a common understanding of it. As side commend, I agree what you wrote
> down as high level layout on it.
>
>

There does seem to be some overlap right now with opstate, wrt/ defining
new datastores.
To me, a datastore is just a way to refer to "data in the same state"
within a protocol.
To others, it is seen as a more concrete implementation requirement. The
IETF will have to work this out.

> What edits are allowed in the ephemeral data store. Should those be
> syntactically correct or syntacticly and semantically?
>
>

This is the $64 question.
Jeff has described at least one scenario where priority between 2 clients
does
not clearly solve edit contention.  (Forget all the details but involves an
entry
that cannot be deleted because the result would leave an unresolved
reference
somewhere else in the data).

There are 3 possible outcomes for a valid edit:

  1) no collisions; must be accepted
  2) partial overlap with better priority data
  3) complete overlap with better priority data

Depending on stop-on-error or continue-on-error (2) will be accepted or not.
This is where Jan (and I) start to worry about the client trying to be too
clever,
but Joel thinks a client could recover and deal with outcome (2)

Clearly the data has to pass "field validation" (pass the typedef checks;
can't send int32=fred)

Validation slows things down a lot, so datastore validation needs to be
considered carefully.  This is where I think routing expertise will help
decide how much validation can really be skipped for a particular use-case.

Andy

---

From: Andy Bierman <[email-masked]>
Date: Sat, 19 Sep 2015 08:53:16 -0700

Hi,

Here is an example of a routing use-case that is a challenge...

How is client priority used to make sure that a lessor client
cannot insert a route with a shorter prefix into a RIB than
an existing entry by a higher priority client?

This goes back to early questions that were never answered,
such as "what exactly is an overlap/edit collision".
It seems that some data models have to be written with client priority
support in them, rather than something than can always be
resolved by comparing exact instances in 2 client panes.

Examples of 2 clients trying to insert routes into the same RIB
would be useful for the draft.  I think we need that to explain
all the things we mean by "overlap" when evaluating client panes.

Andy

---

From: Anu Nair <[email-masked]>
Date: Thu, 24 Sep 2015 08:18:38 +0000

Hi Andy

Can you please clarify this .

So the priority maximum will be same as the max-clients , if  we are assigning unique priorities from 1 – max-clilents.
Eg , if max clients is 100  (leaf max clients , range 1 .. max ) then priority range is also from 1 – max .

So the leaf max-clients { .. range 1- 32 } represents priority information also , so it can be max-clients or max-priorities  ??

Thanks
Anu Nair

From: I2rs-proto-dt [mailto:[email-masked]] On Behalf Of Andy Bierman
Sent: Friday, September 18, 2015 5:52 PM
To: Susan Hares
Cc: [email-masked]
Subject: Re: [I2rs-proto-dt] FW: Join WebEx meeting in progress: i2rs protocol design team

Hi,

On document structure:

1) Intro

   container i2rs-clients {
       leaf max-clients {
          config false;
          mandatory true;
          type uint32 {
            range "1 .. max";
          }
       }
       list i2rs-client {
          key name;
          unique priority;
          leaf name { ... }
          leaf priority { ... }
       }
    }

Andy

On Fri, Sep 18, 2015 at 8:49 AM, Susan Hares <[email-masked]<mailto:[email-masked]>> wrote:
Andy:

Sue

From: I2rs-proto-dt [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Andy Bierman
Sent: Friday, September 18, 2015 11:12 AM
To: Susan Hares
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [I2rs-proto-dt] FW: Join WebEx meeting in progress: i2rs protocol design team

Hi,

Andy

On Fri, Sep 18, 2015 at 6:47 AM, Susan Hares <[email-masked]<mailto:[email-masked]>> wrote:
Hi all:

Any  thoughts?

Sue

From: I2RS Working Group [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Friday, September 18, 2015 9:44 AM
To: [email-masked]<mailto:[email-masked]>
Subject: Join WebEx meeting in progress: i2rs protocol design team

Hello,

Meeting number:

645 703 803

Meeting password:

proto.fun

Join by phone

Access code: 645 703 803

Toll-free calling restrictions<http://www.webex.com/pdf/tollfree_restrictions.pdf>

Can't join the meeting? Contact support.<https://ietf.webex.com/ietf/mc>

_______________________________________________
I2rs-proto-dt mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/i2rs-proto-dt

---

From: Andy Bierman <[email-masked]>
Date: Thu, 24 Sep 2015 06:26:14 -0700

On Thu, Sep 24, 2015 at 1:18 AM, Anu Nair <[email-masked]> wrote:

> So the priority maximum will be same as the max-clients , if  we are
> assigning unique priorities from 1 – max-clilents.
>
> So the leaf max-clients { .. range 1- 32 } represents priority information
> also , so it can be max-clients or max-priorities  ??
>

The term 'max' in YANG resolves to 4B-1 in this range, not 32.

Actually, the text I sent allows for multiple clients to all have the
default priority
which is not good -- if client-id is needed to resolve collisions then
there is
no point to requiring a unique priority per client.

The priority is not required to be densely numbered.
Whether there are 1 pane per client or 1 pane per priority or
1 giant blob full of everything, the code will be the same.

The goal of "unique priority" is to require that only priority be saved
in the meta-data for the ephemeral datastore.  Without that, client-id and
priority
must be saved (per data node).

Andy

> *Sent:* Friday, September 18, 2015 5:52 PM
> *To:* Susan Hares