In the RRG proposals we seem to a set of implicit assumptions that I would like get some clarification.
We are assuming that the networks using EIDs are stub networks, networks that do not provide transit and do not peer between each other. Is this really what is needed and required? If this is a valid assumption it should be documented as it is a clear constraint of the applicability.
ITR/ETR selection (based on weights and priorities) guides the bindings of EID to RLOC which facilitates how the traffic is tunneled (routed and forwarded) over the core. The ingress and egress devices can be located either at the customer edge or at the provider side. This location impacts whether the originating and receiving sites have access to underlying routing preferences. Should we provide tools to the ingress/egress devices to have visibility to the routing policies affecting how the tunnel is performing? For instance, should the ingress benefit from knowing the hop counts/costs of certain RLOCs of the egress?
The location of PTR/proxy matters as they attract traffic and are in charge of forwarding packets causing transit fees. Typically ISPs will forward traffic of their customers routes, and peer supplied routes, but not the traffic of their providers nor between providers. Is this still a valid constraint in the new routing system we are devising? I must assume it is. Consequently the topology and ISP relationships constraint where to place the proxies that are very much needed for the backwards compatibility and incremental deployment.
In small case trials how traffic is routed (i.e. the topology and policies) may not really matter much, but in larger ones where the traffic volumes are significant the path selection will matter as their is a cost factor associated to it.
Regards
Hannu