Re: [CCAMP] draft-wright-ccamp-op-policy-prot-links

Hi Adrian, 

Thanks for your input. 

On point 1, this is likely to be controlled by carrier policy.  There are a couple of use cases for this. 

- Some carriers have policies which mean they are prepared to let some services traverse a link which is temporarily protection-impaired, with the assumption that the link will be repaired at some point.

- Carrier policy can choose to place some services (for which no protection is required) over a protection-impaired link but avoid using that link for other less-valuable services.  This prevents less valuable services using resources on links which, if repaired, could be used to carry protected traffic.  

Are these the sort of deployment example you were thinking of?  I can add these details to the I-D if that helps? 

On point 2, thanks for pointing me at RFC4783.  I think that solves the issue - the node detecting a failure could use error value protectionPathFailure (60) to signal the fault and clear that when the fault condition clears.  You are correct that we could also run end-to-end OAM on the LSP, but that was not necessarily going to be available for some of the cases I was considering.    

Cheers, 

Ben

-----Original Message-----
From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of Adrian Farrel
Sent: 06 July 2013 23:42
To: draft-wright-ccamp-op-policy-prot-links@tools.ietf.org
Cc: ccamp@ietf.org
Subject: [CCAMP] draft-wright-ccamp-op-policy-prot-links

Hi,

As I read this I-D, you are saying two things.

1. You want a way to advertise in an IGP that a link is supposed to have some level of inherent protection, but that that protection is not currently present.
This is, of course, easy to achieve, but not easy to understand or use. How will the path computing system understand the estimated repair time for the impaired protection? When a path is computed that wants some level of protection, it is possible that "allow impaired protection" is a computation constraint, but it would seem to be nonsense if the repair time is going to be long.

Maybe you could add some flesh to the I-D in terms of a deployment example.

2. You want a way to notify the head end of an LSP that there has been a degradation of the LSP, and a way to let it know that things are back to normal.
Have you considered:
a. running OAM on your LSP
b. using RFC 4783

Ciao,
Adrian

_______________________________________________
CCAMP mailing list
CCAMP@ietf.org
https://www.ietf.org/mailman/listinfo/ccamp