Re: [netmod] YANG coordination feedback on draft-openconfig-netmod-opstate-01
Sam Aldrin wrote: > > > On Sep 10, 2015, at 4:13 PM, Mahesh Jethanandani > > wrote: > > > > > >> On Sep 10, 2015, at 12:43 PM, Carl Moberg (camoberg) > >> mailto:camob...@cisco.com>> wrote: > >> > >> Now, think about configuration parameters that have applied > >> configuration located in more than one place. Let’s say you change the > >> IP address of an interface, it is likely that this configuration will > >> be passed around as input to a handful of subsystems (e.g. the DHCP > >> server, some routing daemons that may bind to specific IP > >> addresses). Is the intended and applied in sync when a specific subset > >> of those configurations are updated. What happens if there’s a partial > >> failure? > > > > This is a good example. Another example, and somebody on the call > > today started to ask this but got cut off, relates to interfaces on > > the device. > > > > Interfaces already exist on a system. As such they have a > > configuration (default values) that exists on them. They are enabled > > when configuration gets applied on them. They will have applied > > configuration but no intended configuration. Should this be reported? > > > > Yet another example is of a BFD session that gets bootstrapped because > > of a ping. There is no intended configuration, but the session exists > > and a query of configuration in this case would return a valid BFD > > session. > > > > Could we get some clarification (with examples, preferably) on what > > the expectation is from a openconfig opstate perspective? > > Section 7 of draft-openconfig-netmod-opstate talks about > that. Specifically, #3 talks about the interface question you raise.. I think it is important that we understand how this 'applied config' is supposed to be populated on a device. First it was said that it there is just one way they can be different; time (on async systems). After some discussion I think there are now four ways: 1. Time (in async systems). 2. Hardware. If something is in intended config but there is no hw present, it is not in applied. 3. System-controlled stuff. If the system auto-creates an interface (for example), it will be in the applied config but not in intended. 4. "Template substitution"; the draft uses the example of an 'all' interface that exists in intended config but not in applied. Then Lada brought up the example of ip addresses. It was mentioned on the call that for ip addresses there would be three lists; one for intended, one for applied, and one in derived state, where the one in derived state is what the box *really* uses. So for example if it gets an ip from dhcp, it will be in the derived state list, but not in applied config. Why is this ip-address list different from the interface list? Why was it enough with two lists for interfaces, but we need three for ip addresses? /martin ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
Re: [netmod] Y26 again, sorry
Randy Presuhn writes: > Hi - > >>From: Ladislav Lhotka >>Sent: Sep 10, 2015 2:02 AM >>To: Randy Presuhn , netmod@ietf.org >>Subject: Re: [netmod] Y26 again, sorry >> >>Randy Presuhn writes: >> >>> Hi - >>> From: Andy Bierman Sent: Sep 9, 2015 12:10 PM To: Ladislav Lhotka Cc: Robert Wilton , Randy Presuhn , "netmod@ietf.org" Subject: Re: [netmod] Y26 again, sorry >>> ... I don't think it really addresses the design pattern very well. You want to claim that M and Q are both being developed at the same time,so it's OK that Q adds mandatory nodes to M. YANG has no such rule.YANG says a server can implement M and never implement Q.YANG says a server may implement M and then add Q in a future release.These conformance mechanisms do not align with your expectationsof how YANG can/should be used. >>> >>> I agree with Andy that there seems to be a mismatch in expectations. >> >>I wonder if we can explain these differences. Is your and Andy's >>expectation that the configuration schema has to reflect actual hardware >>configuration, perhaps even dynamically adjust to the changes? > > I can't speak for Andy, but I would expect that a server's > schema could change dynamically, as a result, for example, > of new hardware or software being introduced into a running > system. We were doing this in the late 1980's - it's one > of the things that pulled us into the subagent technology space. My (faint) understanding of CMIP/GDMO is that it was about management objects and prototypes, which indeed makes such a plug-in architecture easier. NETCONF/YANG deals with documents and schemas instead, and I assume the data model is in mostly (always?) fixed by NETCONF/RESTCONF server implementation. Am I wrong? > >>In my view, the supported (and advertised) data model and hardware >>configuration of the device are two different things. > > They are different, but there are relationships. When a new > line card is inserted, I would expect the system to acquire > any necessary schema knowledge in order to manage that new > resource. Likewise, if non-present hardware is being provisioned, > part of that provisioning process (possibly implicit) is for > the system being provisioned to acquire the necessary schema > knowledge so that it can perform at least a preliminary validation of > the provisioning data. I would expect that schema parts related to the new hardware have to be present beforehand. Encapsulation in YANG models is just a matter of conventions, so I think a general solution to dynamically changing schemas is next to impossible, also because parts of data model semantics may be expressed in prose (descriptions). > >>> Let's look at a slightly more complex hypothetical case to tease >>> out how folks *want* things to work. Assume the following have >>> been defined: >>> >>> - base module M >>> - augmentation Q >>> - augmentation R >>> >>> On a server claiming to supporting the modules containing M, Q, >>> and R, respectively, which of the following might one encounter >>> concurrently? >>> >>> - plain M >>> - M+Q >>> - M+R >>> - M+Q+R >> >>It depends on what you mean by "encounter" but in terms of datastore >>validity the only possible answer IMO is M+Q+R. > > By "encounter" I mean if a client asks the server for all of its Ms, > and the server also supports Q and R, are all of the Ms *guaranteed* > to be M+Q+R, or is it possible that some of the Ms might lack Q or > lack R of lack both? If what netmod gives us is strictly M+Q+R, > how would one model a system inhabited by a mixture of the four > kinds of Ms? This very much depends on how M, Q and R are designed. In a typical case, such as ietf-interfaces or ietf-routing, the augmenting modules just add new alternatives (interface types, address families, routing protocols). Lada > > Randy -- 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 coordination feedback on draft-openconfig-netmod-opstate-01
Hi Martin, On 11/09/2015 08:38, Martin Bjorklund wrote: Sam Aldrin wrote: On Sep 10, 2015, at 4:13 PM, Mahesh Jethanandani wrote: On Sep 10, 2015, at 12:43 PM, Carl Moberg (camoberg) mailto:camob...@cisco.com>> wrote: Now, think about configuration parameters that have applied configuration located in more than one place. Let’s say you change the IP address of an interface, it is likely that this configuration will be passed around as input to a handful of subsystems (e.g. the DHCP server, some routing daemons that may bind to specific IP addresses). Is the intended and applied in sync when a specific subset of those configurations are updated. What happens if there’s a partial failure? This is a good example. Another example, and somebody on the call today started to ask this but got cut off, relates to interfaces on the device. Interfaces already exist on a system. As such they have a configuration (default values) that exists on them. They are enabled when configuration gets applied on them. They will have applied configuration but no intended configuration. Should this be reported? Yet another example is of a BFD session that gets bootstrapped because of a ping. There is no intended configuration, but the session exists and a query of configuration in this case would return a valid BFD session. Could we get some clarification (with examples, preferably) on what the expectation is from a openconfig opstate perspective? Section 7 of draft-openconfig-netmod-opstate talks about that. Specifically, #3 talks about the interface question you raise.. I think it is important that we understand how this 'applied config' is supposed to be populated on a device. First it was said that it there is just one way they can be different; time (on async systems). After some discussion I think there are now four ways: 1. Time (in async systems). 2. Hardware. If something is in intended config but there is no hw present, it is not in applied. 3. System-controlled stuff. If the system auto-creates an interface (for example), it will be in the applied config but not in intended. I don't agree with this one. - if a system auto-creates an interface with no config then it is /interfaces-state, but not in /interfaces. - if a system auto-creates an interface and only then applies default config, the default config would go in intended and applied. - interfaces with pre-config that could be put into intended, but be left out of applied (because the hw isn't present). So in summary, I would say that config is in applied and not intended only if the config is in the process of being deleted (or the delete operational failed for some reason). 4. "Template substitution"; the draft uses the example of an 'all' interface that exists in intended config but not in applied. I don't agree with this one either. I don't think that cfg intended vs applied can or should be used as templating mechanism. But I think that there is another case, which is for config that was accepted into the system (i.e. semantically valid) and then failed when being applied. E.g. due to a system, or internal error. There is also a possible failure due to out of resource (which could be counted as the same as case 2). For a sync system, config failures can be returned as part of the edit-config request. What is the equivalent mechanism for an async system? Then Lada brought up the example of ip addresses. It was mentioned on the call that for ip addresses there would be three lists; one for intended, one for applied, and one in derived state, where the one in derived state is what the box *really* uses. So for example if it gets an ip from dhcp, it will be in the derived state list, but not in applied config. Why is this ip-address list different from the interface list? Why was it enough with two lists for interfaces, but we need three for ip addresses? I don't see that they are different. I think that you have 3 lists/leaves in both cases: I.e. I would say that 3 IP addr leaves are required in an async system, at a given time t: - only the intended leaf can indicate what IP addr config the operator wants on the interface (if any). - only the applied leaf can indicate what IP addr is actually being used as the configured value on the interface. - only the derived leaf can indicate what IP addr is actually operationally being used for the interface (which might be due to IP addr config, DHCP, or perhaps some other mechanism). I think that in the both kwatsen-netmod-opstate and wilton-netmod-opstate there are logically 3 interface lists as well: - /if:interfaces is logically split into 2, either through being present in separate running and applied datastores, or through having separate cfg-intended/cfg-applied leaves. - /if:interfaces-state, which I perceive as logically the derived state for an interface. Cheers, Rob /martin
Re: [netmod] YANG coordination feedback on draft-openconfig-netmod-opstate-01
Martin Bjorklund writes: > Sam Aldrin wrote: >> >> > On Sep 10, 2015, at 4:13 PM, Mahesh Jethanandani >> > wrote: >> > >> > >> >> On Sep 10, 2015, at 12:43 PM, Carl Moberg (camoberg) >> >> mailto:camob...@cisco.com>> wrote: >> >> >> >> Now, think about configuration parameters that have applied >> >> configuration located in more than one place. Let’s say you change the >> >> IP address of an interface, it is likely that this configuration will >> >> be passed around as input to a handful of subsystems (e.g. the DHCP >> >> server, some routing daemons that may bind to specific IP >> >> addresses). Is the intended and applied in sync when a specific subset >> >> of those configurations are updated. What happens if there’s a partial >> >> failure? >> > >> > This is a good example. Another example, and somebody on the call >> > today started to ask this but got cut off, relates to interfaces on >> > the device. >> > >> > Interfaces already exist on a system. As such they have a >> > configuration (default values) that exists on them. They are enabled >> > when configuration gets applied on them. They will have applied >> > configuration but no intended configuration. Should this be reported? >> > >> > Yet another example is of a BFD session that gets bootstrapped because >> > of a ping. There is no intended configuration, but the session exists >> > and a query of configuration in this case would return a valid BFD >> > session. >> > >> > Could we get some clarification (with examples, preferably) on what >> > the expectation is from a openconfig opstate perspective? >> >> Section 7 of draft-openconfig-netmod-opstate talks about >> that. Specifically, #3 talks about the interface question you raise.. > > I think it is important that we understand how this 'applied config' > is supposed to be populated on a device. > > First it was said that it there is just one way they can be different; > time (on async systems). After some discussion I think there are now > four ways: > > 1. Time (in async systems). > > 2. Hardware. If something is in intended config but there is no hw > present, it is not in applied. > > 3. System-controlled stuff. If the system auto-creates an > interface (for example), it will be in the applied config but > not in intended. > > 4. "Template substitution"; the draft uses the example of an 'all' > interface that exists in intended config but not in applied. > > > Then Lada brought up the example of ip addresses. It was mentioned > on the call that for ip addresses there would be three lists; one for > intended, one for applied, and one in derived state, where the one in > derived state is what the box *really* uses. So for example if it > gets an ip from dhcp, it will be in the derived state list, but not in > applied config. Right. After yesterday's interim I am much less in favour of this intended/applied proposal because - as you say, applied configuration falls short of representing "the state that the network element is actually in", - states in which intended and applied configuration can be out of sync are only transient. In the use cases I am interested in, such states could be relatively normal and last long. Another example that comes to my mind are static routes: an operator needs to know that a configured static route got installed, and this can be verified only by inspecting a corresponding RIB (operational state). I don't see how a copy of static routes in applied configuration could help. I agree with Juergen that what we need is a clever representation of operational state and this is hard work that needs to be done by experts on an ad hoc basis. That's why I am also sceptical about the possibility of having fixed and universally applicable relationships between configuration and operational state. Lada > > Why is this ip-address list different from the interface list? Why > was it enough with two lists for interfaces, but we need three for ip > addresses? > > > /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] YANG coordination feedback on draft-openconfig-netmod-opstate-01
> On Sep 11, 2015, at 12:07 PM, Ladislav Lhotka wrote: > > Martin Bjorklund writes: > >> Sam Aldrin wrote: >>> On Sep 10, 2015, at 4:13 PM, Mahesh Jethanandani wrote: > On Sep 10, 2015, at 12:43 PM, Carl Moberg (camoberg) > mailto:camob...@cisco.com>> wrote: > > Now, think about configuration parameters that have applied > configuration located in more than one place. Let’s say you change the > IP address of an interface, it is likely that this configuration will > be passed around as input to a handful of subsystems (e.g. the DHCP > server, some routing daemons that may bind to specific IP > addresses). Is the intended and applied in sync when a specific subset > of those configurations are updated. What happens if there’s a partial > failure? This is a good example. Another example, and somebody on the call today started to ask this but got cut off, relates to interfaces on the device. Interfaces already exist on a system. As such they have a configuration (default values) that exists on them. They are enabled when configuration gets applied on them. They will have applied configuration but no intended configuration. Should this be reported? Yet another example is of a BFD session that gets bootstrapped because of a ping. There is no intended configuration, but the session exists and a query of configuration in this case would return a valid BFD session. Could we get some clarification (with examples, preferably) on what the expectation is from a openconfig opstate perspective? >>> >>> Section 7 of draft-openconfig-netmod-opstate talks about >>> that. Specifically, #3 talks about the interface question you raise.. >> >> I think it is important that we understand how this 'applied config' >> is supposed to be populated on a device. >> >> First it was said that it there is just one way they can be different; >> time (on async systems). After some discussion I think there are now >> four ways: >> >> 1. Time (in async systems). >> >> 2. Hardware. If something is in intended config but there is no hw >> present, it is not in applied. >> >> 3. System-controlled stuff. If the system auto-creates an >> interface (for example), it will be in the applied config but >> not in intended. >> >> 4. "Template substitution"; the draft uses the example of an 'all' >> interface that exists in intended config but not in applied. >> >> >> Then Lada brought up the example of ip addresses. It was mentioned >> on the call that for ip addresses there would be three lists; one for >> intended, one for applied, and one in derived state, where the one in >> derived state is what the box *really* uses. So for example if it >> gets an ip from dhcp, it will be in the derived state list, but not in >> applied config. > > Right. After yesterday's interim I am much less in favour of this > intended/applied proposal because > > - as you say, applied configuration falls short of representing "the > state that the network element is actually in", > > - states in which intended and applied configuration can be out of sync > are only transient. In the use cases I am interested in, such states > could be relatively normal and last long. > > Another example that comes to my mind are static routes: an operator > needs to know that a configured static route got installed, and this can > be verified only by inspecting a corresponding RIB (operational > state). I don't see how a copy of static routes in applied configuration > could help. > > I agree with Juergen that what we need is a clever representation of > operational state and this is hard work that needs to be done by experts > on an ad hoc basis. That's why I am also sceptical about the possibility > of having fixed and universally applicable relationships between > configuration and operational state. This is very true! As the networking is done today by vendors, achieving universally applicable relation between config and operational state is very hard. Openconfig folks want to get a single tree with of variables and it is lot of work for existing vendors to translate between customer desires and current vendor implementations, having separate operational and config models. We should ask ourselves are we ready to work on an object oriented networking model with getter and setter functions and if vendors are ready to support such model. Dean > > Lada > >> >> Why is this ip-address list different from the interface list? Why >> was it enough with two lists for interfaces, but we need three for ip >> addresses? >> >> >> /martin >> ___ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > >
Re: [netmod] YANG coordination feedback on draft-openconfig-netmod-opstate-01
Robert Wilton wrote: > Hi Martin, > > On 11/09/2015 08:38, Martin Bjorklund wrote: > > Sam Aldrin wrote: > >>> On Sep 10, 2015, at 4:13 PM, Mahesh Jethanandani > >>> wrote: > >>> > >>> > On Sep 10, 2015, at 12:43 PM, Carl Moberg (camoberg) > mailto:camob...@cisco.com>> wrote: > > Now, think about configuration parameters that have applied > configuration located in more than one place. Let’s say you change the > IP address of an interface, it is likely that this configuration will > be passed around as input to a handful of subsystems (e.g. the DHCP > server, some routing daemons that may bind to specific IP > addresses). Is the intended and applied in sync when a specific subset > of those configurations are updated. What happens if there’s a partial > failure? > >>> This is a good example. Another example, and somebody on the call > >>> today started to ask this but got cut off, relates to interfaces on > >>> the device. > >>> > >>> Interfaces already exist on a system. As such they have a > >>> configuration (default values) that exists on them. They are enabled > >>> when configuration gets applied on them. They will have applied > >>> configuration but no intended configuration. Should this be reported? > >>> > >>> Yet another example is of a BFD session that gets bootstrapped because > >>> of a ping. There is no intended configuration, but the session exists > >>> and a query of configuration in this case would return a valid BFD > >>> session. > >>> > >>> Could we get some clarification (with examples, preferably) on what > >>> the expectation is from a openconfig opstate perspective? > >> Section 7 of draft-openconfig-netmod-opstate talks about > >> that. Specifically, #3 talks about the interface question you raise.. > > I think it is important that we understand how this 'applied config' > > is supposed to be populated on a device. > > > > First it was said that it there is just one way they can be different; > > time (on async systems). After some discussion I think there are now > > four ways: > > > >1. Time (in async systems). > > > >2. Hardware. If something is in intended config but there is no hw > >present, it is not in applied. > > > >3. System-controlled stuff. If the system auto-creates an > >interface (for example), it will be in the applied config but > >not in intended. > > I don't agree with this one. > - if a system auto-creates an interface with no config then it is > - /interfaces-state, but not in /interfaces. Yes this is how ietf-interfaces work. But the openconfig people want to change this, and introduce 'applied config' as a simplicifation. I am / we are trying to understand how they intend this 'applied config' to work. > - if a system auto-creates an interface and only then applies default > - config, the default config would go in intended and applied. > - interfaces with pre-config that could be put into intended, but be > - left out of applied (because the hw isn't present). > > So in summary, I would say that config is in applied and not intended > only if the config is in the process of being deleted (or the delete > operational failed for some reason). > > > > >4. "Template substitution"; the draft uses the example of an 'all' > >interface that exists in intended config but not in applied. > I don't agree with this one either. I don't think that cfg intended > vs applied can or should be used as templating mechanism. See above; the four bullets are (my understanding of) what the openconfig people have said. I hope they clarify if this is not what they meant. /martin > But I think that there is another case, which is for config that was > accepted into the system (i.e. semantically valid) and then failed > when being applied. E.g. due to a system, or internal error. There > is also a possible failure due to out of resource (which could be > counted as the same as case 2). > > For a sync system, config failures can be returned as part of the > edit-config request. What is the equivalent mechanism for an async > system? > > > > > > Then Lada brought up the example of ip addresses. It was mentioned > > on the call that for ip addresses there would be three lists; one for > > intended, one for applied, and one in derived state, where the one in > > derived state is what the box *really* uses. So for example if it > > gets an ip from dhcp, it will be in the derived state list, but not in > > applied config. > > > > Why is this ip-address list different from the interface list? Why > > was it enough with two lists for interfaces, but we need three for ip > > addresses? > I don't see that they are different. I think that you have 3 > lists/leaves in both cases: > > I.e. I would say that 3 IP addr leaves are required in an async > system, at a given time t: > - only the intended leaf can indicate what IP addr config the operator > -
Re: [netmod] Consensus Call Note for Requirements
Hi Kent, Tom, I don't really want to slow down the consensus process, but after the discussion there are a couple of requirements that are not absolutely clear to me. [Sorry for not raising them in the meeting yesterday, but we had already spent a lot of time discussing the requirements and I also think that you understandably went through the options quite fast at the end]. On 10/09/2015 21:44, Nadeau Thomas wrote: This is an official NETMOD working group call for consensus around the requirements referenced below and discussed in detail at the interim meeting held Thursday, September 10, 2015. At that meeting, the chairs went over each requirement in detail and called for any objections to each requirement (and sub-requirement). The question that was asked was “Are there any objections to requirement X in general meaning as it is currently written or with minor/editorial changes to how its written?” There were no objections to any of the requirements, as is detailed in the meeting minutes. However, to confirm these statements the co-chairs are opening this question to the WG for period starting today, Thursday, September 10, 2015 at 5PM EST. This period will close on Monday, September 14, 2015 at 5PM EST. If you commented on the list previously, or at the meeting, there is no need to repeat yourself; we have your position on We will make a call of consensus shortly thereafter. For your reference, the requirements can be found at this URL: http://etherpad.tools.ietf.org:9000/p/netmod-opstate-requirements but I will paste them into this message explicitly to be complete. —Tom (as co-chair) Terminology From: https://tools.ietf.org/html/draft-openconfig-netmod-opstate-01 In order to understand the way in which a network operator or network management system may need to interact with a device, it is key to understand the different types of data that network elements may store or master: o intended configuration - this data represents the state that the network operator intends the system to be in. This data is colloquially referred to as the 'configuration' of the system. o applied configuration - this data represents the state that the network element is actually in, i.e., that which is currently being run by particular software modules (e.g., the BGP daemon), or other systems within the device (e.g., a secondary control- plane, or line card). o derived state - this data represents information which is generated as part of the system's own interactions. For example, derived state may consist of the results of protocol interactions (the negotiated duplex state of an Ethernet link), statistics (such as message queue depth), or counters (such as packet input or output bytes). 1. Ability to interact with both intended and applied configuration a. The ability to ask the operational components of a system (e.g., line cards) for the configuration that they are currently using. This is the "applied configuration". b. applied configuration is read-only c. The data model for the applied configuration is the same as the data model for the intended configuration (same leaves) d. For asynchronous systems, when fully synchronized, the data in the applied configuration is the same as the data in the intended configuration. - I think that it would be useful to define what full synchronized means. In this context, I think of it as meaning if none of the configuration failed to be applied for any reason (e.g. due to absence of hardware, or internal system error). - Separately, this isn't specified in the openconfig-netmod-opstate draft, but is there any requirement to indicate why an intended cfg node isn't in the applied cfg? In the solution that I've proposed, I've assumed that there is. It would be good to get clarification on whether it is a genuine valid requirement or not. 2. Applied configuration as part of operational state a. the ability to retrieve the applied configuration and derived state nodes in a single protocol operation. 3. Support for both transactional, synchronous management systems as well as distributed, asynchronous management systems a. For asynchronous systems, the ability to request a protocol operation to not return (i.e. block) until the intended configuration has been fully synchronized. I'm not sure why 3 (a) is a requirement, or its unclear to me where this is specified in the openconfig-netmod-opstate draft. Thanks, Rob ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
Re: [netmod] Consensus Call Note for Requirements
> On Sep 11, 2015:6:48 AM, at 6:48 AM, Robert Wilton wrote: > > Hi Kent, Tom, > > I don't really want to slow down the consensus process, but after the > discussion there are a couple of requirements that are not absolutely clear > to me. [Sorry for not raising them in the meeting yesterday, but we had > already spent a lot of time discussing the requirements and I also think that > you understandably went through the options quite fast at the end]. > > On 10/09/2015 21:44, Nadeau Thomas wrote: >> This is an official NETMOD working group call for consensus around the >> requirements referenced >> below and discussed in detail at the interim meeting held Thursday, >> September 10, 2015. At that meeting, the >> chairs went over each requirement in detail and called for any objections to >> each requirement (and sub-requirement). The question that was asked was “Are >> there any objections to requirement X in general meaning as it is currently >> written or with minor/editorial changes to how its written?” There were no >> objections to any of the requirements, as is detailed in the meeting >> minutes. However, to confirm these statements the co-chairs are opening >> this question to the WG for period starting today, Thursday, September 10, >> 2015 at 5PM EST. This period will close on Monday, September 14, 2015 at >> 5PM EST. If you commented on the list previously, or at the meeting, there >> is no need to repeat yourself; we have your position on >> >> We will make a call of consensus shortly thereafter. >> >> For your reference, the requirements can be found at this URL: >> >> http://etherpad.tools.ietf.org:9000/p/netmod-opstate-requirements >> >> but I will paste them into this message explicitly to be complete. >> >> —Tom (as co-chair) >> >> >> >> Terminology >> >> From: https://tools.ietf.org/html/draft-openconfig-netmod-opstate-01 >> >> In order to understand the way in which a network operator or network >> management system may need to interact with a device, it is key to >> understand the different types of data that network elements may >> store or master: >> >> o intended configuration - this data represents the state that the >> network operator intends the system to be in. This data is >> colloquially referred to as the 'configuration' of the system. >> >> o applied configuration - this data represents the state that the >> network element is actually in, i.e., that which is currently >> being run by particular software modules (e.g., the BGP daemon), >> or other systems within the device (e.g., a secondary control- >> plane, or line card). >> >> o derived state - this data represents information which is >> generated as part of the system's own interactions. For example, >> derived state may consist of the results of protocol interactions >> (the negotiated duplex state of an Ethernet link), statistics >> (such as message queue depth), or counters (such as packet input >> or output bytes). >> >> >> >> 1. Ability to interact with both intended and applied configuration >> >> a. The ability to ask the operational components of a system >> (e.g., line cards) for the configuration that they are currently >> using. This is the "applied configuration". >> >> b. applied configuration is read-only >> >> c. The data model for the applied configuration is the same as >> the data model for the intended configuration (same leaves) >> >> d. For asynchronous systems, when fully synchronized, the data >> in the applied configuration is the same as the data in the >> intended configuration. > - I think that it would be useful to define what full synchronized means. In > this context, I think of it as meaning if none of the configuration failed to > be applied for any reason (e.g. due to absence of hardware, or internal > system error). > > - Separately, this isn't specified in the openconfig-netmod-opstate draft, > but is there any requirement to indicate why an intended cfg node isn't in > the applied cfg? In the solution that I've proposed, I've assumed that there > is. It would be good to get clarification on whether it is a genuine valid > requirement or not. > >> >> 2. Applied configuration as part of operational state >> >>a. the ability to retrieve the applied configuration and >>derived state nodes in a single protocol operation. >> >> >> 3. Support for both transactional, synchronous management >> systems as well as distributed, asynchronous management >> systems >> >>a. For asynchronous systems, the ability to request a protocol >>operation to not return (i.e. block) until the intended >>configuration has been fully synchronized. > I'm not sure why 3 (a) is a requirement, or its unclear to me where this is > specified in the openconfig-netmod-opstate draft. An
Re: [netmod] Consensus Call Note for Requirements
On 9/11/2015 8:09 AM, Nadeau Thomas wrote: >>> 3. Support for both transactional, synchronous management >>> >> systems as well as distributed, asynchronous management >>> >> systems >>> >> >>> >>a. For asynchronous systems, the ability to request a protocol >>> >>operation to not return (i.e. block) until the intended >>> >>configuration has been fully synchronized. >> > I'm not sure why 3 (a) is a requirement, or its unclear to me where this >> > is specified in the openconfig-netmod-opstate draft. > Anees/Rob, can you guys please add some color to the above descriptions > to help clarify things for Robert? I see (3) but not (3.a) in http://tools.ietf.org/html/draft-openconfig-netmod-opstate-01#section-4.2 so am unsure how 3.a made it on the list. also, I don't object to 3.a if *users* say they need it. Lou ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
Re: [netmod] minutes of the NETMOD 2015-09-07 virtual interim meeting
Juergen Schoenwaelder writes: > * Data tree ordering (Lada) > > LL: Is the data tree fundamentally unordered? > MB: Yes, the ordering is in the encoding parts. > > Action: LL to check whether his comments have been resolved in the > svn version. > The definition of "data tree" is OK, and the text about document order in sec. 6.4 (XPath Evaluations) is IMO sufficient. Thanks, Lada -- 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 coordination feedback on draft-openconfig-netmod-opstate-01
On Fri, Sep 11, 2015 at 12:38 AM, Martin Bjorklund wrote: > Sam Aldrin wrote: > > > > > On Sep 10, 2015, at 4:13 PM, Mahesh Jethanandani > > > wrote: > > > > > > > > >> On Sep 10, 2015, at 12:43 PM, Carl Moberg (camoberg) > > >> mailto:camob...@cisco.com>> wrote: > > >> > > >> Now, think about configuration parameters that have applied > > >> configuration located in more than one place. Let’s say you change the > > >> IP address of an interface, it is likely that this configuration will > > >> be passed around as input to a handful of subsystems (e.g. the DHCP > > >> server, some routing daemons that may bind to specific IP > > >> addresses). Is the intended and applied in sync when a specific subset > > >> of those configurations are updated. What happens if there’s a partial > > >> failure? > > > > > > This is a good example. Another example, and somebody on the call > > > today started to ask this but got cut off, relates to interfaces on > > > the device. > > > > > > Interfaces already exist on a system. As such they have a > > > configuration (default values) that exists on them. They are enabled > > > when configuration gets applied on them. They will have applied > > > configuration but no intended configuration. Should this be reported? > > > > > > Yet another example is of a BFD session that gets bootstrapped because > > > of a ping. There is no intended configuration, but the session exists > > > and a query of configuration in this case would return a valid BFD > > > session. > > > > > > Could we get some clarification (with examples, preferably) on what > > > the expectation is from a openconfig opstate perspective? > > > > Section 7 of draft-openconfig-netmod-opstate talks about > > that. Specifically, #3 talks about the interface question you raise.. > > I think it is important that we understand how this 'applied config' > is supposed to be populated on a device. > > First it was said that it there is just one way they can be different; > time (on async systems). After some discussion I think there are now > four ways: > > IMO it would help to think just a bit about the operational aspects of these issues. There are at least 2 outcomes I can think of: Outcome 1) Convergence: Intended config eventually matches Applied Outcome 2) Non-convergence: Intended config is not going to become Applied A system needs to decide if/when outcome 2 has occurred. When is a fault raised because convergence is not happening? There are probably other uses for all this extra meta-data. So how do these 4 types of differences relate to these outcomes? 1. Time (in async systems). > Obviously the main use-case. Nothing in any solution proposal helps the client decide Outcome 2 has occurred. That is out of scope I guess. For most systems, this time delta will be too short to worry about ( < 5 sec.) A good solution would not impact this vast majority of servers. > 2. Hardware. If something is in intended config but there is no hw > present, it is not in applied. > This is usually handled with a notification that the line-card was plugged in, which causes the NMS to re-check the config. The solution proposal assumes the server can identify all the resources or other reasons that some specific leaf is not applied yet. This seems very complicated to implement in the server. > 3. System-controlled stuff. If the system auto-creates an > interface (for example), it will be in the applied config but > not in intended. > There is no convergence here because this is a case where applied has more than intended, not the other way around. > 4. "Template substitution"; the draft uses the example of an 'all' > interface that exists in intended config but not in applied. > > There is no convergence here because the template is not supposed to show up in Applied. However it is worth noting than none of the proposals solve this problem. The Intended and Applied will never match. The NMS must understand how the specific template works to know what actual instances are expected in Applied. > > Then Lada brought up the example of ip addresses. It was mentioned > on the call that for ip addresses there would be three lists; one for > intended, one for applied, and one in derived state, where the one in > derived state is what the box *really* uses. So for example if it > gets an ip from dhcp, it will be in the derived state list, but not in > applied config. > > Why is this ip-address list different from the interface list? Why > was it enough with two lists for interfaces, but we need three for ip > addresses? > > > /martin > Andy > ___ > 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: New Version Notification for draft-chairs-netmod-opstate-reqs-00.txt
The AD and chairs thought it best to formalize the consensus on the requirements a bit more. So we created the I-D listed below to track and capture final consensus. Additionally, we want to use this GitHub issue tracker to track issues: https://github.com/netmod-wg/opstate-reqs/issues Consistent with Tom's earlier email, we want to collect any issues with these requirements before EOB Monday, September 14, 2015 at 5PM EST. If you have an issue, in addition to posting it to the list, please consider adding it to the GitHub tracker, and let people know you did so. Our goal is to close the issues as quickly as possible, some will go to DEAD while others may remain OPEN, based on WG consensus. Thanks, Kent & Tom On 9/11/15, 5:36 PM, "internet-dra...@ietf.org" wrote: > >A new version of I-D, draft-chairs-netmod-opstate-reqs-00.txt >has been successfully submitted by Kent Watsen and posted to the >IETF repository. > >Name: draft-chairs-netmod-opstate-reqs >Revision: 00 >Title: NETMOD Operational State Requirements >Document date: 2015-09-11 >Group: Individual Submission >Pages: 5 >URL: >https://www.ietf.org/internet-drafts/draft-chairs-netmod-opstate-reqs-00.t >xt >Status: >https://datatracker.ietf.org/doc/draft-chairs-netmod-opstate-reqs/ >Htmlized: >https://tools.ietf.org/html/draft-chairs-netmod-opstate-reqs-00 > > >Abstract: > This document captures consensus on operational state requirements by > the NETMOD working group. > > > > > >Please note that it may take a couple of minutes from the time of >submission >until the htmlized version and diff are available at tools.ietf.org. > >The IETF Secretariat > ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
Re: [netmod] YANG coordination feedback on draft-openconfig-netmod-opstate-01
Hi Mahesh, The answer (today) is that some operator knows the show commands to type, and then knows from the screen full of data that certain config commands are active. It's not hard to imagine that how an API to do this without any magic would be useful. (Hence the openconfig requirement...) As Carl pointed out in the interim, current systems do not provide this level of automation. All this is new code, and perhaps there are complicated corner-cases to be found. All solutions expect the server to be able to determine applied status for every leaf in the intended config. All solutions require basically the same internal API support to check the relevant applied config or operational state. In every solution, the server will magically know how to check that the IP address is active. That's the point. It is better than forcing the client to know how to do this for every type of server. IMO, this requirement is clear, and each draft has a solution approach for this new API. Andy On Fri, Sep 11, 2015 at 2:52 PM, Mahesh Jethanandani < mjethanand...@gmail.com> wrote: > And while we mull over the questions Andy has raised, I want to go back > and dwell on what Rob said about why he wanted a way to determine when the > configuration has taken effect. I might be simplifying the problem a little > too much, but I am sure Rob will correct me. The ask as I understand > is, give me a way to deterministically know when a given piece of > configuration has taken effect. > > As an exercise I wanted to mentally go through trying to configure an > interface to determine if the configuration has taken effect. Very simply, > I want to assign an IP address to an interface. If I now want to know if > this configuration has taken effect, I can check for the IP address of the > interface. Querying the IP address on an interface does not tell me if it > has taken effect. Yes, it has been written to a register, but what does > that tell me? Nothing. My only deterministic way of knowing that the IP > address has taken effect is if I can see traffic transmitted/received with > that IP address on that interface. > > To me that is the crux of the problem with simply reflecting operational > status with a flag that gets updated when the configuration gets written. > In most cases, the configuration will just work and the flag will tell me > nothing new. But when it does not, having written to a flag will also tell > me nothing, other than the fact that the configuration was written. > > I contend that the real ask with this example is to determine if I can > pass IP traffic, and to determine that, we need more than a “intended vs > actual” flag. > > On Sep 11, 2015, at 9:42 AM, Andy Bierman wrote: > > > > On Fri, Sep 11, 2015 at 12:38 AM, Martin Bjorklund wrote: > >> Sam Aldrin wrote: >> > >> > > On Sep 10, 2015, at 4:13 PM, Mahesh Jethanandani >> > > wrote: >> > > >> > > >> > >> On Sep 10, 2015, at 12:43 PM, Carl Moberg (camoberg) >> > >> mailto:camob...@cisco.com>> wrote: >> > >> >> > >> Now, think about configuration parameters that have applied >> > >> configuration located in more than one place. Let’s say you change >> the >> > >> IP address of an interface, it is likely that this configuration will >> > >> be passed around as input to a handful of subsystems (e.g. the DHCP >> > >> server, some routing daemons that may bind to specific IP >> > >> addresses). Is the intended and applied in sync when a specific >> subset >> > >> of those configurations are updated. What happens if there’s a >> partial >> > >> failure? >> > > >> > > This is a good example. Another example, and somebody on the call >> > > today started to ask this but got cut off, relates to interfaces on >> > > the device. >> > > >> > > Interfaces already exist on a system. As such they have a >> > > configuration (default values) that exists on them. They are enabled >> > > when configuration gets applied on them. They will have applied >> > > configuration but no intended configuration. Should this be reported? >> > > >> > > Yet another example is of a BFD session that gets bootstrapped because >> > > of a ping. There is no intended configuration, but the session exists >> > > and a query of configuration in this case would return a valid BFD >> > > session. >> > > >> > > Could we get some clarification (with examples, preferably) on what >> > > the expectation is from a openconfig opstate perspective? >> > >> > Section 7 of draft-openconfig-netmod-opstate talks about >> > that. Specifically, #3 talks about the interface question you raise.. >> >> I think it is important that we understand how this 'applied config' >> is supposed to be populated on a device. >> >> First it was said that it there is just one way they can be different; >> time (on async systems). After some discussion I think there are now >> four ways: >> >> > > IMO it would help to think just a bit about the operational aspects > of these issues. > > There are at least 2 outcomes I
