Re: [netmod] tracking new YANG language issues

[Giles Heron]

On 1 Sep 2015, at 18:30, Juergen Schoenwaelder 
 wrote:
> 
> On Tue, Sep 01, 2015 at 05:58:59PM +0100, Giles Heron wrote:
>> On 1 Sep 2015, at 17:47, Juergen Schoenwaelder 
>>  wrote:
>>> 
>>> I suggest people write I-Ds if they have any far reaching ideas.
>> 
>> I think GitHub would be better.  The overhead is much lower than writing a 
>> draft.
>> 
> 
> IETF processes usually starts with ideas presented in I-Ds. I do not
> care much which tools people use to produce I-Ds.

sure, that is the process in general.  But I’m unconvinced that it’s the right 
way to proceed with YANG.  E.g. we used a numbered of issues for YANG 1.1.  So 
why not a numbered list of suggestions for YANG 2.0?

Giles

> /js
> 
> -- 
> Juergen Schoenwaelder   Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
> Fax:   +49 421 200 3103 

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] tracking new YANG language issues

[Juergen Schoenwaelder]

On Tue, Sep 01, 2015 at 06:45:55PM +0100, Giles Heron wrote:
> On 1 Sep 2015, at 18:30, Juergen Schoenwaelder 
>  wrote:
> > 
> > On Tue, Sep 01, 2015 at 05:58:59PM +0100, Giles Heron wrote:
> >> On 1 Sep 2015, at 17:47, Juergen Schoenwaelder 
> >>  wrote:
> >>> 
> >>> I suggest people write I-Ds if they have any far reaching ideas.
> >> 
> >> I think GitHub would be better.  The overhead is much lower than writing a 
> >> draft.
> >> 
> > 
> > IETF processes usually starts with ideas presented in I-Ds. I do not
> > care much which tools people use to produce I-Ds.
> 
> sure, that is the process in general.  But I’m unconvinced that it’s the 
> right way to proceed with YANG.  E.g. we used a numbered of issues for YANG 
> 1.1.  So why not a numbered list of suggestions for YANG 2.0?
>

The formal answer is that the WG is charted to do YANG 1.1 and not
2.0. The other answer is that (a) collecting issues is easy, (b)
finding agreement on issues is difficult, (c) getting the final text
written and _all the details that pop up worked out_ is very hard
work. Unfortunately, you see many people working on (a), less people
on (b) and finally very few doing (c).

/js

-- 
Juergen Schoenwaelder   Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103 

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] tracking new YANG language issues

[Juergen Schoenwaelder]

On Tue, Sep 01, 2015 at 05:58:59PM +0100, Giles Heron wrote:
> On 1 Sep 2015, at 17:47, Juergen Schoenwaelder 
>  wrote:
> > 
> > I suggest people write I-Ds if they have any far reaching ideas.
> 
> I think GitHub would be better.  The overhead is much lower than writing a 
> draft.
>

IETF processes usually starts with ideas presented in I-Ds. I do not
care much which tools people use to produce I-Ds.

/js

-- 
Juergen Schoenwaelder   Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103 

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] tracking new YANG language issues

[Nadeau Thomas]

> On Sep 1, 2015:1:58 PM, at 1:58 PM, Juergen Schoenwaelder 
>  wrote:
> 
> On Tue, Sep 01, 2015 at 06:45:55PM +0100, Giles Heron wrote:
>> On 1 Sep 2015, at 18:30, Juergen Schoenwaelder 
>>  wrote:
>>> 
>>> On Tue, Sep 01, 2015 at 05:58:59PM +0100, Giles Heron wrote:
 On 1 Sep 2015, at 17:47, Juergen Schoenwaelder 
  wrote:
> 
> I suggest people write I-Ds if they have any far reaching ideas.
 
 I think GitHub would be better.  The overhead is much lower than writing a 
 draft.
 
>>> 
>>> IETF processes usually starts with ideas presented in I-Ds. I do not
>>> care much which tools people use to produce I-Ds.
>> 
>> sure, that is the process in general.  But I’m unconvinced that it’s the 
>> right way to proceed with YANG.  E.g. we used a numbered of issues for YANG 
>> 1.1.  So why not a numbered list of suggestions for YANG 2.0?
>> 
> 
> The formal answer is that the WG is charted to do YANG 1.1 and not
> 2.0. The other answer is that (a) collecting issues is easy, (b)
> finding agreement on issues is difficult, (c) getting the final text
> written and _all the details that pop up worked out_ is very hard
> work. Unfortunately, you see many people working on (a), less people
> on (b) and finally very few doing (c).
> 
> /js

