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

"Zafar Ali (zali)" <> Fri, 09 August 2013 21:27 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B0ECE21F9D28 for <>; Fri, 9 Aug 2013 14:27:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -10.096
X-Spam-Status: No, score=-10.096 tagged_above=-999 required=5 tests=[AWL=0.503, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id jR5Bux-+heE5 for <>; Fri, 9 Aug 2013 14:27:37 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id EC1F811E81E3 for <>; Fri, 9 Aug 2013 14:18:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=6094; q=dns/txt; s=iport; t=1376083103; x=1377292703; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=61RmkJhrnqOItTu+u3pxgb0oaN+kgWsO3MeME4bWqtw=; b=GCgtUSPo9pmF0lUudRHlRr8aAXCARf3+cbpvhCcKtXwLtrUYlS8wADl2 gtsjYudhMvXXSCp++0mSS0s9g8G2fbeeUiYbzrbcSWDi1cfGexyUkGXCp lEzrGrUiWHdVzMCSs95iU3fHF89jkfUvg/7K+mezYnoAPdsK2smyW6da1 s=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="4.89,848,1367971200"; d="scan'208";a="245648817"
Received: from ([]) by with ESMTP; 09 Aug 2013 21:18:22 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id r79LIMv3021891 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 9 Aug 2013 21:18:22 GMT
Received: from ([]) by ([]) with mapi id 14.02.0318.004; Fri, 9 Aug 2013 16:18:21 -0500
From: "Zafar Ali (zali)" <>
To: Gert Grammel <>, "Matt Hartley (mhartley)" <>, Igor Bryskin <>, John E Drake <>, "CCAMP (" <>
Thread-Topic: [CCAMP] draft-ietf-ccamp-te-metric-recording-02
Thread-Index: AQHOlUOvyiZvNP7VTj6v1XoohGG+n5mNcikA
Date: Fri, 9 Aug 2013 21:18:20 +0000
Message-ID: <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
user-agent: Microsoft-MacOutlook/
x-originating-ip: []
Content-Type: text/plain; charset="Windows-1252"
Content-ID: <>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [CCAMP] draft-ietf-ccamp-te-metric-recording-02
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussion list for the CCAMP working group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 09 Aug 2013 21:28:16 -0000

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.


Regards Š Zafar

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

>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.
>From: <> on behalf of Matt
>Hartley (mhartley) <>
>Sent: Friday, August 09, 2013 10:30:59 PM
>To: Igor Bryskin; John E Drake; CCAMP (
>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.
>> 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
>> 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
>> 1;
>> c) client layer TE link  2 supported by a server layer LSP2 in server
>> 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: [] On Behalf
>> Matt Hartley (mhartley)
>> Sent: Friday, August 09, 2013 11:07 AM
>> To: John E Drake; CCAMP (
>> 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
>> 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
>> 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
>> 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
>> 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
>> 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;
>> 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 mailing list
>CCAMP mailing list
>CCAMP mailing list