Subject: Re: [CDNi] Loop detection requirement

From: "GUILLOU, Allan" <[email-masked]>
Date: Wed, 2 Mar 2011 11:33:56 +0100

Hi all,

Maybe using BGP to exchange the information between the different CDN could be interesting to avoid this kind of problem. 
 
The idea is that all the CDN have multiple eBGP peering with its partner and send the IP prefixs that it can stream associated with communities that tell the capabilities of its streamers (for exemple :1 for streaming over http, :2 ..).

On the routing request, or on the rewrite URL, each CDN can add its AS to do the same as an AS PATH on a BGP route.

So when you choose your "best partner" with your criteria of proximity, capability, cost, you can check that it AS is not present on this AS PATH and do not avoid path.

Cheers,

Allan

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] De la part de Lee, Yiu
Envoyé : lundi 14 février 2011 19:59
À : [email-masked]; [email-masked]; [email-masked]
Cc : [email-masked]; [email-masked]
Objet : Re: [CDNi] Loop detection requirement

Hi Phil, Emile and all,

I think we all agree that there is a requirement to prevent looping. It is
as important to prevent looping at 1-level deep or multiple-level deep. We
also agree that the Routing Request API should also indicate the max level
of delegation should allow. These are all captured in the REQ-ID. If they
are not clear, we are welcome to any input to improve the REQ-ID.

Perhaps it may be too early to speak of solution, but I would love to hear
people flowing ideas in the list :-)

Cheers,
Yiu

On 2/11/11 10:23 AM, "[email-masked]"
<[email-masked]> wrote:

