netconf-state monitoring support

[abierman]

o Should long-term RESTCONF operations (i.e. SSE long-poll) be
considered sessions with regards to NETCONF monitoring "session"
list? If so, what text is needed in RESTCONF draft to standardize
the RESTCONF session entries?

Proposal at Toronto IETF accepted for evaluation

● RFC 6022 not clear if non NETCONF protocol sessions are still sessions “managed by the NETCONF server” or not

Proposal to be implemented:
– Re-interpret 6022 restrictions to include all NM sessions that are managed by the server, such as RESTCONF

• Add transport identities to support additional transports

[abierman]

Need to track authentication as a new issue.
Should session-based auth be supported?
Currently each message is authenticated and no session state is kept

[abierman]

Do we need to have a 6022-bis document or can RESTCONF just update the text
in order to support non-NETCONF sessions.

[abierman]

Still need to add identities to RESTCONF for the session list

[abierman]

Resolution from IETF #90 in Toronto:

A new data structure to monitor streams can be added
to the netconf-state sub-tree. The session-id in
this new data structure is not restricted to the
NETCONF-only rules for the sessions sub-tree.

Update after RESTCONF Virtual Interims for draft-02:

There is a desire to identify all admin sessions, however a
layered approach is needed which allows generic session
reporting, plus protocol-specific extensions.
Not all server implementations can detect HTTP sessions.
It is possible that session information can be derived
from the TLS transport layer.

The streams data structure is moved from the ietf-restconf
module to the ietf-restconf-monitoring module.

Session monitoring for RESTCONF will not be added to the netconf-state
data structure in RFC 6022. There are too many objects
(such as NETCONF-specific counters) that do not apply
to RESTCONF.

RESTCONF session monitoring will not be added to ietf-restconf-monitoring
at this time.

[mbj4668]

Andy Bierman notifications@github.com wrote:

Resolution from IETF #90 in Toronto:

A new data structure to monitor streams can be added
to the netconf-state sub-tree. The session-id in
this new data structure is not restricted to the
NETCONF-only rules for the sessions sub-tree.

Update after RESTCONF Virtual Interims for draft-02:

There is a desire to identify all admin sessions, however a
layered approach is needed which allows generic session
reporting, plus protocol-specific extensions.
Not all server implementations can detect HTTP sessions.
It is possible that session information can be derived
from the TLS transport layer.

The streams data structure is moved from the ietf-restconf
module to the ietf-restconf-monitoring module.

Session monitoring for RESTCONF will not be added to the netconf-state
data structure in RFC 6022. There are too many objects
(such as NETCONF-specific counters) that do not apply
to RESTCONF.

RESTCONF session monitoring will not be added to ietf-restconf-monitoring
at this time.

Did you mean "NETCONF session monitoring will not be added"? If not,
what does this last sentence mean?

Will we also have RESTCONF specific counters in this module?

/martin

[abierman]

The proposal is to just have "capabilities" and "streams" in the monitoring
module and add RESTCONF session monitoring later.
The goal is to use the netconf-state session list for generic information
(using the transport identity "restconf-tls"), but to put RESTCONF specific
session information in a different module. The NETCONF-specific
session counters (for example) need to apply only to N$ETCONF sessions.
We could use "augment + when" to add transport-specific data
to the generic session entries.

[kwatsen]

Given that mutual certificate-based auth (just like netconf-tls) is going to be required, HTTP persistent connections are critical for performance. Thus, I propose:

1. we require HTTP/1.1 // where persistent connections are default
2. we recommend setting server timeout to a high value // apache: "KeepAlive On" "KeepAliveTimeout 3600"

Note: apache default is 5 seconds, which is OK for heavily loaded servers, but that's not RESTCONF usage is not high (max num simultaneous northbound connections is small).

If this is done, then we can reliably count RESTCONF sessions

[abierman]

Update VI meeting 2014-10-21:

There was no consensus in the meeting to require HTTP 1.1 persistent connections.
Therefore there is still no consensus about RESTCONF session monitoring
because RESTCONF does not define sessions in the protocol.
Future work may be needed to define a standard definition of a RESTCONF over TLS session
so that can be monitored.

There is agreement that the ietf-netconf-monitoring 'session' list should
have at least common information, and the protocol specific definitions
should be separated. The "augment + when" design pattern can be used
to apply the appropriate statistics definitions depending on the protocol.

A protocol identity called "restconf-tls" will be defined to represent RESTCONF
over TLS sessions.

[abierman]

After WG mailing list review, solution S-0 is adopted.
The restconf-tls identity will not be added to -04.
There will be no mention of RESTCONF session monitoring in the draft.

[abierman]

considered resolved in -04