date:20170621

Re: Custom Delivery Service Domain Support

2017-06-21 Thread Zhilin Huang (zhilhuan)

Thanks for the comments, Eric.

Yes, you can use any number of levels for the custom domain, no matter two or 
three or more.

And the configuration is only in the “HOST_REGEXP” of a delivery service. No 
other parameter needed.


On 6/21/17, 8:48 PM, "Eric Friedrich (efriedri)"  wrote:

Thanks Zhilin-
  Could I use a domain of just “topdomain-cdn.com” or does it require a 
minimum of three levels?

Is configuration just in delivery service or does the domain_name parameter 
need to be modified too?


> On Jun 21, 2017, at 4:56 AM, Zhilin Huang (zhilhuan)  
wrote:
> 
> Hi all,
> 
> I am working on a feature to support custom delivery service domain.
> 
> Currently in traffic ops, you can configure a “HOST_REGEXP” for a 
delivery service with pattern like:
> 1)  .*\.my-subdomain\..*
> 2) my-subdomain.topdomain.com
> 
> I think pattern 1) is well known by all of us. However pattern 2) is 
allowed in traffic ops code, but not well supported. The Custom Delivery 
Service Domain feature will fully support pattern 2) and allow “topdomain.com” 
be different with the domain name of a CDN. This will allow to support 
different domains within a single CDN, and share the router/monitor/cache 
servers with a CDN for different (top level) domains.
> 
> And “my-subdomain.topdomain.com” in pattern 2) will be used as the RFQDN 
instead of “tr.my-subdomain.cdndomain.com” or 
“edge.my-subdomain.cdndomain.com”. This way, user can fully customize the whole 
domain for a delivery service. The NS records for pattern 2) will be the fqdn 
of the routers in this CDN.
> 
> Any comments/suggestions will be welcome. The draft code is ready and 
under testing. And an example is attached in the end of this email.
> 
> Thanks,
> Zhilin
> 
> 
> 
> Here is the example, suppose we have a CDN with domain name 
“ipcdn.mycompany.com”. And configured 2 delivery services with the following 
“HOST_REGEXP”:
> DS1:   .*\.test\..*
> DS2:   test.wholesaler.com
> 
> Then in traffic router, the following zone files will be generated:
> 
> # ls /opt/traffic_router/var/auto-zones/
> test.ipcdn.mycompany.com.  test.wholesaler.com. ipcdn.mycompany.com.
> 
> # cat /opt/traffic_router/var/auto-zones/test.ipcdn.mycompany.com.
> test.ipcdn.mycompany.com.   3600IN  NS  
crdc-router-1.ipcdn.mycompany.com.
> test.ipcdn.mycompany.com.   3600IN  NS  
crdc-router-2.ipcdn.mycompany.com.
> test.ipcdn.mycompany.com.   86400   IN  SOA 
crdc-router-1.ipcdn.mycompany.com. traffic_ops.test.ipcdn.mycompany.com. 
2017062108 28800 7200 604800 30
> crdc-edge-se-1.test.ipcdn.mycompany.com.3600IN  A   
192.168.122.112
> crdc-edge-se-2.test.ipcdn.mycompany.com.3600IN  A   
192.168.122.172
> crdc-edge-se-3.test.ipcdn.mycompany.com.3600IN  A   
192.168.122.110
> crdc-edge-se-4.test.ipcdn.mycompany.com.3600IN  A   
192.168.122.252
> crdc-router-1.test.ipcdn.mycompany.com. 3600IN  A   
192.168.122.175
> crdc-router-2.test.ipcdn.mycompany.com. 3600IN  A   
192.168.122.96
> tr.test.ipcdn.mycompany.com.3600IN  A   192.168.122.96
> tr.test.ipcdn.mycompany.com.3600IN  A   192.168.122.175
> 
> # cat /opt/traffic_router/var/auto-zones/test.wholesaler.com.
> test.wholesaler.com.3600IN  A   192.168.122.96
> test.wholesaler.com.3600IN  A   192.168.122.175
> test.wholesaler.com.3600IN  NS  
crdc-router-1.ipcdn.mycompany.com.
> test.wholesaler.com.3600IN  NS  
crdc-router-2.ipcdn.mycompany.com.
> test.wholesaler.com.86400   IN  SOA 
crdc-router-1.ipcdn.mycompany.com. traffic_ops.test.wholesaler.com. 2017062108 
28800 7200 604800 30
> crdc-edge-se-1.test.wholesaler.com. 3600IN  A   
192.168.122.112
> crdc-edge-se-2.test.wholesaler.com. 3600IN  A   
192.168.122.172
> crdc-edge-se-3.test.wholesaler.com. 3600IN  A   
192.168.122.110
> crdc-edge-se-4.test.wholesaler.com. 3600IN  A   
192.168.122.252
> crdc-router-1.test.wholesaler.com.  3600IN  A   
192.168.122.175
> crdc-router-2.test.wholesaler.com.  3600IN  A   
192.168.122.96
> 
> # cat /opt/traffic_router/var/auto-zones/ipcdn.mycompany.com.
> ipcdn.mycompany.com.3600IN  NS  
crdc-router-1.ipcdn.mycompany.com.
> ipcdn.mycompany.com.3600IN  NS  
crdc-router-2.ipcdn.mycompany.com.
> ipcdn.mycompany.com.86400   IN  SOA 
crdc-router-1.ipcdn.mycompany.com. traffic_ops.ipcdn.mycompany.com. 2017062108 
28800 7200 604800 30
> crdc-router-1.ipcdn.mycompany.com.  3600IN  A

