Clarify SMI root/apex service does not need to be a Kubernetes service

[michelleN]

We came across this paragraph in the traffic split spec while working on OSM and think it might warrant some clarification:

The resource is associated with a root service. This is referenced via spec.service. The spec.service name is the FQDN that applications will use to communicate. For any clients that are not forwarding their traffic through a proxy that implements this proposal, the standard Kubernetes service configuration would continue to operate.

It is clear that the root service should be an FQDN but then the sentence about following standard Kubernetes service configuration might make someone think that the root service needs to be a Kubernetes service. As we understand this part of the spec, we do not think the FQDN needs to reference a Kubernetes service and the spec should explicitly have a line that states this. The reason is because a client should be able to reference any FQDN whether that be foo.com or a Kubernetes service bookstore.bookstore-ns where bookstore is the name of the Kubernetes service and bookstore-ns is the name os the Kubernetes namespace the service runs in.

[michelleN]

potential solution: rename service to fqdn

[shashankram]

Can the spec be extended/clarified to support both:

1. a (virtual) service as the root service. K8s applications are going to use the service FQDN for the most part.
2. Any FQDN

I see a need for implementations to support non HTTP-based traffic splitting, such as when using TCP-based applications in the mesh.

Without the notion of supporting a top-level service (service's FQDN) to split traffic on, the usage of this API will be severely limited for implementations that need to rely on filtering traffic at the L3/L4 layer (ip:port) to correctly enforce routing rules.