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

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

Return-Path: <zali@cisco.com>
X-Original-To: ccamp@ietfa.amsl.com
Delivered-To: ccamp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0ECE21F9D28 for <ccamp@ietfa.amsl.com>; Fri, 9 Aug 2013 14:27:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.096
X-Spam-Level:
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 mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jR5Bux-+heE5 for <ccamp@ietfa.amsl.com>; Fri, 9 Aug 2013 14:27:37 -0700 (PDT)
Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id EC1F811E81E3 for <ccamp@ietf.org>; Fri, 9 Aug 2013 14:18:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; 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-Anti-Spam-Result: AgcFAN9bBVKtJV2a/2dsb2JhbABbgwY1UL5ZgRwWdIIkAQEBBAEBAWsXBgEIDgMDAQEBCx0uCxQJCAIEARIIiAgMuF0EkAEGMgIEgxR1A6kxgxuCKg
X-IronPort-AV: E=Sophos;i="4.89,848,1367971200"; d="scan'208";a="245648817"
Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-6.cisco.com with ESMTP; 09 Aug 2013 21:18:22 +0000
Received: from xhc-aln-x05.cisco.com (xhc-aln-x05.cisco.com [173.36.12.79]) by rcdn-core-3.cisco.com (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 xmb-rcd-x14.cisco.com ([169.254.4.213]) by xhc-aln-x05.cisco.com ([173.36.12.79]) with mapi id 14.02.0318.004; Fri, 9 Aug 2013 16:18:21 -0500
From: "Zafar Ali (zali)" <zali@cisco.com>
To: Gert Grammel <ggrammel@juniper.net>, "Matt Hartley (mhartley)" <mhartley@cisco.com>, Igor Bryskin <IBryskin@advaoptical.com>, John E Drake <jdrake@juniper.net>, "CCAMP (ccamp@ietf.org)" <ccamp@ietf.org>
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: <B6585D85A128FD47857D0FD58D8120D30EA023B8@xmb-rcd-x14.cisco.com>
In-Reply-To: <87c8d290bc824645a5afd0082ece8663@BN1PR05MB041.namprd05.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.2.3.120616
x-originating-ip: [10.82.219.206]
Content-Type: text/plain; charset="Windows-1252"
Content-ID: <C488924C12832049B78A8F156F610719@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [CCAMP] draft-ietf-ccamp-te-metric-recording-02
X-BeenThere: ccamp@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussion list for the CCAMP working group <ccamp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ccamp>, <mailto:ccamp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ccamp>
List-Post: <mailto:ccamp@ietf.org>
List-Help: <mailto:ccamp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ccamp>, <mailto:ccamp-request@ietf.org?subject=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.

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>om>,
"IBryskin@advaoptical.com" <IBryskin@advaoptical.com>om>,
"jdrake@juniper.net" <jdrake@juniper.net>et>, "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