On 09/05/2019 14:02, Robert Varga wrote:
> 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
>
_______________________________________________
controller-dev mailing list
controller-dev@lists.opendaylight.org
https://lists.opendaylight.org/mailman/listinfo/controller-dev
