Subject: [CCAMP] FW: Optical int class, changes to draft-ietf-ccamp-rwa-info-14

From: Leeyoung <[email-masked]>
Date: Tue, 19 Jun 2012 23:13:16 +0000

Hi

We haven't heard any clarification from those who proposed "optical interface classes (OIC) " to replace the current WSON signal compatibility definition. As Greg's previous email indicated, the OIC is defined to represent many fields, some of which are not relevant to WSON signal compatibility (for example, S field = spectral excursion, W = span distance, z = fiber type) and FEC is not defined in OIC. Besides, the WSON signal compatibility needs to include processing capability (e.g., REG capable, and others), which is not defined by the OIC.

The co-authors of the WSON info and encoding do not feel that OIC proposal has much relevance to the current WSON signal compatibility encoding. We'd like to close this issue and move on.

Regards,
Young

From: [email-masked] [mailto:[email-masked]] On Behalf Of Greg Bernstein
Sent: Wednesday, April 18, 2012 2:12 PM
To: [email-masked]
Subject: Re: [CCAMP] Optical int class, changes to draft-ietf-ccamp-rwa-info-14

Hi Giovanni, I still don't understand what problem the "Optical Interface Class" is addressing. You seem to be replacing something that is well defined "modulation type" with something less precise, and removing the important detailed FEC type information.

For the non-impairment case in ITU-T G.959.1 where they define various "optical tributary signal classes". This is the basis for the "modulation type" in the WSON info draft.  In GMPLS WSON extensions we are not trying to take on the entire management plane we take a minimal subset needed for connection provisioning. Perhaps if we just rename our "modulation type" to "optical tributary signal class" this will clear up any confusion.  Otherwise we need to know more specifically what you think you need added and why you want to remove the FEC type.

ITU-T G.698.1 and G.698.2 reference G.959.1 and other documents to create "application codes" which describe link and signal attributes. These application codes have the form: DScW-ytz(v) where
    D     indicates DWDM applications  --> Why do you need or want this? DWDM and CWDM data planes can't talk, LMP will tell you this
    S     indicates maximum spectral excursion --> Sounds impairment related...
    c     is the channel spacing in GHz --> Wouldn't LMP catch this incompatibility?
    W    is a letter indicating the span distance (S = short haul, L long haul) --> This seems like coarse impairment information
    y     indicates the the highest class of optical tributary signal supported  --> From ITU-T G.959.1, already have in WG draft.
    t     is a placeholder letter
    z     indicates the fiber type  --> This seems like very coarse grained impairment information.
    v     indicates the operating wavelength range in terms of spectral bands --> Already have in more detail

We already explicitly support "y" (our more detailed modulation type list) and "v" (we support the more detailed port wavelength constraint explicitly).

Lyndon and other "Optical Interface Class" co-authors in the bay area, perhaps we can meet and discuss.

Best Regards
Greg B.

On 3/30/2012 1:21 AM, Giovanni Martinelli wrote:
Dear WG,

according to input from Lou here the suggested changes on draft-ietf-ccamp-rwa-info-14  if the Optical Interface Class is used:

#1  Section 5.2
OLD:
<InputConstraints> ::= <SharedInput> [<ModulationTypeList>]
   [<FECTypeList>] [<BitRateRange>] [<ClientSignalList>]

NEW:
<InputConstraints> ::= <SharedInput> [<OpticalInterfaceClassList>] [<ClientSignalList>]

#2 Section 5.2
OLD:
<OutputConstraints> := <SharedOutput> [<ModulationTypeList>]
   [<FECTypeList>]

NEW:
<OutputConstraints> := <SharedOutput> [<OpticalInterfaceClassList>]

#3 Section 5.3.1
OLD:
      5.3.2. Modulation Type List

      Modulation type, also known as optical tributary signal class,
      comes in two distinct flavors: (i) ITU-T standardized types; (ii)
      vendor specific types. The permitted modulation type list can
      include any mixture of standardized and vendor specific types.

      <modulation-list>::=
      [<STANDARD_MODULATION>|<VENDOR_MODULATION>]...

      Where the STANDARD_MODULATION object just represents one of the
      ITU-T standardized optical tributary signal class and the
      VENDOR_MODULATION object identifies one vendor specific
      modulation type.

      5.3.3. FEC Type List

      Some devices can handle more than one FEC type and hence a list
      is needed.

      <fec-list>::= [<FEC>]

      Where the FEC object represents one of the ITU-T standardized
      FECs defined in [G.709], [G.707], [G.975.1] or a vendor-specific
      FEC.

      5.3.4. Bit Rate Range List

      Some devices can handle more than one particular bit rate range
      and hence a list is needed.

      <rate-range-list>::= [<rate-range>]...

      <rate-range>::=<START_RATE><END_RATE>

      Where the START_RATE object represents the lower end of the range
      and the END_RATE object represents the higher end of the range.

