On 25/06/2010 15:14, Gigi Karmous-Edwards wrote:
I agree that the removal of non-GOLEs from the topology graph is an alternative to creating a constraint during path computation. I thought that the removal from the graph would be easier, similar to removal of failed links (due to availability etc ) during crank-back. Having said that, in GIRRA, both technology and policy is taken into account but availability is not. This is because we do not collect availability information only relatively static information about the topology, therefore reducing complexity and the number or required updates.
Availability is then taken into account using crank-back. As we discussed before, it remains to be seen whether the number of updates regarding availability outnumbers the load on the network due to crank-backs.
With reference to your other comments about policy: having an open policy GOLE makes path computation easier, since the fewer "policy-rich " domains one has in the computed path the better. IMHO, an ideal global path will consist of only the source and destination domains and the rest of the path will consist of policy-free GOLEs. Leaving the policy of the path to the two endpoint domains only. Does this make sense?
This will really depend on the user! I would imagine that LHC Tier-x users do not want to use GOLEs, but instead want to make use of the LHCnet as much as possible. I realise that the LHC is an extreme case, but similar cases can be made for NLR/Internet2, GEANT, GLORIAD and other networks that some but not all users have access to. Leaving policy out of the equation like this may make pathfinding a whole lot simpler, but I'm not sure whether you end up with answers that you can work with.
I do realize that this is different than traditional approach and I realize that today in our real world, GOLEs are not all interconnected. The above statements are based on an "ideal" network.
Given the examples I made above I'm not sure that we'll ever end up with anything resembling an "ideal" network as you describe. Jeroen.