Subject: [CCAMP] draft-ietf-ccamp-te-metric-recording-02

From: John E Drake <[email-masked]>
Date: Thu, 8 Aug 2013 21:15:05 +0000

Hi,

I think there is a basic issue with this draft, which is that the server network manages its own TE metrics and those metrics almost certainly have nothing in common with the TE metrics used in a given client network.

Given this, would it not be better to have policy in the client nodes that maps the characteristics of a given LSP established across the server network into the TE metric to be advertised with that LSP in the client network?

Yours Irrespectively,

John

---

From: Igor Bryskin <[email-masked]>
Date: Thu, 8 Aug 2013 21:36:07 +0000

John,
I agree completely with you.

Cheers,
Igor

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of John E Drake
Sent: Thursday, August 08, 2013 5:15 PM
To: CCAMP ([email-masked])
Subject: [CCAMP] draft-ietf-ccamp-te-metric-recording-02

Hi,

Yours Irrespectively,

John

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

---

From: "Matt Hartley (mhartley)" <[email-masked]>
Date: Fri, 9 Aug 2013 15:07:17 +0000

John,

The point you raise is a good one, but I don't think it has much to do with this draft.

> I think there is a basic issue with this draft, which is that the server
> network manages its own TE metrics and those metrics almost certainly have
> nothing in common with the TE metrics used in a given client network.

So if I understand you correctly, you're just saying that "cost" is a somewhat vague thing that may mean different things to different network operators? This is true sometimes, but that doesn't mean it will always be the case. And I think concepts such as latency and latency variation are less prone to this problem; when we talk about "latency", I'm reasonably sure we all mean the same thing.

> Given this, would it not be better to have policy in the client nodes that
> maps the characteristics of a given LSP established across the server network
> into the TE metric to be advertised with that LSP in the client network?

Certainly that might be a good idea... but it's beyond the scope of this draft. If you want to map the characteristics of a given LSP established across the server network into the TE metric to be advertised with that LSP in the client network, you first have to know what the characteristics of the LSP across the server network are... and that's what this draft is for; it's simply about the discovery of the information, not what you choose to do with it afterwards.

Cheers

Matt

---

From: John E Drake <[email-masked]>
Date: Fri, 9 Aug 2013 15:41:58 +0000

Yours Irrespectively,

John

> From: Matt Hartley (mhartley) [mailto:[email-masked]]
> Sent: Friday, August 09, 2013 8:07 AM
> To: John E Drake; CCAMP ([email-masked])
> Cc: Matt Hartley (mhartley)
> Subject: RE: draft-ietf-ccamp-te-metric-recording-02
> 
> John,
> 

JD:  This draft is proposing that the cumulative TE metric associated with the establishment of an LSP in the server network be passed to the client LSP endpoints.  My point is that this is probably useless at best.
 
> 
> > I think there is a basic issue with this draft, which is that the
> > server network manages its own TE metrics and those metrics almost
> > certainly have nothing in common with the TE metrics used in a given client
> network.
> 
> So if I understand you correctly, you're just saying that "cost" is a somewhat
> vague thing that may mean different things to different network operators?
> This is true sometimes, but that doesn't mean it will always be the case.

JD:  You have no way of knowing whether there is any congruence between the TE metrics in the server network and the TE metrics in a client network.

> And I
> think concepts such as latency and latency variation are less prone to this
> problem; when we talk about "latency", I'm reasonably sure we all mean the
> same thing.

JD:  I didn't say anything about latency, however, since you mention it, I think it would be far better for the clients to measure latency.

> 
> > Given this, would it not be better to have policy in the client nodes
> > that maps the characteristics of a given LSP established across the
> > server network into the TE metric to be advertised with that LSP in the
> client network?
> 
> Certainly that might be a good idea... but it's beyond the scope of this draft.
> If you want to map the characteristics of a given LSP established across the
> server network into the TE metric to be advertised with that LSP in the client
> network, you first have to know what the characteristics of the LSP across
> the server network are... and that's what this draft is for; it's simply about the
> discovery of the information, not what you choose to do with it afterwards.

JD:  I think you are missing my point.  The accumulated TE metric for an LSP in the server network is not a characteristic that is of any use to the client, so what I am proposing is that it be removed from the draft.

---

