[netmod] "enabled" functionality in draft-ietf-netmod-routing-cfg-18

[Acee Lindem (acee)]

For both the routing-instance and routing-protocol, there is explicit
support, via the “enabled” leaf, for retaining the respective information
in the configuration but removing it from the operational state. This new
functionality would be better provided with generic infra-structure to
include or omit configuration rather than a mandatory leaf in introduced
in these models. Those working on the IGP models (OSPF and IS-IS) reached
consensus that “enabled" should be removed from the ietf-routing model and
the IGPs will model the existing protocol administrative controls. Any
objections? 

Thanks,
Acee 


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

Re: [netmod] draft-ietf-netmod-routing-cfg-18

[Acee Lindem (acee)]

On 5/14/15, 12:16 PM, "Behcet Sarikaya"  wrote:

>Hi all,
>
>I am new to this list, I just sent my subscription request, if it
>doesn't go thru, I hope that chairs can subscribe me.
>
> I have been reading this draft and have a few comments:
>
>The draft defines one RPC operation called fib-route to query a
>routing instance for the active route in the FIB. As such it seems to
>be a read operation.
>What about write or modify type of operations? Are they not needed?

Currently, this use-case is under the purview of the I2RS WG.

Acee 




>
>In Appendix D an example get reply is given, which is useful.
>What about fib-route?
>
>Regards,
>
>Behcet
>
>___
>netmod mailing list
>netmod@ietf.org
>https://www.ietf.org/mailman/listinfo/netmod

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

Re: [netmod] IANA Consideration

[Acee Lindem (acee)]

Hi Lada, 

On 6/30/15, 4:52 AM, "Ladislav Lhotka"  wrote:

>Hi,
>
>is it OK that 6020bis again defines “YANG Module Names” registry? It was
>already defined in RFC 6020 so I’d say it shouldn’t be repeated.

Normally when an RFC is obsoleted by a bis version, the original IANA
considerations are retained. At least that has been my experience both for
bis versions that I have authored and bis version that I have reviewed.

Thanks,
Acee 



>
>Also, the two registered namespace URIs should IMO be
>
> URI: urn:ietf:params:xml:ns:yang:yin:1.1
> URI: urn:ietf:params:xml:ns:yang:1.1
>
>Lada
>
>--
>Ladislav Lhotka, CZ.NIC Labs
>PGP Key ID: E74E8C0C
>
>
>
>
>___
>netmod mailing list
>netmod@ietf.org
>https://www.ietf.org/mailman/listinfo/netmod

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

Re: [netmod] Y34

[Acee Lindem (acee)]

I think being able to place a given model anywhere in the device tree
would be useful and this would allow a model to be rooted in different
locations on different devices. Similarly, we’d need the ability to prefix
XPATH references to data nodes in the model with the root.
Thanks,
Acee 

On 7/20/15, 11:00 PM, "netmod on behalf of Juergen Schoenwaelder"
 wrote:

>Lada,
>
>Y34 is closed and I have not seen any new argument here that indicates
>we made a major mistake with the resolution of Y34. As such, Y34
>remains closed.
>
>If you want to discuss new ideas to relocate or "symlink" data models,
>please do so in a separate thread. (And no, we do not accept new
>issues for YANG 1.1 either at this point in time.)
>
>/js
>
>On Mon, Jul 20, 2015 at 07:42:49PM +0200, Ladislav Lhotka wrote:
>> 
>> > On 20 Jul 2015, at 19:29, Andy Bierman  wrote:
>> > 
>> > 
>> > 
>> > On Mon, Jul 20, 2015 at 10:15 AM, Ladislav Lhotka 
>>wrote:
>> > 
>> > > On 20 Jul 2015, at 17:00, Andy Bierman  wrote:
>> > >
>> > >
>> > >
>> > > On Mon, Jul 20, 2015 at 6:08 AM, Ladislav Lhotka 
>>wrote:
>> > >
>> > > > On 20 Jul 2015, at 14:55, Andy Bierman  wrote:
>> > > >
>> > > > Hi,
>> > > >
>> > > > Can you explain why we need 2 broken anyxmls?
>> > > > (The original and a synonym?)  The whole point of
>> > > > anydata is that it does not have XML cruft in it.
>> > >
>> > > Yes, I understand this was your main priority. For implementors
>>using off-the-shelf XML parsers and tools the XML cruft is not an issue
>>at all.
>> > >
>> > >
>> > > yes it is an issue.
>> > > We need something to model a container full of arbitrary YANG data
>>nodes.
>> > > This is something that can be applied to the contents of a
>>datastore.
>> > 
>> > anyxml can do that, too.
>> > 
>> > 
>> > the WG already decided it can't.
>> > The extra XML PIs, etc. are not accepted by all servers, remember?
>> > There is no use for the extra stuff in the datastore.
>> >  I don't see why we need 2 anyxml constructs that are not
>> > supported by the industry.  One is already too many.
>> 
>> I agree, but this is what we are going to have. My proposal was to have
>>just one with two different names.
>> 
>> > 
>> > 
>> > >
>> > >
>> > > Anyway, I believe there are use cases for arbitrary XML/JSON/CBOR/…
>>with no (YANG) schema available. My only complaint to “anyxml” has
>>always been that it is a misnomer for encodings other than XML.
>> > >
>> > > The message encoding on the wire is not the same issue
>> > > as the contents of a datastore.  Our server stores its own
>> > > internal data structures.  XML, JSON, CBOR are just message
>> > > encoding formats between client and server.  The datastore
>> > > is not encoded in any of these formats.
>> > 
>> > The payload of anyxml needn’t directly map to a data subtree in the
>>usual sense.
>> > 
>> > that's precisely the difference between anyxml and anydata.
>> > The anydata node MUST map directly into data subtrees.
>> 
>> If the server doesn’t know the YANG data model at run time (which is
>>possible) then it cannot do it - for instance, it cannot properly map
>>module names to namespace URI or handle lists.
>> 
>> > 
>> >  
>> > 
>> > >
>> > >
>> > >
>> > >
>> > >
>> > > >
>> > > > I also don't get the value of a single top-level node called
>>'device'
>> > > > that every YANG model on the planet is supposed to augment.
>> > > > Can you explain why a protocol operation to retrieve the
>> > > > document root (/) is not sufficient for the top-level node?
>> > >
>> > > I don’t intend to defend their model, the more serious problem IMO
>>is that a model for a single device/function may be needed in another
>>device that hosts many virtualised devices/functions of the former type.
>>We don’t have a good solution for this rather typical situation.
>> > >
>> > > But a single container called "whatever" provides no such
>>aggregation.
>> > > You would need a list for that. And the NMS might have multiple
>> > > layers of hierarchy to represent various aggregations.  The NP
>> > > container called "device" is not helpful for aggregation.
>> > 
>> > The parent node can be a list as well. The “root” node would be like
>>a mount point in a Unix filesystem.
>> > 
>> > 
>> > Are you saying all data on a device needs to be in a top-level list
>>called 'device'
>> > because an NMS might exist that  wants to have the datastores from
>>lots of devices?
>> > As Martin pointed out several times, the NMS can make its own
>>container or
>> > lists.  It does not need the device to mirror its own structure.
>> 
>> As I said, I don’t care that much about the “device” container. What
>>would be really useful is to have the possibility to do e.g. this:
>> 
>> virtual-node* [name]
>> name
>> if:interfaces
>> ...
>> 
>> to support the use case where all virtual nodes are managed by the same
>>NETCONF/RESTCONF server.
>> 
>> Lada
>> 
>> >  
>> > 
>> > 
>> > Lada
>> > 
>> > Andy
>> >  
>> > 
>> > >
>> > >
>> > >
>> > > Lada
>> > >
>> > >
>>

Re: [netmod] Y34

[Acee Lindem (acee)]

Hi Juergen, 

On 8/1/15, 2:51 AM, "netmod on behalf of Juergen Schoenwaelder"
 wrote:

>On Fri, Jul 31, 2015 at 12:46:49PM -0400, Lou Berger wrote:
>> Andy,
>> 
>> On 07/27/2015 12:58 PM, Andy Bierman wrote:
>> > Hi,
>> > 
>> > I don't think a standard for relocating subtrees would be worth it.
>> > I am not in favor of moving /interfaces or /system to a new location.
>> > That's not how YANG works. It only allows "obsolete and start over".
>> > 
>> > I would suggest pursuing solutions that don't cause
>> > as much disruption and expense as possible.
>> > 
>> 
>> I think it would be really good to explore other, less "disruptive"
>> options.
>>
>
>I think the first step is to find out whether there is a problem worth
>to be fixed. Why are the RFCs in question broken? (Yes, I have read
>the openconfig IDs,

Section 1.1 in 
https://www.ietf.org/id/draft-openconfig-netmod-model-structure-00.txt
lists the goals of a generic model structure that will accommodate most
modern network devices. I guess you don’t agree that these are desirable?

Thanks,
Acee 



>I listened to the virtual interim meetings, I
>assume you have read draft-bjorklund-netmod-openconfig-reply.)



>
>Lets get the core of the openconfig argument on the table why the
>existing RFCs are flawed.
>
>/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

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

Re: [netmod] Y34 - root node

[Acee Lindem (acee)]

I think there is agreement that there is a problem. The YANG Routing Design 
Team is  addressing this with 
https://www.ietf.org/id/draft-rtgyangdt-rtgwg-device-model-00.txt  (which has 
evolved from 
https://www.ietf.org/id/draft-openconfig-netmod-model-structure-00.txt). In 
essence, a place for everything and everything in its place. However, there are 
those who feel that can’t mandate a single model structure for network devices 
and we need mechanisms to manage multiple models but allow for different device 
structure (e.g., 
https://www.ietf.org/id/draft-bierman-netmod-yang-package-00.txt).  I hope we 
can agree on an approach in the coming interim meetings.

Thanks,
Acee



From: netmod mailto:netmod-boun...@ietf.org>> on 
behalf of "Einar Nilsen-Nygaard (einarnn)" 
mailto:eina...@cisco.com>>
Date: Monday, August 10, 2015 at 5:29 AM
To: Jonathan Hansford mailto:jonat...@hansfords.net>>
Cc: NETMOD Working Group mailto:netmod@ietf.org>>
Subject: Re: [netmod] Y34 - root node

As someone sharing responsibilities for guiding a number of development teams 
both defining new models and implementing to some already defined models in 
this area, I can only agree with this addition to what I said earlier.

Cheers,

Einar

On Aug 10, 2015, at 9:46 AM, Jonathan Hansford 
mailto:jonat...@hansfords.net>> wrote:

 And it is not just end users who need help to better understand YANG models 
and how to use them. For those still on the edge, looking to finally take the 
plunge and use NETCONF/YANG to configure their devices, help is also required 
to determine how best to structure their YANG models, make use of the existing 
ones, etc. For those who have "grown up" with the developments in NETCONF and 
YANG, much of this is probably second nature. But coming to it cold (in the 
sense of compiling/writing a first set of YANG models for a device; I've been 
following the netconf/netmod WGs for 3+ years), it still feels very much like a 
dark art! It is not just the individual modules, it is how to put them together 
to best manage a device (let alone a system).

Jonathan



- Original Message -
From:
"Einar Nilsen-Nygaard (einarnn)" mailto:eina...@cisco.com>>

To:
"Andy Bierman" mailto:a...@yumaworks.com>>
Cc:
"NETMOD Working Group" mailto:netmod@ietf.org>>
Sent:
Sat, 8 Aug 2015 11:10:15 +
Subject:
Re: [netmod] Y34 - root node


Andy,

I agree that there is a need for organization of models, but I don’t have a 
firm position on 
draft-openconfig-netmod-model-structure/draft-rtgyangdt-rtgwg-device-model or 
draft-bierman-netmod-yang-package. But we absolutely need *something* to help 
end-users of the models comprehend the overall structure of models, their 
relationship and how to use them.

Cheers,

Einar

On Aug 4, 2015, at 5:16 PM, Andy Bierman 
mailto:a...@yumaworks.com>> wrote:



On Tue, Aug 4, 2015 at 2:34 AM, t.petch 
mailto:ie...@btconnect.com>> wrote:
- Original Message -
From: "Andy Bierman" mailto:a...@yumaworks.com>>
To: "t.petch" mailto:ie...@btconnect.com>>
Sent: Monday, August 03, 2015 5:17 PM

> - Original Message -
> From: "Andy Bierman" mailto:a...@yumaworks.com>>
> To: "t.petch" mailto:ie...@btconnect.com>>
> Sent: Monday, August 03, 2015 4:10 PM
>
> > - Original Message -
> > From: "Andy Bierman" a...@yumaworks.com<mailto:a...@yumaworks.com>
> > Sent: Saturday, August 01, 2015 7:05 PM
> > On Sat, Aug 1, 2015 at 9:51 AM, Acee Lindem (acee) 
> > mailto:a...@cisco.com>>
> >
>>> On 8/1/15, 2:51 AM,  
>>> j.schoenwael...@jacobs-university.de<mailto:j.schoenwael...@jacobs-university.de>>
>>>  wrote:
>>>
>>> Section 1.1 in
>>>
> https://www.ietf.org/id/draft-openconfig-netmod-model-structure-00.txt
>>> lists the goals of a generic model structure that will accommodate
>> most
>>> modern network devices. I guess you don’t agree that these are
>> desirable?
> >
> > The only objection I have to this draft is the insertion of a
top-level
> > root
> > called "device".  (Might as well be called "self").
> > There are no sibling nodes planned or intended for
> > this node, so it serves as an extra document root.
> >
> > 
> > One aspect of YANG I have never grasped is what a root means, if
> > anything.
> >
> > I understand that it is needed for NETCONF (filters) and for YANG
> > (augments, constraints) and so must be somewhere and must be
> relatively
> > stable, but has it any other significance in the data model?
> >
> > As you may recall, I was involved with SMI first, where the root is
> > somewhere up

Re: [netmod] Y34 - root node

[Acee Lindem (acee)]

From: Andy Bierman mailto:a...@yumaworks.com>>
Date: Monday, August 10, 2015 at 4:15 PM
To: Acee Lindem mailto:a...@cisco.com>>
Cc: "Einar Nilsen-Nygaard (einarnn)" 
mailto:eina...@cisco.com>>, Jonathan Hansford 
mailto:jonat...@hansfords.net>>, NETMOD Working Group 
mailto:netmod@ietf.org>>
Subject: Re: [netmod] Y34 - root node



On Mon, Aug 10, 2015 at 12:34 PM, Acee Lindem (acee) 
mailto:a...@cisco.com>> wrote:
I think there is agreement that there is a problem. The YANG Routing Design 
Team is  addressing this with 
https://www.ietf.org/id/draft-rtgyangdt-rtgwg-device-model-00.txt  (which has 
evolved from 
https://www.ietf.org/id/draft-openconfig-netmod-model-structure-00.txt). In 
essence, a place for everything and everything in its place. However, there are 
those who feel that can’t mandate a single model structure for network devices 
and we need mechanisms to manage multiple models but allow for different device 
structure (e.g., 
https://www.ietf.org/id/draft-bierman-netmod-yang-package-00.txt).  I hope we 
can agree on an approach in the coming interim meetings.


Do you expect "everything in its place" to apply to all other SDOs and
all vendor modules? Or do you expect just the IETF routing modules
to follow this subtree hierarchy? If the former, does this mean the
YANG Routing Design Team is the "YANG data placement authority"
or all YANG modules that ever get written? How long should
it take for all other SDOs and vendors to redo all their existing
modules to re-root them in their assigned place in the data tree?

I’d expect the final document to be a product of the netmod WG and, 
consequently, have wide review and approval. We are considering some changes to 
specify an identify for a class of data model rather than trying to specify 
specific models.

As for other SDOs and their YANG models, we can suggest placement but we really 
can even force them to use our building blocks.


IMO is is not a good idea to rely on rigid data node placement,
and a single data placement authority. It is better and use meta-data
built from the YANG modules (or YANG packages) instead.

I guess we’re going to have to see the programming model for this. Fixed paths 
do provide a clean programming model.


The reason Linux uses packages to install/update functionality
is because managing 8000 packages is hard enough.
Managing 247,000 individual files would be insane.
The actual location of files is quite configurable and different
across distros. We could learn something from the last decade
of Linux package management, and try to apply it to YANG.

I wil give your draft a closer read.

Thanks,
Acee








Thanks,
Acee


Andy




From: netmod mailto:netmod-boun...@ietf.org>> on 
behalf of "Einar Nilsen-Nygaard (einarnn)" 
mailto:eina...@cisco.com>>
Date: Monday, August 10, 2015 at 5:29 AM
To: Jonathan Hansford mailto:jonat...@hansfords.net>>
Cc: NETMOD Working Group mailto:netmod@ietf.org>>
Subject: Re: [netmod] Y34 - root node

As someone sharing responsibilities for guiding a number of development teams 
both defining new models and implementing to some already defined models in 
this area, I can only agree with this addition to what I said earlier.

Cheers,

Einar

On Aug 10, 2015, at 9:46 AM, Jonathan Hansford 
mailto:jonat...@hansfords.net>> wrote:

 And it is not just end users who need help to better understand YANG models 
and how to use them. For those still on the edge, looking to finally take the 
plunge and use NETCONF/YANG to configure their devices, help is also required 
to determine how best to structure their YANG models, make use of the existing 
ones, etc. For those who have "grown up" with the developments in NETCONF and 
YANG, much of this is probably second nature. But coming to it cold (in the 
sense of compiling/writing a first set of YANG models for a device; I've been 
following the netconf/netmod WGs for 3+ years), it still feels very much like a 
dark art! It is not just the individual modules, it is how to put them together 
to best manage a device (let alone a system).

Jonathan



- Original Message -
From:
"Einar Nilsen-Nygaard (einarnn)" mailto:eina...@cisco.com>>

To:
"Andy Bierman" mailto:a...@yumaworks.com>>
Cc:
"NETMOD Working Group" mailto:netmod@ietf.org>>
Sent:
Sat, 8 Aug 2015 11:10:15 +
Subject:
Re: [netmod] Y34 - root node


Andy,

I agree that there is a need for organization of models, but I don’t have a 
firm position on 
draft-openconfig-netmod-model-structure/draft-rtgyangdt-rtgwg-device-model or 
draft-bierman-netmod-yang-package. But we absolutely need *something* to help 
end-users of the models comprehend the overall structure of models, their 
relationship and how to use them.

Cheers,

Einar

On Aug 4, 2015, at 5:16 PM, Andy Bierman 
mailto:a...@yumaworks.com>> wr

Re: [netmod] questions about draft-rtgyangdt-rtgwg-device-model-00

[Acee Lindem (acee)]

On 8/26/15, 2:40 AM, "Juergen Schoenwaelder"
 wrote:

>On Tue, Aug 25, 2015 at 10:53:55PM -0400, Lou Berger wrote:
>
>> > Hopefully, a decision to change all existing models (including vendor
>> > models!) will be based on something more technical than the fact that
>> > a group of people "really like it" some other way.
>> 
>> I'm equally unsure that having an argument of "I got there first" is a
>> compelling argument given the number of folks (including vendors) who
>> have stated willingness (or even support) for change.  I think having a
>> major class of users stand up and say this is important should garner
>> some notice.
>
>Please keep in mind that we are talking about several published
>proposed standards that have been implemented and deployed. I think
>there must be convincing technical reasons to declare them broken and
>to redo them.

Other than adding /device at the top, we are not obsoleting RFC 7223. The
current device model keeps the interfaces configuration silo and merely
augments it with a binding to the logical-networking-element.

Thanks, 
Acee




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

Re: [netmod] questions about draft-rtgyangdt-rtgwg-device-model-00

[Acee Lindem (acee)]

On 8/26/15, 8:09 AM, "Martin Bjorklund"  wrote:

>Nadeau Thomas  wrote:
>> 
>> > On Aug 26, 2015:6:26 AM, at 6:26 AM, Martin Bjorklund 
>> > wrote:
>> > 
>> > "Acee Lindem (acee)"  wrote:
>> >> 
>> >> 
>> >> On 8/26/15, 2:40 AM, "Juergen Schoenwaelder"
>> >>  wrote:
>> >> 
>> >>> On Tue, Aug 25, 2015 at 10:53:55PM -0400, Lou Berger wrote:
>> >>> 
>> >>>>> Hopefully, a decision to change all existing models (including
>>vendor
>> >>>>> models!) will be based on something more technical than the fact
>>that
>> >>>>> a group of people "really like it" some other way.
>> >>>> 
>> >>>> I'm equally unsure that having an argument of "I got there first"
>>is a
>> >>>> compelling argument given the number of folks (including vendors)
>>who
>> >>>> have stated willingness (or even support) for change.  I think
>>having
>> >>>> a
>> >>>> major class of users stand up and say this is important should
>>garner
>> >>>> some notice.
>> >>> 
>> >>> Please keep in mind that we are talking about several published
>> >>> proposed standards that have been implemented and deployed. I think
>> >>> there must be convincing technical reasons to declare them broken
>>and
>> >>> to redo them.
>> >> 
>> >> Other than adding /device at the top, we are not obsoleting RFC
>> >> 7223.
>> > 
>> > This doesn't make sense.  The YANG model is the contract.  You are
>> > proposing changing the contract.  The fact is that you will be
>> > obsoleting 7223 (and the other RFCs).  Existing devices and
>> > applications will have to change in order to handle this new top-level
>> > node (which will be in some other namespace I presume, unless your
>> > proposal is one gigantic monolithic model).
>> > 
>> > 
>> > /martin
>> 
>>  Again I will ask: why is this bad?
>
>My point above was in reply to the statement that "we are not
>obsoleting RFC 7223" [because the change is so small?] - you would in
>fact be obsoleting the model in 7223.

There have been other mechanisms discussed to relocate YANG models.
Perhaps, one of these could be employed in lieu of obsoleting the existing
models. 

Thanks,
Acee 


>
>
>/martin

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

Re: [netmod] logical systems model

[Acee Lindem (acee)]

Martin, Andy, 

On 8/28/15, 2:41 AM, "netmod on behalf of Martin Bjorklund"
 wrote:

>Andy Bierman  wrote:
>> Hi,
>> 
>> I started a new subject line because the way logical vs. physical
>>systems
>> are managed is a separate issue from the others.
>> 
>>+--rw device
>>   +--rw logical-network-elements
>>  +--rw logical-network-element* [network-element-id]
>> +--rw network-element-id  uint8
>> +--rw network-element-name?   string
>> +--rw default-networking-instance-name?   string
>> +--rw system-management
>> |  +--rw device-view? boolean
>> |  +--rw syslog
>> |  +--rw dns
>> |  +--rw ntp
>> |  +--rw statistics-collection
>> |  +--rw ssh
>> |  +--rw tacacs
>> |  +--rw snmp
>> |  +--rw netconf
>> 
>> 
>> I do not know of any systems where the logical view
>> is managed with an array entry like in this proposal.
>> Usually the protocol (or CLI command) picks one logical context
>> and the PDU is for that one logical system.  Each logical system
>> is self-contained so that the data models are written for
>> a single system.
>> 
>> Putting the multiplexing in the data model
>> adds a lot of extra complexity and protocol overhead for
>> systems that do not have virtual servers.
>
>+1
>
>I also believe that it is too limiting.  Some systems might do it this
>way, but then there are others that have the concept of "virtual
>system" that works differently.  For example, the virtual system might
>give you your very own sandbox not just for the data model but also
>for the underlying config data store.  There are essentially separate
>instances of a NETCONF server running (or other protocol).

Well, I guess you are recommending going down the same path as SNMP where
each vendor supported multiple virtual routers and instances differently.
IMO, this is undesirable.

Acee 



>
>
>> When it comes to converting this tree to CLI (since this
>> is a common practice) the "interfaces" command will become
>> "devices interfaces", "system" becomes "device system", etc.
>> I don't know of any CLIs that work this way.
>> 
>> The "nacm enable false" command will become
>> 
>> device logical-network-elements logical-network-element 1 \
>> system-management netconf nacm enable false
>
>And this would be a weird place for NACM.  Would there be another NACM
>for logical-network-element 2?  They would share the same root, so are
>rules somehow merged?
>
>Ditto for the snmp container btw.
>
>
>/martin
>
>___
>netmod mailing list
>netmod@ietf.org
>https://www.ietf.org/mailman/listinfo/netmod

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

Re: [netmod] Motivations for Structuring Models

[Acee Lindem (acee)]

On 8/28/15, 8:55 AM, "netmod on behalf of Martin Bjorklund"
 wrote:

>Rob Shakir  wrote:
>> 
>> Hi Martin,
>> 
>> Thanks for the reply.
>> > Martin Bjorklund 
>> > August 28, 2015 at 02:33
>> > So the idea is that this structure is defined in one module,
>> > ietf-something-structure, right?
>> >
>> > And then different oam protocol modules augment this structure?
>> >
>> > How does this help you find the modules that augment this structure?
>> Yes, this is the intention. By then generating the tree of the overall
>> structure, then I can see what different containers are created
>> there. It's not perfect (and hey, this suggestion is a *draft* for a
>> reason - but yet again, there are not alternatives) - but the fact
>> that the modules augment a common path adds some information that they
>> are grouped to providing the same functionality, not
>> disparate. ietf-routing does the same thing, it gives me the fact that
>> at /routing/routing-instance/routing-protocols there are a bunch of
>> control-plane protocols that are related to routing.
>
>Ok.  So your proposal doesn't help with the problem of locating
>relevant YANG modules, but once their located, it is easier to find
>the ones related to a specific function, b/c they would augment a
>common path.  Is this what you mean?

Why doesn’t it help? In the next revision of the Routing YANG DT model,
we’ve switched from including specific models to defining classes of
models with identities. For example,

 grouping oam-protocols {
  container oam-protocols {
  list oam-protocol {
  key "type";
  leaf type {
  type identityref {
  base oam-protocol-type;
  }
  mandatory true;
  description
  "The Operations, Administration, and
   
   
   Maintenance (OAM) protocol type, e.g., BFD,
   
   
   TWAMP, CFM, etc.";
  }
  description
  "List of OAM protocols configured for a
   
   
   networking instance.";
  }
  description
  "Container for list of OAM protocols configured for a
   
   
networking instance.";
  }
  description
  "Grouping for OAM protocols configured for a
   
   
   networking instance.";
  }


Then the grouping is include the networking-instances.  By doing this, the
intent is that it would be evident as to where a particular model would be
found. 

Thanks,
Acee 



>
>
>>  “Just read through the modules” is not acceptable answer when
>>  considering making things easy to use for YANG model consumers.
>> >>> But how does the top-level node /device (sorry, but I really have to
>> >>> ask this) solve this problem?  I *really* do not understand this.
>> >>> Even with your solution you'd have a set of modules that augment
>>this
>> >>> structure, right?  How do I know what these other modules are?
>> > You didn't answer this question.  So I repeated it above and below ;)
>> Right. There was really a reason NOT to answer it. /device is
>> irrelevant. It does not matter
>
>But this is the what we have been arguing about!  Remove /device and
>we can put this behind us and move forward.
>
>> - it is simply how *this proposal*
>> chooses to group things, based on the fact that we think that
>> operators logically configure devices when dealing with these
>> models.
>
>Sure, an operator configure devices.
>
>> From your comments on NCS below, it seems to me that if we'd
>> made this a list, then there'd be significantly less concern?
>
>No that would be even worse!  If every device had a list of exactly
>one device (itself), the operator would have to do the equivalent of:
>
>  $ ssh rtr2
>  ...
>  > config
>  # device device rtr2 interface eth0
>
>On most routers you don't do this. You just do:
>
>  > config
>  # interface eth0
>
>
>Or in an orchestrator like NCS you'd have to do the equivalent of:
>
>  $ ssh orchestrator
>  ...
>  > config
>  # devices device rtr2 data devices device rtr2 interface eth0
>
>This just doesn't make any sense.
>
>
>> I just
>> can't understand why this is something to get hung up on. If /device
>> isn't the right root, please show me what is - and WHY it's better.
>
>Just use '/'.  The point is that *on the device* a root of /device
>doesn't make any sense.
>
>I am all for a common model of a device list to be used in the
>NSM/OSS/..., but that is a separate issue.
>
>> Structuring configuration and operational around some idea that all
>> the configuration belongs to a physical device seems very, very
>> logical to me. Further defining groups so that we have an
>> understanding of how to build a coherent set of models for the
>> 

Re: [netmod] Motivations for Structuring Models

[Acee Lindem (acee)]

On 8/28/15, 9:24 AM, "Martin Bjorklund"  wrote:

>"Acee Lindem (acee)"  wrote:
>> 
>> 
>> On 8/28/15, 8:55 AM, "netmod on behalf of Martin Bjorklund"
>>  wrote:
>> 
>> >Rob Shakir  wrote:
>> >> 
>> >> Hi Martin,
>> >> 
>> >> Thanks for the reply.
>> >> > Martin Bjorklund <mailto:m...@tail-f.com>
>> >> > August 28, 2015 at 02:33
>> >> > So the idea is that this structure is defined in one module,
>> >> > ietf-something-structure, right?
>> >> >
>> >> > And then different oam protocol modules augment this structure?
>> >> >
>> >> > How does this help you find the modules that augment this
>>structure?
>> >> Yes, this is the intention. By then generating the tree of the
>>overall
>> >> structure, then I can see what different containers are created
>> >> there. It's not perfect (and hey, this suggestion is a *draft* for a
>> >> reason - but yet again, there are not alternatives) - but the fact
>> >> that the modules augment a common path adds some information that
>>they
>> >> are grouped to providing the same functionality, not
>> >> disparate. ietf-routing does the same thing, it gives me the fact
>>that
>> >> at /routing/routing-instance/routing-protocols there are a bunch of
>> >> control-plane protocols that are related to routing.
>> >
>> >Ok.  So your proposal doesn't help with the problem of locating
>> >relevant YANG modules, but once their located, it is easier to find
>> >the ones related to a specific function, b/c they would augment a
>> >common path.  Is this what you mean?
>> 
>> Why doesn’t it help? In the next revision of the Routing YANG DT model,
>> we’ve switched from including specific models to defining classes of
>> models with identities. For example,
>> 
>>  grouping oam-protocols {
>>   container oam-protocols {
>>   list oam-protocol {
>>   key "type";
>>   leaf type {
>>   type identityref {
>>   base oam-protocol-type;
>>   }
>>   mandatory true;
>>   description
>>   "The Operations, Administration, and
>> 
>> 
>>Maintenance (OAM) protocol type, e.g., BFD,
>> 
>> 
>>TWAMP, CFM, etc.";
>>   }
>>   description
>>   "List of OAM protocols configured for a
>> 
>> 
>>networking instance.";
>>   }
>>   description
>>   "Container for list of OAM protocols configured for a
>> 
>> 
>> networking instance.";
>>   }
>>   description
>>   "Grouping for OAM protocols configured for a
>> 
>> 
>>networking instance.";
>>   }
>> 
>> 
>> Then the grouping is include the networking-instances.  By doing this,
>>the
>> intent is that it would be evident as to where a particular model would
>>be
>> found. 
>
>Now I am a user of YANG models.  I am searching for the YANG module
>that defines OAM for BFD.  How does your model above help me find it?

If one can envision a function to list the schema rather than the actual
config data, you could retrieve the schema for the oam-protocols
container. It would seem reasonable to support such a function.

Thanks,
Acee


>
>
>/martin

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

Re: [netmod] Motivations for Structuring Models

[Acee Lindem (acee)]

Hi Mahesh,

I think that if we leave structure to the WGs, we will end up with models that 
have a WG-centric view with their corresponding model being at the root and any 
instantiation (logical-network-element, networking-instance, VRF, etc) being 
done within the model. Is this what we want? In routing, we had the benefit of 
the routing-cfg model also being considered and concluded the debate in favor 
of adopting the routing-cfg structure for the routing protocol models.

Thanks,
Acee

From: Mahesh Jethanandani 
mailto:mjethanand...@gmail.com>>
Date: Friday, August 28, 2015 at 7:44 PM
To: Acee Lindem mailto:a...@cisco.com>>
Cc: Martin Bjorklund mailto:m...@tail-f.com>>, 
"r...@rob.sh<mailto:r...@rob.sh>" mailto:r...@rob.sh>>, 
"netmod@ietf.org<mailto:netmod@ietf.org>" 
mailto:netmod@ietf.org>>
Subject: Re: [netmod] Motivations for Structuring Models

Acee,

This is going to become very interesting very quickly. Routing DT has decided 
to define a container for oam-protocols. LIME has decided it wants to define a 
generic YANG module for all OAM in draft-tissa-lime-yang-oam-model.

Which model does BFD augment? Or did you just kill the whole charter for LIME??

On Aug 28, 2015, at 6:20 AM, Acee Lindem (acee) 
mailto:a...@cisco.com>> wrote:

Why doesn’t it help? In the next revision of the Routing YANG DT model,
we’ve switched from including specific models to defining classes of
models with identities. For example,

grouping oam-protocols {
 container oam-protocols {
 list oam-protocol {
 key "type";
 leaf type {
 type identityref {
 base oam-protocol-type;
 }
 mandatory true;
 description
 "The Operations, Administration, and


  Maintenance (OAM) protocol type, e.g., BFD,


  TWAMP, CFM, etc.";
 }
 description
 "List of OAM protocols configured for a


  networking instance.";
 }
 description
 "Container for list of OAM protocols configured for a


   networking instance.";
 }
 description
 "Grouping for OAM protocols configured for a


  networking instance.";
 }


Then the grouping is include the networking-instances.  By doing this, the
intent is that it would be evident as to where a particular model would be
found.

Mahesh Jethanandani
mjethanand...@gmail.com<mailto:mjethanand...@gmail.com>





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

Re: [netmod] Tomorrow's Interim Meeting Details

[Acee Lindem (acee)]

Since the meeting is only an hour, I think it is unrealistic to think we are 
going to cover both Ops-state and model structure tomorrow.
Thanks,
Acee

From: netmod mailto:netmod-boun...@ietf.org>> on 
behalf of Kent Watsen mailto:kwat...@juniper.net>>
Date: Wednesday, September 9, 2015 at 9:26 PM
To: Andy Bierman mailto:a...@yumaworks.com>>, "Thomas D. 
Nadeau" mailto:tnad...@lucidvision.com>>
Cc: netmod WG mailto:netmod@ietf.org>>
Subject: Re: [netmod] Tomorrow's Interim Meeting Details


This goes to model-structure requirements, which are currently undefined.  As 
mentioned below, we will need to spend some time tomorrow writing them down, so 
we have something to call consensus on.Maybe the open config folks could 
take a stab at this before tomorrow's meeting?

Kent

From: Andy Bierman mailto:a...@yumaworks.com>>
Date: Wednesday, September 9, 2015 at 9:01 PM
To: Thomas Nadeau mailto:tnad...@lucidvision.com>>
Cc: "netmod@ietf.org" 
mailto:netmod@ietf.org>>
Subject: Re: [netmod] Tomorrow's Interim Meeting Details

Hi,

This email and the one from Benoit do not mention any sort of problem scope.
IMO it would be useful to know if the scope includes all YANG modules, only IETF
YANG modules, or perhaps only IETF routing modules. As the scope gets wider,
the probability that "1 size fits all" goes way down.


Andy


On Wed, Sep 9, 2015 at 5:38 PM, Nadeau Thomas 
mailto:tnad...@lucidvision.com>> wrote:

I wanted to set things up for the interim meeting tomorrow. To frame 
the meeting, we want to achieve two main goals:

1) close on requirements around a requirement to define a structure for 
IETF models and the requirements around ops state/models

2) discuss/debate/understand the differences between the 3 different 
solution approaches as described in draft-openconfig-netmod-opstate-01, 
draft-kwatsen-netmod-opstate, draft-wilton-netmod-opstate-yang.  While I 
understand the last two drafts are relatively new, they are there and have been 
for a time sufficient to read and ask questions on the list of the authors.

To this end, I’d like to steer the discussion in the direction of 
having direct questions/debate over those solutions. I’d like a representative 
author from each draft lead each of their sections.   If time still exists, I’d 
like to let Kent (speaking as co-chair), objectively compare pros/cons of each 
solution.  I understand that we allocated an hour for tomorrow. We incorrectly 
anticipated a single draft to be compared to the existing opsstate draft.  If 
we need additional time, a second meeting will be planned for hopefully next 
week, so that we can tie things off.


This is the proposed agenda for tomorrow’s meeting.

0) Agenda Bashing - Tom/2 min

1) Statement from the AD:
Please read 
http://www.ietf.org/mail-archive/web/netmod/current/msg13510.html

1) Requirements - Tom/15 min
  - goal is to close on consensus (to be confirmed on list)
  on the problem statement/requirements, as described in
  draft-openconfig-netmod-opstate-01, Sections 3 & 4, and
  implied in draft-openconfig-netmod-model-structure-00
  (yes, we'll need to write them down), as well as any
  other requirements not covered by the above.
- please come prepared to discuss and finalize these


2) Questions/Comments about each specific draft - 15 minutes for each
A rep for each draft (Martin?, Wilton?, Anees?)

   - to be led by a representative for each draft
  (Martin?, Wilton?, Anees?)
- this is not intended to be a presentation of these solution
  so much as an opportunity to ask questions of the authors
  regarding any aspect of the presented solution.
- everyone should come prepared having already read these drafts.
- if there are no questions, we'll move on to the next draft
  right away.

3) Compare and contrast the solutions () - rest of the time, if time 
permits. Kent (as co-chair)

- goal is to up-level the conversation to direct comparison
  of the various solutions.


Finally, I’d like to ask for a volunteer to take notes as well as 
someone to run the Etherpad.


WebEx Details:




>>>
>>> NETMOD Working Group invites you to join this WebEx meeting.
>>>
>>> NETMOD Interm meeting on OpenConfig
>>> Thursday, September 10, 2015
>>> 11:00 am  |  Eastern Daylight Time (New York, GMT-04:00)  |  1 hr
>>>
>>> Join WebEx meeting
>>> Meeting number: 645 732 277
>>> Meeting password:   1234
>>>
>>> Join by phone
>>> 1-877-668-4493 Call-in toll free number (US/Canada)
>>> 1-650-479-3208 Call-in toll number (US/Canada)
>>> Access code: 645 732 277





___
netmod mailing list
netmod@ietf.org
https://w

Re: [netmod] ACL Model 03 - ACL Type should be mandatory

[Acee Lindem (acee)]

On 9/21/15, 10:23 AM, "netmod on behalf of Ladislav Lhotka"
 wrote:

>"Sterne, Jason (Jason)"  writes:
>
>> Hi all,
>>
>> I met with Dean at IETF93 and we agreed that I should send a specific
>>proposal to the list for this.  Here it is:
>>
>> -
>> Replace the following current snippets from model-03:
>> -
>>
>> list acl {
>>   key "acl-name";
>>   ...
>> }
>>
>> leaf acl-type {
>>   type acl-type;
>>   description
>> "It is recommended to have an Access Control List with
>>  uniform access list entries, all of the same type. When
>>  this type is not explicitly specified, if vendor
>>  implementation permits, the access control entries
>>  in the list can be mixed,
>>  by containing L2, L3 and L4 entries";
>> }
>>
>> identity ip-acl {
>>   base acl:acl-base;
>>   description
>> "IP Access Control List is a common name for lists that contain
>>  layer 3 and/or layer 4 match conditions.";
>> }
>>
>> identity eth-acl {
>>   base acl:acl-base;
>>   description
>> "Ethernet Access Control List is name for layer 2 Ethernet
>>  technology Access Control List types, like 10/100/1000baseT or
>>  WiFi Access Control List";
>> }
>>
>> 
>> with the following:
>> 
>>
>> list acl {
>>   key "acl-type acl-name";
>>   ...
>> }
>> (note this is similar construct to the routing model:
>>list routing-protocol {key "type name"... )
>
>Well, originally we had "name" as the only key but some routing folks
>insisted on having "type" as the second key. Personally, I am not
>entirely sold to this idea.

Why not? Existing products support these semantics… Different types of
access-list should have independent name spaces (i.e., one should be able
to have an IP ACL named foo, an IPv6 ACL named foo, and a L2 ACL named
foo). 

Thanks,
Acee 





>
>The thing is: YANG requires config lists to have keys but it doesn't
>mean these keys need to be the same as parameters that are understood as
>keys in a CLI.
>
>One advantage of having YANG list keys separate from "public" keys is
>that a user is free to change the public keys, and it also doesn't break
>any internal references in the configuration. If you have "acl-type" and
>"acl-name" as YANG list keys, then they cannot be changed.
>
>So in fact I'd suggest to have an opaque ID as the only list key, and
>then "acl-name" and "acl-type" as non-key leafs, perhaps subject to a
>unique constraint.
>
>Lada
>
>>
>> leaf acl-type {
>>   type acl-type;
>>   description
>> "Type of access control list. Indicates the primary intended
>>  type of match criteria (e.g. ethernet, IPv4, IPv6, mixed, etc)
>>  used in the list instance.";
>> }
>>
>> identity ipv4-acl {
>>   base acl:acl-base;
>>   description 
>> "ACL that primarily matches on fields from the IPv4 header
>> (e.g. IPv4 destination address) and layer 4 headers (e.g. TCP
>>destination
>> port).  An acl of type ipv4-acl does not contain matches on fields
>>in
>> the ethernet header or the IPv6 header.";
>> }
>>
>> identity ipv6-acl {
>>   base acl:acl-base;
>>   description
>> "ACL that primarily matches on fields from the IPv6 header
>> (e.g. IPv6 destination address) and layer 4 headers (e.g. TCP
>>destination
>> port). An acl of type ipv6-acl does not contain matches on fields in
>> the ethernet header or the IPv4 header.";
>> }
>>   
>> identity eth-acl {
>>   base acl:acl-base;
>>   description
>> "ACL that primarily matches on fields in the ethernet header.
>>  An acl of type eth-acl does not contain matches on fields in
>>  the IPv4 header, IPv6 header or layer 4 headers.";
>> }
>>
>>
>> ---
>> Potential future augmentation of type:
>> 
>>
>> For future mixed types vendors (or the ietf) could augment the
>>acl-type-base with types like the following:
>>
>>   identity mixed-l3-acl {
>> base "access-control-list:acl-type-base";
>> description "ACL that contains a mix of entries that primarily
>>match on fields 
>>   in IPv4 headers and entries that primarily match on fields in
>>IPv6 headers.
>>   Matching on layer 4 header fields may also exist in the list.
>>   An acl of type mixed-l3-acl does not contain matches on fields in
>>   the ethernet header.";
>>   }
>>  
>>   identity mixed-l2-l3-acl {
>> base "access-control-list:acl-type-base";
>> description "ACL that contains a mix of entries that primarily
>>match on fields 
>>   in ethernet headers, entries that primarily match on fields in
>>IPv4 headers,
>>   and entries that primarily match on fields in IPv6 headers.
>>Matching on layer 4
>>   header fields may also exist in the list.";
>>   }
>>
>> Regards,
>> Jason
>>
>> -Original Message-
>> From: Sterne, Jason (Jason)
>> Sent: Sunday, July 19, 2015 12:58
>

Re: [netmod] YANG Mount = Alias Mount + Peer Mount (was RE: Motivations for Structuring Models)

[Acee Lindem (acee)]

Hi Eric, Lada, 

I agree with Eric that the mount requirements should include both use
cases. We have been discussing this mechanism as potentially providing
support for meta model components that may or not be present in a network
device. 

Thanks,
Acee

On 9/22/15, 1:59 PM, "netmod on behalf of Eric Voit (evoit)"
 wrote:

>Hi Lada,
>
>Thanks for your feedback.   I do think that there is value in an
>integrated technology solution.   OpenDaylight combines (1) and (2)
>usefully.  For example there are examples on the page:
>http://wiki.opendaylight.org/view/OpenDaylight_Controller:Config:Examples:
>Netconf
>such as:
>http://localhost:8080/restconf/operations/network-topology:network-topolog
>y/topology/topology-netconf/node//yang-ext:mount/
>which enables a server to reference remote device info embedded within a
>network-topology url
>
>Beyond that, OpenDaylight has the ability to do (1) in the form of "
>loopback mount".  See:
>http://wiki.opendaylight.org/view/Controller_Core_Functionality_Tutorials:
>Tutorials:Netconf_Mount#Testing_against_ODL_itself_.28MD-SAL_netconf_north
>bound_loopback_mount.29
>While this is used mostly for testing, aliasing is also viable.
>
>Eric
>
>-Original Message-
>From: Ladislav Lhotka, September 21, 2015 4:34 AM
>
>Hi Eric,
>
>we are dealing with two rather different problems:
>
>1. A pull-type method for combining YANG schemas as a complement to
>   "augment".
>
>2. A proxy function that mediates access to data that are located
>   elsewhere.
>
>I believe the recent thread on structuring YANG models has been about #1
>while both this draft and draft-clemm-netmod-mount-03 mainly address #2.
>Each problem has its share of issues to solve but the issues don't
>overlap, so I believe it would be useful to keep both problems separate.
>
>Lada
>
>"Eric Voit (evoit)"  writes:
>
>> There was a recent thread on structuring YANG models so that
>>application developers might be able to reference alternative local
>>hierarchies/tree structures for certain objects.  This thread motivated
>>Alex, Sander, and I to rework the YANG Mount requirements draft.  v03 is
>>posted at:
>> http://datatracker.ietf.org/doc/draft-voit-netmod-peer-mount-requireme
>> nts/
>>
>> This draft has been retitled to "Requirements for mounting of local and
>>remote YANG subtrees".  This retitling was done because we have
>>separated the thinking on what it takes to Mount objects from remote
>>devices (Peer Mount) from what it takes to Mount within the same device
>>(Alias Mount).
>>
>> We would be interested in your thoughts.
>>
>> Eric
>>
>> -Original Message-
>> From: Ladislav Lhotka, August 31, 2015 11:05 AM
>>
>> Randy Presuhn  writes:
>>
>>> Hi -
>>>
>>> It is with no little amusement that I watch this thread struggling
>>> with questions that were solved fairly neatly a quarter century ago
>>> in GDMO/CMIP-land.  I'm *not* suggesting we go back there, but would
>>> like to offer an observation about modeling that might help.
>>>
>>> The organization of instance data in SNMP is a direct mirror of the
>>> "object" definitions.  Simple at first, but quickly becoming baroque
>>> as various minds of "multiplexing" are added to compensate for post
>>> hoc deficiencies in the index structures.
>>>
>>> Life is such that once a resource has been modeled, it will be
>>> used/re-used/embedded in systems in ways in which its designers
>>> couldn't be expected to imagine.  A consequence of this is that if
>>> instance naming is completely locked down when the management
>>> interface for a resource is first defined (as it is in SNMP) then all
>>> sorts of peculiar hacks will be needed to deal with, for example,
>>> virtual routers.  Unfortunately, an SNMP/SMI-like mindset is so
>>> pervasive that folks seem to overlook that there are other ways to
>>> deal with this situation.
>>>
>>> What GDMO did was to use a separate "NAME BINDING" construct to
>>> specify contexts in which instances might show up, allowing instances
>>> to be put in places that weren't even imagined when the original
>>> class definition was written.  Name bindings could be standardized,
>>> or be vendor or even product-specific, allowing the simplicity or
>>> complexity of a given system's instance tree to reflect the actual
>>> simplicity or complexity of that system, rather than requiring all
>>> systems to be structured for the worst case.
>>
>> How could this be expressed in YANG terms? (I tried to figure it out
>>myself but I unfortunately couldn't make any sense of sec. 8.6 in CCITT
>>Recommendation X.722).
>>
>> Thanks, Lada
>>
>>>
>>> Yes, separating the specification of instance naming in large part
>>> from class definition does have implications for how one does access
>>> control, and how clients figure out how to ask a server to create
>>> something, but it's not a huge deal - it's just not like VACM, and a
>>> whole slew of hacky solutions and "wierd plumbing adapters" (to
>>> borrow from Jeff Case) just go away.  St

Re: [netmod] rib-data-model and routing-cfg

[Acee Lindem (acee)]

Hi Lada, 
I2RS is not chartered to do the base models. There are other routing
models that reference routing-cfg and even in-progress implementations.

On 10/9/15, 4:13 AM, "netmod on behalf of Ladislav Lhotka"
 wrote:

>Hi,
>
>I am sorry for cross-posting but I think it is high time to decide the
>relationship between the data models in i2rs-rib-data-model and
>netmod-routing-cfg I-Ds because they clearly target the same management
>data in a router. I can see three possible scenarios:
>
>1. The i2rs-rib module will be modified to augment
>ietf-routing/ietf-ipv[46]-unicast-routing.

This would seem to be the obvious choice.

>
>2. The scope of ietf-routing will be changed so that it would address
>only host routing and simple routers. The modelling work for advanced
>routers will be done elsewhere.
>
>3. The work on netmod-routing-cfg will be stopped.

A fourth option would be for me to take over ownership, move the work to
the RTG WG, and we’d recruit some strong authors/reviewers from operators
and other vendors (involving the ADs in selection).

Thanks,
Acee 


>
>Opinions?
>
>Thanks, Lada
>
>--
>Ladislav Lhotka, CZ.NIC Labs
>PGP Key ID: E74E8C0C
>
>
>
>
>___
>netmod mailing list
>netmod@ietf.org
>https://www.ietf.org/mailman/listinfo/netmod

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

Re: [netmod] rib-data-model and routing-cfg

[Acee Lindem (acee)]

Hi Lada, NETMOD, 

So I think we should move forward this ietf-rtg-cfg so that it can be
augmented and other work can move forward. We are still in disagreement
with respect to routing-instance/interface configuration.

- We feel the IPv4/IPv6 interfaces should reference the
routing-instance in their config state. This is consistent with
draft-rtgyangdt-rtgwg-device-model-01.txt.
- You feel that the routing-instance should have a list of leaf-ref’s
to the interface. You believe the leaf-ref provides a level of validation
due to the fact that references can be confined to routing-instance
references. However, heretofore, no models are referencing the interface
leaf-refs in the list.

Other than the Routing YANG Design Team having chosen the first option -
are there any other opinions?

Thanks,
Acee

On 10/9/15, 9:00 AM, "netmod on behalf of Acee Lindem (acee)"
 wrote:

>Hi Lada, 
>I2RS is not chartered to do the base models. There are other routing
>models that reference routing-cfg and even in-progress implementations.
>
>On 10/9/15, 4:13 AM, "netmod on behalf of Ladislav Lhotka"
> wrote:
>
>>Hi,
>>
>>I am sorry for cross-posting but I think it is high time to decide the
>>relationship between the data models in i2rs-rib-data-model and
>>netmod-routing-cfg I-Ds because they clearly target the same management
>>data in a router. I can see three possible scenarios:
>>
>>1. The i2rs-rib module will be modified to augment
>>ietf-routing/ietf-ipv[46]-unicast-routing.
>
>This would seem to be the obvious choice.
>
>>
>>2. The scope of ietf-routing will be changed so that it would address
>>only host routing and simple routers. The modelling work for advanced
>>routers will be done elsewhere.
>>
>>3. The work on netmod-routing-cfg will be stopped.
>
>A fourth option would be for me to take over ownership, move the work to
>the RTG WG, and we’d recruit some strong authors/reviewers from operators
>and other vendors (involving the ADs in selection).
>
>Thanks,
>Acee 
>
>
>>
>>Opinions?
>>
>>Thanks, Lada
>>
>>--
>>Ladislav Lhotka, CZ.NIC Labs
>>PGP Key ID: E74E8C0C
>>
>>
>>
>>
>>___
>>netmod mailing list
>>netmod@ietf.org
>>https://www.ietf.org/mailman/listinfo/netmod
>
>___
>netmod mailing list
>netmod@ietf.org
>https://www.ietf.org/mailman/listinfo/netmod

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

Re: [netmod] rib-data-model and routing-cfg

[Acee Lindem (acee)]

On 10/13/15, 12:30 PM, "Ladislav Lhotka"  wrote:

>
>> On 13 Oct 2015, at 17:20, Acee Lindem (acee)  wrote:
>> 
>> Hi Lada, NETMOD,
>> 
>> So I think we should move forward this ietf-rtg-cfg so that it can be
>> augmented and other work can move forward. We are still in disagreement
>> with respect to routing-instance/interface configuration.
>> 
>>- We feel the IPv4/IPv6 interfaces should reference the
>> routing-instance in their config state. This is consistent with
>> draft-rtgyangdt-rtgwg-device-model-01.txt.
>>- You feel that the routing-instance should have a list of leaf-ref’s
>> to the interface. You believe the leaf-ref provides a level of
>>validation
>> due to the fact that references can be confined to routing-instance
>> references. However, heretofore, no models are referencing the interface
>> leaf-refs in the list.
>
>True, these models (ietf-isis, for instance) use leafrefs with
>"if:interface-ref" type. However, such leafrefs are under-constrained
>because they can be configured to refer to:
>
>- interfaces of any layer, including physical interfaces, VLAN trunks etc.

Actually, putting the routing-instance reference in the IPv4 and IPv6
interface models (i.e., RFC 7277) constrains the reference to layer 3 more
effectively than the list of leaf-refs.

>
>- interfaces assigned to any routing instance.

But the list of leaf-refs doesn’t insure an IPv4 interface or IPv6
interface isn’t included by a single routing-instance.

>
>I believe in all these cases the choice has to be limited to (1) L3
>interfaces, and (2) belonging to "own" routing instance. These
>constraints will have to be checked in server code somehow - I would
>prefer to have them represented in the data model.
>
>But if nobody shares this concern with me, I am not going to block the
>document on this issue.

I’d also be interested if anyone shares this concern.

Thanks,
Acee 


>
>Lada 
>
>> 
>> Other than the Routing YANG Design Team having chosen the first option -
>> are there any other opinions?
>> 
>> Thanks,
>> Acee
>> 
>> On 10/9/15, 9:00 AM, "netmod on behalf of Acee Lindem (acee)"
>>  wrote:
>> 
>>> Hi Lada, 
>>> I2RS is not chartered to do the base models. There are other routing
>>> models that reference routing-cfg and even in-progress implementations.
>>> 
>>> On 10/9/15, 4:13 AM, "netmod on behalf of Ladislav Lhotka"
>>>  wrote:
>>> 
>>>> Hi,
>>>> 
>>>> I am sorry for cross-posting but I think it is high time to decide the
>>>> relationship between the data models in i2rs-rib-data-model and
>>>> netmod-routing-cfg I-Ds because they clearly target the same
>>>>management
>>>> data in a router. I can see three possible scenarios:
>>>> 
>>>> 1. The i2rs-rib module will be modified to augment
>>>> ietf-routing/ietf-ipv[46]-unicast-routing.
>>> 
>>> This would seem to be the obvious choice.
>>> 
>>>> 
>>>> 2. The scope of ietf-routing will be changed so that it would address
>>>> only host routing and simple routers. The modelling work for advanced
>>>> routers will be done elsewhere.
>>>> 
>>>> 3. The work on netmod-routing-cfg will be stopped.
>>> 
>>> A fourth option would be for me to take over ownership, move the work
>>>to
>>> the RTG WG, and we’d recruit some strong authors/reviewers from
>>>operators
>>> and other vendors (involving the ADs in selection).
>>> 
>>> Thanks,
>>> Acee 
>>> 
>>> 
>>>> 
>>>> Opinions?
>>>> 
>>>> Thanks, Lada
>>>> 
>>>> --
>>>> Ladislav Lhotka, CZ.NIC Labs
>>>> PGP Key ID: E74E8C0C
>>>> 
>>>> 
>>>> 
>>>> 
>>>> ___
>>>> netmod mailing list
>>>> netmod@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/netmod
>>> 
>>> ___
>>> netmod mailing list
>>> netmod@ietf.org
>>> https://www.ietf.org/mailman/listinfo/netmod
>> 
>
>--
>Ladislav Lhotka, CZ.NIC Labs
>PGP Key ID: E74E8C0C
>
>
>
>

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

Re: [netmod] rib-data-model and routing-cfg

[Acee Lindem (acee)]

ame]
> +--rw name string
> +--rw type?identityref
> +--rw enabled? boolean
> +--rw router-id?   yang:dotted-quad
> +--rw description? string
> +--rw routing-protocols
> |  +--rw routing-protocol* [type name]
> | +--rw type identityref
> | +--rw name string
> | +--rw description? string
> | +--rw static-routes
> |+--rw v6ur:ipv6
> ||  +--rw v6ur:route* [destination-prefix]
> || +--rw v6ur:destination-prefixinet:ipv6-prefix
> || +--rw v6ur:description?  string
> || +--rw v6ur:next-hop
> ||+--rw (next-hop-options)
> ||   +--:(outgoing-interface)
> ||   |  +--rw v6ur:outgoing-interface?
>if:interface-ref
> ||   +--:(special-next-hop)
> ||   |  +--rw v6ur:special-next-hop?
>enumeration
> ||   +--:(next-hop-address)
> ||  +--rw v6ur:next-hop-address?
>inet:ipv6-address
> |+--rw v4ur:ipv4
> |   +--rw v4ur:route* [destination-prefix]
> |  +--rw v4ur:destination-prefixinet:ipv4-prefix
> |  +--rw v4ur:description?  string
> |  +--rw v4ur:next-hop
> | +--rw (next-hop-options)
> |+--:(outgoing-interface)
>     ||  +--rw v4ur:outgoing-interface?
>if:interface-ref
> |+--:(special-next-hop)
> ||  +--rw v4ur:special-next-hop?
>enumeration
> |+--:(next-hop-address)
> |   +--rw v4ur:next-hop-address?
>inet:ipv4-address
> +--rw ribs
>+--rw rib* [name]
>   +--rw name  string
>   +--rw address-family?   identityref
>   +--rw description?  string
>
>"Acee Lindem (acee)"  writes:
>
>> On 10/13/15, 12:30 PM, "Ladislav Lhotka"  wrote:
>>
>>>
>>>> On 13 Oct 2015, at 17:20, Acee Lindem (acee)  wrote:
>>>> 
>>>> Hi Lada, NETMOD,
>>>> 
>>>> So I think we should move forward this ietf-rtg-cfg so that it can be
>>>> augmented and other work can move forward. We are still in
>>>>disagreement
>>>> with respect to routing-instance/interface configuration.
>>>> 
>>>>- We feel the IPv4/IPv6 interfaces should reference the
>>>> routing-instance in their config state. This is consistent with
>>>> draft-rtgyangdt-rtgwg-device-model-01.txt.
>>>>- You feel that the routing-instance should have a list of
>>>>leaf-ref’s
>>>> to the interface. You believe the leaf-ref provides a level of
>>>>validation
>>>> due to the fact that references can be confined to routing-instance
>>>> references. However, heretofore, no models are referencing the
>>>>interface
>>>> leaf-refs in the list.
>>>
>>>True, these models (ietf-isis, for instance) use leafrefs with
>>>"if:interface-ref" type. However, such leafrefs are under-constrained
>>>because they can be configured to refer to:
>>>
>>>- interfaces of any layer, including physical interfaces, VLAN trunks
>>>etc.
>>
>> Actually, putting the routing-instance reference in the IPv4 and IPv6
>> interface models (i.e., RFC 7277) constrains the reference to layer 3
>>more
>> effectively than the list of leaf-refs.
>>
>>>
>>>- interfaces assigned to any routing instance.
>>
>> But the list of leaf-refs doesn’t insure an IPv4 interface or IPv6
>> interface isn’t included by a single routing-instance.
>>
>>>
>>>I believe in all these cases the choice has to be limited to (1) L3
>>>interfaces, and (2) belonging to "own" routing instance. These
>>>constraints will have to be checked in server code somehow - I would
>>>prefer to have them represented in the data model.
>>>
>>>But if nobody shares this concern with me, I am not going to block the
>>>document on this issue.
>>
>> I’d also be interested if anyone shares this concern.
>>
>> Thanks,
>> Acee 
>>
>>
>>>
>>>Lada 
>>>
>>&g

Re: [netmod] rib-data-model and routing-cfg

[Acee Lindem (acee)]

I guess in the L3VPN use case, both the IPv4 and IPv6 VPNs are for the same 
customer (since the interface only goes to one place).

 I’ve been thinking about this for much of the morning and I see, at least, the 
following options:

  1. Move the reference(s) to routing-instance to 
“/if:interfaces/if:interface/ip:ipv4”  and 
“/if:interfaces/if:interface/ip:ipv6”.
  2. Keep the reference at the “/if:interface/if:interface/“ level but 
make it a container with a more complex structure including the overall 
reference and feature enabled override references for specific purposes (L2, 
IPv6, IPv4, etc).
  3. Others?

I like #2 since it is optimized towards the most common use case.

With respect to encapsulation, I don’t understand how they could be different 
for different AFs unless they are, in fact, different RFC 7223 interfaces. Am I 
missing something?

Thanks,
Acee

From: Rob Shakir mailto:r...@rob.sh>>
Date: Wednesday, October 21, 2015 at 9:58 AM
To: Ladislav Lhotka mailto:lho...@nic.cz>>
Cc: Acee Lindem mailto:a...@cisco.com>>, Routing WG 
mailto:rt...@ietf.org>>, "i...@ietf.org" 
mailto:i...@ietf.org>>, NETMOD WG 
mailto:netmod@ietf.org>>, Routing YANG 
mailto:rtg-yang-co...@ietf.org>>
Subject: Re: [netmod] rib-data-model and routing-cfg

On 21 October 2015 at 07:52:43, Ladislav Lhotka 
(lho...@nic.cz) wrote:
One option would be to create two virtual interfaces - one for IPv4 VPN and 
another for IPv6 VPN, and define routing-instance and addresses separately for 
each.

This is only workable if an implementation must support two virtual interfaces 
that have the same underlying encapsulation (i.e.., they are simply logically 
separating IPv4 and IPv6), in some implementations, this isn’t the case, and 
the virtual interfaces must have different encapsulations.

In openconfig-interfaces, each sub-interface is associated with a single VLAN, 
so in this case, we would need the network-instance to be specified on a per 
address-family basis there. There is nothing to stop one having a single leaf 
at the sub-interface or interface level that is inherited by the other 
constructs - this is something that I have been considering based on work on 
the network-instance model that we recently published.

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

[netmod] draft-ietf-netmod-routing-cfg

[Acee Lindem (acee)]

We had a lot of good discussions at IETF 94 with respect to the
ietf-routing and how it could be augmented in the future to support I2RS.
These discussions are ongoing.

One current change that I would like to propose is to change the base
instance container from routing-instance to networking-instance. This
would provide an instance definition that could be augmented for L2
protocols and service functionality as well as L3. It is also consistent
with the term used in both
https://www.ietf.org/id/draft-rtgyangdt-rtgwg-device-model-01.txt and
https://www.ietf.org/id/draft-openconfig-rtgwg-network-instance-01.txt.

Thanks,
Acee 

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

Re: [netmod] draft-ietf-netmod-routing-cfg

[Acee Lindem (acee)]

Hi Martin,
 
I think using the more generic term, “networking”, at the top would be
preferable. What we need is an instance abstraction that covers L3 (e.g.,
virtual router or VRF), L2 (e.g., Virtual Switch Instance), or a
combination (some EVPN, TRILL, etc). This could be used in lieu of each L2
model creating their own top separate list of instances. For example, the
networking-instance could be augmented with both the VPLS and VPWS
instances in https://tools.ietf.org/html/draft-shah-bess-l2vpn-yang-00.

Some YANG models ascribe greatness from the start, others achieve
greatness through refinement, while still others have greatness thrust
upon them. routing-cfg would fall into the last category…

Thanks,
Acee 

On 11/24/15, 4:24 AM, "Martin Bjorklund"  wrote:

>Hi,
>
>"Acee Lindem (acee)"  wrote:
>> We had a lot of good discussions at IETF 94 with respect to the
>> ietf-routing and how it could be augmented in the future to support
>>I2RS.
>> These discussions are ongoing.
>> 
>> One current change that I would like to propose is to change the base
>> instance container from routing-instance to networking-instance.
>
>Is the idea to simply rename the "routing-instance" container to
>"networking-instance"?
>
>Then we would have:
>
>   +--rw routing
>  +--rw networking-instance
>
>Would you keep the top-level name "routing"?
>
>
>
>
>/martin
>
>
>
>
>> This
>> would provide an instance definition that could be augmented for L2
>> protocols and service functionality as well as L3. It is also consistent
>> with the term used in both
>> https://www.ietf.org/id/draft-rtgyangdt-rtgwg-device-model-01.txt and
>> https://www.ietf.org/id/draft-openconfig-rtgwg-network-instance-01.txt.
>> 
>> Thanks,
>> Acee 
>> 
>> ___
>> netmod mailing list
>> netmod@ietf.org
>> https://www.ietf.org/mailman/listinfo/netmod
>> 

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

Re: [netmod] [Rtg-yang-coord] draft-ietf-netmod-routing-cfg

[Acee Lindem (acee)]

Hi Lada, 

On 11/25/15, 3:26 AM, "Ladislav Lhotka"  wrote:

>"Acee Lindem (acee)"  writes:
>
>> Hi Martin,
>>  
>> I think using the more generic term, “networking”, at the top would be
>> preferable. What we need is an instance abstraction that covers L3
>
>Hmm, shall we also rename "routing-protocol" to "networking-protocol"?
>Seriously, I am concerned that we are drifting away from the original
>focus of the data model. We should keep in mind it needs to remain
>usable by hosts (even constrained ones) and simple routers because there
>is no other model such devices could use.

In the Routing YANG design team, we are now considering a different
approach which would satisfy this requirement and move the elements the of
ietf-routing. There is no need to rename if we can make this work.

Thanks,
Acee


>
>> (e.g., virtual router or VRF), L2 (e.g., Virtual Switch Instance), or
>> a combination (some EVPN, TRILL, etc). This could be used in lieu of
>> each L2 model creating their own top separate list of instances. For
>> example, the networking-instance could be augmented with both the VPLS
>> and VPWS instances in
>> https://tools.ietf.org/html/draft-shah-bess-l2vpn-yang-00.
>>
>> Some YANG models ascribe greatness from the start, others achieve
>> greatness through refinement, while still others have greatness thrust
>> upon them. routing-cfg would fall into the last category…
>
>If it ever gets finished.
>
>Lada
>
>>
>> Thanks,
>> Acee 
>>
>> On 11/24/15, 4:24 AM, "Martin Bjorklund"  wrote:
>>
>>>Hi,
>>>
>>>"Acee Lindem (acee)"  wrote:
>>>> We had a lot of good discussions at IETF 94 with respect to the
>>>> ietf-routing and how it could be augmented in the future to support
>>>>I2RS.
>>>> These discussions are ongoing.
>>>> 
>>>> One current change that I would like to propose is to change the base
>>>> instance container from routing-instance to networking-instance.
>>>
>>>Is the idea to simply rename the "routing-instance" container to
>>>"networking-instance"?
>>>
>>>Then we would have:
>>>
>>>   +--rw routing
>>>  +--rw networking-instance
>>>
>>>Would you keep the top-level name "routing"?
>>>
>>>
>>>
>>>
>>>/martin
>>>
>>>
>>>
>>>
>>>> This
>>>> would provide an instance definition that could be augmented for L2
>>>> protocols and service functionality as well as L3. It is also
>>>>consistent
>>>> with the term used in both
>>>> https://www.ietf.org/id/draft-rtgyangdt-rtgwg-device-model-01.txt and
>>>> 
>>>>https://www.ietf.org/id/draft-openconfig-rtgwg-network-instance-01.txt.
>>>> 
>>>> Thanks,
>>>> Acee 
>>>> 
>>>> ___
>>>> netmod mailing list
>>>> netmod@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/netmod
>>>> 
>>
>> ___
>> Rtg-yang-coord mailing list
>> rtg-yang-co...@ietf.org
>> https://www.ietf.org/mailman/listinfo/rtg-yang-coord
>
>-- 
>Ladislav Lhotka, CZ.NIC Labs
>PGP Key ID: E74E8C0C

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

Re: [netmod] NETMOD WG LC: draft-ietf-netmod-opstate-reqs-01

[Acee Lindem (acee)]

Hi Rob, 
Thanks for authoring the comprehensive response. I’m in complete agreement
and support publication of the document.
Thanks,
Acee 

On 12/18/15, 6:33 AM, "netmod on behalf of Robert Wilton -X (rwilton -
ENSOFT LIMITED at Cisco)"  wrote:

>Hi,
>
>On 17/12/2015 23:45, Randy Presuhn wrote:
>> Hi -
>>
>>> From: Robert Wilton
>>> Sent: Dec 17, 2015 1:12 PM
>>> To: Andy Bierman
>>> Cc: "netmod@ietf.org"
>>> Subject: Re: [netmod] NETMOD WG LC: draft-ietf-netmod-opstate-reqs-01
>> ...
>>>  Your requirement is a bit too strong for my liking.
>>>
>>>  To paraphrase your requirement text, it is forcing that all
>>>  compliant NETCONF/RESTCONF servers MUST support any clients that
>>>do
>>>  not want to differentiate between intended config and applied
>>>  config.
>> Do do otherwise sound to me like an interoperability disaster,
>> and would encourage the "siloization" of toolsets.
>>
>>>  However, this requires all opstate aware servers:
>>>
>>>   - To handle a mix of clients, some of which are opstate aware,
>>>and
>>>   some that are not.
>> This seems perfectly reasonable.  To do otherwise torpedoes the very
>> notion of interoperability.
>>
>>>   - To potentially handle a mix of requests, some of which are
>>>   opstate aware requests, and some are not.
>> Ditto.
>>
>>>  It also prevents:
>>>
>>>   - Having a server that is implemented to only support opstate
>>>aware
>>>   clients.
>> Avoiding the creation of such servers sounds like a *good* thing to me.
>>
>>>   - Having a server side configuration knob to control the
>>>behaviour
>>>   (since it would affect the semantics for all clients).
>> This also sounds like something which it would be desireable to prevent.
>>
>> I think I'm squarely with Andy on this one.
>
>Taking a step back ...
>
>I am probably way off the mark, but my perception is that some (perhaps
>many) of the folks in the WG still perceive that the opstate
>requirements are niche requirements for some unusual scenarios, and that
>everyone else is happy with the status quo and don't want/need them.
>
>Alas, I don't share that view.  For me, the opstate requirements can be
>summarized as saying that the operators just want to know what
>configuration the device is actually running in a format that is
>convenient for them to use.  This really doesn't appear to be
>unreasonable request to me, and if I was writing to a network
>manageability API then I would choose to use opstate because I perceive
>that it is a more robust and easier to use API.  The counter arguments
>appear to be that it is too hard for devices to provide this
>information, and that the operators have historically managed without it.
>
>However, I think that several things have changed, and hence negate
>these counter arguments: (i) the operators want to have much more
>automation and management over their devices, (ii) they have found a way
>to group together and have a more vocal voice about what they need and
>want, (iii) the operators have realized that they don't need to wait for
>the SDOs and can create defacto standard models on their own if they
>have to.
>
>Personally, I would like us to stop spending time churning on the
>requirements and actually get on to discussing the solutions.  To be
>honest, there has been relatively little change in my understanding of
>the requirements from reading draft-openconfig-netmod-opstate-01 back in
>July, and I was expecting to discuss the solution drafts back in
>September.  Here we are in December, and I'm not convinced that we have
>truly made significant progress.
>
>The only reason that I submitted a solution draft to this problem was
>because I thought it unlikely that OpenConfig would support a multiple
>datastore solution, and I could see strong resistance amongst the IETF
>engineers to the proposed OpenConfig solution.  I was hoping that my
>proposed solution might be seen for the compromise that it is between
>the two opposing positions.  But I care less on what the solution is,
>and more whether we can agree on one and move forward.
>
>As someone that is quite new to SDO processes, my main concern is that
>IETF (and other standards bodies) are moving too slowly here, and that
>by the time that IETF have produced a sufficiently complete set of YANG
>models to manage network devices it will be too late because the
>industry will already have converged on the OpenConfig models, which
>although not perfect, are close to being usable now, and are being
>evolved at a much quicker pace ...
>
>So my hope for the early new year is that we can reach common ground
>with OpenConfig and converge on a single set of YANG modules for
>managing network devices, and that includes having a solution to the
>Opstate problem.
>
>Finally, if my acquiescing to Andy's requirement is helpful to move this
>process forward then that is fine with me.  As I have previously
>indicated, I don't really think that it helps with framing or

Re: [netmod] NETMOD WG LC: draft-ietf-netmod-opstate-reqs-01

[Acee Lindem (acee)]

Jurgen, Lada, 

On 12/22/15, 6:45 AM, "netmod on behalf of Ladislav Lhotka"
 wrote:

>
>> On 22 Dec 2015, at 12:38, Benoit Claise  wrote:
>> 
>> Jürgen,
>>> On Mon, Dec 21, 2015 at 06:47:49PM +0100, Benoit Claise wrote:
>>> 
 I hope that nobody disagrees that the operational state design and how
 to structure the models are the two blocking factors to publish YANG
 models. If you disagree or don't see this, let me know, I should
 communicate better.
>>> Even if it may spoil your day, I disagree that there is a blocking
>>> factor that should stop us from publishing models.
>> Interestingly, I received that feedback again recently, this time from
>>the OSPF and ISIS YANG model authors.
>
>Did they mention any reason *why* it is a blocking factor for their
>modules?

This should be obvious - the OSPF and IS-IS WG are not going to publish
YANG models that don’t meet the ops-state requirements. Why would we
publish standards that don’t meet the requirements and are, consequently,
irrelevant? Failure to recognize this is a real blocking issue.

Acee




>
>Thanks, Lada
>
>>> There seem to be
>>> ways to address the requirements without having to block all work or
>>> to redo what that we have published.
>> That's my hope too.
>>> But sure, if you make it a
>>> blocking factor, it will be one.
>> I'll chose to ignore this last sentence.
>> 
>> Regards, Benoit
>>> 
 I hope that nobody really believes that because some people in IETF
(or
 in any other SDOs) thinks that what those operators want is a bad
idea,
 those operators will not get what they request/pay for from their
suppliers.
>>> To be fair, those operators also tell us that they use protocols that
>>> are not IETF protocols and it remains somewhat unclear what those
>>> protocols are we are expected to optimize data model solutions for.
>>> 
>>> /js
>>> 
>> 
>> ___
>> netmod mailing list
>> netmod@ietf.org
>> https://www.ietf.org/mailman/listinfo/netmod
>
>--
>Ladislav Lhotka, CZ.NIC Labs
>PGP Key ID: E74E8C0C
>
>
>
>
>___
>netmod mailing list
>netmod@ietf.org
>https://www.ietf.org/mailman/listinfo/netmod

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

Re: [netmod] NETMOD WG LC: draft-ietf-netmod-opstate-reqs-01

[Acee Lindem (acee)]

Hi Lada,

On 12/22/15, 7:25 AM, "Ladislav Lhotka"  wrote:

>Hi Acee,
>
>> On 22 Dec 2015, at 13:03, Acee Lindem (acee)  wrote:
>> 
>> Jurgen, Lada, 
>> 
>> On 12/22/15, 6:45 AM, "netmod on behalf of Ladislav Lhotka"
>>  wrote:
>> 
>>> 
>>>> On 22 Dec 2015, at 12:38, Benoit Claise  wrote:
>>>> 
>>>> Jürgen,
>>>>> On Mon, Dec 21, 2015 at 06:47:49PM +0100, Benoit Claise wrote:
>>>>> 
>>>>>> I hope that nobody disagrees that the operational state design and
>>>>>>how
>>>>>> to structure the models are the two blocking factors to publish YANG
>>>>>> models. If you disagree or don't see this, let me know, I should
>>>>>> communicate better.
>>>>> Even if it may spoil your day, I disagree that there is a blocking
>>>>> factor that should stop us from publishing models.
>>>> Interestingly, I received that feedback again recently, this time from
>>>> the OSPF and ISIS YANG model authors.
>>> 
>>> Did they mention any reason *why* it is a blocking factor for their
>>> modules?
>> 
>> This should be obvious - the OSPF and IS-IS WG are not going to publish
>> YANG models that don’t meet the ops-state requirements. Why would we
>
>Can you please explain what specific ops-state requirements aren't met in
>those modules? I am interested because the same problem may possibly be
>present in our ietf-routing module.

That’s easy - the requirements as stated in
https://datatracker.ietf.org/doc/draft-ietf-netmod-opstate-reqs/

We could go back and reorganize the IGP models and add separate leaves for
intended and applied config and meet these requirements. However, if we
conclude on a more elegant solution, it would be great to avail ourselves
to that solution. 

Thanks,
Acee 



