Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

add Huawei device support through YANG #242

Merged
merged 2 commits into from
Jul 12, 2018
Merged

Conversation

nickylba
Copy link
Contributor

The existing huawei.py device having some private capabilities in , like "http://www.huawei.com/netconf/capability/exchange/1.0", which tell the connected NE (network element) to work in private work-mode.

In order to ask NE to work in standard way that accpeting only RFC compatible rpc and reply with standard rpc-reply, huaweiyang.py is added

The existing huawei.py device having some private capabilities in <hello>, like "http://www.huawei.com/netconf/capability/exchange/1.0", which tell the connected NE (network element) to work in private work-mode. 

In order to ask NE to work in  standard way that accpeting only RFC compatible rpc and reply with standard rpc-reply, huaweiyang.py is added
@coveralls
Copy link

Coverage Status

Coverage decreased (-0.6%) to 68.465% when pulling 4c95477 on nickylba:master into 23df9a7 on ncclient:master.

@coveralls
Copy link

coveralls commented Jun 19, 2018

Coverage Status

Coverage decreased (-1.2%) to 68.044% when pulling ad132ec on nickylba:master into 434b03b on ncclient:master.

@einarnn
Copy link
Contributor

einarnn commented Jul 1, 2018

Can you please explain in more detail what this PR is attempting to achieve?

@einarnn einarnn added the Waiting Waiting for a response from issue or PR author or for someone to volunteer to pick up an enhancement label Jul 1, 2018
@nickylba
Copy link
Contributor Author

nickylba commented Jul 4, 2018

Hi, the Huawei routes can work in two mode:

  1. schema: in this mode it can accept rpc in format like below, which have some private attribute. This is private behaviour of huawei routers
<rpc message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
  <get-config>
    <source>
      <candidate/>
    </source>
    <filter>
      <ifm xmlns="http://www.huawei.com/netconf/vrp" content-version="1.0" format-version="1.0">
      </ifm>
    </filter>
  </get-config>
</rpc>
  1. yang: in this mode it can accept rpc in RFC format (must not have private attribute)
<rpc message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
  <get-config>
    <source>
      <candidate/>
    </source>
    <filter>
      <ifm xmlns="http://www.huawei.com/netconf/vrp/huawei-ifm">
      </ifm>
    </filter>
  </get-config>
</rpc>

The key difference in the rpc is the xmlns/format-version/content-version in the node "ifm". And We are using "hello" to to diff this two work-mode now, if it carry any private capabilities (ex. 'http://www.huawei.com/netconf/capability/exchange/1.0') presentd in huawei.py, it will work in schema-mode; if it carry only base 1.0 (urn:ietf:params:netconf:base:1.0) OR base 1.1, it will work in yang-mode

so we need another huaweiyang.py to connect to the huawei router in yang mode

thanks

@einarnn einarnn merged commit ed613f1 into ncclient:master Jul 12, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Waiting Waiting for a response from issue or PR author or for someone to volunteer to pick up an enhancement
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants