[i2rs] Robert Wilton's No Objection on draft-ietf-i2rs-yang-l2-network-topology-18: (with COMMENT)

2020-09-17 Thread Robert Wilton via Datatracker 
Robert Wilton has entered the following ballot position for
draft-ietf-i2rs-yang-l2-network-topology-18: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-i2rs-yang-l2-network-topology/



--
COMMENT:
--

Clearing discuss held for IEEE review:

The IEEE Yangsters (members of the IEEE YANG experts) who reviewed and
contributed review comments to this draft are comfortable with version -18. 
Note, that these represent informal reviews of individuals and do not represent
a formal IEEE consensus position."

Regards,
Rob

Mostly minor/editorial comments  (###) on the YANG model, but I do think that
it would be helpful for these to be discussed and addressed as appropriate:

4.  Layer 2 Topology YANG Module

 import ietf-inet-types {
   prefix inet;
   reference
 "Section 4 of RFC 6991";
 }
 import ietf-yang-types {
   prefix yang;
   reference
 "Section 3 of RFC 6991";
 }

###
These references should probably both just be: "RFC 6991: Common YANG Data
Types"

 revision 2020-06-29 {
   description
 "Initial revision";
   reference
 "RFC : A YANG Data Model for Layer 2 Network
Topologies";
 }

###
I would reorder these sections to be (which will solve the forward reference
issue mentioned by Ben):
   feature-stmt
   identity-stmt
   typedef-stmt

I'm surprised that pyang didn't flag this.

 /*
  * Typedefs
  */

 typedef vni {
   type uint32 {
 range "0..16777215";
   }
   description
 "VXLAN Network Identifier or VXLAN Segment ID.
  It allows up to 16 M VXLAN segments to coexist
  within the same administrative domain.

  The use of value '0' is implementation-specific.";
   reference
 "RFC 7348: Virtual eXtensible Local Area  Network (VXLAN):
A Framework for Overlaying Virtualized Layer 2
Networks over Layer 3 Networks";
 }

 typedef l2-flag-type {
   type identityref {
 base flag-identity;
   }
   description
 "Base type for L2 flags. One example of L2 flag
  type is trill which represents trill topology
  type.";
 }

###
This isn't really a base type.  Given where this flag is used, would this be
better as an "network-flag-type", with a description more similar to the ones
below?

 typedef node-flag-type {
   type identityref {
 base flag-identity;
   }
   description
 "Node flag attributes. The physical node can be
  one example of node flag attribute.";
 }

 typedef link-flag-type {
   type identityref {
 base flag-identity;
   }
   description
 "Link flag attributes. One example of link flag
  attribute is the pseudowire.";
 }

###
Should there be identities defined for l2-flag, node-flag and link-flag that
derive from flag-identity?  That would them make these three typedefs reference
different things rather than all referencing the same base flags.

 typedef l2-network-event-type {
   type enumeration {
 enum add {
   value 0;
   description
 "A Layer 2 node or link or termination-point
  has been added.";
 }
 enum remove {
   value 1;
   description
 "A Layer 2 node or link or termination-point
  has been removed.";
 }
 enum update {
   value 2;
   description
 "A Layer 2 node or link or termination-point
  has been updated.";
 }
   }
   description
 "Layer 2 network event type for notifications.";
 }

###
Since these are events, I would suggest renaming these
"add" -> "addition", "remove" -> "removal", "update"

 typedef neg-mode {
   type enumeration {
 enum full-duplex {
   description
 "Indicates full-duplex mode.";
 }
 enum auto-neg {
   description
 "Indicates auto-negotiation mode.";
 }
 enum half-duplex {
   description
 "Indicates half-duplex mode.";
 }

[i2rs] Robert Wilton's Discuss on draft-ietf-i2rs-yang-l2-network-topology-14: (with DISCUSS and COMMENT)

2020-07-09 Thread Robert Wilton via Datatracker 
Robert Wilton has entered the following ballot position for
draft-ietf-i2rs-yang-l2-network-topology-14: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-i2rs-yang-l2-network-topology/



--
DISCUSS:
--

I support Magnus's discuss regarding IEEE 802.1Q WG review.

I also feel that the YANG model could benefit from another editorial pass:
 - In many places the descriptions are very terse, and references are missing.
 - The way that auto-neg is defined doesn't really match the 802.3
 specification, probably splitting it into two separate leaves (one for whether
 auto-neg is on/off, and separate one for the duplex setting would be better).
 - The use of terminology for VLAN vs QinQ might not be acceptable to IEEE. 
 Finding names that are more closely aligned with the terms in 802.1Q may be
 helpful (although if I understand it correctly, 802.1Q bridges don't directly
 expose double VLAN tags).  Possibly some of the terminology/description from
 draft-ietf-netmod-sub-intf-vlan-model (which has been reviewed by IEEE 802.1Q
 WG) may be helpful here.


--
COMMENT:
--

Mostly minor/editorial comments  (###) on the YANG model, but I do think that
it would be helpful for these to be discussed and addressed as appropriate:

4.  Layer 2 Topology YANG Module

 import ietf-inet-types {
   prefix inet;
   reference
 "Section 4 of RFC 6991";
 }
 import ietf-yang-types {
   prefix yang;
   reference
 "Section 3 of RFC 6991";
 }

###
These references should probably both just be: "RFC 6991: Common YANG Data
Types"

 revision 2020-06-29 {
   description
 "Initial revision";
   reference
 "RFC : A YANG Data Model for Layer 2 Network
Topologies";
 }

###
I would reorder these sections to be (which will solve the forward reference
issue mentioned by Ben):
   feature-stmt
   identity-stmt
   typedef-stmt

I'm surprised that pyang didn't flag this.

 /*
  * Typedefs
  */

 typedef vni {
   type uint32 {
 range "0..16777215";
   }
   description
 "VXLAN Network Identifier or VXLAN Segment ID.
  It allows up to 16 M VXLAN segments to coexist
  within the same administrative domain.

  The use of value '0' is implementation-specific.";
   reference
 "RFC 7348: Virtual eXtensible Local Area  Network (VXLAN):
A Framework for Overlaying Virtualized Layer 2
Networks over Layer 3 Networks";
 }

 typedef l2-flag-type {
   type identityref {
 base flag-identity;
   }
   description
 "Base type for L2 flags. One example of L2 flag
  type is trill which represents trill topology
  type.";
 }

###
This isn't really a base type.  Given where this flag is used, would this be
better as an "network-flag-type", with a description more similar to the ones
below?

 typedef node-flag-type {
   type identityref {
 base flag-identity;
   }
   description
 "Node flag attributes. The physical node can be
  one example of node flag attribute.";
 }

 typedef link-flag-type {
   type identityref {
 base flag-identity;
   }
   description
 "Link flag attributes. One example of link flag
  attribute is the pseudowire.";
 }

###
Should there be identities defined for l2-flag, node-flag and link-flag that
derive from flag-identity?  That would them make these three typedefs reference
different things rather than all referencing the same base flags.

 typedef l2-network-event-type {
   type enumeration {
 enum add {
   value 0;
   description
 "A Layer 2 node or link or termination-point
  has been added.";
 }
 enum remove {
   value 1;
   description
 "A Layer 2 node or link or termination-point
  has been removed.";
 }
 enum update {
   value 2;
   description
 "A Layer 2 node or link or termination-point
  has been updated.";

Re: [i2rs] WG LC confirmation on draft-ietf-i2rs-yang-l2-network-topology (3/7 to 3/21/2018)

2018-03-07 Thread Robert Wilton 

One quick comment (not a proper review):

I note that the extra state module in Appendix A is redefining features 
defined in the main module.  This isn't generically necessarily the 
wrong thing to do, but in this case it looks like they are not required 
in the state module (since they don't appear to be used), and would be 
best removed.


Thanks,
Rob


On 07/03/2018 17:25, Susan Hares wrote:


Greetings I2RS folks:

This is a 2 Week WG LC to confirm the WG LC on 
draft-ietf-i2rs-yang-l2-network-topology.   During this WG LC, please 
indicate any issues with the updates to align with Network Management 
Data Store Module.  These may include:


1)Yang data model structure,

2)High level Yang language format

3)Security consideration section,

4)Any issues with the notification calls.

If you feel this updated data model is ready for publication, please 
send indicate that in your response.


Cheerily, Susan Hares



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


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

Re: [i2rs] I-D Action: draft-ietf-i2rs-yang-network-topo-13.txt

2017-06-28 Thread Robert Wilton 

Hi Alex,


On 27/06/2017 22:09, Alexander Clemm wrote:


Hi Robert,

We will add it to the draft.

This will presumably also affect the l3-topo draft, to augment the 
–state with its own –state tree.



Yes, I would think so.

You mention tooling that can automatically generate this.  Can you 
please point me to such a tool?  (If not, no problem, will update 
manually.)



Not that is robust enough at the moment, it needs some more work.

Will investigate use of grouping and uses statements.  In that case 
the –state module could simply use the grouping defined in the 
NMDA-compliant module.


Groupings can sometimes be shared, but I think that gets more complex, 
so life is easier if you don't try and optimize them.


I think that the conversion steps are:
1) Take a copy of the NMDA module and add "-state" to the name of the 
module, and also in the namespace.

2) Add "-s" to the prefix.
3) Delete any typedefs/identities and import from the original NMDA 
module instead.
4) Fixup up augments to augment the "-state" module path instead of the 
NMDA config tree, and add any required imports.
5) Check xpath expressions.  Paths that are relative and internal to the 
module should be fine, absolute paths may need to be updated to use the 
equivalent -state module (if it exists).


