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

[Rob Shakir]

Hi Kent, NETMOD,

On Fri, Aug 26, 2016 at 10:54 AM, Kent Watsen  wrote:

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

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.
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

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

[Ladislav Lhotka]

> On 02 Sep 2016, at 21:30, Kent Watsen  wrote:
> 
> It holds.  Some have FUD.  I do not.

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

> 
> K.
> 
> 
> On 9/2/16, 4:35 AM, "Ladislav Lhotka"  wrote:
> 
>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,  
>>  wrote:
>> 
>> 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:netmod-boun...@ietf.org] On Behalf Of Juergen 
>> Schoenwaelder
>> Sent: Wednesday, August 31, 2016 20:41
>> To: Kent Watsen
>> Cc: netmod@ietf.org
>> 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 +, 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 
>> 
>> ___
>> netmod mailing list
>> netmod@ietf.org
>> https://www.ietf.org/mailman/listinfo/netmod
>> 
>> _
>> 
>> 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.
>> 
>> ___
>> netmod mailing list
>> netmod@ietf.org
>> https://www.ietf.org/mailman/listinfo/netmod
> 
>--
>Ladislav Lhotka, CZ.NIC Labs
>PGP Key ID: E74E8C0C
> 
> 
> 
> 
> 
> 

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




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