Subject: [Pce] Comment on WSON Requirements

From: <[email-masked]>
Date: Thu, 2 Apr 2009 11:07:51 +0200

Hi Young.

This is a try to resume our discussion started during the SF meeting. Indeed, I still don't get the rationale behind adding the BER as a requirement for PCEP request.

First, I wonder what your intend is when requesting a BER threshold at computation time while you can't really know it before LSP provisioning. Obviously, what we look for is a low BER, but the way I see using BER in routing would be to request a 2nd route *after* a poor BER measurement on a firstly established LSP.
Then, considering what you called a "BER estimation", I don't clearly see how you intend to estimate (or model?) it. The BER associated to an LSP is highly dependent on so many parameters: link DGD at measurement time, performance of the FEC used for the to-be-provisioned LSP , possible cross-talk and thus impact of potential adjacent channels... Furthermore, I don't really understand why focusing on the measurable BER range while a typical PMD (in)accuracy may just move us between an acceptable route and an unacceptable one, the latter being the very 1st problem we should try to solve.
Finally, I don't get the use of such feature. Even if we could, why would I request a 10^(-6) maximum BER? I don't see any room for anything else than "the best one", so do we really need something else? I tend to see BER as a varying quality feed*back*, not as an indicator that we can accurately target at routing time.

I completely agree that PCEP must support optical requirements, but my concern is to understand actual needs before loading the protocol. Therefore, I look forward to reading some clarification on those issues.

Best regards,

Julien

---

From: Young Lee <[email-masked]>
Date: Thu, 02 Apr 2009 13:43:37 -0500

Hi Julien,

The reason why we put the BER threshold in the PCEP request is to
"approximate" if the optical path in consideration would be "healthy" enough
from the BER perspective. Please note that we have defined two different
computation types of IA-PCE functions in the IA-WSON framework draft: (i)
approximate approach; (ii) candidate approach. Approximate approach is a
quick way of estimating the affects of impairment while the candidate
approach is to give a list of acceptable paths with more thorough
data/model. 

The BER can be estimated in various ways given the availability of other
impairment parameters. In any IA-RWA (approximate) type computation where we
are given impairment parameters to estimate the affects of impairments, we
must use some threshold criteria to accept/reject paths. The BER parameter
was our first attempt at providing some control over this criterion.

Best Regards,
Young

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] 
Sent: Thursday, April 02, 2009 4:08 AM
To: [email-masked]
Cc: [email-masked]
Subject: Comment on WSON Requirements

Hi Young.

This is a try to resume our discussion started during the SF meeting.
Indeed, I still don't get the rationale behind adding the BER as a
requirement for PCEP request.

First, I wonder what your intend is when requesting a BER threshold at
computation time while you can't really know it before LSP provisioning.
Obviously, what we look for is a low BER, but the way I see using BER in
routing would be to request a 2nd route *after* a poor BER measurement on a
firstly established LSP.
Then, considering what you called a "BER estimation", I don't clearly see
how you intend to estimate (or model?) it. The BER associated to an LSP is
highly dependent on so many parameters: link DGD at measurement time,
performance of the FEC used for the to-be-provisioned LSP , possible
cross-talk and thus impact of potential adjacent channels... Furthermore, I
don't really understand why focusing on the measurable BER range while a
typical PMD (in)accuracy may just move us between an acceptable route and an
unacceptable one, the latter being the very 1st problem we should try to
solve.
Finally, I don't get the use of such feature. Even if we could, why would I
request a 10^(-6) maximum BER? I don't see any room for anything else than
"the best one", so do we really need something else? I tend to see BER as a
varying quality feed*back*, not as an indicator that we can accurately
target at routing time.

I completely agree that PCEP must support optical requirements, but my
concern is to understand actual needs before loading the protocol.
Therefore, I look forward to reading some clarification on those issues.

Best regards,

Julien

---

From: <[email-masked]>
Date: Fri, 3 Apr 2009 17:18:15 +0200

Hi Young.

If I understand correctly, your actual requirement is to find a
"threshold criteria" to request a route that is "healthy enough" for the
PCC. So why have you chosen the BER which more relative to a digital
client layer? Why not considering a more optical criteria, like OSNR for
instance?

Have a good week-end,

Julien

-----Original Message-----
From: Young Lee [mailto:[email-masked]] 