[RESULT][VOTE]Release Apache Traffic Control 2.0.0-incubating (RC6)

2017-06-21 Thread Eric Friedrich (efriedri)

The PPMC vote passes with 3 +1s and 0 -1s

Thanks to the following for their votes
  Dewayne Richardson
  Dave Neuman 
  Dan Kirkwood 

IPMC VOTE Thread coming up shortly

Re: DSCP marking from Mid->Edge

2017-06-21 Thread Durfey, Ryan

Generally speaking, I think this is a good idea, but I defer to our engineers 
for additional feedback.  We currently struggle with logging in that is only 
derivable by origin value.  I would love to be able to  1) aggregate logs from 
multiple services into one log file or 2) divide logs from a single service 
into multiple log files based on some type of flag that is set by the system 
for each request.  But this could be taking you down a rabbit hole ☺

Ryan DurfeyM | 303-524-5099
CDN Support (24x7): 866-405-2993 or 
cdn_supp...@comcast.com

From: "Mike Sandman (misandma)" 
Reply-To: "dev@trafficcontrol.incubator.apache.org" 

Date: Wednesday, June 21, 2017 at 1:46 PM
To: "dev@trafficcontrol.incubator.apache.org" 

Subject: Re: DSCP marking from Mid->Edge

So would it be better for the “Forwarded” header to be configurable globally, 
or separately from enabling DS-specific features on the mids? Originally I 
thought the Edge would only set the “Forwarded” header on a per-remap basis for 
DSes where the mid needs to be aware, but for logging purposes does it make 
sense to allow setting this header at a global (per-edge) level?

Thanks,
Mike Sandman

On 6/20/17, 9:21 AM, "Durfey, Ryan" 
mailto:ryan_dur...@comcast.com>> wrote:

As an aside we also struggle with separating mid tier to origin logs for 
services using the same origin value.  Currently we are forced to create a 
cname for one of the services so the origin fqdns are different between the two 
services.  Marking services heading from mid to origin with a service value 
marker would also potentially solve that issue which would be helpful.

Ryan DurfeyM | 303-524-5099
CDN Support (24x7): 866-405-2993 or 
cdn_supp...@comcast.com

From: "Mike Sandman (misandma)" 
mailto:misan...@cisco.com>>
Reply-To: 
"dev@trafficcontrol.incubator.apache.org"

mailto:dev@trafficcontrol.incubator.apache.org>>
Date: Monday, June 19, 2017 at 5:05 PM
To: 
"dev@trafficcontrol.incubator.apache.org"

mailto:dev@trafficcontrol.incubator.apache.org>>
Subject: Re: DSCP marking from Mid->Edge

