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

Hi Gert- 

Let's not confuse/ mix inquiry with recording.

The question raised here is related to "Cost recording" - for which author
can take an AI and come back.

Thanks

Regards Š Zafar

-----Original Message-----
From: Gert Grammel <ggrammel@juniper.net>
Date: Friday, August 9, 2013 5:01 PM
To: "Matt Hartley (mhartley)" <mhartley@cisco.com>,
"IBryskin@advaoptical.com" <IBryskin@advaoptical.com>,
"jdrake@juniper.net" <jdrake@juniper.net>, "ccamp@ietf.org"
<ccamp@ietf.org>
Subject: Re: [CCAMP] draft-ietf-ccamp-te-metric-recording-02

>Matt,
>
>Let's not forget that the thread started with the question if poking with
>RSVP to understand server layer TE attributes is wise to do.
>Now the discussion becomes whether TE information is necessary at all.
>That doesn't reflect the concerns.
>
>Rather than jumping on a protocol to add a few hacks, it would be better
>to define the problem space and analyze the options.
>
>-Gert
>
>
>
>________________________________________
>From: ccamp-bounces@ietf.org <ccamp-bounces@ietf.org> on behalf of Matt
>Hartley (mhartley) <mhartley@cisco.com>
>Sent: Friday, August 09, 2013 10:30:59 PM
>To: Igor Bryskin; John E Drake; CCAMP (ccamp@ietf.org)
>Subject: Re: [CCAMP] 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
>_______________________________________________
>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