NEW:
    5.3.2 Optical Interface Class List

    <OpticalInterfaceClassList> ::= <OPTICAL_INT_CLASS> ...

    Where the term <OPTICAL_INT_CLASS> is defined by [xyz].

for the info model, That's all folks
Cheers
G

_______________________________________________

CCAMP mailing list

[email-masked]<mailto:[email-masked]>

https://www.ietf.org/mailman/listinfo/ccamp

--

===================================================

Dr Greg Bernstein, Grotto Networking (510) 573-2237

---

From: Giovanni Martinelli <[email-masked]>
Date: Wed, 20 Jun 2012 22:41:50 +0200

Hi Young,

you are right I did not answer yet...

The question I have for you and Greg is: why you want to go and discuss 
details about ITU application code internals? Is not enough to state 
that if two interfaces has the same application code they are compatible?

As already stated, the OIC concept get rid of specific parameters you 
need to list to assess signal compatibility so we just leverage what ITU 
decided to make compatibility assessment. In term of WSON protocols the 
we think the better solution is to provide room to caary compatibility 
information but not to go into arguing about internal gory details (we 
are supposed not to have optical knowledge ;-))

Cheers
G

On 6/20/12 1:13 , Leeyoung wrote:
>
> Hi
>
> We haven't heard any clarification from those who proposed "optical 
> interface classes (OIC) " to replace the current WSON signal 
> compatibility definition. As Greg's previous email indicated, the OIC 
> is defined to represent many fields, some of which are not relevant to 
> WSON signal compatibility (for example, S field = spectral excursion, 
> W = span distance, z = fiber type) and FEC is not defined in OIC. 
> Besides, the WSON signal compatibility needs to include processing 
> capability (e.g., REG capable, and others), which is not defined by 
> the OIC.
>
> The co-authors of the WSON info and encoding do not feel that OIC 
> proposal has much relevance to the current WSON signal compatibility 
> encoding. We'd like to close this issue and move on.
>
> Regards,
>
> Young
>
> *From:[email-masked] [mailto:[email-masked]] *On 
> Behalf Of *Greg Bernstein
> *Sent:* Wednesday, April 18, 2012 2:12 PM
> *To:* [email-masked]
> *Subject:* Re: [CCAMP] Optical int class, changes to 
> draft-ietf-ccamp-rwa-info-14
>
> Hi Giovanni, I still don't understand what problem the "Optical 
> Interface Class" is addressing. You seem to be replacing something 
> that is well defined "modulation type" with something less precise, 
> and removing the important detailed FEC type information.
>
> For the non-impairment case in ITU-T G.959.1 where they define various 
> "optical tributary signal classes". This is the basis for the 
> "modulation type" in the WSON info draft.  In GMPLS WSON extensions we 
> are not trying to take on the entire management plane we take a 
> minimal subset needed for connection provisioning. Perhaps if we just 
> rename our "modulation type" to "optical tributary signal class" this 
> will clear up any confusion.  Otherwise we need to know more 
> specifically what you think you need added and why you want to remove 
> the FEC type.
>
> ITU-T G.698.1 and G.698.2 reference G.959.1 and other documents to 
> create "application codes" which describe link and signal attributes. 
> These application codes have the form: DScW-ytz(v) where
>     D     indicates DWDM applications  --> Why do you need or want 
> this? DWDM and CWDM data planes can't talk, LMP will tell you this
>     W    is a letter indicating the span distance (S = short haul, L 
> long haul) --> This seems like coarse impairment information
>     y     indicates the the highest class of optical tributary signal 
> supported  --> From ITU-T G.959.1, already have in WG draft.
>     v     indicates the operating wavelength range in terms of 
> spectral bands --> Already have in more detail
>
> We already explicitly support "y" (our more detailed modulation type 
> list) and "v" (we support the more detailed port wavelength constraint 
> explicitly).
>
> according to input from Lou here the suggested changes on 
> draft-ietf-ccamp-rwa-info-14  if the Optical Interface Class is used:
>
> #1  Section 5.2
> OLD:
> [email-masked]  <mailto:[email-masked]>
> [email-masked]