From: "Zafar Ali (zali)" <[email-masked]>
Date: Fri, 9 Aug 2013 15:54:02 +0000

Hi John:

Please see in-line.

Thanks

Regards Š Zafar

-----Original Message-----
From: "[email-masked]" <[email-masked]>
Date: Friday, August 9, 2013 11:41 AM
To: "Matt Hartley (mhartley)" <[email-masked]>, "[email-masked]"
<[email-masked]>
Subject: Re: [CCAMP] draft-ietf-ccamp-te-metric-recording-02

>> The point you raise is a good one, but I don't think it has much to do
>>with this
>> draft.
>
>JD:  This draft is proposing that the cumulative TE metric associated
>with the establishment of an LSP in the server network be passed to the
>client LSP endpoints.  My point is that this is probably useless at best.

This is all controlled by policy at the client layer and depends on the
use cases of independent vs. dependent costs.

>JD:  You have no way of knowing whether there is any congruence between
>the TE metrics in the server network and the TE metrics in a client
>network.

This is all controlled by policy at the client layer.
><snip>

---

From: Igor Bryskin <[email-masked]>
Date: Fri, 9 Aug 2013 16:14:17 +0000

Matt,

John's point is that the costs of a TE link in a client layer are not "something vague"  or something absolute as you imply, rather, something that can relate said TE link to other client layer TE links, and such costs have nothing to do with the costs of the server LSPs supporting them. Consider the following:
a) static client  layer TE link 0;
b) client layer TE link 1 supported by a server layer LSP1 in server domain 1;
c) client layer TE link  2 supported by a server layer LSP2 in server domain 2

The point is that the costs collected for, say,  LSP1 do not help in any way to define the costs of TE Link1 as compared to costs of TE link 0 or TE link2;

Cheers,
Igor

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Matt Hartley (mhartley)
Sent: Friday, August 09, 2013 11:07 AM
To: John E Drake; CCAMP ([email-masked])
Subject: Re: [CCAMP] draft-ietf-ccamp-te-metric-recording-02

John,

> certainly have nothing in common with the TE metrics used in a given client network.

> server network into the TE metric to be advertised with that LSP in the client network?

Cheers

Matt

---

From: John E Drake <[email-masked]>
Date: Fri, 9 Aug 2013 16:32:30 +0000

Zafar,

Given that a client has no idea what the TE metric it receives from the server network means, how exactly does this work?

Yours Irrespectively,

John

> From: Zafar Ali (zali) [mailto:[email-masked]]
> Sent: Friday, August 09, 2013 8:54 AM
> To: John E Drake; Matt Hartley (mhartley); CCAMP ([email-masked])
> This is all controlled by policy at the client layer and depends on the use cases
> of independent vs. dependent costs.
> 
> >
> >>
> >> > certainly have nothing in common with the TE metrics used in a
> >> > given
> >>client
> >> network.
> >>
> >> So if I understand you correctly, you're just saying that "cost" is a
> >>somewhat  vague thing that may mean different things to different
> >>network operators?

---

From: "Zafar Ali (zali)" <[email-masked]>
Date: Fri, 9 Aug 2013 16:55:58 +0000

John- 

Of course, client knows that the metric represents server layer cost of
using this connection.

Thanks

Regards Š Zafar

-----Original Message-----
From: "[email-masked]" <[email-masked]>
Date: Friday, August 9, 2013 12:32 PM
To: zali <[email-masked]>, "Matt Hartley (mhartley)" <[email-masked]>,
"[email-masked]" <[email-masked]>
Subject: RE: [CCAMP] draft-ietf-ccamp-te-metric-recording-02

>Zafar,
>
>Given that a client has no idea what the TE metric it receives from the
>server network means, how exactly does this work?
>
>Yours Irrespectively,
>
>John
><snip>

---

From: John E Drake <[email-masked]>
Date: Fri, 9 Aug 2013 17:34:25 +0000

Zafar,

And what normalization function does it use to turn this value, which is a dimensionless number which has meaning only in the context of the server network, into a TE metric that has meaning in the client network? 

Yours Irrespectively,

John

> Sent: Friday, August 09, 2013 9:56 AM
> Of course, client knows that the metric represents server layer cost of using
> this connection.
> 
> Thanks
> 
> Regards Š Zafar
> 
> 
>

