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

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:mhartley@cisco.com] 
Sent: Friday, August 09, 2013 4:31 PM
To: Igor Bryskin; John E Drake; CCAMP (ccamp@ietf.org)
Cc: Matt Hartley (mhartley)
Subject: RE: draft-ietf-ccamp-te-metric-recording-02

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:
> 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: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of
> Matt Hartley (mhartley)
> Sent: Friday, August 09, 2013 11:07 AM
> To: John E Drake; CCAMP (ccamp@ietf.org)
> Subject: Re: [CCAMP] draft-ietf-ccamp-te-metric-recording-02
> 
> 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
> 
> >
> > Yours Irrespectively,
> >
> > John
> >
> >
> > _______________________________________________
> > CCAMP mailing list
> > CCAMP@ietf.org
> > https://www.ietf.org/mailman/listinfo/ccamp
> _______________________________________________
> CCAMP mailing list
> CCAMP@ietf.org
> https://www.ietf.org/mailman/listinfo/ccamp