>
>Thanks, Lada
>
>> publish standards that don’t meet the requirements and are,
>>consequently,
>> irrelevant? Failure to recognize this is a real blocking issue.
>> 
>> Acee
>> 
>> 
>> 
>> 
>>> 
>>> Thanks, Lada
>>> 
>>>>> There seem to be
>>>>> ways to address the requirements without having to block all work or
>>>>> to redo what that we have published.
>>>> That's my hope too.
>>>>> But sure, if you make it a
>>>>> blocking factor, it will be one.
>>>> I'll chose to ignore this last sentence.
>>>> 
>>>> Regards, Benoit
>>>>> 
>>>>>> I hope that nobody really believes that because some people in IETF
>>>>>> (or
>>>>>> in any other SDOs) thinks that what those operators want is a bad
>>>>>> idea,
>>>>>> those operators will not get what they request/pay for from their
>>>>>> suppliers.
>>>>> To be fair, those operators also tell us that they use protocols that
>>>>> are not IETF protocols and it remains somewhat unclear what those
>>>>> protocols are we are expected to optimize data model solutions for.
>>>>> 
>>>>> /js
>>>>> 
>>>> 
>>>> ___
>>>> netmod mailing list
>>>> netmod@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/netmod
>>> 
>>> --
>>> Ladislav Lhotka, CZ.NIC Labs
>>> PGP Key ID: E74E8C0C
>>> 
>>> 
>>> 
>>> 
>>> ___
>>> netmod mailing list
>>> netmod@ietf.org
>>> https://www.ietf.org/mailman/listinfo/netmod
>
>--
>Ladislav Lhotka, CZ.NIC Labs
>PGP Key ID: E74E8C0C
>
>
>
>

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

Re: [netmod] NETMOD WG LC: draft-ietf-netmod-opstate-reqs-01

[Acee Lindem (acee)]

On 12/23/15, 3:22 AM, "netmod on behalf of Ladislav Lhotka"
 wrote:

>
>> On 23 Dec 2015, at 04:06, Kent Watsen  wrote:
>> 
>> 
>> 
>> 
>> 
>> 
>> On 12/21/15, 2:21 PM, "netmod on behalf of Ladislav Lhotka"
>> wrote:
>> 
>>> 
 On 21 Dec 2015, at 19:02, Juergen Schoenwaelder
 wrote:
 
 On Mon, Dec 21, 2015 at 06:47:49PM +0100, Benoit Claise wrote:
 
> I hope that nobody disagrees that the operational state design and
>how 
> to structure the models are the two blocking factors to publish YANG
> models. If you disagree or don't see this, let me know, I should
> communicate better.
 
 Even if it may spoil your day, I disagree that there is a blocking
 factor that should stop us from publishing models. There seem to be
 ways to address the requirements without having to block all work or
 to redo what that we have published. But sure, if you make it a
 blocking factor, it will be one.
>>> 
>>> I agree with Juergen. It is not clear to me how the proposed split
>>>between intended and applied configuration is supposed to affect the
>>>data models we are working on.
>> 
>> 
>> As I understand it, solution #1 affects the models themselves, whereas
>>solutions #2 and #3 are transparent to the models.
>
>Then #1 looks like a non-starter to me.

I’d like to point out that we also have the requirement to allow retrieval
of derived-state along with intended-config and applied-config. This will
require modification to most of the existing YANG drafts as most now have
separate trees for config and operational state. Note that this is
discussed in sections 6, 7.3, and 7.4 of
https://www.ietf.org/id/draft-wilton-netmod-opstate-yang-02.txt.

Thanks,
Acee 


>
>Lada
>
>> 
>> Kent
>> 
>> 
>> 
>>> Lada
>>> 
 
> I hope that nobody really believes that because some people in IETF
>(or 
> in any other SDOs) thinks that what those operators want is a bad
>idea, 
> those operators will not get what they request/pay for from their
>suppliers.
 
 To be fair, those operators also tell us that they use protocols that
 are not IETF protocols and it remains somewhat unclear what those
 protocols are we are expected to optimize data model solutions for.
 
 /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
>>> 
>>> --
>>> Ladislav Lhotka, CZ.NIC Labs
>>> PGP Key ID: E74E8C0C
>>> 
>>> 
>>> 
>>> 
>>> ___
>>> netmod mailing list
>>> netmod@ietf.org
>>> https://www.ietf.org/mailman/listinfo/netmod
>
>--
>Ladislav Lhotka, CZ.NIC Labs
>PGP Key ID: E74E8C0C
>
>
>
>
>___
>netmod mailing list
>netmod@ietf.org
>https://www.ietf.org/mailman/listinfo/netmod

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

Re: [netmod] NETMOD WG LC: draft-ietf-netmod-opstate-reqs-01

[Acee Lindem (acee)]

From: Andy Bierman mailto:a...@yumaworks.com>>
Date: Wednesday, December 23, 2015 at 10:46 AM
To: Acee Lindem mailto:a...@cisco.com>>
Cc: Ladislav Lhotka mailto:lho...@nic.cz>>, Kent Watsen 
mailto:kwat...@juniper.net>>, 
"netmod@ietf.org<mailto:netmod@ietf.org>" 
mailto:netmod@ietf.org>>
Subject: Re: [netmod] NETMOD WG LC: draft-ietf-netmod-opstate-reqs-01



On Wed, Dec 23, 2015 at 7:01 AM, Acee Lindem (acee) 
mailto:a...@cisco.com>> wrote:

On 12/23/15, 3:22 AM, "netmod on behalf of Ladislav Lhotka"
mailto:netmod-boun...@ietf.org> on behalf of 
lho...@nic.cz<mailto:lho...@nic.cz>> wrote:

>
>> On 23 Dec 2015, at 04:06, Kent Watsen 
>> mailto:kwat...@juniper.net>> wrote:
>>
>>
>>
>>
>>
>>
>> On 12/21/15, 2:21 PM, "netmod on behalf of Ladislav Lhotka"
>>mailto:netmod-boun...@ietf.org> on behalf of 
>>lho...@nic.cz<mailto:lho...@nic.cz>> wrote:
>>
>>>
>>>> On 21 Dec 2015, at 19:02, Juergen Schoenwaelder
>>>>mailto:j.schoenwael...@jacobs-university.de>>
>>>> wrote:
>>>>
>>>> On Mon, Dec 21, 2015 at 06:47:49PM +0100, Benoit Claise wrote:
>>>>
>>>>> I hope that nobody disagrees that the operational state design and
>>>>>how
>>>>> to structure the models are the two blocking factors to publish YANG
>>>>> models. If you disagree or don't see this, let me know, I should
>>>>> communicate better.
>>>>
>>>> Even if it may spoil your day, I disagree that there is a blocking
>>>> factor that should stop us from publishing models. There seem to be
>>>> ways to address the requirements without having to block all work or
>>>> to redo what that we have published. But sure, if you make it a
>>>> blocking factor, it will be one.
>>>
>>> I agree with Juergen. It is not clear to me how the proposed split
>>>between intended and applied configuration is supposed to affect the
>>>data models we are working on.
>>
>>
>> As I understand it, solution #1 affects the models themselves, whereas
>>solutions #2 and #3 are transparent to the models.
>
>Then #1 looks like a non-starter to me.

I’d like to point out that we also have the requirement to allow retrieval
of derived-state along with intended-config and applied-config. This will
require modification to most of the existing YANG drafts as most now have
separate trees for config and operational state. Note that this is
discussed in sections 6, 7.3, and 7.4 of
https://www.ietf.org/id/draft-wilton-netmod-opstate-yang-02.txt.


A NETCONF  with a subtree filter  can retrieveg both config and non-config 
subtrees
at the same time.  A new RPC can be added (or existing  RPC extended) to
filter various conditions.  I don't see how the YANG data layout affects the 
definition
of "rpc" statements in another module.

There is the requirement to be able to do the retrievals but there is also this 
requirement:


 C.  The mappings needs to be programmatically consumable

Now, if the derived-state nodes are located with the config-nodes, then this is 
readily satisfied. Another way of satisfying the requirement may be structural 
and naming conventions but this is not as sure as co-location.

Thanks,
Acee



Thanks,
Acee


Andy



>
>Lada
>
>>
>> Kent
>>
>>
>>
>>> Lada
>>>
>>>>
>>>>> I hope that nobody really believes that because some people in IETF
>>>>>(or
>>>>> in any other SDOs) thinks that what those operators want is a bad
>>>>>idea,
>>>>> those operators will not get what they request/pay for from their
>>>>>suppliers.
>>>>
>>>> To be fair, those operators also tell us that they use protocols that
>>>> are not IETF protocols and it remains somewhat unclear what those
>>>> protocols are we are expected to optimize data model solutions for.
>>>>
>>>> /js
>>>>
>>>> --
>>>> Juergen Schoenwaelder   Jacobs University Bremen gGmbH
>>>> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
>>>> Fax:   +49 421 200 3103 <http://www.jacobs-university.de/>
>>>>
>>>> ___
>>>> netmod mailing list
>>>> netmod@ietf.org<mailto:netmod@ietf.org>
>>>> https://www.ietf.org/mailman/listinfo/netmod
>>>
>>> --
>>> Ladislav Lhotka, CZ.NIC Labs
>>> PGP Key ID: E74E8C0C
>>>
>>>
>>>
>>>
>>> ___
>>> netmod mailing list
>>> netmod@ietf.org<mailto:netmod@ietf.org>
>>> https://www.ietf.org/mailman/listinfo/netmod
>
>--
>Ladislav Lhotka, CZ.NIC Labs
>PGP Key ID: E74E8C0C
>
>
>
>
>___
>netmod mailing list
>netmod@ietf.org<mailto:netmod@ietf.org>
>https://www.ietf.org/mailman/listinfo/netmod

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

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

Re: [netmod] NETMOD WG LC: draft-ietf-netmod-opstate-reqs-01

[Acee Lindem (acee)]

From: Andy Bierman mailto:a...@yumaworks.com>>
Date: Wednesday, December 23, 2015 at 11:18 AM
To: Acee Lindem mailto:a...@cisco.com>>
Cc: Ladislav Lhotka mailto:lho...@nic.cz>>, Kent Watsen 
mailto:kwat...@juniper.net>>, 
"netmod@ietf.org<mailto:netmod@ietf.org>" 
mailto:netmod@ietf.org>>
Subject: Re: [netmod] NETMOD WG LC: draft-ietf-netmod-opstate-reqs-01



On Wed, Dec 23, 2015 at 8:11 AM, Acee Lindem (acee) 
mailto:a...@cisco.com>> wrote:


From: Andy Bierman mailto:a...@yumaworks.com>>
Date: Wednesday, December 23, 2015 at 10:46 AM
To: Acee Lindem mailto:a...@cisco.com>>
Cc: Ladislav Lhotka mailto:lho...@nic.cz>>, Kent Watsen 
mailto:kwat...@juniper.net>>, 
"netmod@ietf.org<mailto:netmod@ietf.org>" 
mailto:netmod@ietf.org>>
Subject: Re: [netmod] NETMOD WG LC: draft-ietf-netmod-opstate-reqs-01



On Wed, Dec 23, 2015 at 7:01 AM, Acee Lindem (acee) 
mailto:a...@cisco.com>> wrote:

On 12/23/15, 3:22 AM, "netmod on behalf of Ladislav Lhotka"
mailto:netmod-boun...@ietf.org> on behalf of 
lho...@nic.cz<mailto:lho...@nic.cz>> wrote:

>
>> On 23 Dec 2015, at 04:06, Kent Watsen 
>> mailto:kwat...@juniper.net>> wrote:
>>
>>
>>
>>
>>
>>
>> On 12/21/15, 2:21 PM, "netmod on behalf of Ladislav Lhotka"
>>mailto:netmod-boun...@ietf.org> on behalf of 
>>lho...@nic.cz<mailto:lho...@nic.cz>> wrote:
>>
>>>
>>>> On 21 Dec 2015, at 19:02, Juergen Schoenwaelder
>>>>mailto:j.schoenwael...@jacobs-university.de>>
>>>> wrote:
>>>>
>>>> On Mon, Dec 21, 2015 at 06:47:49PM +0100, Benoit Claise wrote:
>>>>
>>>>> I hope that nobody disagrees that the operational state design and
>>>>>how
>>>>> to structure the models are the two blocking factors to publish YANG
>>>>> models. If you disagree or don't see this, let me know, I should
>>>>> communicate better.
>>>>
>>>> Even if it may spoil your day, I disagree that there is a blocking
>>>> factor that should stop us from publishing models. There seem to be
>>>> ways to address the requirements without having to block all work or
>>>> to redo what that we have published. But sure, if you make it a
>>>> blocking factor, it will be one.
>>>
>>> I agree with Juergen. It is not clear to me how the proposed split
>>>between intended and applied configuration is supposed to affect the
>>>data models we are working on.
>>
>>
>> As I understand it, solution #1 affects the models themselves, whereas
>>solutions #2 and #3 are transparent to the models.
>
>Then #1 looks like a non-starter to me.

I’d like to point out that we also have the requirement to allow retrieval
of derived-state along with intended-config and applied-config. This will
require modification to most of the existing YANG drafts as most now have
separate trees for config and operational state. Note that this is
discussed in sections 6, 7.3, and 7.4 of
https://www.ietf.org/id/draft-wilton-netmod-opstate-yang-02.txt.


A NETCONF  with a subtree filter  can retrieveg both config and non-config 
subtrees
at the same time.  A new RPC can be added (or existing  RPC extended) to
filter various conditions.  I don't see how the YANG data layout affects the 
definition
of "rpc" statements in another module.

There is the requirement to be able to do the retrievals but there is also this 
requirement:


 C.  The mappings needs to be programmatically consumable

Now, if the derived-state nodes are located with the config-nodes, then this is 
readily satisfied. Another way of satisfying the requirement may be structural 
and naming conventions but this is not as sure as co-location.


There can be meta-data returned (XML attributes) that identify the additional 
properties.
This is better co-location since the pattern cannot be unintentional (as it can 
with the
config-within-state containers).

This may be an option for published models. However, for models in development, 
wouldn’t it be easier to just move the nodes rather than defining the 
relationships in meta-data?

Thanks,
Acee




Thanks,
Acee


Andy



Thanks,
Acee


Andy



>
>Lada
>
>>
>> Kent
>>
>>
>>
>>> Lada
>>>
>>>>
>>>>> I hope that nobody really believes that because some people in IETF
>>>>>(or
>>>>> in any other SDOs) thinks that what those operators want is a bad
>>>>>idea,
>>>>> those operators will not get what they request/pay for from their
>>>>>suppliers.
>&

Re: [netmod] I-D Action: draft-ietf-netmod-opstate-reqs-02.txt

[Acee Lindem (acee)]

Juergen, 

As another non-author, I disagree with this characterization of the draft.
The intended/applied configuration is an important requirement but
certainly not the only one precisely articulated in the draft.

Acee 

On 1/5/16, 3:02 PM, "netmod on behalf of Juergen Schoenwaelder"
 wrote:

>On Mon, Jan 04, 2016 at 10:29:54PM +, Kent Watsen wrote:
>> 
>> This update addresses comments received during the Last Call.
>>
>
>I not entirely happy with the new title:
>
>   Terminology and Requirements for Enhanced
>Operational State Visibility and Control
>
>Since the key contribution is the concept of intended configuration
>and applied configuration, why not put these terms into the title
>instead of "Enhanced Operational State Visibility and Control", which
>is somewhat vague? What about this proposal:
>
>  Terminology and Requirements for Distinguishing
> Intended and Applied Configuration
>
>/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

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

Re: [netmod] NETMOD WG LC: draft-ietf-netmod-opstate-reqs-01

[Acee Lindem (acee)]

Hi Martin, et al, 

On 1/8/16, 2:54 AM, "Martin Bjorklund"  wrote:

>Hi,
>
>"Acee Lindem (acee)"  wrote:
>> 
>> On 12/23/15, 3:22 AM, "netmod on behalf of Ladislav Lhotka"
>>  wrote:
>> 
>> >
>> >> On 23 Dec 2015, at 04:06, Kent Watsen  wrote:
>> >> 
>> >> 
>> >> 
>> >> 
>> >> 
>> >> 
>> >> On 12/21/15, 2:21 PM, "netmod on behalf of Ladislav Lhotka"
>> >> wrote:
>> >> 
>> >>> 
>> >>>> On 21 Dec 2015, at 19:02, Juergen Schoenwaelder
>> >>>> wrote:
>> >>>> 
>> >>>> On Mon, Dec 21, 2015 at 06:47:49PM +0100, Benoit Claise wrote:
>> >>>> 
>> >>>>> I hope that nobody disagrees that the operational state design and
>> >>>>>how 
>> >>>>> to structure the models are the two blocking factors to publish
>>YANG
>> >>>>> models. If you disagree or don't see this, let me know, I should
>> >>>>> communicate better.
>> >>>> 
>> >>>> Even if it may spoil your day, I disagree that there is a blocking
>> >>>> factor that should stop us from publishing models. There seem to be
>> >>>> ways to address the requirements without having to block all work
>>or
>> >>>> to redo what that we have published. But sure, if you make it a
>> >>>> blocking factor, it will be one.
>> >>> 
>> >>> I agree with Juergen. It is not clear to me how the proposed split
>> >>>between intended and applied configuration is supposed to affect the
>> >>>data models we are working on.
>> >> 
>> >> 
>> >> As I understand it, solution #1 affects the models themselves,
>>whereas
>> >>solutions #2 and #3 are transparent to the models.
>> >
>> >Then #1 looks like a non-starter to me.
>> 
>> I’d like to point out that we also have the requirement to allow
>>retrieval
>> of derived-state along with intended-config and applied-config. This
>>will
>> require modification to most of the existing YANG drafts as most now
>>have
>> separate trees for config and operational state.
>
>I don't agree with the conclusion that changes are needed due to this
>requirement.
>
>Solution #1 ("openconfig") requires changes to handle applied config.
>Solution #2 ("kent's") does not.
>
>Both solutions #1 and #2 use separate nodes for derived state.
>
>It might appear as #1 and #2 are very different in their handling of
>derived state, since #1 put all config false nodes directly under the
>config true nodes, whereas #2 in some cases have a top-level
>"xxx-state" config false node.
>
>But in fact #2 allows the solution in #1 as one special case.  The
>reason that RFC 7223 has a separate list for derived state interfaces
>is to allow for non-configured interfaces to be monitored.  If this
>was not a requirement, all config false nodes could (would) have been
>defined in the config true interface list.

I see that this is discussed in the latest version of
draft-ietf-netmod-rfc6087bis-05.txt and that it is “appropriate" to put
the operational state in the same subtree as the config state if it would
not exist if not configured. Is “appropriate” a recommendation?

   Careful consideration needs to be given to the location of
   operational state data.  It can either be located within the
   configuration subtree for which it applies, or it can be located
   outside the particular configuration subtree.  Placing operation
   state within the configuration subtree is appropriate if the
   operational values can only exist if the configuration exists.


However, we currently have many YANG models in progress where the config
and state trees are separate subtrees. If we all agree with the opstate
requirement for derived state, perhaps it is time to get the word out and
modify these models.

Thanks,
Acee 



>
>
>/martin

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

Re: [netmod] I-D Action: draft-ietf-netmod-opstate-reqs-02.txt

[Acee Lindem (acee)]

On 1/8/16, 7:47 AM, "netmod on behalf of Ladislav Lhotka"
 wrote:

>Juergen Schoenwaelder  writes:
>
>> On Thu, Jan 07, 2016 at 05:24:45PM +, Robert Wilton wrote:
>>> Hi Juergen,
>>> 
>>> On 07/01/2016 16:05, Juergen Schoenwaelder wrote:
>>> >On Wed, Jan 06, 2016 at 06:18:46PM +, Kent Watsen wrote:
>>> >>It’s true that the draft is largely centered around the
>>> >>intended/applied config notion, but not exclusively.  Specifically,
>>>4-B 
>>> >>has "Ability to map intended config nodes to associated derived
>>>state 
>>> >>nodes".  I think that this might be the only exclusion though and,
>>>if it 
>>> >>weren’t for it I would’ve used your title suggestion from the LC
>>> >>review.   Should one requirement have such influence over the title
>>>is 
>>> >>the question.  I was trying to be fair to it, but maybe it's going
>>>too 
>>> >>far.
>>> >>
>>> >>Regarding visibility and control, I was attempting to use common
>>>words 
>>> >>(not normative terms) here.  My intent for them is something along
>>>the 
>>> >>lines of:
>>> >>
>>> >>  visibility: read/understand
>>> >>  control: write/orchestrate
>>> >>
>>> >We do not write operational state. I have no clue how 'orchestrate'
>>> >helps me either. What is wrong with using defined terminology in
>>> >a title?
>>> I don't think that using defined terminology is a problem.  But I also
>>> think that the title that you have suggested seems to suggest a
>>>narrower 
>>> scope that what the requirements articulate.
>>> 
>>> In particular, the draft places requirements relating the
>>>configuration 
>>> to the derived state (I.e. Req 4B).
>>> 
>>> It also places further requirements on how management protocols are
>>> expected to handle synchronous and asynchronous config edit requests.
>>> (E.g. Req 2 A, B, C and associated definitions).
>>
>> Note that synchronous and asynchronous are defined in terms of
>> intended / applied configuration.
>>  
>>> I don't have a particular problem with the current title, but if you
>>> don't like visibility/control, then perhaps "Terminology and
>>> Requirements for Enhanced Handling of Operational State"?
>>
>> Better but I still think this proposal is too broad given the content
>> of the document. I still believe my proposal is right to the point.
>
>+1
>
>The draft talks about introducing applied configuration and its
>relationship to state data and intended configuration (which, I believe,
>is the good old "running"). I don't see any enhanced handling of
>operational state.

The draft is quite succinct and I’m not sure how you and Juergen do not
agree that there are requirements beyond intended/applied state. Perhaps
you do not agree with them? Refer to requirements 3.(B & C) and 4.(B & C).
For your convenience, I’ve excerpted them below:


   3.  Separation of the applied configuration and derived state aspects
   of operational state; ability to retrieve them independently and
   together

   A.  Be able to retrieve only the applied configuration aspects of
   operational state

   B.  Be able to retrieve only the derived state aspects of
   operational state

   C.  Be able to retrieve both the applied configuration and
   derived state aspects of operational state together

   4.  Ability to relate configuration with its corresponding
   operational state

   A.  Ability to map intended config nodes to corresponding applied
   config nodes

   B.  Ability to map intended config nodes to associated derived
   state nodes

   C.  The mappings needs to be programmatically consumable


Thanks,
Acee 


>
>Lada
>
>>
>> /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
>
>-- 
>Ladislav Lhotka, CZ.NIC Labs
>PGP Key ID: E74E8C0C
>
>___
>netmod mailing list
>netmod@ietf.org
>https://www.ietf.org/mailman/listinfo/netmod

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

Re: [netmod] applied configuration and system-controlled entries

[Acee Lindem (acee)]

On 1/11/16, 2:54 PM, "netmod on behalf of Martin Bjorklund"
 wrote:

>Ladislav Lhotka  wrote:
>> Hi Gert,
>> 
>> > On 11 Jan 2016, at 14:25, Gert Grammel  wrote:
>> > 
>> > Lada,
>> > 
>> > The requirement says:
>> >   D.  When a configuration change for any intended configuration
>> >   node has been successfully applied to the server (e.g. not
>> >   failed, nor deferred due to absent hardware) then the
>> >   existence and value of the corresponding applied
>> >   configuration node must match the intended configuration
>> >   node.
>> > 
>> > I don't see that this would limit the case you described below. In
>> > your case there is no intended config, hence there is no
>> > "corresponding applied configuration" either.
>> 
>> You are right, the requirement can be interpreted this way. I thought
>> that applied configuration was supposed to be identical to intended
>> after some synchronization period.
>
>This is a very important point to clarify.  Can there ever be data in
>"applied" that is not in "intended"?  I think Anees & Rob previously
>said "no", but I might be wrong.

My opinion is that there is a 1-1 relationship between “applied” and
“intended” config.

Thanks,
Acee 

>
>
>
>/martin
>
>
>> 
>> > 
>> > Besides that, the case you mentioned should be clearly in scope.
>> 
>> Great, then I am open to discussing what this could mean for the
>> existing modules (ietf-interfaces, ietf-routing, ACL etc.).
>> 
>> One useful change to YANG semantics could be that a leafref with
>> require-instance=true would refer to applied
>> configuration. Specifically, the ACL module could then simply use
>> "if:interface-ref" (with require-instance=true) as the type for
>> "input-interface".
>> 
>> Thanks, Lada
>> 
>> >  
>> > 
>> > --Gert
>> > 
>> >> -Original Message-
>> >> From: netmod [mailto:netmod-boun...@ietf.org] On Behalf Of Ladislav
>> >> Lhotka
>> >> Sent: 07 January 2016 11:20
>> >> To: NETMOD WG
>> >> Subject: [netmod] applied configuration and system-controlled entries
>> >> 
>> >> Hi,
>> >> 
>> >> a good use of applied configuration could be to formalize the concept
>> >> of
>> >> system-controlled entries as defined in RFC 7223, routing-cfg, and
>> >> probably
>> >> elsewhere, too.
>> >> 
>> >> My idea is that system-controlled interfaces or other entries would
>> >> appear in
>> >> applied configuration, but not in intended configuration until
>> >> something needs
>> >> to be really configured. We could then permit leafrefs from intended
>> >> configuration to refer to leafs in applied configuration. One case
>> >> where this
>> >> would be useful is the ACL module, where match conditions refering to
>> >> interfaces currently have to use plain strings as references to
>> >> interface names.
>> >> 
>> >> However, the above idea seems to be at odds with requirement 1D in
>> >> opstate-
>> >> reqs-02. I wonder: could that requirement be relaxed or removed so
>> >> that the
>> >> above use case can be supported?
>> >> 
>> >> Thanks, Lada
>> >> 
>> >> --
>> >> Ladislav Lhotka, CZ.NIC Labs
>> >> PGP Key ID: E74E8C0C
>> >> 
>> >> 
>> >> 
>> >> 
>> >> ___
>> >> netmod mailing list
>> >> netmod@ietf.org
>> >> https://www.ietf.org/mailman/listinfo/netmod
>> 
>> --
>> Ladislav Lhotka, CZ.NIC Labs
>> PGP Key ID: E74E8C0C
>> 
>> 
>> 
>> 
>> ___
>> netmod mailing list
>> netmod@ietf.org
>> https://www.ietf.org/mailman/listinfo/netmod
>> 
>
>___
>netmod mailing list
>netmod@ietf.org
>https://www.ietf.org/mailman/listinfo/netmod

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

Re: [netmod] applied configuration and system-controlled entries

[Acee Lindem (acee)]

On 1/11/16, 3:11 PM, "Ladislav Lhotka"  wrote:

>
>> On 11 Jan 2016, at 15:07, Acee Lindem (acee)  wrote:
>> 
>> 
>> 
>> On 1/11/16, 2:54 PM, "netmod on behalf of Martin Bjorklund"
>>  wrote:
>> 
>>> Ladislav Lhotka  wrote:
>>>> Hi Gert,
>>>> 
>>>>> On 11 Jan 2016, at 14:25, Gert Grammel  wrote:
>>>>> 
>>>>> Lada,
>>>>> 
>>>>> The requirement says:
>>>>>  D.  When a configuration change for any intended configuration
>>>>>  node has been successfully applied to the server (e.g. not
>>>>>  failed, nor deferred due to absent hardware) then the
>>>>>  existence and value of the corresponding applied
>>>>>  configuration node must match the intended configuration
>>>>>  node.
>>>>> 
>>>>> I don't see that this would limit the case you described below. In
>>>>> your case there is no intended config, hence there is no
>>>>> "corresponding applied configuration" either.
>>>> 
>>>> You are right, the requirement can be interpreted this way. I thought
>>>> that applied configuration was supposed to be identical to intended
>>>> after some synchronization period.
>>> 
>>> This is a very important point to clarify.  Can there ever be data in
>>> "applied" that is not in "intended"?  I think Anees & Rob previously
>>> said "no", but I might be wrong.
>> 
>> My opinion is that there is a 1-1 relationship between “applied” and
>> “intended” config.
>
>Do you mean their data model or instances? The point is: if the device
>has an interface, say "eth0" that is operational and configurable, but
>hasn't been configured so far via intended config, then does "eth0" entry
>appear in the "if:interface" list of applied config or not?

Data model.

Acee


>
>Lada
>
>> 
>> Thanks,
>> Acee 
>> 
>>> 
>>> 
>>> 
>>> /martin
>>> 
>>> 
>>>> 
>>>>> 
>>>>> Besides that, the case you mentioned should be clearly in scope.
>>>> 
>>>> Great, then I am open to discussing what this could mean for the
>>>> existing modules (ietf-interfaces, ietf-routing, ACL etc.).
>>>> 
>>>> One useful change to YANG semantics could be that a leafref with
>>>> require-instance=true would refer to applied
>>>> configuration. Specifically, the ACL module could then simply use
>>>> "if:interface-ref" (with require-instance=true) as the type for
>>>> "input-interface".
>>>> 
>>>> Thanks, Lada
>>>> 
>>>>> 
>>>>> 
>>>>> --Gert
>>>>> 
>>>>>> -Original Message-
>>>>>> From: netmod [mailto:netmod-boun...@ietf.org] On Behalf Of Ladislav
>>>>>> Lhotka
>>>>>> Sent: 07 January 2016 11:20
>>>>>> To: NETMOD WG
>>>>>> Subject: [netmod] applied configuration and system-controlled
>>>>>>entries
>>>>>> 
>>>>>> Hi,
>>>>>> 
>>>>>> a good use of applied configuration could be to formalize the
>>>>>>concept
>>>>>> of
>>>>>> system-controlled entries as defined in RFC 7223, routing-cfg, and
>>>>>> probably
>>>>>> elsewhere, too.
>>>>>> 
>>>>>> My idea is that system-controlled interfaces or other entries would
>>>>>> appear in
>>>>>> applied configuration, but not in intended configuration until
>>>>>> something needs
>>>>>> to be really configured. We could then permit leafrefs from intended
>>>>>> configuration to refer to leafs in applied configuration. One case
>>>>>> where this
>>>>>> would be useful is the ACL module, where match conditions refering
>>>>>>to
>>>>>> interfaces currently have to use plain strings as references to
>>>>>> interface names.
>>>>>> 
>>>>>> However, the above idea seems to be at odds with requirement 1D in
>>>>>> opstate-
>>>>>> reqs-02. I wonder: could that requirement be relaxed or removed so
>>>>>> that the
>>>>>> above use case can be supported?
>>>>>> 
>>>>>> Thanks, Lada
>>>>>> 
>>>>>> --
>>>>>> Ladislav Lhotka, CZ.NIC Labs
>>>>>> PGP Key ID: E74E8C0C
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> ___
>>>>>> netmod mailing list
>>>>>> netmod@ietf.org
>>>>>> https://www.ietf.org/mailman/listinfo/netmod
>>>> 
>>>> --
>>>> Ladislav Lhotka, CZ.NIC Labs
>>>> PGP Key ID: E74E8C0C
>>>> 
>>>> 
>>>> 
>>>> 
>>>> ___
>>>> netmod mailing list
>>>> netmod@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/netmod
>>>> 
>>> 
>>> ___
>>> netmod mailing list
>>> netmod@ietf.org
>>> https://www.ietf.org/mailman/listinfo/netmod
>
>--
>Ladislav Lhotka, CZ.NIC Labs
>PGP Key ID: E74E8C0C
>
>
>
>

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

Re: [netmod] applied configuration and system-controlled entries

[Acee Lindem (acee)]

On 1/11/16, 3:13 PM, "Juergen Schoenwaelder"
 wrote:

>On Mon, Jan 11, 2016 at 02:07:13PM +, Acee Lindem (acee) wrote:
>> 
>> My opinion is that there is a 1-1 relationship between “applied” and
>> “intended” config.
>>
>
>I do not understand. Please clarify what 1-1 means here.

In the context of these requirements, I do not agree that applied config
includes anything else. The data models for the intended and applied
config are the aligned and all other state falls in the category of
derived state.  

Thanks,
Acee 

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

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

Re: [netmod] Working group Last Call: draft-ietf-netmod-acl-model-06

[Acee Lindem (acee)]

On 1/22/16, 12:56 AM, "netmod on behalf of Ebben Aries"
 wrote:

>
>On 01/21/2016 12:45 AM, Qin Wu wrote:
>> 1. This draft defines two module, one is IETF-PACKET-FIELDS, the other
>>is ietf-access-control-list module,
>> I am wondering whether ietf-packet-fields module can be defined in more
>>generic way that can be applied to other modules defined somewhere else?
>> e.g., in ietf-packet-fields module, acl-ip-header-fields grouping is
>>defined, I am wondering whether prefix "acl-" can be removed to make it
>>more generic?
>
>What you'll likely run into here is that the header fields defined in
>acl-*-header-fields are more or less the lowest common denominators for
>the application of "acl" - Not all header fields are defined here.
>
>I suppose an approach could be to define generic groupings of all header
>fields and create per application groupings, referencing what is
>supported with appropriate constraints, etc...  Not sure what that buys
>here since you're likely to have overlap but not complete parity between
>the different consumers of these packet fields.

Furthermore, this is not a generic IP packet fields YANG module. It is a
module for matching IP packet fields using traditional ACL semantics.
Hence, changing the container name won’t change the content or semantics.
If anything, the module name should be changed to include “acl-“ and not
imply that it is generic.

Thanks,
Acee



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

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

Re: [netmod] IPR Check: draft-ietf-netmod-opstate-reqs-01

[Acee Lindem (acee)]

As a contributor to the NETMOD Operational State requirements draft
discussion, I am not aware of any relevant IPR.
Thanks,
Acee 

On 1/26/16, 10:57 AM, "netmod on behalf of Mahesh Jethanandani"
 wrote:

>I am not aware of any IPR.
>
>> On Dec 16, 2015, at 6:13 AM, Nadeau Thomas 
>>wrote:
>> 
>> This mail starts the IPR poll on draft-ietf-netmod-opstate-reqs-01.
>> 
>> Are you aware of any IPR that applies to
>>draft-ietf-netmod-opstate-reqs-01?
>> If so, has this IPR been disclosed in compliance with IETF IPR rules
>>(see RFCs
>> 3979, 4879, 3669 and 5378 for more details)?
>> 
>> If you are listed as a document author or contributor please respond to
>>this
>> email explicitly regardless of whether or not you are aware of any
>>relevant IPR.
>> The response needs to be sent to the NETMOD WG mailing list.  The
>>document
>> will not advance to the next stage until a response has been received
>>from each
>> author and contributor.
>> 
>> If you are on the NETMOD WG email list but are not listed as an author
>>or
>> contributor, then please explicitly respond only if you are aware of
>>any IPR that
>> has not yet been disclosed in conformance with IETF rules.
>> 
>> Thank you,
>> 
>> Kent and Tom, NETMOD WG Chairs
>> 
>> ___
>> netmod mailing list
>> netmod@ietf.org
>> https://www.ietf.org/mailman/listinfo/netmod
>
>Mahesh Jethanandani
>mjethanand...@gmail.com
>
>
>
>___
>netmod mailing list
>netmod@ietf.org
>https://www.ietf.org/mailman/listinfo/netmod

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

Re: [netmod] [Rtg-dt-yang-arch] [yang-doctors] Working group Last Call: draft-ietf-netmod-acl-model-06

[Acee Lindem (acee)]

All,

On 1/27/16, 9:45 AM, "netmod on behalf of Juergen Schoenwaelder"
 wrote:

>Eliot,
>
>I posted a technical review of the ACL draft on December 11th to the
>list since the document was send to WG last call. I believe the I-D
>has technical issues that need to be resolved. I am not going to
>repeat my technical comments.
>
>Note I have been one of the _few_ who actually read the I-D when it
>was sent to WG last call.

FWIW, I also read the document both after it was accepted as a WG document
and during WG last call. There have been some points of discussion during
the document’s life that were discussed on the NETMOD list or during
NETMOD open meetings. There are some YANG nodes that I probably would have
named differently as well. However, I believe WG last call is a bit late
and would not let my personal biases delay document publication.

Thanks,
Acee 


> And yes, I believe a standard in this area
>needs to be highly extensible (so we better get this right) and I
>believe it needs to be resonably match widely deployed open source
>packet filters and not just Juniper and Cisco gear.
>
>/js
>
>PS: I reduced the CC: list to the NETMOD WG since this is where the
>work is supposed to take place.
>
>On Tue, Jan 19, 2016 at 06:16:47PM +0100, Eliot Lear wrote:
>> Hi Juergen,
>> 
>> Skipping down...
>> 
>> On 1/19/16 5:48 PM, Juergen Schoenwaelder wrote:
>> 
>> > While we can have a lengthy debate about terminology, I think more
>> > important is to get functionality right.
>> 
>> Agree.  We are arguing over labels that aren't generally meant for
>> humans ANYWAY.
>> 
>> >>> I am talking about the modularity of the base model, I do not see
>>how
>> >>> the cited thread relates to this.
>> >> Among the vendors, ace-eth, ace-ipv4 and ace-ipv6 are always
>>supported. I appreciate your input, but we did this design choice as
>>design team and went forward with it. Also, the YANG models are not set
>>in stone. I definitely see models evolving.
>> > My main concern is that we need to get the extensibility of the model
>> > right. One way to make sure we achieved this goal is to actually treat
>> > everything as an extension of the core model (this forces us to get
>> > the extensibility right). This is essentially what we did with the
>> > routing data model and the interfaces data model.
>> >
>> >
>> While I agree I am also becoming concerned that we may be going down a
>> rat hole from which we may not return.  The above thread snippets have
>> lost so much context that one cannot divine what it is we are arguing
>> over.  While a design team certainly does not represent consensus, can
>> we please at least argue over what it is we are supposed to be arguing
>> over?  With regard to this model, I could imagine innumerable ways to
>> represent an access list.  The deference due the people who wrote this
>> stuff out is at least to recognize that.  If you are going to propose an
>> alternative at this point, please do it the old fashion way: send text.
>> 
>> Eliot
>> 
>
>
>
>> ___
>> netmod mailing list
>> netmod@ietf.org
>> https://www.ietf.org/mailman/listinfo/netmod
>
>
>-- 
>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

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

Re: [netmod] Yang mount / ysdl example use case

[Acee Lindem (acee)]

On 2/3/16, 1:18 AM, "Ladislav Lhotka"  wrote:

