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

[Juergen Schoenwaelder]

On Thu, Feb 11, 2016 at 02:52:27PM +, Robert Wilton wrote:
> 
> On 11/02/2016 09:29, Juergen Schoenwaelder wrote:
> >We are discussing this text:
> >
> >D.  The configuration protocol MUST specify how configuration
> >errors are handled.  Errors SHOULD be handled by semantics
> >similar to NETCONF's error-options for the 
> >operation (stop-on-error, continue-on-error, rollback-on-
> >error), as described in Section 7.2 in [RFC6241], but
> >extended to incorporate both the intended and applied
> >configurations.  Support for "rollback on error" semantics
> >SHOULD be provided.
> >
> >First, let me observe that it is underspecified what a 'configuration
> >error' is in the context of this requirement statement. Is the
> >configuration of an interface that is currently not present a
> >configuration error?
> My opinion is yes, this is an error and hence would cause configuration 
> to fail and rollback if "rollback-on-error" semantics had been requested.
> 
> If the request had used continue-on-error semantics then I would expect 
> that you would see this configuration in intended, but not applied.
> 
> >  If not, does it become a configuration error if a
> >line card is inserted to which the configuration can not be applied?
> As above, this question doesn't directly apply.
> 
> But a similar question might be: what would happen if the configuration 
> had previously been accepted and then a linecard removed?  In this case 
> the the affected interface configuration would stay in intended but be 
> removed from applied by the system.

Looks like the semantics you describe are somewhat inconsistent. BTW,
I have been told that 'some operators' do provision configuration for
hardware not yet present. RFC 7223 has been designed to allow this to
happen. Anyway, this is an example. The point is that it is not clear
cut whether something that can't be immediately applied really is an
error.
 
> >Note that NETCONF together with YANG provides a rather clear
> >definition what validation of a configuration datastore means. When we
> >talk about applied config and the difference between intended and
> >applied config, the notion of what is a configuration error is not
> >clear cut anymore.
> Personally, I agree that having tighter semantics are a good thing here 
> (and should be covered by the solution draft).

Then I note that the requirement is at least not well defined.

> >Second, in order to rollback, there needs to be a configuration that
> >can be safely rolled back into. The only robust way I can imagine to
> >implement this rollback requirement is to use locks until the whole
> >new config has been applied, thereby turning an asynchronous system
> >into a synchronous system. Otherwise, I fail to see how I can ensure
> >that I have a configuration that can be safely rolled back into.
> Locks are the simplest way of implementing this, but I agree that they 
> defeat the point of async configuration updates.
> 
> I don't think that locking is the only way to solve this.  I would have 
> thought that one of the optimistic transactional locking approaches 
> could be used to process multiple requests concurrently.

As long as it is clear to which configuration to roll back to. Once
you process multiple requests concurrently, this is not at all clear,
at least not to me.

> Hence, I think that the decision as to whether or not to use a global 
> lock should probably be specified during the client operation (if at 
> all), and the solution draft shouldn't enforce always using a server 
> side lock.  Instead it should specify the exact semantics that a client 
> can expect when interacting with the server during configuration 
> requests.  This is to allow for flexibility in server implementations - 
> i.e. to trade off complexity for performance.

If it is unclear from the specification what the result of a rollback
is, then I believe this serves little value. And see the previous
examples; what can be applied at time t in general depends on the
overall state of the system at time t. YANG does not allow config true
nodes to depend on config false nodes and the reason is that
configuration validity must not depend on the time varying operational
state of a device.

/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] Module and Submodule Revision Dates

[Martin Bjorklund]

JOEY BOYD  wrote:
> Hi all,
> 
> In RFC6087, there's a statement under Lifecycle Management regarding
> the revision date of a module with respect to its submodules.
> 
> "If submodules are used, then the document containing the main module
> MUST be updated so that the main module revision date is equal or more
> recent than the revision date of any submodule that is (directly or
> indirectly) included by the main module."
> 
> In the Broadband Forum, we weren't aware of this statement until our
> models were validated using another tool besides pyang which flagged
> an error as our main modules' revision dates were older than some of
> their submodules.  We were wondering why pyang does not check for this
> when using the --lint option as it seems to validate RFC6087
> requirements.  Is this just an oversight or are we interpreting
> something incorrectly?