Thanks,
Rob


Thanks

--- Alex

*From:*Robert Wilton [mailto:rwil...@cisco.com]
*Sent:* Tuesday, June 27, 2017 2:50 AM
*To:* Alexander Clemm <alexander.cl...@huawei.com>; 'Xufeng Liu' 
<xufeng_...@jabil.com>; i2rs@ietf.org

*Subject:* Re: [i2rs] I-D Action: draft-ietf-i2rs-yang-network-topo-13.txt

Hi Alex,

If you need to represent learned topologies before NMDA compliant 
implementations are available then you need the extra -state module 
(i.e. a copy of the NMDA compatible I2RS topology module, but with 
name appended with -state and all nodes set as config false).  This 
could be generated via tooling, put into github, or added in an 
appendix to the draft.


Without this, then the existing I2RS topology module can only be used 
to represent configured topologies on non NMDA compliant 
implementations (specifically any implementations that don't expose 
the operational state datastore).


For NMDA compliant implementations the network topology module in 
draft -13 works well.


Thanks,
Rob

On 26/06/2017 18:52, Alexander Clemm wrote:

Hi Rob,

Inline , below

Thanks

--- Alex

-- Forwarded message --
From: "*Robert Wilton*" <rwil...@cisco.com <mailto:rwil...@cisco.com>>
Date: Mon, Jun 26, 2017 at 1:53 AM -0700
Subject: Re: [i2rs] I-D Action:
draft-ietf-i2rs-yang-network-topo-13.txt
To: "Alexander Clemm" <lud...@clemm.org
<mailto:lud...@clemm.org>>, <i2rs@ietf.org
<mailto:i2rs@ietf.org>>, "'Nitin Bahadur'"
<nitin_baha...@yahoo.com <mailto:nitin_baha...@yahoo.com>>, "'Russ
White'" <r...@riw.us <mailto:r...@riw.us>>, "'Xufeng Liu'"
<xufeng_...@jabil.com <mailto:xufeng_...@jabil.com>>,
<h...@packetdesign.com <mailto:h...@packetdesign.com>>, "'Jan
Medved (jmedved)'" <jmed...@cisco.com <mailto:jmed...@cisco.com>>,
<robert.va...@pantheon.sk <mailto:robert.va...@pantheon.sk>>,
"'Susan Hares'" <sha...@ndzh.com <mailto:sha...@ndzh.com>>, "Kent
Watsen" <kwat...@juniper.net <mailto:kwat...@juniper.net>>,
"Martin Bjorklund" <m...@tail-f.com <mailto:m...@tail-f.com>>


Hi Juergen,

  

  


On 24/06/2017 14:17, Juergen Schoenwaelder wrote:

> On Thu, Jun 22, 2017 at 11:44:00AM +0100, Robert Wilton wrote:

>> Do you think that it would be useful if the draft also included the extra

>> transient "-state" modules in an appendix (e.g. as per

>> draft-dsdt-nmda-guidelines-01 section 2)?

>>

>> Specifically, I'm thinking to help make the topology module fully usable 
by

>> modules that augment it (e.g. by the TE modules if/when they adopt the 
NMDA

>> conventions), until NMDA implementations before widely available.

>>

> Rob,

>

> the less we have of those transient "-state" trees, the better it is.

> For LMAP (in auth48) we did not do this. These extra "-state" trees

> should ideally only be used in very rare cases, I think existing code

> already works with a single tree (at least this is what I understood

> from the OpenDaylight discussions).

I completely agree with you in general, but for the topology module I

think that the -state tree is required to represent topologies that

exist but have not been configured (e.g. perhaps those learned from a

dynamic routing

Re: [i2rs] I-D Action: draft-ietf-i2rs-yang-network-topo-13.txt

2017-06-27 Thread Robert Wilton 

Xufeng,

Thanks for the confirmation.  That hadn't been clear from the previous 
emails.


When you generate the "-state" modules, I would suggest that you also 
reuse and import any typedefs that you have in the original NMDA 
compliant module, rather than redefine them.  That should make it easier 
for implementers, both now and in the future.


Thanks,
Rob


On 27/06/2017 14:23, Xufeng Liu wrote:


As Alex mentioned in another email, we have discussed and agreed on 
the plan to move forward with both I2RS topology model and TE topology 
model, by adding the “-state” module. We will do it as quickly as 
possible.


Thanks,

- Xufeng

*From:*Robert Wilton [mailto:rwil...@cisco.com]
*Sent:* Tuesday, June 27, 2017 5:50 AM
*To:* Alexander Clemm <alexander.cl...@huawei.com>; Xufeng Liu 
<xufeng_...@jabil.com>; i2rs@ietf.org

*Subject:* Re: [i2rs] I-D Action: draft-ietf-i2rs-yang-network-topo-13.txt

Hi Alex,

If you need to represent learned topologies before NMDA compliant 
implementations are available then you need the extra -state module 
(i.e. a copy of the NMDA compatible I2RS topology module, but with 
name appended with -state and all nodes set as config false).  This 
could be generated via tooling, put into github, or added in an 
appendix to the draft.


Without this, then the existing I2RS topology module can only be used 
to represent configured topologies on non NMDA compliant 
implementations (specifically any implementations that don't expose 
the operational state datastore).


For NMDA compliant implementations the network topology module in 
draft -13 works well.


Thanks,
Rob

On 26/06/2017 18:52, Alexander Clemm wrote:

Hi Rob,

Inline , below

Thanks

--- Alex

-- Forwarded message ------
    From: "*Robert Wilton*" <rwil...@cisco.com <mailto:rwil...@cisco.com>>
Date: Mon, Jun 26, 2017 at 1:53 AM -0700
Subject: Re: [i2rs] I-D Action:
draft-ietf-i2rs-yang-network-topo-13.txt
To: "Alexander Clemm" <lud...@clemm.org
<mailto:lud...@clemm.org>>, <i2rs@ietf.org
<mailto:i2rs@ietf.org>>, "'Nitin Bahadur'"
<nitin_baha...@yahoo.com <mailto:nitin_baha...@yahoo.com>>, "'Russ
White'" <r...@riw.us <mailto:r...@riw.us>>, "'Xufeng Liu'"
<xufeng_...@jabil.com <mailto:xufeng_...@jabil.com>>,
<h...@packetdesign.com <mailto:h...@packetdesign.com>>, "'Jan
Medved (jmedved)'" <jmed...@cisco.com <mailto:jmed...@cisco.com>>,
<robert.va...@pantheon.sk <mailto:robert.va...@pantheon.sk>>,
"'Susan Hares'" <sha...@ndzh.com <mailto:sha...@ndzh.com>>, "Kent
Watsen" <kwat...@juniper.net <mailto:kwat...@juniper.net>>,
"Martin Bjorklund" <m...@tail-f.com <mailto:m...@tail-f.com>>


Hi Juergen,

  

  


On 24/06/2017 14:17, Juergen Schoenwaelder wrote:

> On Thu, Jun 22, 2017 at 11:44:00AM +0100, Robert Wilton wrote:

>> Do you think that it would be useful if the draft also included the extra

>> transient "-state" modules in an appendix (e.g. as per

>> draft-dsdt-nmda-guidelines-01 section 2)?

>>

>> Specifically, I'm thinking to help make the topology module fully usable 
by

>> modules that augment it (e.g. by the TE modules if/when they adopt the 
NMDA

>> conventions), until NMDA implementations before widely available.

>>

> Rob,

>

> the less we have of those transient "-state" trees, the better it is.

> For LMAP (in auth48) we did not do this. These extra "-state" trees

> should ideally only be used in very rare cases, I think existing code

> already works with a single tree (at least this is what I understood

> from the OpenDaylight discussions).

I completely agree with you in general, but for the topology module I

think that the -state tree is required to represent topologies that

exist but have not been configured (e.g. perhaps those learned from a

dynamic routing protocol).

  


Also copying Kent and Martin, since they were very both very involved in

the discussions on the I2RS alias discussing the structure of the I2RS

network topology module.

  


My interpretation is from Xufeng was it is needed for the TE YANG

modules, but if it turns out that it is not actually needed, then that

is also good with me ;-)

  