I think we do want it per DS (and not even per origin) since the asking 
customer will potentially have two DSes pointing to the same origin where one 
is for in-home traffic and one is for mobile, and they may want different QoS 
for each.

Thanks,
Mike Sandman

On 6/19/17, 5:00 PM, "Steve Malenfant" 
mailto:smalenf...@gmail.com>>
 wrote:

Mike,

Is there a requirement to have it configured per delivery service? If 
not,
would enabling global header rewrite in plugin.config would work for a
specific DSCP value?

Steve

On Mon, Jun 19, 2017 at 1:28 PM, Mike Sandman (misandma) 
mailto:misan...@cisco.com>
> wrote:

> Hi all,
>
> I’m beginning work on a feature to enable DSCP marking for traffic 
between
> the mid and edge cache. So far the high level proposed design is:
>
>
> 1.   DSCP marking from Mid to Edge will be configurable on a 
per-DS
> basis (like DSCP marking from Edge to Client is today). This means 
the Mids
> will need to know what DS a particular request corresponds to (we 
have a
> use case for two DSes pointing to the same origin)
>
> 2.   Therefore, the Edge will need to write a new header
> (Forwarded:host= as per RFC 
7239)
> into the request that is sent up to the Mid
>
> 3.   The Mid will use a remap rule (like the Edge does today) to 
apply
> a DSCP config to responses where the request has a matching Forwarded 
header
>
> 4.   To accomplish this, Traffic Ops will need to generate header
> rewrite rules on the Edge and remap.config on the Mid to match this
> configuration scheme
>
> Any issues or improvements to this? Or will this work?
>
> Thanks,
> Mike Sandman
>

Re: DSCP marking from Mid->Edge

2017-06-21 Thread Mike Sandman (misandma)

So would it be better for the “Forwarded” header to be configurable globally, 
or separately from enabling DS-specific features on the mids? Originally I 
thought the Edge would only set the “Forwarded” header on a per-remap basis for 
DSes where the mid needs to be aware, but for logging purposes does it make 
sense to allow setting this header at a global (per-edge) level?

Thanks,
Mike Sandman

On 6/20/17, 9:21 AM, "Durfey, Ryan"  wrote:

As an aside we also struggle with separating mid tier to origin logs for 
services using the same origin value.  Currently we are forced to create a 
cname for one of the services so the origin fqdns are different between the two 
services.  Marking services heading from mid to origin with a service value 
marker would also potentially solve that issue which would be helpful.

Ryan DurfeyM | 303-524-5099
CDN Support (24x7): 866-405-2993 or 
cdn_supp...@comcast.com

From: "Mike Sandman (misandma)" 
Reply-To: "dev@trafficcontrol.incubator.apache.org" 

Date: Monday, June 19, 2017 at 5:05 PM
To: "dev@trafficcontrol.incubator.apache.org" 

Subject: Re: DSCP marking from Mid->Edge

I think we do want it per DS (and not even per origin) since the asking 
customer will potentially have two DSes pointing to the same origin where one 
is for in-home traffic and one is for mobile, and they may want different QoS 
for each.

Thanks,
Mike Sandman

On 6/19/17, 5:00 PM, "Steve Malenfant" 
mailto:smalenf...@gmail.com>> wrote:

Mike,

Is there a requirement to have it configured per delivery service? If 
not,
would enabling global header rewrite in plugin.config would work for a
specific DSCP value?

Steve

On Mon, Jun 19, 2017 at 1:28 PM, Mike Sandman (misandma) 
mailto:misan...@cisco.com>
> wrote:

> Hi all,
>
> I’m beginning work on a feature to enable DSCP marking for traffic 
between
> the mid and edge cache. So far the high level proposed design is:
>
>
> 1.   DSCP marking from Mid to Edge will be configurable on a 
per-DS
> basis (like DSCP marking from Edge to Client is today). This means 
the Mids
> will need to know what DS a particular request corresponds to (we 
have a
> use case for two DSes pointing to the same origin)
>
> 2.   Therefore, the Edge will need to write a new header
> (Forwarded:host= as per RFC 
7239)
> into the request that is sent up to the Mid
>
> 3.   The Mid will use a remap rule (like the Edge does today) to 
apply
> a DSCP config to responses where the request has a matching Forwarded 
header
>
> 4.   To accomplish this, Traffic Ops will need to generate header
> rewrite rules on the Edge and remap.config on the Mid to match this
> configuration scheme
>
> Any issues or improvements to this? Or will this work?
>
> Thanks,
> Mike Sandman
>