---

From: Fatai Zhang <[email-masked]>
Date: Thu, 21 Jun 2012 03:40:32 +0000

Hi Giovanni,

I don’t know how many people have reviewed “draft-martinelli-wson-interface-class-02”, but I have to admit that I don’t understand what problem this draft is trying to resolve after I reviewed it several times.

I guess the purpose of the OCI is to use a general format to carry all kinds of the signal compatibility information, is this right?  If my understanding is correct, could you tell how to carry all kinds of the necessary signal compatibility information instead of simply saying as follows? In another way, could you explain and illustrate how to carry the information defined in [G.698.1] and [G.698.2]?
=======================================================================
   S=1, OI Code Points:
      0: reserved
      1: [ITU-G.698.1] application code.
      2: [ITU-G.698.2] application code.
=====================================================================

Please see more in-line below.

Thanks

Fatai

发件人: [email-masked] [mailto:[email-masked]] 代表 Giovanni Martinelli
发送时间: 2012年6月21日 4:42
收件人: [email-masked]
主题: Re: [CCAMP] FW: Optical int class, changes to draft-ietf-ccamp-rwa-info-14

Hi Young,

The question I have for you and Greg is: why you want to go and discuss details about ITU application code internals? Is not enough to state that if two interfaces has the same application code they are compatible?

As already stated, the OIC concept get rid of specific parameters you need to list to assess signal compatibility so we just leverage what ITU decided to make compatibility assessment. In term of WSON protocols the we think the better solution is to provide room to caary compatibility information but not to go into arguing about internal gory details (we are supposed not to have optical knowledge ;-))

[Fatai] How to get rid of…? We must go into the tech details when we design the protocol encoding. I don’t know how people who are supposed not having optical knowledge design the protocol encoding.

Cheers
G

We haven’t heard any clarification from those who proposed “optical interface classes (OIC) ” to replace the current WSON signal compatibility definition. As Greg’s previous email indicated, the OIC is defined to represent many fields, some of which are not relevant to WSON signal compatibility (for example, S field = spectral excursion, W = span distance, z = fiber type) and FEC is not defined in OIC. Besides, the WSON signal compatibility needs to include processing capability (e.g., REG capable, and others), which is not defined by the OIC.

The co-authors of the WSON info and encoding do not feel that OIC proposal has much relevance to the current WSON signal compatibility encoding. We’d like to close this issue and move on.

Regards,
Young

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Greg Bernstein
Sent: Wednesday, April 18, 2012 2:12 PM
To: [email-masked]<mailto:[email-masked]>
Subject: Re: [CCAMP] Optical int class, changes to draft-ietf-ccamp-rwa-info-14

Best Regards
Greg B.

#1  Section 5.2
OLD:

NEW:

#2 Section 5.2
OLD:

NEW:

#3 Section 5.3.1
OLD:

      <modulation-list>::=

      5.3.3. FEC Type List

      <fec-list>::= [<FEC>]

NEW:

CCAMP mailing list

--

CCAMP mailing list

---

From: Greg Bernstein <[email-masked]>
Date: Thu, 21 Jun 2012 08:12:18 -0700

Hi Giovanni, in our drafts we don't use the ITU-T application code. You 
suggested its use in your OIC draft. I was pointing out that most of the 
ITU code deals with impairments. These drafts are not related to 
impairments. For signal compatibility we need a certain minimal amount 
of information which includes modulation type (ITU-T's optical tributary 
class) and FEC type.
For both of these we provide for vendor specific types so can 
accommodate any special signals/FECs that you want to define.
Can you please explain what problem you are trying to solve and how the 
current drafts do not address this problem. Please remember these drafts 
are for the non-impairment case.
Regards
Greg
On 6/20/2012 1:41 PM, Giovanni Martinelli wrote:
> The question I have for you and Greg is: why you want to go and 
> discuss details about ITU application code internals? Is not enough to 
> state that if two interfaces has the same application code they are 
> compatible?
>
> need to list to assess signal compatibility so we just leverage what 
> ITU decided to make compatibility assessment. In term of WSON 
> protocols the we think the better solution is to provide room to caary 
> compatibility information but not to go into arguing about internal 
> gory details (we are supposed not to have optical knowledge ;-))
>
>
> Cheers
> G
>
>
>
>> is defined to represent many fields, some of which are not relevant 
>> to WSON signal compatibility (for example, S field = spectral 
>> excursion, W = span distance, z = fiber type) and FEC is not defined 
>> in OIC. Besides, the WSON signal compatibility needs to include 
>> processing capability (e.g., REG capable, and others), which is not 
>> defined by the OIC.
>>
>> For the non-impairment case in ITU-T G.959.1 where they define 
>> various "optical tributary signal classes". This is the basis for the 
>> list) and "v" (we support the more detailed port wavelength 
>> constraint explicitly).
>>