The need to represent topologies that are learned is certainly
there.  It is not exclusive to TE, and I would be surprised if TE
YANG modules have an extra need for a separate state tree. 
Probably the best person to comment here is Xufeng, but it sounds

to me, also per Juergen’s comments, that an extra state tree will
_/not/_ be needed.



Thanks,

Rob

  


>

> /js

>

  



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

Re: [i2rs] I-D Action: draft-ietf-i2rs-yang-network-topo-13.txt

2017-06-27 Thread Robert Wilton 

Hi Alex,

If you need to represent learned topologies before NMDA compliant 
implementations are available then you need the extra -state module 
(i.e. a copy of the NMDA compatible I2RS topology module, but with name 
appended with -state and all nodes set as config false).  This could be 
generated via tooling, put into github, or added in an appendix to the 
draft.


Without this, then the existing I2RS topology module can only be used to 
represent configured topologies on non NMDA compliant implementations 
(specifically any implementations that don't expose the operational 
state datastore).


For NMDA compliant implementations the network topology module in draft 
-13 works well.


Thanks,
Rob


On 26/06/2017 18:52, Alexander Clemm wrote:


Hi Rob,

Inline , below

Thanks

--- Alex

-- Forwarded message --
From: "*Robert Wilton*" <rwil...@cisco.com <mailto:rwil...@cisco.com>>
Date: Mon, Jun 26, 2017 at 1:53 AM -0700
Subject: Re: [i2rs] I-D Action: draft-ietf-i2rs-yang-network-topo-13.txt
To: "Alexander Clemm" <lud...@clemm.org <mailto:lud...@clemm.org>>, 
<i2rs@ietf.org <mailto:i2rs@ietf.org>>, "'Nitin Bahadur'" 
<nitin_baha...@yahoo.com <mailto:nitin_baha...@yahoo.com>>, "'Russ 
White'" <r...@riw.us <mailto:r...@riw.us>>, "'Xufeng Liu'" 
<xufeng_...@jabil.com <mailto:xufeng_...@jabil.com>>, 
<h...@packetdesign.com <mailto:h...@packetdesign.com>>, "'Jan Medved 
(jmedved)'" <jmed...@cisco.com <mailto:jmed...@cisco.com>>, 
<robert.va...@pantheon.sk <mailto:robert.va...@pantheon.sk>>, "'Susan 
Hares'" <sha...@ndzh.com <mailto:sha...@ndzh.com>>, "Kent Watsen" 
<kwat...@juniper.net <mailto:kwat...@juniper.net>>, "Martin Bjorklund" 
<m...@tail-f.com <mailto:m...@tail-f.com>>


Hi Juergen,
On 24/06/2017 14:17, Juergen Schoenwaelder wrote:
> On Thu, Jun 22, 2017 at 11:44:00AM +0100, Robert Wilton wrote:
>> Do you think that it would be useful if the draft also included the extra
>> transient "-state" modules in an appendix (e.g. as per
>> draft-dsdt-nmda-guidelines-01 section 2)?
>>
>> Specifically, I'm thinking to help make the topology module fully usable by
>> modules that augment it (e.g. by the TE modules if/when they adopt the NMDA
>> conventions), until NMDA implementations before widely available.
>>
> Rob,
>
> the less we have of those transient "-state" trees, the better it is.
> For LMAP (in auth48) we did not do this. These extra "-state" trees
> should ideally only be used in very rare cases, I think existing code
> already works with a single tree (at least this is what I understood
> from the OpenDaylight discussions).
I completely agree with you in general, but for the topology module I
think that the -state tree is required to represent topologies that
exist but have not been configured (e.g. perhaps those learned from a
dynamic routing protocol).
Also copying Kent and Martin, since they were very both very involved in
the discussions on the I2RS alias discussing the structure of the I2RS
network topology module.
My interpretation is from Xufeng was it is needed for the TE YANG
modules, but if it turns out that it is not actually needed, then that
is also good with me ;-)

The need to represent topologies that are learned is certainly there.  
It is not exclusive to TE, and I would be surprised if TE YANG modules 
have an extra need for a separate state tree.  Probably the best 
person to comment here is Xufeng, but it sounds to me, also per 
Juergen’s comments, that an extra state tree will _/not/_ be needed.


Thanks,
Rob
>
> /js
>


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

Re: [i2rs] I-D Action: draft-ietf-i2rs-yang-network-topo-13.txt

2017-06-23 Thread Robert Wilton 

Hi Alex,

Good questions, please see inline ...


On 23/06/2017 17:26, Alexander Clemm wrote:

Hi Robert,

We will do whatever is required to make the model future proof.

However, I am not quite sure of the particular ask.  Perhaps this is my
limited understanding of NMDA.  The following is really more of an NMDA
question: why would we require to duplicate the entire model under a -state
namespace, when we have different datastores and e.g. what is contained in
operational is "by definition" read-only?  (Data that originated from
configuration is marked as intended)  What would really be gained from that?
This extra -state tree is an interim solution only.  I.e. it is to make 
the NMDA model usable today on current devices that don't yet support 
the operational datastore, rather than having to wait for NMDA 
implementations to be available before the models are usable.


Once the devices support NMDA that they (probably) wouldn't implement 
the extra "-state" module, as you say the same information is available 
in the  datastore with the same semantics.


Effectively what is reported in the extra "-state" tree is the same 
information that would be reported in , and the semantics 
should be the same.


Thanks,
Rob



The issue we were facing in the topology was that different instantiations
of the same (in the model) list element can originate from an intended
configuration, or it can be learned.  If it is intended, it shows up in the
intended / config datastore, but ultimately all topology that is in effect
shows up in the operational datastore.  It is not clear to me what this NMDA
guideline would provide in addition; it seems to not be needed and if
anything seems it would result in redundant operspecification of what's in
the operational datastore?

--- Alex

-Original Message-
From: i2rs [mailto:i2rs-boun...@ietf.org] On Behalf Of Robert Wilton
Sent: Thursday, June 22, 2017 3:44 AM
To: Alexander Clemm <lud...@clemm.org>; i2rs@ietf.org
Cc: 'Nitin Bahadur' <nitin_baha...@yahoo.com>; 'Russ White' <r...@riw.us>;
'Xufeng Liu' <xufeng_...@jabil.com>; h...@packetdesign.com; 'Jan Medved
(jmedved)' <jmed...@cisco.com>; robert.va...@pantheon.sk; 'Susan Hares'
<sha...@ndzh.com>
Subject: Re: [i2rs] I-D Action: draft-ietf-i2rs-yang-network-topo-13.txt

Hi Alex,

Do you think that it would be useful if the draft also included the extra
transient "-state" modules in an appendix (e.g. as per
draft-dsdt-nmda-guidelines-01 section 2)?

Specifically, I'm thinking to help make the topology module fully usable by
modules that augment it (e.g. by the TE modules if/when they adopt the NMDA
conventions), until NMDA implementations before widely available.

Thanks,
Rob


On 22/06/2017 06:29, Alexander Clemm wrote:

Hello I2RS Working Group,

This draft contains the updates to topology model as discussed in Chicago.
This concerned the issue about how to deal with the fact that we can
have configurable overlay topologies that are layered on top of
discovered, or "learned", underlay topologies.  The solution simply relies

on the the

revised datastore architecture.   The "server-provided" data node has been
removed; other than that the structure of the model can remain exactly
the same.  The text has been updated accordingly to provide the

explanations.

--- Alex