Re: Custom Delivery Service Domain Support

2017-06-21 Thread Eric Friedrich (efriedri)

Thanks Zhilin-
  Could I use a domain of just “topdomain-cdn.com” or does it require a minimum 
of three levels?

Is configuration just in delivery service or does the domain_name parameter 
need to be modified too?


> On Jun 21, 2017, at 4:56 AM, Zhilin Huang (zhilhuan)  
> wrote:
> 
> Hi all,
> 
> I am working on a feature to support custom delivery service domain.
> 
> Currently in traffic ops, you can configure a “HOST_REGEXP” for a delivery 
> service with pattern like:
> 1)  .*\.my-subdomain\..*
> 2) my-subdomain.topdomain.com
> 
> I think pattern 1) is well known by all of us. However pattern 2) is allowed 
> in traffic ops code, but not well supported. The Custom Delivery Service 
> Domain feature will fully support pattern 2) and allow “topdomain.com” be 
> different with the domain name of a CDN. This will allow to support different 
> domains within a single CDN, and share the router/monitor/cache servers with 
> a CDN for different (top level) domains.
> 
> And “my-subdomain.topdomain.com” in pattern 2) will be used as the RFQDN 
> instead of “tr.my-subdomain.cdndomain.com” or 
> “edge.my-subdomain.cdndomain.com”. This way, user can fully customize the 
> whole domain for a delivery service. The NS records for pattern 2) will be 
> the fqdn of the routers in this CDN.
> 
> Any comments/suggestions will be welcome. The draft code is ready and under 
> testing. And an example is attached in the end of this email.
> 
> Thanks,
> Zhilin
> 
> 
> 
> Here is the example, suppose we have a CDN with domain name 
> “ipcdn.mycompany.com”. And configured 2 delivery services with the following 
> “HOST_REGEXP”:
> DS1:   .*\.test\..*
> DS2:   test.wholesaler.com
> 
> Then in traffic router, the following zone files will be generated:
> 
> # ls /opt/traffic_router/var/auto-zones/
> test.ipcdn.mycompany.com.  test.wholesaler.com. ipcdn.mycompany.com.
> 
> # cat /opt/traffic_router/var/auto-zones/test.ipcdn.mycompany.com.
> test.ipcdn.mycompany.com.   3600IN  NS  
> crdc-router-1.ipcdn.mycompany.com.
> test.ipcdn.mycompany.com.   3600IN  NS  
> crdc-router-2.ipcdn.mycompany.com.
> test.ipcdn.mycompany.com.   86400   IN  SOA 
> crdc-router-1.ipcdn.mycompany.com. traffic_ops.test.ipcdn.mycompany.com. 
> 2017062108 28800 7200 604800 30
> crdc-edge-se-1.test.ipcdn.mycompany.com.3600IN  A   
> 192.168.122.112
> crdc-edge-se-2.test.ipcdn.mycompany.com.3600IN  A   
> 192.168.122.172
> crdc-edge-se-3.test.ipcdn.mycompany.com.3600IN  A   
> 192.168.122.110
> crdc-edge-se-4.test.ipcdn.mycompany.com.3600IN  A   
> 192.168.122.252
> crdc-router-1.test.ipcdn.mycompany.com. 3600IN  A   
> 192.168.122.175
> crdc-router-2.test.ipcdn.mycompany.com. 3600IN  A   192.168.122.96
> tr.test.ipcdn.mycompany.com.3600IN  A   192.168.122.96
> tr.test.ipcdn.mycompany.com.3600IN  A   192.168.122.175
> 
> # cat /opt/traffic_router/var/auto-zones/test.wholesaler.com.
> test.wholesaler.com.3600IN  A   192.168.122.96
> test.wholesaler.com.3600IN  A   192.168.122.175
> test.wholesaler.com.3600IN  NS  
> crdc-router-1.ipcdn.mycompany.com.
> test.wholesaler.com.3600IN  NS  
> crdc-router-2.ipcdn.mycompany.com.
> test.wholesaler.com.86400   IN  SOA 
> crdc-router-1.ipcdn.mycompany.com. traffic_ops.test.wholesaler.com. 
> 2017062108 28800 7200 604800 30
> crdc-edge-se-1.test.wholesaler.com. 3600IN  A   
> 192.168.122.112
> crdc-edge-se-2.test.wholesaler.com. 3600IN  A   
> 192.168.122.172
> crdc-edge-se-3.test.wholesaler.com. 3600IN  A   
> 192.168.122.110
> crdc-edge-se-4.test.wholesaler.com. 3600IN  A   
> 192.168.122.252
> crdc-router-1.test.wholesaler.com.  3600IN  A   
> 192.168.122.175
> crdc-router-2.test.wholesaler.com.  3600IN  A   192.168.122.96
> 
> # cat /opt/traffic_router/var/auto-zones/ipcdn.mycompany.com.
> ipcdn.mycompany.com.3600IN  NS  
> crdc-router-1.ipcdn.mycompany.com.
> ipcdn.mycompany.com.3600IN  NS  
> crdc-router-2.ipcdn.mycompany.com.
> ipcdn.mycompany.com.86400   IN  SOA 
> crdc-router-1.ipcdn.mycompany.com. traffic_ops.ipcdn.mycompany.com. 
> 2017062108 28800 7200 604800 30
> crdc-router-1.ipcdn.mycompany.com.  3600IN  A   192.168.122.175
> crdc-router-2.ipcdn.mycompany.com.  3600IN  A   192.168.122.96
> 
> 
> And in one of the cache server, the following content will be generated for 
> remap.config:
> 
> # cat /opt/trafficserver/etc/trafficserver/remap.config
> # DO NOT EDIT - Generated for crdc-edge-se-2 by Traffic Ops 
> (https://localhost) on Tue Jun 13 05:59:22 UTC 2017
> map http://crdc-edge-se-2.test.ipcdn.mycompany.com/ 
> http://192.168.122.156/ @plugin=header_rewrite.

Custom Delivery Service Domain Support

2017-06-21 Thread Zhilin Huang (zhilhuan)

Hi all,

I am working on a feature to support custom delivery service domain.

Currently in traffic ops, you can configure a “HOST_REGEXP” for a delivery 
service with pattern like:
1)  .*\.my-subdomain\..*
2) my-subdomain.topdomain.com

