opennetworkingfoundation / configuration Goto Github PK

I tested the console for Cisco Nexus and it worked fine.
Now testing for Juniper, I don't get any response for the bgp payload that I sent in.
I checked the logs at the device end and I see the following:

Jul 21 20:03:36 [NETCONF] Started tracing session: 27008
Jul 21 20:03:36 [NETCONF] - [27008] Outgoing: <!-- No zombies were killed during the creation of this user interface -->
Jul 21 20:03:36 [NETCONF] - [27008] Outgoing: <!-- user root, class super-user -->
Jul 21 20:03:36 [NETCONF] - [27008] Outgoing: <hello xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
Jul 21 20:03:36 [NETCONF] - [27008] Outgoing:   <capabilities>
    <capability>urn:ietf:params:netconf:base:1.0</capability>
    <capability>urn:ietf:params:netconf:capability:candidate:1.0</capability>
    <capability>urn:ietf:params:netconf:capability:confirmed-commit:1.0</capability>
    <capability>urn:ietf:params:netconf:capability:validate:1.0</capability>
    <capability>urn:ietf:params:netconf:capability:url:1.0?scheme=http,ftp,file</capability>
    <capability>urn:ietf:params:xml:ns:netconf:base:1.0</capability>
    <capability>urn:ietf:params:xml:ns:netconf:capability:candidate:1.0</capability>
    <capability>urn:ietf:params:xml:ns:netconf:capability:confirmed-commit:1.0</capability>
    <capability>urn:ietf:params:xml:ns:netconf:capability:validate:1.0</capability>
    <capability>urn:ietf:params:xml:ns:netconf:capability:url:1.0?protocol=http,ftp,file</capability>
    <capability>http://xml.juniper.net/netconf/junos/1.0</capability>
    <capability>http://xml.juniper.net/dmi/system/1.0</capability>
Jul 21 20:03:36 [NETCONF] - [27008] Outgoing:   </capabilities>
Jul 21 20:03:36 [NETCONF] - [27008] Outgoing:   <session-id>27008</session-id>
Jul 21 20:03:36 [NETCONF] - [27008] Outgoing: </hello>
Jul 21 20:03:36 [NETCONF] - [27008] Outgoing: ]]>]]>
Jul 21 20:03:36 [NETCONF] - [27008] Incoming: <?xml version="1.0" encoding="UTF-8"?>
<hello xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
  <capabilities>
    <capability>urn:ietf:params:netconf:base:1.0</capability>
    <capability>urn:ietf:params:netconf:base:1.1</capability>
 
    </capabilities>
</hello>]]>]]>
Jul 21 20:03:36 [NETCONF] - [27008] Incoming:
#144
<?xml version="1.0" encoding="UTF-8"?>
                <rpc xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"
                     message-id="1">
#205
<rpc>
<get-config>
        <source><running/></source>
        <filter type="subtree">
            <bgp xmlns="http://openconfig.net/yang/bgp">
            </bgp>
        </filter>
    <get-config>
</rpc>
 
#6
</rpc>
##
 
Jul 21 20:03:36 [NETCONF] - [27008] Outgoing: <!-- netconf error: unknown command -->
Jul 21 20:03:36 [NETCONF] - [27008] Debug: The last token parsed by mgd [27008] was [
#144] and gram data current token [
#144]
Jul 21 20:03:36 [NETCONF] - [27008] Outgoing: <!-- session end at 2017-07-21 20:03:36 UTC -->

I tested the same payload, directly via ssh, and it worked. This is my payload:

<rpc>
    <get-config>
        <source><running/></source>
        <filter type="subtree">
            <bgp xmlns="http://openconfig.net/yang/bgp">
            </bgp>
        </filter>
    </get-config>
</rpc>
]]>]]>


Any pointers on where I could be going wrong with this?

I am trying to generate xml output using pyang -f xsd --xsd-groups --xsd-no-any-augments filename.yang

