Subject: Re: [yang-doctors] proposed text to clarify use of the ietf-network-topology and ietf-network

From: Kent Watsen <[email-masked]>
Date: Mon, 30 Jan 2017 23:27:03 +0000

[+yang-doctors]

Hi Xufeng,

> I think that the issue raised by Kent has been discussed multiple times between the
> authors, I2RS WG, and several Yang doctors (Martin, Andy, and Lada?). 

My reading of the recent I2RS thread comes to a different conclusion.  It seems that
many were struggling with basics such as if this is a standard YANG module or something
constrained to ephemeral/I2RS use only.  There may have been discussions before, but
given this disconnect, I question their validity.  Still, in case I'm missing something
subtle, please point me to where a YANG doctor blessed the 'server-provided' flag, 
knowing that 1) this module is for general use, 2) it promotes non-config to config,
and 3) it breaks standard operations and workflows (e.g., backup/restore).

Alternatively, since I just CC-ed the YANG-doctors list, can someone there quickly
tell me that this is really a sanctioned solution?

> The result of
> the discussions was to keep the current "server-provided" as a compromise, because
> there had been no ideal solution available so far. 

Per 6087bis Section 5.23, the current officially accepted approach for reporting 
operational state for system-generated values is to have a separate config false
/foo-state tree.   Why was this not considered an acceptable solution?

Jumping ahead of the expected answer, I understand that controller apps like ODL
have config/intent service-level models that essentially defined overlay networks
that need to reference real underlay networks.  While at first it may seem like
a case where a config true node would need to point to a config false node, I don't 
believe it's that way at all.  Rather I think that the controller app, would import
(and merge/de-duplicate) the network elements' topo opstate into its database as
config (not opstate), which would result in config true pointing to config true.
The only thing that may not be ideal is the controller app wouldn't be able to
differentiate which parts of the topo model it imported versus created, and here
is where a 'server-provided' flag might make sense but, in this case, it should
be an augmentation added in at the controller-level as opposed to being in the
base model, right?

Thanks,
Kent

---

From: Hariharan Ananthakrishnan <[email-masked]>
Date: Mon, 30 Jan 2017 23:40:09 +0000

Reposting YANG Doctor review thread for reference:
 https://www.ietf.org/mail-archive/web/yang-doctors/current/msg00032.html

- Hari