An oversight in the tool.  [Please report this as a bug at
https://github.com/mbj4668/pyang]


/martin

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

Re: [netmod] Case Statements in Groupings

[Martin Bjorklund]

JOEY BOYD  wrote:
> Hi all,
> 
> Currently, it's not allowed to do the following as you cannot wrap
> case statements in a grouping.
> 
> grouping common-cases {
>   case b {
> leaf b {
> }
>   }
> 
>   case c {
> leaf c {
> }
>   }
> }
> 
> container alpha {
>   choice my-first-choice {
> case a {
>   leaf a {
>   }
> }
> 
> uses common-cases;
>   }
> }
> 
> container beta {
>   choice my-second-choice {
> case d {
>   leaf d {
>   }
> }
> uses common-cases;
>   }
> }
> 
> 
> 
> I was wondering why this restriction is in place.  I know you have to
> be careful with name collisions but that's true of just a grouping of
> leafs.  Am I missing something?

This could maybe have been considered.  Such a grouping would of
course only be allowed to be used in a choice, and it would be limited
to define *only* case nodes.  As such it is a bit different than other
groupings.

Note that you can achieve a similar effect by doing:

  grouping choice-with-common-cases {
choice the-choice {
  case b {
leaf b {
}
  }

  case c {
leaf c {
}
  }
}
  }

  container alpha {
uses choice-with-common-cases {
  augment "the-choice" {
case a {
  leaf a {
  }
}
  }
}
  }

  container beta {
uses choice-with-common-cases {
  augment "the-choice" {
case d {
  leaf d {
  }
}
  }
}
  }
  



/martin

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

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

[Robert Wilton]

On 12/02/2016 08:19, Juergen Schoenwaelder wrote:

On Thu, Feb 11, 2016 at 02:52:27PM +, Robert Wilton wrote:

On 11/02/2016 09:29, Juergen Schoenwaelder wrote:

We are discussing this text:

D.  The configuration protocol MUST specify how configuration
errors are handled.  Errors SHOULD be handled by semantics
similar to NETCONF's error-options for the 
operation (stop-on-error, continue-on-error, rollback-on-
error), as described in Section 7.2 in [RFC6241], but
extended to incorporate both the intended and applied
configurations.  Support for "rollback on error" semantics
SHOULD be provided.

First, let me observe that it is underspecified what a 'configuration
error' is in the context of this requirement statement. Is the
configuration of an interface that is currently not present a
configuration error?

My opinion is yes, this is an error and hence would cause configuration
to fail and rollback if "rollback-on-error" semantics had been requested.

If the request had used continue-on-error semantics then I would expect
that you would see this configuration in intended, but not applied.


  If not, does it become a configuration error if a
line card is inserted to which the configuration can not be applied?

As above, this question doesn't directly apply.

But a similar question might be: what would happen if the configuration
had previously been accepted and then a linecard removed?  In this case
the the affected interface configuration would stay in intended but be
removed from applied by the system.

Looks like the semantics you describe are somewhat inconsistent.

OK, they were not meant to be inconsistent at all:

- The intended configuration is what the operator wants, and can only be 
changed by the operator.
- The applied configuration is what state the system is in, and should 
be continuously kept up to date with the current system state.


- If a config change completes without any errors that means that for 
every node in the changeset, the applied config node matches the 
intended config node.
- This is why I would say that the cleanest semantics are that 
attempting to configure an interface that doesn't exist should be 
regarded as a config apply error.  (If the operator wants to push this 
config in then I think that they should be using the continue-on-error 
option - or perhaps something similar).




  BTW,
I have been told that 'some operators' do provision configuration for
hardware not yet present. RFC 7223 has been designed to allow this to
happen. Anyway, this is an example. The point is that it is not clear
Yes.  I'm not opposed to this on principal, but if a choice of semantics 
are supported then it should be down the operators request to choose the 
semantics.  Having rules that give flexibility in how a device is 
allowed to behave just makes them more difficult for the operator to manage.




cut whether something that can't be immediately applied really is an
error.
  

Note that NETCONF together with YANG provides a rather clear
definition what validation of a configuration datastore means. When we
talk about applied config and the difference between intended and
applied config, the notion of what is a configuration error is not
clear cut anymore.

Personally, I agree that having tighter semantics are a good thing here
(and should be covered by the solution draft).

Then I note that the requirement is at least not well defined.
Perhaps, but we had already spent a long time discussing the 
requirements draft, hence personally I think that it is OK to 
specify/agree the precise semantics/behaviour in a solution draft.






Second, in order to rollback, there needs to be a configuration that
can be safely rolled back into. The only robust way I can imagine to
implement this rollback requirement is to use locks until the whole
new config has been applied, thereby turning an asynchronous system
into a synchronous system. Otherwise, I fail to see how I can ensure
that I have a configuration that can be safely rolled back into.

Locks are the simplest way of implementing this, but I agree that they
defeat the point of async configuration updates.

I don't think that locking is the only way to solve this.  I would have
thought that one of the optimistic transactional locking approaches
could be used to process multiple requests concurrently.

As long as it is clear to which configuration to roll back to. Once
you process multiple requests concurrently, this is not at all clear,
at least not to me.
Logically, the system must revert to a state where the failed 
configuration request was never applied.  I think this is the only 
guarantee that is being made to the client.


One way to achieve this would be rollback the configuration (intended 
and applied) back to exactly the point before that failed request (or 
any other request) was processed.


Any concurrent configuration request

Re: [netmod] Restricting interface name maximum length and character set

[William Lupton]

Thanks for the reply. No other BBF specs (that I am aware of) require such 
restrictions. I (personally) think that handling this as a device requirement 
is a fine solution, but we wanted to check what people thought of trying to 
define such restrictions in the YANG.

BTW, we were thinking of: maximum length (64) and restricted character set 
(ASCII 32-126).

William

> On 11 Feb 2016, at 13:55, Juergen Schoenwaelder 
>  wrote:
> 
> On Thu, Feb 11, 2016 at 12:22:19PM +, William Lupton wrote:
>> All,
>> 
>> Here in the Broadband Forum we are defining YANG modules that augment RFC 
>> 7223 ietf-interfaces. We want to limit interface name maximum length and 
>> character set but don't see a way of doing this in the YANG.
>> 
>> Can/should we do do this in the YANG, or should it just be a device-level 
>> requirement?
>> 
> 
> I wonder why you want to do this. Is it because other existing BBF
> specifications break if interfaces can have long names and use Unicode
> characters? Out of curiosity, what would be the length and character
> set restriction BBF finds a good choice?
> 
> A deviation statement describes how an implementation deviates from a
> data model. It was not the intent that an SDO defines a 'standard'
> deviation for a data model (the term 'profile' might be more
> appropriate for this).
> 
> Note that these kind of 'profiles' often do not combine well. If BBF
> says the max length is N and MEF says that max length is N with N !=
> M, then an implementor has a hard time to produce a device that
> satisfies both requirements. (All one can do is to use min(N,M) and
> then annouce a deviation to the profiles affected, all getting pretty
> ugly soon, in particular if the common native interface names may be
> longer than N and M.)
> 
> I understand that 'arbitrarily long' may sound ridiculous. But having
> an implementation announce its real limit instead of a data model or
> 'profile' imposed limit seems simpler and more robust to me.
> 
> /js
> 
> PS: On Windows, MAX_ADAPTER_NAME_LENGTH seems to be 256, on Linux
>IF_NAMESIZE seems to be 16, on FreeBSD and MacOS IF_NAMESIZE seems
>to be 16 as well (but there are likely systems derived from
>FreeBSD that use a different constant, may also be true for Linux
>- and most likely people change this constant for a reason).
> 
> -- 
> 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] draft-ietf-netmod-routing-cfg

