Re: [i2rs] modeling options for draft-ietf-i2rs-yang-network-topo

["Susan Hares" <[e-mail]>]

To Xufeng: 

Clarifying question - Are you asking about I2RS topology as a generic yang
model for any configuration or are you asking about I2RS topology model as
an ephemeral topology model. 

To Martin: 
Clarifying questions: 

1)  Is your rpc suggest target toward the I2RS topology model as a generic
topology model or an I2RS ephemeral state model or both? 

2) Could we define rpcs now that operate as Alex desired for generic
topology models that could be replaced by more generic mechanisms later?
For example, the I2RS RIB has defined rpcs for all major functions
(add/delete rib, add/delete route, add/delete nexhop) plus notifications for
changes.  Is this the best approach here? 

Sue 

-----Original Message-----
From: i2rs [mailto:[e-mail]] On Behalf Of Xufeng Liu
Sent: Thursday, February 16, 2017 10:39 AM
To: 'Martin Bjorklund'; [e-mail]
Cc: [e-mail]
Subject: Re: [i2rs] modeling options for draft-ietf-i2rs-yang-network-topo



> -----Original Message-----
> From: i2rs [mailto:[e-mail]] On Behalf Of Martin 
> Bjorklund
> Sent: Tuesday, February 14, 2017 11:41 AM
> To: [e-mail]
> Cc: [e-mail]
> Subject: Re: [i2rs] modeling options for 
> draft-ietf-i2rs-yang-network-topo
> 
> Kent Watsen <[e-mail]> wrote:
> >
> >
> > [moving yang-doctors to BCC]
> >
> >
> > >> OPTION 1: separate /foo and /foo-state trees
> > >> --------------------------------------------
> > >>
> > >> This option was/is described here:
> > >> https://www.ietf.org/mail-archive/web/i2rs/current/msg04316.html.
> > >>
> > >> PROS:
> > >>   a) does NOT break legacy clients (how we got here)
> > >>   b) consistent with convention used in many IETF modules
> > >>   c) able to show if/how opstate may differ from configured 
> > >> values
> > >>
> > >> CONS:
> > >>   a) questionably valid YANG leafref usage
> > >
> > > What does this mean?
> >
> > I'm referring to how the description statement explains that the 
> > server may look to operational state in order to resolve the 
> > leafref, which is to result in behavior similar to pre-configuration 
> > in RFC 7223.
> 
> Ok, I didn't pay close attention to the proposal in the quoted email.
> 
> I would design this a bit differently.  The config true leaf "dependency"
should
> have a leafref to the config false node name, with require-instance false.
The
> description should explain that the configuration item will be used by 
> the
server
> if all dependencies exist.  When the configuration item is used, it 
> shows
up in the
> config false list.
> 
> This way, the leafref usage is valid and straight forward.
> 
> > >>   b) complex server implementation (to handle require-instance
> > >> false)
> > >
> > >Can you elaborate on this one?
> >
> > This is primarily a reflection of the CON listed above, in that it 
> > seems that a server would need to have special handling for when 
> > dependencies transition from being present to not-present and vice 
> > versa, much like the code to handle when a physical card is plugged 
> > in or removed.
> 
> Yes, but I think this is inherent to the problem at hand.  Even with 
> the
config true
> solution defined in the current draft, it is not clear how things that
were created
> by the server would be deleted (if there were references to them).
> 
> > Note: I should've listed this as a CON for OPTION 2 as well.
> >
> >
> >
> > >>   c) eventually the module would need to migrate to the long-term
> > >>      solution, which would result in needing to also rewrite all
> > >>      modules that have augmented it (e.g., ietf-te-topology).
> > >>   d) leafref path expressions really only work for configuration
data,
> > >>      though a clever server could have a special ability to peak at
> > >>      the opstate values when doing validations.  Of course, with
> > >>      require-instance is false, the value of leafref based validation
> > >>      checking is negated anyway, even for config true nodes, so this
> > >>      may not matter much.
> > >>
> > >>
> > >>
> > >> OPTION 2: explicit client-option to also return tagged opstate 
> > >> data
> > >> -----------------------------------------------------------------
> > >> --
> > >>
> > >> This option takes a couple forms.  The first is module-specific 
> > >> and the second is generic.  In both cases, the idea is modeled 
> > >> after the with-defaults solution (RFC6243), wherein the client 
> > >> passes a special flag into <get-config> causing the server to 
> > >> also return opstate data, having a special metadata flag set, 
> > >> intermingled with the configuration data.
> > >>
> > >>
> > >> 2A: Module-specific version
> > >>
> > >>    module foo {
> > >>       import ietf-netconf { prefix nc; }
> > >>       import ietf-yang-metadata { prefix md; }
> > >>       md:annotation server-provided {
> > >>          type boolean;
> > >>       }
> > >>       container nodes {
> > >>          config true;
> > >>          list node {
> > >>             key "name";
> > >>             leaf name { type string; }
> > >>             leaf dependency {
> > >>                type leafref {
> > >>                  path "../node/name"
> > >>                  require-instance false;
> > >>                }
> > >>             }
> > >>          }
> > >>       }
> > >>       augment /nc:get-config/nc:input {
> > >>          leaf with-server-provided {
> > >>             type boolean;
> > >>          }
> > >>       }
> > >>    }
> > >
> > > I don't think this solution is substantially different from the 
> > > solution in draft-ietf-i2rs-yang-network-topo-10.  You have just 
> > > moved a config false leaf to a meta-data annotation.  This 
> > > solution suffers from the same problems as the solution in 
> > > draft-ietf-i2rs-yang-network-topo-10.
> >
> > There are two primary differences:
> >
> > 1) It doesn't break legacy clients
> 
> The solution in the draft doesn't break legacy clients either - 
> there's a
config
> false leaf among the config true.  No problem.
> 
> >    , because it requires the client to
> >    explicitly pass a 'with-server-provided' flag in the <get-config>
> >    request in order to get back the extended response.  Likewise, it
> >    doesn't break backup/restore workflows, as the server can discard
> >    any 'server-provided' nodes passed in an <edit-config> operation.
> 
> Huh?  This goes against the defined behavior of 6241 + 7950.  This is 
> the
main
> problem with the solution in the current draft.
> 
> If a client sends a <get-config> for data in running, the server 
> cannot
send back
> data that is not in running.
> 
> >    Lastly, it doesn't break <lock>/<unlock>, as there is no comingling
> >    of opstate data in the 'running' datastore.
> >
> > 2) It doesn't say anything about how the opstate data is stored on the
> >    server.  The opstate data is not modeled at all.  This approach
> >    only defines a presentation-layer format for how opstate data can
> >    be returned via an RPC.  The server is free to persist the opstate
> >    data anyway it wants, perhaps in an internal datastore called
> >    'operational-state' or in an uber-datastore with the opstate data
> >    flagged with a datastore='oper-state' attribute.  Regardless, it's
> >    an implementation detail, and the conceptual datastore model is
> >    preserved.
> 
> You are essentially defining a new operation, but do it by modifying 
> the semantics of an existing one.  I don't think this is a good idea; 
> it is
better to
> define a new rpc.

[Xufeng] Is using a new rpc is acceptable? If so, this could be a viable
option.

> 
> 
> /martin
> 
> _______________________________________________
> i2rs mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/i2rs

_______________________________________________
i2rs mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/i2rs