Juergen is technically correct, although conversations with the AD have 
started about adjusting our charter to facilitate a 2.0 rev of Yang. If you 
have input/opinions around whether or not we should
embark on this, I suggest sending a note to Benoit.

I am also collecting issues to publish into a draft, that will document 
these problems right now. 
If anyone has issues they wish to document and want to contribute, please 
contact me offline. 

—Tom



> 
> -- 
> Juergen Schoenwaelder   Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
> Fax:   +49 421 200 3103 
> 
> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Motivations for Structuring Models

[Randy Presuhn]

Hi -

>From: "Alexander Clemm (alex)" 
>Sent: Sep 1, 2015 2:21 PM
>To: Randy Presuhn , "netmod@ietf.org" 
>
>Subject: RE: [netmod] Motivations for Structuring Models
>
>Hi Randy,
>
>GDMO had some very powerful concepts.  The ability to separate
>definition hierarchy and containment hierarchy is indeed very
>powerful.  In many ways, it was ahead of its time.  The problem
>I see is that in the context of YANG (much simpler), I don't
>think the same concept of name bindings is applicable, really.

Agreed.  At best it would probably be an ugly bolt-on;
some of the concerns it is intended to address are ones
that folks in the Netconf universe have tended to declare
out-of-scope, though as more people use these tools we'll
probably encounter more calls to revisit those long-held
assumptions.

> The difference is that in GDMO, MOC definitions did not make
> any statement about naming/ containment - this made it possible
> to separate containment out from other aspects of the model,
> cleanly, as they were orthogonal concepts.  In YANG, however,
> the definition of the containment structure is very much at
> the core of what is being defined as part of the model.

That's a polite way of saying the difficulty is architectural,
and *completely* fixing it would likely be disruptive.  I
think you're right.

>  This is in part what makes it simple (and IMHO arguably
> also easier to read and consume - name bindings were arguably
> "harder to follow"), but there are some limitations that we
> are starting to bump into.

They're essentially the same problems as arise with naming
in SNMP-land, with the same causes and consequences.

> I think it is possible to address these (allowing the
> definition of mount points is one proposal), but the
> mechanism will need to be different from name bindings
> simply because the MOCs being linked are not defined "on
> their own", but as part of containment relationships
> intrinsically tied to their definitions.

I agree a mechanism to accomplish something like it will
likely be quite different.  Name bindings rely on a particular
characteristics of the metamodel and have specific consequences
for the management protocol, and both sets of assumptions don't
hold true in netconf/yang-land.  Trying to ape GDMO does not
seem like a productive route to me, given where Yang already
finds itself.

As long as naming is so closely bound to the definition,
however, use of the models is constrained in unhelpful ways.
Using mount points, at least as they've been formulated so far,
only addresses parts of the problem.  Whether that's going to
be good enough remains to be seen.  Without mount points or
something similar, what we currently have is only about as broken
as SNMP/SMI, and the industry got a lot of mileage out of that.

I suspect the debate over mount points will be the beginning of
netconf's counterpart to the "subagent wars" where the issue was
not so much one of "can this be made to work with(out) this
technology increment" than one of "what is the impact of this
technology increment on our overall development/deployment/operational
cost".

Randy

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] tracking new YANG language issues

[Alexander Clemm (alex)]

FWIW, I prefer I-D as well.  This is a very well established and very well 
understood process.  One advantage is that things are very easy to find (from 
the documents page).  Regardless which way is chosen, having the IETF 
datatracker page as an entry point from where to find stuff is IMHO a must.
--- Alex

-Original Message-
From: netmod [mailto:netmod-boun...@ietf.org] On Behalf Of Juergen Schoenwaelder
Sent: Tuesday, September 01, 2015 10:58 AM
To: Giles Heron 
Cc: Randy Presuhn ; netmod@ietf.org
Subject: Re: [netmod] tracking new YANG language issues