---

From: Leeyoung <[email-masked]>
Date: Thu, 21 Jun 2012 19:26:33 +0000

Hi Giovanni

Please see in-line for my comments.

Thanks.
Young

From: [email-masked] [mailto:[email-masked]] On Behalf Of Giovanni Martinelli
Sent: Wednesday, June 20, 2012 3:42 PM
To: [email-masked]
Subject: Re: [CCAMP] FW: Optical int class, changes to draft-ietf-ccamp-rwa-info-14

Hi Young,

YOUNG>> First, the ITU-T application code format defined in G.698.1 and .2 cannot be used in WSON case because it is not complete --- FEC types are not defined in the current field: DScW-ytz(v) which Greg's email already described each field.
So we cannot borrow its code as is today --- there is no way to check FEC compatibility.

Beside, In signal compatibility, we have other fields we are checking such as processing capability (see section 5.6 http://datatracker.ietf.org/doc/draft-ietf-ccamp-rwa-wson-encode/?include_text=1) --- such as reg capability, monitoring and any vendor specific capability).

More fundamentally, the application code points in the current G.698.1 and .2 were defined in the context of DWDM black links and optical impairment context. As such many data are not relevant to the current WSON non-impairment scope.

Cheers
G

Regards,
Young

Best Regards
Greg B.

#1  Section 5.2
OLD:

NEW:

#2 Section 5.2
OLD:

NEW:

#3 Section 5.3.1
OLD:

      <modulation-list>::=

      5.3.3. FEC Type List

      <fec-list>::= [<FEC>]

NEW:

CCAMP mailing list

--

CCAMP mailing list

---

From: Giovanni MARTINELLI <[email-masked]>
Date: Mon, 25 Jun 2012 18:11:35 +0200

Hi Greg,

On 6/21/12 17:12 , Greg Bernstein wrote:
> Hi Giovanni, in our drafts we don't use the ITU-T application code. 
> You suggested its use in your OIC draft. I was pointing out that most 
> of the ITU code deals with impairments. These drafts are not related 
> to impairments.
ITU application does *not only* deal with impairments, for sure they 
deal with some other physical parameters and they *guarantee* wson 
interfaces compatibility (which is our current sub-case).
I'm wondering  we need some official statement from from ITU on this 
topic through the usual communication flows ccamp has with ITU (but I 
guess thisi to wg chairs to decide).

 From CCAMP side, I would say that draft are not related to impairments 
but I would prefer a solution that will simplify both problems: RWA only 
(i.e. signal compatibility), RWA-IV (signal compatibility + some others 
parmeters).

Keep in mind that ITU application code is one instance of the optical 
interface class. The OIC per-se is a container and 
draft-martinelli-wson-interface-class-02 propose how the ITU application 
can map on the OIC .

> For signal compatibility we need a certain minimal amount of 
> information which includes modulation type (ITU-T's optical tributary 
> class) and FEC type.

Plus all the specific values for those parameters. Every time ITU define 
a new FEC type, a new modulation format etc. you need to update all your 
drafts.

> accommodate any special signals/FECs that you want to define.

That's given I'm not complaining about this (although I would love to 
state that vendor specific does not means private or hidden).

> Can you please explain what problem you are trying to solve and how 
> the current drafts do not address this problem. Please remember these 
> drafts are for the non-impairment case.

The problem is that current draft explicit guess what are the interface 
parameters needed for signal compatibility. There was a mail a while ago 
on the mailing list where I did propose changes on 
draft-ietf-ccamp-rwa-info. I will refresh those info proposing changes 
on current encoding drafts as well.

Cheers
G

>> discuss details about ITU application code internals? Is not enough 
>> to state that if two interfaces has the same application code they 
>> are compatible?
>>
>> protocols the we think the better solution is to provide room to 
>> caary compatibility information but not to go into arguing about 
>> internal gory details (we are supposed not to have optical knowledge ;-))
>>
>>
>> Cheers
>> G
>>
>>
>>
>>> compatibility definition. As Greg's previous email indicated, the 
>>> OIC is defined to represent many fields, some of which are not 
>>> relevant to WSON signal compatibility (for example, S field = 
>>> spectral excursion, W = span distance, z = fiber type) and FEC is 
>>> not defined in OIC. Besides, the WSON signal compatibility needs to 
>>> include processing capability (e.g., REG capable, and others), which 
>>> is not defined by the OIC.
>>>
>>> various "optical tributary signal classes". This is the basis for 
>>> the "modulation type" in the WSON info draft.  In GMPLS WSON 
>>> extensions we are not trying to take on the entire management plane 
>>> we take a minimal subset needed for connection provisioning. Perhaps 
>>> if we just rename our "modulation type" to "optical tributary signal 
>>> class" this will clear up any confusion.  Otherwise we need to know 
>>> more specifically what you think you need added and why you want to 
>>> remove the FEC type.
>>>
>>> create "application codes" which describe link and signal 
>>> attributes. These application codes have the form: DScW-ytz(v) where
>>>     y     indicates the the highest class of optical tributary 
>>> signal supported  --> From ITU-T G.959.1, already have in WG draft.