[Behcet Sarikaya]

 Hi Lada,

When trying to validate NETCONF get reply in Appendix D, I ran into a problem:

This annex introduces a namespace iana-if-types and none of the YANG
modules of ietf-routing-cfg is dependent on this namespace.
As a result, the NETCONF tool that I am using could not recognize
ethernetCdmacd when it comes to the line

ianaift:ethernetCsmacd

I know that iana-if-types is defined at the beginning of the rpc reply
but it seems like those declarations are simply ignored.

Do you offer any solution?

Regards,

Behcet

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

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

[Kent Watsen]

[As a contributor]




   If not, does it become a configuration error if a
 line card is inserted to which the configuration can not be applied?
>>> As above, this question doesn't directly apply.
>>>
>>> But a similar question might be: what would happen if the configuration
>>> had previously been accepted and then a linecard removed?  In this case
>>> the the affected interface configuration would stay in intended but be
>>> removed from applied by the system.
>> Looks like the semantics you describe are somewhat inconsistent.
>OK, they were not meant to be inconsistent at all:
>
>- The intended configuration is what the operator wants, and can only be 
>changed by the operator.
>- The applied configuration is what state the system is in, and should 
>be continuously kept up to date with the current system state.
>
>- If a config change completes without any errors that means that for 
>every node in the changeset, the applied config node matches the 
>intended config node.
>- This is why I would say that the cleanest semantics are that 
>attempting to configure an interface that doesn't exist should be 
>regarded as a config apply error.  (If the operator wants to push this 
>config in then I think that they should be using the continue-on-error 
>option - or perhaps something similar).

