Subject: Re: [netmod] WG Last Call for draft-ietf-netmod-routing-cfg-23 (until Sep 9, 2016)

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 01 Sep 2016 10:41:31 +0200

Kent Watsen <[email-masked]> writes:

> [as a contributor]
>
> My only comment on this draft is that I’d prefer it if the
> “routing-state” tree were moved into another YANG module, so that it
> could be more easily deprecated when the opstate solution comes.   I
> suggested this before, with regards to rfc6087bis Section 5.23, but
> that thread seemed to have petered out, but now here we are and my
> opinion remains the same.

I am actually in favour of making this change as it gives additional
flexibility. There may be use cases that implement just the
configuration part, and replace "routing-state" with another module (or
are designed to retrieve state data by other means).

Lada

>
> Thanks,
> Kent
>
> From: netmod <[email-masked]> on behalf of Kent Watsen <[email-masked]>
> Date: Friday, August 26, 2016 at 1:54 PM
> To: "[email-masked]" <[email-masked]>
> Subject: [netmod] WG Last Call for draft-ietf-netmod-routing-cfg-23 (until Sep 9, 2016)
>
>
> This is a notice to start a two-week NETMOD WG last call for the document:
>
>                 A YANG Data Model for Routing Management
>                 https://tools.ietf.org/html/draft-ietf-netmod-routing-cfg-23
>
> Please indicate your support or concerns by Thursday September 9, 2016.
>
> We are not only interested in receiving defect reports, we are equally interested in statements of the form:
>
>   * I have reviewed draft-ietf-netmod-routing-cfg-23 and I found no issues
>   * I have implemented the data model in draft-ietf-netmod-routing-cfg-23
>   * I am implementing the data model in draft-ietf-netmod-routing-cfg-23
>   * I am considering to implement the data model in draft-ietf-netmod-routing-cfg-23
>
> Of course, these are merely suggestions, folks can provide comments in any form that suits them.
>
>
> Thank you,
>
> NETMOD WG Chairs
>
>
> _______________________________________________
> netmod mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netmod

-- 
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C

---

From: <[email-masked]>
Date: Fri, 2 Sep 2016 08:16:36 +0000

Hi,

As this model is a base for multiple routing modules, it would be good to align the op-state modeling between this model and the existing routing related modules (so we can also close the work on multiple routing yang models).
So if core routing model uses foo:/foo foo:/foo-state, do we keep this modeling also for our protocol models and close the work ? 

Best Regards,

Stephane

-----Original Message-----
From: netmod [mailto:[email-masked]] On Behalf Of Juergen Schoenwaelder
Sent: Wednesday, August 31, 2016 20:41
To: Kent Watsen
Cc: [email-masked]
Subject: Re: [netmod] WG Last Call for draft-ietf-netmod-routing-cfg-23 (until Sep 9, 2016)

On Wed, Aug 31, 2016 at 06:11:14PM +0000, Kent Watsen wrote:
> [as a contributor]
> 
> My only comment on this draft is that I’d prefer it if the “routing-state” tree were moved into another YANG module, so that it could be more easily deprecated when the opstate solution comes.   I suggested this before, with regards to rfc6087bis Section 5.23, but that thread seemed to have petered out, but now here we are and my opinion remains the same.
>

We already have foo:/foo /foo:foo-state modules and while we can now start a series of foo:/foo and foo-state:/foo-state modules in the hope that this will eventually 'easier' in the future, it might also be that we just create more variation and confusion.

/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/>

_________________________________________________________________________________________________________________________

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: Ladislav Lhotka <[email-masked]>
Date: Fri, 2 Sep 2016 10:35:37 +0200

Hi Stephane,

if we do any changes to the core routing module, then I am afraid all modules that depend on it will have to follow suit. In particular, if we put config and state data into separate modules, protocol modules should do the same.

I don't like the idea of putting the core routing model and all work that depends on it on hold until we reach a decision regarding opstate. So, *if* the separation of config and state data gives a reasonable guarantee that at least the config part will be compatible with the ultimate opstate solution (whatever it is), it IMO makes sense to do it. But I am not even sure that the premise holds.

Lada

> On 02 Sep 2016, at 10:16, <[email-masked]> <[email-masked]> wrote:
> 
> Hi,
>

---

From: Kent Watsen <[email-masked]>
Date: Fri, 2 Sep 2016 19:30:54 +0000

It holds.  Some have FUD.  I do not.

K.

On 9/2/16, 4:35 AM, "Ladislav Lhotka" <[email-masked]> wrote:

    Hi Stephane,

    
    Lada

---

From: Kent Watsen <[email-masked]>
Date: Fri, 2 Sep 2016 19:32:57 +0000

Amendment: previous message as a contributor.  

K.

On 9/2/16, 3:30 PM, "netmod on behalf of Kent Watsen" <[email-masked] on behalf of [email-masked]> wrote:

    K.

        Hi Stephane,

        
        Lada

---

From: Ladislav Lhotka <[email-masked]>
Date: Sat, 3 Sep 2016 09:45:08 +0200

