Open Transport Configuration & Control
Space shortcuts
Expand all   Collapse all
Child pages
  • Frequently Asked Questions

Versions Compared

Old Version 22

changes.mady.by.user Nigel Davis

Saved on

compared with

New Version Current

changes.mady.by.user Karthik Sethuraman

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Contents

Table of Contents
maxLevel3
minLevel3
indent15px

Note to editors: Please style the question as "Heading 3" and answer as normal "Paragraph" (see an existing question). Please simply add to the end of the list of existing questions.

Are all attributes in the TAPI models are mandatory, or does the controller have flexibility to choose attributes?

The UML model provides clarity on which attributes are intended to be mandatory. The Yang (derived from the UML using tooling) is somewhat looser. Most attributes are optional in the Yang. We do aim to tighten this up a little.

Where you cannot map an attribute, e.g., because the feature or aspect of technology is not present in the device or in the controller, the attribute can either be omitted (i.e., can be considered as not mandatory) or, if available in the definition, set to a relevant default value or null value.

Is it necessary to support the node-rule-group capability?

You can choose to not support node-rule-group in which case all potential connection opportunities in the node are assumed to be allowed. If you choose to support node-rule-group, then you can model to whatever depth you consider appropriate for your application. Clearly, the deeper and more precise the model, the more often a client based path computation capability will choose valid routes without requiring supplementary information.

Is it necessary to provide the pin-identification in connector-pin-address for all cases?

The intention is that there is sufficient detail to allow an understanding of which connectors and, where relevant, pins the signal passes through. The pin is only relevant if the connector carries several modeled signals. This is to help diagnostics where the cable/connector may be faulty and to clarify how the signal traverses in a complex wiring environment (recognizing that we are intentionally not covering outside plant). The specific identification ought to be that that would be meaningful to a person standing at the equipment. But you can choose to be less precise if the application would not benefit from this detail. Where the pin detail is not relevant it can be omitted.

Should RPC be used?

The aim is to not use RPC but to instead use standard Restconf/OAS operations. We are intending to remove the RPCs in a later release. We suggest that you explore the Restconf approach or the OAS approach.