---

From: Giovanni MARTINELLI <[email-masked]>
Date: Mon, 25 Jun 2012 18:19:42 +0200

Hi Young,

pls see inline with [GM]

On 6/21/12 21:26 , Leeyoung wrote:
> Behalf Of *Giovanni Martinelli
> *Sent:* Wednesday, June 20, 2012 3:42 PM
> *To:* [email-masked]
> *Subject:* Re: [CCAMP] FW: Optical int class, changes to 
> YOUNG>> First, the ITU-T application code format defined in G.698.1 
> and .2 cannot be used in WSON case because it is not complete --- FEC 
> types are not defined in the current field: DScW-ytz(v) which Greg's 
> email already described each field.
>
[GM] I guess my view is within the other email. Instead of looking at 
ITU application code internals we make this question: two interfaces 
having the same application code are compatible?
My answer is yes...

> Beside, In signal compatibility, we have other fields we are checking 
> such as processing capability (see section 5.6 
> http://datatracker.ietf.org/doc/draft-ietf-ccamp-rwa-wson-encode/?include_text=1) 
> --- such as reg capability, monitoring and any vendor specific 
> capability).
>
I would keep the signal compatibility separated from processing 
capability. As suggested by Lou I would send an email with proposed 
changes on the draft you mention (I did only on info model, encoding 
changes comes easily but better to highlight)

Cheers
G

> More fundamentally, the application code points in the current G.698.1 
> and .2 were defined in the context of DWDM black links and optical 
> impairment context. As such many data are not relevant to the current 
> WSON non-impairment scope.
>
>
>
> *From:[email-masked] <mailto:[email-masked]> 
> [mailto:[email-masked]] *On Behalf Of *Greg Bernstein
> *To:* [email-masked] <mailto:[email-masked]>

---

From: Giovanni MARTINELLI <[email-masked]>
Date: Mon, 25 Jun 2012 18:39:47 +0200

Hi Fatai,

finally back to you as well ... see inline

On 6/21/12 5:40 , Fatai Zhang wrote:
>
> Hi Giovanni,
>
> I don’t know how many people have reviewed
> “draft-martinelli-wson-interface-class-02”, but I have to admit that I
> don’t understand what problem this draft is trying to resolve after I
> reviewed it several times.
>

[GM] assuming you well know how current wson draft deals with the signal
compatibility I'm not sure about your statement here above...

> I guess the purpose of the OCI is to use a general format to carry all
> kinds of the signal compatibility information, is this right?
>

[GM] yes

> If my understanding is correct, could you tell how to carry all kinds
> of the necessary signal compatibility information instead of simply
> saying as follows? In another way, could you explain and illustrate
> how to carry the information defined in [G.698.1] and [G.698.2]?
>

[GM] In current draft the only requirement to assess the signal
compatibility is that two interface having the same OIC value are
compatible. So WSON protocols does not need to explicitly list optical
parameters and their value. We can probably provide some examples in an
appendix about how you can map them but the OIC concept per se does not
depend on this.

Cheers
G

> *发 件人:[email-masked] [mailto:[email-masked]] *代
> 表 *Giovanni Martinelli
> *发 送时间:*2012年6月21日4:42
> *收件人:[email-masked]
> *主题:*Re: [CCAMP] FW: Optical int class, changes to
> [Fatai] How to get rid of…? We must go into the tech details when we
> design the protocol encoding. I don’t know how people who are supposed
> not having optical knowledge design the protocol encoding.
>