>Hi Phil,
>
>See below
>
>> -----Message d'origine-----
>> De : [email-masked] [mailto:[email-masked]]
>> Envoyé : vendredi 11 février 2011 14:59
>> À : STEPHAN Emile RD-CORE-LAN; [email-masked]
>> Cc : [email-masked]; [email-masked]; [email-masked]
>> Objet : RE: [CDNi] Loop detection requirement
>> 
>> 
>> 
>> -----Original Message-----
>> From: [email-masked] [mailto:emile.stephan@orange-
>> ftgroup.com]
>> Sent: 07 February 2011 08:29
>> To: [email-masked]; Eardley,PL,Philip,DES8 R
>> Cc: [email-masked]; [email-masked]; [email-masked]
>> Subject: RE: [CDNi] Loop detection requirement
>> 
>> Hi Francois,
>> 
>> CDNI interfaces must support loop detection even when there is only 2
>>CDNs
>> interconnected. Hence this req is tied nor to the number of CDNs of the
>> CDNi chain nor to its nature.
>> 
>> So imo support for loop detection is a generic MUST that applies to each
>> CDNi APIs.
>> 
>> [phil] well, in the case with only 2 CDNs interconnected, solving loop
>> detection is trivial; if there is a chain then it is not clear to me
>>that
>> the issues are trivial.
>
>IMO the check is identical in both cases: a CDN must check that it is not
>trying to provide a service that it asked for.
>
>Do we defined 'chain' ?
>
>Regards
>emile 
>
>
>This is not just about loop detection - for
>> instance, for the logging API, do you need a common agreement along the
>> chain about logging format, security, what "real time" means, etc? Eg,
>>if
>> A & B agree one format and B & C agree a different format, then do you
>> need to translate it?
>> If the "chain issues" are tricky to solve, then starting with the
>> assumption of no chain would make the scope more manageable. Of course,
>>if
>> the "chain issues" are easy to solve then the scope is still manageable.
>> Phil/
>> 
>> 
>> I suggest inserting this req directly in the header of the section 3 of
>> the req draft.
>> 
>> 
>> Regards
>> Emile
>> 
>> 
>> > -----Message d'origine-----
>> > De : [email-masked] [mailto:[email-masked]] De la part
>>de
>> > Francois Le Faucheur
>> > Envoyé : jeudi 3 février 2011 11:29
>> > À : [email-masked]
>> > Cc : [email-masked]; [email-masked]; [email-masked]
>> > Objet : Re: [CDNi] Limit nb of redirects & loop sRe: CDNI Requirements
>> I-D
>> >
>> > Hi Phil,
>> >
>> > On 3 Feb 2011, at 11:18, <[email-masked]> wrote:
>> >
>> >
>> >     Cascaded CDNs would be nice.
>> >
>> >     Cascading is missing from the logging section - where it seems
>>hard.
>> > the logging record needs to include (aggregated) info where content
>>has
>> > been delivered to a UA by a CDN further down a cascade of CDNs.
>> >
>> >
>> > There are requirements in the Security section that relate to that:
>> >
>> > "
>> >    R71  The CDNI solution MUST be able to ensure that for any given
>> >         request redirected to a Downstream CDN, the chain of CDN
>> >         Delegation (leading to that request being served by that CDN)
>> >         can be established with non-repudiation.
>> >
>> >    R72  The CDNI solution MUST be able to ensure that the Downstream
>>CDN
>> >         cannot spoof a transaction log attempting to appear as if it
>> >         corresponds to a request redirected by a given Upstream CDN
>>when
>> >         that request has not been redirected by this Upstream CDN.
>> > "
>> >
>> > This is meant to apply also to the Logging API.
>> > Is that sufficient to capture the topic or do you want to see a
>>specific
>> > requirement under the "Logging API" section?
>> >
>> >
>> >
>> >     This is quite challenging, especially if one allows any
>>flexibility
>> > over what is reported, format of reports, security methods, real-time
>> > reports, etc.
>> >
>> >
>> >
>> >     Agree that cascading should be mentioned as a generic requirement
>>-
>> > and we treat it at the same requirements level for all the APIs
>>(whether
>> > that's: MUST in initial scope, SHOULD, or beyond initial scope).
>> >
>> >     Personally think there is quite a lot "within initial scope" in
>>the
>> > requirements draft, and cascading might be deferrable if it adds
>> > significant work to standardising the APIs - as most of the value of
>>CDN
>> > interconnect seems to come from the "one hop" case ie:
>> >     CSP -> Upstream CDN -> Downstream CDN -> UA
>> >
>> >
>> >
>> > I take this as a "B" Vote.
>> >
>> > Thanks
>> >
>> > Francois
>> >
>> >
>> >
>> >
>> >     -----Original Message-----
>> >     From: [email-masked] [mailto:[email-masked]] On
>>Behalf
>> > Of Francois Le Faucheur
>> >     Sent: 02 February 2011 10:45
>> >     To: David R Oran
>> >     Cc: [email-masked]; Viveganandhan Mahesh; Yiu Lee
>> >     Subject: Re: [CDNi] Limit nb of redirects & loop sRe: CDNI
>> > Requirements I-D
>> >
>> >     Dave and all,
>> >
>> >     On 2 Feb 2011, at 01:53, David R Oran wrote:
>> >
>> >
>> >
>> >
>> >         On Feb 1, 2011, at 2:25 PM, Ben Niven-Jenkins wrote:
>> >
>> >
>> >
>> >             Francois,
>> >
>> >
>> >
>> >             On 1 Feb 2011, at 19:00, Francois Le Faucheur wrote:
>> >
>> >
>> >                 This discussion drifted from (i) the ability to
>> > limit the number of CDN redirections (for the sake of avoiding
>> degradation
>> > of user experience) into a discussion on (ii) preventing loops in
>> request
>> > touting and other information exchange.
>> >
>> >
>> >
>> >
>> >             That's my fault because I wasn't distinguishing between
>> > loop detection of CDN redirections and other types of loop detection.
>> >
>> >
>> >
>> >                 (i) is addressed in:
>> >
>> >
>> >                 "
>> >
>> >
>> >                 R34  The CDNI Request-Routing API SHOULD support
>> > optional enforcement
>> >
>> >
>> >                     of a limit on the number of successive CDN
>> > redirections for a
>> >
>> >
>> >                     given request.
>> >
>> >
>> >                 "
>> >
>> >
>> >
>> >                 (ii) is currently addressed in :
>> >
>> >
>> >
>> >                 R32  The CDNI Request-Routing API SHOULD support
>> > request loop
>> >
>> >
>> >                     detection and prevention (e.g.  Prevent
>> > request looping in a
>> >
>> >
>> >                     situation where CDN1 redirects to CDN2 that
>> > redirects to CDN3
>> >
>> >
>> >                     that would redirect to CDN1).
>> >
>> >
>> >
>> >                 R33  The CDNI Request-Routing loop prevention
>> > mechanism SHOULD allow
>> >
>> >
>> >                     routing of the request (as opposed to the
>> > request loop being
>> >
>> >
>> >                     simply interrupted without routing the
>> > request).
>> >
>> >
>> >
>> >                 (as well as R39 and R40 for longer term)
>> >
>> >
>> >
>> >                 R55  If cascaded CDNs are supported by the CDNI
>> > solution, the CDNI
>> >
>> >
>> >                     Metadata API MUST prevent looping of CDNI
>> > Metadata distribution
>> >
>> >
>> >                     across CDNs.
>> >
>> >
>> >
>> >                 Do you guys still think something is missing?
>> >
>> >
>> >                 Can you suggest something to cover missing bits?
>> >
>> >
>> >
>> >
>> >             For CDNI Request Routing the above is fine. What I'm
>> > saying is I think loop detection also applies to the control API and
>>may
>> > be useful in the other APIs.
>> >
>> >
>> >
>> >             I'd therefore suggest making loop detection a general
>> > requirement (SHOULD) and any more specific requirements (e.g. R33)
>>under
>> > the specific API they apply to.
>> >
>> >
>> >
>> >         I think the requirement is stronger: CDNs need to agree on a
>> > common mechanism for loop detection;
>> >
>> >
>> >
>> >     I agree it is a MUST (as along as "cascaded CDNs" are supported).
>> >     In the Requirements I-D it was presented:
>> >     * as a "MUST" for longer term
>> >     * as a "SHOULD" for shorter term, because support of cascaded CDNs
>> > itself is only listed as a SHOULD for the shorter term (on the grounds
>> > that not supporting it may potentially allow definition of a simpler
>> > solution faster)
>> >
>> >     I think we could either:
>> >
>> >     *A*:
>> >     * agree right now that the shorter term solution (ie within
>>initial
>> > charter scope) MUST support cascaded CDNs
>> >     * include a MUST requirement for loop prevention in the Generic
>> > Reqts section and possibly in each API specific section (Control,
>> Request-
>> > Routing, Metadata)
>> >
>> >     *B:
>> >     * defer the decision about support of cascaded CDNs in shorter
>>term
>> > (ie within initial charter scope) to further discussions
>> >     * include a "conditional" MUST (ie "if cascaded CDNs are
>> > supported,...") in the Generic Reqts section and possibly in each API
>> > specific section (Control, Request-Routing, Metadata)
>> >
>> >     I would vote for *A* because:
>> >     * we wouldn't want to go for a shorter term solution that cannot
>>be
>> > easily extended to support cascaded CDNs
>> >     * there are short term use cases for cascaded CDNs.
>> >
>> >     other voters?
>> >
>> >     Thanks
>> >
>> >     Francois
>> >
>> >
>> >
>> >         otherwise you can get multiplicative loop diameters and
>> > effectively not have useful loop detection when the non-looping paths
>> are
>> > long. This is routing; we know what happens when you do loop detect
>>with
>> > thing like count-to-infinity.
>> >
>> >
>> >
>> >         Incidently, my favorite loop detection scheme was invented by
>> > Knuth all the way back in volume 2. It has the nice property of
>> detecting
>> > loops in constant memory and with an upper bound of traversing the
>>loop
>> 2
>> > times, for all loop diameters. Look it up - it's called the "even-odd
>> > iteration counting".
>> >
>> >
>> >
>> >         DaveO.
>> >
>> >
>> >
>> >
>> >             Thanks
>> >
>> >
>> >             Ben
>> >
>> >
>> >
>> >
>> >             _______________________________________________
>> >
>> >
>> >             CDNi mailing list
>> >
>> >
>> >             [email-masked]
>> >
>> >
>> >             https://www.ietf.org/mailman/listinfo/cdni
>> >
>> >
>> >
>> >
>> >     _______________________________________________
>> >     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 <http://www.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
>> >
>> >
>

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

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Thu, 3 Mar 2011 14:56:46 +0000

Hi Allan,

> So when you choose your "best partner" with your criteria of proximity, capability, cost, you can check that it AS is not present on this AS PATH and do not avoid path.

I think we can look to how other protocols solve loop detection and reuse an appropriate method where the way BGP uses ASPATH would be an example of how another protocol solves loop detection.

However, I do not think it is appropriate for CDNI to overload BGP to do everything we need. BGP is IMO not an appropriate protocol to encoding metadata properties or for making Request Routing requests to another CDN.

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Thu, 3 Mar 2011 17:05:38 +0000

On 3 Mar 2011, at 15:58, GUILLOU, Allan wrote:

> Hi Ben,
> 
> The point is that the geoloc functionality is really similar than an IP routing protocol. It is done to see which CDN is nearest than another from the IP address of the subscriber. That is why a routing protocol seems to feet well with this.
> 

I agree that routing protocols can be used to provide information useful for geo-location. I think that issue is largely orthogonal to CDNI. 

> The idea is not to use bgp for request routing, but to use it or something similar to create the geoloc database. In this case, the AS number can be reused in the request routing to avoid resending it to a cdn which has already response.
> 

This is my confusion based on you responding to an e-mail chain talking about detecting loops in between Request Routers by suggesting BGP as a solution.

We need loop detection, we can work on the specific method to use after a WG is formed I think.

Thanks
Ben

>> De : Ben Niven-Jenkins [mailto:[email-masked]]
>> Envoyé : jeudi 3 mars 2011 15:57
>> À : GUILLOU, Allan
>> Cc : 'Lee, Yiu'; [email-masked]; [email-masked];
>> [email-masked]; [email-masked]; [email-masked]
>>> Maybe using BGP to exchange the information between the different CDN
>> could be interesting to avoid this kind of problem.
>>> 
>>> The idea is that all the CDN have multiple eBGP peering with its partner
>> and send the IP prefixs that it can stream associated with communities
>> that tell the capabilities of its streamers (for exemple :1 for streaming
>> over http, :2 ..).
>>> 
>>> On the routing request, or on the rewrite URL, each CDN can add its AS
>> to do the same as an AS PATH on a BGP route.
>>> 
>>> So when you choose your "best partner" with your criteria of proximity,
>> capability, cost, you can check that it AS is not present on this AS PATH
>> and do not avoid path.
>>> 
>> 
>> I think we can look to how other protocols solve loop detection and reuse
>> an appropriate method where the way BGP uses ASPATH would be an example of
>> how another protocol solves loop detection.
>> 
>> However, I do not think it is appropriate for CDNI to overload BGP to do
>> everything we need. BGP is IMO not an appropriate protocol to encoding
>> metadata properties or for making Request Routing requests to another CDN.
>> 
>> 
>> 
>>> Cheers,
>>> 
>>> Allan
>>>

---

From: "Lee, Yiu" <[email-masked]>
Date: Fri, 4 Mar 2011 15:48:55 +0000

Hi Ben and Allan,

I second Ben. We have many ways to detect loops and BGP may be too heavy
for this purpose. 

I also agree with Ben that the geo-location function should not be solved
in CDNi.  

Cheers,
Yiu

On 3/3/11 12:05 PM, "Ben Niven-Jenkins" <[email-masked]> wrote:

>> The point is that the geoloc functionality is really similar than an IP
>>routing protocol. It is done to see which CDN is nearest than another
>>from the IP address of the subscriber. That is why a routing protocol
>>seems to feet well with this.
>> 
>
>I agree that routing protocols can be used to provide information useful
>for geo-location. I think that issue is largely orthogonal to CDNI.
>
>> The idea is not to use bgp for request routing, but to use it or
>>something similar to create the geoloc database. In this case, the AS
>>number can be reused in the request routing to avoid resending it to a
>>cdn which has already response.
>> 
>
>This is my confusion based on you responding to an e-mail chain talking
>about detecting loops in between Request Routers by suggesting BGP as a
>solution.
>
>>> Lee, Yiu
>>>> I think we all agree that there is a requirement to prevent looping.
>>>>It
>>> is
>>>> as important to prevent looping at 1-level deep or multiple-level
>>>>deep.
>>> We

---

From: "Woundy, Richard" <[email-masked]>
Date: Fri, 4 Mar 2011 18:40:30 +0000

> I also agree with Ben that the geo-location function should not be solved in CDNi.

Agreed. FYI, geo-location has been an item of interest for the ALTO WG.

<http://datatracker.ietf.org/doc/draft-penno-alto-cdn/>
<http://www.ietf.org/proceedings/79/slides/alto-10.pdf>

-- Rich

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Lee, Yiu
Sent: Friday, March 04, 2011 10:49 AM
To: Ben Niven-Jenkins; GUILLOU, Allan
Cc: [email-masked]; [email-masked]
Subject: Re: [CDNi] Loop detection requirement

Hi Ben and Allan,

Cheers,
Yiu

---

From: Francois Le Faucheur <[email-masked]>
Date: Mon, 7 Mar 2011 16:51:11 +0100

Hello Yiu and all,

> I also agree with Ben that the geo-location function should not be solved

The term "geo-location" may be creating some confusion here.

I think there was some convergence on the idea that a target CDNi solution would allow a Downstream CDN to advertise information to help upstream CDNs Request Routing system make better redirection decisions (ie more informed Downstream CDN selection). For example, a Downstream CDN could advertise the footprint that it is willing to serve as well as some information about its abilities/willingness/cost to do so and possibly some information to facilitate redirection towards this downstream CDN. 
This is currently discussed in R20 of cdni-requirements-00.
(Whether this is to be included or not, or partially, in an initial charter is still TBD, but that is a separate question).

As mentioned by Richard in a response to this message, ALTO has been working on providing network proximity information. It can be seen as a candidate base protocol for the exchange of the information discussed above to facilitate CDNi CDN selection. Perhaps some new ALTO "network map" format for CDNi.

I believe Allan is making a valid point that BGP is an alternative candidate protocol to consider for the exchange of information to facilitate CDNi CDN Selection. 
Resolving the looping issue (for distribution of CDNi information to facilitate CDN selection- which is different to the question of solving looping of actual request redirection) is just one of the properties that BGP would bring in for free. Policy control is another one.

While it is early to discuss solution details, I think it is useful to have a high level idea/discussion on candidate approaches for building the various CDNi components and how much we can leverage.

Francois

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.

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: "Lee, Yiu" <[email-masked]>
Date: Tue, 8 Mar 2011 03:13:13 +0000

Hi Francois,

I think this depends on what people agree with the WG to work on short-term vs. long-term. Yes, the WG can work on the problem to allow downstream CDN to dynamically advertise the location information to the upstream. IMHO, this is a hard problem and not requires immediate attention right now. We could defer it after the WG finish specify the core protocol for CDNi.

Comments and thoughts?
/Yiu

From: Francois Le Faucheur <[email-masked]<mailto:[email-masked]>>
Date: Mon, 7 Mar 2011 16:51:11 +0100
To: Microsoft Office User <[email-masked]<mailto:[email-masked]>>
Cc: Francois Le Faucheur <[email-masked]<mailto:[email-masked]>>, Ben Niven-Jenkins <[email-masked]<mailto:[email-masked]>>, "GUILLOU, Allan" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [CDNi] Loop detection requirement

Hello Yiu and all,

Hi Ben and Allan,

Francois

Cheers,
Yiu

On 3/3/11 12:05 PM, "Ben Niven-Jenkins" <[email-masked]<mailto:[email-masked]>> wrote:

Hi Ben,

We need loop detection, we can work on the specific method to use after a
WG is formed I think.

Thanks
Ben

-----Message d'origine-----
De : Ben Niven-Jenkins [mailto:[email-masked]]
Envoyé : jeudi 3 mars 2011 15:57
À : GUILLOU, Allan
Cc : 'Lee, Yiu'; [email-masked]<mailto:[email-masked]>;
[email-masked]<mailto:[email-masked]>;
[email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Objet : Re: [CDNi] Loop detection requirement

Hi Allan,

Hi all,

The idea is that all the CDN have multiple eBGP peering with its
partner
and send the IP prefixs that it can stream associated with communities
that tell the capabilities of its streamers (for exemple :1 for
streaming
over http, :2 ..).

So when you choose your "best partner" with your criteria of
proximity,
capability, cost, you can check that it AS is not present on this AS
PATH
and do not avoid path.

I think we can look to how other protocols solve loop detection and
reuse
an appropriate method where the way BGP uses ASPATH would be an
example of
how another protocol solves loop detection.

However, I do not think it is appropriate for CDNI to overload BGP to
do
everything we need. BGP is IMO not an appropriate protocol to encoding
metadata properties or for making Request Routing requests to another
CDN.

Cheers,

Allan

-----Message d'origine-----
De : [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] De la part
de
Lee, Yiu
Envoyé : lundi 14 février 2011 19:59
À : [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>;
[email-masked]<mailto:[email-masked]>
Cc : [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Objet : Re: [CDNi] Loop detection requirement

Hi Phil, Emile and all,

I think we all agree that there is a requirement to prevent looping.
It
is
as important to prevent looping at 1-level deep or multiple-level
deep.
We
also agree that the Routing Request API should also indicate the max
level
of delegation should allow. These are all captured in the REQ-ID. If
they
are not clear, we are welcome to any input to improve the REQ-ID.

Perhaps it may be too early to speak of solution, but I would love to
hear
people flowing ideas in the list :-)

Cheers,
Yiu

On 2/11/11 10:23 AM, "[email-masked]<mailto:[email-masked]>"
<[email-masked]<mailto:[email-masked]>> wrote:

Hi Phil,

See below

-----Message d'origine-----
De : [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]
Envoyé : vendredi 11 février 2011 14:59
À : STEPHAN Emile RD-CORE-LAN; [email-masked]<mailto:[email-masked]>
Cc : [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Objet : RE: [CDNi] Loop detection requirement

-----Original Message-----
From: [email-masked]<mailto:[email-masked]> [mailto:emile.stephan@orange-
ftgroup.com]
Sent: 07 February 2011 08:29
To: [email-masked]<mailto:[email-masked]>; Eardley,PL,Philip,DES8 R
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: RE: [CDNi] Loop detection requirement

Hi Francois,

CDNI interfaces must support loop detection even when there is only
2
CDNs
interconnected. Hence this req is tied nor to the number of CDNs of
the
CDNi chain nor to its nature.

So imo support for loop detection is a generic MUST that applies to
each
CDNi APIs.

[phil] well, in the case with only 2 CDNs interconnected, solving
loop
detection is trivial; if there is a chain then it is not clear to me
that
the issues are trivial.

IMO the check is identical in both cases: a CDN must check that it is
not
trying to provide a service that it asked for.

Do we defined 'chain' ?

Regards
emile

This is not just about loop detection - for
instance, for the logging API, do you need a common agreement along
the
chain about logging format, security, what "real time" means, etc?
Eg,
if
A & B agree one format and B & C agree a different format, then do
you
need to translate it?
If the "chain issues" are tricky to solve, then starting with the
assumption of no chain would make the scope more manageable. Of
course,
if
the "chain issues" are easy to solve then the scope is still
manageable.
Phil/

I suggest inserting this req directly in the header of the section 3
of
the req draft.

Regards
Emile

-----Message d'origine-----
De : [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] De la
part
de
Francois Le Faucheur
Envoyé : jeudi 3 février 2011 11:29
À : [email-masked]<mailto:[email-masked]>
Cc : [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Objet : Re: [CDNi] Limit nb of redirects & loop sRe: CDNI
Requirements
I-D

Hi Phil,

On 3 Feb 2011, at 11:18, <[email-masked]<mailto:[email-masked]>> wrote:

"

 This is quite challenging, especially if one allows any
flexibility
over what is reported, format of reports, security methods,
real-time
reports, etc.

significant work to standardising the APIs - as most of the value
of

Thanks

Francois

 -----Original Message-----
 From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On
Behalf
Of Francois Le Faucheur
 Sent: 02 February 2011 10:45
 To: David R Oran
 Cc: [email-masked]<mailto:[email-masked]>; Viveganandhan Mahesh; Yiu Lee
 Subject: Re: [CDNi] Limit nb of redirects & loop sRe: CDNI
Requirements I-D

 Dave and all,

         Francois,

         That's my fault because I wasn't distinguishing between
loop detection of CDN redirections and other types of loop
detection.

             (i) is addressed in:

             "

                 given request.

             "

                 across CDNs.

         For CDNI Request Routing the above is fine. What I'm
saying is I think loop detection also applies to the control API
and
may
be useful in the other APIs.

 I agree it is a MUST (as along as "cascaded CDNs" are supported).
 In the Requirements I-D it was presented:
 * as a "MUST" for longer term
 * as a "SHOULD" for shorter term, because support of cascaded
CDNs
itself is only listed as a SHOULD for the shorter term (on the
grounds
that not supporting it may potentially allow definition of a
simpler
solution faster)

 I think we could either:

 *A*:

 *B:
supported,...") in the Generic Reqts section and possibly in each
API

 other voters?

 Thanks

 Francois

     otherwise you can get multiplicative loop diameters and
effectively not have useful loop detection when the non-looping
paths
are
long. This is routing; we know what happens when you do loop detect
with
thing like count-to-infinity.

     Incidently, my favorite loop detection scheme was invented by
Knuth all the way back in volume 2. It has the nice property of
detecting
loops in constant memory and with an upper bound of traversing the
loop
2
times, for all loop diameters. Look it up - it's called the
"even-odd
iteration counting".

     DaveO.

         Thanks

         Ben

         CDNi mailing list

         [email-masked]<mailto:[email-masked]>

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

Francois Le Faucheur
Distinguished Engineer
Corporate Development
[email-masked]<mailto:[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<http://Cisco.com> <http://www.cisco.com>

Think before you print.

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

Francois Le Faucheur
Distinguished Engineer
Corporate Development
[email-masked]<mailto:[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<http://www.cisco.com>

 Think before you print.

---

From: Jan Medved <[email-masked]>
Date: Mon, 7 Mar 2011 23:29:05 -0800

Hi Francois,

Please see inline.

Thanks,
Jan

From: Francois Le Faucheur <[email-masked]<mailto:[email-masked]>>
Date: Mon, 7 Mar 2011 07:51:11 -0800
To: "Lee, Yiu" <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [CDNi] Loop detection requirement

Hello Yiu and all,

Hi Ben and Allan,

I agree that ALTO is a good candidate for this (probably the best, IMO). The format would likely not change – it would still be the regular network and cost maps, as defined by the ALTO draft. What will be needed is a convention / normalization of the information that goes into the maps, and how the maps are constructed from the underlying topology, load, geolocation, … data.

Yes, agreed on this one too. Please look at draft-gredler-bgp-te-00 (http://datatracker.ietf.org/doc/draft-gredler-bgp-te), which proposes a way to carry this kind of information in BGP.

Francois

Cheers,
Yiu

Hi Ben,

Thanks
Ben

-----Message d'origine-----
De : Ben Niven-Jenkins [mailto:[email-masked]]
Envoyé : jeudi 3 mars 2011 15:57
À : GUILLOU, Allan
Cc : 'Lee, Yiu'; [email-masked]<mailto:[email-masked]>;

Hi Allan,

Hi all,

Cheers,

Allan

-----Message d'origine-----

Hi Phil, Emile and all,

Cheers,
Yiu

Hi Phil,

See below

-----Message d'origine-----
De : [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]
Envoyé : vendredi 11 février 2011 14:59
À : STEPHAN Emile RD-CORE-LAN; [email-masked]<mailto:[email-masked]>
Cc : [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Objet : RE: [CDNi] Loop detection requirement

-----Original Message-----

Hi Francois,

Do we defined 'chain' ?

Regards
emile

Regards
Emile

-----Message d'origine-----

Hi Phil,

"

Thanks

Francois

 -----Original Message-----

 Dave and all,

         Francois,

             (i) is addressed in:

             "

                 given request.

             "

                 across CDNs.

 I think we could either:

 *A*:

 *B:

 other voters?

 Thanks

 Francois

     DaveO.

         Thanks

         Ben

         CDNi mailing list

Francois Le Faucheur
Distinguished Engineer
Corporate Development

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

Think before you print.

Francois Le Faucheur
Distinguished Engineer
Corporate Development

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

 Think before you print.

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Wed, 9 Mar 2011 14:20:05 +0000

Colleagues,

At this point in time I suggest we put on hold any discussion of the "best" method/protocol for exchanging geo-location information and concentrate on what we need to do to the problem statement, requirements, etc. to achieve consensus to form a WG and what the initial charter scope of such a WG should be. Detailed discussions of particular approaches to solving the problem are likely to just distract from our immediate task of developing and demonstrating consensus for a new WG.

Ben