Hi Julien,

The reason why we put the BER threshold in the PCEP request is to
"approximate" if the optical path in consideration would be "healthy"
enough
from the BER perspective. Please note that we have defined two different
computation types of IA-PCE functions in the IA-WSON framework draft:
(i)
approximate approach; (ii) candidate approach. Approximate approach is a
quick way of estimating the affects of impairment while the candidate
approach is to give a list of acceptable paths with more thorough
data/model. 

The BER can be estimated in various ways given the availability of other
impairment parameters. In any IA-RWA (approximate) type computation
where we
are given impairment parameters to estimate the affects of impairments,
we
must use some threshold criteria to accept/reject paths. The BER
parameter
was our first attempt at providing some control over this criterion.

Best Regards,
Young

-----Original Message-----

Hi Young.

First, I wonder what your intend is when requesting a BER threshold at
computation time while you can't really know it before LSP provisioning.
Obviously, what we look for is a low BER, but the way I see using BER in
routing would be to request a 2nd route *after* a poor BER measurement
on a
firstly established LSP.
Then, considering what you called a "BER estimation", I don't clearly
see
how you intend to estimate (or model?) it. The BER associated to an LSP
is
highly dependent on so many parameters: link DGD at measurement time,
performance of the FEC used for the to-be-provisioned LSP , possible
cross-talk and thus impact of potential adjacent channels...
Furthermore, I
don't really understand why focusing on the measurable BER range while a
typical PMD (in)accuracy may just move us between an acceptable route
and an
unacceptable one, the latter being the very 1st problem we should try to
solve.
Finally, I don't get the use of such feature. Even if we could, why
would I
request a 10^(-6) maximum BER? I don't see any room for anything else
than
"the best one", so do we really need something else? I tend to see BER
as a
varying quality feed*back*, not as an indicator that we can accurately
target at routing time.

Best regards,

Julien

---

From: Jonas Mårtensson <[email-masked]>
Date: Fri, 3 Apr 2009 18:30:24 +0200

Hi Young and Julien,

I missed this discussion in San Francisco but I tend to agree with (most of) Julien's comments. But if the PCE is expected to compute paths taking optical impairments into account it makes sense for a PCC to be able to set a "threshold" constraint, or minimum acceptable signal quality, although I find it a bit difficult to see under what circumstances anyone would be satisfied with anything else than "virtually zero" BER (or "error-free") for an optical path. In addition, some OSNR margin is usually required in order to allow for aging and other effects. In this case I think it might be better to specify the pre-FEC BER (or equivalent Q-factor if that sounds more related to the optical layer) and maybe in addition the desired OSNR margin.

Regards,
Jonas

> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of [email-masked]
> Sent: den 3 april 2009 17:18
> To: [email-masked]
> Cc: [email-masked]
> Subject: Re: [Pce] Comment on WSON Requirements
> 
> Hi Young.
> 
> If I understand correctly, your actual requirement is to find 
> a "threshold criteria" to request a route that is "healthy 
> enough" for the PCC. So why have you chosen the BER which 
> more relative to a digital client layer? Why not considering 
> a more optical criteria, like OSNR for instance?
> 
> Have a good week-end,
> 
> Julien
> 
> 
> The reason why we put the BER threshold in the PCEP request 
> is to "approximate" if the optical path in consideration 
> would be "healthy"
> enough
> from the BER perspective. Please note that we have defined 
> two different computation types of IA-PCE functions in the 
> IA-WSON framework draft:
> (i)
> approximate approach; (ii) candidate approach. Approximate 
> approach is a quick way of estimating the affects of 
> impairment while the candidate approach is to give a list of 
> acceptable paths with more thorough data/model. 
> 
> The BER can be estimated in various ways given the 
> availability of other impairment parameters. In any IA-RWA 
> (approximate) type computation where we are given impairment 
> parameters to estimate the affects of impairments, we must 
> use some threshold criteria to accept/reject paths. The BER 
> parameter was our first attempt at providing some control 
> over this criterion.
> 
> Best Regards,
> Young
> 
> Indeed, I still don't get the rationale behind adding the BER 
> as a requirement for PCEP request.
> 
> First, I wonder what your intend is when requesting a BER 
> threshold at computation time while you can't really know it 
> before LSP provisioning.
> Obviously, what we look for is a low BER, but the way I see 
> using BER in routing would be to request a 2nd route *after* 
> a poor BER measurement on a firstly established LSP.
> Then, considering what you called a "BER estimation", I don't 
> clearly see how you intend to estimate (or model?) it. The 
> BER associated to an LSP is highly dependent on so many 
> parameters: link DGD at measurement time, performance of the 
> FEC used for the to-be-provisioned LSP , possible cross-talk 
> and thus impact of potential adjacent channels...
> Furthermore, I
> don't really understand why focusing on the measurable BER 
> range while a typical PMD (in)accuracy may just move us 
> between an acceptable route and an unacceptable one, the 
> latter being the very 1st problem we should try to solve.
> Finally, I don't get the use of such feature. Even if we 
> could, why would I request a 10^(-6) maximum BER? I don't see 
> any room for anything else than "the best one", so do we 
> really need something else? I tend to see BER as a varying 
> quality feed*back*, not as an indicator that we can 
> accurately target at routing time.
> 
> I completely agree that PCEP must support optical 
> requirements, but my concern is to understand actual needs 
> before loading the protocol.
> _______________________________________________
> Pce mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pce
> 
>

