Subject: Re: [CCAMP] Clarification on RFC4202

From: Ben Wright <[email-masked]>
Date: Mon, 4 Mar 2013 14:20:35 +0000

Hi Deborah, John, Igor,

Thanks for your responses - apologies for my delay in getting back.

To answer Deborah's questions:

- In the example I gave, I intended that the advertised link was configured as 1+1, but there has been a failure on one of its underlying links such that the protection link is in use.   In this case, the link is configured as a 1+1 protected link, is still able to carry the maximum LSP bandwidth which was previously advertised, but a single failure of the protection link may now cause the advertised link to be unable to carry traffic.   In that case, do you think the Link Protection Type on the advertised link should be set to '1+1' or 'unprotected'?

- Based on feedback I've had, I believe operator policy may wish to prevent (at least some) new LSPs from being set up over a configured 1+1 link which currently has a failure as described above.   Independently, they may want to reroute existing LSPs to use different "fully operational" 1+1 links if available, but the requirement for that is not as clear-cut.

I hope that makes sense.

Thanks,

Ben

From: BRUNGARD, DEBORAH A [mailto:[email-masked]]
Sent: 28 February 2013 16:22
To: Ben Wright; Ccamp
Subject: RE: Clarification on RFC4202

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]> [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,

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

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,
I agree. Link should advertise its protection capability as available at the moment.

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,

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: "BRUNGARD, DEBORAH A" <[email-masked]>
Date: Wed, 6 Mar 2013 19:16:18 +0000

Hi Ben,

(operator hat on/co-chair hat off)

Again, I think it will depend on an operator's policy. Even for the same operator, their answer may differ depending on the application.

Some examples. It depends on the location of the 1+1 link and if there are alternative network paths. There are other setup parameters to consider e.g. latency. And if one advertises it as "unprotected", one may attract "unprotected" traffic using up capacity on a premium 1+1 LSP. Maybe that's ok, maybe not. There's nothing precluding different operations.

And the 1+1 is still operational. If the 1+1 fails (both sides), there will be a failure indication to the head end node and it can decide to reroute (based on policy). I am wondering if you are confusing this with pre-planned mesh? For mesh, the operator has even more choices on how to operate (based on policy) - hopefully:)

Deborah

From: Ben Wright [mailto:[email-masked]]
Sent: Monday, March 04, 2013 9:21 AM
To: BRUNGARD, DEBORAH A; Ccamp
Cc: John E Drake; Igor Bryskin
Subject: RE: Clarification on RFC4202

Hi Deborah, John, Igor,

I hope that makes sense.

Thanks,

Ben

Hi Ben,

Thanks,
Deborah

Ben,

Irrespectively Yours,

John

Ben,

Cheers,
Igor

Hi,

Thanks,

Ben

---

From: Ben Wright <[email-masked]>
Date: Thu, 7 Mar 2013 13:35:55 +0000

Hi Deborah,

Thanks.   I'd assumed most of the operator policy would be configured on the element performing path computation, rather than the elements advertising the link in the first place.

One thought: it feels to me that there may be value in extending routing to allow NEs advertise the configured protection information for a link as well as the current protection information.   That way

- we give enough information to the element performing Path Computation to allow it to make a full decision and therefore implement more intelligent path computation decisions (for example, they might want some high-priority unprotected LSPs routed over the 1+1 link with a failure, but lower priority unprotected LSPs to avoid it OR they might want a high-priority / value LSP to only be placed over 1+1 links which have both underlying links fully operational)

- policy can be concentrated on the elements performing Path Computation (e.g in a PCE, rather than on individual Network Elements) if desired - although there is nothing to stop operators having their own policy on the NEs to allow them to control how links are presented to routing for use by Path Computation.

What do you think?

Ben

From: BRUNGARD, DEBORAH A [mailto:[email-masked]]
Sent: 06 March 2013 19:16
To: Ben Wright; Ccamp
Subject: RE: Clarification on RFC4202

Hi Ben,

Deborah

Hi Deborah, John, Igor,

I hope that makes sense.

Thanks,

Ben

Hi Ben,

Thanks,
Deborah

Ben,

Irrespectively Yours,

John

Ben,

Cheers,
Igor

Hi,

Thanks,

Ben

---

From: "BRUNGARD, DEBORAH A" <[email-masked]>
Date: Thu, 7 Mar 2013 15:21:39 +0000

Ben,

You have many different items here. Best is to do a requirements draft (before a solution:)) so ccamp can discuss.
Thanks,
Deborah

From: Ben Wright [mailto:[email-masked]]
Sent: Thursday, March 07, 2013 8:36 AM
To: BRUNGARD, DEBORAH A; Ccamp
Subject: RE: Clarification on RFC4202

Hi Deborah,

What do you think?

Ben

Hi Ben,

Deborah

Hi Deborah, John, Igor,

I hope that makes sense.

