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

Gert Grammel <ggrammel@juniper.net> Fri, 09 August 2013 21:10 UTC

Return-Path: <ggrammel@juniper.net>
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 7EBCE21F9F80 for <ccamp@ietfa.amsl.com>; Fri, 9 Aug 2013 14:10:28 -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 P-A0Oyoq9VTr for <ccamp@ietfa.amsl.com>; Fri, 9 Aug 2013 14:10:23 -0700 (PDT)
Received: from db8outboundpool.messaging.microsoft.com (mail-db8lp0188.outbound.messaging.microsoft.com [213.199.154.188]) by ietfa.amsl.com (Postfix) with ESMTP id AE46C21E8063 for <ccamp@ietf.org>; Fri, 9 Aug 2013 14:02:05 -0700 (PDT)
Received: from mail115-db8-R.bigfish.com (10.174.8.242) by DB8EHSOBE035.bigfish.com (10.174.4.98) with Microsoft SMTP Server id 14.1.225.22; Fri, 9 Aug 2013 21:02:04 +0000
Received: from mail115-db8 (localhost [127.0.0.1]) by mail115-db8-R.bigfish.com (Postfix) with ESMTP id B07444016F; Fri, 9 Aug 2013 21:02:04 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT005.namprd05.prod.outlook.com; RD:none; EFVD:NLI
X-SpamScore: -22
X-BigFish: PS-22(zz9371I542Iec9I1432Izz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzc2hz1de098h1033IL1de096h8275bh8275dh1de097hz2fh2a8h668h839h944hd24hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1d07h1d0ch1d2eh1d3fh1dc1h1de9h1dfeh1dffh1e1dh1fe8h9a9j1155h)
Received-SPF: pass (mail115-db8: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=ggrammel@juniper.net; helo=BL2PRD0510HT005.namprd05.prod.outlook.com ; .outlook.com ;
X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(51704005)(189002)(13464003)(199002)(37854004)(377454003)(53806001)(69226001)(51856001)(47446002)(83072001)(74502001)(74662001)(74876001)(54356001)(77982001)(65816001)(46102001)(59766001)(81542001)(49866001)(80022001)(4396001)(47976001)(83322001)(50986001)(33646001)(76786001)(54316002)(76576001)(31966008)(81686001)(79102001)(1941001)(74316001)(19580395003)(16406001)(76796001)(74706001)(19580385001)(19580405001)(56776001)(74366001)(80976001)(63696002)(76482001)(66066001)(76176001)(77096001)(47736001)(56816003)(81342001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BN1PR05MB140; H:BN1PR05MB041.namprd05.prod.outlook.com; CLIP:178.239.82.32; RD:InfoNoRecords; MX:1; A:1; LANG:en;
Received: from mail115-db8 (localhost.localdomain [127.0.0.1]) by mail115-db8 (MessageSwitch) id 1376082122571967_29152; Fri, 9 Aug 2013 21:02:02 +0000 (UTC)
Received: from DB8EHSMHS025.bigfish.com (unknown [10.174.8.238]) by mail115-db8.bigfish.com (Postfix) with ESMTP id 7ADEA2C0048; Fri, 9 Aug 2013 21:02:02 +0000 (UTC)
Received: from BL2PRD0510HT005.namprd05.prod.outlook.com (157.56.240.101) by DB8EHSMHS025.bigfish.com (10.174.4.35) with Microsoft SMTP Server (TLS) id 14.16.227.3; Fri, 9 Aug 2013 21:02:02 +0000
Received: from BN1PR05MB140.namprd05.prod.outlook.com (10.255.205.23) by BL2PRD0510HT005.namprd05.prod.outlook.com (10.255.100.40) with Microsoft SMTP Server (TLS) id 14.16.341.1; Fri, 9 Aug 2013 21:02:00 +0000
Received: from BN1PR05MB041.namprd05.prod.outlook.com (10.255.202.140) by BN1PR05MB140.namprd05.prod.outlook.com (10.255.205.23) with Microsoft SMTP Server (TLS) id 15.0.731.16; Fri, 9 Aug 2013 21:01:58 +0000
Received: from BN1PR05MB041.namprd05.prod.outlook.com ([169.254.13.216]) by BN1PR05MB041.namprd05.prod.outlook.com ([169.254.13.216]) with mapi id 15.00.0731.000; Fri, 9 Aug 2013 21:01:58 +0000
From: Gert Grammel <ggrammel@juniper.net>
To: "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: AQHOlUOvEFcja1tdtE+PhbF+ss1Nwg==
Date: Fri, 9 Aug 2013 21:01:58 +0000
Message-ID: <87c8d290bc824645a5afd0082ece8663@BN1PR05MB041.namprd05.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [178.239.82.32]
x-forefront-prvs: 0933E9FD8D
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn%
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:10:28 -0000

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