On Fri, Jun 28, 2019 at 7:09 AM Fengchong (frank) < [email protected]> 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:[email protected]] > 发送时间: 2019年6月28日 17:18 > 收件人: Fengchong (frank) <[email protected]>; Juergen > Schoenwaelder <[email protected]> > 抄送: [email protected]; [email protected]; Zhangwei (SS) < > [email protected]> > 主题: 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) <[email protected]> > Sent: 28 June 2019 10:07 > To: Juergen Schoenwaelder <[email protected]>; Rob > Wilton (rwilton) <[email protected]> > Cc: [email protected]; [email protected]; Zhangwei (SS) < > [email protected]> > 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:[email protected]] > 发送时间: 2019年6月28日 16:50 > 收件人: Rob Wilton (rwilton) <[email protected]> > 抄送: Fengchong (frank) <[email protected]>; [email protected]; > [email protected]; Zhangwei (SS) <[email protected]> > 主题: 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 <[email protected]> On Behalf Of Fengchong (frank) > > Sent: 28 June 2019 04:29 > > To: [email protected]; [email protected] > > Cc: Zhangwei (SS) <[email protected]> > > 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 > > 电子邮件：[email protected]<mailto:[email protected]> > > 公司网址：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 > > 收件人: '[email protected]' <[email protected]<mailto:[email protected]>>; > > [email protected]<mailto:[email protected]> > > 抄送: Yangshouchuan > > <[email protected]<mailto:[email protected]>>; Zhangwei > > (SS) <[email protected]<mailto:[email protected]>> > > 主题: 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 > > [email protected] > > https://www.ietf.org/mailman/listinfo/netmod > > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 <https://www.jacobs-university.de/> > _______________________________________________ > netconf mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/netconf >
_______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