Thanks,

Ben

Hi Ben,

Thanks,
Deborah

Ben,

Irrespectively Yours,

John

Ben,

Cheers,
Igor

Hi,

Thanks,

Ben

---

From: John E Drake <[email-masked]>
Date: Thu, 7 Mar 2013 14:01:39 +0000

Gilding the Lilly

Irrespectively Yours,

John

From: [email-masked] [mailto:[email-masked]] On Behalf Of Ben Wright
Sent: Thursday, March 07, 2013 5:36 AM
To: BRUNGARD, DEBORAH A; Ccamp
Subject: Re: [CCAMP] Clarification on RFC4202

Hi Deborah,

What do you think?

Ben

Hi Ben,

Deborah

Hi Deborah, John, Igor,

I hope that makes sense.

Thanks,

Ben

Hi Ben,

Thanks,
Deborah

Ben,

Irrespectively Yours,

John

Ben,

Cheers,
Igor

Hi,

Thanks,

Ben

---

From: Fatai Zhang <[email-masked]>
Date: Fri, 8 Mar 2013 03:08:03 +0000

John,

For me, it is really interesting to see your mails to learn some useful English, :-)

Sorry for chiming in without technical points from me.

Thanks

Fatai

________________________________

发件人: [email-masked] [[email-masked]] 代表 John E Drake [[email-masked]]
发送时间: 2013年3月7日 22:01
到: Ben Wright; BRUNGARD, DEBORAH A; Ccamp
主题: Re: [CCAMP] Clarification on RFC4202

Gilding the Lilly

Irrespectively Yours,

John

Hi Deborah,

Thanks.   I’d assumed most of the operator policy would be configured on the element performing path computation, rather than the elements advertising the link in the first place.

- policy can be concentrated on the elements performing Path Computation (e.g in a PCE, rather than on individual Network Elements) if desired – although there is nothing to stop operators having their own policy on the NEs to allow them to control how links are presented to routing for use by Path Computation.

What do you think?

Ben

Hi Ben,

Again, I think it will depend on an operator’s policy. Even for the same operator, their answer may differ depending on the application.

Some examples. It depends on the location of the 1+1 link and if there are alternative network paths. There are other setup parameters to consider e.g. latency. And if one advertises it as “unprotected”, one may attract “unprotected” traffic using up capacity on a premium 1+1 LSP. Maybe that’s ok, maybe not. There’s nothing precluding different operations.

And the 1+1 is still operational. If the 1+1 fails (both sides), there will be a failure indication to the head end node and it can decide to reroute (based on policy). I am wondering if you are confusing this with pre-planned mesh? For mesh, the operator has even more choices on how to operate (based on policy) – hopefully:)

Deborah

Hi Deborah, John, Igor,

Thanks for your responses – apologies for my delay in getting back.

To answer Deborah’s questions:

- In the example I gave, I intended that the advertised link was configured as 1+1, but there has been a failure on one of its underlying links such that the protection link is in use.   In this case, the link is configured as a 1+1 protected link, is still able to carry the maximum LSP bandwidth which was previously advertised, but a single failure of the protection link may now cause the advertised link to be unable to carry traffic.   In that case, do you think the Link Protection Type on the advertised link should be set to ‘1+1’ or ‘unprotected’?

- Based on feedback I’ve had, I believe operator policy may wish to prevent (at least some) new LSPs from being set up over a configured 1+1 link which currently has a failure as described above.   Independently, they may want to reroute existing LSPs to use different “fully operational” 1+1 links if available, but the requirement for that is not as clear-cut.

I hope that makes sense.

Thanks,

Ben

Hi Ben,

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

Ben,

Irrespectively Yours,

John

Ben,

Cheers,
Igor

Hi,

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: John E Drake <[email-masked]>
Date: Fri, 8 Mar 2013 11:50:09 +0000

You’re welcome.

Irrespectively Yours,

John

From: Fatai Zhang [mailto:[email-masked]]
Sent: Thursday, March 07, 2013 7:08 PM
To: John E Drake; Ben Wright; BRUNGARD, DEBORAH A; Ccamp
Subject: 答复: Clarification on RFC4202

John,

Thanks

Fatai

________________________________
发件人: [email-masked]<mailto:[email-masked]> [[email-masked]] 代表 John E Drake [[email-masked]]
发送时间: 2013年3月7日 22:01
到: Ben Wright; BRUNGARD, DEBORAH A; Ccamp
主题: Re: [CCAMP] Clarification on RFC4202
Gilding the Lilly

Irrespectively Yours,

John

Hi Deborah,

What do you think?

Ben

Hi Ben,

Deborah

Hi Deborah, John, Igor,

I hope that makes sense.

Thanks,

Ben

Hi Ben,

Thanks,
Deborah

Ben,

Irrespectively Yours,

John

Ben,

Cheers,
Igor

Hi,

Thanks,

Ben