Subject: Re: [CDNi] CDNI Requirements I-D

From: "Lee, Yiu" <[email-masked]>
Date: Tue, 1 Feb 2011 18:58:54 +0000

Hi Ben,

Thanks for thinking through this. My concern was U2 should put the IP in
the URL but it wouldn¹t happen. This is fine. I agree that if we use the
FQDN in the redirect, CDN2 will stream the content to U2 in native v6 if
the CDN2 supports v6.

Yiu

>
>U2 is behind NAT64 so CDN1 will see an IPv4 address for U2. That is not
>the issue. The issue is that NAT64 relies on the NAT64 device synthesising
>AAAA DNS responses as U2 only speaks DNSv6. But if U2 gets an v4 address
>literal in the Content-Location header of a HTTP 302 it has no way to
>communicate with that v4 address as it has no native v4 capability (or no
>native v4 routing).
>
>Using a FQDN (and avoiding v4 address literals) in the Content-Location
>header would avoid the issue as you first suggested.
>
>Ben
>

---

From: Francois Le Faucheur <[email-masked]>
Date: Tue, 1 Feb 2011 20:06:22 +0100

So we should add a requirement along the lines of the one you discussed earlier with Dan:

> I would propose adding a general requirement to the document stating
> "any
> URIs returned to User Agents MUST NOT contain IP address literals in
> the
> <authority> component of the URI" or similar text.

Right?

Francois

> _______________________________________________
> CDNi mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/cdni

Francois Le Faucheur
Distinguished Engineer
Corporate Development
[email-masked]
Phone: +33 49 723 2619
Mobile: +33 6 19 98 50 90

Cisco Systems France
Greenside
400 Ave de Roumanille
06410 Sophia Antipolis
France
Cisco.com

 Think before you print.

This email may contain confidential and privileged material for the sole use of the intended recipient. Any review, use, distribution or disclosure by others is strictly prohibited. If you are not the intended recipient (or authorized to receive for the recipient), please contact the sender by reply email and delete all copies of this message.

Cisco Systems France, Société à responsabiité limitée, Rue Camille Desmoulins – Imm Atlantis Zac Forum Seine Ilot 7 92130 Issy les Moulineaux, Au capital de 91.470 €, 349 166 561 RCS Nanterre, Directeur de la publication: Jean-Luc Michel Givone.

For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/index.html

---

From: David R Oran <[email-masked]>
Date: Tue, 1 Feb 2011 19:47:43 -0500

Isn't this a special case of the general 3rd party referral problem? Why are you writing CDNi-specific requirements? Shouldn't you just say "CDN interconnection requires third party references and hence depends on mechanisms for the handling of such in URI's for a number of cases involving NATs, V4/V6 tunnels, and other scenarios that cause problems with third party references".

I would hate to see a requirement that led to a custom solution for CDN interconnection that didn't work for any old style of redirection.

If IP address literals cause third-party breakage, just banning them will only mask problems when people add further breakage like split DNS.

DaveO

---

From: "Lee, Yiu" <[email-masked]>
Date: Wed, 2 Feb 2011 04:32:24 +0000

Agreed and we didn't write a requirement that would lead to any specific
technology. All we are saying is that the the Content-Location would
contain FQDN. That's it.

On 2/1/11 7:47 PM, "David R Oran" <[email-masked]> wrote:

>Isn't this a special case of the general 3rd party referral problem? Why
>are you writing CDNi-specific requirements? Shouldn't you just say "CDN
>interconnection requires third party references and hence depends on
>mechanisms for the handling of such in URI's for a number of cases
>involving NATs, V4/V6 tunnels, and other scenarios that cause problems
>with third party references".
>
>I would hate to see a requirement that led to a custom solution for CDN
>interconnection that didn't work for any old style of redirection.
>
>If IP address literals cause third-party breakage, just banning them will
>only mask problems when people add further breakage like split DNS.
>
>DaveO
>
>> This email may contain confidential and privileged material for the
>>sole use of the intended recipient. Any review, use, distribution or
>>disclosure by others is strictly prohibited. If you are not the intended
>>recipient (or authorized to receive for the recipient), please contact
>>the sender by reply email and delete all copies of this message.
>> 
>> Cisco Systems France, Société à responsabiité limitée, Rue Camille
>>Desmoulins – Imm Atlantis Zac Forum Seine Ilot 7 92130 Issy les
>>Moulineaux, Au capital de 91.470 €, 349 166 561 RCS Nanterre, Directeur
>>de la publication: Jean-Luc Michel Givone.
>>

---

From: David R Oran <[email-masked]>
Date: Wed, 2 Feb 2011 09:49:06 -0500

> technology. All we are saying is that the the Content-Location would
I don't follow your reasoning. Saying that is neither necessary (since in many cases addresses will work), nor sufficient (because in a number of cases like split DNS an FQDN will not work).

I think the requirement is that "people only use URI's that work as third-party references".

This is a difficult area, admittedly, but writing requirements that don't capture the underlying problem to be solved isn't all that helpful since in hindsight people will inevitably forget why the requirement existed.

Now, if you want to mandate only FQDNs for some other reason that's fine, but do you want to close the door to someday having a CDN-friendly URNs instead of URIs anyway.

DaveO.

---

From: "Lee, Yiu" <[email-masked]>
Date: Wed, 2 Feb 2011 18:28:12 +0000

Hi Dave,

Let me clarify what I try to say. In the current requirement draft, we
specifically gave example to include IP address. This is why Dan replied
warning us this would break NAT64. IMHO, we should remove those examples
to have IP address. I am ok with your suggestion (ie third-party
reference), but I would like to give some examples such as FQDN, URN, etc
and remove IP address from the current example.

Cheers,
Yiu

On 2/2/11 9:49 AM, "David R Oran" <[email-masked]> wrote:

>I don't follow your reasoning. Saying that is neither necessary (since in
>many cases addresses will work), nor sufficient (because in a number of
>cases like split DNS an FQDN will not work).
>
>This is a difficult area, admittedly, but writing requirements that don't
>capture the underlying problem to be solved isn't all that helpful since
>in hindsight people will inevitably forget why the requirement existed.
>
>Now, if you want to mandate only FQDNs for some other reason that's fine,
>but do you want to close the door to someday having a CDN-friendly URNs
>instead of URIs anyway.
>
>DaveO.
>
>>>> So we should add a requirement along the lines of the one you
>>>>discussed
>>>> earlier with Dan:
>>>>

---

From: David R Oran <[email-masked]>
Date: Wed, 2 Feb 2011 18:29:33 -0500

> and remove IP address from the current example.
I agree that giving examples of problematic URI forms, including those that cause third-party reference problems, would be a good addition to the document. I myself was remiss in being so terse and not giving examples myself in my email.

Thanks for the thoughtful reply.

I was mostly aiming at ensuring that we didn't just laser-focus on IP addresses as problematic in URIs since sometimes they are and sometimes they aren't. Just banning IP addresses from URIs used in CDNi is attacking only one manifestation of the problem

Incidentally, a good example of where FQDNs can also go astray is the split-DNS situation I previously alluded to. When you have split DNS, servers in one domain may return different results from servers in other domains, or potentially fail to return any useful results. This may in fact be a real problem in CDNi situations as service providers (and sometimes enterprises as well) are sometimes enticed by the supposed benefits of using split-DNS techniques to hide the names of internal resources. Another example I might raise (with some trepidation) is "carrier ENUM" where the DNS FQDNs for phone numbers resolve differently (or not at all) in different SP networks.

DaveO

---

From: Francois Le Faucheur <[email-masked]>
Date: Thu, 3 Feb 2011 11:47:54 +0100

David, Yiu,

On 3 Feb 2011, at 00:29, David R Oran wrote:

> I agree that giving examples of problematic URI forms, including those that cause third-party reference problems, would be a good addition to the document.

I have the impression you two are talking slightly past each other (unless it is me that is past the two of you).

I believe Yiu is making the point that the current Requirements document includes an example of IP address being used as a reference (Yiu, I assume you refer to R35 in particular?). This was intended to be a positive example, so it now seems like a real bad example and should be changed to a better example (eg FQDN).

I believe David is making the point that, alongside the new requirement to be added along the lines of ... the CDNI solution MUST "only use URI's that work as third-party references", it would be useful to provide an example of what is a broken 3rd party reference (eg because it is based on IP address).

If I got this right, both points seem valid.

David, is there some document that can be referenced to help folks understand what it means "to work as a third-party reference"?

Thanks

Francois

> I myself was remiss in being so terse and not giving examples myself in my email.
> 

Francois Le Faucheur
Distinguished Engineer
Corporate Development
[email-masked]
Phone: +33 49 723 2619

Cisco Systems France
Greenside
400 Ave de Roumanille
06410 Sophia Antipolis
France
Cisco.com

 Think before you print.

---

From: David R Oran <[email-masked]>
Date: Thu, 3 Feb 2011 07:24:34 -0500

> I believe Yiu is making the point that the current Requirements document includes an example of IP address being used as a reference (Yiu, I assume you refer to R35 in particular?). This was intend…
Ok.

> I believe David is making the point that, alongside the new requirement to be added along the lines of ... the CDNI solution MUST "only use URI's that work as third-party references", it would be u…
Yes.

> If I got this right, both points seem valid.
Yes.

> David, is there some document that can be referenced to help folks understand what it means "to work as a third-party reference"?
I've never seen this all gathered up in one place, aside from even more general architecture papers that talk about "transparency" and "end-to-end". If the net were transparent as it's original architects envisioned then we would not be having this discussion because third-party references, using either addresses or names, would always work.

I'll ask around though.

---

From: Benjamin Niven-Jenkins <[email-masked]>
Date: Thu, 3 Feb 2011 20:45:33 +0000

Dave,

I read the rest of the thread before responding but this earlier e-mail from you seems the most appropriate one to respond to.

> Isn't this a special case of the general 3rd party referral problem? Why are you writing CDNi-specific requirements? Shouldn't you just say "CDN interconnection requires third party references and…

I agree, what we need to do is ensure redirects between CDNs work in the networks and deployments where it is likely to be used. "laser focussing" on IP address literals was partly my fault for bashing out quick replies rather taking some time to consider the wider implications so thanks for pointing this out.

> I would hate to see a requirement that led to a custom solution for CDN interconnection that didn't work for any old style of redirection.

Me too. I guess a slight concern I have is that if (as one of your later e-mails implied) there is currently no work that pulls all the cases together then we may end up in something of a catch-22. A CDNI WG is not the place to define the general case solution for 3rd party redirects (IMO) but we will need a solution that CDNI can leverage for (at least a subset) of the issues with 3rd party redirects and if no-one else is working on the problem we may have an issue when we come to define the CDNI solution in detail. I appreciate your offer to do some digging and we can see where that leads.

In the meantime I would propose that we make the requirement more general to refer to 3rd party redirects. We can use IP address literals as one example of how they can be problematic if folks want to include it explicitly. When we come to do the detailed specification work we will hopefully have a better view as to what existing work there is that we could leverage and if there is no such work we can take AD advice on how to stimulate that more general work (and the appropriate place to try and do it) or whether we should go and define a solution for CDNI by ourselves (e.g. if there is not the energy in the community to take on the more general problem space of 3rd party redirects).

Does that sound reasonable and address your concerns?

Ben

---

From: David R Oran <[email-masked]>
Date: Thu, 3 Feb 2011 18:09:21 -0500

> Does that sound reasonable and address your concerns?
WFM!

Thanks, DaveO.