Section 3.1 - DDL for JUNOS Configuration Statements

UI Infrastructure Programmer's Guide

3.1.1. Defining Data Hierarchy

For configuration mode, 'object' and 'attribute' are the basic DDL data structures. 'object' is the container and 'attribute' is a terminal node. An object can contain muliple other objects and attributes, and a type has to be defined for each attribute.

In configuration mode, all the top-level objects are listed in order.cnf.dd. The remaining objects are coded in the individual daemon DDL input files, *.cnf.dd.

JUNOS has a rich set of built-in types to describe the objects and attributes. Choose the appropriate data type to ensure proper user input. The type should accurately characterize this input.

It is important to construct the configuration hierarchy and the operational commands with self-explanatory structures, naming keywords for {object, attribute} so that they can be easily understood by users.

Following are the available types for the JUNOS configuration mode:

Common data types
-----------------
numerical: type sbyte
	   type ubyte
	   type short
	   type ushort
	   type int
	   type sint
	   type uint
	   type int64
	   type sint64
	   type uint64
	   type sfloat
	   type ufloat
string:	   type string
time:	   type time
boolean:   type toggle

Network-related types
---------------------
IP address:   type ipaddr
              type ipv4addr
              type ipv6addr
              type ipprefix-mandatory
              type ipv4prefix-mandatory
              type ipv6prefix-mandatory
              type ipprefix
              type ipv4prefix
              type ipv6prefix
	      type ipprefix-optional
	      type ipv4prefix-optional
	      type ipv6prefix-optional
	      type ipprefix-accept
	      type ipv4prefix-accept
	      type ipv6prefix-accept
	      type ipprefix-only
	      type ipv4prefix-only
	      type ipv6prefix-only
ISO address:  type isoaddr
MAC address:  type macaddr
MPLS:	      type mpls-label
OSPF:	      type areaid
BGP:	      type community
ATM:	      type atm-vci
interface:    type interface-device
	      type interface-unit
	      type interface-wildcard
IP/interface: type ipaddr-or-interface
	      type ipv4addr-or-interface
	      type ipv6addr-or-interface

Special-function types
----------------------
	      type regular-expression
	      type setof policy-algebra
	      type secret
	      type filename

Type Modifiers

There are a few modifiers that can be applied to certain types.

ranged is used to limit the range of the valid inputs. It can be used for string and numerical types.

setof and list allow a list of the objects or attributes to be configured. This can be applied to all configuration types.

        object test-object {
            help "Example of an object";

            attribute test-attribute {
                help "Example of an attribute";
                type ranged uint 1 .. 10;
            }
        }

3.1.2. Defining Help Messages

Help messages are displayed when users type '?' to query the available commands. Hence, it is important for programmers to supply the appropriate help messages.

The only rule to help messages is that they have to begin with capital letters. It is prudent that such messages are precise and concise so that they can be displayed in the limited space.

Example 1 help messages

        user@router# set test?
        Possible Completions:
        test-object             Example of an object

        [edit]
        user@router# set test-object ?
        test-attribute          Example of an attribute

        [edit]

3.1.3. Characterizing DDL entities

Once the {object, attribute} entities are defined, it is essential to characterize these UI keywords in more detail.

Constraints

Using constraints can ensure proper user input. Add constraints when the DDL input is first implemented, as adding constraints later may break existing configurations. The following are some possible constraints one can apply:

The must Statement

Sometimes it is necessary to prevent the user from configuring one object unless another one is or is not also configured. The must statement allows you to specify existence constraints such as

When such a constraint is violated, the user sees a warning on giving the 'show' command, or an error on 'commit'. You are required to specify the warning or error text using the 'must-message' statement.

The recognized operators are the usual logical operators and two keyword operators: AND and OR.

expr := term | term OR expr
term := factor | factor AND term
factor := NOT factor | subfactor
subfactor := ( expr ) | path | K_ANY path | K_ALL path

where OR is expressed as ||, AND as &&, NOT as !, K_ANY as any, K_ALL as all, and anything more complex than a path should be put in parentheses.

Paths are expressed in the same way as they are for the 'path-reference' statement, except that you cannot use ';' to assemble several paths. You can use the wildcard in a path. The logical operator implied among multiple statements sharing the wildcard path must be explicitly specified using the keywords 'all' or 'any', where all means && and any means ||.

'must' cannot be used in conjunction with 'prune-unchanged'.

The match Statement

'match' is a very simple constraint statement. It limits the user inputs to match the pattern (using regular expression) defined by the DDL programmer.

The accompanying 'match-message' statement must be defined when 'match' is used. It lets users to know exactly what format is expected for the configuration statement.

Flags

'Flag' is a generalized function in DDL to characterize DDL entities. In addition to supplying constraints, flags can be used to affect the DDL entities in display (presentation in the CLI), augment or provide specialized purpose of the data type, or provide special instructions for mgd to communicate the data entity to other daemons or processes.

Each DDL entity can contain one or more flags, which control aspects of that entity. Most of these flags can modify any of the major entities, including commands and objects, attributes and arguments, and even choices.

Flags are defined using the 'flag' keyword. The level in the DDL structure at which the flag is defined is the level for which it is active. Multiple flags can be defined on a single line and multiple lines of flags work identically as if they are defined on the same line.

Display-related flags
---------------------
	autosort
	cells
	helpful
	homogeneous
	k1000
	kilo
	no-struct
	nokeyword
	oneliner
	oneliner-plus
	oneset
	phantom
	remove-empty
	secret
	strict-order
	text-choice

Constraint flags
----------------
	allow-atmvpn
	allow-iso-addr
	allow-iso-prefix
	allow-iso-sysid
	allow-mask
	allow-no
	date-only
	disallow-martians
	long
	mandatory
	multicast-only
	no-apply
	no-fips
	on-all-re
	multicast-only
	time-only

Special Purpose
---------------
	advanced
	identifier
	mustquote
	positional
	quoted
	setof list
	unquoted
	prune-lcc
	prune-unchanged

Other DDL statements

Similar to the available DDL flags, there are other DDL statements which can be used as constraints, and other purposes.


2007-2009 Juniper Networks, Inc. All rights reserved. The information contained herein is confidential information of Juniper Networks, Inc., and may not be used, disclosed, distributed, modified, or copied without the prior written consent of Juniper Networks, Inc. in an express license. This information is subject to change by Juniper Networks, Inc. Juniper Networks, the Juniper Networks logo, and JUNOS are registered trademarks of Juniper Networks, Inc. in the United States and other countries. All other trademarks, service marks, registered trademarks, or registered service marks are the property of their respective owners.
Generated on Sun May 30 20:23:10 2010 for JUNOS UI Programmer's Guide by Doxygen 1.4.5