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

From: "Adrian Farrel" <[email-masked]>
Date: Sat, 6 Jul 2013 23:41:55 +0100

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

---

From: Ben Wright <[email-masked]>
Date: Wed, 10 Jul 2013 08:18:07 +0000

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: [email-masked] [mailto:[email-masked]] On Behalf Of Adrian Farrel
Sent: 06 July 2013 23:42
To: [email-masked]
Cc: [email-masked]
Subject: [CCAMP] draft-wright-ccamp-op-policy-prot-links

Hi,

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.

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
[email-masked]
https://www.ietf.org/mailman/listinfo/ccamp

---

From: Julien Meuric <[email-masked]>
Date: Wed, 10 Jul 2013 17:40:49 +0200

Hi Ben.

Please see below.

On 07/10/2013 10:18, Ben Wright wrote:

[...]
> - 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…
I agree 100 %. The key-word here is *temporarily*. On the opposite 
TE-LSPs are typically provisioned for rather long times. As a result, I 
do not believe that adding a supplementary short-life link-protection 
state (i.e. "protection-impaired") would bring actual value to initial 
path computation. It is a matter of time scale.
When it comes to traffic re-routing triggered by a failure, traffic 
recovery matters above all and an available link should typically be 
considered, whatever transient state a protected link may be facing.
> - 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 l…
I guess you meant "for which protection is required". The situation is 
not supposed to last for long. Should provisioning happen over a 
degraded network anyway and chose that link, constrained routing remains 
a proactive way to addresses the issue, re-routing (only once!) is a 
reactive one.

I have also read the I-D and especially the "operator requirements" section:
- R1 brings me back to my comment above: I do not feel comfortable in 
constraining path computation by temporary situations that do no affect 
traffic.
- R2 looks really odd to me: except for planed maintenance, I fail to 
see why someone would want to temporarily re-route a perfectly flowing 
traffic, which means accept the traffic impact (twice, even if sub-50 
ms...) and the risk that the new path is not better than the former. 
What prevails on operational networks is typically: "do no touch 
something working properly".

Regards,

Julien

---

From: Ben Wright <[email-masked]>
Date: Fri, 12 Jul 2013 08:28:29 +0000

Hi Julien,

Thanks for your comments.  Your point of view is, of course, completely valid.

Let me try to rephrase the use case for R1.  I've received input from some carriers who see a need for a policy which means that they are *not* prepared to let certain services traverse a protection-impaired link, no matter how temporary the impairment is likely to be.  Path computation would therefore need to take the impairment status of each link into account for those services only.

On R2, the required policy is that there are certain services that must not be at risk from being taken out by a second failure on a protection-impaired link, even though that means re-routing the traffic when a failure occurs.  You are correct that traffic would not normally be re-routed from a working connection, but my understanding is that these services are very much a special case.

I'm interested in whether these requirements are of wider interest, so thanks for your feedback.

Regards,

Ben

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Julien Meuric
Sent: 10 July 2013 16:41
To: [email-masked]
Subject: Re: [CCAMP] draft-wright-ccamp-op-policy-prot-links

Hi Ben.

Please see below.

[...]
> - 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…
I agree 100 %. The key-word here is *temporarily*. On the opposite TE-LSPs are typically provisioned for rather long times. As a result, I do not believe that adding a supplementary short-life link-protection state (i.e. "protection-impaired") would bring actual value to initial path computation. It is a matter of time scale.
When it comes to traffic re-routing triggered by a failure, traffic recovery matters above all and an available link should typically be considered, whatever transient state a protected link may be facing.
> - 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 l…
I guess you meant "for which protection is required". The situation is not supposed to last for long. Should provisioning happen over a degraded network anyway and chose that link, constrained routing remains a proactive way to addresses the issue, re-routing (only once!) is a reactive one.

I have also read the I-D and especially the "operator requirements" section:
- R1 brings me back to my comment above: I do not feel comfortable in constraining path computation by temporary situations that do no affect traffic.
- R2 looks really odd to me: except for planed maintenance, I fail to see why someone would want to temporarily re-route a perfectly flowing traffic, which means accept the traffic impact (twice, even if sub-50
ms...) and the risk that the new path is not better than the former. 
What prevails on operational networks is typically: "do no touch something working properly".

Regards,

Julien