---

From: "Zafar Ali (zali)" <[email-masked]>
Date: Fri, 9 Aug 2013 17:38:50 +0000

Hi John- 

Client could apply a transformation (via offline policy); it can also use
server cost as a measure of relative cost of the connections.

Thanks

Regards ... Zafar

-----Original Message-----
From: "[email-masked]" <[email-masked]>
Date: Friday, August 9, 2013 1:34 PM
To: zali <[email-masked]>, "Matt Hartley (mhartley)" <[email-masked]>,

>Zafar,
>
>And what normalization function does it use to turn this value, which is
>a dimensionless number which has meaning only in the context of the
>server network, into a TE metric that has meaning in the client network?
>
>Yours Irrespectively,
>
>John
>
>>using

---

From: John E Drake <[email-masked]>
Date: Fri, 9 Aug 2013 17:53:41 +0000

Zafar,

I just don't think you understand the problem.  Did you read Igor's email?

Yours Irrespectively,

John

> Sent: Friday, August 09, 2013 10:39 AM
> Client could apply a transformation (via offline policy); it can also use server
> cost as a measure of relative cost of the connections.
> 
> Thanks
> 
> Regards ... Zafar
> 
> 
> >And what normalization function does it use to turn this value, which
> >is a dimensionless number which has meaning only in the context of the
> >> Of course, client knows that the metric represents server layer cost
> >>of using  this connection.
> >>
> >> Thanks
> >>
> >> Regards Š Zafar
> >>
> >>
> >>
> >> >Given that a client has no idea what the TE metric it receives from
> >> >the server network means, how exactly does this work?
> >> >
> >> >Yours Irrespectively,
> >> >
> >> >John
> >> ><snip>
> >>
> >>
> >
> >
> 
>

---

From: "Matt Hartley (mhartley)" <[email-masked]>
Date: Fri, 9 Aug 2013 20:30:59 +0000

Igor, John,

It seems that we have a simple disagreement here about whether discovering the cost of a LSP over a server layer is any use at all. I don't agree that it's as completely useless as you assert.

While it would certainly be very hard to make much of it in the complete absence of other communication between the operators of the client and server networks, I don't think that's how things work most of the time. While the silicon beasts that run the network may not be able to negotiate the meaning of "cost", the carbon-based ones that are supposed to be in charge of it all are fully capable of doing so. At the very least there has to be an agreement to allow the LSP in the first place, and there's no reason why that agreement can't cover other things, such as what costs are going to mean or how they should be interpreted.

Granted, there will be times when this absolutely isn't the case, but I don't think the operators of client and server networks are always completely at arm's length. I think this is what Zafar meant when he said it was a policy matter.

It seems to me that the uselessness (or usefulness) of discovering the cost of a LSP over a server network is a decision best made by the network operators, rather than a decision that should be forced onto the network operator by us. I'm therefore in favour of leaving it in place so that it may be used by those who wish to.

Cheers

Matt

> Matt,
> 
> John's point is that the costs of a TE link in a client layer are not
> "something vague"  or something absolute as you imply, rather, something that
> can relate said TE link to other client layer TE links, and such costs have
> nothing to do with the costs of the server LSPs supporting them. Consider the
> following:
> The point is that the costs collected for, say,  LSP1 do not help in any way
> to define the costs of TE Link1 as compared to costs of TE link 0 or TE
> link2;
> 
> Cheers,
> Igor
> 
> somewhat vague thing that may mean different things to different network
> operators? This is true sometimes, but that doesn't mean it will always be
> the case. And I think concepts such as latency and latency variation are less
> prone to this problem; when we talk about "latency", I'm reasonably sure we
> all mean the same thing.
> 
> Certainly that might be a good idea... but it's beyond the scope of this
> draft. If you want to map the characteristics of a given LSP established
> across the server network into the TE metric to be advertised with that LSP
> in the client network, you first have to know what the characteristics of the
> LSP across the server network are... and that's what this draft is for; it's
> simply about the discovery of the information, not what you choose to do with
> it afterwards.
> 
> Cheers
> 
> Matt
> 
> >
> > Yours Irrespectively,
> >
> > John
> >
> >

---