>
>> On 03 Feb 2016, at 03:24, Kent Watsen  wrote:
>> 
>> 
>> [Chair hat on]
>> 
>> Given the number of competing/complementing drafts involved, and the
>>general lack of discussion on any of them, a virtual interim meeting
>>might be an expedient way to proceed.  In fairness, we know that there
>>has been some discussion, but it hasn’t been picked up yet in a big way,
>>and now Lou has an updated draft.
>> 
>> The chairs discussed maybe scheduling one for a couple weeks from now,
>>perhaps Thursday Feb 18 starting at 10am EST?   I'm thinking
>
>Thursday at this time doesn't suit me very well, Monday till Wednesday of
>that week are OK.

I’m out the entire week of Feb 14th.

Thanks,
Acee 


>
>Lada
>
>>  about this slot only since it worked for us for previously.  Is this a
>>good time slot?  I assume to schedule for 2 hours, with a plan to end
>>early if needed - makes sense? We also need to put together a proper
>>agenda, perhaps the following?
>> 
>>  10 min: RTG DT YANG Arch team use-case summary
>>  20 min: draft-rtgyangdt-rtgwg-device-model
>>  20 min: draft-lhotka-netmod-ysdl
>>  20 min: draft-bjorklund-netmod-structural-mount
>>  50 min: general discussion or end early
>> 
>> 
>> We hope to schedule the meeting itself tomorrow or the next day, so
>>please respond quickly to this email if possible.
>> 
>> Thanks,
>> Kent and Tom
>> 
>> 
>> 
>> 
>> On 2/2/16, 2:04 PM, "netmod on behalf of Lou Berger"
>> wrote:
>> 
>>> 
>>> I thought it would be worth summarizing what we're looking for in our
>>> draft, draft-rtgyangdt-rtgwg-device-model-02 (note new version in case
>>> you missed it) with respect to the draft-lhotka-netmod-ysdl and
>>> draft-bjorklund-netmod-structural-mount drafts. This is just my view,
>>>so
>>> my co-authors may wish to chime in and correct me.
>>> 
>>> I'd be interested in hearing from the authors of YSDL and
>>> structural-mount, or anyone else for that matter, on how they see to
>>> best meet these needs.
>>> 
>>> Here's what I think our draft needs:
>>> 
>>> 1. that there be a mechanism that allows the incorporation (or
>>>  'mounting') of the data model defined by one top-level module
>>>  within another module.
>>> 
>>>  The implication here is that when information is instantiated
>>>  for the parent model it is also instantiated for the
>>>  incorporated/mounted model. In our case we expect to do this on
>>>  list element creation. Both solutions drafts cover the path
>>>  implications, so these are not repeated here.
>>> 
>>> 2. that this mechanism allow identification of specific modules to
>>>  be incorporated/mounted at time of module definition, i.e. that
>>>  no additional module is needed to support 1. This doesn't
>>>  preclude definition of such a module.
>>> 
>>> 3. that this mechanism allow for a server to control (and
>>>  identify) which modules are incorporated/mounted. (see Section
>>>  3 LNE in our draft for an envisioned usage.)
>>> 
>>> 4. that all capabilities that exist with the mounted module are
>>>  available e.g. RPC operations and notifications.
>>> 
>>> 5. while our primary requirement is for 'mounting' of top level
>>>  modules, mounting of submodules may also be useful. (DT not draft
>>>  driven.)
>>> 
>>> We make use of the above in sections 3 and 4 of rtgwg-device-model.  We
>>> see having a solution as critical for the simplifications/flexibility
>>> represented in the -02 version of our draft vs the -03 rev.  We don't
>>> see wither solution draft as significantly different and just hope for
>>>a
>>> standard solution as soon as possible.  (a draft-ietf-netmod solutions
>>> draft on the topic by BA would be fantastic given the impact on routing
>>> area -- even if it had to document two variations / alternative
>>>solutions.)
>>> 
>>> Again, this is just my opinion and my coauthors or others on the rtg
>>> area yang DT may choose to chime in.
>>> 
>>> Lou
>>> 
>>> 
>>> 
>>> ___
>>> netmod mailing list
>>> netmod@ietf.org
>>> https://www.ietf.org/mailman/listinfo/netmod
>
>--
>Ladislav Lhotka, CZ.NIC Labs
>PGP Key ID: E74E8C0C
>
>
>
>

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

Re: [netmod] Yang mount / ysdl example use case

[Acee Lindem (acee)]

Kent - I’m assuming the poll is EST given that is where you are located.
Thanks,
Acee

On 2/3/16, 8:50 AM, "Kent Watsen"  wrote:

>
>No problem, I just created another poll for the following week:
>
>   http://doodle.com/poll/byugp4umy2m4fwdz
>
>The first poll is now deleted.  For the couple of folks that put values
>there, please fill in your values again on this new poll.
>
>Kent
>
>
>
>
>
>On 2/3/16, 6:59 AM, "Acee Lindem (acee)"  wrote:
>
>>
>>
>>On 2/3/16, 1:18 AM, "Ladislav Lhotka"  wrote:
>>
>>>
>>>> On 03 Feb 2016, at 03:24, Kent Watsen  wrote:
>>>> 
>>>> 
>>>> [Chair hat on]
>>>> 
>>>> Given the number of competing/complementing drafts involved, and the
>>>>general lack of discussion on any of them, a virtual interim meeting
>>>>might be an expedient way to proceed.  In fairness, we know that there
>>>>has been some discussion, but it hasn’t been picked up yet in a big
>>>>way,
>>>>and now Lou has an updated draft.
>>>> 
>>>> The chairs discussed maybe scheduling one for a couple weeks from now,
>>>>perhaps Thursday Feb 18 starting at 10am EST?   I'm thinking
>>>
>>>Thursday at this time doesn't suit me very well, Monday till Wednesday
>>>of
>>>that week are OK.
>>
>>I’m out the entire week of Feb 14th.
>>
>>Thanks,
>>Acee 
>>
>>
>>>
>>>Lada
>>>
>>>>  about this slot only since it worked for us for previously.  Is this
>>>>a
>>>>good time slot?  I assume to schedule for 2 hours, with a plan to end
>>>>early if needed - makes sense? We also need to put together a
>>>>proper
>>>>agenda, perhaps the following?
>>>> 
>>>>  10 min: RTG DT YANG Arch team use-case summary
>>>>  20 min: draft-rtgyangdt-rtgwg-device-model
>>>>  20 min: draft-lhotka-netmod-ysdl
>>>>  20 min: draft-bjorklund-netmod-structural-mount
>>>>  50 min: general discussion or end early
>>>> 
>>>> 
>>>> We hope to schedule the meeting itself tomorrow or the next day, so
>>>>please respond quickly to this email if possible.
>>>> 
>>>> Thanks,
>>>> Kent and Tom
>>>> 
>>>> 
>>>> 
>>>> 
>>>> On 2/2/16, 2:04 PM, "netmod on behalf of Lou Berger"
>>>> wrote:
>>>> 
>>>>> 
>>>>> I thought it would be worth summarizing what we're looking for in our
>>>>> draft, draft-rtgyangdt-rtgwg-device-model-02 (note new version in
>>>>>case
>>>>> you missed it) with respect to the draft-lhotka-netmod-ysdl and
>>>>> draft-bjorklund-netmod-structural-mount drafts. This is just my view,
>>>>>so
>>>>> my co-authors may wish to chime in and correct me.
>>>>> 
>>>>> I'd be interested in hearing from the authors of YSDL and
>>>>> structural-mount, or anyone else for that matter, on how they see to
>>>>> best meet these needs.
>>>>> 
>>>>> Here's what I think our draft needs:
>>>>> 
>>>>> 1. that there be a mechanism that allows the incorporation (or
>>>>>  'mounting') of the data model defined by one top-level module
>>>>>  within another module.
>>>>> 
>>>>>  The implication here is that when information is instantiated
>>>>>  for the parent model it is also instantiated for the
>>>>>  incorporated/mounted model. In our case we expect to do this on
>>>>>  list element creation. Both solutions drafts cover the path
>>>>>  implications, so these are not repeated here.
>>>>> 
>>>>> 2. that this mechanism allow identification of specific modules to
>>>>>  be incorporated/mounted at time of module definition, i.e. that
>>>>>  no additional module is needed to support 1. This doesn't
>>>>>  preclude definition of such a module.
>>>>> 
>>>>> 3. that this mechanism allow for a server to control (and
>>>>>  identify) which modules are incorporated/mounted. (see Section
>>>>>  3 LNE in our draft for an envisioned usage.)
>>>>> 
>>>>> 4. that all capabilities that exist with the mounted module are
>>>>&g

Re: [netmod] Consistency in YANG for Router IDs [Was: WG Chair comments on draft-raza-mpls-ldp-mldp-yang-02]

[Acee Lindem (acee)]

Hi Benoit, Lada, 

On 2/26/16, 3:32 AM, "netmod on behalf of Benoit Claise (bclaise)"
 wrote:

>Hi Lada,
>
>> Hi Benoit,
>>
>> this was discussed a while ago in this thread:
>>
>> https://mailarchive.ietf.org/arch/msg/netmod/TehrMAboX-cMmmX537rs81DNl3I
>>
>> tl;dr: The WG decision then was to introduce a new type in
>>ietf-inet-types, namely "dotted-quad", that explicitly does NOT have the
>>semantics of an IPv4 address - it is an uint32 number that's expressed
>>in the dotted quad format, which is what most router platforms accept as
>>routerID via CLI.
>
> From what I understand below, this is not an acceptable solution.
>I'm sure the routing experts will confirm this.

At least for the OSPF Router ID (RFC 2328) and the BGP Identifier (RFC
4271), the dotted-quad type matches the semantics of the protocols. The
value is not necessarily a routable address and solely a unique 32-bit
identifier within the protocol routing domain that is commonly expressed
in dotted quad format. What is the problem with using this YANG type?

Thanks,
Acee

>
>Regards, Benoit
>>
>> Lada
>>
>>> On 25 Feb 2016, at 13:41, Benoit Claise  wrote:
>>>
>>> Dear all,
>>>
>>> Sorry for the delay (mix of vacation and business travel).
>>>
>>> Let me try to summarize the situation as I see it:
>>> - From the routing RFCs, BGP Identifier, OSPF router ID, TE
>>>identifier, and LSR identifiers are all an unsigned integers.
>>> - We need consistency for the router ID and identifier in YANG
>>>leaf/typedef
>>> - The OSPF MIB module has defined
>>> RouterID ::= TEXTUAL-CONVENTION
>>> STATUS   current
>>> DESCRIPTION
>>>"A OSPF Router Identifier.
>>> Note that the Router ID, in OSPF, has the same format
>>> as an IP address, but identifies the router independent
>>> of its IP address."
>>> SYNTAX   IpAddress
>>>
>>>
>>>ospfRouterId OBJECT-TYPE
>>> SYNTAX   RouterID
>>> MAX-ACCESS   read-write
>>> STATUS   current
>>> DESCRIPTION
>>>"A 32-bit integer uniquely identifying the
>>>router in the Autonomous System.
>>>By convention, to ensure uniqueness, this
>>>should default to the value of one of the
>>>router's IP interface addresses.
>>>
>>> As Adrian mentioned: it is NOT an IP address but the MIB module uses
>>>the notational formatting of n IP address for display purposes.
>>> - An IPv4 address as OSPF router ID doesn't make sense in an IPv6
>>>environment
>>>
>>> Based on this, I believe that:
>>> - We must not associate an IP address semantic with the router ID
>>> - Based on Brian's feedback (which I agree with) "As long as the YANG
>>>module does not specify a format that makes the routerID display like
>>>an IPv4 address", it was probably a mistake to have defined RouterID as
>>>IpAdress in OSPF MIB module.
>>> - Interestingly,
>>>https://tools.ietf.org/html/draft-ietf-netmod-routing-cfg-20 contains:
>>>
>>>   grouping router-id {
>>> description
>>>   "This grouping provides router ID.";
>>> leaf router-id {
>>>   type yang:dotted-quad;
>>>   description
>>> "A 32-bit number in the form of a dotted quad that is used
>>>by
>>>  some routing protocols identifying a router.";
>>>   reference
>>> "
>>> RFC 2328
>>> : OSPF Version 2.";
>>> }
>>>   }
>>>
>>> This should be an uint32 number.
>>> - An union-based solution is a bad compromise
>>>  From draft-raza-mpls-ldp-mldp-yang-02
>>>   leaf lsr-id {
>>> type union {
>>>   type yang:dotted-quad;
>>>   type uint32;
>>> }
>>> description "LSR ID.";
>>>
>>>
>>>
>>> Since the question was asked: as AD, I would support uint32 everywhere.
>>>
>>> Now, practically, how to move forward?
>>> - Either all drafts reference draft-ietf-netmod-routing-cfg-20 (with
>>>the uint32 modification),
>>> - Or you create a "Common Routing YANG Data Types", similarly to RFC
>>>6991 including the router IDs. I see already many typedef in
>>>draft-raza-mpls-ldp-mldp-yang-02
>>> - Or you define you own types in your own draft
>>>
>>> But, if we have agreement on the uint32, let's document this now
>>>somewhere/somehow, and let's not revisit this on regular basis (yes, I
>>>see it coming...)
>>> A few lines of explanation in the draft would already help for
>>>example, in an operational section, explaining to people the mapping of
>>>the MIB OSPF RouterID to the YANG object
>>>
>>> Regards, Benoit
 Hi Adrian,

 On 2/16/16 7:53 AM, Adrian Farrel wrote:

> Hi Brian,
>
> I said I wasn't going to participate in this discussion :-)
>
 Nice try. ;)


>>> I should not respond to questions that I don't fully understand,
>>>but:
>>>
>>> the BGP Identifier is an unsigned integer
>>> the OSPF router 

Re: [netmod] Consistency in YANG for Router IDs [Was: WG Chair comments on draft-raza-mpls-ldp-mldp-yang-02]

[Acee Lindem (acee)]

On 3/2/16, 4:45 AM, "Benoit Claise (bclaise)"  wrote:

>On 2/26/2016 1:13 PM, Acee Lindem (acee) wrote:
>> Hi Benoit, Lada,
>>
>> On 2/26/16, 3:32 AM, "netmod on behalf of Benoit Claise (bclaise)"
>>  wrote:
>>
>>> Hi Lada,
>>>
>>>> Hi Benoit,
>>>>
>>>> this was discussed a while ago in this thread:
>>>>
>>>> 
>>>>https://mailarchive.ietf.org/arch/msg/netmod/TehrMAboX-cMmmX537rs81DNl3
>>>>I
>>>>
>>>> tl;dr: The WG decision then was to introduce a new type in
>>>> ietf-inet-types, namely "dotted-quad", that explicitly does NOT have
>>>>the
>>>> semantics of an IPv4 address - it is an uint32 number that's expressed
>>>> in the dotted quad format, which is what most router platforms accept
>>>>as
>>>> routerID via CLI.
>>>  From what I understand below, this is not an acceptable solution.
>>> I'm sure the routing experts will confirm this.
>> At least for the OSPF Router ID (RFC 2328) and the BGP Identifier (RFC
>> 4271), the dotted-quad type matches the semantics of the protocols. The
>> value is not necessarily a routable address and solely a unique 32-bit
>> identifier within the protocol routing domain that is commonly expressed
>> in dotted quad format. What is the problem with using this YANG type?
>uint32 sure, but what is the conclusion regarding dotted-quad?
>On one side, I hear: dotted-quad is suitable because it's uint32 and
>does NOT have the semantics of an IPv4 address.
>On the other side, I hear: we should not even display the identifier as
>an IPv4 address.
>
>The routing experts should tell us if the dotted-quad type is appropriate.


We have been displaying these unique identifiers (Router IDs) in dotted
quad format in 
OAM systems since the early 90s, so why shouldn’t we continue? The
description should 
specify whether that it is simply a unique address and, not necessarily, a
routable IP
address. 

Thanks,
Acee





>
>Regards, Benoit
>>
>> Thanks,
>> Acee
>>
>>> Regards, Benoit
>>>> Lada
>>>>
>>>>> On 25 Feb 2016, at 13:41, Benoit Claise  wrote:
>>>>>
>>>>> Dear all,
>>>>>
>>>>> Sorry for the delay (mix of vacation and business travel).
>>>>>
>>>>> Let me try to summarize the situation as I see it:
>>>>> - From the routing RFCs, BGP Identifier, OSPF router ID, TE
>>>>> identifier, and LSR identifiers are all an unsigned integers.
>>>>> - We need consistency for the router ID and identifier in YANG
>>>>> leaf/typedef
>>>>> - The OSPF MIB module has defined
>>>>> RouterID ::= TEXTUAL-CONVENTION
>>>>>  STATUS   current
>>>>>  DESCRIPTION
>>>>> "A OSPF Router Identifier.
>>>>>  Note that the Router ID, in OSPF, has the same format
>>>>>  as an IP address, but identifies the router independent
>>>>>  of its IP address."
>>>>>  SYNTAX   IpAddress
>>>>>
>>>>>
>>>>> ospfRouterId OBJECT-TYPE
>>>>>  SYNTAX   RouterID
>>>>>  MAX-ACCESS   read-write
>>>>>  STATUS   current
>>>>>  DESCRIPTION
>>>>> "A 32-bit integer uniquely identifying the
>>>>> router in the Autonomous System.
>>>>> By convention, to ensure uniqueness, this
>>>>> should default to the value of one of the
>>>>> router's IP interface addresses.
>>>>>
>>>>> As Adrian mentioned: it is NOT an IP address but the MIB module uses
>>>>> the notational formatting of n IP address for display purposes.
>>>>> - An IPv4 address as OSPF router ID doesn't make sense in an IPv6
>>>>> environment
>>>>>
>>>>> Based on this, I believe that:
>>>>> - We must not associate an IP address semantic with the router ID
>>>>> - Based on Brian's feedback (which I agree with) "As long as the YANG
>>>>> module does not specify a format that makes the routerID display like
>>>>> an IPv4 address", it was probably a mistake to have defined RouterID
>>>>>as
>>>>> IpAdress in OSPF M

Re: [netmod] proposed change to ietf-routing

[Acee Lindem (acee)]

Hi Lada, NETMOD WG members,

There are actually a number of changes that we would like to
see in the ietf-routing model:

- Remove routing-instances since ietf-routing since it will be
  “mounted” at different points in the device hierarchy dependent
  on the device requirements.

- Collapse it into one module supporting different address families
  rather 3 modules (base, IPv4, and IPv6).

- Remove the ND (RFC 4861) Router Advertisement protocol since it
  doesn’t need to be here.

- Support at least the next hop enhancements in
  https://tools.ietf.org/html/draft-acee-rtgwg-yang-rib-extend-00

- Include at least ECMP in the static route configuration.

- Structure consistent with the operational state recommendation.
  Even w/o having the final recommendation, this model seems to
  branch between config and state at way too high a level.

Thanks,
Acee


On 2/26/16, 8:36 AM, "netmod on behalf of Ladislav Lhotka"
 wrote:

>Hi,
>
>as a part of synchronization of the routing data models that are being
>developed by the NETMOD and RTG working groups, the authors of
>draft-ietf-netmod-routing-cfg propose to remove the routing-instance
>level in the data hierarchy, and leave it to structural-mount/YSDL to
>provide a top level structure.
>
>Schematically, the configuration and state data subtrees of ietf-routing
>would be reduced to something like this:
>
>module: ietf-routing
>   +--ro routing-state
>   |  +--ro router-id?   yang:dotted-quad
>   |  +--ro interfaces
>   |  |  +--ro interface*   if:interface-state-ref
>   |  +--ro routing-protocols
>   |  |  +--ro routing-protocol* [type name]
>   |  | ...
>   |  +--ro ribs
>   | +--ro rib* [name]
>   |...
>   +--rw routing
>  +--rw router-id?   yang:dotted-quad
>  +--rw description? string
>  +--rw routing-protocols
>  |  +--rw routing-protocol* [type name]
>  | ...
>  +--rw ribs
> +--rw rib* [name]
>   ...
>
>Are there any objections to this change?
>
>Thanks,
>
>Acee and Lada
> 
>--
>Ladislav Lhotka, CZ.NIC Labs
>PGP Key ID: E74E8C0C
>
>
>
>
>___
>netmod mailing list
>netmod@ietf.org
>https://www.ietf.org/mailman/listinfo/netmod

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

Re: [netmod] proposed change to ietf-routing

[Acee Lindem (acee)]

Hi Lada, 

On 3/3/16, 8:01 AM, "Ladislav Lhotka"  wrote:

>"Acee Lindem (acee)"  writes:
>
>> Hi Lada, NETMOD WG members,
>>
>> There are actually a number of changes that we would like to
>> see in the ietf-routing model:
>>
>> - Remove routing-instances since ietf-routing since it will be
>>   “mounted” at different points in the device hierarchy dependent
>>   on the device requirements.
>
>Agreed.
>
>>
>> - Collapse it into one module supporting different address families
>>   rather 3 modules (base, IPv4, and IPv6).
>
>This is possible, but we would have to introduce a mechanism for
>implementations supporting only one of them. It seems to me that it is
>easier to select modules for base + any combination of address families,
>and each family module inserts appropriate stuff to right places - and
>there is quite a bunch of them. What you are proposing probably means the
>(single) module would have if-features or whens in all those places.

Are there planned implementations required YANG models where only IPv4 or
IPv6 are supported? Maybe way off in the future, when you and I are both
sitting on a beach drinking beer there will be IPv6 only products but I
don’t see it happening soon.



>
>>
>> - Remove the ND (RFC 4861) Router Advertisement protocol since it
>>   doesn’t need to be here.
>
>Well, RFC 4861 says: "A router MUST allow for the following conceptual
>variables to be configured by system management."
>
>So I don't think they can be considered optional. We could perhaps move
>them to a submodule so that they don't clutter the main module.

I don’t disagree - but why are they grouped with the main RIB and infra
draft? Router Advertisement should be with the other RFC 4861 protocols.
It is out of place here.



>
>>
>> - Support at least the next hop enhancements in
>>   https://tools.ietf.org/html/draft-acee-rtgwg-yang-rib-extend-00
>
>They can be added via augments, and many potential users of the routing
>module (hosts and simple routers) don't support them.

Are there hosts that don’t support at least ECMP?

>
>>
>> - Include at least ECMP in the static route configuration.
>
>Same as in the previous case: ietf-routing provides a choice node for
>next-hops in both RIBs and static routes, and ECMP is explicitly
>mentioned as a candidate for augmentation. Why is it such a big a
>problem?

It is not but as long as we are changing the model, we might as well
handle the predominant use cases.


>
>>
>> - Structure consistent with the operational state recommendation.
>>   Even w/o having the final recommendation, this model seems to
>>   branch between config and state at way too high a level.
>
>Could you outline the concrete changes that you propose here? The most
>significant part of state data in this module is the list of RIBs, and I
>don't see any way how it can be bundled with configuration somewhere
>deeper in the hierarchy.

I guess we will discuss this in upstate call next week. However, no matter
what solution we come up with, it seems keeping the derived state closer
to intended/applied config is better.

Thanks, 
Acee 


>
>Lada
>
>>
>> Thanks,
>> Acee
>>
>>
>> On 2/26/16, 8:36 AM, "netmod on behalf of Ladislav Lhotka"
>>  wrote:
>>
>>>Hi,
>>>
>>>as a part of synchronization of the routing data models that are being
>>>developed by the NETMOD and RTG working groups, the authors of
>>>draft-ietf-netmod-routing-cfg propose to remove the routing-instance
>>>level in the data hierarchy, and leave it to structural-mount/YSDL to
>>>provide a top level structure.
>>>
>>>Schematically, the configuration and state data subtrees of ietf-routing
>>>would be reduced to something like this:
>>>
>>>module: ietf-routing
>>>   +--ro routing-state
>>>   |  +--ro router-id?   yang:dotted-quad
>>>   |  +--ro interfaces
>>>   |  |  +--ro interface*   if:interface-state-ref
>>>   |  +--ro routing-protocols
>>>   |  |  +--ro routing-protocol* [type name]
>>>   |  | ...
>>>   |  +--ro ribs
>>>   | +--ro rib* [name]
>>>   |...
>>>   +--rw routing
>>>  +--rw router-id?   yang:dotted-quad
>>>  +--rw description? string
>>>  +--rw routing-protocols
>>>  |  +--rw routing-protocol* [type name]
>>>  | ...
>>>  +--rw ribs
>>> +--rw rib* [name]
>>> ...
>>>
>>>Are there any objections to this change?
>>>
>>>Thanks,
>>>
>>>Acee and Lada
>>> 
>>>--
>>>Ladislav Lhotka, CZ.NIC Labs
>>>PGP Key ID: E74E8C0C
>>>
>>>
>>>
>>>
>>>___
>>>netmod mailing list
>>>netmod@ietf.org
>>>https://www.ietf.org/mailman/listinfo/netmod
>>
>
>-- 
>Ladislav Lhotka, CZ.NIC Labs
>PGP Key ID: E74E8C0C

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

Re: [netmod] proposed change to ietf-routing

[Acee Lindem (acee)]

Hi Lada, 

On 3/4/16, 8:00 AM, "Ladislav Lhotka"  wrote:

>"Acee Lindem (acee)"  writes:
>
>> Hi Lada, 
>>
>> On 3/3/16, 8:01 AM, "Ladislav Lhotka"  wrote:
>>
>>>"Acee Lindem (acee)"  writes:
>>>
>>>> Hi Lada, NETMOD WG members,
>>>>
>>>> There are actually a number of changes that we would like to
>>>> see in the ietf-routing model:
>>>>
>>>> - Remove routing-instances since ietf-routing since it will be
>>>>   “mounted” at different points in the device hierarchy dependent
>>>>   on the device requirements.
>>>
>>>Agreed.
>>>
>>>>
>>>> - Collapse it into one module supporting different address families
>>>>   rather 3 modules (base, IPv4, and IPv6).
>>>
>>>This is possible, but we would have to introduce a mechanism for
>>>implementations supporting only one of them. It seems to me that it is
>>>easier to select modules for base + any combination of address families,
>>>and each family module inserts appropriate stuff to right places - and
>>>there is quite a bunch of them. What you are proposing probably means
>>>the
>>>(single) module would have if-features or whens in all those places.
>>
>> Are there planned implementations required YANG models where only IPv4
>>or
>> IPv6 are supported? Maybe way off in the future, when you and I are both
>> sitting on a beach drinking beer there will be IPv6 only products but I
>> don’t see it happening soon.
>>
>
>Maybe some experts in the embedded area could comment on this, but I
>believe in both 6LoWPAN and ZigBee IPv6-only networks are commonplace.

Okay - I’ve also heard requirements from an SP for access devices with
only IPv6. However, is a separate module required for this?
ietf-yang-types has the type ip-address supporting both AFs. Does
supporting one or the other AF or both need to be enforced with separate
modules? For IPv4, we are going to need to support IPv6 next-hops (refer
to RFC 5549).  


>
>>
>>
>>>
>>>>
>>>> - Remove the ND (RFC 4861) Router Advertisement protocol since it
>>>>   doesn’t need to be here.
>>>
>>>Well, RFC 4861 says: "A router MUST allow for the following conceptual
>>>variables to be configured by system management."
>>>
>>>So I don't think they can be considered optional. We could perhaps move
>>>them to a submodule so that they don't clutter the main module.
>>
>> I don’t disagree - but why are they grouped with the main RIB and infra
>> draft? Router Advertisement should be with the other RFC 4861 protocols.
>> It is out of place here.
>
>The idea is that any device that implements ietf-routing is required to
>support these configuration variables, which is what 4861 says.

But it says nothing about the organization of the YANG modules ;^)

> With a
>mechanism like Andy's packages we would have more flexibility, but for
>the time being the best solution seems to be to move RA stuff to a
>submodule.

Why wouldn’t RA be in a separate draft with all the other RFC 4861
protocols? 



>
>>
>>
>>
>>>
>>>>
>>>> - Support at least the next hop enhancements in
>>>>   https://tools.ietf.org/html/draft-acee-rtgwg-yang-rib-extend-00
>>>
>>>They can be added via augments, and many potential users of the routing
>>>module (hosts and simple routers) don't support them.
>>
>> Are there hosts that don’t support at least ECMP?
>
>I am not sure. If there is consensus that ECMP is really ubiquitous,
>then we can add it.
>
>>
>>>
>>>>
>>>> - Include at least ECMP in the static route configuration.
>>>
>>>Same as in the previous case: ietf-routing provides a choice node for
>>>next-hops in both RIBs and static routes, and ECMP is explicitly
>>>mentioned as a candidate for augmentation. Why is it such a big a
>>>problem?
>>
>> It is not but as long as we are changing the model, we might as well
>> handle the predominant use cases.
>
>My concern is that other groups may come up with their favourite
>cases. Any new stuff increases the likelihood that bugs or inadequacies
>will be discovered in the module after it is published, but then it will
>be a problem due to the draconian module update rules. So I'd prefer to
>keep this module really skinny.
>
>>
>>
>>>
>>>>
>>>> - Structure consistent with the operationa

Re: [netmod] proposed change to ietf-routing

[Acee Lindem (acee)]

Hi Lada, 

On 3/7/16, 8:45 AM, "Ladislav Lhotka"  wrote:

>"Acee Lindem (acee)"  writes:
>
>> Hi Lada, 
>>
>> On 3/4/16, 8:00 AM, "Ladislav Lhotka"  wrote:
>>
>>>"Acee Lindem (acee)"  writes:
>>>
>>>> Hi Lada, 
>>>>
>>>> On 3/3/16, 8:01 AM, "Ladislav Lhotka"  wrote:
>>>>
>>>>>"Acee Lindem (acee)"  writes:
>>>>>
>>>>>> Hi Lada, NETMOD WG members,
>>>>>>
>>>>>> There are actually a number of changes that we would like to
>>>>>> see in the ietf-routing model:
>>>>>>
>>>>>> - Remove routing-instances since ietf-routing since it will be
>>>>>>   “mounted” at different points in the device hierarchy dependent
>>>>>>   on the device requirements.
>>>>>
>>>>>Agreed.
>>>>>
>>>>>>
>>>>>> - Collapse it into one module supporting different address families
>>>>>>   rather 3 modules (base, IPv4, and IPv6).
>>>>>
>>>>>This is possible, but we would have to introduce a mechanism for
>>>>>implementations supporting only one of them. It seems to me that it is
>>>>>easier to select modules for base + any combination of address
>>>>>families,
>>>>>and each family module inserts appropriate stuff to right places - and
>>>>>there is quite a bunch of them. What you are proposing probably means
>>>>>the
>>>>>(single) module would have if-features or whens in all those places.
>>>>
>>>> Are there planned implementations required YANG models where only IPv4
>>>>or
>>>> IPv6 are supported? Maybe way off in the future, when you and I are
>>>>both
>>>> sitting on a beach drinking beer there will be IPv6 only products but
>>>>I
>>>> don’t see it happening soon.
>>>>
>>>
>>>Maybe some experts in the embedded area could comment on this, but I
>>>believe in both 6LoWPAN and ZigBee IPv6-only networks are commonplace.
>>
>> Okay - I’ve also heard requirements from an SP for access devices with
>> only IPv6. However, is a separate module required for this?
>
>An IPv6-only system should not have IPv4-related nodes in the schema. As
>I wrote, alternatives are
>
>(a) define features for individual address families
>(b) include configuration of address families, and then use "when"
>statements to control the schema.

We have the ip-address type that supports both… Couldn’t we use this type
and have the server simply return an error if a route is configured for an
unsupported address family? Should the ietf-yang-types module be
re-published with ip-address removed?

I guess don’t see this as a major point.


>
>We also have to consider other families that may be added, even some
>that don't exist yet.


Agreed. These can be added through augmentation.

>
>> ietf-yang-types has the type ip-address supporting both AFs. Does
>> supporting one or the other AF or both need to be enforced with separate
>> modules? For IPv4, we are going to need to support IPv6 next-hops (refer
>> to RFC 5549).  
>>
>>
>>>
>>>>
>>>>
>>>>>
>>>>>>
>>>>>> - Remove the ND (RFC 4861) Router Advertisement protocol since it
>>>>>>   doesn’t need to be here.
>>>>>
>>>>>Well, RFC 4861 says: "A router MUST allow for the following conceptual
>>>>>variables to be configured by system management."
>>>>>
>>>>>So I don't think they can be considered optional. We could perhaps
>>>>>move
>>>>>them to a submodule so that they don't clutter the main module.
>>>>
>>>> I don’t disagree - but why are they grouped with the main RIB and
>>>>infra
>>>> draft? Router Advertisement should be with the other RFC 4861
>>>>protocols.
>>>> It is out of place here.
>>>
>>>The idea is that any device that implements ietf-routing is required to
>>>support these configuration variables, which is what 4861 says.
>>
>> But it says nothing about the organization of the YANG modules ;^)
>
>No, but currently there is no way to say that if module X is implemented,
>then
>module Y has to be implemented, too.
>
>>
>>> With a
>>>mechanism like Andy's

Re: [netmod] proposed change to ietf-routing

[Acee Lindem (acee)]

> On Mar 7, 2016, at 7:54 PM, Acee Lindem (acee)  wrote:
> 
> Hi Lada, 
> 
> On 3/7/16, 8:45 AM, "Ladislav Lhotka"  wrote:
> 
>> "Acee Lindem (acee)"  writes:
>> 
>>> Hi Lada, 
>>> 
>>> On 3/4/16, 8:00 AM, "Ladislav Lhotka"  wrote:
>>> 
>>>> "Acee Lindem (acee)"  writes:
>>>> 
>>>>> Hi Lada, 
>>>>> 
>>>>> On 3/3/16, 8:01 AM, "Ladislav Lhotka"  wrote:
>>>>> 
>>>>>> "Acee Lindem (acee)"  writes:
>>>>>> 
>>>>>>> Hi Lada, NETMOD WG members,
>>>>>>> 
>>>>>>> There are actually a number of changes that we would like to
>>>>>>> see in the ietf-routing model:
>>>>>>> 
>>>>>>> - Remove routing-instances since ietf-routing since it will be
>>>>>>>  “mounted” at different points in the device hierarchy dependent
>>>>>>>  on the device requirements.
>>>>>> 
>>>>>> Agreed.
>>>>>> 
>>>>>>> 
>>>>>>> - Collapse it into one module supporting different address families
>>>>>>>  rather 3 modules (base, IPv4, and IPv6).
>>>>>> 
>>>>>> This is possible, but we would have to introduce a mechanism for
>>>>>> implementations supporting only one of them. It seems to me that it is
>>>>>> easier to select modules for base + any combination of address
>>>>>> families,
>>>>>> and each family module inserts appropriate stuff to right places - and
>>>>>> there is quite a bunch of them. What you are proposing probably means
>>>>>> the
>>>>>> (single) module would have if-features or whens in all those places.
>>>>> 
>>>>> Are there planned implementations required YANG models where only IPv4
>>>>> or
>>>>> IPv6 are supported? Maybe way off in the future, when you and I are
>>>>> both
>>>>> sitting on a beach drinking beer there will be IPv6 only products but
>>>>> I
>>>>> don’t see it happening soon.
>>>>> 
>>>> 
>>>> Maybe some experts in the embedded area could comment on this, but I
>>>> believe in both 6LoWPAN and ZigBee IPv6-only networks are commonplace.
>>> 
>>> Okay - I’ve also heard requirements from an SP for access devices with
>>> only IPv6. However, is a separate module required for this?
>> 
>> An IPv6-only system should not have IPv4-related nodes in the schema. As
>> I wrote, alternatives are
>> 
>> (a) define features for individual address families
>> (b) include configuration of address families, and then use "when"
>> statements to control the schema.
> 
> We have the ip-address type that supports both… Couldn’t we use this type
> and have the server simply return an error if a route is configured for an
> unsupported address family? Should the ietf-yang-types module be
> re-published with ip-address removed?
> 
> I guess don’t see this as a major point.

The thing about the static route definition for IPv4 and IPv6 is that their 
RIBs will have pretty much the same structure other than differences in address 
type. For other AFs, there may be other differences as well. For every 
augmentation, we’re essentially doubling the specification effort. 

Thanks,
Acee




> 
> 
>> 
>> We also have to consider other families that may be added, even some
>> that don't exist yet.
> 
> 
> Agreed. These can be added through augmentation.
> 
>> 
>>> ietf-yang-types has the type ip-address supporting both AFs. Does
>>> supporting one or the other AF or both need to be enforced with separate
>>> modules? For IPv4, we are going to need to support IPv6 next-hops (refer
>>> to RFC 5549).  
>>> 
>>> 
>>>> 
>>>>> 
>>>>> 
>>>>>> 
>>>>>>> 
>>>>>>> - Remove the ND (RFC 4861) Router Advertisement protocol since it
>>>>>>>  doesn’t need to be here.
>>>>>> 
>>>>>> Well, RFC 4861 says: "A router MUST allow for the following conceptual
>>>>>> variables to be configured by system management."
>>>>>> 
>>>>>> 

Re: [netmod] proposed change to ietf-routing

[Acee Lindem (acee)]

On 3/8/16, 1:47 AM, "j.schoenwael...@jacobs-university.de"
 wrote:

>On Tue, Mar 08, 2016 at 01:23:50AM +, Acee Lindem (acee) wrote:
>> 
>> The thing about the static route definition for IPv4 and IPv6 is that
>>their RIBs will have pretty much the same structure other than
>>differences in address type. For other AFs, there may be other
>>differences as well. For every augmentation, we’re essentially doubling
>>the specification effort.
>>
>
>One benefit of having separate augmentations is that the data types
>are tighter. For example, the data model does not allow an IPv6 next
>hop for an IPv4 prefix, i.e., you can't mess up address families since
>the data model forces a clear separation (and generic validation will
>catch that in contrast to having the runtime catching inconsistent
>address family data).

Actually this is supported on the data center product that I work on (see
RFC 5549). However, I agree mixing AFs will not be the norm.


>
>How much that matters likely can be debated. But somehow it feels like
>keeping things separate allows for independent evolution, which may
>proof to be very handy in the future. I kind of liked Lada's approach
>to maintain the architectural separation in the data model.
>
>/js
>
>-- 
>Juergen Schoenwaelder   Jacobs University Bremen gGmbH
>Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
>Fax:   +49 421 200 3103 <http://www.jacobs-university.de/>

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

Re: [netmod] proposed change to ietf-routing

[Acee Lindem (acee)]

On 3/8/16, 1:55 AM, "Martin Bjorklund"  wrote:

>Juergen Schoenwaelder  wrote:
>> On Tue, Mar 08, 2016 at 01:23:50AM +, Acee Lindem (acee) wrote:
>> > 
>> > The thing about the static route definition for IPv4 and IPv6 is that
>>their RIBs will have pretty much the same structure other than
>>differences in address type. For other AFs, there may be other
>>differences as well. For every augmentation, we’re essentially doubling
>>the specification effort.
>> >
>> 
>> One benefit of having separate augmentations is that the data types
>> are tighter. For example, the data model does not allow an IPv6 next
>> hop for an IPv4 prefix, i.e., you can't mess up address families since
>> the data model forces a clear separation (and generic validation will
>> catch that in contrast to having the runtime catching inconsistent
>> address family data).
>> 
>> How much that matters likely can be debated. But somehow it feels like
>> keeping things separate allows for independent evolution, which may
>> proof to be very handy in the future. I kind of liked Lada's approach
>> to maintain the architectural separation in the data model.
>
>I agree.  I think the model is more clear this way.  I guess I don't
>understand why Acee wants to have a single module?

I was trying to eliminate the effort of updating both modules with the
exact same augmentations. However, I guess I’m ready to relent on this
point. 

Thanks,
Acee 



>
>
>/martin

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

Re: [netmod] proposed change to ietf-routing

[Acee Lindem (acee)]

On 3/8/16, 6:35 AM, "Ladislav Lhotka"  wrote:

>
>> On 08 Mar 2016, at 12:08, Acee Lindem (acee)  wrote:
>> 
>> 
>> 
>> On 3/8/16, 1:55 AM, "Martin Bjorklund"  wrote:
>> 
>>> Juergen Schoenwaelder  wrote:
>>>> On Tue, Mar 08, 2016 at 01:23:50AM +, Acee Lindem (acee) wrote:
>>>>> 
>>>>> The thing about the static route definition for IPv4 and IPv6 is that
>>>> their RIBs will have pretty much the same structure other than
>>>> differences in address type. For other AFs, there may be other
>>>> differences as well. For every augmentation, we’re essentially
>>>>doubling
>>>> the specification effort.
>>>>> 
>>>> 
>>>> One benefit of having separate augmentations is that the data types
>>>> are tighter. For example, the data model does not allow an IPv6 next
>>>> hop for an IPv4 prefix, i.e., you can't mess up address families since
>>>> the data model forces a clear separation (and generic validation will
>>>> catch that in contrast to having the runtime catching inconsistent
>>>> address family data).
>>>> 
>>>> How much that matters likely can be debated. But somehow it feels like
>>>> keeping things separate allows for independent evolution, which may
>>>> proof to be very handy in the future. I kind of liked Lada's approach
>>>> to maintain the architectural separation in the data model.
>>> 
>>> I agree.  I think the model is more clear this way.  I guess I don't
>>> understand why Acee wants to have a single module?
>> 
>> I was trying to eliminate the effort of updating both modules with the
>> exact same augmentations. However, I guess I’m ready to relent on this
>> point.
>
>OK, thanks. Do we want to post another revision before IETF 95? If so, we
>should probably do most preparations this week because I will be on
>vacation next week.

I think we should at least try and get the structural changes posted
before IETF 95. We can meet on next hops at IETF 95.

Thanks,
Acee



>
>Lada
>
>>  
>> 
>> Thanks,
>> Acee 
>> 
>> 
>> 
>>> 
>>> 
>>> /martin
>> 
>> ___
>> netmod mailing list
>> netmod@ietf.org
>> https://www.ietf.org/mailman/listinfo/netmod
>
>--
>Ladislav Lhotka, CZ.NIC Labs
>PGP Key ID: E74E8C0C
>
>
>
>

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

Re: [netmod] Fwd: Re: [Rtg-dt-yang-arch] I-D Action: draft-rtgyangdt-rtgwg-device-model-03.txt

[Acee Lindem (acee)]

Hey Tom, 

On 3/10/16, 7:25 AM, "netmod on behalf of t.petch"
 wrote:

>- Original Message -
>From: "Juergen Schoenwaelder" 
>To: "Benoit Claise" 
>Cc: ; "NETMOD Working Group"
>
>Sent: Friday, March 04, 2016 10:33 AM
>Subject: Re: [netmod] Fwd: Re: [Rtg-dt-yang-arch] I-D Action:
>draft-rtgyangdt-rtgwg-device-model-03.txt
>
>
>> Is the rtgyangdt chartered to define a structure that potentially
>> affects all YANG models produced in the IETF?
>
>Even if it were so chartered, I question the competence of it to do so.
>The vast majority of managed devices in the world are not network
>devices (for any widely used management architecture).  One of the
>weaknesses of SNMP is that it started life as routing only, and had all
>the other managed devices added later so the structure has never been
>quite right for the common case (unless you are only concerned with the
>routing area).
>
>This I-D does make it clear how limited it is
>"we consider network devices that support protocols
>   and functions defined within the IETF Routing Area"
>so it is clearly excluding most managed devices.
>
>It is understandable, if unfortunate, that SNMP suffers from having
>started out with a limited remit.  It would be unforgiveable to build
>that limitation into YANG.

One of the primary YANG Routing Design Team work items is to advance
mechanisms (structural mount or YSDL) to allow placement of IETF YANG
modules at different levels of the device hierarchy dependent on the
requirements of that device.  I think this is consistent with making YANG
and, even the IETF data models, reusable for any class of the device.
However, the device targeted in the device model draft is, in fact, a
carrier class networking device. I believe it would be foolish to try and
define a “one size fits all” device model.

Thanks,
Acee


>
>Tom Petch
>
>> /js
>>
>> On Fri, Mar 04, 2016 at 11:27:23AM +0100, Benoit Claise wrote:
>> > Dear all,
>> >
>> > This draft is extremely important because it doesn't only cover
>routing
>> > information but it wants to impose a structure for all YANG models.
>> > Please review and comment.
>> >
>> >
>> > Regards, Benoit
>> >  Forwarded Message 
>> > Subject: Re: [Rtg-dt-yang-arch] I-D Action:
>> > draft-rtgyangdt-rtgwg-device-model-03.txt
>> > Date: Thu, 25 Feb 2016 17:55:31 +
>> > From: Jeff Tantsura 
>> > To: Lou Berger 
>> > CC: Routing Area YANG Architecture DT ,
>> > Routing WG 
>> >
>> >
>> >
>> > Hi RTGWG,
>> >
>> > Given the importance of the document, please do review and provide
>your
>> > comments, suggestions and in case you wouldn't support it as is  -
>what
>> > should be changed/missing.
>> >
>> > Thanks!
>> >
>> > Regards,
>> > Jeff
>> >
>> > >On Feb 23, 2016, at 6:40 PM, Lou Berger  wrote:
>> > >
>> > >
>> > >Hello,
>> > >   This draft has been updated to use an emerging yang  capability
>> > >called 'schema-mount' [1] which translates to a significant
>> > >simplification.  To quote the draft:
>> > >
>> > >  Schema Mount enables a dramatic simplification of the presented
>> > >  device model, particularly for "lower-end" devices which are
>unlikely
>> > >  to support multiple network instances or logical network
>elements.
>> > >  Should structural-mount/YSDL not be available, the more explicit
>tree
>> > >  structure presented in earlier versions of this document will
>need to
>> > >  be utilized.
>> > >
>> > >As it looks like there will soon be a netmod WG draft on schema
>mount,
>> > >we think it's time to ask the WG to consider adopting our draft as
>a RTG
>> > >WG draft.
>> > >
>> > >[1] There was a netmod interim on schema mount on Monday, see
>> > >http://etherpad.tools.ietf.org:9000/p/netmod-interim-20160222
>> > >
>> > >Our slides from that meeting are available at
>> >
>>https://www.ietf.org/proceedings/interim/2016/02/22/netmod/slides/slide
>s-interim-2016-netmod-1-1.pptx
>> > >and it gives a brief overview of the current draft.
>> > >
>> > >Lou (and co-authors)
>> > > Forwarded Message 
>> > >Subject:I-D Action: draft-rtgyangdt-rtgwg-device-model-03.txt
>> > >Date:Tue, 23 Feb 2016 18:29:51 -0800
>> > >From:internet-dra...@ietf.org
>> > >Reply-To:internet-dra...@ietf.org
>> > >To:i-d-annou...@ietf.org
>> > >
>> > >
>> > >
>> > >A New Internet-Draft is available from the on-line Internet-Drafts
>> > >directories.
>> > >
>> > >
>> > >   Title   : Network Device YANG Organizational Models
>> > >   Authors : Acee Lindem
>> > > Lou Berger
>> > > Dean Bogdanovic
>> > > Christan Hopps
>> > >   Filename: draft-rtgyangdt-rtgwg-device-model-03.txt
>> > >   Pages   : 36
>> > >   Date: 2016-02-23
>> > >
>> > >Abstract:
>> > >  This document presents an approach for organizing YANG models in
>a
>> > >  comprehensive structure that may be used to configure and operate
>> > >  network devices.  The structure is itself

Re: [netmod] WG adoption poll draft-bjorklund-netmod-structural-mount-02 as draft-ietf-netmod-schema-mount

[Acee Lindem (acee)]

Support.
Acee

On 3/21/16, 12:17 PM, "netmod on behalf of Lou Berger"
 wrote:

>All,
>
>This is start of a two week poll on making
>draft-bjorklund-netmod-structural-mount-02 a working group document with
>the name draft-ietf-netmod-schema-mount.
>
>This adoption is a little bit unusual in that, per our last interim, we
>know that this document is likely to see significant changes in
>technical (solution) details as it progresses through normal WG process.
> And the -01 version is expected to be done in combination with
>Lada/draft-lhotka-netmod-ysdl.
>
>Please send email to the list indicating "yes/support" or "no/do not
>support".  Note that Yes indicates your support for working on a schema
>mount solution, rather than the specific solution.  If you have specific
>technical proposals/suggestions that you'd like to voice please feel
>free to also do so - but please use a new/different thread so we can
>keep the process and technical discussions separate.
>
>The poll ends April 4, 2016
>(after our in-person meeting, but authors / main contributors are not
>expected to be present in BA. So please discuss on list.)
>
>Thank you,
>
>NETMOD Chairs
>
>___
>netmod mailing list
>netmod@ietf.org
>https://www.ietf.org/mailman/listinfo/netmod

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

Re: [netmod] Remove input-interface (metadata) from netmod-acl-model-07 ?

[Acee Lindem (acee)]

Hi Dean,

From: netmod mailto:netmod-boun...@ietf.org>> on 
behalf of Dean Bogdanovic mailto:ivand...@gmail.com>>
Date: Thursday, March 31, 2016 at 5:26 AM
To: "Sterne, Jason (Nokia - CA)" 
mailto:jason.ste...@nokia.com>>
Cc: netmod WG mailto:netmod@ietf.org>>
Subject: Re: [netmod] Remove input-interface (metadata) from 
netmod-acl-model-07 ?


On Mar 30, 2016, at 9:36 PM, Sterne, Jason (Nokia - CA) 
mailto:jason.ste...@nokia.com>> wrote:

Hi all,

The ACL model is converging on a small core set of functionality that is fairly 
common.

But I think the matching on input-interface should be removed from the model 
(or at the least put inside a feature flag).

Matching on basic IPv4/IPv4/MAC header fields is common functionality.  But 
having that input-interface match on metadata in the core model is out of 
place.  It should be left to further extension drafts or vendor specific 
augmentations (along with whatever other metadata might be useful or 
vendor-specific).

ACLs are typically assigned to interfaces as shown in section A.3. of the ACL 
draft.   That is the most common use case.

Actually matching on input-interface in the ACL rules themselves is not basic 
core ACL functionality.  Nokia SR OS does not have that capability.  Does 
IOS-XR ?  Brocade ?  others ?

Cisco and Juniper support matching on input interface. It is useful when you 
want to filter on general traffic coming from interface.

Cisco
match input-interface
match input-vlan

These are “class-map”  sub-commands - not “access-list" sub-commands. So you 
are referring to the general functionality rather than specifically 
functionality supported by access-list?



Junos
family any {
filter L2_filter {
term t1 {
from {
interface fe-0/0/0.0;
}
then {
policer p1;
count c1;
}
}
}
}

Brocade supports matching based on interface, Dell supports VLAN matching, 
Arista supports input interface matching, Redback supports matching against 
input interface for logging,

If you are referring to “log-input”, this indicates to include the 
input-interface in the log message. Cisco supports this as well.

Thanks,
Acee


so it is pretty standard across multiple vendors

Dean

 If some major implementations don’t do it, and it isn’t necessary for 
typical basic ACL use, then it should be removed (or feature flagged).

Regards,
Jason

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

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

Re: [netmod] Remove input-interface (metadata) from netmod-acl-model-07 ?

[Acee Lindem (acee)]

Hi Dean,

From: Dean Bogdanovic mailto:ivand...@gmail.com>>
Date: Saturday, April 2, 2016 at 7:39 AM
To: Acee Lindem mailto:a...@cisco.com>>
Cc: "Sterne, Jason (Nokia - CA)" 
mailto:jason.ste...@nokia.com>>, netmod WG 
mailto:netmod@ietf.org>>
Subject: Re: [netmod] Remove input-interface (metadata) from 
netmod-acl-model-07 ?

Hi Acee,

On Mar 31, 2016, at 8:17 AM, Acee Lindem (acee) 
mailto:a...@cisco.com>> wrote:

Hi Dean,

From: netmod mailto:netmod-boun...@ietf.org>> on 
behalf of Dean Bogdanovic mailto:ivand...@gmail.com>>
Date: Thursday, March 31, 2016 at 5:26 AM
To: "Sterne, Jason (Nokia - CA)" 
mailto:jason.ste...@nokia.com>>
Cc: netmod WG mailto:netmod@ietf.org>>
Subject: Re: [netmod] Remove input-interface (metadata) from 
netmod-acl-model-07 ?


On Mar 30, 2016, at 9:36 PM, Sterne, Jason (Nokia - CA) 
mailto:jason.ste...@nokia.com>> wrote:

Hi all,

The ACL model is converging on a small core set of functionality that is fairly 
common.

But I think the matching on input-interface should be removed from the model 
(or at the least put inside a feature flag).

Matching on basic IPv4/IPv4/MAC header fields is common functionality.  But 
having that input-interface match on metadata in the core model is out of 
place.  It should be left to further extension drafts or vendor specific 
augmentations (along with whatever other metadata might be useful or 
vendor-specific).

ACLs are typically assigned to interfaces as shown in section A.3. of the ACL 
draft.   That is the most common use case.

Actually matching on input-interface in the ACL rules themselves is not basic 
core ACL functionality.  Nokia SR OS does not have that capability.  Does 
IOS-XR ?  Brocade ?  others ?

Cisco and Juniper support matching on input interface. It is useful when you 
want to filter on general traffic coming from interface.

Cisco
match input-interface
match input-vlan

These are “class-map”  sub-commands - not “access-list" sub-commands. So you 
are referring to the general functionality rather than specifically 
functionality supported by access-list?

According to the Cisco website 
(http://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst3750x_3560x/software/release/12-2_55_se/configuration/guide/3750xscg/swacl.html)

Note The ACL must be an extended named ACL.



– match input-interface interface-id-list

– match ip dscp dscp-list

– match ip precedence ip-precedence-list

If you cut the line above this you’d see these are class-map commands as I 
stated previously.


With IPv4 QoS ACLs, if you enter the class-map { match-all | match-any } 
class-map-name global configuration command, you can enter these match commands:

 – match access-group acl-name

Note The ACL must be an extended named ACL.

 – match input-interface interface-id-list

 – match ip dscp dscp-list

 – match ip precedence ip-precedence-list

You cannot enter the match access-group acl-index command.

Thanks,
Acee










Junos
family any {
filter L2_filter {
term t1 {
from {
interface fe-0/0/0.0;
}
then {
policer p1;
count c1;
}
}
}
}

Brocade supports matching based on interface, Dell supports VLAN matching, 
Arista supports input interface matching, Redback supports matching against 
input interface for logging,

If you are referring to “log-input”, this indicates to include the 
input-interface in the log message. Cisco supports this as well.

Thanks,
Acee


so it is pretty standard across multiple vendors

Dean

 If some major implementations don’t do it, and it isn’t necessary for 
typical basic ACL use, then it should be removed (or feature flagged).

Regards,
Jason

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


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

Re: [netmod] identical RIB augmentations in OSPF and ISIS YANG models

[Acee Lindem (acee)]

Hi Lada, Helen, 

On 5/25/16, 9:58 AM, "Ing-Wher (Helen) Chen"  wrote:

>Hi Lada,
>
>"metric" in this case is the operational state metric (or cost) of a
>route, and
>has identical definitions in in all three drafts (OSPF, ISIS, and RIB
>extension).
>(They're all defined to be type uint32, with no range or default value.)
>I
>understand that each protocol might define and configure the metric (or
>cost) of a link differently, but shouldn't the operational state,
>/rt:routing-state/rt:ribs/rt:rib/rt:routes/rt:route/ospf:metric or
>/rt:routing-state/rt:ribs/rt:rib/rt:routes/rt:route/isis:metric or
>/rt:routing-state/rt:ribs/rt:rib/rt:routes/rt:route/rib-ext:metrc , be
>comparable and with the same semantics so that RIB can determine the
>best route?

I can’t think a single uint32 metric should handle the superset of cases.


>
>For route-type, is it possible to define the type as an identityref, and
>let
>each protocol define identities?  (Similar to how
>/rt:routing/rt:routing-protocols/rt:routing-protocol/rt:type is defined
>to be
>type identityref.)

That is a good idea. Trying to define all the possible route-types a
priori is an exercise in futility.


>
>For route-tag, I missed that ISIS defines is as a leaf-list instead of a
>leaf...

This is not widely implemented (if at all) although I have draft for OSPF
supporting multiple tags per prefix. Is it possible to support a single
tag in the ietf-routing and support an augmentation to support multiples
(without it being too ugly)?

Thanks,
Acee

>
>Thanks,
>Helen
>
>> -Original Message-
>> From: Ladislav Lhotka [mailto:lho...@nic.cz]
>> Sent: Wednesday, May 25, 2016 8:28 AM
>> To: Ing-Wher (Helen) Chen ; draft-ietf-ospf-
>> y...@ietf.org; draft-ietf-isis-yang-isis-...@ietf.org;
>>draft-acee-rtgwg-yang-
>> rib-ext...@ietf.org; draft-ietf-netmod-routing-...@ietf.org;
>> netmod@ietf.org
>> Subject: Re: identical RIB augmentations in OSPF and ISIS YANG models
>> 
>> "Ing-Wher (Helen) Chen"  writes:
>> 
>> > Hello,
>> >
>> > I notice that the OSPF and ISIS YANG models
>> > ( and
>> > ) each
>> > defines its own augmentation to
>> > /rt:routing-state/rt:ribs/rt:rib/rt:routes/rt:route that adds metric,
>> > tag and route-type to the OSPF and ISIS YANG models.
>> 
>> Both IS-IS and OSPF define route-type but each uses a different
>>enumeration
>> type, so presumably their semantics are different as well. So I am not
>>sure it
>> is a good idea to define a common route-type in ietf-routing. What
>>would be
>> its type?
>> 
>> I remember there was already a similar discussion about metric, too.
>> Different protocols use metrics with different ranges and semantics, so
>>the
>> conclusion then was to leave the definition of metric to each protocol.
>> 
>> Route tag is uint32 in all cases, so it could be added to ietf-routing.
>> 
>> Lada
>> 
>> >
>> > Separately, I notice that the RIB extension YANG model
>> () also
>> defines a similar augmentation to /rt:routing-
>> state/rt:ribs/rt:rib/rt:routes/rt:route that adds metric and tag (but
>>not route-
>> type).
>> >
>> > Since it looks like the metric/tag/route-type augmentation is common
>>to
>> most routing protocols, may I suggest that these attributes, metric,
>>tag, and
>> route-type, be placed in the (base) routing YANG model
>> ()
>>instead of
>> individual routing protocols or even the RIB extension model?
>> >
>> > Thanks,
>> > Helen
>> 
>> --
>> Ladislav Lhotka, CZ.NIC Labs
>> PGP Key ID: E74E8C0C

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

Re: [netmod] identical RIB augmentations in OSPF and ISIS YANG models

[Acee Lindem (acee)]

Sigh… 

On 5/25/16, 10:09 AM, "Acee Lindem (acee)"  wrote:

>Hi Lada, Helen, 
>
>On 5/25/16, 9:58 AM, "Ing-Wher (Helen) Chen"  wrote:
>
>>Hi Lada,
>>
>>"metric" in this case is the operational state metric (or cost) of a
>>route, and
>>has identical definitions in in all three drafts (OSPF, ISIS, and RIB
>>extension).
>>(They're all defined to be type uint32, with no range or default value.)
>>I
>>understand that each protocol might define and configure the metric (or
>>cost) of a link differently, but shouldn't the operational state,
>>/rt:routing-state/rt:ribs/rt:rib/rt:routes/rt:route/ospf:metric or
>>/rt:routing-state/rt:ribs/rt:rib/rt:routes/rt:route/isis:metric or
>>/rt:routing-state/rt:ribs/rt:rib/rt:routes/rt:route/rib-ext:metrc , be
>>comparable and with the same semantics so that RIB can determine the
>>best route?
>
>I can’t think a single uint32 metric should handle the superset of cases.

I think a single uint32 metric should handle the superset of cases for the
global RIB. 


>
>
>>
>>For route-type, is it possible to define the type as an identityref, and
>>let
>>each protocol define identities?  (Similar to how
>>/rt:routing/rt:routing-protocols/rt:routing-protocol/rt:type is defined
>>to be
>>type identityref.)
>
>That is a good idea. Trying to define all the possible route-types a
>priori is an exercise in futility.
>
>
>>
>>For route-tag, I missed that ISIS defines is as a leaf-list instead of a
>>leaf...
>
>This is not widely implemented (if at all) although I have draft for OSPF
>supporting multiple tags per prefix. Is it possible to support a single
>tag in the ietf-routing and support an augmentation to support multiples
>(without it being too ugly)?
>
>Thanks,
>Acee
>
>>
>>Thanks,
>>Helen
>>
>>> -Original Message-
>>> From: Ladislav Lhotka [mailto:lho...@nic.cz]
>>> Sent: Wednesday, May 25, 2016 8:28 AM
>>> To: Ing-Wher (Helen) Chen ; draft-ietf-ospf-
>>> y...@ietf.org; draft-ietf-isis-yang-isis-...@ietf.org;
>>>draft-acee-rtgwg-yang-
>>> rib-ext...@ietf.org; draft-ietf-netmod-routing-...@ietf.org;
>>> netmod@ietf.org
>>> Subject: Re: identical RIB augmentations in OSPF and ISIS YANG models
>>> 
>>> "Ing-Wher (Helen) Chen"  writes:
>>> 
>>> > Hello,
>>> >
>>> > I notice that the OSPF and ISIS YANG models
>>> > (<https://tools.ietf.org/html/draft-ietf-ospf-yang-04> and
>>> > <https://tools.ietf.org/html/draft-ietf-isis-yang-isis-cfg-08>) each
>>> > defines its own augmentation to
>>> > /rt:routing-state/rt:ribs/rt:rib/rt:routes/rt:route that adds metric,
>>> > tag and route-type to the OSPF and ISIS YANG models.
>>> 
>>> Both IS-IS and OSPF define route-type but each uses a different
>>>enumeration
>>> type, so presumably their semantics are different as well. So I am not
>>>sure it
>>> is a good idea to define a common route-type in ietf-routing. What
>>>would be
>>> its type?
>>> 
>>> I remember there was already a similar discussion about metric, too.
>>> Different protocols use metrics with different ranges and semantics, so
>>>the
>>> conclusion then was to leave the definition of metric to each protocol.
>>> 
>>> Route tag is uint32 in all cases, so it could be added to ietf-routing.
>>> 
>>> Lada
>>> 
>>> >
>>> > Separately, I notice that the RIB extension YANG model
>>> (<https://tools.ietf.org/html/draft-acee-rtgwg-yang-rib-extend-01>)
>>>also
>>> defines a similar augmentation to /rt:routing-
>>> state/rt:ribs/rt:rib/rt:routes/rt:route that adds metric and tag (but
>>>not route-
>>> type).
>>> >
>>> > Since it looks like the metric/tag/route-type augmentation is common
>>>to
>>> most routing protocols, may I suggest that these attributes, metric,
>>>tag, and
>>> route-type, be placed in the (base) routing YANG model
>>> (<https://tools.ietf.org/html/draft-ietf-netmod-routing-cfg-21>)
>>>instead of
>>> individual routing protocols or even the RIB extension model?
>>> >
>>> > Thanks,
>>> > Helen
>>> 
>>> --
>>> Ladislav Lhotka, CZ.NIC Labs
>>> PGP Key ID: E74E8C0C
>

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

Re: [netmod] "A YANG Data Model for Routing Management" Modifications

[Acee Lindem (acee)]

Hi Lada, 
If we can’t get YANG to do what we need, can we just support a choice with
a special value of “unspecified” for the interface and address?
Additionally, we’d need a constraint that enforces the fact that both
interface and address cannot be “unspecified”.

Thanks,
Acee 

On 5/30/16, 8:51 AM, "Ladislav Lhotka"  wrote:

>"Yingzhen Qu (yiqu)"  writes:
>
>> Hi Lada,
>>
>> The ³multi-next-hop² is using the combination of interface and address
>>as
>> the list key. I know key can¹t be empty, but for next hop it¹s possible
>> that only either interface or address is used. I¹ve been trying to
>>figure
>> out a better way to present this, any suggestion?
>
>Optional list keys were proposed for YANG 1.1:
>
>https://svn.tools.ietf.org/svn/wg/netmod/yang-1.1/issues.html#sec-10
>
>The reason that the issue Y09 was eventually rejected was that many
>people thought it was a relatively far-reaching change. This means we
>are left with the same options as in YANG 1.0, none of them being very
>pretty:
>
>- Add a dummy opaque key, e.g.
>
>  list next-hop-entries {
>key id;
>leaf id {
>  type uint16;
>}
>unique interface address;
>...
>  }
>
>- Use special value, such as empty string, to indicate that either
>  interface or address isn't present. But since inet:ipv[46]-address
>  cannot be empty, we would need to define the type of "address" as a
>  union of empty string and inet:ipv[46]-address.
>
>Lada
>
>>
>> If there is anything I can help with the modification, please let me
>>know.
>>
>> Thanks,
>> Yingzhen
>>
>> On 5/27/16, 4:14 AM, "Acee Lindem (acee)"  wrote:
>>
>>>Hi Lada, 
>>>
>>>On 5/27/16, 5:42 AM, "Ladislav Lhotka"  wrote:
>>>
>>>>Hi Acee,
>>>>
>>>>I have a couple of questions:
>>>>
>>>>1. I changed "routing-protocol" -> "control-plane-protocol" (this is
>>>>   already in GitHub). As for identities, I introduced a new base
>>>>   identity "control-plane-protocol", and derived "routing-protocol"
>>>>   from it. So the idea is that routing protocols will still use
>>>>   "routing-protocol" as their base. Is it OK?
>>>
>>>Yes - as long as there is a single list. I¹ll pull the source today.
>>>
>>>>
>>>>2. We could define identities for route types but I am still not
>>>>   convinced that route-type should be added to ietf-routing because
>>>>   then we can't limit the set of types for each protocol, so that, for
>>>>   example, OSPF routes could carry IS-IS Level [12] routes.
>>>
>>>Do you mean that OSPF would install the wrong type of route? I would see
>>>this as a bug but not something the model itself should enforce.
>>>
>>>Note that OSPF can ³carry² any type of route if it is imported into OSPF
>>>and advertised as an AS External route.
>>>
>>>>
>>>>3. The "multi-next-hop" case in rib-extend-01 uses interface and
>>>>address
>>>>   as keys. This means that for every next-hop *both* parameters have
>>>>to
>>>>   be given. Is it really intended?
>>>
>>>No - either or both must be specified but both are not required. I¹ll
>>>leave this to you YANG experts.
>>>
>>>Thanks,
>>>Acee
>>>
>>>
>>>
>>>>
>>>>Thanks, Lada
>>>>
>>>>"Acee Lindem (acee)"  writes:
>>>>
>>>>> Hi Lada, 
>>>>>
>>>>>
>>>>> On 5/23/16, 8:30 AM, "Ladislav Lhotka"  wrote:
>>>>>
>>>>>>"Acee Lindem (acee)"  writes:
>>>>>>
>>>>>>> Hi Lada, 
>>>>>>>
>>>>>>> I thought I go through the impetus for the changes I discussed in
>>>>>>>my
>>>>>>>last
>>>>>>> E-mail. I believe we should make these changes and then freeze the
>>>>>>> specification other than possible modifications based on the
>>>>>>>consensus
>>>>>>>for
>>>>>>> the NETMOD operational state direction.
>>>>>>
>>>>>>I agree.
>>>>>>
>>>>>>>
>>>>>>> The request to merge draft
>>>>>>> https://www.iet

Re: [netmod] Opstate solutions discussions: update and request for WG input

[Acee Lindem (acee)]

I agree that option B is the best way forward. The sooner we reach the
consensus the sooner we can discuss how this can simply models that are
waiting for the IETF OpsState direction.
Thanks,
Acee 

On 6/8/16, 11:20 AM, "netmod on behalf of cho...@chopps.org"
 wrote:

>
>Martin Bjorklund  writes:
>
>> Andy Bierman  wrote:
>>> Hi,
>>>
>>> I prefer (B).
>>
>> For the record, I also prefer B.
>
>I also prefer B.
>
>In addition to the points below, it also "Just Works" for all
>existing and future models including ones designed outside of the
>purview of the IETF.
>
>Thanks,
>Chris.
>
>>
>> B is a more robust solution, since it can handle not only intended and
>> applied, but also other existing (e.g. startup) and future
>> (e.g. ephemeral) datastores.
>>
>>
>> /martin
>>
>>
>>> I do not think it is realistic that vendors will rewrite their IETF
>>> modules and vendor modules and all the associated client/server
>>> instrumentation.
>>> This is expensive at many levels. Stability is important for an API.
>>>
>>> So if we do (A), there will be some modules following the convention
>>> and the rest using proprietary RPC-based solutions.
>>> But if we do (B), vendors can integrate the standard RPC-based solution
>>> into their existing running code with zero disturbance.
>>>
>>>
>>> Andy
>>>
>>>
>>>
>>> On Tue, Jun 7, 2016 at 7:19 AM, Lou Berger  wrote:
>>>
>>> > All,
>>> >
>>> > We want to provide an update based on the off line discussions
>>> > related to OpState Solutions that we have been having and solicit
>>> > input from the WG.
>>> >
>>> > All authors of current solution drafts [1,2,3] together with those
>>> > who helped conduct the solutions analysis* were invited to the these
>>> > discussions -- with the objective of coming up with a single
>>> > consolidated proposal to bring to the WG. (I/Lou acted as facilitator
>>> > as Kent and Juergen were and are involved with the technical
>>>details.)
>>> >
>>> > The discussions have yielded some results but, unfortunately,
>>> > not a single consolidated proposal as hoped, but rather two
>>> > alternate directions -- and clearly we need to choose one:
>>> >
>>> > 1) Adopt the conventions for representing state/config
>>> >based on Section 6 of [1].
>>> >
>>> >From a model definition perspective, these conventions
>>> >impact every model and every model writer.
>>> >
>>> > 2) Model OpState using a revised logical datastore definition
>>> >as introduced in [4] and also covered in [5]. There is
>>> >also a variant of this that we believe doesn't significantly
>>> >impact this choice.
>>> >
>>> >With this approach, model definitions need no explicit
>>> >changes to support applied configuration.
>>> >
>>> > >From a technology/WG standpoint, we believe an approach
>>> > that doesn't impact every model written (i.e., #2) is superior.
>>> > The counterpoint to this is that the conventions based
>>> > approach (i.e., #1) is available today and being followed in
>>> > OpenConfig defined models.
>>> >
>>> > We would like to hear opinions on this from the WG before
>>> > declaring one of the following as the WG direction:
>>> >
>>> > A) models that wish to support applied configuration MUST
>>> >follow conventions based on [1] -- and the WG needs to
>>> >formalize these conventions.
>>> > or
>>> > B) no explicit support is required for models to support
>>> >applied configuration -- and that the WG needs to
>>> >formalize an opstate solution based on the approach
>>> >discussed in [4] and [5].
>>> >
>>> > We intend to close on this choice before Berlin.
>>> >
>>> > Thank you,
>>> > Lou (and co-chairs)
>>> >
>>> > [1] https://tools.ietf.org/html/draft-openconfig-netmod-opstate-01
>>> > [2] https://tools.ietf.org/html/draft-kwatsen-netmod-opstate-02
>>> > [3] https://tools.ietf.org/html/draft-wilton-netmod-opstate-yang-02
>>> > [4] 
>>>https://tools.ietf.org/html/draft-schoenw-netmod-revised-datastores-00
>>> > [5] 
>>>https://tools.ietf.org/html/draft-wilton-netmod-refined-datastores-00
>>> > * - Chris H. and Acee L.
>>> >
>>> >
>>> > ___
>>> > netmod mailing list
>>> > netmod@ietf.org
>>> > https://www.ietf.org/mailman/listinfo/netmod
>>> >
>>
>> ___
>> netmod mailing list
>> netmod@ietf.org
>> https://www.ietf.org/mailman/listinfo/netmod
>

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

Re: [netmod] Remove input-interface (metadata) from netmod-acl-model-07 ?

[Acee Lindem (acee)]

Hi Mahesh, 

From:  Mahesh Jethanandani 
Date:  Thursday, June 9, 2016 at 10:35 AM
To:  Dean Bogdanovic 
Cc:  Acee Lindem , netmod WG 
Subject:  Re: [netmod] Remove input-interface (metadata) from
netmod-acl-model-07 ?


>Dean/Acee,
>
>

I initially misread this as “Dear Acee” ;^)

>
>Is this a relevant example of ACL being configured on an interface?
>
>http://www.cisco.com/c/en/us/td/docs/routers/asr9000/software/asr9k_r4-2/a
>ddr_serv/configuration/guide/b_ipaddr_cg42a9k/b_ipaddr_cg42a9k_chapter_01.
>html#task_1049371
>
>

In the same way I misread your salutation, I think you’ve misinterpreted
this example as it applies to including interface in the ACL model. If you
examine the referenced configuration html closely, you’ll see that the ACL
is a reusable packet-matching policy that is applied to an interface
rather than the interface being included in the ACL rules themselves. In
IOS-XR, the command to apply the ACL to an interface is “{ipv4 | ipv6}
access-group ” specified in interface configuration submode. Is
there something in the text that I’m missing?

>
>Talking to implementers, the feature is very much desired.
>
>

As the initial implementor of the function on Redback SEOS (now Ericsson
IPOS), I can confirm that attaching an ACL to an interface is, indeed, an
essential function.

Thanks,
Acee 



>
>
>Mahesh Jethanandani
>mjethanand...@gmail.com
>
>
>On Apr 2, 2016, at 4:39 AM, Dean Bogdanovic  wrote:
>
>
>
>Hi Acee,
>
>
>On Mar 31, 2016, at 8:17 AM, Acee Lindem (acee)  wrote:
>
>Hi Dean, 
>
>From: netmod  on behalf of Dean Bogdanovic
>
>Date: Thursday, March 31, 2016 at 5:26 AM
>To: "Sterne, Jason (Nokia - CA)" 
>Cc: netmod WG 
>Subject: Re: [netmod] Remove input-interface (metadata) from
>netmod-acl-model-07 ?
>
>
>>
>>
>>On Mar 30, 2016, at 9:36 PM, Sterne, Jason (Nokia - CA)
>> wrote:
>>
>>Hi all,
>> 
>>The ACL model is converging on a small core set of functionality that is
>>fairly common.
>> 
>>But I think the matching on input-interface should be removed from the
>>model (or at the least put inside a feature flag).
>> 
>>Matching on basic IPv4/IPv4/MAC header fields is common functionality.
>>But having that input-interface match on metadata in the core model is
>>out of place.  It should be left to further extension drafts or vendor
>>specific augmentations (along
>> with whatever other metadata might be useful or vendor-specific).
>>
>>
>> 
>>ACLs are typically assigned to interfaces as shown in section A.3. of
>>the ACL draft.   That is the most common use case.
>> 
>>Actually matching on input-interface in the ACL rules themselves is not
>>basic core ACL functionality.  Nokia SR OS does not have that
>>capability.  Does IOS-XR ?  Brocade ?  others ?
>>
>>
>>
>>
>>Cisco and Juniper support matching on input interface. It is useful when
>>you want to filter on general traffic coming from interface.
>>
>>Cisco
>>match input-interface
>>match input-vlan
>>
>>
>>
>>
>
>These are “class-map”  sub-commands - not “access-list" sub-commands. So
>you are referring to the general functionality rather than specifically
>functionality supported by access-list?
>
>
>
>
>
>According to the Cisco website
>(http://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst3750x_3560x/sof
>tware/release/12-2_55_se/configuration/guide/3750xscg/swacl.html)
>
>Note The ACL must be an extended named ACL.
>
>
>
>– match input-interface interface-id-list
>– match ip dscp dscp-list
>– match ip precedence ip-precedence-list
>
>
>
>>
>>
>>Junos
>>family any {
>>filter L2_filter {
>>term t1 {
>>from {
>>interface fe-0/0/0.0;
>>}
>>then {
>>policer p1;
>>count c1;
>>}
>>}
>>}
>>}
>>
>>Brocade supports matching based on interface, Dell supports VLAN
>>matching, Arista supports input interface matching, Redback supports
>>matching against input interface for logging,
>>
>>
>>
>>
>>
>
>If you are referring to “log-input”, this indicates to include the
>input-interface in the log message. Cisco supports this as well.
>
>Thanks,
>Acee 
>
>
>>so it is pretty standard across multiple vendors
>>
>>Dean
>>
>>
>>
>> If some major implementations don’t do it, and it isn’t necessary
>>for typical basic ACL use, then it should be removed (or feature
>>flagged).
>> 
>>Regards,
>>Jason 
>> 
>>___
>>netmod
>> mailing list
>>netmod@ietf.org
>>https://www.ietf.org/mailman/listinfo/netmod
>>
>>
>>
>>
>>
>>
>>
>
>
>
>
>
>
>
>
>
>
>___
>netmod mailing list
>netmod@ietf.org
>https://www.ietf.org/mailman/listinfo/netmod

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

Re: [netmod] Opstate solutions discussions: update and request for WGinput

[Acee Lindem (acee)]

Hi Tom, 
At least most of the YANG model authors that I work with are following
this discussion. However, I would guess that many are waiting for the
outcome and how it affects model structure as opposed to having a strong
opinion on the options.
Thanks,
Acee 

On 6/17/16, 11:15 AM, "netmod on behalf of t.petch"
 wrote:

>Lou
>
>By now, 17th June, I see solid support for one option but only see
>comments from a somewhat small number of participants
>
>The majority of the authors of the 172 YANG files I have in an
>archive are probably unaware of this discussion and yet some at least
>will be affected.  What concerns me is that history might be repeating
>itself.  In a sense, this discussion is about the original proposals for
>NETCONF and YANG not meeting current requirements which
>may be because there has mostly been a limited number of
>participants in netmod discussions.
>
>I was struck by Dale's recent, brilliant review of 6020bis because it
>came from a fresh angle and brought up nagging concerns that I had had
>but had not been able to articulate.  With a wider audience, similar
>comments might have been made much earlier to the advantage
>of YANG (perhaps even about RFC6020).
>
>In the same vein, there is NETCONF.  Juergen's I-D, which I see finding
>favour, could be said to cut the ground from under NETCONF (well, I
>would).  RFC6241 says
>" Configuration data is the set of writable data that is required to
>   transform a system from its initial default state into its current
>   state.  State data is the additional data on a system that is not
>   configuration data such as read-only status information and collected
>   statistics.  "
>
>The proposed 'intended' in the I-D is (ct, ro).  It is ct, configuration
>true, so it is configuration data.  It is ro, read only, so it is
>clearly not
>configuration data.  Without changing RFC6241, I cannot reconcile this.
>
>So I see RFC6241 being changed; can anyone reading the RFC understand it
>any more?  And yet the I-D makes no mention of this change to
>NETCONF nor have I seen any discussion on the netconf list.
>
>Stimulated by posts to the I2RS list, perhaps also a trigger for
>Juergen's I-D, I wrote up my own summary of the current state of
>datastores but I called it draft-tp-netconf-datastore because I see
>NETCONF
>currently telling us almost all that we know about datastores; YANG 1.0
>adds very little.  For me, NETCONF should be the starting point.
>
>Tom Petch
>
>- Original Message -
>From: "Lou Berger" 
>To: "netmod WG" 
>Cc: 
>Sent: Tuesday, June 07, 2016 3:19 PM
>
>> All,
>>
>> We want to provide an update based on the off line discussions
>> related to OpState Solutions that we have been having and solicit
>> input from the WG.
>>
>> All authors of current solution drafts [1,2,3] together with those
>> who helped conduct the solutions analysis* were invited to the these
>> discussions -- with the objective of coming up with a single
>> consolidated proposal to bring to the WG. (I/Lou acted as facilitator
>> as Kent and Juergen were and are involved with the technical details.)
>>
>> The discussions have yielded some results but, unfortunately,
>> not a single consolidated proposal as hoped, but rather two
>> alternate directions -- and clearly we need to choose one:
>>
>> 1) Adopt the conventions for representing state/config
>>based on Section 6 of [1].
>>
>>From a model definition perspective, these conventions
>>impact every model and every model writer.
>>
>> 2) Model OpState using a revised logical datastore definition
>>as introduced in [4] and also covered in [5]. There is
>>also a variant of this that we believe doesn't significantly
>>impact this choice.
>>
>>With this approach, model definitions need no explicit
>>changes to support applied configuration.
>>
>> >From a technology/WG standpoint, we believe an approach
>> that doesn't impact every model written (i.e., #2) is superior.
>> The counterpoint to this is that the conventions based
>> approach (i.e., #1) is available today and being followed in
>> OpenConfig defined models.
>>
>> We would like to hear opinions on this from the WG before
>> declaring one of the following as the WG direction:
>>
>> A) models that wish to support applied configuration MUST
>>follow conventions based on [1] -- and the WG needs to
>>formalize these conventions.
>> or
>> B) no explicit support is required for models to support
>>applied configuration -- and that the WG needs to
>>formalize an opstate solution based on the approach
>>discussed in [4] and [5].
>>
>> We intend to close on this choice before Berlin.
>>
>> Thank you,
>> Lou (and co-chairs)
>>
>> [1] https://tools.ietf.org/html/draft-openconfig-netmod-opstate-01
>> [2] https://tools.ietf.org/html/draft-kwatsen-netmod-opstate-02
>> [3] https://tools.ietf.org/html/draft-wilton-netmod-opstate-yang-02
>> [4]
>ht