On Tue, Sep 01, 2015 at 06:45:55PM +0100, Giles Heron wrote:
> On 1 Sep 2015, at 18:30, Juergen Schoenwaelder 
>  wrote:
> > 
> > On Tue, Sep 01, 2015 at 05:58:59PM +0100, Giles Heron wrote:
> >> On 1 Sep 2015, at 17:47, Juergen Schoenwaelder 
> >>  wrote:
> >>> 
> >>> I suggest people write I-Ds if they have any far reaching ideas.
> >> 
> >> I think GitHub would be better.  The overhead is much lower than writing a 
> >> draft.
> >> 
> > 
> > IETF processes usually starts with ideas presented in I-Ds. I do not 
> > care much which tools people use to produce I-Ds.
> 
> sure, that is the process in general.  But I’m unconvinced that it’s the 
> right way to proceed with YANG.  E.g. we used a numbered of issues for YANG 
> 1.1.  So why not a numbered list of suggestions for YANG 2.0?
>

The formal answer is that the WG is charted to do YANG 1.1 and not 2.0. The 
other answer is that (a) collecting issues is easy, (b) finding agreement on 
issues is difficult, (c) getting the final text written and _all the details 
that pop up worked out_ is very hard work. Unfortunately, you see many people 
working on (a), less people on (b) and finally very few doing (c).

/js

-- 
Juergen Schoenwaelder   Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103 

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Motivations for Structuring Models

[Alexander Clemm (alex)]

Hi Randy,

GDMO had some very powerful concepts.  The ability to separate definition 
hierarchy and containment hierarchy is indeed very powerful.  In many ways, it 
was ahead of its time.  The problem I see is that in the context of YANG (much 
simpler), I don't think the same concept of name bindings is applicable, 
really.  The difference is that in GDMO, MOC definitions did not make any 
statement about naming/ containment - this made it possible to separate 
containment out from other aspects of the model, cleanly, as they were 
orthogonal concepts.  In YANG, however, the definition of the containment 
structure is very much at the core of what is being defined as part of the 
model.  This is in part what makes it simple (and IMHO arguably also easier to 
read and consume - name bindings were arguably "harder to follow"), but there 
are some limitations that we are starting to bump into.  I think it is possible 
to address these (allowing the definition of mount points is one proposal), but 
the mechan
 ism will need to be different from name bindings simply because the MOCs being 
linked are not defined "on their own", but as part of containment relationships 
intrinsically tied to their definitions.

--- Alex

-Original Message-
From: netmod [mailto:netmod-boun...@ietf.org] On Behalf Of Randy Presuhn
Sent: Monday, August 31, 2015 12:32 PM
To: netmod@ietf.org
Subject: Re: [netmod] Motivations for Structuring Models

Hi -

>From: Ladislav Lhotka 
>Sent: Aug 31, 2015 8:04 AM
>To: Randy Presuhn , netmod@ietf.org
>Subject: Re: [netmod] Motivations for Structuring Models
...
>> What GDMO did was to use a separate "NAME BINDING" construct to 
>> specify contexts in which instances might show up, allowing instances 
>> to be put in places that weren't even imagined when the original 
>> class definition was written.  Name bindings could be standardized, 
>> or be vendor or even product-specific, allowing the simplicity or 
>> complexity of a given system's instance tree to reflect the actual 
>> simplicity or complexity of that system, rather than requiring all 
>> systems to be structured for the worst case.
>
>How could this be expressed in YANG terms? (I tried to figure it out 
>myself but I unfortunately couldn't make any sense of sec. 8.6 in CCITT 
>Recommendation X.722).

A key concept of naming in that universe is "containment".
As with X.500 Directory or modern file systems, object instances are identified 
by their "distinguishing attribute(s)" within the context of a containing 
object.  The containment hierarchy within a given system generally reflects 
physical or logical containment.

Perhaps an example of how it could be used would help.
Suppose I've defined a "cpu" class and a "motherboard" class.
Further suppose that the "cpu" class has an attribute called "processorId" 
which is guaranteed to be unique within any naming context in which one might 
find more than one processor as immediate siblings. To say that a cpu could be 
identified
(named) within the context of a motherboard, one could say something like

