Subject: [Supa] Review of draft-zaalouk-supa-configuration-model-00

From: JF Tremblay <[email-masked]>
Date: Mon, 29 Sep 2014 15:01:13 -0400

I read draft-zaalouk-supa-configuration-model-00. 

It provides an interesting starting set for the models to be defined in supa. Whether these should be tackled as a single draft or one for each model is debatable. Both approaches have advantages, but having them together would be desirable if some of the modelling is re-used between models. Having them separated would allow for the work to be more modular and to advance them separately if some have a consensus and not others. 

That said, each model seems to be fairly independent at this moment, there’s no re-use of common topology modelling between each of them, even if some of the elements seem to be fairly similar. For example, in the TE model, a pathNode and nodeID are used for configuration, but PathResult and PathResultNode are used for reporting. Why not define a common model that works both ways? There’s also a nodeID and type defined in the flow model. There would be significant advantages in having these different models using the topology language, for example the one defined in draft-contreras-supa-yang-network-topo. 

Some more specific comments about the draft below: 
Introduction: 
- First paragraph. Not sure why RFC2473 is mentioned there, since it’s about IPv6 tunnelling. 
- Second paragraph. This is a single sentence of 9 lines. Breaking it down in smaller pieces would certainly make it more readable. Also, it refers to APONF-architecture. 
- Third paragraph. This text seems to hint heavily at RESTCONF. As Juerguen mentioned in a previous post, NETCONF is more complex but has some advantages compared to RESTCONF, such as being able to manage multiple versions of the configuration (for example a current one before “committing”). 

L3VPN
- The models could use a bit more descriptions. For example, in a hub-and-spoke topology, how is the hub defined? Is it the role leaf? What type of identifier is phyAcIfId?
- Why is there a username and password at the interface level? 
- The interface seems to be focused on PE-CE edge side. What happens if the application would like the details of the VPN configuration reported? (RD, RT, RR used, RT filter, etc) Would that be handled in another interface?
- I don’t see any way to perform route filtering. This would be important in a PE-CE context. 

Flows
- Missing a ‘e’ in module SUPA-servicflow ?
- Are sourcePrefix and destinationPrefix actually masks? 
- What is the prefix leaf? It’s only specified as an IP address, so it wouldn’t reflect an actual prefix. 
- How are policies mapped to flows? By the flow name only? 
- The definition and usage for the “Terminal Point Key” and “Terminal Key ID” is a bit unclear, some description would be useful. 

IP TE
- First sentence: "The network connection between data centers is usually leased…”. This is quite a strong statement. You might want to soften the language here (s/usually/often/) or put a reference, as I’m not sure this is true for all operators. 
- Why not use a common definition of flows in this model and the preceding one?
- What is iptePathResultNodes exactly? An ordered list of nodes describing the traffic path? 
- Each iptePathResult seems to carry a single iptePrefixName and path, while an ipteFlow seems to carry multiple prefixes and and paths. What would be the logic behind this way of organizing data?

Tunnels: 
- The combinaisons of ip tunnels (ip-in-ip, ip-in-ipv6, etc) seem to be missing from tunnelType. Also, what are bgp and ldp tunnels?

Again, this is a nice starting point for the discussion about models, but I’m sure there would ways to re-use common parts of the models instead of repeating a lot of what seems to be the same structures in each one. Also, the description of each model could be fleshed out a bit, as the role of each element is not always obvious from the description. 

JF