Hi Dave, Thanks for the quick response. If I hear no objections, I will work with our team to put a PR to open source next week.
Thanks, -Hongfei On 11/3/17, 2:19 PM, "Dave Neuman" <[email protected]> wrote: Hey Hongfei, Thanks for the email. To be honest I saw that geo blocking was not in the UI, so I added it without really thinking about the implications in Traffic Router, that is my fault. I think I am on board with Cisco's implementation and I look forward to it being contributed back to Traffic Control. Thanks, Dave On Thu, Nov 2, 2017 at 4:34 PM, Hongfei Zhang (hongfezh) <[email protected] > wrote: > 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 > >