On 30/01/2017, 15:33, "Kent Watsen" <[email-masked]> wrote:

    [update: now CC-ing the yang-doctor's list!]
    
    [+yang-doctors]

    Hi Xufeng,

    

    

    Thanks,
    Kent

---

From: Kent Watsen <[email-masked]>
Date: Mon, 30 Jan 2017 23:33:36 +0000

[+yang-doctors]

Hi Xufeng,

Thanks,
Kent

---

From: Kent Watsen <[email-masked]>
Date: Tue, 31 Jan 2017 01:07:33 +0000

Thanks Hari,

That review was a while ago, and there is no support for this approach from me of Andy there.  I was hoping there was something more recent...

Searching 'server-provided' in the I2RS mailing list, I see the "WG LC for Topology (10/1 to 10/14)" discussion in October 2015 in which Martin, Juergen, and Andy continually say that this is a misuse of YANG.  I can't find any support for this approach there.  [FWIW, that thread ends without a resolution that I can see].

Strangely, the next time 'server-provided' is discussed is nearly 14 months later, during the most-recent IESG balloting.  Actually, just searching for the word 'provided' yields the same result.  In either case, as we all know, the most recent discussion didn't yield support for this approach either.

As I'm unable to find any support and, in fact, find quite the opposite, I stand by my concern that this is an illegal use of YANG.

Kent

- Hari

    
    [+yang-doctors]

    Hi Xufeng,

    

    

    Thanks,
    Kent

---

From: Kent Watsen <[email-masked]>
Date: Tue, 31 Jan 2017 08:24:14 +0000

I just woke up thinking I about this and felt like I needed to explain my yang-doctor review some before my conscious would let me go to sleep again (if possible after staring at the screen to write this).

Anyway, I remember this yang-doctor review, it was my first and only such review.  I'd never looked at the topo draft before.  I remember thinking that I should only need to look at the YANG module itself since, generically speaking, yang-doctors can't be domain-experts in every WG.  I literally just searched for the YANG modules contained within the draft, skipping all text leading up to them.  What I saw was a config false node called 'server-provided' having a somewhat unremarkable description statement and naively wondered if the node had a lifecycle different than /networks/network/network-id, which is why models typically have a top-level /foo-state tree. It never occurred to me that this little flag was actually being used to change fundamental YANG semantics.  I was not at this time aware of the thread that had occurred on the i2rs list before.  As an aside, note that I completely missed that (in -03) 'network-ref' was a config false node pointing to a config true node, which should've failed YANG validation.  Anyway, the response I got back didn't alert me, and I figured it was a WG matter to sort out.  

As far as post-mortems go, I should've dug a little deeper, perhaps inquiring about the nature of the "controversial discussions" and/or reading more of the draft to understand the 'server-provided' flag's semantics.  And, for Alex's part, he may have assumed that I'd seen the discussions on the I2RS list from before and/or read the entire draft.  Anyway, it seems that this fell through the cracks and for that I apologize.   [Good, now that I'd said that, maybe I can get back to sleep].

Thanks,
Kent

Thanks Hari,

That review was a while ago, and there is no support for this approach from me or Andy there.  I was hoping there was something more recent...

Kent

- Hari

    
    [+yang-doctors]

    Hi Xufeng,

    

    

    Thanks,
    Kent

---

From: Andy Bierman <[email-masked]>
Date: Tue, 31 Jan 2017 08:57:03 -0800

Hi,

I am concerned about different protocols deciding that the same YANG
statement
means 1 thing in protocol A and another in protocol B.

The config=true statement is very clear in YANG.
It is not defined in terms of protocol, but rather abstract configuration
datastores.
YANG says config=true means the node is part of configuration datastores.

It is OK for protocol A to have access to datastores and protocol B to hide
them,
or protocol B has access to different datastores than A.  But the YANG
statements
need to reflect the intent of the data model, not the protocols.

There is no YANG rule that says config=false means read-only in every
protocol.
It doesn't say that at all. config=false also allows I2RS to write
constraints that
reference any node.

Andy

On Mon, Jan 30, 2017 at 5:07 PM, Kent Watsen <[email-masked]> wrote:

>
> Thanks Hari,
>
> That review was a while ago, and there is no support for this approach
> from me of Andy there.  I was hoping there was something more recent...
>
> Searching 'server-provided' in the I2RS mailing list, I see the "WG LC for
> Topology (10/1 to 10/14)" discussion in October 2015 in which Martin,
> Juergen, and Andy continually say that this is a misuse of YANG.  I can't
> find any support for this approach there.  [FWIW, that thread ends without
> a resolution that I can see].
>
> Strangely, the next time 'server-provided' is discussed is nearly 14
> months later, during the most-recent IESG balloting.  Actually, just
> searching for the word 'provided' yields the same result.  In either case,
> as we all know, the most recent discussion didn't yield support for this
> approach either.
>
> As I'm unable to find any support and, in fact, find quite the opposite, I
> stand by my concern that this is an illegal use of YANG.
>
> Kent
>
>
>
> _______________________________________________
> yang-doctors mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/yang-doctors
>

---

From: Alia Atlas <[email-masked]>
Date: Tue, 31 Jan 2017 11:59:19 -0500

Andy,

It is quite clear that there is a technical concern here that wasn't
adequately discussed or at least
that the resulting conclusions were adequately documented.

We are meeting today to talk through the technical issue and understand
what our options are.
I fully expect that the documents will need to be returned to the WG for
improvement and clarification.
I am waiting to do so until we've met today and have a bit more clarity for
the WG in terms of what
the technical options are.

Regards,
Alia

On Tue, Jan 31, 2017 at 11:57 AM, Andy Bierman <[email-masked]> wrote:

> It is OK for protocol A to have access to datastores and protocol B to
> hide them,
>> Searching 'server-provided' in the I2RS mailing list, I see the "WG LC
>> for Topology (10/1 to 10/14)" discussion in October 2015 in which Martin,
>> As I'm unable to find any support and, in fact, find quite the opposite,
>> I stand by my concern that this is an illegal use of YANG.
>>
>> Kent
>>
>>
>>

---

From: Thomas Nadeau <[email-masked]>
Date: Tue, 31 Jan 2017 14:42:45 -0500

+1

> On Jan 31, 2017:11:57 AM, at 11:57 AM, Andy Bierman <[email-masked]> wrote:
> 
> Hi,
> 
> 
> I am concerned about different protocols deciding that the same YANG statement
> It is not defined in terms of protocol, but rather abstract configuration datastores.
> It is OK for protocol A to have access to datastores and protocol B to hide them,
> or protocol B has access to different datastores than A.  But the YANG statements
> There is no YANG rule that says config=false means read-only in every protocol.
> It doesn't say that at all. config=false also allows I2RS to write constraints that
> reference any node.
> 
> 
> Andy
> 
> 
> 
> On Mon, Jan 30, 2017 at 5:07 PM, Kent Watsen <[email-masked] <mailto:[email-masked]>> wrote:
> 
> Thanks Hari,
> 
>  https://www.ietf.org/mail-archive/web/yang-doctors/current/msg00032.html <https://www.ietf.org/mail-archive/web/yang-doctors/current/msg00032.html>
> 
> - Hari
> 
> On 30/01/2017, 15:33, "Kent Watsen" <[email-masked] <mailto:[email-masked]>> wrote:
> 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/yang-doctors <https://www.ietf.org/mailman/listinfo/yang-doctors>
>

---

From: "Susan Hares" <[email-masked]>
Date: Tue, 31 Jan 2017 15:31:46 -0500

Tom and Andy: 

How would you suggest indicating configuration and operational state in
ephemeral control plane data store?  It is very useful to differentiate
between the two in ephemeral state.  Do you have a suggestion?  

Sue 

From: Thomas Nadeau [mailto:[email-masked]] 
Sent: Tuesday, January 31, 2017 2:43 PM
To: Andy Bierman
Cc: Kent Watsen; [email-masked]; Hariharan Ananthakrishnan; Xufeng
Liu; [email-masked]; [email-masked];
Vishnu Pavan Beeram; [email-masked];
[email-masked]; Alexander Clemm; Alia Atlas; Susan Hares
Subject: Re: [yang-doctors] proposed text to clarify use of the
ietf-network-topology and ietf-network

+1

On Jan 31, 2017:11:57 AM, at 11:57 AM, Andy Bierman <[email-masked]>
wrote:

Hi,

reference any node.

Andy

Thanks Hari,

That review was a while ago, and there is no support for this approach from
me of Andy there.  I was hoping there was something more recent...

Searching 'server-provided' in the I2RS mailing list, I see the "WG LC for
Topology (10/1 to 10/14)" discussion in October 2015 in which Martin,
Juergen, and Andy continually say that this is a misuse of YANG.  I can't
find any support for this approach there.  [FWIW, that thread ends without a
resolution that I can see].

Strangely, the next time 'server-provided' is discussed is nearly 14 months
later, during the most-recent IESG balloting.  Actually, just searching for
the word 'provided' yields the same result.  In either case, as we all know,
the most recent discussion didn't yield support for this approach either.

Kent

- Hari

    [+yang-doctors]

    Hi Xufeng,

    > authors, I2RS WG, and several Yang doctors (Martin, Andy, and Lada?).

    My reading of the recent I2RS thread comes to a different conclusion.
It seems that
    many were struggling with basics such as if this is a standard YANG
module or something
    constrained to ephemeral/I2RS use only.  There may have been discussions
before, but
    given this disconnect, I question their validity.  Still, in case I'm
missing something
    subtle, please point me to where a YANG doctor blessed the
'server-provided' flag,
    knowing that 1) this module is for general use, 2) it promotes