From: "Matt Hartley (mhartley)" <[email-masked]>
Date: Fri, 9 Aug 2013 20:40:22 +0000

John,

I think most of your mail was covered by my reply to Igor's, but one thing that wasn't:

> JD:  I didn't say anything about latency, however, since you mention it, I
> think it would be far better for the clients to measure latency.

If you want a truly accurate measure of what the latency is right now, then yes. However, discovering the latency of the LSP you currently have (according to the server network) becomes much more useful once you also have other tools at your disposal. In particular, you can use the discovered latency to impose latency constraints on another LSP you may signal (as described in draft-ali-ccamp-rc-objective-function-metric-bound-03).

Cheers

Matt

---

From: John E Drake <[email-masked]>
Date: Fri, 9 Aug 2013 20:49:46 +0000

Yours Irrespectively,

John

> Sent: Friday, August 09, 2013 1:40 PM
> > JD:  I didn't say anything about latency, however, since you mention
> > it, I think it would be far better for the clients to measure latency.
> 
> If you want a truly accurate measure of what the latency is right now, then
> yes. 

JD:  Correct.

> However, discovering the latency of the LSP you currently have
> (according to the server network) becomes much more useful once you also
> have other tools at your disposal. In particular, you can use the discovered
> latency to impose latency constraints on another LSP you may signal (as
> described in draft-ali-ccamp-rc-objective-function-metric-bound-03).

JD:  You use the measured latency of one LSP to specify the desired latency 
for a subsequent LSP?  If that is what you are saying then you have just agreed
with my original point which was having the server network provide a culmulative
estimate of an LSP's latency in the server network is not nearly as useful as having
the client measure the latency of its LSP.

---

From: "Matt Hartley (mhartley)" <[email-masked]>
Date: Fri, 9 Aug 2013 20:58:08 +0000

John,

> > (according to the server network) becomes much more useful once you
> > also have other tools at your disposal. In particular, you can use the
> > discovered latency to impose latency constraints on another LSP you
> > may signal (as described in draft-ali-ccamp-rc-objective-function-metric-
> bound-03).
> 
> for a subsequent LSP?  

No. You'd use the collected latency on one LSP to specify the desired latency on a subsequent one (or to give you a good idea of what specified latency it might be reasonable to require).

I'm being somewhat pessimistic here and assuming that there may be discrepancies between the collected and measured latencies on the original LSP. Obviously we'd like to think there wouldn't be, but... :)

Cheers

Matt

> If that is what you are saying then you have just
> agreed with my original point which was having the server network provide a
> culmulative estimate of an LSP's latency in the server network is not nearly
> as useful as having the client measure the latency of its LSP.
> 
> >
> > Cheers
> >
> > Matt
> >
>

---

From: Igor Bryskin <[email-masked]>
Date: Fri, 9 Aug 2013 21:11:25 +0000

Martin,
We (John and myself) are of a school of thought that believes a client should know what to expect from an LSP it requests from a service provider *before* the setup request is issued (e.g. through a standard virtual link advertisement). Among other things this allows for the client all kinds of pre-planning.  What you and Zafar suggest is to request LSP, first, and analyze its properties later, using a set of obscure metrics understood only by the provider. It is not clear, what the client can do with these metrics because:
a) the client may not understand them;
b) the client may understand them through some other communication you mentioned (email?, twitter?) but don't like them. I mean, what the client is supposed to do in this case: try another LSP? Go to a different provider?

Cheers,
Igor

-----Original Message-----
From: Matt Hartley (mhartley) [mailto:[email-masked]] 
Sent: Friday, August 09, 2013 4:31 PM
To: Igor Bryskin; John E Drake; CCAMP ([email-masked])
Cc: Matt Hartley (mhartley)
Subject: RE: draft-ietf-ccamp-te-metric-recording-02

Igor, John,

Cheers

Matt

---

From: John E Drake <[email-masked]>
Date: Fri, 9 Aug 2013 21:18:05 +0000

Yours Irrespectively,

John

> Sent: Friday, August 09, 2013 1:31 PM
> It seems that we have a simple disagreement here about whether
> discovering the cost of a LSP over a server layer is any use at all. I don't agree
> that it's as completely useless as you assert.

JD:  I don't think it's an assertion.  There is a reason why the term 'Autonomous System'
Is used.  

