Subject: [netmod] opstate-reqs #7: Why limit scope to just IETF-defined modules

From: Kent Watsen <[email-masked]>
Date: Fri, 18 Sep 2015 21:56:09 +0000

Regarding https://github.com/netmod-wg/opstate-reqs/issues/7

  Jonathan> Why does 7(A) limit the scope to IETF-defined modules of
            others are now defining YANG modules?

  Benoit> Good point. We need to provide guidance for the other SDOs.

Current text says:

   7.  Ability for distinct modules to leverage a common model-structure
       A.  Scope is limited to IETF-defined modules
       B.  Multiple domain-specific trees are okay
       C.  Multiple namespaces are okay

Background:

  I pulled 7A from Andy's message here:

https://mailarchive.ietf.org/arch/msg/netmod/I6clHE2665C40taRZHi0CKLD46U

  and put a stake in the ground so that, if nothing else, it could
  be discussed...and here we are!

  FWIW, I wrote 7A this way because I didn't see how it can be
  enforced outside of the IETF.  But maybe that doesn't matter?
  Of course, we can have 6087bis guidance for other SDOs, but
  I didn't put that in the text.

Thoughts on how the text should be updated?

PS: Please Reply-All to the list rather than post comments to the GitHub
issue tracker.

Thanks,
Kent

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Sun, 20 Sep 2015 07:26:35 +0000

Hi,

There is a difference between providing guidance to other SDOs or organizations, and writing YANG modules for them. The role of the activity in the IETF should be to provide guidance, partly in informational RFCs, partly in the IETF YANG modules which can be used as design examples. We can also provide advice and review modules written out of the IETF as we do in the hackathons. We should not IMO write YANG modules for other SDOs or models for non-IETF protocols. 

Regards,

Dan

> -----Original Message-----
> From: netmod [mailto:[email-masked]] On Behalf Of Kent Watsen
> Sent: Saturday, September 19, 2015 12:56 AM
> To: [email-masked]
> Subject: [netmod] opstate-reqs #7: Why limit scope to just IETF-defined
> modules
> 
> 
> Regarding https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__github.com_netmod-2Dwg_opstate-
> 2Dreqs_issues_7&d=BQICAg&c=BFpWQw8bsuKpl1SgiZH64Q&r=I4dzGxR31O
> cNXCJfQzvlsiLQfucBXRucPvdrphpBsFA&m=yi1uYR3VJD4JrRa5l8jqBkjtxrsJuHg
> 5dcsU1w-nzZQ&s=kj8v5eC_6IVKqyfqvnd-CDGFXN97L8I02gRhUeBY278&e=
> 
> 
> https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__mailarchive.ietf.org_arch_msg_netmod_I6clHE2665C40taRZHi0CKLD46U
> &d=BQICAg&c=BFpWQw8bsuKpl1SgiZH64Q&r=I4dzGxR31OcNXCJfQzvlsiLQfu
> cBXRucPvdrphpBsFA&m=yi1uYR3VJD4JrRa5l8jqBkjtxrsJuHg5dcsU1w-
> nzZQ&s=RbIG290qfYTtkdYRghpbUXmzbJCGclTOYnPhBC1o2nk&e=
> 
> PS: Please Reply-All to the list rather than post comments to the GitHub issue
> tracker.
> 
> 
> Thanks,
> Kent
> 
> _______________________________________________
> netmod mailing list
> [email-masked]
> https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__www.ietf.org_mailman_listinfo_netmod&d=BQICAg&c=BFpWQw8bsuK
> pl1SgiZH64Q&r=I4dzGxR31OcNXCJfQzvlsiLQfucBXRucPvdrphpBsFA&m=yi1uY
> R3VJD4JrRa5l8jqBkjtxrsJuHg5dcsU1w-
> nzZQ&s=aLfNVEmox9KUVrZVBBSrrpoW6R3mScbV6TfvudUesa0&e=

---

From: Robert Wilton <[email-masked]>
Date: Mon, 21 Sep 2015 10:34:39 +0100

Hi,