cpuOfMotherboard NAME BINDING
 SUBORDINATE OBJECT CLASS cpu AND SUBCLASSES;
 NAMED BY SUPERIOR OBJECT CLASS motherboard AND SUBCLASSES;
 WITH ATTRIBUTE processorId;
 REGISTERED AS blah ;

This says that if one has located an instance of the motherboard class or any 
of its subclasses, instances of the cpu class that are immediately contained by 
it could be named within that context by their "processorId" attribute.  (A 
meta-model requirement is that any instantiable object class needs to have at 
least one attribute suitable for use in naming.)

Later, say we find that we need to model line cards with cpus, and those line 
cards (for whatever reason) are not derived from the motherboard class.  But we 
can still use the cpu class to manage those processors by adding another name 
binding:

cpuOfLinecard NAME BINDING
 SUBORDINATE OBJECT CLASS cpu AND SUBCLASSES;
 NAMED BY SUPERIOR OBJECT CLASS lineCard AND SUBCLASSES;
 WITH ATTRIBUTE processorId;
 REGISTERED AS blahblah ;

The point is that the class definition does not by itself determine where 
object instances might appear in a managed system; the supported name bindings 
determine where instances can be, whether (and how) they are created, and 
whether (and how) they can be deleted.

Is that a bit clearer?  No tidy way to do all of this in Yang-land is apparent 
to me - the (meta-) modeling assumptions seem too far removed, particularly 
with regard to inheritance and containment - but someone more creative than me 
might figure out how to do it.  But the point is not to ape GDMO.  The point is 
that this capability was included in that world to address real-world modeling 
needs, and we're seeing those same needs resurfacing here.

Randy

___
netmod mailing list
netmod@ietf.org

[netmod] tracking new YANG language issues

[Kent Watsen]

[chair hat on, changed subject line]



On 9/1/15, 11:05 AM, "Lou Berger"  wrote:

>This is exactly the (sub) model reuse issue I was getting at in
>http://www.ietf.org/mail-archive/web/netmod/current/msg13357.html
>
>I think this new capability (i.e., the ability to define complex,
>augmentable and reusable structures that are "included" when defining
>more complex models) would be a good new issue to track.
>
>Lou


Yes, we need to start tracking new YANG language issues like this one.
How/where is the question...

First off, anything that can be implemented using a YANG language
extension should be submitted as a draft and released that way.
Everything else is essentially destined for a 6020bis-bis - agreed?

The big question, which may not even have to be answered immediately, is
if 6020bis-bis is YANG 1.2 or a 2.0.  That is, will we confine ourselves
to backwards compatibility or not.

Personally, since I don't have a sense for how much 2.0 there might be, I
think it would be interesting just to collect the YANG 2.0 ideas now.  It
would be good to see what all else is out there besides the I2RS and
OpenConfig stuff we already know about.

Thoughts? - how should we proceed?  - use GitHub issue tracker?

Kent



___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

[netmod] New Yang issue? (was Re: Motivations for Structuring Models)

[Lou Berger]

On 8/31/2015 11:04 AM, Ladislav Lhotka wrote:
>> Randy Presuhn  writes:
>> ...
>> Life is such that once a resource has been modeled, it will be
>> used/re-used/embedded in systems in ways in which its designers
>> couldn't be expected to imagine.  A consequence of this is that
>> if instance naming is completely locked down when the management
>> interface for a resource is first defined (as it is in SNMP) then
>> all sorts of peculiar hacks will be needed to deal with, for example,
>> virtual routers.  Unfortunately, an SNMP/SMI-like mindset is so
>> pervasive that folks seem to overlook that there are other ways
>> to deal with this situation.
>>
>> What GDMO did was to use a separate "NAME BINDING" construct to
>> specify contexts in which instances might show up, allowing
>> instances to be put in places that weren't even imagined when
>> the original class definition was written.  Name bindings could
>> be standardized, or be vendor or even product-specific, allowing
>> the simplicity or complexity of a given system's instance tree
>> to reflect the actual simplicity or complexity of that system,
>> rather than requiring all systems to be structured for the
>> worst case.
> 
> How could this be expressed in YANG terms? (I tried to figure it out
> myself but I unfortunately couldn't make any sense of sec. 8.6 in CCITT
> Recommendation X.722).
> 

This is exactly the (sub) model reuse issue I was getting at in
http://www.ietf.org/mail-archive/web/netmod/current/msg13357.html

