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

Yours Irrespectively,

John

> -----Original Message-----
> From: Matt Hartley (mhartley) [mailto:mhartley@cisco.com]
> Sent: Friday, August 09, 2013 8:07 AM
> To: John E Drake; CCAMP (ccamp@ietf.org)
> Cc: Matt Hartley (mhartley)
> Subject: RE: 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.

JD:  This draft is proposing that the cumulative TE metric associated with the establishment of an LSP in the server network be passed to the client LSP endpoints.  My point is that this is probably useless at best.

> 
> > 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.

JD:  You have no way of knowing whether there is any congruence between the TE metrics in the server network and the TE metrics in a client network.

> 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.

JD:  I didn't say anything about latency, however, since you mention it, I think it would be far better for the clients to measure latency.

> 
> > 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.

JD:  I think you are missing my point.  The accumulated TE metric for an LSP in the server network is not a characteristic that is of any use to the client, so what I am proposing is that it be removed from the draft. 

> 
> Cheers
> 
> Matt
> 
> >
> > Yours Irrespectively,
> >
> > John
> >
> >
> > _______________________________________________
> > CCAMP mailing list
> > CCAMP@ietf.org
> > https://www.ietf.org/mailman/listinfo/ccamp
> 