openconfig / reference

This repository contains reference implementations, specifications and tooling related to OpenConfig-based network management.
Apache License 2.0
155 stars 88 forks source link

gNMI Path containing elements from multiple models #102

Open Pyro2266 opened 6 years ago

Pyro2266 commented 6 years ago

Let's say target uses data defined by yang files. These yang files contains augmentations between them. How should gNMI Path look in case of multiple augmentations in one path? Or if two different yangs augment same element in same model with same element names? How can I specify to which model I want to point?

I found that Path can contain origin, which can be (according to specification) used to disambiguate path. But it can be defined only once per path. So this will not work in case of multiple augmentations in one path.

For example this is container I want to augment:

container top-level-container {
    leaf some-value {
        type string;    
    }
}

This is first augmentation from one model:

augment "/xxx:top-level-container" {
    container augmented-container {
        leaf augmented-leaf {
            type int32;
        }        
    }
}

And this is second augmentation from another model:

augment "/xxx:top-level-container" {
    container augmented-container {
        leaf augmented-leaf {
            type string;
        }        
    }
}
robshakir commented 6 years ago

Different origins can define the format of their path. For example, one origin could specify that it names its path elements specifically in the form "module:element-name". Within the "openconfig" origin, we specify that augmentations within this curated namespace MUST NOT overlap - and hence do not include the module name.

Augmenting overlapping names into modules has really negative impacts on usability of models, and should be discouraged. The approach of not including module names specifically signals that naming choices within this origin should be designed to not be ambiguous.

Pyro2266 commented 6 years ago

So origin defines rules how should be path handled/what should it look like? For example format of the PathElem? Who defines these origins? Should it not be standardized?

If I understand it correctly, the target device (server) must know all the origins (from its capabilities) and handle every path differently according to its origin? In addition client must know these rules too and send them correctly to server.

If yes, can I list all origins and their rules somewhere?

robshakir commented 6 years ago

The origins are defined based on the modules that are supported. OpenConfig defines an origin that never uses the module name within it. gNMI does not seek to standardise this because it is a generic protocol for transporting data that conforms to the rules defined in the spec introduction.

Each origin that is addressed by gNMI should define this behaviour. This is part of the contract which is established by the model between client and target.