Subject: [CCAMP] Clarification on RFC4202

From: Ben Wright <[email-masked]>
Date: Fri, 22 Feb 2013 10:24:34 +0000

Hi,

I have a question on the text in RFC4202.

A 1+1 protected link may be configured between two nodes, but 1+1 protection may be temporarily unavailable (e.g. because of a failure on one of the constituent lower-layer links which provide the 1+1 protection).   In this case, should implementations advertised the link as having the currently supported link protection type (i.e. unprotected) or the intended / configured link protection type (1+1 protected)?

http://tools.ietf.org/html/rfc4202#section-2.2 describes the Link Protection Type as "the protection capability that exists for a link".    My reading is that this means the currently supported protection type should be advertised (i.e. unprotected in the case above) not the intended / configured link protection type.   Do you agree?

Thanks,

Ben

---

From: Igor Bryskin <[email-masked]>
Date: Fri, 22 Feb 2013 13:56:22 +0000

Ben,
I agree. Link should advertise its protection capability as available at the moment.

Cheers,
Igor

From: [email-masked] [mailto:[email-masked]] On Behalf Of Ben Wright
Sent: Friday, February 22, 2013 5:25 AM
To: Ccamp
Subject: [CCAMP] Clarification on RFC4202

Hi,

Thanks,

Ben

---

From: John E Drake <[email-masked]>
Date: Fri, 22 Feb 2013 14:24:12 +0000

Ben,

I think I wrote that section and that was definitely the intent.

Irrespectively Yours,

John

From: [email-masked] [mailto:[email-masked]] On Behalf Of Igor Bryskin
Sent: Friday, February 22, 2013 5:56 AM
To: Ben Wright; Ccamp
Subject: Re: [CCAMP] Clarification on RFC4202

Ben,

Cheers,
Igor

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Ben Wright
Sent: Friday, February 22, 2013 5:25 AM
To: Ccamp
Subject: [CCAMP] Clarification on RFC4202

Hi,

Thanks,

Ben

---

From: "BRUNGARD, DEBORAH A" <[email-masked]>
Date: Thu, 28 Feb 2013 16:21:56 +0000

Hi Ben,

(speaking with co-chair hat off/operator hat on)

I wasn't sure of the context of your question when you say 1+1 is not available. 1+1 is a bit different from the other protection schemes. As in 4202, even the protection link bandwidth is not advertised as the signal is bridged - it is dedicated protection. It's not "intended", it's configured.

Is the context, the operator has provisioned a link as 1+1, the link is operating as 1+1, one side is down, and the link is now using the protection link? Your question is how to advertise when the link is still operating as 1+1 protection? Why would you consider it as protection is "not available" when it is still in the 1+1 state? Or did you mean that the operator because of the failure  has changed the provisioning state (e.g. the failure has become more than a temporary event)? As John and Igor say, what is advertised is what is the current protection state e.g. for this example, if it is working as 1+1 then 1+1 is advertised.

If you want to advertise it as not protected when it is still operating as 1+1 protection and so prevent LSP set up over it, then this should be based on an operator's policy for such treatment. Are you also going to re-route the LSPs using the 1+1 link?

Thanks,
Deborah

From: [email-masked] [mailto:[email-masked]] On Behalf Of John E Drake
Sent: Friday, February 22, 2013 9:24 AM
To: Igor Bryskin; Ben Wright; Ccamp
Subject: Re: [CCAMP] Clarification on RFC4202

Ben,

Irrespectively Yours,

John

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Igor Bryskin
Sent: Friday, February 22, 2013 5:56 AM
To: Ben Wright; Ccamp
Subject: Re: [CCAMP] Clarification on RFC4202

Ben,

Cheers,
Igor

Hi,

Thanks,

Ben