non-config to config,
    and 3) it breaks standard operations and workflows (e.g.,
backup/restore).

    Alternatively, since I just CC-ed the YANG-doctors list, can someone
there quickly
    tell me that this is really a sanctioned solution?

    > there had been no ideal solution available so far.

    Per 6087bis Section 5.23, the current officially accepted approach for
reporting
    operational state for system-generated values is to have a separate
config false
    /foo-state tree.   Why was this not considered an acceptable solution?

    Jumping ahead of the expected answer, I understand that controller apps
like ODL
    have config/intent service-level models that essentially defined overlay
networks
    that need to reference real underlay networks.  While at first it may
seem like
    a case where a config true node would need to point to a config false
node, I don't
    believe it's that way at all.  Rather I think that the controller app,
would import
    (and merge/de-duplicate) the network elements' topo opstate into its
database as
    config (not opstate), which would result in config true pointing to
config true.
    The only thing that may not be ideal is the controller app wouldn't be
able to
    differentiate which parts of the topo model it imported versus created,
and here
    is where a 'server-provided' flag might make sense but, in this case, it
should
    be an augmentation added in at the controller-level as opposed to being
in the
    base model, right?

    Thanks,
    Kent

---

From: Andy Bierman <[email-masked]>
Date: Tue, 31 Jan 2017 12:50:38 -0800