> 
> While it would certainly be very hard to make much of it in the complete
> absence of other communication between the operators of the client and
> server networks, I don't think that's how things work most of the time. While
> the silicon beasts that run the network may not be able to negotiate the
> meaning of "cost", the carbon-based ones that are supposed to be in charge
> of it all are fully capable of doing so. At the very least there has to be an
> agreement to allow the LSP in the first place, and there's no reason why that
> agreement can't cover other things, such as what costs are going to mean or
> how they should be interpreted.

JD:  You seem to be implicitly agreeing that providing this information Is useless
unless there is an out of band mechanism that provides a context for it.   Given this,
it hardly seems worth the trouble to embed TE metric accumulation in the RSVP-TE
signaling, since the out of band mechanism can provide TE metrics itself.
  
> 
> Granted, there will be times when this absolutely isn't the case, but I don't
> think the operators of client and server networks are always completely at
> arm's length. I think this is what Zafar meant when he said it was a policy
> matter.

JD:  This is somewhere between speculation and assertion.

> 
> It seems to me that the uselessness (or usefulness) of discovering the cost of
> a LSP over a server network is a decision best made by the network
> operators, rather than a decision that should be forced onto the network
> operator by us. I'm therefore in favour of leaving it in place so that it may be
> used by those who wish to.

JD:  So, we are supposed to create all sorts of random protocol extensions in the
hope that someone somewhere someday will find a use for them?

I have seen far too many pointless additions to RSVP-TE signaling and we have to
start using some common sense.

---

From: Igor Bryskin <[email-masked]>
Date: Fri, 9 Aug 2013 21:27:46 +0000

Matt, 
I apologize for calling you by wrong name.

Igor

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Igor Bryskin
Sent: Friday, August 09, 2013 5:11 PM
To: Matt Hartley (mhartley); John E Drake; CCAMP ([email-masked])
Subject: Re: [CCAMP] draft-ietf-ccamp-te-metric-recording-02

Martin,

Cheers,
Igor

-----Original Message-----
From: Matt Hartley (mhartley) [mailto:[email-masked]] 
Sent: Friday, August 09, 2013 4:31 PM
To: Igor Bryskin; John E Drake; CCAMP ([email-masked])
Cc: Matt Hartley (mhartley)
Subject: RE: draft-ietf-ccamp-te-metric-recording-02

Igor, John,

Cheers

Matt

---

From: "Zafar Ali (zali)" <[email-masked]>
Date: Fri, 9 Aug 2013 21:46:06 +0000

-----Original Message-----
From: "[email-masked]" <[email-masked]>
Date: Friday, August 9, 2013 5:27 PM
To: "Matt Hartley (mhartley)" <[email-masked]>, "[email-masked]"
<[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [CCAMP] draft-ietf-ccamp-te-metric-recording-02

>We (John and myself) are of a school of thought that believes a client
>should know what to expect from an LSP it requests from a service
>provider *before* the setup request is issued (e.g. through a standard
>virtual link advertisement). Among other things this allows for the
>client all kinds of pre-planning.  What you and Zafar suggest is to
>request LSP, first, and analyze its properties later,

Igore- 

These are building blocks and you cannot conclude on a full solution by
cherry picking part of the overall solution. In another draft that we
discussed via the email
draft-ali-ccamp-rc-objective-function-metric-bound, we talk about client
requesting metric bound (e.g., latency bound). So yes, connection
requirements are driven by the clients.

Thanks

Regards Š Zafar

---

From: John E Drake <[email-masked]>
Date: Fri, 9 Aug 2013 21:55:10 +0000

Zafar,

'Overall solution' to what problem?  Don't we normally start with requirements drafts?

Yours Irrespectively,

John

> Sent: Friday, August 09, 2013 2:46 PM
> To: Igor Bryskin; Matt Hartley (mhartley); John E Drake; CCAMP
> ([email-masked])
> >From: [email-masked] [mailto:[email-masked]] On
> Behalf
> >Of Igor Bryskin
> These are building blocks and you cannot conclude on a full solution by cherry
> picking part of the overall solution. In another draft that we discussed via the
> email draft-ali-ccamp-rc-objective-function-metric-bound, we talk about
> client requesting metric bound (e.g., latency bound). So yes, connection