I think this new capability (i.e., the ability to define complex,
augmentable and reusable structures that are "included" when defining
more complex models) would be a good new issue to track.

Lou


___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] logical systems model

[Lou Berger]

Alex,

Thanks for the response - see below.

I think the additions of 'mounts' that are themselves configurable (with
support for local and recursion/cascades) is a really interesting and
may turn out to be very useful/important.  Although it does add its own
complexity.

That said, there are some specifics that will need to be addressed to
use this approach: e.g. to quote:
Mounted data is "read-only" data.
YANG-Mount does not extend towards RPCs that are defined as
   part of YANG modules whose contents is being mounted.
YANG-Mount does not extend towards notifications.
Perhaps most of these limitations can be relaxed for local mounts.

Also handling when a device/server doesn't support local mounts (or is
invalid)

On 8/28/2015 6:16 PM, Alexander Clemm (alex) wrote:
> Hi Lou,
> 
>  
> 
> Andy basically already provided the answer, but just to add to your
> question: yes, there is an example in the draft (appendix A). 
> 

Actually, I was looking for an example on the server/device.  I do like
your example though, as it shows *exactly* the case of a sibling of
/device (i.e, topologies).

Thanks,
Lou

>...

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

[netmod] minutes of the NETMOD 2015-08-31 virtual interim meeting

[Juergen Schoenwaelder]

Hi,

attached are the minutes of the 2015-03-31 virtual interim meeting.
Please let me know if something needs fixing.

You can find all the virtual interim meeting minutes next to the YANG
1.1 issue list in the NETMOD WG subversion repository:

 http://svn.tools.ietf.org/svn/wg/netmod/yang-1.1/

/js

-- 
Juergen Schoenwaelder   Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103 
=
NETCONF Data Modeling Language WG (netmod)
19th YANG 1.1 Virtual Interim
Monday, August 31st, 2015, 17:00-18:00 CEST
Minutes Juergen Schoenwaelder
=

* Participants

  DB = Dean Bogdanovic
  JS = Juergen Schoenwaelder
  KW = Kent Watsen
  LL = Ladislav Lhotka
  MB = Martin Bjorklund
  MJ = Mahesh Jethanandani

* Definition of 'data tree'

  One option is to define 'data tree' to capture the choice currently
  embedded in the xpath expression evaluation section. This will make
  the xpath section way simpler. It is unclear whether this also
  brings simplification at other places.
   
  Is it a goal to remove any reference to  in normative
  text? Note that RESTCONF does not have  but instead a
  unified datastore (but it seems this got lately changed again).
   
  Observation: YANG does not define terms like 'datastore' or
  'configuration datastore' or . RFC 6020 is silently
  assuming the import of these terms from RFC 6241.
   
  MB: I suggest to import the necessary terms.
  JS: I agree that key terms should be defined in the document or
  the definition should be imported. In an ideal world, we would have
  an architecture document defining architectural concepts and then
  YANG and protocol specifications would import from there. We can
  only slowly move to an ideal world in the IETF.

  KW: Should we refer to an 'intended' configuration datastore instead of
  the running configuration datastore?
  LL: Perhaps 'active' configuration with 'active' meaning 'running' on a
  traditional NETCONF server?
   
  KW: running + ephemeral => intended => applied
   
  MB: YANG 1.0 clearly uses running. If we create a new term, it must
  resolve to  in NETCONF.
   
  LL: The issue for me is config false node refering to a config true
  node. With possible future extensions of NETCONF (or RESTCONF),
  referring to  may not be useful anymore.
   
  MB: The notifications in the SMIv2 mapping to YANG make use of
  references to  datastore content.
  JS: But this is accomplished via leafrefs, not via xpath expressions.
   
  Resolution: We keep the choice text in xpath section. We will replace
   with 'running configuration datastore'.
   
  What about data tree? It seems to make sense to expand its
  definition but we need to figure out where the expansion would not
  be OK. LL volunteers to take a look. MB will do this as well.
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] logical systems model

[Lou Berger]

On August 28, 2015 5:33:41 PM Andy Bierman  wrote:

> On Fri, Aug 28, 2015 at 1:31 PM, Lou Berger  wrote:
>
>> On August 28, 2015 3:53:33 PM Andy Bierman  wrote:
>>
>> > On Fri, Aug 28, 2015 at 11:31 AM, Alexander Clemm (alex)
> >
>> > wrote:
>> >
>> >>
>> >>
>> >> -Original Message-
>> >> From: netmod [mailto:netmod-boun...@ietf.org] On Behalf Of Ladislav
>> Lhotka
>> >> Sent: Friday, August 28, 2015 4:31 AM
>> >> To: Martin Bjorklund ; a...@yumaworks.com
>> >> Cc: netmod@ietf.org
>> >> Subject: Re: [netmod] logical systems model
>> >>
>> >>
>> >> .
>> >> 
>> >>
>> >> NACM, as well as all other modules we have, is based on the assumption
>> of
>> >> a single managed device.
>> >>
>> >> I think it is a typical trend that what once was a single instance
>> becomes
>> >> an array. If we did ietf-routing 20 years ago, there would probably be
>> no
>> >> routing-instance list.
>> >>
>> >> So I think it is a real problem that we can't migrate from a container
>> to
>> >> a list and reuse the container's data model. Groupings might help
>> somewhat
>> >> but they are still not fully reusable, if, for example, they contain
>> >> absolute references.
>> >>
>> >> Lada
>> >> 
>> >>
>> >> One comment, if you forgive the pitch, but this problem / use case
is by
>> >> the way exactly one of the reasons for mounting, which allows you to
>> >> introduce and impose an additional structure on top of an existing
>> >> structure, and "insert" the existing structure into it.  Augmentations
>> etc
>> >> can only add below the hierarchy, there is no way we can put a new
>> >> container or list or whatever on top of an existing structure (without
>> >> replicating the existing structure in a duplicate model), but
peer-mount
>> >> lets you do that.  One use case used in Open Daylight involves
>> organizing/
>> >> inserting device-level information into a network inventory, which is
>> >> basically imposed "on top".
>> >>
>> >>
>> >
>> > I thing YANG Mount would be the best way to solve this problem.
>> > It provides a standard way to do "chroot" and it is flexible.
>> > The mechanics of a "datastore within a datastore" are the
>> > same and independent of the source of the data (local,
>> > remote, virtual, etc.)
>> >
>>
>> So I think an example of how you see this working would helpful.
>>
>> Can one of you give an example of how this word work for a device (which
>> may be physical or virtual) that allocates done resources, say interfaces
>> to one logical entity (router, system, etc) and other resources to a
second
>> entity? And of course I want to manage all with yang and the first and
>> second (sub) entity must be completely independent and ignorant of each
>> other.
>>
>
> Is there an example of this in your draft?
>

Sure, this is what logical-network-element and device view is all about
and the example is actually in the slides from the last ietf that I
pointed to a couple of weeks ago.

> Do you mean an example of what the controller looks like?

No, the server/device.

> Maybe the analogy to chroot is not  universally understood.
>
> The logical system knows only about itself:
>
> /interfaces
> /system
>
> The / node is represented by  or  or  in the
protocol.
>
>
>
>
>  
>  
>   
>
>
> Each logical system can have its own "eth0" interface or whatever.
> They are mapped to real interfaces in the physical system.
>

It's the control of this mapping that is part of the question. ..

BTW this "physical " system may itself be a virtual device (e.g., VM w/
NFV) . ..

> All operations on the logical system are validated against its own
> virtual datastore.  YANG validation does not work on individual array
> slices -- it only applies to an entire datastore.
>
> On the physical server there needs to be a data model to manage the
> logical servers (as Martin suggested).
>
>   <--- root on PHY server
>   <--- contains the real interfaces,
> including eth23
>
>   
>  vs1
>  
>  eth23
>  eth0
>  
>  
> <--- YANG mount point (virtual
> server root)
> 
>
>   eth0
> 
>
> 
> 
>  
>
> 
>   
>
> On the physical system, the virtual roots are within list entries,
> not at the top of the tree.  The physical server data and/or any
> of the logical servers can be accessed at once.

Okay, so our logical-network-element is basically your virtual-server.root

Think this is an interesting approach that is worth looking at to
address the logical-network-element   (virtual
router/chassis/fabric/) problem.  I like that it
can go n-levels deep as it is basically recursive.  The challenge will
be dealing with mapping for every top level module