-Original Message-
From: i2rs [mailto:i2rs-boun...@ietf.org] On Behalf Of
internet-dra...@ietf.org
Sent: Wednesday, June 21, 2017 10:03 PM
To: i-d-annou...@ietf.org
Cc: i2rs@ietf.org
Subject: [i2rs] I-D Action: draft-ietf-i2rs-yang-network-topo-13.txt


A New Internet-Draft is available from the on-line Internet-Drafts
directories.
This draft is a work item of the Interface to the Routing System of
the IETF.

  Title   : A Data Model for Network Topologies
  Authors : Alexander Clemm
Jan Medved
Robert Varga
Nitin Bahadur
Hariharan Ananthakrishnan
Xufeng Liu
Filename: draft-ietf-i2rs-yang-network-topo-13.txt
Pages   : 35
Date: 2017-06-21

Abstract:
 This document defines an abstract (generic) YANG data model for
 network/service topologies and inventories.  The model serves as a
 base model which is augmented with technology-specific details in
 other, more specific topology and inventory models.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-i2rs-yang-network-topo/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-i2rs-yang-network-topo-13
https://datatracker.ietf.org/doc/html/draft-ietf-i2rs-yang-network-top
o-13

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-i2rs-yang-netw

Re: [i2rs] I-D Action: draft-ietf-i2rs-yang-network-topo-13.txt

2017-06-22 Thread Robert Wilton 

Hi Alex,

Do you think that it would be useful if the draft also included the 
extra transient "-state" modules in an appendix (e.g. as per 
draft-dsdt-nmda-guidelines-01 section 2)?


Specifically, I'm thinking to help make the topology module fully usable 
by modules that augment it (e.g. by the TE modules if/when they adopt 
the NMDA conventions), until NMDA implementations before widely available.


Thanks,
Rob


On 22/06/2017 06:29, Alexander Clemm wrote:

Hello I2RS Working Group,

This draft contains the updates to topology model as discussed in Chicago.
This concerned the issue about how to deal with the fact that we can have
configurable overlay topologies that are layered on top of discovered, or
"learned", underlay topologies.  The solution simply relies on the the
revised datastore architecture.   The "server-provided" data node has been
removed; other than that the structure of the model can remain exactly the
same.  The text has been updated accordingly to provide the explanations.

--- Alex

-Original Message-
From: i2rs [mailto:i2rs-boun...@ietf.org] On Behalf Of
internet-dra...@ietf.org
Sent: Wednesday, June 21, 2017 10:03 PM
To: i-d-annou...@ietf.org
Cc: i2rs@ietf.org
Subject: [i2rs] I-D Action: draft-ietf-i2rs-yang-network-topo-13.txt


A New Internet-Draft is available from the on-line Internet-Drafts
directories.
This draft is a work item of the Interface to the Routing System of the
IETF.

 Title   : A Data Model for Network Topologies
 Authors : Alexander Clemm
   Jan Medved
   Robert Varga
   Nitin Bahadur
   Hariharan Ananthakrishnan
   Xufeng Liu
Filename: draft-ietf-i2rs-yang-network-topo-13.txt
Pages   : 35
Date: 2017-06-21

Abstract:
This document defines an abstract (generic) YANG data model for
network/service topologies and inventories.  The model serves as a
base model which is augmented with technology-specific details in
other, more specific topology and inventory models.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-i2rs-yang-network-topo/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-i2rs-yang-network-topo-13
https://datatracker.ietf.org/doc/html/draft-ietf-i2rs-yang-network-topo-13

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-i2rs-yang-network-topo-13


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

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

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



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

Re: [i2rs] FW: New Version Notification for draft-hares-netmod-i2rs-yang-04.txt

2017-03-21 Thread Robert Wilton 

Hi Sue,

I've only had a very quick scan of the doc, and I think that you may be 
planning to update this to reflect revised-datastores-1 anyway.


But I have one high level question/comment (that I think may equally 
apply to the I2RS impact on NETCONF and RESTCONF):


Is I2RS planning on making changes/additions to the core of YANG to 
support I2RS requirements?  I.e. new YANG statements that would expect 
to be supported by all YANG implementations.


Or, is I2RS planning on defining some I2RS specific extensions to YANG, 
which would also include defining some new I2RS specific datastore(s), 
but that would not change the core of the YANG language?  E.g. rather 
than adding a new "ephemeral" keyword to YANG, the I2RS extension would 
define the "ephemeral" extension statement, which would then be 
annotated in I2RS specific modules as "i2rs:ephemeral true".


I think that the latter approach would be much more preferable if that 
is feasible.


Similar comments to NETCONF and RESTCONF may equally apply (I've not 
read your drafts yet).  I.e. if possible, it is probably better to 
define optional I2RS specific extensions than attempt to bake I2RS 
support into the NETCONF or RESTCONF protocols themselves.


Thanks,
Rob


On 11/03/2017 19:37, Susan Hares wrote:

Russ:

I request a time slot to present a yang syntax that would support I2RS work.

Sue Hares



-Original Message-
From: internet-dra...@ietf.org [mailto:internet-dra...@ietf.org]
Sent: Saturday, March 11, 2017 2:41 PM
To: amit.d...@ericsson.com; Amit Daas; Susan Hares
Subject: New Version Notification for draft-hares-netmod-i2rs-yang-04.txt


A new version of I-D, draft-hares-netmod-i2rs-yang-04.txt
has been successfully submitted by Susan Hares and posted to the IETF 
repository.

Name:   draft-hares-netmod-i2rs-yang
Revision:   04
Title:  Yang for I2RS Protocol
Document date:  2017-03-11
Group:  Individual Submission
Pages:  26
URL:
https://www.ietf.org/internet-drafts/draft-hares-netmod-i2rs-yang-04.txt
Status: https://datatracker.ietf.org/doc/draft-hares-netmod-i2rs-yang/
Htmlized:   https://tools.ietf.org/html/draft-hares-netmod-i2rs-yang-04
Diff:   
https://www.ietf.org/rfcdiff?url2=draft-hares-netmod-i2rs-yang-04

Abstract:
This document requests yang language additions for the data models
that exist as part of the I2RS control plane datastore.  One of these
additions is the ability to mark a portion of the model as having
ephemeral state.

   



Please note that it may take a couple of minutes from the time of submission 
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat


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



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

Re: [i2rs] topo model use of NACM

2017-02-21 Thread Robert Wilton 

Hi Andy,


On 16/02/2017 22:36, Andy Bierman wrote:



On Thu, Feb 16, 2017 at 2:18 PM, Alexander Clemm 
> wrote:


There are actually a number of interesting implications with
regards to NACM.  NACM could indeed be a key to the solution if it
provides sufficient flexibility with regards to articulating and
enforcing authorization rules.  Regarding this, I have a number of
questions/comments:

-If a subtree contains objects that a client does not have write
privileges for, will the client be prevented from locking the
subtree? How about the case when the client does not even have
read privileges?


locking and NACM are 2 different things.
NETCONF has datastore (global) locks and subtree (partial) locks.
There is no mechanism in NACM or elsewhere that constrains the values
that a particular client can use. (NACM controls access to the rpc, 
with no

control over specific input paramters).




The current NACM-bis draft states in section 3.7.2 that this is
not the case – i.e. a client is able to lock an entire subtree,
even in cases when there is not a single object in that subtree
that the client actually has access privileges to.

To me, this does not seem right.  It just invites abuse.

Now, there is still the possibility to restrict access to the
operation overall.  But again, this means that you have to give a
users an all-or-nothing choice.  Too inflexible.  By the same
token that partial locks were supported to avoid requiring anyone
who needs the ability to conduct a transaction to lock down the
entire server, there should be the ability to restrict access to
the lock and partial-lock operation by targeted subtree.  However,
this capability is currently missing.



NACM was designed to be simple to implement.
Some complex features that were in VACM were intentionally left out of 
NACM.

NETCONF locking is also intentionally simple.

I would rather have NETCONF 2.0 use a mandatory implicit, optimistic 
concurrent
locking model, rather than more band-aids on the optional explicit, 
pessimistic

serialized locking model we have now.
This is interesting.  If you have time, then at some point, please can 
you expand on this idea, perhaps on the NETCONF alias?


Thanks,
Rob

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

Re: [i2rs] modeling options for draft-ietf-i2rs-yang-network-topo

2017-02-14 Thread Robert Wilton 

Hi Kent,

I think that the answer depends on when this module needs to be published:

