Hi Folks, Two months ago, We (Cisco) branched off 2.1.x for our next release. We noticed the geo restrictions functionality was not supported for steering services. Since some of our customers are using the blocking features extensively (CZF, National geo blocking, regional geo blocking, vpn blocking) and will be using steering services, we decided to enable the blocking functionality. The work was completed a few weeks ago on our fork. We recently noticed https://github.com/apache/incubator-trafficcontrol/pull/1458 “Cannot set geo restrictions on CLIENT_STEERING delivery services” seemed to try address the same issue.
The open source implementation however differs from ours in a significant way and I want to bring this up so we can understand the use cases and desired behavior better. 1. Open source took the straightforward approach where operator explicitly configure geo restriction for steering service, traffic router then enforce them on steering service only. Disclaimer - I can’t find any evidence where such enforcement exists in master today and I assuming this is WIP (TrafficRouter code doesn’t check any geo blocking attributes for steering service itself). It does however explicitly ignore the target’s service’s setting https://github.com/apache/incubator-trafficcontrol/blob/master/traffic_router/core/src/main/java/com/comcast/cdn/traffic_control/traffic_router/core/router/TrafficRouter.java#L468 . To end user the blocking features works in a way I call “Overwriting” – steering service’s setting overwrites those of the target services’s. If steering services is not configured as geo blocking, then it becomes wide open regardless of targets’ settings. So operator must configure these settings, most likely duplicate them from target DSs’ if they need to enforce same geo blocking for steering service. Although requiring extra steps to configure, this approach does give operator the flexibility to enforce geo restriction options for steering service that is different from those defined for targets. 1. Cisco’s implementation, in addition to added support for regional/vpn restrictions, took a different approach. We do not require operator to configure geo restriction for steering service (hidden from UI), and changed the Router code to iterate through the target DSs and apply the various restrictions on each. If a target DS is configured to be blocked, its caches will not be added in the “locations” response. To end user the blocking features works in a way I call “Inheriting” – steering service inherits blocking ability from the target DSs. Our view is that steering service is a virtual service to add service resiliency and it is only meaningful/useful when overlaid on top of real services, therefore this inheritance behavior might be desirable. From a restriction enforcement perspective, it is simpler since target service’s restrictions is always in effect. It does not however provide any flexibility to bypass/overwriting the target DSs’ settings. Since our open source community , especially Comcast folks have extensive operational experiences, I would like to hear your take. To me the most importantly questions is: What is end user (operator)’s perception about steering service concept? – Is it just another FULL service they need/want to provision that will have its only individual characters or it is just simply an OVERLAY mechanism that gives them additional service resiliency? There are certainly options to make the two co-exist (invoke 1 after 2, let user configure/choose one over the other, etc) but an answer to above question can guide us to provide the “right” solution. The answer will also helps us deciding other existing DS feature’s applicability to steering. Thanks, -Hongfei
