> On Feb 24, 2016, at 10:02 PM, [email protected] wrote: > > Hi Lou, > >> From a high level perspective, schema mount looks really good in term of >> simplification. I went to the draft quickly (very quickly), and I may see an >> issue. > Let's take the example of LNE, LNE may not have the exact same configuration > statements as the physical host, as example some HW specific parameters that > can only be configured on the physical host. In this case, when you mount the > model into LNE, we need the ability to prune some subtree of the mounted > tree. This pruning capacity does not seem to be taken into account yet. > > Thoughts ?
Think of the mounted models as something the LNE provides, not as something that the host provides. The view and access using the mount point is from the host, but the LNE defines what is there. Conceptually this is just a different way to access the LNE models instead of logging into the LNE mgmt netconf port and talking netconf directly to the LNE. This is not a requirement in how the things are implemented, but is useful in clarifying what is being provided. Thanks, Chris. > Best Regards, > > Stephane > > > > -----Original Message----- > From: Rtg-dt-yang-arch [mailto:[email protected]] On Behalf > Of Lou Berger > Sent: Wednesday, February 24, 2016 03:40 > To: Routing WG > Cc: Routing Area YANG Architecture DT > Subject: [Rtg-dt-yang-arch] Fwd: I-D Action: > draft-rtgyangdt-rtgwg-device-model-03.txt > > > Hello, > This draft has been updated to use an emerging yang capability called > 'schema-mount' [1] which translates to a significant simplification. To > quote the draft: > > Schema Mount enables a dramatic simplification of the presented > device model, particularly for "lower-end" devices which are unlikely > to support multiple network instances or logical network elements. > Should structural-mount/YSDL not be available, the more explicit tree > structure presented in earlier versions of this document will need to > be utilized. > > As it looks like there will soon be a netmod WG draft on schema mount, we > think it's time to ask the WG to consider adopting our draft as a RTG WG > draft. > > [1] There was a netmod interim on schema mount on Monday, see > http://etherpad.tools.ietf.org:9000/p/netmod-interim-20160222 > > Our slides from that meeting are available at > https://www.ietf.org/proceedings/interim/2016/02/22/netmod/slides/slides-interim-2016-netmod-1-1.pptx > and it gives a brief overview of the current draft. > > Lou (and co-authors) > -------- Forwarded Message -------- > Subject: I-D Action: draft-rtgyangdt-rtgwg-device-model-03.txt > Date: Tue, 23 Feb 2016 18:29:51 -0800 > From: [email protected] > Reply-To: [email protected] > To: [email protected] > > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > Title : Network Device YANG Organizational Models > Authors : Acee Lindem > Lou Berger > Dean Bogdanovic > Christan Hopps > Filename : draft-rtgyangdt-rtgwg-device-model-03.txt > Pages : 36 > Date : 2016-02-23 > > Abstract: > This document presents an approach for organizing YANG models in a > comprehensive structure that may be used to configure and operate > network devices. The structure is itself represented as a YANG > model, with all of the related component models logically organized > in a way that is operationally intuitive, but this model is not > expected to be implemented. The identified component modules are > expected to be defined and implemented on common network devices. > > This document also defines two modules that can be used to model the > logical and virtual resource representations that may be present on a > network device. Examples of common industry terms for logical > resource representations are Logical Systems or Routers. Examples of > of common industry terms for virtual resource representations are > Virtual Routing and Forwarding (VRF) instances and Virtual Switch > Instances (VSIs). > > This document is derived from work submitted to the IETF by members > of the informal OpenConfig working group of network operators and is > a product of the Routing Area YANG Architecture design team. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-rtgyangdt-rtgwg-device-model/ > > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-rtgyangdt-rtgwg-device-model-03 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-rtgyangdt-rtgwg-device-model-03 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > I-D-Announce mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html or > ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > > > _______________________________________________ > Rtg-dt-yang-arch mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/rtg-dt-yang-arch > > _________________________________________________________________________________________________________________________ > > Ce message et ses pieces jointes peuvent contenir des informations > confidentielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu > ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages > electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, deforme ou > falsifie. Merci. > > This message and its attachments may contain confidential or privileged > information that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and delete > this message and its attachments. > As emails may be altered, Orange is not liable for messages that have been > modified, changed or falsified. > Thank you. > > _______________________________________________ > Rtg-dt-yang-arch mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/rtg-dt-yang-arch >
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ rtgwg mailing list [email protected] https://www.ietf.org/mailman/listinfo/rtgwg