If it needs to be published now, then I think that it should follow the 
standard IETF config/state module conventions and use separate /foo and 
/foo-state trees.  This should make the module most widely usable.  
Would it help if the model defined two "require-instance false" 
dependency leaf refs, one to the potential underlay node in the config 
tree, and a second to the potential underlay node in the state tree?


Otherwise, if this model can be delayed until the revised datastores and 
I2RS work progresses then it could use a single combined config/state 
tree.  It seems that the revised datastore solution would allow for a 
simpler model to be constructed to represent network topologies.


Rob


On 14/02/2017 13:55, Kent Watsen wrote:


[moving yang-doctors to BCC]



OPTION 1: separate /foo and /foo-state trees


This option was/is described here:
https://www.ietf.org/mail-archive/web/i2rs/current/msg04316.html.

PROS:
   a) does NOT break legacy clients (how we got here)
   b) consistent with convention used in many IETF modules
   c) able to show if/how opstate may differ from configured values

CONS:
   a) questionably valid YANG leafref usage

What does this mean?

I'm referring to how the description statement explains that
the server may look to operational state in order to resolve
the leafref, which is to result in behavior similar to
pre-configuration in RFC 7223.




   b) complex server implementation (to handle require-instance false)

Can you elaborate on this one?

This is primarily a reflection of the CON listed above, in that
it seems that a server would need to have special handling for
when dependencies transition from being present to not-present
and vice versa, much like the code to handle when a physical
card is plugged in or removed.

Note: I should've listed this as a CON for OPTION 2 as well.




   c) eventually the module would need to migrate to the long-term
  solution, which would result in needing to also rewrite all
  modules that have augmented it (e.g., ietf-te-topology).
   d) leafref path expressions really only work for configuration data,
  though a clever server could have a special ability to peak at
  the opstate values when doing validations.  Of course, with
  require-instance is false, the value of leafref based validation
  checking is negated anyway, even for config true nodes, so this
  may not matter much.



OPTION 2: explicit client-option to also return tagged opstate data
---

This option takes a couple forms.  The first is module-specific and
the second is generic.  In both cases, the idea is modeled after the
with-defaults solution (RFC6243), wherein the client passes a special
flag into  causing the server to also return opstate data,
having a special metadata flag set, intermingled with the
configuration
data.


2A: Module-specific version

module foo {
   import ietf-netconf { prefix nc; }
   import ietf-yang-metadata { prefix md; }
   md:annotation server-provided {
  type boolean;
   }
   container nodes {
  config true;
  list node {
 key "name";
 leaf name { type string; }
 leaf dependency {
type leafref {
  path "../node/name"
  require-instance false;
}
 }
  }
   }
   augment /nc:get-config/nc:input {
  leaf with-server-provided {
 type boolean;
  }
   }
}

I don't think this solution is substantially different from the
solution in draft-ietf-i2rs-yang-network-topo-10.  You have just moved
a config false leaf to a meta-data annotation.  This solution suffers
from the same problems as the solution in
draft-ietf-i2rs-yang-network-topo-10.

There are two primary differences:

1) It doesn't break legacy clients, because it requires the client to
explicitly pass a 'with-server-provided' flag in the 
request in order to get back the extended response.  Likewise, it
doesn't break backup/restore workflows, as the server can discard
any 'server-provided' nodes passed in an  operation.
Lastly, it doesn't break /, as there is no comingling
of opstate data in the 'running' datastore.

2) It doesn't say anything about how the opstate data is stored on the
server.  The opstate data is not modeled at all.  This approach
only defines a presentation-layer format for how opstate data can
be returned via an RPC.  The server is free to persist the opstate
data anyway it wants, perhaps in an internal datastore called
'operational-state' or in an uber-datastore with the opstate data
flagged with a datastore='oper-state' attribute.  Regardless, it's
an implementation detail, and

[i2rs] Trivial comments on draft-ietf-i2rs-ephemeral-state-21

2016-11-09 Thread Robert Wilton 

Hi,

I was just reviewing the latest version of this draft to see what had 
changed since my last review and spotted a few potential trivial typos, 
in case you have time to correct them:


1. Last paragraph of 1. Introduction:

 "Section 7 provided" => " Section 7 provides"

2. 1.

"filtered evens" => "filtered events"?

7. Ephemeral-REQ-12

"(which includes indicating data node the collision occurred on) => 
"(which includes indicating the data node that the collision occurred on)"


Otherwise the draft looks fine to me.

Thanks,
Rob

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

Re: [i2rs] Comments on Ephemeral-REQ-07 (local config vs. ephemeral)

2016-07-20 Thread Robert Wilton -X (rwilton - ENSOFT LIMITED at Cisco) 
Hi,

Sorry, but I can't make the I2RS meeting because I'm presenting at the end of 
NETCONF.

I've spoken to Sue and understand that the requirement isn't changing here - 
just the text to describe it.

I think that I'm OK with this new text.

One suggestion: Possibly It might help if the text made it clear that the 
priotiy resolution applies to the complete set of ephemeral config vs the 
complete set of local config. I.e. the requirement is not asking for priority 
resolution between the two config sets on a per datanode basis.

But I strongly support getting the requirements draft completed, and hence I 
suspect that whatever text that you agree in the 2nd I2RS meeting will be fine.

Thanks,
Rob


Sent from my Xperia™ tablet

 Joe Clarke (jclarke) wrote 

On 7/20/16 03:42, Susan Hares wrote:
> Joe:
> Yes - you are correct.  Can you help me state this requirement -07 better?

What about:

Ephemeral-REQ-07: Ephemeral configuration and local configuration MUST
each have a priority.  This priority will determine whether ephemeral
configuration or local configuration take precedence.  The I2RS protocol
MUST support this mechanism.

Is this clear and correct enough?

Joe

>
> Sue
>
> -Original Message-
> From: Joe Clarke [mailto:jcla...@cisco.com]
> Sent: Wednesday, July 20, 2016 3:40 AM
> To: Susan Hares; 'Russ White'; i2rs@ietf.org
> Subject: Re: [i2rs] Comments on Ephemeral-REQ-07 (local config vs.
> ephemeral)
>
> On 7/20/16 02:18, Susan Hares wrote:
>>  
>>
>> Here's text that might replace it:
>>
>> Ephemeral-REQ-07: Ephemeral configuration state MUST be able to set a
>> priority on local configuration and ephemeral state.  Based on this
>> priority implementations MUST be able to provide a mechanism to choose
>> which takes precedence. The I2RS Protocol MUST be able to support this
> mechanisms.
>>
>> Any thoughts?
>
> I'm a bit confused by the first sentence.  I think what you're stating is
> that both ephemeral and local configurations MUST have a priority.
> This priority will determine whether ephemeral configuration or local
> configuration take precedence.  The I2RS protocol MUST support this
> mechanism.
>
> Am I correct in my interpretation?
>
> Joe
>
>>
>> Sue
>>
>> -Original Message-
>> From: Russ White [mailto:7ri...@gmail.com]
>> Sent: Wednesday, July 20, 2016 2:09 AM
>> To: 'Joe Clarke'; 'Susan Hares'; i2rs@ietf.org
>> Subject: RE: [i2rs] Comments on Ephemeral-REQ-07 (local config vs.
>> ephemeral)
>>
>>
>> (wg chair hat off) --
>>
>>> I think the idea of extending I2RS priority to local config operators
>> (e.g., CLI)
>>> will still work.  Let's take knob 1.  Knob 1 is kind of like the
>>> on/off
>> switch.  If I
>>> don't want I2RS to have any effect on operational state, I'd have
>>> this
>> off.  In
>>> the I2RS priority case, by default my local config could will have
>>> the
>> highest
>>> priority (let's say that's 255 to make it concrete).  In this case no
>> ephemeral
>>> config can win.
>>
>> I wanted to extend Joe's remarks a bit... On reflection, I actually
>> think having priority + "this wins" bits is rather confusing, and
>> opens the door to all sorts of strange behavior. Say I have two items
>> thus --
>>
>> Local config item -- priority 100
>> I2RS config item -- priority 200, don't overwrite bit set
>>
>> If the higher priority is supposed to win, then which item should the
>> operator find in the resulting running config? Should it be the I2RS
>> version, because the priority is higher, or the local config, because
>> the "don't overwrite" bit is set? There doesn't seem to be any clear
>> way to interpret such a situation.
>>
>> It's better to have a single "thing" that determines which
>> configuration among many wins, rather than two.
>>
>> -r
>>
>>
>
>

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

