[Contents] [Prev] [Next] [Index] [Report an Error]

Verifying Compatibility

Exchanging <hello> tag elements enables a client application and the NETCONF server to determine if they support the same capabilities. In addition, we recommend that the client application determine the version of the SRC software running on the NETCONF server. After emitting its<hello> tag element, it emits the <get-system-info> tag element in an <rpc> tag element:




<rpc>
    <get-system-info/> 

</rpc>
]]>]]>

The NETCONF server returns the <system-info> tag element, which encloses the <system-identification> and <software-version> tag elements. (For information about the <rpc-reply> tag element, see Parsing the NETCONF Server Response.) Some tag elements appear on multiple lines, for legibility only:




<rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" \
                xmlns:sdx="http://xml.juniper.net/junos/sdx/1.0">
    <system-info>
        <system-identification>
            <software-version>SRC Release 2.0.0</software-version>
            <!- - other <system-identification> child tag elements - ->

        </system-identification>
        <!- - other <system-info> child tag elements - ->

    </system-info>
</rpc-reply>
]]>]]>

Normally, the version is the same for all SRC software components running on the C-series Controller. (We recommend this configuration for predictable performance.) The client application can determine the version of the SRC software components running on the NETCONF server by emitting the <get-component-all> tag element in an<rpc> tag element:




<rpc>
    <get-component-all/> 

</rpc>
]]>]]>

The NETCONF server returns the <sdx-component-list> tag element, which encloses the <sdx-component> tag elements plus a <version> tag element for each installed SRC software component. (For information about the <rpc-reply> tag element, see Parsing the NETCONF Server Response.) The <version> tag element within the <sdx-component> tag element specifies the SRC release number (in the following example, 2.0 for SRC Release 2.0) and the build information. Some tag elements appear on multiple lines, for legibility only:




<rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" \
                xmlns:sdx="http://xml.juniper.net/junos/sdx/1.0">
    <sdx-component-list>

        <sdx-component>

            <status>stopped</status>
            <version>Release: 2.0 Build: ACP.B.2.0.0.001</version>
            <name>acp</name>
        </sdx-component>

        <!- - other <sdx-component> tag elements - ->


        <sdx-component>

            <status>running</status>
            <version>Release: 2.0 Build: WEBADM.B.2.0.0.001</version>
            <name>webadm</name>
        </sdx-component>

    </sdx-component-list>

</rpc-reply>
]]>]]>

In the NETCONF API for SRC, it is the responsibility of the client application to determine how to handle any differences in version or capabilities. For fully automated performance, include code in the client application that determines whether it supports the same capabilities and SRC version as the NETCONF server. Decide which of the following options is appropriate when there are differences, and implement the corresponding response:

Ignore differences in capabilities and SRC version, and do not alter the client application’s behavior to accommodate the NETCONF server. A difference in SRC versions does not necessarily make the server and client incompatible, so this is often a valid approach. Similarly, it is a valid approach if the capabilities that the client application does not support are operations that are always initiated by a client, such as validation of a configuration and confirmed commit. In that case, the client maintains compatibility by not initiating the operation.
Alter standard behavior to be compatible with the NETCONF server. If the client application is running a later version of the SRC software, for example, it can choose to emit only NETCONF and SRC XML tag elements that represent the software features available in the NETCONF server’s version of the software.
End the NETCONF session and terminate the connection. This is appropriate if you decide that it is not practical to make the client application accommodate the SRC version or capabilities supported by the NETCONF server. For instructions, see Ending a NETCONF Session and Closing the Connection.

[Contents] [Prev] [Next] [Index] [Report an Error]