Create new union for ip and te-node-id

[tsaad-dev]

replace upstream/downstream_info ip-address with union

[tsaad-dev]

addressed in 410ec61

[italobusi]

2020-02-21 Call

There is an ambiguity between IPv4 address and te-node-id

Needs more discussion since the attribute is used as part on a key

[tsaad-dev]

2.2.2.2: TE node-ID
1.1.1.1 : IP address

Option #1
global leaf per TE topology
leaf address-type
IP-address or TE node ID

Option #2 (issue with lists as a key):
grouping generic-node-id {
leaf node-id-type
IP-adress
leaf node-id-value
1.1.1.1
}

Option #3 :
leaf is a composite string
ip:1.1.1.1
id:2.2.2.2
ip:2001::1

OPTION 4:
list key: "node-id, source-ip"

leaf1
source-ip
1.1.1.1

leaf2
node-id
2.2.2.2

Agreement is to adopt option #2.

[tsaad-dev]

option #2 (enhanced):
introduce new index for the list (running index).
Then you can add a choice (or new type)
Add unique on combination.

[italobusi]

Please note that IEEE is using a string as key instead of a running index:

https://github.com/YangModels/yang/blob/fe74c496e21e938be740fc756ea94525f2c13339/standard/ieee/draft/802.1/Qcx/ieee802-dot1q-cfm-types.yang#L692-L700

One possible advantage could be more implementation freedom: an implementation can encode in the string a running index or the association information using some rules, such as:

/<type>/<id>/te-node-id/<source/te-node-id>/ | /<type>/<id>/ip-address/<source/ip-address>/

This would be similar to the relationship between the network-id attribute, defined in RFC83345, and the provider-id, client-id and topology-id attributes, defined in te-topology.

[italobusi]

@tsaad-dev : I think we can close this issue now