Re: [i2rs] I-D Action: draft-ietf-i2rs-ephemeral-state-13.txt

2016-07-05 Thread Robert Wilton 

Hi Sue,

Looking at requirement REQ-07, I had a further clarifying question:

3.4. Ephemeral Configuration overlapping Local Configuration

   Ephemeral-REQ-07: Ephemeral configuration state could override
   overlapping local configuration state, or vice-versa.
   Implementations MUST provide a mechanism to choose which takes
   precedence.  This mechanism MUST include local configuration (policy)
   and MAY be provided via the I2RS protocol mechanisms.


It is unclear to me whether this requirement only covers the specific 
case that a datanode for the same YANG schema leaf exists with two 
different values in both the local configuration and ephemeral 
configuration datastores, or whether it is also necessary to allow one 
datastore to override the other datastore by deleting a datanode for the 
same YANG schema leaf.


E.g. if ephemeral ds overrides local configuration ds, and the local 
config ds has leaf foo=true, and ephemeral wants to override and force 
leaf foo to be deleted altogether.


Thanks,
Rob


On 01/07/2016 21:07, internet-dra...@ietf.org wrote:

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Interface to the Routing System of the IETF.

 Title   : I2RS Ephemeral State Requirements
 Authors : Jeff Haas
   Susan Hares
Filename: draft-ietf-i2rs-ephemeral-state-13.txt
Pages   : 11
Date: 2016-07-01

Abstract:
This document covers requests to the NETMOD and NETCONF Working
Groups for functionality to support the ephemeral state requirements
to implement the I2RS architecture.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-i2rs-ephemeral-state/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-i2rs-ephemeral-state-13

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-i2rs-ephemeral-state-13


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

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



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

Re: [i2rs] Review of draft-ietf-i2rs-ephemeral-state-11

2016-06-30 Thread Robert Wilton 

Hi Sue,

All fine with me.  A couple of comments inline ...


On 30/06/2016 17:15, Susan Hares wrote:


Robert:

Thank you for your comments.  See resolution of comments below. 
Version -12 will be sent to the list to handle most of these comments.


Sue

*From:*i2rs [mailto:i2rs-boun...@ietf.org] *On Behalf Of *Robert Wilton
*Sent:* Monday, June 27, 2016 11:30 AM
*To:* i2rs@ietf.org
*Subject:* [i2rs] Review of draft-ietf-i2rs-ephemeral-state-11

Hi,

I've reviewed draft-ietf-i2rs-ephemeral-state-11 and given a few minor 
comments below.  Generally I think that I understand the requirements 
stated in this document.


Minors comments:

1) Ephemeral-REQ-01 (page 5):

   Ephemeral-REQ-01: I2RS requires ephemeral state; i.e. state that does
   not persist across reboots.  If state must be restored, it should be
   done solely by replay actions from the I2RS client via the I2RS
   agent.

The architecture document indicates that the ephemeral state would (or 
is that may) also be lost on other circumstances such as process 
restart of the I2RS agent.  Does this need to be clarified in the 
requirement?  E.g.


Sue: In our previous discussions,  other people suggest that “reboots” 
covered hardware and software reboot of the I2RS agent.   And that the 
specific nature of the reboot was too-much information for the 
requirement.



Rob: OK.


   Ephemeral-REQ-01: I2RS requires ephemeral state; i.e. state that MUST
   NOT persist across reboots of the device or I2RS Agent subsystem. If
   state must be restored, it should be done solely by replay actions
   from the I2RS client via the I2RS agent.

2) Hierarchy: (page 5)
Based on the previous description, I would possibly split 
Ephemeral-REQ-06 up into the following requirements:


Old (from ephemeral-state:10):

   Ephemeral-REQ-06: The ability to augment an object with appropriate
   YANG structures that have the property of being ephemeral.  An object
   defined as any one of the following: yang module, submodule or
   components of submodule, or schema node.

Old (from ephemeral-state-11):

   Ephemeral-REQ-06: The ability to augment Yang schema nodes with
   additional Yang Schema nodes that have the property of being
   ephemeral.

Proposed:

   Ephemeral-REQ-06:
   1. The ability to define a YANG module or submodule schema that
   only contains data nodes with the property of being ephemeral.
   2. The ability to augment a YANG data model with additional YANG
   schema nodes that have the property of being ephemeral.

I will accept this change and release in it version-12.

3) Ephemeral-REQ-07: (page 6):

   Ephemeral-REQ-07: Ephemeral configuration state could override
   overlapping local configuration state, or vice-versa.
   Implementations MUST provide a mechanism to choose which takes
   precedence.  This mechanism MUST include local configuration (policy)
   and MAY be provided via the I2RS protocol mechanisms.

I note that this requirement doesn't specify the scope of whether the 
override mechanism should operate globally or on a per data node 
basis.  I'm not sure whether this needs to be clarified - since the 
text in the architecture document makes it pretty clear that a global 
level resolution is sufficient.


Sue:  Again, we were cautioned to not specify the design, but only 
provide a result.  The global is sufficient.



Rob: OK


4) Ephemeral-REQ-08: (page 6):
Similar to Juergen's comments, I'm concerned about the 
writable/non-writable requirement.


   Ephemeral-REQ-08: Yang MUST have a way to indicate in a data model
   that schema nodes have the following properties: ephemeral, writable/
   not-writable, and status/configuration.

I'm somewhat adverse to writable operational state, and hence I would 
prefer if this requirement was watered down to something like:


   Ephemeral-REQ-08: In addition to config true/false, there MUST be a
   way to indicate that YANG schema nodes represent ephemeral state.
   It is desirable to allow for, and have to way to indicate, config
   false YANG schema nodes that are writable operational state.

Sue: You are Juergen are concerned about writeable/non-writeable.  
 Martin is concerned about status/configuration.  The I2RS authors 
believe we are running into the different operational state models. 
 Each time we change this requirement we get another response.   The 
requirement will stay for now.  I suspect the we will be working on 
the design of the solution after we have settled on the operational 
state models.



Rob:
My actual concern is that what I have proposed as a datastore solution 
cannot meet this requirement, because I think that only configuration 
should be writable, and hence the writable/non-writable property is 
implicit.




5) Ephemeral-Req-12, page 7:
Presumably the requirement is that the notification must indicate the 
node that we involved in the collision?  I.e. it isn't sufficient to 
just signal to the client that there has been a collision with some

[i2rs] Review of draft-ietf-i2rs-ephemeral-state-11

2016-06-27 Thread Robert Wilton 

Hi,

I've reviewed draft-ietf-i2rs-ephemeral-state-11 and given a few minor 
comments below.  Generally I think that I understand the requirements 
stated in this document.


Minors comments:

1) Ephemeral-REQ-01 (page 5):

   Ephemeral-REQ-01: I2RS requires ephemeral state; i.e. state that does
   not persist across reboots.  If state must be restored, it should be
   done solely by replay actions from the I2RS client via the I2RS
   agent.

The architecture document indicates that the ephemeral state would (or 
is that may) also be lost on other circumstances such as process restart 
of the I2RS agent.  Does this need to be clarified in the requirement?  E.g.


   Ephemeral-REQ-01: I2RS requires ephemeral state; i.e. state that MUST
   NOT persist across reboots of the device or I2RS Agent subsystem. If
   state must be restored, it should be done solely by replay actions
   from the I2RS client via the I2RS agent.


2) Hierarchy: (page 5)
Based on the previous description, I would possibly split 
Ephemeral-REQ-06 up into the following requirements:


Old (from ephemeral-state:10):

   Ephemeral-REQ-06: The ability to augment an object with appropriate
   YANG structures that have the property of being ephemeral.  An object
   defined as any one of the following: yang module, submodule or
   components of submodule, or schema node.

Old (from ephemeral-state-11):

   Ephemeral-REQ-06: The ability to augment Yang schema nodes with
   additional Yang Schema nodes that have the property of being
   ephemeral.

Proposed:

   Ephemeral-REQ-06:
 
   1. The ability to define a YANG module or submodule schema that

   only contains data nodes with the property of being ephemeral.

   2. The ability to augment a YANG data model with additional YANG
   schema nodes that have the property of being ephemeral.