---

From: Young Lee <[email-masked]>
Date: Fri, 03 Apr 2009 12:00:31 -0500

Hi Jonas and Julien,

I was thinking PRE-FEC BER when I mentioned the BER threshold. I also agree
with Julien that we may need to specify other optical parameters such as
OSNR margin. Regarding the BER threshold, please refer to G.698.1 and
G.698.2 in which to discuss black link definition and optical parameters
required. In particular, please read section 7.1.3 that discusses two cases
where Pre-FEC BER requirement. 

Let's continue on the discussion. Thanks.

Regards,
Young

-----Original Message-----
From: Jonas Mårtensson [mailto:[email-masked]] 
Sent: Friday, April 03, 2009 11:30 AM
To: [email-masked]; [email-masked]
Cc: [email-masked]
Subject: RE: Comment on WSON Requirements

Hi Young and Julien,

I missed this discussion in San Francisco but I tend to agree with (most of)
Julien's comments. But if the PCE is expected to compute paths taking
optical impairments into account it makes sense for a PCC to be able to set
a "threshold" constraint, or minimum acceptable signal quality, although I
find it a bit difficult to see under what circumstances anyone would be
satisfied with anything else than "virtually zero" BER (or "error-free") for
an optical path. In addition, some OSNR margin is usually required in order
to allow for aging and other effects. In this case I think it might be
better to specify the pre-FEC BER (or equivalent Q-factor if that sounds
more related to the optical layer) and maybe in addition the desired OSNR
margin.

Regards,
Jonas

---

From: "Sadler, Jonathan B." <[email-masked]>
Date: Fri, 3 Apr 2009 14:14:40 -0500

I agree that being able to specify minimum path "quality" (where the specific quality measure still needs to be specified) is something that needs to be provided by the PCC to the PCE.

That said I'm not certain that PRE-FEC BER is necessarily a good measure for optical path quality as it still is a discussion of the quality seen by the client of the modulation scheme in use.  The BER can be radically different for different modulations in the face of the different types of impairments.

This feels like an area where the experts in Q6/15 can provide beneficial council.

Jonathan Sadler

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Young Lee
Sent: Friday, April 03, 2009 12:01 PM
To: 'Jonas Mårtensson'; [email-masked]
Cc: [email-masked]
Subject: Re: [Pce] Comment on WSON Requirements

Hi Jonas and Julien,

Regards,
Young

-----Original Message-----
From: Jonas Mårtensson [mailto:[email-masked]] 
Sent: Friday, April 03, 2009 11:30 AM
To: [email-masked]; [email-masked]
Cc: [email-masked]
Subject: RE: Comment on WSON Requirements

Hi Young and Julien,

Regards,
Jonas

_______________________________________________
Pce mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/pce
============================================================
The information contained in this message may be privileged
and confidential and protected from disclosure. If the reader
of this message is not the intended recipient, or an employee
or agent responsible for delivering this message to the
intended recipient, you are hereby notified that any reproduction,
dissemination or distribution of this communication is strictly
prohibited. If you have received this communication in error,
please notify us immediately by replying to the message and
deleting it from your computer. Thank you. Tellabs
============================================================