Subject: Fwd: I-D Action: draft-rtgyangdt-rtgwg-device-model-03.txt

From: Lou Berger <[email-masked]>
Date: Tue, 23 Feb 2016 21:40:27 -0500

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-masked]
Reply-To: 	[email-masked]
To: 	[email-masked]

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-masked]
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

---

From: Loa Andersson <[email-masked]>
Date: Wed, 24 Feb 2016 18:10:39 +0800

Lou, et.al.,

A somewhat interesting questions (at least before reading) is how it is
with the alignment between this and what is in the OpenConfig documents?

/Loa

On 2016-02-24 10:40, Lou Berger wrote:
> rtgwg mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtgwg
>

---

From: Lou Berger <[email-masked]>
Date: Wed, 24 Feb 2016 06:54:41 -0500

Loa,

See inline below.

> with the alignment between this and what is in the OpenConfig documents?

In short : we're getting there:
- Their models are compatible with LNEs as they are ignorant of them, which 
is of course part of the value/strength of our proposed approach.
- WRT NIs, we have terminology and end structure alignment with 
draft-openconfig-rtgwg-network-instance and my hope is for the work to 
fully converge once Rob has time to spend on schema mount.

Also would be good to hear from the open config folks directly - - Rob and 
Anees, do you want to add anything?

Lou

> Rtg-dt-yang-arch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtg-dt-yang-arch
>

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Wed, 24 Feb 2016 16:04:03 +0000

NETMOD and I2RS WGs,

Note that this discussion is going in the rtgwg WG. We see it as mechanism
to support varying schema hierarchies for anything from a host or
linux-based access router all the way up to the largest carrier class
router while sharing the same YANG data models.

Thanks,
Acee

---

From: <[email-masked]>
Date: Thu, 25 Feb 2016 03:02:21 +0000

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 ?

Best Regards,

Stephane

-----Original Message-----
From: Rtg-dt-yang-arch [mailto:[email-masked]] 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:

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.

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-masked]
Reply-To: 	[email-masked]
To: 	[email-masked]

Abstract:

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.

_______________________________________________
I-D-Announce mailing list
[email-masked]
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

_________________________________________________________________________________________________________________________

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.

---

From: Lou Berger <[email-masked]>
Date: Thu, 25 Feb 2016 08:24:52 -0500

Stephane,
	See below.
On 02/24/2016 10:02 PM, [email-masked] 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. 

Agreed (I think).

> This
> pruning capacity does not seem to be taken into account yet.
> 

We tried to cover this point in sec 3.1:

   Resources assigned to the LNE will be represented in that LNE's
   resource modules. e.g., an LNE's interfaces module will contain the
   interfaces assigned to that LNE from the containing network-device.

and in sec 3.2:
   ... When accessing an LNE via an LNE's management interface, a
   network-device representation will be presented, but its scope will
   be limited to the specific LNE.  Normal YANG/NETCONF mechanisms,
   together with ietf-yang-library, can be used to identify the
   available modules.  Each supported module will be presented as a top
   level module.  Only LNE associated resources will be reflected in
   resource related modules, e.g., interfaces, hardware and perhaps QoS.
   From the management perspective, there will be no difference between
   the available LNE view (information) and an a physical network
   device.

I'm sure there's room for improvement here and any suggestions  would be
appreciated!

Thanks,
Lou

---

From: Jeff Tantsura <[email-masked]>
Date: Thu, 25 Feb 2016 17:55:31 +0000

Hi RTGWG,

Given the importance of the document, please do review and provide your comments, suggestions and in case you wouldn't support it as is  - what should be changed/missing.

Thanks!

Regards,
Jeff

> On Feb 23, 2016, at 6:40 PM, Lou Berger <[email-masked]> wrote:
> 
> 
> Hello,

---

From: Christian Hopps <[email-masked]>
Date: Thu, 25 Feb 2016 15:12:51 -0500

> On Feb 24, 2016, at 10:02 PM, [email-masked] wrote:
> 
> Hi Lou,
> 

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.

---

From: Loa Andersson <[email-masked]>
Date: Fri, 26 Feb 2016 15:04:04 +0800

Chis,

On 2016-02-26 04:12, Christian Hopps wrote:
> 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.

I always thought about a "model" as something "in the eye of the
beholder", a specific way you chose to view what is there, i.e. a LNE
model is an abstraction of the NE.

/Loa

-- 

Loa Andersson                        email: [email-masked]
Senior MPLS Expert                          [email-masked]
Huawei Technologies (consultant)     phone: +46 739 81 21 64