3) Ephemeral-REQ-07: (page 6):

   Ephemeral-REQ-07: Ephemeral configuration state could override
   overlapping local configuration state, or vice-versa.
   Implementations MUST provide a mechanism to choose which takes
   precedence.  This mechanism MUST include local configuration (policy)
   and MAY be provided via the I2RS protocol mechanisms.

I note that this requirement doesn't specify the scope of whether the 
override mechanism should operate globally or on a per data node basis.  
I'm not sure whether this needs to be clarified - since the text in the 
architecture document makes it pretty clear that a global level 
resolution is sufficient.



4) Ephemeral-REQ-08: (page 6):
Similar to Juergen's comments, I'm concerned about the 
writable/non-writable requirement.



   Ephemeral-REQ-08: Yang MUST have a way to indicate in a data model
   that schema nodes have the following properties: ephemeral, writable/
   not-writable, and status/configuration.

I'm somewhat adverse to writable operational state, and hence I would 
prefer if this requirement was watered down to something like:


   Ephemeral-REQ-08: In addition to config true/false, there MUST be a
   way to indicate that YANG schema nodes represent ephemeral state.
   It is desirable to allow for, and have to way to indicate, config
   false YANG schema nodes that are writable operational state.


5) Ephemeral-Req-12, page 7:
Presumably the requirement is that the notification must indicate the 
node that we involved in the collision?  I.e. it isn't sufficient to 
just signal to the client that there has been a collision with some of 
their configuration?


   Ephemeral-REQ-12: When a collision occurs as two clients are trying
   to write the same data node, this collision is considered an error
   and priorities were created to give a deterministic result.  When
   there is a collision, a notification MUST BE sent to the original
   client to give the original client a chance to deal with the issues
   surrounding the collision.  The original client may need to fix their
   state.

Should this be made explicit?  E.g. perhaps:

   Ephemeral-REQ-12: When a collision occurs as two clients are trying
   to write the same data node, this collision is considered an error
   and priorities were created to give a deterministic result.  When
   there is a collision, a notification (indicating which data node the
   collision occurred on) MUST BE sent to the original client to give
   the original client a chance to deal with the issues surrounding
   the collision.  The original client may need to fix their state.


6) Ephemeral-REQ-14, page 7:
I would suggest potentially rewording this to make the requirement and 
leeway on the solution more explicit.


   Ephemeral-REQ-14: If two clients have the same priority, the
   architecture says the first one wins.  The I2RS protocol has this
   requirement to prevent oscillations between clients.  If one uses the
   last wins scenario, you may oscillate.  That was our opinion, but a
   design which prevents oscillation is the key point.

Proposed alternative text:

   Ephemeral-REQ-14: A deterministic

Re: [i2rs] comments on draft-ietf-i2rs-ephemeral-state-10

2016-06-23 Thread Robert Wilton 

Yes.

Thanks,
Rob


On 23/06/2016 17:19, Susan Hares wrote:

Robert:

I changed Ephemeral-REQ-03 to:

Ephemeral-REQ-03: Ephemeral state may have constraints that refer
  to operational state, this includes potentially fast changing or
  short lived operational state nodes, such as MPLS LSP-ID or a BGP
IN-RIB.

Is this OK?

Sue

-Original Message-
From: i2rs [mailto:i2rs-boun...@ietf.org] On Behalf Of Robert Wilton
Sent: Thursday, June 23, 2016 12:00 PM
To: Susan Hares; 'Juergen Schoenwaelder'
Cc: i2rs@ietf.org
Subject: Re: [i2rs] comments on draft-ietf-i2rs-ephemeral-state-10

Hi,


On 23/06/2016 16:47, Susan Hares wrote:

Juergen and Robert:

I will use the following for Ephemeral-REQ-03.

Ephemeral-REQ-03: Ephemeral state must be able to utilized temporary
   operational state (e.g.  MPLS LSP-ID or a BGP IN-RIB) as a
   constraints.

That is the original text.  Am I correct in assuming that you meant this
text instead?:

Ephemeral-REQ-03: Ephemeral state must be able to utilize operational state
(e.g. MPLS LSP-ID or BGP In-RIB) as a constraint.

If so, this proposed text is OK with me.



On Ephemeral-REQ-04,


Ephemeral-REQ-04: Ephemeral state MAY refer to non-ephemeral state
for purposes of implementing constraints.

Non-ephemeral state is both configuration state (config true), and
operational state (config false).

I believe these are two different requirements.

Yes.  Given that REQ-03 covers using operational state as a constraint, then
would it be sufficient to word REQ-04 as:

Ephemeral-REQ-04: Ephemeral state MAY refer to non-ephemeral configuration
for purposes of implementing constraints.

Or perhaps to relate it more closely to REQ-03, as:

Ephemeral-REQ-03: Ephemeral state must be able to utilize non-ephemeral
configuration as a constraint.

Or is this missing something out?

Thanks,
Rob



Sue

-Original Message-
From: i2rs [mailto:i2rs-boun...@ietf.org] On Behalf Of Juergen
Schoenwaelder
Sent: Thursday, June 23, 2016 11:42 AM
To: Robert Wilton
Cc: i2rs@ietf.org
Subject: Re: [i2rs] comments on draft-ietf-i2rs-ephemeral-state-10

On Thu, Jun 23, 2016 at 03:12:50PM +0100, Robert Wilton wrote:

Hi,

On 23/06/2016 13:02, Juergen Schoenwaelder wrote:

Hi,

here are few comments on the latest version.

  Ephemeral-REQ-03: Ephemeral state must be able to utilized

temporary

  operational state (e.g.  MPLS LSP-ID or a BGP IN-RIB) as a
  constraints.

I am not sure what 'must be able to utilized temporary operational
state as constraints' means. The text in the parenthesis does not
help me understand this better. Did you want to say something like:
'Ephemeral configuration state may have constraints that refer to
operational state'? I am using 'ephemeral configuration state' since
this is used in other places (although sometimes worded slightly
different).

I asked a similar question in the I2RS  interim meeting yesterday, I
think that Sue's spoken explanation of the requirement was effectively:

 Ephemeral-REQ-03: Ephemeral state may have constraints that refer
 to operational state, this includes potentially fast changing or
 short lived operational state nodes, such as MPLS LSP-ID or a BGP

IN-RIB.

Perhaps this wording is more clear?

Yes, this is clearer. One question of course is what is expected to
happen if constraints are becoming false due to (fast) operational
state changes, that is, what the expected consequence of this is.


  Ephemeral-REQ-04: Ephemeral state MAY refer to non-ephemeral state
  for purposes of implementing constraints.

Hm, now I wonder whether this is just a special case of
Ephemeral-REQ-03 and if so it is not clear why we need this as a
separate requirement. If this is not the case but something
different, then likely my interpretation of Ephemeral-REQ-03 is wrong.

I think that ephemeral state could also use configuration nodes as a
constraint, so it isn't just operational state covered by REQ-3.

Well, the Ephemeral-REQ-04 text says 'non-ephemeral state' - if your
interpretation is correct than this phrase is wrong or possibly

misleading.

/js


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

.



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

Re: [i2rs] comments on draft-ietf-i2rs-ephemeral-state-10

2016-06-23 Thread Robert Wilton 

Hi,


On 23/06/2016 16:47, Susan Hares wrote:

Juergen and Robert:

I will use the following for Ephemeral-REQ-03.

Ephemeral-REQ-03: Ephemeral state must be able to utilized temporary
  operational state (e.g.  MPLS LSP-ID or a BGP IN-RIB) as a
  constraints.
That is the original text.  Am I correct in assuming that you meant this 
text instead?:


Ephemeral-REQ-03: Ephemeral state must be able to utilize operational state
(e.g. MPLS LSP-ID or BGP In-RIB) as a constraint.

If so, this proposed text is OK with me.




On Ephemeral-REQ-04,


Ephemeral-REQ-04: Ephemeral state MAY refer to non-ephemeral state
for purposes of implementing constraints.

Non-ephemeral state is both configuration state (config true), and
operational state (config false).

I believe these are two different requirements.
Yes.  Given that REQ-03 covers using operational state as a constraint, 
then would it be sufficient to word REQ-04 as:


Ephemeral-REQ-04: Ephemeral state MAY refer to non-ephemeral configuration
for purposes of implementing constraints.

Or perhaps to relate it more closely to REQ-03, as:

Ephemeral-REQ-03: Ephemeral state must be able to utilize non-ephemeral
configuration as a constraint.

Or is this missing something out?

Thanks,
Rob




Sue

