cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
79
Views
1
Helpful
8
Replies
Highlighted
Cisco Employee

Q on YANG modelling for optional leafs

how would I handle the following requirement in YANG?

    • Model contains
      • Interface config: Interfacename, address, mask, etc
      • Static Routes: Address, mask, interface, metric, etc

If leaf “Interface” is not set as part of the static Route, we should use the Interfacename from the corresponding Interface config, else use the “Interface” provided as part of the static route.

Can I model the StaticRoute/Interface leaf as a union of leafref and string, with the first being the default ?

1 ACCEPTED SOLUTION

Accepted Solutions
Highlighted
Cisco Employee

The Yang file is attached. The tree-based output is easier to read though.

> I’m referring especially to the following elements:

>

> a)

> AuftragAnschluss/Anschluss/PeRouter/StatischeRoute/IPv4Route/Interface

> b)

> AuftragAnschluss/Anschluss/PeRouter/VerbindungVomPeZumCpe/RouterIFC/SN

> MP-De

> scription

View solution in original post

8 REPLIES 8
Highlighted
Cisco Employee

This is not possible today, but will be allowed in YANG 1.1.   Today you'd have to simply model this as a string and describe the relationship in text.

But isn't the Interface a leafref even if it was provided as part of the static route?

Highlighted
Cisco Employee

Not sure I understand well the 2nd part.

If the Interface is provided as part of the service, everything is easy and I can use this leaf for filling the mapping templates.

If not provided, I could:

- use Java to to find the info and provide it as variable to the template

- use XPATH to different trees in the service to fill the template

- (my hope): tell the yang model, what should be the default, if it is not provided

Would be great to have the XML mapping agnostic whether the Interface leaf is provided or not.

Highlighted
Cisco Employee

Hi,

not sure my last reply was perceived as a question. Assuming Java code would be the only way to achieve this currently?

Highlighted
Cisco Employee

I think the lack of responses may be due to difficulties in parsing the question. I for one don’t understand what you’re looking for. Perhaps it would be easier to understand if you pasted your YANG here and gave an example config.

Highlighted
Cisco Employee

You can definitely use default values in YANG for configuration leaf elements and not require the user to always specify a value. Is this what you are looking for?

The YANG statement is:

default <value>;

Highlighted
Cisco Employee

The Yang file is attached. The tree-based output is easier to read though.

I’m referring especially to the following elements:

a) AuftragAnschluss/Anschluss/PeRouter/StatischeRoute/IPv4Route/Interface

b)

AuftragAnschluss/Anschluss/PeRouter/VerbindungVomPeZumCpe/RouterIFC/SNMP-De

scription

a) is optional.

b) is mandatory

If a) is provided: use it.

If a) is not provided, then use b)  (let’s ignore for the moment RouterIFC

is a list).

Summarising, I would need the default to be the path b) if a) is not

provided.

I hope this explains a bit better what I’m trying to do.

Highlighted
Cisco Employee

The Yang file is attached. The tree-based output is easier to read though.

> I’m referring especially to the following elements:

>

> a)

> AuftragAnschluss/Anschluss/PeRouter/StatischeRoute/IPv4Route/Interface

> b)

> AuftragAnschluss/Anschluss/PeRouter/VerbindungVomPeZumCpe/RouterIFC/SN

> MP-De

> scription

View solution in original post

Highlighted
Cisco Employee

many thanks for the hints.

So I should put the intelligence in the XML template, not the YANG model.

Sounds doable and looks nice.

Regarding the other 3 points:  (many thanks for the quick review)

- naming convention: Will correct for phase 2. Demo is next week, so bad time to mess with the names in yang and java.

- Patterns/ranges: Also planned for phase 2 and on my list. prio was given on the service deployment though for now.

- CoCo Instance:

Idea was having a container ³CoCo² for the sum of all CoCo Services. This container has a list of Orders that represent service instances.

I now understand I should re-model this and have CoCo as a list. Could be the reason I went for the current way to be compatible with the NB XML template we receive.

Content for Community-Ad
Cisco Community October 2020 Spotlight Award Winners