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

[Andy Bierman <[e-mail]>]

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

> 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  ??
>


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).





>
>
> Thanks
>
> Anu Nair
>


Andy


>
>
> *From:* I2rs-proto-dt [mailto:[e-mail]] *On Behalf
> Of *Andy Bierman
> *Sent:* Friday, September 18, 2015 5:52 PM
> *To:* Susan Hares
> *Cc:* [e-mail]
> *Subject:* Re: [I2rs-proto-dt] FW: Join WebEx meeting in progress: i2rs
> protocol design team
>
>
>
> 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 <[e-mail]> 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:[e-mail]] *On Behalf
> Of *Andy Bierman
> *Sent:* Friday, September 18, 2015 11:12 AM
> *To:* Susan Hares
> *Cc:* [e-mail]
> *Subject:* Re: [I2rs-proto-dt] FW: Join WebEx meeting in progress: i2rs
> protocol design team
>
>
>
> 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 <[e-mail]> 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:[e-mail]]
> *Sent:* Friday, September 18, 2015 9:44 AM
> *To:* [e-mail]
> *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
>
>
>
>
>
>
>
> *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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/i2rs-proto-dt
>
>
>
>
>