Re: [netconf] 答复: [netmod] pls clarify get operation

[Andy Bierman <[e-mail]>]

On Fri, Jun 28, 2019 at 7:09 AM Fengchong (frank) <
[e-mail]> wrote:

> Hi Rob,
>     I think IETF solution: migrate to NMDA is unrealistic. The cost of
> migration to NMDA is too expensive, If the entire industry migrates to
> NMDA, the time will be long.
>     This will delay the deployment of the IETF model in the industry.
>     Anyway, even if vendor implements NMDA, the network manager/
> controller or client tools may not support NMDA client.
>     A non-NMDA client only support get/get-config, it still has no way to
> retrieve system-controlled data.
>
>

Although it would have been possible to augment the existing <get>
operation, it is much cleaner
to create a new operation instead. (From standards and implementation POV).

There is a significant amount of work needed to support NMDA in a server.
This effort would be the same whether <get> or <get-data> was used.
The protocol work is the tip of the iceberg.  Updating all the
instrumentation callbacks to
return operational values is the real work -- and exactly the same no
matter what protocol
solution is used. Client complexity is mostly related to the new YANG
library.

Starting over on a new solution would only take longer to deploy.


Andy




>     Generation config false copy for IETF YANG model is not reasonable,
> because published IETF standard YANG should not be changed, moreover, this
> is not friendly to the client or the server.
> -----邮件原件-----
> 发件人: Rob Wilton (rwilton) [mailto:[e-mail]]
> 发送时间: 2019年6月28日 17:18
> 收件人: Fengchong (frank) <[e-mail]>; Juergen
> Schoenwaelder <[e-mail]>
> 抄送: [e-mail]; [e-mail]; Zhangwei (SS) <
> [e-mail]>
> 主题: RE: [netmod] pls clarify get operation
>
> Hi Frank,
>
> You can't just change definitions in RFCs.  It breaks all existing
> clients/servers.  Besides, what you suggest doesn't really work (path
> clashes between configuration and operational state), unless you return two
> trees ... which starts to look extremely similar to the NMDA architecture
> ...
>
> IETF has already explored this problem and there is already a published
> IETF solution to the problem that you describe: Migrate to NMDA.  The NMDA
> architecture has many other benefits as well (E.g. allows for templating,
> inactive configuration, dynamic configuration, consistent OIR handling).
>
> Thanks,
> Rob
>
>
> -----Original Message-----
> From: Fengchong (frank) <[e-mail]>
> Sent: 28 June 2019 10:07
> To: Juergen Schoenwaelder <[e-mail]>; Rob
> Wilton (rwilton) <[e-mail]>
> Cc: [e-mail]; [e-mail]; Zhangwei (SS) <
> [e-mail]>
> Subject: 答复: [netmod] pls clarify get operation
>
> Should we change the definition of get operation? Like this, get operation
> can retrieve all running operational data including running configuration,
> system configuration.
> Otherwise, we have no way to get the information of system-controlled data
> according a NMDA-style YANG module(because has no config false copy )
> unless we implement NMDA.
> -----邮件原件-----
> 发件人: Juergen Schoenwaelder [mailto:[e-mail]]
> 发送时间: 2019年6月28日 16:50
> 收件人: Rob Wilton (rwilton) <[e-mail]>
> 抄送: Fengchong (frank) <[e-mail]>; [e-mail];
> [e-mail]; Zhangwei (SS) <[e-mail]>
> 主题: Re: [netmod] pls clarify get operation
>
> Yes, both the NETCONF <get> operation and the RESTCONF GET on the unified
> view of the underlying datastores have limitations and a solution in
> situations where these limitations hurt is to move towards NMDA.
>
> /js
>
> On Fri, Jun 28, 2019 at 08:38:38AM +0000, Rob Wilton (rwilton) wrote:
> > Hi Frank,
> >
> > Pre NMDA:
> >
> >   *   You have a the <running> datastore, along with some others like
> <candidate> and <startup> that you can ignore for the purposes of this
> discussion.
> >   *   The <running> datastore can only contains data for schema nodes
> that are marked as “config true” in YANG (i.e. “rw” in your tree output
> below).
> >   *   The system may also have some operational state data that is
> marked as “config false” in YANG (i.e. “ro” in your tree output below).
> >
> > The NETCONF <get-config> operation returns the contents of the <running>
> datastore.
> > The NETCONF <get> operation returns the contents of the <running>
> datastore combined with all the operational state as well.  Filters can be
> applied to return a subset of the data.
> >
> > Regarding your question about user created configuration vs system
> created configuration, it depends on whether the devices instantiates the
> configuration in <running> or not.  If it does, then it would be returned
> in <get> and <get-config> operations.  If it doesn’t then it would not.
> Different vendors/devices will likely implement this in different ways.
> >
> > Generally, I think that <running> should only contain the configuration
> explicitly configured by the operator’s systems.  But this means that there
> isn’t a clean way to represent system created configuration or applied
> configuration, unless you make a config false copy of every config true
> node in YANG.  This is approach that was taken by the original IETF YANG
> models (e.g. RFC 7223) before they were superseded by NMDA, and also the
> OpenConfig YANG models (but using a different structure – which also
> struggles to cleanly represent system created configuration data).
> >
> > The NMDA architecture was written to solve this problem in a clean way
> without requiring duplication in the YANG data models.
> >
> > Hopefully this helps clarify.
> >
> > Thanks,
> > Rob
> >
> >
> > From: netmod <[e-mail]> On Behalf Of Fengchong (frank)
> > Sent: 28 June 2019 04:29
> > To: [e-mail]; [e-mail]
> > Cc: Zhangwei (SS) <[e-mail]>
> > Subject: [netmod] 答复: pls clarify get operation
> >
> > Hi all,
> >
> >      Pls clarify this question. I have been confused for a long time.
> >
> > ________________________________
> > 华为技术有限公司 Huawei Technologies Co., Ltd.
> > [Company_logo]
> > 个人签名：冯冲
> > 手 机：13776612983
> > 电子邮件：[e-mail]<mailto:[e-mail]>
> > 公司网址：www.huawei.com<http://www.huawei.com>
> > ________________________________
> >  本邮件及其附件含有华为公司的保密信息，仅限于发送给上面地址中列出的个人或群组。禁
> > 止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制、或散发）本邮件中
> > 的信息。如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本邮件！
> > This e-mail and its attachments contain confidential information from
> > HUAWEI, which is intended only for the person or entity whose address
> > is listed above. Any use of the information contained herein in any
> > way (including, but not limited to, total or partial disclosure,
> > reproduction, or dissemination) by persons other than the intended
> > recipient(s) is prohibited. If you receive this e-mail in error,
> > please notify the sender by phone or email immediately and delete it!
> >
> > 发件人: Fengchong (frank)
> > 发送时间: 2019年6月27日 9:59
> > 收件人: '[e-mail]' <[e-mail]<mailto:[e-mail]>>;
> > [e-mail]<mailto:[e-mail]>
> > 抄送: Yangshouchuan
> > <[e-mail]<mailto:[e-mail]>>; Zhangwei
> > (SS) <[e-mail]<mailto:[e-mail]>>
> > 主题: pls clarify get operation
> >
> > Hi all,
> > In RFC6241, get operation is defined as:
> > 7.7<https://tools.ietf.org/html/rfc6241#section-7.7>.  <get>
> >
> >    Description:  Retrieve running configuration and device state
> >
> >       information.
> > This description is too simply, so I think it should be clarified.
> >
> > The case is: a data node modelled by one yang can be configured by user,
> but also can be created/modified by system or other protocols. If client
> issues get operation to retrieve this node,
> >           The data is created/modified by system or other protocols
> SHOULD be returned?
> >           For example:
> >           Rib can be configured by user and also can be created by
> routing protocols. In RFC 8349, the rib list is defined as:
> >
> >
> >
> >       +--rw ribs
> >
> >          +--rw rib* [name]
> >
> >             +--rw name              string
> >
> >             +--rw address-family?   identityref
> >
> >             +--ro default-rib?      boolean {multiple-ribs}?
> >
> >             +--ro routes
> >
> >             |  +--ro route*
> >
> >             |        ...
> >
> >             +---x active-route
> >
> >             |  +---w input
> >
> >             |  |  +---w v4ur:destination-address?   inet:ipv4-address
> >
> >             |  |  +---w v6ur:destination-address?   inet:ipv6-address
> >
> >             |  +--ro output
> >
> >             |        ...
> >
> >             +--rw description?      string
> >
> >
> >
> >        If client issued get operation to retrieve ribs from non-NMDA
> device, rib instance created by routing protocols should be returned?
> >
> >        Another associated question: If client issued get-config
> operation from non-NMDA device, only user-controlled rib instance should be
> returned?
> >
>
>
>
> > _______________________________________________
> > netmod mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/netmod
>
>
> --
> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> Phone: [phone]         Campus Ring 1 | 28759 Bremen | Germany
> Fax:   [phone]         <https://www.jacobs-university.de/>
> _______________________________________________
> netconf mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/netconf
>