-Original Message-
From: i2rs [mailto:i2rs-boun...@ietf.org] On Behalf Of Juergen Schoenwaelder
Sent: Thursday, June 23, 2016 11:42 AM
To: Robert Wilton
Cc: i2rs@ietf.org
Subject: Re: [i2rs] comments on draft-ietf-i2rs-ephemeral-state-10

On Thu, Jun 23, 2016 at 03:12:50PM +0100, Robert Wilton wrote:

Hi,

On 23/06/2016 13:02, Juergen Schoenwaelder wrote:

Hi,

here are few comments on the latest version.

 Ephemeral-REQ-03: Ephemeral state must be able to utilized temporary
 operational state (e.g.  MPLS LSP-ID or a BGP IN-RIB) as a
 constraints.

I am not sure what 'must be able to utilized temporary operational
state as constraints' means. The text in the parenthesis does not
help me understand this better. Did you want to say something like:
'Ephemeral configuration state may have constraints that refer to
operational state'? I am using 'ephemeral configuration state' since
this is used in other places (although sometimes worded slightly
different).

I asked a similar question in the I2RS  interim meeting yesterday, I
think that Sue's spoken explanation of the requirement was effectively:

Ephemeral-REQ-03: Ephemeral state may have constraints that refer
to operational state, this includes potentially fast changing or
short lived operational state nodes, such as MPLS LSP-ID or a BGP

IN-RIB.

Perhaps this wording is more clear?

Yes, this is clearer. One question of course is what is expected to happen
if constraints are becoming false due to (fast) operational state changes,
that is, what the expected consequence of this is.


 Ephemeral-REQ-04: Ephemeral state MAY refer to non-ephemeral state
 for purposes of implementing constraints.

Hm, now I wonder whether this is just a special case of
Ephemeral-REQ-03 and if so it is not clear why we need this as a
separate requirement. If this is not the case but something
different, then likely my interpretation of Ephemeral-REQ-03 is wrong.

I think that ephemeral state could also use configuration nodes as a
constraint, so it isn't just operational state covered by REQ-3.

Well, the Ephemeral-REQ-04 text says 'non-ephemeral state' - if your
interpretation is correct than this phrase is wrong or possibly misleading.

/js



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

Re: [i2rs] comments on draft-ietf-i2rs-ephemeral-state-10

2016-06-23 Thread Robert Wilton 

Hi,

On 23/06/2016 13:02, Juergen Schoenwaelder wrote:

Hi,

here are few comments on the latest version.

Ephemeral-REQ-03: Ephemeral state must be able to utilized temporary
operational state (e.g.  MPLS LSP-ID or a BGP IN-RIB) as a
constraints.

I am not sure what 'must be able to utilized temporary operational
state as constraints' means. The text in the parenthesis does not help
me understand this better. Did you want to say something like:
'Ephemeral configuration state may have constraints that refer to
operational state'? I am using 'ephemeral configuration state' since
this is used in other places (although sometimes worded slightly
different).
I asked a similar question in the I2RS  interim meeting yesterday, I 
think that Sue's spoken explanation of the requirement was effectively:


   Ephemeral-REQ-03: Ephemeral state may have constraints that refer
   to operational state, this includes potentially fast changing or
   short lived operational state nodes, such as MPLS LSP-ID or a BGP IN-RIB.

Perhaps this wording is more clear?




Ephemeral-REQ-04: Ephemeral state MAY refer to non-ephemeral state
for purposes of implementing constraints.

Hm, now I wonder whether this is just a special case of
Ephemeral-REQ-03 and if so it is not clear why we need this as a
separate requirement. If this is not the case but something different,
then likely my interpretation of Ephemeral-REQ-03 is wrong.
I think that ephemeral state could also use configuration nodes as a 
constraint, so it isn't just operational state covered by REQ-3.




s/2RS/I2RS in Ephemeral-REQ-05. I would actually rewrite the beginning
of Ephemeral-REQ-05 as follows:

Ephemeral-REQ-05: I2RS interactions may
lead to undesirable or unsustainable resource consumption on a system
implementing an I2RS Agent.  It is RECOMMENDED that mechanisms be
made available to permit prioritization of I2RS interactions, when
appropriate, to permit implementations to shed work load when
operating under constrained resources.  An example of such a work
shedding mechanism is rate-limiting.

I would remove the Note: since I believe the key observation here are
the potentially high volume of I2RS interactions and not the fact that
there is a datastore involved that is ephemeral.

I am still struggling with Ephemeral-REQ-06:

Ephemeral-REQ-06: The ability to augment an object with appropriate
YANG structures that have the property of being ephemeral.  An object
defined as any one of the following: yang module, submodule or
components of submodule, or schema node.

Perhaps this is what you wanted to say?

Ephemeral-REQ-06: The ability to augment YANG schema nodes with
additional YANG schema nodes that have the property of being
ephemeral.

I wonder why there are some ephemeral state requirements in sections
labeled with "I2RS Protocol version 1" while others seem to be
protocol version agnostic. What is the definition of I2RS protocol
versions?  Perhaps this notion of protocol version should simply be
removed; I am not sure it helps with the requirements.

Ephemeral-REQ-08: Yang MUST have a way to indicate in a data model
that nodes have the following properties: ephemeral, writable/not-
writable, and status/configuration.

This is confusing because it says 'nodes' while in YANG we distinguish
data nodes and schema nodes. For example, in YANG a schema node has a
property config true|false. This schema node property defines whether
corresponding data nodes are writable/non-writable. In other words,
some of this requirement seems to be covered by YANG already; so what
remains is the 'ephemeral' property - does the requirement expect this
to be a property of a schema node?
This also came up in the meeting yesterday.  My understanding is that 
there is a desire to be able to mark ephemeral operational state nodes 
in the YANG schema as writable.  One example given was to be able to 
have a single topology table that is predominantly learned from OSPF and 
ISIS but also have some static client entries added as well.


Personally, I would prefer that all operational state is read only, and 
to restrict writable nodes to configuration only.


Hence, this leads me to wonder whether the actual desire here is really 
to be able to have tables of ephemeral state (i.e. YANG lists) that 
consist of both ephemeral configuration and ephemeral state entries.


Rob




Editorial: s/prevent was the oscillation/prevent oscillation/

/js



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

[i2rs] Clarifications on draft-ietf-i2rs-ephemeral-state section 3

2016-06-20 Thread Robert Wilton 

Hi Jeff, Susan,

In one of the discussions that I had with Juergen regarding datastores 
he indicated the refined datastore architecture that I was proposing 
wasn't in keeping with the current ephemeral datastore ideas on I2RS, 
hence I'm trying to catch up.


I have a few clarifying questions on sections 3.2 of 
draft-ietf-i2rs-ephemeral-state that you might be able to help with me 
please.  I've only just signed up the IR2S, so apologies if these 
questions have already been asked/answered.


Section 3.1. Persistence, paragraph 1 is stated as:

   Ephemeral-REQ-01: I2RS requires ephemeral state; i.e. state that does
   not persist across reboots.  If state must be restored, it should be
   done solely by replay actions from the I2RS client via the I2RS
   agent.  Ephemeral state may consist of ephemeral configuration or
   ephemeral operational state, or both.

This text makes it clear that "Ephemeral state" consists of both 
"ephemeral config" and/or "ephemeral operation state".


Ephemeral-REQ-03 is stated as:

   Ephemeral-REQ-03: Ephemeral state must be able to utilized temporary
   operational state (e.g.  MPLS LSP-ID or a BGP IN-RIB) as a
   constraints.

Q1. Am I right in understanding that both ephemeral config and ephemeral 
operational state independently have the requirement that they have to 
rely on regular operational state as a constraint?


Q2. What is expected to happen if the operational state changes such 
that the constraint no longer hold for a ephemeral node? Should that 
node be removed, or just stop taking effect?  Or expressed differently: 
could ephemeral config be regarded as being conditionally applied on a 
constraint?


Ephemeral-REQ-04 is stated as:

   Ephemeral-REQ-04: Ephemeral state MAY refer to non-ephemeral state
   for purposes of implementing constraints.  The designer of ephemeral
   state modules are advised that such constraints may impact the speed
   of processing ephemeral state commits and should avoid them when
   speed is essential.

Q3. I think that REQ-03 may already answer this, but to avoid any 
confusion: Does this mean that ephemeral config nodes may refer to 
non-ephemeral operational state nodes?


Thanks,
Rob



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