From: "Matt Hartley (mhartley)" <mhartley@cisco.com>
To: Igor Bryskin <IBryskin@advaoptical.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+nwAmJqLQAAIuwnAACK27oA==
Date: Fri, 9 Aug 2013 20:30:59 +0000
Message-ID: <9D50FCE7413E3D4EA5E42331115FB5BC105AF282@xmb-rcd-x03.cisco.com>
References: <fef00ba6c7f24978ad08fb60ee929a79@BY2PR05MB142.namprd05.prod.outlook.com>
 <9D50FCE7413E3D4EA5E42331115FB5BC105AD55C@xmb-rcd-x03.cisco.com>
 <CDAC6F6F5401B245A2C68D0CF8AFDF0A1929580B@atl-srv-mail10.atl.advaoptical.com>
In-Reply-To: <CDAC6F6F5401B245A2C68D0CF8AFDF0A1929580B@atl-srv-mail10.atl.advaoptical.com>
Accept-Language: en-US
Content-Language: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [CCAMP] draft-ietf-ccamp-te-metric-recording-02
Precedence: list

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 ab=
sence 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 meani=
ng 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 ag=
reement 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 o=
r 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 pol=
icy 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 oper=
ators, rather than a decision that should be forced onto the network operat=
or 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,
>=20
> 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 ha=
ve
> 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 doma=
in
> 1;
> c) client layer TE link  2 supported by a server layer LSP2 in server dom=
ain
> 2
>=20
> 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;
>=20
> Cheers,
> Igor
>=20
> -----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
>=20
> John,
>=20
> The point you raise is a good one, but I don't think it has much to do wi=
th
> this draft.
>=20
> > 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 cl=
ient
> network.
>=20
> 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 b=
e
> 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.
>=20
> > 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?
>=20
> 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 L=
SP
> 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; i=
t's
> simply about the discovery of the information, not what you choose to do =
with
> it afterwards.
>=20
> Cheers
>=20
> Matt
>=20
> >
> > 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