> We haven’t heard any clarification from those who proposed “optical
> interface classes (OIC) ” to replace the current WSON signal
> compatibility definition. As Greg’s previous email indicated, the OIC
> encoding. We’d like to close this issue and move on.
>
> Regards,
>
> Young
>
> D indicates DWDM applications --> Why do you need or want this? DWDM
> and CWDM data planes can't talk, LMP will tell you this
> W is a letter indicating the span distance (S = short haul, L long
> haul) --> This seems like coarse impairment information

---

From: Greg Bernstein <[email-masked]>
Date: Tue, 26 Jun 2012 08:20:03 -0700

Hi Giovanni, I don't think the ITU-T application code "guarantees" WSON 
interface compatibility, but serves as a way of describing a number of 
aspects of the an optical line system. This information seems useful for 
the management plane but not appropriate in its entirety or scope for 
the control plane.  Maybe some regular ITU-T optical folks would care to 
comment.
Greg
On 6/25/2012 9:11 AM, Giovanni MARTINELLI wrote:
> but I would prefer a solution that will simplify both problems: RWA 
> only (i.e. signal compatibility), RWA-IV (signal compatibility + some 
> others parmeters).
>
> draft-martinelli-wson-interface-class-02 propose how the ITU 
> application can map on the OIC .
>
>
> Plus all the specific values for those parameters. Every time ITU 
> define a new FEC type, a new modulation format etc. you need to update 
> all your drafts.
>
> The problem is that current draft explicit guess what are the 
> interface parameters needed for signal compatibility. There was a mail 
> a while ago on the mailing list where I did propose changes on 
>>> As already stated, the OIC concept get rid of specific parameters 
>>> you need to list to assess signal compatibility so we just leverage 
>>> what ITU decided to make compatibility assessment. In term of WSON 
>>>> include processing capability (e.g., REG capable, and others), 
>>>> which is not defined by the OIC.
>>>>
>>>> proposal has much relevance to the current WSON signal 
>>>> compatibility encoding. We'd like to close this issue and move on.
>>>>
>>>> Regards,
>>>>
>>>> Young
>>>>
>>>> we take a minimal subset needed for connection provisioning. 
>>>> Perhaps if we just rename our "modulation type" to "optical 
>>>> tributary signal class" this will clear up any confusion. Otherwise 
>>>> we need to know more specifically what you think you need added and 
>>>> why you want to remove the FEC type.
>>>>
>>>>     W    is a letter indicating the span distance (S = short haul, 
>>>> L long haul) --> This seems like coarse impairment information
>>>> We already explicitly support "y" (our more detailed modulation 
>>>> type list) and "v" (we support the more detailed port wavelength 
>>>> constraint explicitly).
>>>>

---

From: Fatai Zhang <[email-masked]>
Date: Thu, 28 Jun 2012 08:44:51 +0000

Hi Giovanni,

<snipped>

[GM] In current draft the only requirement to assess the signal compatibility is  that two interface having the same OIC value are compatible. So WSON protocols does not need to explicitly list optical parameters and their value. We can probably provide some examples in an appendix about how you can map them but the OIC concept per se does not depend on this.

[Fatai] How magic the OIC is. I really want to see how this magic would happen if there is no need to list optical parameters and their value.

Cheers
G

Thanks

Fatai

---

From: Greg Bernstein <[email-masked]>
Date: Fri, 29 Jun 2012 10:51:14 -0700

Hi Giovanni, I'm still not sure what problem you are trying to solve.  
Can you give us a specific example within the context of non-impairment 
WSON. Then we can work to see if anything needs to be changed in the 
existing documents. The current information within the WSON documents 
has been thoroughly reviewed. We can't remove information and replace it 
with less specific information from the compatibility perspective.  If 
you need additional information added for your application, please 
furnish an example.

If changes are needed we will incorporate them, as we have done in the past.

Best Regards
Greg B.
On 6/28/2012 1:44 AM, Fatai Zhang wrote:
> parameters and their value. We can probably provide some examples in 
> an appendix about how you can map them but the OIC concept per se does 
> not depend on this.
>
> [Fatai] How magic the OIC is. I really want to see how this magic 
> would happen if there is no need to list optical parameters and their 
> value.
>
>
> Cheers
> G
>
> Thanks
>
> Fatai
>
>
>