I suggest changing the wording for A and adding D:

    7.  Ability for distinct modules to leverage a common model-structure
        A.  Scope is limited to providing a general model-structure only
        B.  Multiple domain-specific trees are okay
        C.  Multiple namespaces are okay
        D.  The model-structure may be used or extended by other organizations.

Justifications for (A):
  - Limiting the scope to IETF-defined modules almost implies that 
'ietf' would end up in the path (which would be wrong/unnecessary).
  - Clients don't care which SDO defines the modules for the protocols 
they use, they just want a coherent organization of modules.
  - General structure only to limit the scope because trying to 
precisely place every protocol/feature is likely to be fragile in the 
face of future changes.

Justifications for (D):
  - To suggest and encourage other SDOs to use the same structure, but 
cannot mandate what they do.

Thanks,
Rob

On 18/09/2015 22:56, Kent Watsen wrote:
> https://www.ietf.org/mailman/listinfo/netmod
>

---

From: Kent Watsen <[email-masked]>
Date: Mon, 21 Sep 2015 19:09:39 +0000

Thanks Robert, but I think I like Benoit's edit more.  Are you OK with it
as well?

PS: I've moved this issue to the VERIFY state.

Thanks,
Kent

---

From: Andy Bierman <[email-masked]>
Date: Mon, 21 Sep 2015 12:28:58 -0700

Hi,

I do not think the issue of scope is being considered very carefully.

IMO the solutions being proposed are extremely router-centric.
(e.g., most NETCONF servers DO NOT have any virtual servers within them).

The larger the scope, the more concern I have that
the IETF will be pushing expensive solutions on platforms
that don't have any of the "problems" in the first place.

Andy

---

From: Robert Wilton <[email-masked]>
Date: Tue, 22 Sep 2015 10:23:03 +0100

Hi Kent,

Yes, fine with me.

BTW, please can I check that I correctly understand B and C.

Am I right in understanding that B means that multiple top level trees 
would be acceptable, and C means that having the structure defined in 
multiple modules would be acceptable?

Thanks,
Rob

---

From: Robert Wilton <[email-masked]>
Date: Tue, 22 Sep 2015 11:00:07 +0100

Hi Andy,

Please can you clarify. Is your concern specifically with requirement 
7?  Or the full set of requirements in 
draft-chairs-netmod-opstate-reqs-00<https://datatracker.ietf.org/doc/draft-chairs-netmod-opstate-reqs/>?

Thanks,
Rob

On 21/09/2015 20:28, Andy Bierman wrote:
> On Mon, Sep 21, 2015 at 12:09 PM, Kent Watsen <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>
>     On 9/21/15, 5:34 AM, "Robert Wilton" <[email-masked]
>     <mailto:[email-masked]>> wrote:
>
>     >Hi,
>     >
>     >> [email-masked] <mailto:[email-masked]>
>     [email-masked] <mailto:[email-masked]>

---

From: Kent Watsen <[email-masked]>
Date: Tue, 22 Sep 2015 12:45:02 +0000

>Yes, fine with me.

Excellent!

>multiple modules would be acceptable?

Yes, this is what is intended, do you think the text needs to be clarified?

Thanks,
Kent

---

From: Robert Wilton <[email-masked]>
Date: Tue, 22 Sep 2015 14:25:15 +0100

> Yes, this is what is intended, do you think the text needs to be clarified?
Personally, I don't mind.

For B, I presume that it is both multiple top level trees domain 
specific trees that are being considered, and also potentially multiple 
domain specific trees lower down the hierarchy (e.g. under 
if:interfaces).  If so I think that the current text for B is reasonable.

For C, possibly the following text helps clarify?

OLD:

   7.  Ability for distinct modules to leverage a common model-structure
        A.  Focus on the IETF-defined modules, and ideally provides guidance to other SDOs
        B.  Multiple domain-specific trees are okay
        C.  Multiple namespaces are okay

NEW:

   7.  Ability for distinct modules to leverage a common model-structure
        A.  Focus on the IETF-defined modules, and ideally provides guidance to other SDOs
        B.  Multiple domain-specific trees are okay
        C.  Model-structure may be defined in multiple modules with distinct namespaces.