> between the two in ephemeral state.  Do you have a suggestion?

I do not agree that the I2RS control plane datastore has any operational
data in it.
That data would be in the operational daatstore.

The solution discussed many times was a YANG extension -- e.g., tagging a
node as writable by I2RS

  extension writable {
    description
       "Argument indicates whether I2RS can write to the data node
containing this statement.
        Also indicates I2RS conformance for the data node containing this
statement.
        Default is false if this extension is not present.";
  }

  container some-node {
     i2rs:writable true;
     config false;
     description "I2RS can write to this container in its ephemeral
datastore";
  }

  container some-other-node {
     i2rs:writable false;
     config false;
     description "I2RS cannot write to this container in its ephemeral
datastore";
  }

If config=true then node can also appear in the configuration datastores.

Sue

Andy

>
>
> *From:* Thomas Nadeau [mailto:[email-masked]]
> *Sent:* Tuesday, January 31, 2017 2:43 PM
> *To:* Andy Bierman
> *Cc:* Kent Watsen; [email-masked]; Hariharan Ananthakrishnan;
> Xufeng Liu; [email-masked];
> [email-masked]; Vishnu Pavan Beeram; draft-ietf-i2rs-yang-l3-
> [email-masked]; [email-masked]; Alexander Clemm; Alia Atlas;
> Susan Hares
> *Subject:* Re: [yang-doctors] proposed text to clarify use of the

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 31 Jan 2017 22:21:25 +0100 (CET)

> [update: now CC-ing the yang-doctor's list!]

[trimming the Cc a bit to avoid the "Too many recipients" problem.  I
hope everyone still receives this reply]

> tell me that this is really a sanctioned solution?

I just re-read the old ML thread you referred to in another mail ("WG
LC for Topology (10/1 to 10/14)", and I think it is pretty clear that
from the YANG doctors point of view, this is not a "sanctioned
solution".  We pointed out the problems with the current design and
suggested several alternative ways of handling this issue, including
the traditional /foo and /foo-state solution that 6087bis recommends.

This said, this problem was one of the reasons we now have
draft-ietf-netmod-revised-datastores.  Maybe one way to deal with this
document is to use one of the traditional solutions for now, and then
revisit this model once the work that has been started with
draft-ietf-netmod-revised-datastores is finished.

/martin

---

From: Kent Watsen <[email-masked]>
Date: Tue, 31 Jan 2017 21:48:56 +0000

All,

There was a meeting today amongst authors, chairs, and ADs.  I participated more as a technical expert than a co-chair.  The net-net is that the draft will be returned to the WG and I signed up to facilitate a proper solution.  Immediately I'm going to meet with the authors offline to hammer out a workable solution, which will then be brought to the I2RS WG for ratification.  This should occur before the end of next week.

Stay tuned!
Kent