I think pattern 1) is well known by all of us. However pattern 2) is allowed in 
traffic ops code, but not well supported. The Custom Delivery Service Domain 
feature will fully support pattern 2) and allow “topdomain.com” be different 
with the domain name of a CDN. This will allow to support different domains 
within a single CDN, and share the router/monitor/cache servers with a CDN for 
different (top level) domains.

And “my-subdomain.topdomain.com” in pattern 2) will be used as the RFQDN 
instead of “tr.my-subdomain.cdndomain.com” or 
“edge.my-subdomain.cdndomain.com”. This way, user can fully customize the whole 
domain for a delivery service. The NS records for pattern 2) will be the fqdn 
of the routers in this CDN.

Any comments/suggestions will be welcome. The draft code is ready and under 
testing. And an example is attached in the end of this email.

Thanks,
Zhilin



Here is the example, suppose we have a CDN with domain name 
“ipcdn.mycompany.com”. And configured 2 delivery services with the following 
“HOST_REGEXP”:
DS1:   .*\.test\..*
DS2:   test.wholesaler.com

Then in traffic router, the following zone files will be generated:

# ls /opt/traffic_router/var/auto-zones/
test.ipcdn.mycompany.com.  test.wholesaler.com. ipcdn.mycompany.com.

# cat /opt/traffic_router/var/auto-zones/test.ipcdn.mycompany.com.
test.ipcdn.mycompany.com.   3600IN  NS  
crdc-router-1.ipcdn.mycompany.com.
test.ipcdn.mycompany.com.   3600IN  NS  
crdc-router-2.ipcdn.mycompany.com.
test.ipcdn.mycompany.com.   86400   IN  SOA 
crdc-router-1.ipcdn.mycompany.com. traffic_ops.test.ipcdn.mycompany.com. 
2017062108 28800 7200 604800 30
crdc-edge-se-1.test.ipcdn.mycompany.com.3600IN  A   
192.168.122.112
crdc-edge-se-2.test.ipcdn.mycompany.com.3600IN  A   
192.168.122.172
crdc-edge-se-3.test.ipcdn.mycompany.com.3600IN  A   
192.168.122.110
crdc-edge-se-4.test.ipcdn.mycompany.com.3600IN  A   
192.168.122.252
crdc-router-1.test.ipcdn.mycompany.com. 3600IN  A   192.168.122.175
crdc-router-2.test.ipcdn.mycompany.com. 3600IN  A   192.168.122.96
tr.test.ipcdn.mycompany.com.3600IN  A   192.168.122.96
tr.test.ipcdn.mycompany.com.3600IN  A   192.168.122.175