Thanks,
Rob

---

From: Andy Bierman <[email-masked]>
Date: Tue, 22 Sep 2015 06:38:44 -0700

On Tue, Sep 22, 2015 at 3:00 AM, Robert Wilton <[email-masked]> wrote:

> Hi Andy,
>
> Please can you clarify. Is your concern specifically with requirement 7?
> Or the full set of requirements in draft-chairs-netmod-opstate-reqs-00
> <https://datatracker.ietf.org/doc/draft-chairs-netmod-opstate-reqs/>?
>
>

My concern is the impact on implementations that do not contain virtual
servers
or do not even contain routers. If the scope of a solution is only routers,
then
it does not matter how router-centric the solution.  But if the scope is
every
device that uses YANG, then it does matter.

To be quite specific:
   - most devices do not require long time intervals  to apply
configuration so any solution
     to identify intended vs. applied config is a waste of resources

  - most devices do not contain virtual servers so placing the data models
in a framework
    for virtualization is a waste of resources

A good engineering solution would only use engineering resources, device
resources,
and/or network resources on platforms that actually have these problems.
It's the  difference between MAY leverage a common model-structure and MUST
leverage
a common model-structure. (Something IETFers should understand).

If the solution really is MAY, then I have no concerns, but I know YANG does
not actually support that, and it probably never will.  Relocatable YANG
would
be rather complicated, so that is not an option at this time.

Thanks,

Andy

>> On 9/21/15, 5:34 AM, "Robert Wilton" < <[email-masked]>
>> [email-masked]> wrote:
>>
>> >Hi,
>> >

---

From: Dean Bogdanovic <[email-masked]>
Date: Tue, 22 Sep 2015 14:39:20 -0400

Andy,

Mobile operators are sharing infrastructure more and more. They are even now considering sharing spectrum. Today there are already use cases where Radio Access Network (RAN) is shared between multiple operators and they are interested in sharing core resources as well. I can see multiple NETCONF servers running on Mobile Switching Center (MSC), server per each virtual instance for tenant.

Dean