> On 02 Sep 2016, at 21:30, Kent Watsen <[email-masked]> wrote:
> 

Then you probably already know what the solution is going to be. I don't.

Anyway, if the consensus was to split config and state data into separate modules, we would have to tell all module developers who build upon the core routing model to split their augments into config and state parts as well, because otherwise the change to ietf-routing would be useless.  

Lada

---

From: Rob Shakir <[email-masked]>
Date: Sat, 3 Sep 2016 09:04:49 -0700

Hi Kent, NETMOD,

> draft-ietf-netmod-routing-cfg-23

I'd like to add a new category to this set of statements:

 * I have reviewed this draft, and will *not* be implementing the data
model described within it.

I have concerns with the contents of this model and their suitability as a
base for the wider set of models that are intended to augment it. Indeed, I
think the elements that it tackles (e.g., arrangement of protocols within a
routing instance) are very much lowest common denominator, and none of the
wider issues around multi-tenancy of routing instances (especially those
that mix VSI and VRF type semantics) on an individual device, or the way
that protocols map to RIBs, and how they then interact/interconnect are
tackled within the model.

Whilst I understand the difficulties that the authors have been through to
try and find a solution, I'm afraid that consensus here has led to a model
that actually is operationally a no-op -- even the configuration for static
routing is not sufficient for most operator use cases that we have examined
when working on a similar problem space.

Based on this, and the lack of examination of real configurations of
network elements to the model described within the draft, I would oppose
progressing this model to RFC until such time as it has been proved to
cover a operationally viable set of functionality, and there can be any
level of confidence that further changes to the model will not be
immediately needed to be able to accommodate the use cases that are
required of it.  Given the historical opposition to revising models once
they have been cast as RFCs that we have seen within the IETF, then I feel
that avoiding incomplete models going to RFC is the best course of action.

Thanks,
r.

[0]: Please note: I am speaking as an individual here, not on behalf of any
wider set of view points.
[1]: Please further note: This opposition to publishing this document
completely ignores the issue of operational state. I have made my thoughts
clear on this previously, but these comments are entirely orthogonal to
that opposition.

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 05 Sep 2016 14:47:12 +0200

> model described within it.

Fair enough.

> when working on a similar problem space.

Earlier revisions of the draft (such as -16) contained more stuff that
really implemented something (framework for route filters, explicit connection of
routing protocols to RIBs, fancy next-hops). All of them were removed,
mainly because they aren't the lowest common denominator.

Nonetheless, I don't think that what remains is a no-op. The core
routing model does define a framework in which multiple instances of
routing protocols can coexist. And it also implements an approach to
configuration versus state data analogical to RFC 7223 (which you
probably don't like).

As for static routing, I believe it perfectly suffices for hosts and
simpler router configurations. As a proof of concept, I myself wrote
XSLT stylesheets that were able to convert this data to CLI
configurations for Cisco IOS and BIRD routing daemon. It may not be
sufficient for all use cases, but then nothing prevents you or anybody
else from developing a data model for a new "static-on-steroids"
protocol, and fit it into the core routing model.

Lada

---

From: Kent Watsen <[email-masked]>
Date: Thu, 8 Sep 2016 17:56:54 +0000

>    Then you probably already know what the solution is going to be. I don't.

It’s not that I know the exact solution.  It’s that I see this approach offering good options for graceful migration to an opstate compliant solution (for which I’m on the design team alias), without incurring any modelling cost, other than there being an additional module.  I additionally see this approach as more flexible in that, as you said, it would allow one module to be updated without disturbing the other.

> Anyway, if the consensus was to split config and state data into separate modules, we would have to tell all module developers who build upon the core routing model to split their augments into con…

Yes, indeed, this would be the primary consequence.

Kent

---

From: Ladislav Lhotka <[email-masked]>
Date: Fri, 09 Sep 2016 13:54:51 +0200

Kent Watsen <[email-masked]> writes:

> It’s not that I know the exact solution.  It’s that I see this
> approach offering good options for graceful migration to an opstate
> compliant solution (for which I’m on the design team alias), without
> incurring any modelling cost, other than there being an additional
> module.  I additionally see this approach as more flexible in that, as
> you said, it would allow one module to be updated without disturbing
> the other.

The data modelling cost of splitting config and state data into
separate modules IMO is that it weakens the concept of system- and
user-controlled objects. I understand that some folks don't like it but
I am still not convinced that anything better is readily available.

And then of course another cost is that all modules depending on
ietf-routing need to be updated accordingly. So IMO we should think
twice before making this change. I would appreciate more opinions on it.

Lada

---

From: Kent Watsen <[email-masked]>
Date: Wed, 14 Sep 2016 13:46:23 +0000

The last call on this draft has ended!  Thank you everyone who participated.  There doesn’t seem to be consensus to adopt my proposal to move the -state tree to another module, and so we will call it rough consensus in favor of publishing the document as it is.   This document will be moved to the ‘WG Consensus: Waiting for Write-Up’ working group state shortly; the shepherd will take it from there.

Thanks,
Kent (and Lou)

Thank you,

NETMOD WG Chairs