Subject: Re: [mpls-tp] -03 of requirements draft & actions still to beresolved

From: "Eric Gray" <[email-masked]>
Date: Mon, 26 Jan 2009 16:05:10 -0600

VVVVVVV[CHOP]VVVVVVV

Neil (1st time) =>
(iv)  I know it is not always under the control of one party to specify
      both the network mode/technology and the routing congruency of
      lower layer networks, but I still think there should be some form
      of 'health warning' on the performance inheritance and failure/
      availability impact of this...along the lines of the Note I gave.

Eric >> I'm not sure what this means.

NH=> It is simply 2 factors:

VVVVVVV[CHOP]VVVVVVV

So, by "health warning", you mean that you have to be very careful in
negotiating inter-carrier SLAs to ensure that you get something very
like what you expect from the "links" another carrier provides.  If
you want the indepedence you've previously been able to assume, you 
have to spell it out.

Right?
_______________________________________________
mpls-tp mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mpls-tp

---

From: <[email-masked]>
Date: Tue, 27 Jan 2009 00:02:40 -0000

> So, by "health warning", you mean that you have to be very 
> careful in negotiating inter-carrier SLAs to ensure that you 
> get something very like what you expect from the "links" 
> another carrier provides.  If you want the indepedence you've 
> previously been able to assume, you have to spell it out.
> 
> Right?
Not really.  Spelling it out as an SLA will not change the physics of
the network mode that is in place.....what it might do is result in an
uneconomic design/operating model to ensure that SLAs can be met with
overkill OAM and performance measurements 'just to be sure' it's always
OK.  This should not be necessary in a properly designed transport
network.

But to be fair and clear, the point I was alluding to is not specific to
MPLS-TP....it arises for all client/server 'network builder' transport
cases.

regards, Neil