Input Yang file:
module toaster {

yang-version 1;

namespace
"http://netconfcentral.org/ns/toaster";

prefix toast;

organization "Netconf Central";

contact
"Andy Bierman [email protected]";

description
"YANG version of the TOASTER-MIB.

Copyright (c) 2009 Andy Bierman and the persons identified as
authors of the code. All rights reserved.

Redistribution and use in source and binary forms, with or
without modification, is permitted pursuant to, and subject
to the license terms contained in, the BSD 3-Clause License
http://opensource.org/licenses/BSD-3-Clause";

revision "2009-11-20" {
description
"Toaster module in progress.";
}

identity toast-type {
description
"Base for all bread types supported by the toaster.
New bread types not listed here nay be added in the
future.";
}

identity white-bread {
base toast:toast-type;
description "White bread.";
}

identity wheat-bread {
base toast-type;
description "Wheat bread.";
}

identity wonder-bread {
base toast-type;
description "Wonder bread.";
}

identity frozen-waffle {
base toast-type;
description "Frozen waffle.";
}

identity frozen-bagel {
base toast-type;
description "Frozen bagel.";
}

identity hash-brown {
base toast-type;
description "Hash browned potatos.";
}

typedef DisplayString {
type string {
length "0 .. 255";
}
description
"YANG version of the SMIv2 DisplayString TEXTUAL-CONVENTION.";
reference
"RFC 2579, section 2.";

}

container toaster {
presence
"Indicates the toaster service is available";
description
"Top-level container for all toaster database objects.";
leaf toasterManufacturer {
type DisplayString;
config false;
mandatory true;
description
"The name of the toaster's manufacturer. For instance,
Microsoft Toaster.";
}

leaf toasterModelNumber {
  type DisplayString;
  config false;
  mandatory true;
  description
    "The name of the toaster's model. For instance,
         Radiant Automatic.";
}

leaf toasterStatus {
  type enumeration {
    enum "up" {
      value 1;
      description
        "The toaster knob position is up.
                No toast is being made now.";
    }
    enum "down" {
      value 2;
      description
        "The toaster knob position is down.
                Toast is being made now.";
    }
  }
  config false;
  mandatory true;
  description
    "This variable indicates the current state of 
         the toaster.";
}

} // container toaster

rpc make-toast {
description
"Make some toast.
The toastDone notification will be sent when
the toast is finished.
An 'in-use' error will be returned if toast
is already being made.
A 'resource-denied' error will be returned
if the toaster service is disabled.";
input {
leaf toasterDoneness {
type uint32 {
range "1 .. 10";
}
default '5';
description
"This variable controls how well-done is the
ensuing toast. It should be on a scale of 1 to 10.
Toast made at 10 generally is considered unfit
for human consumption; toast made at 1 is warmed
lightly.";
}

  leaf toasterToastType {
    type identityref {
      base toast:toast-type;
    }
    default 'wheat-bread';
    description
      "This variable informs the toaster of the type of 
             material that is being toasted. The toaster 
             uses this information, combined with 
             toasterDoneness, to compute for how 
             long the material must be toasted to achieve 
             the required doneness.";
  }
}

} // rpc make-toast

rpc cancel-toast {
description
"Stop making toast, if any is being made.
A 'resource-denied' error will be returned
if the toaster service is disabled.";
} // rpc cancel-toast

notification toastDone {
description
"Indicates that the toast in progress has completed.";
leaf toastStatus {
type enumeration {
enum "done" {
value 0;
description "The toast is done.";
}
enum "cancelled" {
value 1;
description
"The toast was cancelled.";
}
enum "error" {
value 2;
description
"The toaster service was disabled or
the toaster is broken.";
}
}
description
"Indicates the final toast status";
}
} // notification toastDone
} // module toaster

Need to discuss the life cycle of the list of ports available in capable-switch. E.g. if there are physical ports on the device, are they pre-populated, and what does it mean to remove an enty in this list? Use cases will be helpful.

The port list is here:
https://github.com/OpenNetworkingFoundation/configuration/blob/master/drafts/of-config.yang#L393

We make use of resource-id in a couple of places. Resource-id is of type inet:uri and is described to uniquely identify ports and other resources. YANG provides means of uniquely identifying instances using instance-id (http://tools.ietf.org/html/rfc6020#section-9.13).

An example of the use of resource-id is here:
https://github.com/OpenNetworkingFoundation/configuration/blob/master/drafts/of-config.yang#L413

There is a fairly complicated must-constraint on the port list that I suggest we remove. It depends on operational data (e.g. the current rate of the port) which is a complicated and thorny issue.

The must statement is here:
https://github.com/OpenNetworkingFoundation/configuration/blob/master/drafts/of-config.yang#L398