Re: [netmod] I-D Action: draft-ietf-netmod-routing-cfg-22.txt

[Acee Lindem (acee)]

Hi Stephane,
I think this will be a protracted discussion. I am a bit tied up with
other activities right now but I plan to start a thread on this early next
week.  
Thanks,
Acee

On 7/7/16, 8:32 AM, "netmod on behalf of stephane.litkow...@orange.com"
 wrote:

>Hi Authors,
>
>Do you plan to move the operational states with the option B) modeling ?
>so we can start moving underneath routing protocol models also ...
>
>Best Regards,
>
>Stephane
>
>-Original Message-
>From: netmod [mailto:netmod-boun...@ietf.org] On Behalf Of
>internet-dra...@ietf.org
>Sent: Tuesday, July 05, 2016 18:52
>To: i-d-annou...@ietf.org
>Cc: netmod@ietf.org
>Subject: [netmod] I-D Action: draft-ietf-netmod-routing-cfg-22.txt
>
>
>A New Internet-Draft is available from the on-line Internet-Drafts
>directories.
>This draft is a work item of the NETCONF Data Modeling Language of the
>IETF.
>
>Title   : A YANG Data Model for Routing Management
>Authors : Ladislav Lhotka
>  Acee Lindem
>   Filename: draft-ietf-netmod-routing-cfg-22.txt
>   Pages   : 72
>   Date: 2016-07-05
>
>Abstract:
>   This document contains a specification of three YANG modules and one
>   submodule.  Together they form the core routing data model which
>   serves as a framework for configuring and managing a routing
>   subsystem.  It is expected that these modules will be augmented by
>   additional YANG modules defining data models for control plane
>   protocols, route filters and other functions.  The core routing data
>   model provides common building blocks for such extensions - routes,
>   routing information bases (RIB), and control plane protocols.
>
>
>The IETF datatracker status page for this draft is:
>https://datatracker.ietf.org/doc/draft-ietf-netmod-routing-cfg/
>
>There's also a htmlized version available at:
>https://tools.ietf.org/html/draft-ietf-netmod-routing-cfg-22
>
>A diff from the previous version is available at:
>https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-routing-cfg-22
>
>
>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/
>
>___
>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

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

[netmod] OpsState Direction Impact on Recommended IETF YANG Model Structure

[Acee Lindem (acee)]

While there are details to be worked out between the two data stores
models (as indicated below), we now have implicit modeling of applied
configuration. Existing models (both standard and draft) do not take this
into consideration and, consequently, much of the state that is modeled
explicitly represents the application configuration. For the RFC models,
it probably doesn’t make much sense to redo them (unless they are being
reworked for other reasons). This still leaves the existing WG draft
models for which we have basically 3 options:

  1. Do nothing - allow them proceed as they are with multiple ways of
representing the applied configuration. This would provide visibility to
the data independent of whether or not the device supported the revised
data-stores supporting implicit retrieval of the applied configuration.
  2. Prune out the redundant data nodes except those required as list
keys, etc, since they can be obtained from the applied state data store.
  3. #2 plus collapse the config (read-write) and  system-state
(read-only) into common containers. No more branching of
-config and -state at the top level of the model.

At I high-level, I feel these are the options. I’m not married to any one
of these and the worse thing we could do is hold up progression of the
existing YANG model drafts for another couple years while we debate the
best course. Having said that, #3 is compelling since it will yield the
most concise models and colocates the schema data nodes for any managed
object. 

Thanks,
Acee 

On 7/1/16, 12:36 PM, "netmod on behalf of Lou Berger"
 wrote:

>All,
>
>It's time to make a consensus call on this topic, so that we can all move
>on to defining a solution and aligning modules under development. Based
>on the feedback received and the overall discussions on the topic, we see
>that there is consensus to follow a datastore based approach to
>supporting operational state, i.e., direction 'B'.
>
>We will be asking the authors of [4] and [5] to review their proposals
>(individual drafts) in Berlin, as well as to highlight differences and
>suggest ways that their work could be consolidated. Of course, others may
>also choose to submit their own proposals. Given the importance of this
>work, we will be looking to have active discussion on the topic both in
>Berlin and on the list, with an objective of having a draft ready for
>considerations as a WG document by the November IETF.
>
>We have reviewed this decision with our AD and the NetConf chairs and
>have agreed to begin this work in NetMod. We certainly expect to
>coordinate the work with the NetConf WG and re-home work as/if needed.
>
>Finally, we'd also like to thank all those who have contributed to this
>discussion to date, from problem identification to proposed solutions,
>and we look forward to your continued efforts to publish a standard
>solution. 
>
>Lou (and Kent)
>
>
>On 6/7/2016 10:19 AM, Lou Berger wrote:
>> All,
>>
>> We want to provide an update based on the off line discussions
>> related to OpState Solutions that we have been having and solicit
>> input from the WG.
>>
>> All authors of current solution drafts [1,2,3] together with those
>> who helped conduct the solutions analysis* were invited to the these
>> discussions -- with the objective of coming up with a single
>> consolidated proposal to bring to the WG. (I/Lou acted as facilitator
>> as Kent and Juergen were and are involved with the technical details.)
>>
>> The discussions have yielded some results but, unfortunately,
>> not a single consolidated proposal as hoped, but rather two
>> alternate directions -- and clearly we need to choose one:
>>
>> 1) Adopt the conventions for representing state/config
>>based on Section 6 of [1].
>>
>>From a model definition perspective, these conventions
>>impact every model and every model writer.
>>
>> 2) Model OpState using a revised logical datastore definition
>>as introduced in [4] and also covered in [5]. There is
>>also a variant of this that we believe doesn't significantly
>>impact this choice.
>>
>>With this approach, model definitions need no explicit
>>changes to support applied configuration.
>>
>> >From a technology/WG standpoint, we believe an approach
>> that doesn't impact every model written (i.e., #2) is superior.
>> The counterpoint to this is that the conventions based
>> approach (i.e., #1) is available today and being followed in
>> OpenConfig defined models.
>>
>> We would like to hear opinions on this from the WG before
>> declaring one of the following as the WG direction:
>>
>> A) models that wish to support applied configuration MUST
>>follow conventions based on [1] -- and the WG needs to
>>formalize these conventions.
>> or
>> B) no explicit support is required for models to support
>>applied configuration -- and that the WG needs to
>>formalize an opstate solution based on the appr

Re: [netmod] OpsState Direction Impact on Recommended IETF YANG Model Structure

[Acee Lindem (acee)]

Hi Lou, 
I’m not advocating this #2. If you are going to rely on the revised data
stores to obtain the information, you should go all the way to #3. For
example, based on the control-plane-protocols in routing-cfg, we have
separate top level containers for config state.

 +--rw routing
  +--rw router-id?
  +--rw control-plane-protocols
  |  +--rw control-plane-protocol* [type name]


And:
+— ro routing-state
  +--ro router-id?
  +--ro interfaces
  |  +--ro interface*
  +--ro control-plane-protocols
  |  +--ro control-plane-protocol* [type name]
  | +--ro type
  | +--ro name


The control plane protocols augment these two lists separately. With #2,
we leave the bifurcated structure and simply remove the data nodes that
are not needed from the protocol state.

Thanks,
Acee 

On 7/12/16, 11:23 AM, "Lou Berger"  wrote:

>Acee,
>
>I personally was assuming we'd follow 3, but I'd like to understand
>the implication of 2 as I'm not sure I really understand what you're
>thinking here.  Can you elaborate what you're thinking here?
>
>Thanks,
>
>Lou
>
>On 7/11/2016 12:36 PM, Acee Lindem (acee) wrote:
>> While there are details to be worked out between the two data stores
>> models (as indicated below), we now have implicit modeling of applied
>> configuration. Existing models (both standard and draft) do not take
>>this
>> into consideration and, consequently, much of the state that is modeled
>> explicitly represents the application configuration. For the RFC models,
>> it probably doesn’t make much sense to redo them (unless they are being
>> reworked for other reasons). This still leaves the existing WG draft
>> models for which we have basically 3 options:
>>
>>   1. Do nothing - allow them proceed as they are with multiple ways of
>> representing the applied configuration. This would provide visibility to
>> the data independent of whether or not the device supported the revised
>> data-stores supporting implicit retrieval of the applied configuration.
>>   2. Prune out the redundant data nodes except those required as list
>> keys, etc, since they can be obtained from the applied state data store.
>>   3. #2 plus collapse the config (read-write) and  system-state
>> (read-only) into common containers. No more branching of
>> -config and -state at the top level of the
>>model.
>>
>> At I high-level, I feel these are the options. I’m not married to any
>>one
>> of these and the worse thing we could do is hold up progression of the
>> existing YANG model drafts for another couple years while we debate the
>> best course. Having said that, #3 is compelling since it will yield the
>> most concise models and colocates the schema data nodes for any managed
>> object. 
>>
>> Thanks,
>> Acee 
>>
>> On 7/1/16, 12:36 PM, "netmod on behalf of Lou Berger"
>>  wrote:
>>
>>> All,
>>>
>>> It's time to make a consensus call on this topic, so that we can all
>>>move
>>> on to defining a solution and aligning modules under development. Based
>>> on the feedback received and the overall discussions on the topic, we
>>>see
>>> that there is consensus to follow a datastore based approach to
>>> supporting operational state, i.e., direction 'B'.
>>>
>>> We will be asking the authors of [4] and [5] to review their proposals
>>> (individual drafts) in Berlin, as well as to highlight differences and
>>> suggest ways that their work could be consolidated. Of course, others
>>>may
>>> also choose to submit their own proposals. Given the importance of this
>>> work, we will be looking to have active discussion on the topic both in
>>> Berlin and on the list, with an objective of having a draft ready for
>>> considerations as a WG document by the November IETF.
>>>
>>> We have reviewed this decision with our AD and the NetConf chairs and
>>> have agreed to begin this work in NetMod. We certainly expect to
>>> coordinate the work with the NetConf WG and re-home work as/if needed.
>>>
>>> Finally, we'd also like to thank all those who have contributed to this
>>> discussion to date, from problem identification to proposed solutions,
>>> and we look forward to your continued efforts to publish a standard
>>> solution. 
>>>
>>> Lou (and Kent)
>>>
>>>
>>> On 6/7/2016 10:19 AM, Lou Berger wrote:
>>>> All,
>>>>
>>>> We want to provide an update based on the off line discu

Re: [netmod] OpsState Direction Impact on Recommended IETF YANG Model Structure

[Acee Lindem (acee)]

Hi Andy,

From: Andy Bierman mailto:a...@yumaworks.com>>
Date: Tuesday, July 12, 2016 at 12:17 PM
To: Lou Berger mailto:lber...@labn.net>>
Cc: Acee Lindem mailto:a...@cisco.com>>, netmod WG 
mailto:netmod@ietf.org>>
Subject: Re: [netmod] OpsState Direction Impact on Recommended IETF YANG Model 
Structure



On Tue, Jul 12, 2016 at 8:23 AM, Lou Berger 
mailto:lber...@labn.net>> wrote:
Acee,

I personally was assuming we'd follow 3, but I'd like to understand
the implication of 2 as I'm not sure I really understand what you're
thinking here.  Can you elaborate what you're thinking here?

Thanks,

Lou
.
>   3. #2 plus collapse the config (read-write) and  system-state
> (read-only) into common containers. No more branching of
> -config and -state at the top level of the model.
>.


I would really like to understand what problem (3) is supposed to solve.

Most of the foo-state variables are for monitoring.
This information is useful even if the server uses proprietary configuration 
mechanisms.
(e.g., the way the SNMP world has worked for 30 years)

If you forbid separate monitoring subtrees and force the data to be co-located
with configuration, that means the standard monitoring will not be supported
unless the standard configuration is also supported.

If they are meant to be supported independently, why wouldn’t they be separate 
models?

Thanks,
Acee


Why is that progress?


Andy



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

Re: [netmod] OpsState Direction Impact on Recommended IETF YANG Model Structure

[Acee Lindem (acee)]

From: Andy Bierman mailto:a...@yumaworks.com>>
Date: Tuesday, July 12, 2016 at 12:38 PM
To: Acee Lindem mailto:a...@cisco.com>>
Cc: Lou Berger mailto:lber...@labn.net>>, netmod WG 
mailto:netmod@ietf.org>>
Subject: Re: [netmod] OpsState Direction Impact on Recommended IETF YANG Model 
Structure



On Tue, Jul 12, 2016 at 9:30 AM, Acee Lindem (acee) 
mailto:a...@cisco.com>> wrote:
Hi Andy,

From: Andy Bierman mailto:a...@yumaworks.com>>
Date: Tuesday, July 12, 2016 at 12:17 PM
To: Lou Berger mailto:lber...@labn.net>>
Cc: Acee Lindem mailto:a...@cisco.com>>, netmod WG 
mailto:netmod@ietf.org>>
Subject: Re: [netmod] OpsState Direction Impact on Recommended IETF YANG Model 
Structure



On Tue, Jul 12, 2016 at 8:23 AM, Lou Berger 
mailto:lber...@labn.net>> wrote:
Acee,

I personally was assuming we'd follow 3, but I'd like to understand
the implication of 2 as I'm not sure I really understand what you're
thinking here.  Can you elaborate what you're thinking here?

Thanks,

Lou
.
>   3. #2 plus collapse the config (read-write) and  system-state
> (read-only) into common containers. No more branching of
> -config and -state at the top level of the model.
>.


I would really like to understand what problem (3) is supposed to solve.

Most of the foo-state variables are for monitoring.
This information is useful even if the server uses proprietary configuration 
mechanisms.
(e.g., the way the SNMP world has worked for 30 years)

If you forbid separate monitoring subtrees and force the data to be co-located
with configuration, that means the standard monitoring will not be supported
unless the standard configuration is also supported.

If they are meant to be supported independently, why wouldn’t they be separate 
models?



YANG features can be used and they can still be supported independently.

True - but I have not run across a model featured at the config/state branch.

Acee





Thanks,
Acee


Andy


Why is that progress?


Andy




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

Re: [netmod] OpsState Direction Impact on Recommended IETF YANG Model Structure

[Acee Lindem (acee)]

From: netmod mailto:netmod-boun...@ietf.org>> on 
behalf of Andy Bierman mailto:a...@yumaworks.com>>
Date: Tuesday, July 12, 2016 at 1:27 PM
To: "Robert Wilton -X (rwilton - ENSOFT LIMITED at Cisco)" 
mailto:rwil...@cisco.com>>
Cc: netmod WG mailto:netmod@ietf.org>>
Subject: Re: [netmod] OpsState Direction Impact on Recommended IETF YANG Model 
Structure



On Tue, Jul 12, 2016 at 10:22 AM, Robert Wilton 
mailto:rwil...@cisco.com>> wrote:


On 12/07/2016 18:05, Andy Bierman wrote:


On Tue, Jul 12, 2016 at 9:59 AM, Robert Wilton 
mailto:rwil...@cisco.com>> wrote:

Hi Andy,

On 12/07/2016 17:17, Andy Bierman wrote:


On Tue, Jul 12, 2016 at 8:23 AM, Lou Berger 
<lber...@labn.net> wrote:
Acee,

I personally was assuming we'd follow 3, but I'd like to understand
the implication of 2 as I'm not sure I really understand what you're
thinking here.  Can you elaborate what you're thinking here?

Thanks,

Lou
.
>   3. #2 plus collapse the config (read-write) and  system-state
> (read-only) into common containers. No more branching of
> -config and -state at the top level of the model.
>.


I would really like to understand what problem (3) is supposed to solve.
My personal view is that I think that it makes the models simpler, with less 
duplication.

E.g. I also see that it makes it easier for a client to fetch all of the 
information associated with a particular feature in a single sub tree rather 
that needing to merge data from two separate config & state sub trees.


This is your opinion.
I think separate makes it easier to read, especially if the monitoring data
is relevant regardless of how associated configuration was done.
This is easily achievable by filtering (e.g. only return config false leaves + 
config true structural nodes).



Filtering is not widely implemented or implemented correctly.

IMO it is up to the data model designers how they want to organize their data.
I have not heard any valid reasons why a generalized solution is even needed,
let alone why separate config and state needs to be avoided.

There is definitely value in having model conventions. One argument for 
collapsing the config and state is that once you have the implicit retrieval of 
the applied state, there is much less operational state that isn’t redundant.

There is also requirement #4 in 
https://www.ietf.org/id/draft-ietf-netmod-opstate-reqs-04.txt. However, I know 
you’ve never been a fan of this document.

Thanks,
Acee






Andy





Most of the foo-state variables are for monitoring.
This information is useful even if the server uses proprietary configuration 
mechanisms.
(e.g., the way the SNMP world has worked for 30 years)
I thought that it was config that was originally driving YANG because there is 
already a solution for state data (SNMP).  Hence, I would have thought that the 
most common case would be that YANG is used just for config, or config & state. 
 So, I think that it makes sense to optimize models for these scenarios.


This is marketing.
Do you have any technical arguments?
Yes, I gave them below: I don't see that merging config and state prevents 
entities from only monitoring state if they wish.

Thanks,
Rob





If you forbid separate monitoring subtrees and force the data to be co-located
with configuration, that means the standard monitoring will not be supported
unless the standard configuration is also supported.
Both datastore draft solutions allow for system created config entries.  So in 
both drafts the operational state datastore can instantiate whatever config 
nodes are necessary to parent config false state nodes.

I also don't think that separate monitoring subtrees are going to be banned, 
they should be used where appropriate.  It is just that it will be no longer be 
required to have separate state subtrees purely because of potential 
differences in the lifetime of config vs state objects (e.g. interfaces vs 
interfaces-state).

I would be very happy if "interfaces" and "interfaces-state" could be merged 
into "interfaces" as a new/updated interfaces YANG model that draft models 
could be updated to use.  I understand that would be a impactful change to make 
(but seemingly mostly on IETF models that haven't yet been standardized).  But 
I hope that we are going to have to live with the YANG model structure for a 
long time, and if we still have an opportunity to "fix" a fairly big wart then 
I think that it would be good to do so.


I can't say if the pre-provisioning model in ietf-interfaces should be 
generalized.
I have not seen any good general solutions for combining config and state.



Rob

Andy


  Why is that progress?


Andy






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




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

Re: [netmod] OpsState Direction Impact on Recommended IETF YANG Model Structure

[Acee Lindem (acee)]

On 7/14/16, 4:00 PM, "Kent Watsen"  wrote:

>
>[This thread took on a life of its own, so I’m replying to this email
>from two days ago]
>
>I had assumed the plan/recommendation would be:
>  - for works-in-progress, to evaluate if their models can be improved.
>  - for existing RFCs, do nothing (though we may want to consider
>RFC7223).
>
>By “if their models can be improved” in the above, I’m implying that
>having a top-level -state branch may still be the best solution for some
>models.  It’s up to each model designer to decide the best approach for
>their models.
>
>Makes sense?

I think the statement “if their models can be improved” leaves too much
subjectivity in the guideline. Either we are going to avail the revised
data store model to avoid duplication of YANG schema nodes or we are going
to leverage the new data stores solely to meet the intended/applied config
requirement. If it is the latter and a good portion of the network devices
will not support, then I would agree.




>
>Kent  // as a contributor
>
>
>On 7/12/16, 11:23 AM, "netmod on behalf of Lou Berger"
> wrote:
>
>Acee,
>
>I personally was assuming we'd follow 3, but I'd like to understand
>the implication of 2 as I'm not sure I really understand what you're
>thinking here.  Can you elaborate what you're thinking here?
>
>Thanks,
>
>Lou
>
>On 7/11/2016 12:36 PM, Acee Lindem (acee) wrote:
>> While there are details to be worked out between the two data stores
>> models (as indicated below), we now have implicit modeling of applied
>> configuration. Existing models (both standard and draft) do not take
>>this
>> into consideration and, consequently, much of the state that is modeled
>> explicitly represents the application configuration. For the RFC models,
>> it probably doesn’t make much sense to redo them (unless they are being
>> reworked for other reasons). This still leaves the existing WG draft
>> models for which we have basically 3 options:
>>
>>   1. Do nothing - allow them proceed as they are with multiple ways of
>> representing the applied configuration. This would provide visibility to
>> the data independent of whether or not the device supported the revised
>> data-stores supporting implicit retrieval of the applied configuration.
>>   2. Prune out the redundant data nodes except those required as list
>> keys, etc, since they can be obtained from the applied state data store.
>>   3. #2 plus collapse the config (read-write) and  system-state
>> (read-only) into common containers. No more branching of
>> -config and -state at the top level of the
>>model.
>>
>> At I high-level, I feel these are the options. I’m not married to any
>>one
>> of these and the worse thing we could do is hold up progression of the
>> existing YANG model drafts for another couple years while we debate the
>> best course. Having said that, #3 is compelling since it will yield the
>> most concise models and colocates the schema data nodes for any managed
>> object. 
>>
>> Thanks,
>> Acee 
>>
>> On 7/1/16, 12:36 PM, "netmod on behalf of Lou Berger"
>>  wrote:
>>
>>> All,
>>>
>>> It's time to make a consensus call on this topic, so that we can all
>>>move
>>> on to defining a solution and aligning modules under development. Based
>>> on the feedback received and the overall discussions on the topic, we
>>>see
>>> that there is consensus to follow a datastore based approach to
>>> supporting operational state, i.e., direction 'B'.
>>>
>>> We will be asking the authors of [4] and [5] to review their proposals
>>> (individual drafts) in Berlin, as well as to highlight differences and
>>> suggest ways that their work could be consolidated. Of course, others
>>>may
>>> also choose to submit their own proposals. Given the importance of this
>>> work, we will be looking to have active discussion on the topic both in
>>> Berlin and on the list, with an objective of having a draft ready for
>>> considerations as a WG document by the November IETF.
>>>
>>> We have reviewed this decision with our AD and the NetConf chairs and
>>> have agreed to begin this work in NetMod. We certainly expect to
>>> coordinate the work with the NetConf WG and re-home work as/if needed.
>>>
>>> Finally, we'd also like to thank all those who have contributed to this
>>> discussion to date, from problem identification to proposed solutions,
>>> and we look forward to

Re: [netmod] OpsState Direction Impact on Recommended IETF YANG Model Structure

[Acee Lindem (acee)]

On 7/15/16, 10:23 AM, "Robert Wilton -X (rwilton - ENSOFT LIMITED at
Cisco)"  wrote:

>
>
>On 15/07/2016 15:16, Acee Lindem (acee) wrote:
>>
>> On 7/14/16, 4:00 PM, "Kent Watsen"  wrote:
>>
>>> [This thread took on a life of its own, so I’m replying to this email
>> >from two days ago]
>>> I had assumed the plan/recommendation would be:
>>>   - for works-in-progress, to evaluate if their models can be improved.
>>>   - for existing RFCs, do nothing (though we may want to consider
>>> RFC7223).
>>>
>>> By “if their models can be improved” in the above, I’m implying that
>>> having a top-level -state branch may still be the best solution for
>>>some
>>> models.  It’s up to each model designer to decide the best approach for
>>> their models.
>>>
>>> Makes sense?
>> I think the statement “if their models can be improved” leaves too much
>> subjectivity in the guideline. Either we are going to avail the revised
>> data store model to avoid duplication of YANG schema nodes or we are
>>going
>> to leverage the new data stores solely to meet the intended/applied
>>config
>> requirement. If it is the latter and a good portion of the network
>>devices
>> will not support, then I would agree.
>Devices can still leverage the new operational state datastore (and
>hence allow foo and foo-state to be merged) without having to supporting
>an intended/applied configuration split (i.e. they just treat applied =
>intended).

Right - but then the applied configuration wouldn’t be available for the
cases where it does differ from intended configuration.

>
>I'm keen to get the models simpler were possible because I think that
>will help with their longevity and ease of use.

For the record, I agree. However, reaching consensus will be difficult.

Thanks,
Acee



>
>Thanks,
>Rob
>
>
>>
>>
>>
>>
>>> Kent  // as a contributor
>>>
>>>
>>> On 7/12/16, 11:23 AM, "netmod on behalf of Lou Berger"
>>>  wrote:
>>>
>>> Acee,
>>>
>>> I personally was assuming we'd follow 3, but I'd like to understand
>>> the implication of 2 as I'm not sure I really understand what you're
>>> thinking here.  Can you elaborate what you're thinking here?
>>>
>>> Thanks,
>>>
>>> Lou
>>>
>>> On 7/11/2016 12:36 PM, Acee Lindem (acee) wrote:
>>>> While there are details to be worked out between the two data stores
>>>> models (as indicated below), we now have implicit modeling of applied
>>>> configuration. Existing models (both standard and draft) do not take
>>>> this
>>>> into consideration and, consequently, much of the state that is
>>>>modeled
>>>> explicitly represents the application configuration. For the RFC
>>>>models,
>>>> it probably doesn’t make much sense to redo them (unless they are
>>>>being
>>>> reworked for other reasons). This still leaves the existing WG draft
>>>> models for which we have basically 3 options:
>>>>
>>>>1. Do nothing - allow them proceed as they are with multiple ways
>>>>of
>>>> representing the applied configuration. This would provide visibility
>>>>to
>>>> the data independent of whether or not the device supported the
>>>>revised
>>>> data-stores supporting implicit retrieval of the applied
>>>>configuration.
>>>>2. Prune out the redundant data nodes except those required as list
>>>> keys, etc, since they can be obtained from the applied state data
>>>>store.
>>>>3. #2 plus collapse the config (read-write) and  system-state
>>>> (read-only) into common containers. No more branching of
>>>> -config and -state at the top level of the
>>>> model.
>>>>
>>>> At I high-level, I feel these are the options. I’m not married to any
>>>> one
>>>> of these and the worse thing we could do is hold up progression of the
>>>> existing YANG model drafts for another couple years while we debate
>>>>the
>>>> best course. Having said that, #3 is compelling since it will yield
>>>>the
>>>> most concise models and colocates the schema data nodes for any
>>>>managed
>>>> object.
>>>>
>>>> Thanks,
>>>> Acee
>>>>
>>>> On 7/1/16, 12:

Re: [netmod] OpsState Direction Impact on Recommended IETF YANG Model Structure

[Acee Lindem (acee)]

From: netmod mailto:netmod-boun...@ietf.org>> on 
behalf of Kent Watsen mailto:kwat...@juniper.net>>
Date: Tuesday, July 26, 2016 at 10:36 PM
To: "Robert Wilton -X (rwilton - ENSOFT LIMITED at Cisco)" 
mailto:rwil...@cisco.com>>, netmod WG 
mailto:netmod@ietf.org>>
Subject: Re: [netmod] OpsState Direction Impact on Recommended IETF YANG Model 
Structure




So my thinking is that if we can't merge "foo-state" into "foo" then instead we 
should have consistent rules that explicitly state that for all IETF models 
"foo" and "foo-state" are separate trees with a consistent naming convention 
and structure.  That should hopefully allow tooling to programmatically relate 
the two separate trees together.  It may give a path to allow "foo-state" to be 
merged into "foo" in future, but once IETF has standardized 600+ models with 
separate sub-trees, I cannot see that they would get merged back together again.

What other alternatives are available?  As a WG we need to tell the other WGs 
how the IETF YANG models should be structured.

In short, unfortunately I think that we have probably already missed the 
opportunity to merge "foo" and "foo-state" subtrees together ...




Firstly, I’m trying to get a sense of how big a problem this foo/foo-state 
thing is.  [Note: by foo-state, I’m only referring to counters, not opstate].   
I know about RFC 7223, which was done out of consideration for system-generated 
interfaces, but how many other such models are there envisioned to be?  Is this 
issue currently blocking models from progressing, or are we getting ourselves 
wrapped around a hypothetical?  If RFC 7223 is an outlier, then we can address 
it as a special case (perhaps via the related-state/related-config YANG 
annotations).  What do you think?

Next, regarding paths forward (assuming 7223 is not an outlier), I’m thinking 
the opposite.  I’m quite sure that we would never merge the 600+ models with 
separate subtrees back together again.  So I’m thinking we immediately merge 
foo and foo-state in all active YANG models (so that the YANG “conceptual” 
models are stable and good) *and* then we use your idea to programmatically 
generate the “foo-state” tree, presumably only when needed.  This foo-state 
tree could be generated offline by tools and provided as a second YANG module 
in drafts.  In this way, servers (opstate aware or not) can advertise if 
clients can access the foo-state tree (an opstate-aware server may still 
advertise it for business reasons, and it can ‘deprecate’ the tree when no 
longer needed).   We could do the same without tools today by just using a 
feature statement on, for instance, the interfaces-state container, but I like 
pushing for tooling upfront so that we’re guaranteed mergeability later.  
Thoughts?

There are a number of issues here. The first is that you are now depending on 
the separate applied state data store being implemented on every network device 
if you are going to eliminate the duplication of actual values in the OpState. 
The second is that OpsState is MUCH more than just counters. For example, for 
routing protocols will many times include a local RIB. The third is that it is 
a big change for these draft models and, if you have been following the 
discussion on the list, you should know that this option is not universally 
accepted (reference the E-mail thread I started with options before IETF 96).

Acee







Kent // as a contributor



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

Re: [netmod] OpsState Direction Impact on Recommended IETF YANG Model Structure

[Acee Lindem (acee)]

From: Kent Watsen mailto:kwat...@juniper.net>>
Date: Wednesday, July 27, 2016 at 12:19 AM
To: Acee Lindem mailto:a...@cisco.com>>, "Robert Wilton -X 
(rwilton - ENSOFT LIMITED at Cisco)" 
mailto:rwil...@cisco.com>>, netmod WG 
mailto:netmod@ietf.org>>
Subject: Re: [netmod] OpsState Direction Impact on Recommended IETF YANG Model 
Structure


There are a number of issues here. The first is that you are now depending on 
the separate applied state data store being implemented on every network device 
if you are going to eliminate the duplication of actual values in the OpState. 
The second is that OpsState is MUCH more than just counters. For example, for 
routing protocols will many times include a local RIB. The third is that it is 
a big change for these draft models and, if you have been following the 
discussion on the list, you should know that this option is not universally 
accepted (reference the E-mail thread I started with options before IETF 96).



But I specifically called out that I was only talking about counters (e.g., 
7223) and not applied config.   For applied config, I think that we’ll wait for 
the opstate solution, per decision ‘B’.

Why would we consider handling counters differently from other operational 
state that is not part of applied config???

Acee




Regardless, let’s not lose focus on my first question about how prevalent an 
issue this is.  If 7223 is a singularity, then we should stop worrying about 
this as a general problem.  I’d like to understand how big this box is before 
jumping into it.

We’ve had config false leafs mixed in config true trees forever.  Only when 
there are system-generated values or values whose lifetimes extend past the 
lifetime of the config true object is there an issue.   This isn’t a new thing, 
nor an applied config thing, but it can be nicely solved by the opstate 
solution.  The only question is what we do in the interim.

Kent  // as a contributor


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

Re: [netmod] OpsState Direction Impact on Recommended IETF YANG Model Structure

[Acee Lindem (acee)]

From: netmod mailto:netmod-boun...@ietf.org>> on 
behalf of Mahesh Jethanandani 
mailto:mjethanand...@gmail.com>>
Date: Wednesday, July 27, 2016 at 9:07 PM
To: Xufeng Liu mailto:xufeng.liu.i...@gmail.com>>
Cc: netmod WG mailto:netmod@ietf.org>>
Subject: Re: [netmod] OpsState Direction Impact on Recommended IETF YANG Model 
Structure

Robert mentions IS-IS, and if I look at OSPF, I see a clear separation of rw 
and ro nodes.

Right - and this separation is based on the routing and routing-state split in 
the ietf-routing-cfg model. In general, ietf-routing-cfg specifies that all 
control plane protocol YANG models should adapt this structure. Anyone who 
thinks collapsing all the models one config/state tree is simply a matter of 
moving a few counters should taking a better look at the existing drafts. I 
outlined the options in the E-mail thread prior to IETF 96.  Now, with the 
context of IETF 96 behind us, I believe more NETMOD participants will 
understand the options. To review the options specified in the previous E-mail 
thread.

   1. Do nothing - allow them proceed as they are with multiple ways of
   representing the applied configuration. This would provide visibility to
   the data independent of whether or not the device supported the revised
   data-stores supporting implicit retrieval of the applied configuration.
   2. Prune out the redundant data nodes except those required as list
keys, etc, since they can be obtained from the applied state data store.
  3. #2 plus collapse the config (read-write) and  system-state
   (read-only) into common containers. No more branching of
   -config and -state at the top level of the model.

Prior to IETF 96, I don’t believe we had selected a direction. However, I 
believe we agreed on option #1 in order to allow the publication of these 
models within the next year. We’d still be able to avail the benefits of 
applied vs intended configuration on network devices supporting these data 
stores.

Thanks,
Acee





On Jul 27, 2016, at 11:22 AM, Xufeng Liu 
mailto:xufeng.liu.i...@gmail.com>> wrote:

The assumption of “I suspect that all the routing models will be structured 
similarly” is not correct. Very few models in routing area structure this way.

Regards,

- Xufeng

From: netmod [mailto:netmod-boun...@ietf.org] On Behalf Of Robert Wilton
Sent: Wednesday, July 27, 2016 1:05 PM
To: Kent Watsen mailto:kwat...@juniper.net>>; netmod WG 
mailto:netmod@ietf.org>>
Subject: Re: [netmod] OpsState Direction Impact on Recommended IETF YANG Model 
Structure





On 26/07/2016 21:36, Kent Watsen wrote:



So my thinking is that if we can't merge "foo-state" into "foo" then instead we 
should have consistent rules that explicitly state that for all IETF models 
"foo" and "foo-state" are separate trees with a consistent naming convention 
and structure.  That should hopefully allow tooling to programmatically relate 
the two separate trees together.  It may give a path to allow "foo-state" to be 
merged into "foo" in future, but once IETF has standardized 600+ models with 
separate sub-trees, I cannot see that they would get merged back together again.

What other alternatives are available?  As a WG we need to tell the other WGs 
how the IETF YANG models should be structured.

In short, unfortunately I think that we have probably already missed the 
opportunity to merge "foo" and "foo-state" subtrees together ...





Firstly, I’m trying to get a sense of how big a problem this foo/foo-state 
thing is.  [Note: by foo-state, I’m only referring to counters, not opstate].
RW:
By counters, I think that we also mean any config false nodes that don't 
directly represent "applied configuration", right?  E.g. is an interface 
operationally up or down.


   I know about RFC 7223, which was done out of consideration for 
system-generated interfaces, but how many other such models are there 
envisioned to be?
RW:
- Any models that augment RFC 7223 and have config false nodes will be impacted.
- I thought that quite a lot of other IETF models that are in the process of 
being standardized have a top level split between "foo" and "foo-state".  E.g 
the ISIS model (draft-ietf-isis-yang-isis-cfg-08) has this split.  I suspect 
that all the routing models will be structured similarly.
- Although it is perhaps worth pointing out that I think that the OpenConfig 
modules effectively have exactly this same issue (e.g. they have a combined 
interfaces tree keyed by config true leaves), and they pragmatically just 
ignore the issue of system created interface entries.


 Is this issue currently blocking models from progressing, or are we getting 
ourselves wrapped around a hypothetical?
RW:
I think that it is blocking models from progressing.

The current guidance for "intended vs applied" is clear.  I.e. there must not 
be "config false" leaves in the IETF YANG data models to represent "applied 
config".

But there is no clear guidance for the rest of ope

Re: [netmod] OpsState Direction Impact on Recommended IETF YANG Model Structure

[Acee Lindem (acee)]

Hi Lada, 

On 7/28/16, 9:52 AM, "netmod on behalf of Ladislav Lhotka"
 wrote:

>Robert Wilton  writes:
>
>> On 26/07/2016 21:36, Kent Watsen wrote:
>>>
>>> 
>>>
>>>
>>> So my thinking is that if we can't merge "foo-state" into "foo" then
>>> instead we should have consistent rules that explicitly state that for
>>> all IETF models "foo" and "foo-state" are separate trees with a
>>> consistent naming convention and structure.  That should hopefully
>>> allow tooling to programmatically relate the two separate trees
>>> together.  It may give a path to allow "foo-state" to be merged into
>>> "foo" in future, but once IETF has standardized 600+ models with
>>> separate sub-trees, I cannot see that they would get merged back
>>> together again.
>>>
>>> What other alternatives are available?  As a WG we need to tell the
>>> other WGs how the IETF YANG models should be structured.
>>>
>>> In short, unfortunately I think that we have probably already missed
>>> the opportunity to merge "foo" and "foo-state" subtrees together ...
>>>
>>> 
>>>
>>> Firstly, I’m trying to get a sense of how big a problem this
>>> foo/foo-state thing is.  [Note: by foo-state, I’m only referring to
>>> counters, not opstate].
>>>
>> RW:
>> By counters, I think that we also mean any config false nodes that
>>don't 
>> directly represent "applied configuration", right?  E.g. is an
>>interface 
>> operationally up or down.
>>
>>>I know about RFC 7223, which was done out of consideration for
>>> system-generated interfaces, but how many other such models are there
>>> envisioned to be?
>>>
>> RW:
>> - Any models that augment RFC 7223 and have config false nodes will be
>> impacted.
>> - I thought that quite a lot of other IETF models that are in the
>> process of being standardized have a top level split between "foo" and
>> "foo-state".  E.g the ISIS model (draft-ietf-isis-yang-isis-cfg-08) has
>> this split.  I suspect that all the routing models will be structured
>> similarly.
>
>Correct. One reason is that the core routing model envisions
>system-controlled RIBs.
>
>> - Although it is perhaps worth pointing out that I think that the
>> OpenConfig modules effectively have exactly this same issue (e.g. they
>> have a combined interfaces tree keyed by config true leaves), and they
>> pragmatically just ignore the issue of system created interface
>> entries.
>
>The NETMOD WG considered this issue quite important in the past.
>
>My impression from the OpState discussion is that we are on the quest of
>the philosopher's stone, trying to find a shortcut where none is
>possible in general. The long session in Berlin concentrated on the
>life-cycle of a single parameter that's somehow configured, then
>manipulated, and eventually ends up as operational state. IMO this
>is too simplistic, the relationship between configuration and state can
>be much more complex. RIB is one example - it combines contributions
>from configuration (static routes) and derived state (routing
>protocols).

If one were to support the Applied-Config data store, it be comprised of
only the current state of the configured static routes.  The complete RIB
would still need to be accessible in separate data nodes.

Thanks,
Acee 



>
>After all, most real devices have some configuration mode and "show"
>commands. They are separate even though there is certainly some
>relationship between their data.
>
>Lada
>
>>
>>>  Is this issue currently blocking models from progressing, or are we
>>> getting ourselves wrapped around a hypothetical?
>>>
>> RW:
>> I think that it is blocking models from progressing.
>>
>> The current guidance for "intended vs applied" is clear.  I.e. there
>> must not be "config false" leaves in the IETF YANG data models to
>> represent "applied config".
>>
>> But there is no clear guidance for the rest of operational state that
>> isn't applied config.  The other WGs need clear guidance (effectively
>> now) to ensure that they can start publishing models as RFCs.
>>
>>
>>>   If RFC 7223 is an outlier, then we can address it as a special case
>>> (perhaps via the related-state/related-config YANG annotations).  What
>>> do you think?
>>>
>> RW:
>> Personally, I would like one common convention that applies to all IETF
>> YANG models.
>>
>> Idealistically I would like foo and foo-state to be merged because I
>> think that will make the models easier to use and maintain in the long
>> term, but I don't know if we are just too late to go in that direction.
>> 
>> It seems to me that the NETMOD WG really should try to come to a
>> decision quite quickly on this, but I don't know how to encourage that.
>> 
>> A virtual interim on just this topic perhaps?
>>
>>> Next, regarding paths forward (assuming 7223 is not an outlier), I’m
>>> thinking the opposite.  I’m quite sure that we would never merge the
>>> 600+ models with separate subtrees back together again.  So I’m
>>> thinking we immediately merge foo and foo-state in all active YANG
>>> models (so th

Re: [netmod] OpsState Direction Impact on Recommended IETF YANG Model Structure

[Acee Lindem (acee)]

On 7/28/16, 10:42 AM, "Robert Wilton -X (rwilton - ENSOFT LIMITED at
Cisco)"  wrote:

>
>
>On 28/07/2016 15:20, Ladislav Lhotka wrote:
>>> On 28 Jul 2016, at 15:57, Acee Lindem (acee)  wrote:
>>>
>>> Hi Lada,
>>>
>>> On 7/28/16, 9:52 AM, "netmod on behalf of Ladislav Lhotka"
>>>  wrote:
>>>
>>>> Robert Wilton  writes:
>>>>
>>>>> On 26/07/2016 21:36, Kent Watsen wrote:
>>>>>> 
>>>>>>
>>>>>>
>>>>>> So my thinking is that if we can't merge "foo-state" into "foo" then
>>>>>> instead we should have consistent rules that explicitly state that
>>>>>>for
>>>>>> all IETF models "foo" and "foo-state" are separate trees with a
>>>>>> consistent naming convention and structure.  That should hopefully
>>>>>> allow tooling to programmatically relate the two separate trees
>>>>>> together.  It may give a path to allow "foo-state" to be merged into
>>>>>> "foo" in future, but once IETF has standardized 600+ models with
>>>>>> separate sub-trees, I cannot see that they would get merged back
>>>>>> together again.
>>>>>>
>>>>>> What other alternatives are available?  As a WG we need to tell the
>>>>>> other WGs how the IETF YANG models should be structured.
>>>>>>
>>>>>> In short, unfortunately I think that we have probably already missed
>>>>>> the opportunity to merge "foo" and "foo-state" subtrees together ...
>>>>>>
>>>>>> 
>>>>>>
>>>>>> Firstly, I’m trying to get a sense of how big a problem this
>>>>>> foo/foo-state thing is.  [Note: by foo-state, I’m only referring to
>>>>>> counters, not opstate].
>>>>>>
>>>>> RW:
>>>>> By counters, I think that we also mean any config false nodes that
>>>>> don't
>>>>> directly represent "applied configuration", right?  E.g. is an
>>>>> interface
>>>>> operationally up or down.
>>>>>
>>>>>>I know about RFC 7223, which was done out of consideration for
>>>>>> system-generated interfaces, but how many other such models are
>>>>>>there
>>>>>> envisioned to be?
>>>>>>
>>>>> RW:
>>>>> - Any models that augment RFC 7223 and have config false nodes will
>>>>>be
>>>>> impacted.
>>>>> - I thought that quite a lot of other IETF models that are in the
>>>>> process of being standardized have a top level split between "foo"
>>>>>and
>>>>> "foo-state".  E.g the ISIS model (draft-ietf-isis-yang-isis-cfg-08)
>>>>>has
>>>>> this split.  I suspect that all the routing models will be structured
>>>>> similarly.
>>>> Correct. One reason is that the core routing model envisions
>>>> system-controlled RIBs.
>>>>
>>>>> - Although it is perhaps worth pointing out that I think that the
>>>>> OpenConfig modules effectively have exactly this same issue (e.g.
>>>>>they
>>>>> have a combined interfaces tree keyed by config true leaves), and
>>>>>they
>>>>> pragmatically just ignore the issue of system created interface
>>>>> entries.
>>>> The NETMOD WG considered this issue quite important in the past.
>>>>
>>>> My impression from the OpState discussion is that we are on the quest
>>>>of
>>>> the philosopher's stone, trying to find a shortcut where none is
>>>> possible in general. The long session in Berlin concentrated on the
>>>> life-cycle of a single parameter that's somehow configured, then
>>>> manipulated, and eventually ends up as operational state. IMO this
>>>> is too simplistic, the relationship between configuration and state
>>>>can
>>>> be much more complex. RIB is one example - it combines contributions
>>>> from configuration (static routes) and derived state (routing
>>>> protocols).
>>> If one were to support the Applied-Config data store, it be comprised
>>>of
>>> only the current state of the con

Re: [netmod] OpsState Direction Impact on Recommended IETF YANG Model Structure

[Acee Lindem (acee)]

On 7/28/16, 10:20 AM, "Ladislav Lhotka"  wrote:

>
>> On 28 Jul 2016, at 15:57, Acee Lindem (acee)  wrote:
>> 
>> Hi Lada, 
>> 
>> On 7/28/16, 9:52 AM, "netmod on behalf of Ladislav Lhotka"
>>  wrote:
>> 
>>> Robert Wilton  writes:
>>> 
>>>> On 26/07/2016 21:36, Kent Watsen wrote:
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> So my thinking is that if we can't merge "foo-state" into "foo" then
>>>>> instead we should have consistent rules that explicitly state that
>>>>>for
>>>>> all IETF models "foo" and "foo-state" are separate trees with a
>>>>> consistent naming convention and structure.  That should hopefully
>>>>> allow tooling to programmatically relate the two separate trees
>>>>> together.  It may give a path to allow "foo-state" to be merged into
>>>>> "foo" in future, but once IETF has standardized 600+ models with
>>>>> separate sub-trees, I cannot see that they would get merged back
>>>>> together again.
>>>>> 
>>>>> What other alternatives are available?  As a WG we need to tell the
>>>>> other WGs how the IETF YANG models should be structured.
>>>>> 
>>>>> In short, unfortunately I think that we have probably already missed
>>>>> the opportunity to merge "foo" and "foo-state" subtrees together ...
>>>>> 
>>>>> 
>>>>> 
>>>>> Firstly, I’m trying to get a sense of how big a problem this
>>>>> foo/foo-state thing is.  [Note: by foo-state, I’m only referring to
>>>>> counters, not opstate].
>>>>> 
>>>> RW:
>>>> By counters, I think that we also mean any config false nodes that
>>>> don't 
>>>> directly represent "applied configuration", right?  E.g. is an
>>>> interface 
>>>> operationally up or down.
>>>> 
>>>>>   I know about RFC 7223, which was done out of consideration for
>>>>> system-generated interfaces, but how many other such models are there
>>>>> envisioned to be?
>>>>> 
>>>> RW:
>>>> - Any models that augment RFC 7223 and have config false nodes will be
>>>> impacted.
>>>> - I thought that quite a lot of other IETF models that are in the
>>>> process of being standardized have a top level split between "foo" and
>>>> "foo-state".  E.g the ISIS model (draft-ietf-isis-yang-isis-cfg-08)
>>>>has
>>>> this split.  I suspect that all the routing models will be structured
>>>> similarly.
>>> 
>>> Correct. One reason is that the core routing model envisions
>>> system-controlled RIBs.
>>> 
>>>> - Although it is perhaps worth pointing out that I think that the
>>>> OpenConfig modules effectively have exactly this same issue (e.g. they
>>>> have a combined interfaces tree keyed by config true leaves), and they
>>>> pragmatically just ignore the issue of system created interface
>>>> entries.
>>> 
>>> The NETMOD WG considered this issue quite important in the past.
>>> 
>>> My impression from the OpState discussion is that we are on the quest
>>>of
>>> the philosopher's stone, trying to find a shortcut where none is
>>> possible in general. The long session in Berlin concentrated on the
>>> life-cycle of a single parameter that's somehow configured, then
>>> manipulated, and eventually ends up as operational state. IMO this
>>> is too simplistic, the relationship between configuration and state can
>>> be much more complex. RIB is one example - it combines contributions
>>> from configuration (static routes) and derived state (routing
>>> protocols).
>> 
>> If one were to support the Applied-Config data store, it be comprised of
>> only the current state of the configured static routes.  The complete
>>RIB
>> would still need to be accessible in separate data nodes.
>
>Yes, but I didn't talk about intended-applied. I understand that another
>goal of OpState is to unify config and (true) state and get rid of the
>foo and foo-state dichotomy in the data model. I am sceptical about it.

Suffice it to day that in a combined tree there will be state that has not
corresponding config. For e

Re: [netmod] OpsState Direction Impact on Recommended IETF YANG Model Structure

[Acee Lindem (acee)]

Agreed. I’m not saying it isn’t possible to have a combined config/state
tree. My previous point is that it represents a major shift and would be
hard to reach consensus in the desired time frame.

Thanks,
Acee 

On 7/28/16, 10:57 AM, "Robert Wilton -X (rwilton - ENSOFT LIMITED at
Cisco)"  wrote:

>
>
>On 28/07/2016 15:48, Acee Lindem (acee) wrote:
>>
>> On 7/28/16, 10:42 AM, "Robert Wilton -X (rwilton - ENSOFT LIMITED at
>> Cisco)"  wrote:
>>
>>>
>>> On 28/07/2016 15:20, Ladislav Lhotka wrote:
>>>>> On 28 Jul 2016, at 15:57, Acee Lindem (acee)  wrote:
>>>>>
>>>>> Hi Lada,
>>>>>
>>>>> On 7/28/16, 9:52 AM, "netmod on behalf of Ladislav Lhotka"
>>>>>  wrote:
>>>>>
>>>>>> Robert Wilton  writes:
>>>>>>
>>>>>>> On 26/07/2016 21:36, Kent Watsen wrote:
>>>>>>>> 
>>>>>>>>
>>>>>>>>
>>>>>>>> So my thinking is that if we can't merge "foo-state" into "foo"
>>>>>>>>then
>>>>>>>> instead we should have consistent rules that explicitly state that
>>>>>>>> for
>>>>>>>> all IETF models "foo" and "foo-state" are separate trees with a
>>>>>>>> consistent naming convention and structure.  That should hopefully
>>>>>>>> allow tooling to programmatically relate the two separate trees
>>>>>>>> together.  It may give a path to allow "foo-state" to be merged
>>>>>>>>into
>>>>>>>> "foo" in future, but once IETF has standardized 600+ models with
>>>>>>>> separate sub-trees, I cannot see that they would get merged back
>>>>>>>> together again.
>>>>>>>>
>>>>>>>> What other alternatives are available?  As a WG we need to tell
>>>>>>>>the
>>>>>>>> other WGs how the IETF YANG models should be structured.
>>>>>>>>
>>>>>>>> In short, unfortunately I think that we have probably already
>>>>>>>>missed
>>>>>>>> the opportunity to merge "foo" and "foo-state" subtrees together
>>>>>>>>...
>>>>>>>>
>>>>>>>> 
>>>>>>>>
>>>>>>>> Firstly, I’m trying to get a sense of how big a problem this
>>>>>>>> foo/foo-state thing is.  [Note: by foo-state, I’m only referring
>>>>>>>>to
>>>>>>>> counters, not opstate].
>>>>>>>>
>>>>>>> RW:
>>>>>>> By counters, I think that we also mean any config false nodes that
>>>>>>> don't
>>>>>>> directly represent "applied configuration", right?  E.g. is an
>>>>>>> interface
>>>>>>> operationally up or down.
>>>>>>>
>>>>>>>> I know about RFC 7223, which was done out of consideration for
>>>>>>>> system-generated interfaces, but how many other such models are
>>>>>>>> there
>>>>>>>> envisioned to be?
>>>>>>>>
>>>>>>> RW:
>>>>>>> - Any models that augment RFC 7223 and have config false nodes will
>>>>>>> be
>>>>>>> impacted.
>>>>>>> - I thought that quite a lot of other IETF models that are in the
>>>>>>> process of being standardized have a top level split between "foo"
>>>>>>> and
>>>>>>> "foo-state".  E.g the ISIS model (draft-ietf-isis-yang-isis-cfg-08)
>>>>>>> has
>>>>>>> this split.  I suspect that all the routing models will be
>>>>>>>structured
>>>>>>> similarly.
>>>>>> Correct. One reason is that the core routing model envisions
>>>>>> system-controlled RIBs.
>>>>>>
>>>>>>> - Although it is perhaps worth pointing out that I think that the
>>>>>>> OpenConfig modules effectively have exactly this same issue (e.g.
>>>>>>> they
>>>>>>> have a combined interfaces

Re: [netmod] OpsState and Schema-Mount

[Acee Lindem (acee)]

On 8/3/16, 5:02 AM, "netmod on behalf of Robert Wilton -X (rwilton -
ENSOFT LIMITED at Cisco)"  wrote:

>
>
>On 03/08/2016 07:49, Ladislav Lhotka wrote:
>>> On 02 Aug 2016, at 18:35, Balazs Lengyel 
>>>wrote:
>>>
>>> Hello,
>>> If we allow foo and foo-state for opstate, mounting models atop such a
>>>multi rooted yang module will be fun.
>>> mount modB-config-part onto modA-config-part
>>> mount modB-state-part onto modA-state-part
>>> One mount becomes two and you have to maintain parallel mounts
>>>otherwise you are mounting half modules.
>> This is already happenning with augments. It means some work but
>>nothing terribly complex.
>>
>>> Actually the problem is not caused by opstate, but rather by
>>>multi-rooted models. but avoiding foo-state would make life easier once
>>>more.
>> We already agreed that some items (such as RIBs) are "true" state which
>>don't have direct counterparts in configuration. If we don't have
>>foo-state, where are these supposed to be placed?
>One choice is that they could just be placed under foo, where foo is a
>config false leaf.

While there is a NETCONF/RESTCONF incompatibility with config-false data
nodes under config-true data nodes, there is no problem with the reverse -
correct? 

Thanks,
Acee




>
>Rob
>
>
>>
>> Lada
>>
>>> regards Balazs
>>>
>>> -- 
>>> Balazs Lengyel   Ericsson Hungary Ltd.
>>> Senior Specialist
>>> Mobile: +36-70-330-7909  email: balazs.leng...@ericsson.com
>>>
>> --
>> Ladislav Lhotka, CZ.NIC Labs
>> PGP Key ID: E74E8C0C
>>
>>
>>
>>
>> .
>>
>
>___
>netmod mailing list
>netmod@ietf.org
>https://www.ietf.org/mailman/listinfo/netmod

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

Re: [netmod] OpsState and Schema-Mount

[Acee Lindem (acee)]

On 8/4/16, 6:52 AM, "Robert Wilton -X (rwilton - ENSOFT LIMITED at Cisco)"
 wrote:

>
>
>On 03/08/2016 19:37, Acee Lindem (acee) wrote:
>>
>> On 8/3/16, 5:02 AM, "netmod on behalf of Robert Wilton -X (rwilton -
>> ENSOFT LIMITED at Cisco)" > rwil...@cisco.com> wrote:
>>
>>>
>>> On 03/08/2016 07:49, Ladislav Lhotka wrote:
>>>>> On 02 Aug 2016, at 18:35, Balazs Lengyel
>>>>>
>>>>> wrote:
>>>>>
>>>>> Hello,
>>>>> If we allow foo and foo-state for opstate, mounting models atop such
>>>>>a
>>>>> multi rooted yang module will be fun.
>>>>> mount modB-config-part onto modA-config-part
>>>>> mount modB-state-part onto modA-state-part
>>>>> One mount becomes two and you have to maintain parallel mounts
>>>>> otherwise you are mounting half modules.
>>>> This is already happenning with augments. It means some work but
>>>> nothing terribly complex.
>>>>
>>>>> Actually the problem is not caused by opstate, but rather by
>>>>> multi-rooted models. but avoiding foo-state would make life easier
>>>>>once
>>>>> more.
>>>> We already agreed that some items (such as RIBs) are "true" state
>>>>which
>>>> don't have direct counterparts in configuration. If we don't have
>>>> foo-state, where are these supposed to be placed?
>>> One choice is that they could just be placed under foo, where foo is a
>>> config false leaf.
>> While there is a NETCONF/RESTCONF incompatibility with config-false data
>> nodes under config-true data nodes, there is no problem with the
>>reverse -
>> correct?
>You are allowed config false nodes under config true, but not config
>true nodes under config false.
>
>I had assumed in the example above that there wasn't already a config
>true "foo" to put them under, so to reconsider my answer:
>
>In draft-ietf-netmod-routing-cfg "routing" is a top level container that
>is nominally config true.  But it is also a non presence container, so
>it would be allowed to put the config false RIB nodes directly under the
>"routing" container.  Given that "routing" is an NP container, its
>existence (e.g. to report the RIB) doesn't imply that routing has been
>configured.
>
>In fact (given the recent discussion on the NETCONF alias), it is
>questionable what a "config" true NP container actually means.  I
>suspect that really it just ends up being a filter as to what type of
>child nodes are allowed.  I.e. if the NP container is config=true, then
>child nodes can be config true or config false. Conversely, if the NP
>container is config false then any child nodes must also be config false.


Then I see no YANG language barriers in collapsing config and state trees
- the model root just needs to be “config true”.

Thanks,
Acee 



>
>Thanks,
>Rob
>
>
>>
>> Thanks,
>> Acee
>>
>>
>>
>>
>>> Rob
>>>
>>>
>>>> Lada
>>>>
>>>>> regards Balazs
>>>>>
>>>>> -- 
>>>>> Balazs Lengyel   Ericsson Hungary Ltd.
>>>>> Senior Specialist
>>>>> Mobile: +36-70-330-7909  email:
>>>>>balazs.leng...@ericsson.com
>>>>>
>>>> --
>>>> Ladislav Lhotka, CZ.NIC Labs
>>>> PGP Key ID: E74E8C0C
>>>>
>>>>
>>>>
>>>>
>>>> .
>>>>
>>> ___
>>> netmod mailing list
>>> netmod@ietf.org
>>> https://www.ietf.org/mailman/listinfo/netmod
>

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

[netmod] FW: Fwd: I-D Action: draft-ietf-netmod-routing-cfg-23.txt

[Acee Lindem (acee)]

Lou, Kent, 

Lada and I feel this version is ready for WG last call.

Thanks,
Acee 

On 8/18/16, 11:17 AM, "netmod on behalf of Ladislav Lhotka"
 wrote:

>Hi,
>
>apart from relatively minor changes to the schema that were agreed in
>Berlin, all modules were migrated to YANG 1.1 and actively use new YANG
>1.1 features: XPath function derived-from-or-self(), and the action
>"active-route".
>
>Lada
>
>> Begin forwarded message:
>> 
>> From: internet-dra...@ietf.org
>> Subject: [netmod] I-D Action: draft-ietf-netmod-routing-cfg-23.txt
>> Date: 18 August 2016 at 17:12:35 GMT+2
>> To: 
>> Cc: netmod@ietf.org
>> 
>> 
>> A New Internet-Draft is available from the on-line Internet-Drafts
>>directories.
>> This draft is a work item of the NETCONF Data Modeling Language of the
>>IETF.
>> 
>>Title   : A YANG Data Model for Routing Management
>>Authors : Ladislav Lhotka
>>  Acee Lindem
>>  Filename: draft-ietf-netmod-routing-cfg-23.txt
>>  Pages   : 74
>>  Date: 2016-08-18
>> 
>> Abstract:
>>   This document contains a specification of three YANG modules and one
>>   submodule.  Together they form the core routing data model which
>>   serves as a framework for configuring and managing a routing
>>   subsystem.  It is expected that these modules will be augmented by
>>   additional YANG modules defining data models for control plane
>>   protocols, route filters and other functions.  The core routing data
>>   model provides common building blocks for such extensions -- routes,
>>   routing information bases (RIB), and control plane protocols.
>> 
>> 
>> The IETF datatracker status page for this draft is:
>> https://datatracker.ietf.org/doc/draft-ietf-netmod-routing-cfg/
>> 
>> There's also a htmlized version available at:
>> https://tools.ietf.org/html/draft-ietf-netmod-routing-cfg-23
>> 
>> A diff from the previous version is available at:
>> https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-routing-cfg-23
>> 
>> 
>> 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/
>> 
>> ___
>> netmod mailing list
>> netmod@ietf.org
>> https://www.ietf.org/mailman/listinfo/netmod
>
>--
>Ladislav Lhotka, CZ.NIC Labs
>PGP Key ID: E74E8C0C
>
>
>
>
>___
>netmod mailing list
>netmod@ietf.org
>https://www.ietf.org/mailman/listinfo/netmod

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

Re: [netmod] Regarding IPR on draft-ietf-netmod-routing-cfg-23

[Acee Lindem (acee)]

Speaker as an author,

No, I am not aware of an IPR that applies to this draft.

Thanks,
Acee

From: Kent Watsen mailto:kwat...@juniper.net>>
Date: Friday, August 26, 2016 at 1:58 PM
To: Ladislav Lhotka mailto:lho...@nic.cz>>, Acee Lindem 
mailto:a...@cisco.com>>
Cc: "netmod@ietf.org" 
mailto:netmod@ietf.org>>, 
"netmod-cha...@ietf.org" 
mailto:netmod-cha...@ietf.org>>
Subject: Regarding IPR on draft-ietf-netmod-routing-cfg-23


Authors, Contributors, WG,



As part of the WG Last Call, are you aware of any IPR that applies to draft 
identified above?  Please state either:

  * "No, I'm not aware of any IPR that applies to this draft"

  * "Yes, I'm aware of IPR that applies to this draft"



If “yes”, has this IPR been disclosed in compliance with IETF IPR rules (see 
RFCs 3979, 4879, 3669 and 5378 for more details)?   Please state either:

  * "Yes, the IPR has been disclosed in compliance with IETF IPR rules"

  * "No, the IPR has not been disclosed"



If you answer “no”, please provide any additional details you think appropriate.



If you are listed as a document author or contributor, please answer the above 
by responding to this email regardless of whether or not you are aware of any 
relevant IPR. This document will not advance to the next stage until a response 
has been received from each author and listed contributor. NOTE: THIS APPLIES 
TO ALL OF YOU LISTED IN THIS MESSAGE'S TO LINES.



If you are on the WG email list or attend WG meetings but are not listed as an 
author or contributor, we remind you of your obligations under the IETF IPR 
rules which encourages you to notify the IETF if you are aware of IPR of others 
on an IETF contribution, or to refrain from participating in any contribution 
or discussion related to your undisclosed IPR. For more information, please see 
the RFCs listed above and 
http://trac.tools.ietf.org/group/iesg/trac/wiki/IntellectualProperty.



PS: Please include all listed in the headers of this message in your response.



Thank you,

NETMOD WG Chairs






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

Re: [netmod] RFC 6087bis guidance re use of revision statements indrafts

[Acee Lindem (acee)]

On 8/31/16, 8:00 AM, "netmod on behalf of Ladislav Lhotka"
 wrote:

>
>> On 31 Aug 2016, at 13:17, William Lupton 
>>wrote:
>> 
>> I like this. In particular I like the clean use of “version” and
>>“revision”. Editorial nit: add a comma after “i.e.” because that’s the
>>style used for “e.g.”. Tx, W.
>
>+1
>
>Lada

I like this text as well. Keeping a complete revision history in the model
can become unwieldy. Besides, git does a MUCH better job of this.

Thanks,
Acee





>
>> 
>>> On 31 Aug 2016, at 11:56, Jonathan Hansford 
>>>wrote:
>>> 
>>> How about:
>>>  
>>> NEW:
>>>  
>>> It is not required to keep the full revision history of draft versions
>>>(e.g., modules contained within Internet-Drafts). That is, within a
>>>sequence of draft versions, only the most recent revision need be
>>>recorded in the module. However, whenever a new (i.e. changed) version
>>>is made available (e.g., via a new version of an Internet-Draft), the
>>>revision date of that new version MUST be updated to a date later than
>>>that of the previous version.
>>>  
>>> Jonathan
>>>  
>>> From: William Lupton
>>> Sent: 29 August 2016 15:20
>>> To: Andy Bierman
>>> Cc: netmod@ietf.org
>>> Subject: Re: [netmod] RFC 6087bis guidance re use of revision
>>>statements indrafts
>>>  
>>> Andy,
>>>  
>>> This thread started with discussion of an apparent ambiguity in the
>>>current text:
>>>  
>>> OLD
>>>  
>>> It is acceptable to reuse the same revision statement within
>>>unpublished versions (i.e., Internet-Drafts), but the revision date
>>>MUST be updated to a higher value each time the Internet-Draft is
>>>re-posted.
>>>  
>>> —— 
>>>  
>>> It became clear from the subsequent discussion (thanks Randy!) that
>>>the above text isn’t intended to mean “reuse the identical revision
>>>statement, INCLUDING THE REVISION DATE” but to mean “reuse the revision
>>>statement, UPDATING THE REVISION DATE”.
>>>  
>>> Then other people raised other points, e.g only updating the revision
>>>date if the YANG has changed, distinguishing between the document and
>>>the YANG contained therein, and distinguishing between YANG in IDs and
>>>YANG created by other SDOs. My proposed new text tries to address all
>>>of these:
>>>  
>>> NEW:
>>> 
>>> It is not required to keep the full revision history of draft versions
>>>(e.g., modules contained within Internet-Drafts). That is, within a
>>>sequence of draft versions, only the most recent revision need be
>>>recorded in the module. However, if the module has changed, the
>>>revision date of the most recent revision MUST be updated to a later
>>>date whenever a new version is made available (e.g., via a new version
>>>of an Internet-Draft).
>>>  
>>> ——
>>>  
>>> I believe that this retains the original intent in a way that resolves
>>>the original ambiguity and addresses the other points that were raised.
>>>It it’s “worse”, how is it worse (apart from being longer, on which
>>>point mea culpa)?
>>>  
>>> Thanks,
>>> William
>>>  
>>> On 19 Aug 2016, at 15:42, Andy Bierman  wrote:
>>>  
>>> On Fri, Aug 19, 2016 at 7:13 AM, Dale R. Worley 
>>>wrote:
>>> Andy Bierman  writes:
>>> > An Internet-Draft is NOT a means of "publishing" a specification;
>>> 
>>> As I said, that's the theory, but practice is considerably different.
>>>  
>>> Anybody that implements a work-in-progress knows they are taking a risk
>>> on an unstable document.  The guideline already says MUST update
>>> the revision date.
>>>  
>>> Not sure what more you want to guidelines document to do.
>>>  
>>> Dale
>>>  
>>> Andy
>> 
>> ___
>> netmod mailing list
>> netmod@ietf.org
>> https://www.ietf.org/mailman/listinfo/netmod
>
>--
>Ladislav Lhotka, CZ.NIC Labs
>PGP Key ID: E74E8C0C
>
>
>
>
>___
>netmod mailing list
>netmod@ietf.org
>https://www.ietf.org/mailman/listinfo/netmod

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

Re: [netmod] I-D Action: draft-ietf-netmod-schema-mount-03.txt

[Acee Lindem (acee)]

Hi Lada, Martin, 

With respect to the restriction in section 3.1, I think it would be better
to support paths that relative either to the mount point or to the
absolute device root If not, how will we support device list interface
references? 

Thanks,
Acee 

On 10/31/16, 10:13 AM, "netmod on behalf of 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 NETCONF Data Modeling Language of the
>IETF.
>
>Title   : YANG Schema Mount
>Authors : Martin Bjorklund
>  Ladislav Lhotka
>   Filename: draft-ietf-netmod-schema-mount-03.txt
>   Pages   : 24
>   Date: 2016-10-31
>
>Abstract:
>   This document defines a mechanism to combine YANG modules into the
>   schema defined in other YANG modules.
>
>
>The IETF datatracker status page for this draft is:
>https://datatracker.ietf.org/doc/draft-ietf-netmod-schema-mount/
>
>There's also a htmlized version available at:
>https://tools.ietf.org/html/draft-ietf-netmod-schema-mount-03
>
>A diff from the previous version is available at:
>https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-schema-mount-03
>
>
>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/
>
>___
>netmod mailing list
>netmod@ietf.org
>https://www.ietf.org/mailman/listinfo/netmod

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

Re: [netmod] I-D Action: draft-ietf-netmod-schema-mount-03.txt

[Acee Lindem (acee)]

On 11/1/16, 3:51 AM, "Martin Bjorklund"  wrote:

>Hi,
>
>"Acee Lindem (acee)"  wrote:
>> Hi Lada, Martin,
>> 
>> With respect to the restriction in section 3.1, I think it would be
>>better
>> to support paths that relative either to the mount point or to the
>> absolute device root If not, how will we support device list interface
>> references? 
>
>Can you elaborate on the use case a bit?

Let’s say you want to schema mount a model, e.g., ietf-routing, and it has
references to interfaces using the interface-ref from ietf-interfaces (RFC
7223). Is this possible?

Thanks,
Acee 




>
>
>/martin
>
>
>
>> 
>> Thanks,
>> Acee 
>> 
>> On 10/31/16, 10:13 AM, "netmod on behalf of 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 NETCONF Data Modeling Language of the
>> >IETF.
>> >
>> >Title   : YANG Schema Mount
>> >Authors : Martin Bjorklund
>> >  Ladislav Lhotka
>> >Filename: draft-ietf-netmod-schema-mount-03.txt
>> >Pages   : 24
>> >Date: 2016-10-31
>> >
>> >Abstract:
>> >   This document defines a mechanism to combine YANG modules into the
>> >   schema defined in other YANG modules.
>> >
>> >
>> >The IETF datatracker status page for this draft is:
>> >https://datatracker.ietf.org/doc/draft-ietf-netmod-schema-mount/
>> >
>> >There's also a htmlized version available at:
>> >https://tools.ietf.org/html/draft-ietf-netmod-schema-mount-03
>> >
>> >A diff from the previous version is available at:
>> >https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-schema-mount-03
>> >
>> >
>> >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/
>> >
>> >___
>> >netmod mailing list
>> >netmod@ietf.org
>> >https://www.ietf.org/mailman/listinfo/netmod
>> 
>> ___
>> netmod mailing list
>> netmod@ietf.org
>> https://www.ietf.org/mailman/listinfo/netmod
>> 

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

Re: [netmod] I-D Action: draft-ietf-netmod-schema-mount-03.txt

[Acee Lindem (acee)]

On 11/1/16, 7:38 AM, "Ladislav Lhotka"  wrote:

>
>> On 1 Nov 2016, at 12:21, Acee Lindem (acee)  wrote:
>> 
>> 
>> 
>> On 11/1/16, 3:51 AM, "Martin Bjorklund"  wrote:
>> 
>>> Hi,
>>> 
>>> "Acee Lindem (acee)"  wrote:
>>>> Hi Lada, Martin,
>>>> 
>>>> With respect to the restriction in section 3.1, I think it would be
>>>> better
>>>> to support paths that relative either to the mount point or to the
>>>> absolute device root If not, how will we support device list interface
>>>> references? 
>>> 
>>> Can you elaborate on the use case a bit?
>> 
>> Let’s say you want to schema mount a model, e.g., ietf-routing, and it
>>has
>> references to interfaces using the interface-ref from ietf-interfaces
>>(RFC
>> 7223). Is this possible?
>
>It is possible if ietf-interface and ietf-routing are part of the same
>(mounted) schema. If you want to have, e.g., a global list of interfaces
>and refer to it from a mounted schema (routing instance), then it is not
>supported by schema mount - and it could hardly be because modules such
>as ietf-routing do not have the information where they can possibly be
>mounted.
>
>It is probably necessary, as in the logical-devices example, to include
>ietf-interfaces in the mounted schema, and handle the relationship
>between the global and mounted interface list outside the data model.
>
>Ideas how to handle this formally would certainly be appreciated.

I think we need to be able to handle either an absolute path or one
relative to the mount point. I can see how this is going to be difficult
since the models don’t support this today.

Thanks,
Acee 





>
>Lada 
>
>> 
>> Thanks,
>> Acee 
>> 
>> 
>> 
>> 
>>> 
>>> 
>>> /martin
>>> 
>>> 
>>> 
>>>> 
>>>> Thanks,
>>>> Acee 
>>>> 
>>>> On 10/31/16, 10:13 AM, "netmod on behalf of 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 NETCONF Data Modeling Language of
>>>>>the
>>>>> IETF.
>>>>> 
>>>>>   Title   : YANG Schema Mount
>>>>>   Authors : Martin Bjorklund
>>>>> Ladislav Lhotka
>>>>>   Filename: draft-ietf-netmod-schema-mount-03.txt
>>>>>   Pages   : 24
>>>>>   Date: 2016-10-31
>>>>> 
>>>>> Abstract:
>>>>>  This document defines a mechanism to combine YANG modules into the
>>>>>  schema defined in other YANG modules.
>>>>> 
>>>>> 
>>>>> The IETF datatracker status page for this draft is:
>>>>> https://datatracker.ietf.org/doc/draft-ietf-netmod-schema-mount/
>>>>> 
>>>>> There's also a htmlized version available at:
>>>>> https://tools.ietf.org/html/draft-ietf-netmod-schema-mount-03
>>>>> 
>>>>> A diff from the previous version is available at:
>>>>> https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-schema-mount-03
>>>>> 
>>>>> 
>>>>> 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/
>>>>> 
>>>>> ___
>>>>> netmod mailing list
>>>>> netmod@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/netmod
>>>> 
>>>> ___
>>>> netmod mailing list
>>>> netmod@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/netmod
>>>> 
>> 
>> ___
>> netmod mailing list
>> netmod@ietf.org
>> https://www.ietf.org/mailman/listinfo/netmod
>
>--
>Ladislav Lhotka, CZ.NIC Labs
>PGP Key ID: E74E8C0C
>
>
>
>

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

