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

Igor Bryskin <IBryskin@advaoptical.com> Fri, 09 August 2013 16:21 UTC

Return-Path: <IBryskin@advaoptical.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 AF28021F9F86 for <ccamp@ietfa.amsl.com>; Fri, 9 Aug 2013 09:21:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
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 lpkKBuh+GCkZ for <ccamp@ietfa.amsl.com>; Fri, 9 Aug 2013 09:21:38 -0700 (PDT)
Received: from mail3.advaoptical.com (mail3.advaoptical.com [74.202.24.82]) by ietfa.amsl.com (Postfix) with ESMTP id E212521F9CDF for <ccamp@ietf.org>; Fri, 9 Aug 2013 09:14:19 -0700 (PDT)
Received: from atl-srv-mail10.atl.advaoptical.com (atl-srv-mail10.atl.advaoptical.com [172.16.5.39]) by atl-vs-fsmail.advaoptical.com (8.14.5/8.14.5) with ESMTP id r79GEH8v027642 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 9 Aug 2013 12:14:17 -0400
Received: from ATL-SRV-MAIL10.atl.advaoptical.com ([fe80::c4d6:b136:bc16:77ae]) by atl-srv-mail10.atl.advaoptical.com ([fe80::c4d6:b136:bc16:77ae%17]) with mapi id 14.03.0146.000; Fri, 9 Aug 2013 12:14:17 -0400
From: Igor Bryskin <IBryskin@advaoptical.com>
To: "Matt Hartley (mhartley)" <mhartley@cisco.com>, John E Drake <jdrake@juniper.net>, "CCAMP (ccamp@ietf.org)" <ccamp@ietf.org>
Thread-Topic: draft-ietf-ccamp-te-metric-recording-02
Thread-Index: Ac6UeCOcyiZvNP7VTj6v1XoohGG+nwAmJqLQAAIuwnA=
Date: Fri, 09 Aug 2013 16:14:17 +0000
Message-ID: <CDAC6F6F5401B245A2C68D0CF8AFDF0A1929580B@atl-srv-mail10.atl.advaoptical.com>
References: <fef00ba6c7f24978ad08fb60ee929a79@BY2PR05MB142.namprd05.prod.outlook.com> <9D50FCE7413E3D4EA5E42331115FB5BC105AD55C@xmb-rcd-x03.cisco.com>
In-Reply-To: <9D50FCE7413E3D4EA5E42331115FB5BC105AD55C@xmb-rcd-x03.cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [174.46.146.58]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.10.8794, 1.0.431, 0.0.0000 definitions=2013-08-09_07:2013-08-09, 2013-08-09, 1970-01-01 signatures=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 16:21:43 -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: 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