Explore re-use of idioms from config spec language for routing spec

[istio]

Explore re-use of idioms from config spec language for routing spec

[kyessenov]

It would be good to understand the expressive power limit of the current Envoy configuration format. I can imagine we'd probably need to extend the routing section in Envoy to take into account arbitrary Mixer attributes and that would require extensive changes to core Envoy.

For example, routing rules are grouped by virtual hosts in Envoy. If we have rules for a binding svcA -> svcB, can we get away with a single virtual host for B or we need one host per binding?

[rshriram]

Depends on the protocol. When the protocol allows multiplexing (e.g. HTTP), we can get away with a single virtual host, while forcing all outbound connections from the app to land on a predefined port (say 6379). We can differentiate different targets using the http host header and URLs. Or an easier fallback would be catch all (*) for internal envoys running with non edge services (i.e. non user facing).

If it's a non multiplex-able protocol like redis, mongo, plain tcp, etc., we would need one virtual host per service (e.g. One for mongo, one for redis) each listening on a different port.

[rshriram]

This has been listed as a TODO in the ProxyConfig proto in istio/api/proxy/alphav1/config/cfg.proto
@ayj this can be moved out of V0 into some bucket for future iterations?

[ayj]

Sure. We don't have any future milestone / projects defined yet, but we can treat anything not tracked under ManagerV0 as part of some future iteration for now.

[rshriram]

closing this as of now. The two projects have diverged significantly. Aspects and stuff do not apply to route configurations.