# cat /opt/traffic_router/var/auto-zones/test.wholesaler.com.
test.wholesaler.com.3600IN  A   192.168.122.96
test.wholesaler.com.3600IN  A   192.168.122.175
test.wholesaler.com.3600IN  NS  
crdc-router-1.ipcdn.mycompany.com.
test.wholesaler.com.3600IN  NS  
crdc-router-2.ipcdn.mycompany.com.
test.wholesaler.com.86400   IN  SOA 
crdc-router-1.ipcdn.mycompany.com. traffic_ops.test.wholesaler.com. 2017062108 
28800 7200 604800 30
crdc-edge-se-1.test.wholesaler.com. 3600IN  A   192.168.122.112
crdc-edge-se-2.test.wholesaler.com. 3600IN  A   192.168.122.172
crdc-edge-se-3.test.wholesaler.com. 3600IN  A   192.168.122.110
crdc-edge-se-4.test.wholesaler.com. 3600IN  A   192.168.122.252
crdc-router-1.test.wholesaler.com.  3600IN  A   192.168.122.175
crdc-router-2.test.wholesaler.com.  3600IN  A   192.168.122.96

# cat /opt/traffic_router/var/auto-zones/ipcdn.mycompany.com.
ipcdn.mycompany.com.3600IN  NS  
crdc-router-1.ipcdn.mycompany.com.
ipcdn.mycompany.com.3600IN  NS  
crdc-router-2.ipcdn.mycompany.com.
ipcdn.mycompany.com.86400   IN  SOA 
crdc-router-1.ipcdn.mycompany.com. traffic_ops.ipcdn.mycompany.com. 2017062108 
28800 7200 604800 30
crdc-router-1.ipcdn.mycompany.com.  3600IN  A   192.168.122.175
crdc-router-2.ipcdn.mycompany.com.  3600IN  A   192.168.122.96


And in one of the cache server, the following content will be generated for 
remap.config:

# cat /opt/trafficserver/etc/trafficserver/remap.config
# DO NOT EDIT - Generated for crdc-edge-se-2 by Traffic Ops (https://localhost) 
on Tue Jun 13 05:59:22 UTC 2017
map http://crdc-edge-se-2.test.ipcdn.mycompany.com/ 
http://192.168.122.156/ @plugin=header_rewrite.so @pparam=dscp/set_dscp_0.config
map http://crdc-edge-se-2.test.wholesaler.com/ http://192.168.122.156/ 
@plugin=header_rewrite.so @pparam=dscp/set_dscp_0.config

Re: Custom Delivery Service Domain Support

[RESULT][VOTE]Release Apache Traffic Control 2.0.0-incubating (RC6)

Re: DSCP marking from Mid->Edge

Re: DSCP marking from Mid->Edge

Re: Custom Delivery Service Domain Support

Custom Delivery Service Domain Support

6 matches

Site Navigation

Mail list logo

Footer information