Re: [netmod] Ben Campbell's No Objection on draft-ietf-netmod-routing-cfg-24: (with COMMENT)

[Acee Lindem (acee)]

Hi Ben, 

On 11/1/16, 4:19 PM, "Ben Campbell"  wrote:

>Ben Campbell has entered the following ballot position for
>draft-ietf-netmod-routing-cfg-24: 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-netmod-routing-cfg/
>
>
>
>--
>COMMENT:
>--
>
>Should the reference to 6536. Be normative?

I certainly don’t think so. This is simply an informative reference
describing the NETCONF access control model. The model in the draft is in
no way dependent on this model.

Thanks,
Acee 



>
>

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

Re: [netmod] Ben Campbell's No Objection on draft-ietf-netmod-routing-cfg-24: (with COMMENT)

[Acee Lindem (acee)]

On 11/1/16, 8:23 PM, "Ben Campbell"  wrote:

>On 1 Nov 2016, at 15:55, Acee Lindem (acee) wrote:
>
>> Hi Ben,
>>
>> On 11/1/16, 4:19 PM, "Ben Campbell"  wrote:
>>
>>> Ben Campbell has entered the following ballot position for
>>> draft-ietf-netmod-routing-cfg-24: 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-netmod-routing-cfg/
>>>
>>>
>>>
>>> --
>>> COMMENT:
>>> --
>>>
>>> Should the reference to 6536. Be normative?
>>
>> I certainly don’t think so. This is simply an informative reference
>> describing the NETCONF access control model. The model in the draft is
>> in
>> no way dependent on this model.
>
>I can't call myself a NETCONF expert--but if you use the model in this
>draft over NETCONF, are there other access control models one might
>realistically use? (Noting that NETCONF itself is a normative
>reference.)

NETCONF probably should not be - I’ll confer with my co-author. Note that
NETCONF and NETCONF ACM are normative references in RFC 7223.

Thanks,
Acee 


>
>Ben.
>

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

Re: [netmod] Ben Campbell's No Objection on draft-ietf-netmod-routing-cfg-24: (with COMMENT)

[Acee Lindem (acee)]

On 11/2/16, 3:52 AM, "Ladislav Lhotka"  wrote:

>
>> On 2 Nov 2016, at 01:45, Acee Lindem (acee)  wrote:
>> 
>> 
>> 
>> On 11/1/16, 8:23 PM, "Ben Campbell"  wrote:
>> 
>>> On 1 Nov 2016, at 15:55, Acee Lindem (acee) wrote:
>>> 
>>>> Hi Ben,
>>>> 
>>>> On 11/1/16, 4:19 PM, "Ben Campbell"  wrote:
>>>> 
>>>>> Ben Campbell has entered the following ballot position for
>>>>> draft-ietf-netmod-routing-cfg-24: 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-netmod-routing-cfg/
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>>--
>>>>> COMMENT:
>>>>> 
>>>>>--
>>>>> 
>>>>> Should the reference to 6536. Be normative?
>>>> 
>>>> I certainly don’t think so. This is simply an informative reference
>>>> describing the NETCONF access control model. The model in the draft is
>>>> in
>>>> no way dependent on this model.
>>> 
>>> I can't call myself a NETCONF expert--but if you use the model in this
>>> draft over NETCONF, are there other access control models one might
>>> realistically use? (Noting that NETCONF itself is a normative
>>> reference.)
>> 
>> NETCONF probably should not be - I’ll confer with my co-author. Note
>>that
>> NETCONF and NETCONF ACM are normative references in RFC 7223.
>
>You probably meant "are not normative references", which is the case in
>RFC 7223. It makes sense to keep it this way for data modelling work -
>securing access to data is a protocol issue. Simple implementations may
>not need the granularity of NACM, and can instead allow access only to a
>"root" user.

Yes - that’s what I meant. I’d vote to make them both informative as in
RFC 7223 - especially with the trend to use YANG with different transport
protocols. 

Thanks,
Acee


>
>Lada
>
>> 
>> Thanks,
>> Acee 
>> 
>> 
>>> 
>>> Ben.
>>> 
>> 
>> ___
>> netmod mailing list
>> netmod@ietf.org
>> https://www.ietf.org/mailman/listinfo/netmod
>
>--
>Ladislav Lhotka, CZ.NIC Labs
>PGP Key ID: E74E8C0C
>
>
>
>

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

Re: [netmod] Stephen Farrell's No Objection on draft-ietf-netmod-routing-cfg-24: (with COMMENT)

[Acee Lindem (acee)]

Hi Stephen, 

On 11/2/16, 10:14 AM, "Stephen Farrell"  wrote:

>
>
>On 02/11/16 14:04, Ladislav Lhotka wrote:
>> 
>>> On 2 Nov 2016, at 11:53, Stephen Farrell
>>>  wrote:
>>> 
>>> Stephen Farrell has entered the following ballot position for
>>> draft-ietf-netmod-routing-cfg-24: 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-netmod-routing-cfg/
>>> 
>>> 
>>> 
>>> --
>>>
>>> 
>COMMENT:
>>> --
>>>
>>>
>>>
>>> 
>If there exists a draft for a yang module that augments this
>>> in a way that includes cryptographic values (e.g. maybe for an
>>> IPsec VPN or something) then I think that'd be a nice addition to
>>> section 11 as an informative reference.
>> 
>> One such module is ietf-key-chain by Acee et al. [1] Would it make
>> sense to include an informative reference to it?
>
>Not sure, but I think maybe not. Acee's draft doesn't
>seem to augment the modules defined in this one which
>is what I thought might provide useful information.

I believe the augmentation you are looking for exists yet.

Thanks,
Acee 





>
>S.
>
>> 
>> Lada
>> 
>> [1] https://tools.ietf.org/html/draft-ietf-rtgwg-yang-key-chain-10
>> 
>>> 
>>> 
>> 
>> -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C
>> 
>> 
>> 
>> 
>

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

Re: [netmod] RFC 8022 on A YANG Data Model for Routing Management

[Acee Lindem (acee)]

On 11/10/16, 2:46 AM, "netmod on behalf of Ladislav Lhotka"
 wrote:

>
>> On 10 Nov 2016, at 07:06, Dean Bogdanovic  wrote:
>> 
>> Congrats Lada!
>> 
>> This was a great marathon to pull of with Acee coming down the road and
>>helping out.
>> 
>> Again, congrats to both of you
>
>Thank you, this one really calls for a drink. :-)

It may take more than one to reach consensus…
Acee 

>
>Cheers, Lada
>
>> 
>> Dean
>> 
>>> On Nov 9, 2016, at 11:18 PM, rfc-edi...@rfc-editor.org wrote:
>>> 
>>> A new Request for Comments is now available in online RFC libraries.
>>> 
>>> 
>>>   RFC 8022
>>> 
>>>   Title:  A YANG Data Model for
>>>   Routing Management
>>>   Author: L. Lhotka, A. Lindem
>>>   Status: Standards Track
>>>   Stream: IETF
>>>   Date:   November 2016
>>>   Mailbox:lho...@nic.cz,
>>>   a...@cisco.com
>>>   Pages:  64
>>>   Characters: 115083
>>>   Updates/Obsoletes/SeeAlso:   None
>>> 
>>>   I-D Tag:draft-ietf-netmod-routing-cfg-25.txt
>>> 
>>>   URL:https://www.rfc-editor.org/info/rfc8022
>>> 
>>>   DOI:http://dx.doi.org/10.17487/RFC8022
>>> 
>>> This document contains a specification of three YANG modules and one
>>> submodule.  Together they form the core routing data model that
>>> serves as a framework for configuring and managing a routing
>>> subsystem.  It is expected that these modules will be augmented by
>>> additional YANG modules defining data models for control-plane
>>> protocols, route filters, and other functions.  The core routing data
>>> model provides common building blocks for such extensions -- routes,
>>> Routing Information Bases (RIBs), and control-plane protocols.
>>> 
>>> This document is a product of the NETCONF Data Modeling Language
>>>Working Group of the IETF.
>>> 
>>> This is now a Proposed Standard.
>>> 
>>> STANDARDS TRACK: This document specifies an Internet Standards Track
>>> protocol for the Internet community, and requests discussion and
>>>suggestions
>>> for improvements.  Please refer to the current edition of the Official
>>> Internet Protocol Standards (https://www.rfc-editor.org/standards) for
>>>the 
>>> standardization state and status of this protocol.  Distribution of
>>>this 
>>> memo is unlimited.
>>> 
>>> This announcement is sent to the IETF-Announce and rfc-dist lists.
>>> To subscribe or unsubscribe, see
>>> https://www.ietf.org/mailman/listinfo/ietf-announce
>>> https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist
>>> 
>>> For searching the RFC series, see https://www.rfc-editor.org/search
>>> For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk
>>> 
>>> Requests for special distribution should be addressed to either the
>>> author of the RFC in question, or to rfc-edi...@rfc-editor.org.  Unless
>>> specifically noted otherwise on the RFC itself, all RFCs are for
>>> unlimited distribution.
>>> 
>>> 
>>> The RFC Editor Team
>>> Association Management Solutions, LLC
>>> 
>>> 
>>> ___
>>> netmod mailing list
>>> netmod@ietf.org
>>> https://www.ietf.org/mailman/listinfo/netmod
>> 
>> ___
>> netmod mailing list
>> netmod@ietf.org
>> https://www.ietf.org/mailman/listinfo/netmod
>
>--
>Ladislav Lhotka, CZ.NIC Labs
>PGP Key ID: E74E8C0C
>
>
>
>
>___
>netmod mailing list
>netmod@ietf.org
>https://www.ietf.org/mailman/listinfo/netmod

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

Re: [netmod] WG Last Call for draft-ietf-netmod-acl-model-09 (until Oct 27, 2016)

[Acee Lindem (acee)]

Hi Dean,
If you make this a list of heterogeneous IPv4 header fields, how will you 
constrain specification to only one field of each type? For example, one source 
address? Existing implementations do not support multiples and generate all 
permutations (given multiple specifications of each field) could be complex.
Thanks,
Acee


From: netmod mailto:netmod-boun...@ietf.org>> on 
behalf of Dean Bogdanovic mailto:ivand...@gmail.com>>
Date: Tuesday, November 15, 2016 at 10:06 AM
To: Kent Watsen mailto:kwat...@juniper.net>>
Cc: "netmod@ietf.org" 
mailto:netmod@ietf.org>>
Subject: Re: [netmod] WG Last Call for draft-ietf-netmod-acl-model-09 (until 
Oct 27, 2016)

I have something that might delay WGLC, but found out an optimization which 
would help in the future

In ietf-packet-fields.yang, example below

grouping acl-ipv4-header-fields {
   description
 "Fields in IPv4 header.";
   leaf destination-ipv4-network {
 type inet:ipv4-prefix;
 description
   "Destination IPv4 address prefix.";
   }
   leaf source-ipv4-network {
 type inet:ipv4-prefix;
 description
   "Source IPv4 address prefix.";
   }
 }

Instead of using "leaf" for "destination-ipv4-network" and 
"source-ipv4-network", "leaf-list" reduces the number of terms/ace needed.

If we would agree with this change, then would propose one more

for mac-addresses, having the mask under the address itself look better in the 
data itself:

  
01:01:01:00:00:00
ff:ff:ff:00:00:00
  

  Or create a new type 'mac-address-prefix'.

  This allows having matching multiple destinations to 1 source, or multiple 
sources to 1 destination, if they cannot be easily combined into 1 entry.

  
01:01:01:00:00:00
ff:ff:ff:00:00:00
  
  
01:04:01:00:00:00
ff:ff:ff:00:00:00
  
  

  
On Nov 14, 2016, at 7:35 AM, Dean Bogdanovic 
mailto:ivand...@gmail.com>> wrote:

Kent,

Thank you for the answer
On Nov 13, 2016, at 1:20 PM, Kent Watsen 
mailto:kwat...@juniper.net>> wrote:

Hi Dean,

> Don’t understand your question. What is the difference between system and 
> user generated acls?

User-generated would be, for instance, configured via NETCONF or RESTCONF, 
whereas system-generated would be ACLs that get created by default.  For 
example, RFC 7223 has the top-level /interfaces-state to support 
system-generated interfaces (e.g., lo) so, when running `shows interfaces`, the 
result includes both configured and system-generated interfaces.   Makes sense?

I understand now what you meant. Where I can see for the interfaces the use 
case you describe (for loopback and physical interfaces), for ACLs have much 
harder time to find an example use case where a system would generate an ACL. 
Maybe for a highly secure system would generate an ACL to deny all traffic to 
and from, except to access it via console when it comes up. Can you come with 
some other use cases? If we can find viable use cases, then yes, would say that 
reporting opstate for system generated ACLs is useful.

Dean


Thanks,
Kent

From: Dean Bogdanovic mailto:ivand...@gmail.com>>
Date: Friday, November 11, 2016 at 3:45 PM
To: Kent Watsen mailto:kwat...@juniper.net>>
Cc: "netmod@ietf.org" 
mailto:netmod@ietf.org>>
Subject: Re: [netmod] WG Last Call for draft-ietf-netmod-acl-model-09 (until 
Oct 27, 2016)


On Oct 29, 2016, at 4:01 AM, Kent Watsen 
mailto:kwat...@juniper.net>> wrote:

The last call period for this draft has ended.   Thank you to all that 
responded.  Given the responses received, my co-chair and I believe that the 
draft is ready to move forward.  I will begin the shepherd write-up shortly.
In parallel, prompted by a conversation I had this morning, I’m wondering about 
the YANG module’s use of the config false nodes ‘acl-oper-data’ and 
‘ace-oper-data’.  In particular, are the lifetimes of these nodes always the 
same as the configured nodes?

Yes, they are. When the nodes are created, they are don’t have to be attached 
to an another object, like interface or RIB, etc, but they get operational 
state. Once attached, (to continue with the example) operational status of 
counters is changing. When detached from the interface, the last know counter 
is kept, until the ace is deleted. Same is for acl-oper-data.

- is there any need to support reporting opstate for system-generated acts?

Don’t understand your question. What is the difference between system and user 
generated acls?

Dean


Thanks,
Kent (as shepherd)


From: netmod mailto:netmod-boun...@ietf.org>> on 
behalf of Kent Watsen mailto:kwat...@juniper.net>>
Date: Thursday, October 13, 2016 at 5:05 PM
To: "netmod@ietf.org" 
mailto:netmod@ietf.org>>
Subject: [netmod] WG Last Call for draft-ietf-netmod-acl-model-09 (until Oct 
27, 2016)


This is a notice to start a two-week NETMOD WG last call for the document:

   Network Access Control List (ACL) YANG Data Model
   https://tools.ietf.org/

Re: [netmod] WG Last Call for draft-ietf-netmod-acl-model-09 (until Oct 27, 2016)

[Acee Lindem (acee)]

Hi David,

From: David Bannister mailto:d...@netflix.com>>
Date: Wednesday, November 23, 2016 at 12:28 PM
To: Kent Watsen mailto:kwat...@juniper.net>>
Cc: Eliot Lear mailto:l...@cisco.com>>, Acee Lindem 
mailto:a...@cisco.com>>, Dean Bogdanovic 
mailto:ivand...@gmail.com>>, 
"netmod@ietf.org" 
mailto:netmod@ietf.org>>
Subject: Re: [netmod] WG Last Call for draft-ietf-netmod-acl-model-09 (until 
Oct 27, 2016)

Here are my issues with the ACL draft as it stands today from a high level, vs. 
calling out every missing field.

Although I'm not an author of this YANG model, I'm the author of others and I 
can say from experience that it would be infinitely more productive for you to 
list the specific fields and corresponding use cases as opposed to a subjective 
high-level critique. That way, these can be incorporated or, at least, we can 
have the discussion as whether or not they belong in the base model.

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

Re: [netmod] WG Last Call for draft-ietf-netmod-acl-model-09 (until Oct 27, 2016)

[Acee Lindem (acee)]

If you could just point out the general features you are using in your configs 
that are not present in the base model. I know you mentioned TCP options 
matching. With respect to the augmentations, they don't have to be vendor 
specific. Some advanced ACL functions such as conditional ACLs could be 
provided in standard model augmentations in future modules.

Thanks,
Acee

From: David Bannister mailto:d...@netflix.com>>
Date: Wednesday, November 23, 2016 at 1:54 PM
To: Acee Lindem mailto:a...@cisco.com>>
Cc: Kent Watsen mailto:kwat...@juniper.net>>, Eliot Lear 
mailto:l...@cisco.com>>, Dean Bogdanovic 
mailto:ivand...@gmail.com>>, 
"netmod@ietf.org<mailto:netmod@ietf.org>" 
mailto:netmod@ietf.org>>
Subject: Re: [netmod] WG Last Call for draft-ietf-netmod-acl-model-09 (until 
Oct 27, 2016)

I'm open to the idea given ample time.

On Wed, Nov 23, 2016 at 12:53 PM, Acee Lindem (acee) 
mailto:a...@cisco.com>> wrote:
Hi David,

From: David Bannister mailto:d...@netflix.com>>
Date: Wednesday, November 23, 2016 at 12:28 PM
To: Kent Watsen mailto:kwat...@juniper.net>>
Cc: Eliot Lear mailto:l...@cisco.com>>, Acee Lindem 
mailto:a...@cisco.com>>, Dean Bogdanovic 
mailto:ivand...@gmail.com>>, 
"netmod@ietf.org<mailto:netmod@ietf.org>" 
mailto:netmod@ietf.org>>
Subject: Re: [netmod] WG Last Call for draft-ietf-netmod-acl-model-09 (until 
Oct 27, 2016)

Here are my issues with the ACL draft as it stands today from a high level, vs. 
calling out every missing field.

Although I'm not an author of this YANG model, I'm the author of others and I 
can say from experience that it would be infinitely more productive for you to 
list the specific fields and corresponding use cases as opposed to a subjective 
high-level critique. That way, these can be incorporated or, at least, we can 
have the discussion as whether or not they belong in the base model.

Thanks,
Acee

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

Re: [netmod] I-D Action: draft-han-netmod-intf-ext-ppp-yang-00.txt

[Acee Lindem (acee)]

Hi Hansance, 

I believe this is the right place since other RFC 7223 augmentations are
here. 
Thanks,
Acee

On 11/24/16, 3:11 AM, "netmod on behalf of Hansance Han"
 wrote:

>Hi Lou and Kent,
>
>I submitted a YANG draft about PPP feature, while PPP WG is concluded for
>a long time, I didn't know whether this PPP draft could be discussed in
>netmod WG. Would netmod WG be like to adopt it?
>
>BR
>Hansance Han
>
>-Original Message-
>From: t.petch [mailto:ie...@btconnect.com]
>Sent: Tuesday, November 22, 2016 5:40 PM
>To: Hansance Han 
>Cc: Hua Lv ; James Zhang Q
>
>Subject: Re: I-D Action: draft-han-netmod-intf-ext-ppp-yang-00.txt
>
>Hi
>
>It is up to the chairs of the netmod group.
>
>If they consider that it falls within the charter of the WG, then they
>can ask the WG if there is interest in adopting the I-D as a WG item, and
>if enough people say yes, then it becomes a WG item and discussion can
>happen on the netmod list.
>
>So, I would suggest an e-mail, perhaps on the netmod list, to the chairs,
>copying the announcement, saying that you have produced this and would
>netmod WG be willing to adopt it.
>
>I note that there are a number of changes that will be needed, hence my
>question about where it might be discussed.  I prefer posting to a list
>so that others can agree or disagree with me, as opposed to off-list
>discussions about needed changes.
>
>Tom Petch
>
>- Original Message -
>From: "Hansance Han" 
>To: "t.petch" 
>Cc: "Hua Lv" ; "James Zhang Q"
>
>Sent: Monday, November 21, 2016 2:36 AM
>
>Hi there,
>
>We have checked the ppp is concluded group. How to active this group? If
>we cannot active this group, so I claim that this draft is under netmod
>group, is that ok?
>
>BR
>Hansance Han
>
>ppp Point-to-Point Protocol 1988-03 1989-11
>
>-Original Message-
>From: t.petch [mailto:ie...@btconnect.com]
>Sent: Friday, November 18, 2016 7:36 PM
>To: Hansance Han 
>Cc: Hua Lv ; James Zhang Q
>
>Subject: Re: I-D Action: draft-han-netmod-intf-ext-ppp-yang-00.txt
>
>Do you have a wg in mind where this I-D will be discussed/
>
>Tom Petch
>
>
>- Original Message -
>From: 
>To: 
>Sent: Friday, November 18, 2016 8:58 AM
>
>> A New Internet-Draft is available from the on-line Internet-Drafts
>directories.
>>
>>
>> Title   : Yang Data Model for PPP Protocol
>> Authors : Hansance Han
>>   Hua Lv
>>   James Zhang
>> Filename: draft-han-netmod-intf-ext-ppp-yang-00.txt
>> Pages   : 8
>> Date: 2016-11-18
>>
>> Abstract:
>>This document defines a YANG data model that can be used to
>> configure and manage PPP.
>>
>>
>> The IETF datatracker status page for this draft is:
>> https://datatracker.ietf.org/doc/draft-han-netmod-intf-ext-ppp-yang/
>>
>> There's also a htmlized version available at:
>> https://tools.ietf.org/html/draft-han-netmod-intf-ext-ppp-yang-00
>>
>>
>> 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/
>>
>> ___
>> I-D-Announce mailing list
>> i-d-annou...@ietf.org
>> https://www.ietf.org/mailman/listinfo/i-d-announce
>> Internet-Draft directories: http://www.ietf.org/shadow.html or
>> ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>
>___
>netmod mailing list
>netmod@ietf.org
>https://www.ietf.org/mailman/listinfo/netmod

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

[netmod] Key Strings in ietf-key-chain operational state

[Acee Lindem (acee)]

In the days of MIBs, we used to omit key strings from the data that would be 
returned. This was ostensibly done for security purposes. We did the same for 
the operational state returned for keystring in key-chain-entries. I'm now 
thinking this was a mistake. Rather, it would seem that one could use RFC 6536 
rules to accomplish this at a more granular level.

Note that the model also support keystring encryption as described in RFC 5649.

Thanks,
Acee

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

Re: [netmod] Key Strings in ietf-key-chain operational state

[Acee Lindem (acee)]

Hi Mahesh,

From: Mahesh Jethanandani 
mailto:mjethanand...@gmail.com>>
Date: Wednesday, November 30, 2016 at 5:25 PM
To: Acee Lindem mailto:a...@cisco.com>>
Cc: "netmod@ietf.org<mailto:netmod@ietf.org>" 
mailto:netmod@ietf.org>>
Subject: Re: [netmod] Key Strings in ietf-key-chain operational state

Acee,

This is something we ran into with ietf-keystore model also. The thoughts are 
that key strings should never leave the device. If anything most devices have 
tamper proof capability (FIPS 140-2) to wipe the keys out if tampered with or 
exported. So exporting the string, encrypted, even with NACM would defy that.

So, what we have today would with the key strings omitted from the operational 
state would be consistent with the direction for the ietf-keystore model. 
Correct?

How will this be enforced when we have an applied-config datastore?

Thanks,
Acee






On Nov 30, 2016, at 1:37 PM, Acee Lindem (acee) 
mailto:a...@cisco.com>> wrote:

In the days of MIBs, we used to omit key strings from the data that would be 
returned. This was ostensibly done for security purposes. We did the same for 
the operational state returned for keystring in key-chain-entries. I'm now 
thinking this was a mistake. Rather, it would seem that one could use RFC 6536 
rules to accomplish this at a more granular level.

Note that the model also support keystring encryption as described in RFC 5649.

Thanks,
Acee

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

Mahesh Jethanandani
mjethanand...@gmail.com<mailto:mjethanand...@gmail.com>



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

Re: [netmod] Key Strings in ietf-key-chain operational state

[Acee Lindem (acee)]

On 12/1/16, 3:20 AM, "Juergen Schoenwaelder"
 wrote:

>On Wed, Nov 30, 2016 at 09:37:21PM +, Acee Lindem (acee) wrote:
>
>> In the days of MIBs, we used to omit key strings from the data that
>>would be returned. This was ostensibly done for security purposes.
>
>This is not correct. In SMIv2, INDEX objects are not accessible
>because the values of these objects are embedded in the instance
>identifier. In other words, making INDEX objects not-accessible was a
>performance optimization, forcing SNMP managers to extract the INDEX
>object values out of the instance identifiers. Making INDEX objects
>not accessible does _not_ hide any information.

This is a different issue. What I am referring to is never returning the
keys in a read request (get, get-next, get-many, etc). For example,
(excerpted from RFC 4750):

 ospfIfAuthKey OBJECT-TYPE
   SYNTAX   OCTET STRING (SIZE (0..256))
   MAX-ACCESS   read-create
   STATUS   current
  DESCRIPTION
  "The cleartext password used as an OSPF
  authentication key when simplePassword security
  is enabled.  This object does not access any OSPF
  cryptogaphic (e.g., MD5) authentication key under
  any circumstance.

  If the key length is shorter than 8 octets, the
  agent will left adjust and zero fill to 8 octets.

  Unauthenticated interfaces need no authentication
  key, and simple password authentication cannot use
  a key of more than 8 octets.

  Note that the use of simplePassword authentication
  is NOT recommended when there is concern regarding
  attack upon the OSPF system.  SimplePassword
  authentication is only sufficient to protect against
  accidental misconfigurations because it re-uses
  cleartext passwords [RFC1704].

  When read, ospfIfAuthKey always returns an octet
  string of length zero."
   REFERENCE
  "OSPF Version 2, Section 9 The Interface Data
  Structure"
   DEFVAL { ''H } -- 0.0.0.0.0.0.0.0
   ::= { ospfIfEntry 16 }



Thanks,
Acee 





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

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

Re: [netmod] WG adoption poll draft-nmdsdt-netmod-revised-datastores-00

[Acee Lindem (acee)]

Yes/Support

On 12/2/16, 4:26 PM, "netmod on behalf of Lou Berger"
 wrote:

>All,
>
>This is start of a two week poll on making
>draft-nmdsdt-netmod-revised-datastores-00 a NetMod working group
>document.  This document is unusual in that WG last call will be jointly
>held in both the NetConf and NetMod WGs, while adoption and day-to-day
>processing
>will take place in NetMod.
>
>Please send email to the list indicating "yes/support" or "no/do not
>support".  If indicating no, please state your reservations with the
>document.  If yes, please also feel free to provide comments you'd like
>to see addressed once the document is a WG document.
>
>The poll ends December 16.
>
>Thank you,
>NetConf and NetMod WG Chairs
>
>___
>netmod mailing list
>netmod@ietf.org
>https://www.ietf.org/mailman/listinfo/netmod

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

Re: [netmod] Key Strings in ietf-key-chain operational state

[Acee Lindem (acee)]

Hi Kent, 
So are you suggesting the nacm:default-deny-all for key strings rather
than omitting it from the operational state?
Thanks,
Acee 

On 12/2/16, 3:15 PM, "Kent Watsen"  wrote:

>Hi Acee,
>
>Sorry for being late to this thread.  As Mehesh mentioned, this aspect of
>the keystore mode is currently open, and being tracked by github issue
>#2.  
>
>It is my understanding that the working group would like to pursue a
>strategy that supports backup/restore operations to the greatest extent
>possible.  
>
>In order to prevent unauthorized access, NACM rules can be used to mark
>the private key data leaf (not its parent list entry) with
>³nacm:default-deny-all².
>
>In order to support hardware protected keys, the private key data leaf
>can be marked as mandatory false, with the explanation that, if not
>returned, it might be because the key is protected by hardware.
>
>Not stated yet, but the thinking is that the private key data leaf would
>be config true, to support the backup/restore case of the NC/RC client
>passing the private to the device  (open issue: how to direct specialized
>hardware to generate a new protected key).  Pertinently, for the
>applied/operational-state datastores, the NACM and mandatory attributes
>carry over, so still the key is protected from unauthorized access and
>still the solution supports hardware protected keys.
>
>What do you think?
>
>Kent
>  
>
>
>On 12/1/16, 11:28 AM, "netmod on behalf of Juergen Schoenwaelder"
>j.schoenwael...@jacobs-university.de> wrote:
>
>OK. I misread your statement. Sorry for the noise.
>
>/js
>
>On Thu, Dec 01, 2016 at 01:35:15PM +, Acee Lindem (acee) wrote:
>> 
>> 
>> On 12/1/16, 3:20 AM, "Juergen Schoenwaelder"
>>  wrote:
>> 
>> >On Wed, Nov 30, 2016 at 09:37:21PM +, Acee Lindem (acee) wrote:
>> >
>> >> In the days of MIBs, we used to omit key strings from the data that
>> >>would be returned. This was ostensibly done for security purposes.
>> >
>> >This is not correct. In SMIv2, INDEX objects are not accessible
>> >because the values of these objects are embedded in the instance
>> >identifier. In other words, making INDEX objects not-accessible was a
>> >performance optimization, forcing SNMP managers to extract the INDEX
>> >object values out of the instance identifiers. Making INDEX objects
>> >not accessible does _not_ hide any information.
>> 
>> This is a different issue. What I am referring to is never returning the
>> keys in a read request (get, get-next, get-many, etc). For example,
>> (excerpted from RFC 4750):
>> 
>>  ospfIfAuthKey OBJECT-TYPE
>>SYNTAX   OCTET STRING (SIZE (0..256))
>>MAX-ACCESS   read-create
>>STATUS   current
>>   DESCRIPTION
>>   "The cleartext password used as an OSPF
>>   authentication key when simplePassword security
>>   is enabled.  This object does not access any OSPF
>>   cryptogaphic (e.g., MD5) authentication key under
>>   any circumstance.
>> 
>>   If the key length is shorter than 8 octets, the
>>   agent will left adjust and zero fill to 8 octets.
>> 
>>   Unauthenticated interfaces need no authentication
>>   key, and simple password authentication cannot use
>>   a key of more than 8 octets.
>> 
>>   Note that the use of simplePassword authentication
>>   is NOT recommended when there is concern regarding
>>   attack upon the OSPF system.  SimplePassword
>>   authentication is only sufficient to protect against
>>   accidental misconfigurations because it re-uses
>>   cleartext passwords [RFC1704].
>> 
>>   When read, ospfIfAuthKey always returns an octet
>>   string of length zero."
>>REFERENCE
>>   "OSPF Version 2, Section 9 The Interface Data
>>   Structure"
>>DEFVAL { ''H } -- 0.0.0.0.0.0.0.0
>>::= { ospfIfEntry 16 }
>> 
>> 
>> 
>> Thanks,
>> Acee 
>> 
>> 
>> 
>> 
>> 
>> >
>> >/js
>> >
>> >-- 
>> >Juergen Schoenwaelder   Jacobs University Bremen gGmbH
>> >Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
>> >Fax:   +49 421 200 3103 <http://www.jacobs-university.de/>
>> 
>
>-- 
>Juergen Schoenwaelder   Jacobs University Bremen gGmbH
>Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
>Fax:   +49 421 200 3103 <http://www.jacobs-university.de/>
>
>___
>netmod mailing list
>netmod@ietf.org
>https://www.ietf.org/mailman/listinfo/netmod
>
>

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

Re: [netmod] Key Strings in ietf-key-chain operational state

[Acee Lindem (acee)]

For key-chains, we do want to allow creation of entries complete with the
key-string. Otherwise, the model would not be of much use…. How would one
code this in the YANG model? RFC 6536 is lacking of any examples.
Thanks,
Acee 

On 12/5/16, 6:24 PM, "Kent Watsen"  wrote:

>
>Exactly, with access-control, less privileged clients would never obtain
>the private key data, even when reading operational state.
>
>I don’t think this has been discussed on list yet so, to be clear, I’m
>saying that NACM annotations MUST be enforced for all the new datastores
>in the revised datastore proposal.
>
>K.
>
>
>On 12/2/16, 7:45 PM, "Acee Lindem (acee)"  wrote:
>
>Hi Kent, 
>So are you suggesting the nacm:default-deny-all for key strings rather
>than omitting it from the operational state?
>Thanks,
>Acee 
>
>On 12/2/16, 3:15 PM, "Kent Watsen"  wrote:
>
>>Hi Acee,
>>
>>Sorry for being late to this thread.  As Mehesh mentioned, this aspect of
>>the keystore mode is currently open, and being tracked by github issue
>>#2.  
>>
>>It is my understanding that the working group would like to pursue a
>>strategy that supports backup/restore operations to the greatest extent
>>possible.  
>>
>>In order to prevent unauthorized access, NACM rules can be used to mark
>>the private key data leaf (not its parent list entry) with
>>³nacm:default-deny-all².
>>
>>In order to support hardware protected keys, the private key data leaf
>>can be marked as mandatory false, with the explanation that, if not
>>returned, it might be because the key is protected by hardware.
>>
>>Not stated yet, but the thinking is that the private key data leaf would
>>be config true, to support the backup/restore case of the NC/RC client
>>passing the private to the device  (open issue: how to direct specialized
>>hardware to generate a new protected key).  Pertinently, for the
>>applied/operational-state datastores, the NACM and mandatory attributes
>>carry over, so still the key is protected from unauthorized access and
>>still the solution supports hardware protected keys.
>>
>>What do you think?
>>
>>Kent
>>  
>>
>>
>>On 12/1/16, 11:28 AM, "netmod on behalf of Juergen Schoenwaelder"
>>>j.schoenwael...@jacobs-university.de> wrote:
>>
>>OK. I misread your statement. Sorry for the noise.
>>
>>/js
>>
>>On Thu, Dec 01, 2016 at 01:35:15PM +, Acee Lindem (acee) wrote:
>>> 
>>> 
>>> On 12/1/16, 3:20 AM, "Juergen Schoenwaelder"
>>>  wrote:
>>> 
>>> >On Wed, Nov 30, 2016 at 09:37:21PM +, Acee Lindem (acee) wrote:
>>> >
>>> >> In the days of MIBs, we used to omit key strings from the data that
>>> >>would be returned. This was ostensibly done for security purposes.
>>> >
>>> >This is not correct. In SMIv2, INDEX objects are not accessible
>>> >because the values of these objects are embedded in the instance
>>> >identifier. In other words, making INDEX objects not-accessible was a
>>> >performance optimization, forcing SNMP managers to extract the INDEX
>>> >object values out of the instance identifiers. Making INDEX objects
>>> >not accessible does _not_ hide any information.
>>> 
>>> This is a different issue. What I am referring to is never returning
>>>the
>>> keys in a read request (get, get-next, get-many, etc). For example,
>>> (excerpted from RFC 4750):
>>> 
>>>  ospfIfAuthKey OBJECT-TYPE
>>>SYNTAX   OCTET STRING (SIZE (0..256))
>>>MAX-ACCESS   read-create
>>>STATUS   current
>>>   DESCRIPTION
>>>   "The cleartext password used as an OSPF
>>>   authentication key when simplePassword security
>>>   is enabled.  This object does not access any OSPF
>>>   cryptogaphic (e.g., MD5) authentication key under
>>>   any circumstance.
>>> 
>>>   If the key length is shorter than 8 octets, the
>>>   agent will left adjust and zero fill to 8 octets.
>>> 
>>>   Unauthenticated interfaces need no authentication
>>>   key, and simple password authentication cannot use
>>>   a key of more than 8 octets.
>>> 
>>>   Note that the use of simplePassword authentication
>>>   is NOT recommended when there is concern regarding
>>>   attack upon the OSPF system

Re: [netmod] Key Strings in ietf-key-chain operational state

[Acee Lindem (acee)]

Ok - I've looked at this from a different angle and I now think we should use 
NACM to limit access to the strings by default. It doesn't make sense to 
address read access without addressing read and create access.

Thanks,
Acee

BTW, I always though the OSPF MIB decision to simply omit the string was 
somewhat lame. However, write wasn't a factor since most implementations didn't 
support MIB variable update.

From: rtgwg mailto:rtgwg-boun...@ietf.org>> on behalf 
of Acee Lindem mailto:a...@cisco.com>>
Date: Friday, December 2, 2016 at 12:07 PM
To: Routing WG mailto:rt...@ietf.org>>
Subject: FW: [netmod] Key Strings in ietf-key-chain operational state

Note that omitting the keystring data node from the operational state in 
ietf-key-chain is consistent with what the approach in the NETMOD ietf-keystore 
model.

Thanks,
Acee

From: Mahesh Jethanandani 
mailto:mjethanand...@gmail.com>>
Date: Wednesday, November 30, 2016 at 9:36 PM
To: Acee Lindem mailto:a...@cisco.com>>
Cc: "netmod@ietf.org<mailto:netmod@ietf.org>" 
mailto:netmod@ietf.org>>
Subject: Re: [netmod] Key Strings in ietf-key-chain operational state


On Nov 30, 2016, at 2:33 PM, Acee Lindem (acee) 
mailto:a...@cisco.com>> wrote:


This is something we ran into with ietf-keystore model also. The thoughts are 
that key strings should never leave the device. If anything most devices have 
tamper proof capability (FIPS 140-2) to wipe the keys out if tampered with or 
exported. So exporting the string, encrypted, even with NACM would defy that.

So, what we have today would with the key strings omitted from the operational 
state would be consistent with the direction for the ietf-keystore model. 
Correct?

That is correct. Kent can correct me, but we are still trying to figure how to 
model it in YANG and in the datastores ( and ).


How will this be enforced when we have an applied-config datastore?

Thanks,
Acee






On Nov 30, 2016, at 1:37 PM, Acee Lindem (acee) 
mailto:a...@cisco.com>> wrote:

In the days of MIBs, we used to omit key strings from the data that would be 
returned. This was ostensibly done for security purposes. We did the same for 
the operational state returned for keystring in key-chain-entries. I'm now 
thinking this was a mistake. Rather, it would seem that one could use RFC 6536 
rules to accomplish this at a more granular level.

Note that the model also support keystring encryption as described in RFC 5649.

Thanks,
Acee

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

Mahesh Jethanandani
mjethanand...@gmail.com<mailto:mjethanand...@gmail.com>




Mahesh Jethanandani
mjethanand...@gmail.com<mailto:mjethanand...@gmail.com>



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