On 09/05/2019 13:27, Martin Sandberg wrote: > Hi Ajay, > > > > Sorry, I can’t really describe the signaling sequence more than that. I > have basically no knowledge about the code, I have only tested ODL a > bit, and observed the behavior I described below. I don’t actually know > for a fact how ODL reads up the models from the node after the Hello > message exchange, it’s just an assumption that a <get> on RFC 7895 > /modules-state is done, and then uploads each of those models. Hopefully > others who knows the code much better can answer detailed questions.
Hello, the issue here is discovery of what modules does a particular server support, which we need to know in order to form our understanding of the data that can be exchanged with it. The baseline specification here is RFC6020, which requires all models to be announced: https://tools.ietf.org/html/rfc6020#section-5.6.4 This obviously is inefficient and does not support transfer of schemas, which is required for seamless connection establishment. An alternative is RFC6022 (ietf-netconf-monitoring), which optional to implement. This mistake was rectified in YANG 1.1 (RFC7950), which refers to RFC7895 (ietf-yang-library) to provide capabilities similar to RFC6022. Hence our connection bootstrap process occurs in two phases, where the first phase bootstraps the basic understanding of models based on advertisement in <hello/>, which allows us to start talking to the device -- i.e. interact with RFC6022/RFC7895, at which point we establish the connection based on the combined understanding of the device's schema. > If you turn on detailed tracing, you can maybe see the exact signaling > sequence. Yup, the sequence can be inferred at TRACE level, where netconf becomes very chatty about what it is doing. > Since the trace is only a WARNing, I guess it shouldn’t be treated as > something that is breaking anything, but I agree it could maybe have > sufficed as a INFO trace. Actually, the code should be re-visited to suppress the warning in case of :yang-library(:1.1) capability presence, as that is a promise that yang-library is available and the server is following RFC7950 specification. If the capability is not present, the warning still has to be present there, as in that case we are dealing with an inconsistent RFC6020/RFC6022 server. > I think our reason to only advertise the basic capabilities in the Hello > message is to be able to protect access to more sensitive > application-specific models via <get> on /modules-state by applying > access control mechanisms on that part of the model. That, and also to keep the <hello/> message small. Regards, Robert
signature.asc
Description: OpenPGP digital signature
_______________________________________________ controller-dev mailing list controller-dev@lists.opendaylight.org https://lists.opendaylight.org/mailman/listinfo/controller-dev