> On Sep 22, 2015, at 9:38 AM, Andy Bierman <[email-masked]> wrote:
> 
> 
> 
> On Tue, Sep 22, 2015 at 3:00 AM, Robert Wilton <[email-masked] <mailto:[email-masked]>> wrote:
> Hi Andy,
> 
> Please can you clarify. Is your concern specifically with requirement 7?  Or the full set of requirements in draft-chairs-netmod-opstate-reqs-00 <https://datatracker.ietf.org/doc/draft-chairs-netmod-opstate-reqs/>?
> 
> 
> 
> My concern is the impact on implementations that do not contain virtual servers
> or do not even contain routers. If the scope of a solution is only routers, then
> it does not matter how router-centric the solution.  But if the scope is every
>    - most devices do not require long time intervals  to apply configuration so any solution
>   - most devices do not contain virtual servers so placing the data models in a framework
> A good engineering solution would only use engineering resources, device resources,
> It's the  difference between MAY leverage a common model-structure and MUST leverage
> not actually support that, and it probably never will.  Relocatable YANG would
>> On Mon, Sep 21, 2015 at 12:09 PM, Kent Watsen <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> On 9/21/15, 5:34 AM, "Robert Wilton" < <mailto:[email-masked]>[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> >Hi,
>> >
>> >> Regarding https://github.com/netmod-wg/opstate-reqs/issues/7 <https://github.com/netmod-wg/opstate-reqs/issues/7>
>> >>
>> >>
>> >> https://mailarchive.ietf.org/arch/msg/netmod/I6clHE2665C40taRZHi0CKLD46U <https://mailarchive.ietf.org/arch/msg/netmod/I6clHE2665C40taRZHi0CKLD46U>
>> >>
>> >> https://www.ietf.org/mailman/listinfo/netmod <https://www.ietf.org/mailman/listinfo/netmod>
>> >>
>> >
>> 
>> https://www.ietf.org/mailman/listinfo/netmod <https://www.ietf.org/mailman/listinfo/netmod>
>> 
> 
>

---

From: Andy Bierman <[email-masked]>
Date: Tue, 22 Sep 2015 11:46:39 -0700

On Tue, Sep 22, 2015 at 11:39 AM, Dean Bogdanovic <[email-masked]>
wrote:

> Andy,
>
> Mobile operators are sharing infrastructure more and more. They are even
> now considering sharing spectrum. Today there are already use cases where
> Radio Access Network (RAN) is shared between multiple operators and they
> are interested in sharing core resources as well. I can see multiple
> NETCONF servers running on Mobile Switching Center (MSC), server per each
> virtual instance for tenant.
>
>
That's all fine but it does not alter my opinion at all that platforms that
do not need this feature should not be impacted by it.  If that means that
YANG will "fork" into a solution for big routers and a different solution
for not-a-routers, then that's fine.  The market can decide better than the
IETF anyway.

Dean

Andy

---

From: Dean Bogdanovic <[email-masked]>
Date: Tue, 22 Sep 2015 14:53:49 -0400

> On Sep 22, 2015, at 2:46 PM, Andy Bierman <[email-masked]> wrote:
> 
> 
> 
> On Tue, Sep 22, 2015 at 11:39 AM, Dean Bogdanovic <[email-masked] <mailto:[email-masked]>> wrote:
> Andy,
> 
> for not-a-routers, then that's fine.  The market can decide better than the IETF anyway.

To certain extent agree with your comment. But when you are talking about forking YANG for different domains, shouldn’t we try to have features in YANG and then implementers can decide which features they want to use? And then market can decide, which implementations they like the best?

Dean

> 
> 
> Dean
> 
> Andy
>  
> 
>> On Sep 22, 2015, at 9:38 AM, Andy Bierman <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> 
>>

---

From: Andy Bierman <[email-masked]>
Date: Tue, 22 Sep 2015 12:40:21 -0700

On Tue, Sep 22, 2015 at 11:53 AM, Dean Bogdanovic <[email-masked]>
wrote:

> To certain extent agree with your comment. But when you are talking about
> forking YANG for different domains, shouldn’t we try to have features in
> YANG and then implementers can decide which features they want to use? And
> then market can decide, which implementations they like the best?
>
>
OK - I guess we are in agreement.

There is nothing particularly difficult about extracting text from a YANG
module
and pasting it into a different YANG module.  In my experience, vendors
are not willing to spend unlimited resources to comply to a standard.
If the standard does not fit, they will use the parts that do fit and figure
something else out for the rest.

E.g., if a YANG module is deemed too heavy-weight because it assumes
a set of use-cases that do not apply to a platform, it will be quite easy
to use a different YANG module.  Market forces will not sustain false
commonality.

Dean
Andy

>>> 7?  Or the full set of requirements in draft-chairs-netmod-opstate-reqs-00

---

From: Kent Watsen <[email-masked]>
Date: Wed, 23 Sep 2015 14:18:47 +0000

>        C.  Model-structures may be defined in multiple modules with
>distinct namespaces.

If no one objects within 5 days, we will move forward with the NEW text
listed above for requirement #7.

Thanks,
Kent

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 24 Sep 2015 11:16:50 +0200

> Mobile operators are sharing infrastructure more and more. They are even now considering sharing spectrum. Today there are already use cases where Radio Access Network (RAN) is shared between multi…

This sounds like full virtualization in the sense that each tenant
sees his own view of the world. This is fine and does not require any
changes to any of the existing data models. We are running NETCONF
servers on virtual machines and all is just fine.

The discussion (as I understand it) is whether multiple networking
stacks within a single operating system is something that needs to be
supported universally by mandating that every data model path includes
elements that allow to select the network stack (or namespace) one
talks about.

And in Linux, there are actually several namespaces (not just network
stack namespaces) that you can combine more or less freely, giving you
so called Linux containers (where the isolation is so complete that
running a NETCONF server inside a container is just fine again) and
the like but it is a whole spectrum of possible combinations in this
space.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>