I disagree.  JUNOS specifically allows for preconfiguration for hardware that 
does not exists yet.  It’s a well-regarded feature.  It is not an error, but 
may be reported as a warning.  This is why we defined leaf "apply-warning” in 
this draft (see subject line).  That said, I do agree that the applied 
configuration would not have the config for the missing hardware, as would be 
evident in a diff between it and the intended configuration.  



>>   BTW,
>> I have been told that 'some operators' do provision configuration for
>> hardware not yet present. RFC 7223 has been designed to allow this to
>> happen. Anyway, this is an example. The point is that it is not clear
>Yes.  I'm not opposed to this on principal, but if a choice of semantics 
>are supported then it should be down the operators request to choose the 
>semantics.  Having rules that give flexibility in how a device is 
>allowed to behave just makes them more difficult for the operator to manage.

I think that this doesn’t scale.  By this token, servers should support 
everything the IETF defines.  But that’s not how it works, instead we have 
features and capabilities that enable devices to advertise what they support.  
This ability is important when a brown-field device is moving to support 
NETCONF/RESTCONF but can’t break compatibility with its legacy APIs.



Note that NETCONF together with YANG provides a rather clear
 definition what validation of a configuration datastore means. When we
 talk about applied config and the difference between intended and
 applied config, the notion of what is a configuration error is not
 clear cut anymore.
>>> Personally, I agree that having tighter semantics are a good thing here
>>> (and should be covered by the solution draft).
>> Then I note that the requirement is at least not well defined.
>Perhaps, but we had already spent a long time discussing the 
>requirements draft, hence personally I think that it is OK to 
>specify/agree the precise semantics/behaviour in a solution draft.

Not just that, but it was the decision we made as a WG, and why the 
requirements say "The configuration protocol MUST specify how configuration 
errors are handled.” - right?



 Second, in order to rollback, there needs to be a configuration that
 can be safely rolled back into. The only robust way I can imagine to
 implement this rollback requirement is to use locks until the whole
 new config has been applied, thereby turning an asynchronous system
 into a synchronous system. Otherwise, I fail to see how I can ensure
 that I have a configuration that can be safely rolled back into.
>>> Locks are the simplest way of implementing this, but I agree that they
>>> defeat the point of async configuration updates.
>>>
>>> I don't think that locking is the only way to solve this.  I would have
>>> thought that one of the optimistic transactional locking approaches
>>> could be used to process multiple requests concurrently.
>> As long as it is clear to which configuration to roll back to. Once
>> you process multiple requests concurrently, this is not at all clear,
>> at least not to me.
>Logically, the system must revert to a state where the failed 
>configuration request was never applied.  I think this is the only 
>guarantee that is being made to the client.
>
>One way to achieve this would be rollback the configuration (intended 
>and applied) back to exactly the point before that failed request (or 
>any other request) was processed.
>
>Any concurrent configuration requests that were previously in progress 
>would then need to be re-applied one by one (in the same order).