Subject: Re: [CCAMP] Fwd: New Version Notification for draft-martinelli-wson-interface-class-02.txt

From: Greg Bernstein <[email-masked]>
Date: Tue, 27 Mar 2012 08:34:24 -0700

Hi CCAMPers, I forgot to CC'd the entire CCAMP group with my comments on 
this draft. Here are my comments along with some of Giovanni's responses.
Greg

-------- Original Message --------
Subject: 	Re: [CCAMP] Fwd: New Version Notification for 
draft-martinelli-wson-interface-class-02.txt
Date: 	Mon, 26 Mar 2012 10:20:14 +0200
From: 	Giovanni Martinelli <[email-masked]>
To: 	Greg Bernstein <[email-masked]>

Hi Greg,

thx for your comments!

On 3/23/12 18:24 , Greg Bernstein wrote:
> Hi Giovanni and Lyndon and other co-authors.
since looks like I'm the only one in to, is this mail for ccamp ML? in 
case pls forward to the list ...

>   In formulating the compatibility aspects of the WSON we looked at 
> various ITU-T specifications and extracted the essential information 
> of general applicability across all types of WSONs.  The G.698.x 
> series are good documents but they are aimed primarily at the metro 
> space. They include much information that CCAMP would consider 
> impairment related.
>
> We went through a similar process when looking at G.959 which has 
> general "application codes" that include things such as fiber 
> attentuation (an impairment related parameter).  Hence why we 
> extracted a small subset, i.e.,  the "modulation format" in the WSON 
> info/encoding drafts. ITU-T calls this an "optical tributary signal 
> class" in G.959.1 (which G.698.x points to).  I'm not sure what else 
> in the ITU-T application codes is useful in the non-impairment case.  
> Too little information on FEC is currently included in the codes to 
> guarantee compatibility, so we put together a list of ITU-T 
> standardized FEC codes (plus option for vendor specific).
>
The process you did is clear. The set of parameters selected for 
compatibility was you choice or a result of a answer received through 
the ITU liason?

> Is the our term "modulation type" confusing you? Would folks prefer 
> "optical tributary signal class". It looks like this existing field 
> can do everything that you would need in the non-impairment case.  A 
> guiding principle in determining what to include in WSON has been that 
> the control plane takes on just enough management plane information to 
> perform a task.  We don't try to repeat all possible management plane 
> information in the control plane. 
Right so the idea of this draft is to abstract from each optical 
parameters internal (Modulation format is just taken as an example among 
the full set).

> I can see some of these ITU-T application codes contributing in the 
> impairment case but don't see how they are essential in the 
> non-impairment case.  Do we really need to modify the non-impairment 
> drafts at this point? We are already ITU-T compatible.
>
I guess this is part of WG discussion

Cheers
G

> Greg
>
> On 3/23/2012 6:12 AM, Giovanni Martinelli wrote:
>> Hi Young,
>>
>> appreciate your comments! The part of the draft which report 
>> references to G.698.x is the encoding that shows how the interface 
>> class concept is fully compatible with the ITU application code.   In 
>> the next revision we could figure out code points for all ITU 
>> applications codes available now (including G.959).
>>
>> I would like to mention however that the Optical Interface Class is 
>> fully in scope with current WSON rwa activity (not only with 
>> impairments) since even for RWA you need to assess at least signal 
>> compatibility. Current WSON proposal have explicit parameters 
>> definitions (e.g. FEC and Modulation formats), with the Interface 
>> class concept you don't need to explicit them since the semantic of 
>> the class will be defined elsewhere.
>>
>> The goal is not saving bits in encoding but making protocol WSON 
>> extensions a bit more independent from explicit optical parameters 
>> definitions.
>>
>> Cheers
>> G
>>
>>
>> On 3/22/12 18:03 , Leeyoung wrote:
>>>
>>> Hi Giovanni,
>>>
>>> It looks like your draft is in the context of black links and the 
>>> use of some of ITU-T interface model for impairment context. Your 
>>> reference is G.698.1 and .2.
>>>
>>> This seems to belong to impairment/black link model which is beyond 
>>> the current WSON scope. The part of confusion is the fact that 
>>> G.698.1 and .2 talk about some modulation type (such as NRZ's).  But 
>>> this was discussed in the context of black link.  We are discussing 
>>> Modulation and FEC  in the context of resource block property 
>>> (OEO/REG). Our ITU-T reference is 709, 975 and 959.1.
>>>
>>> One of the referred entities in your interface class is fiber type, 
>>> which is an important factor in impairment modeling, but this is 
>>> beyond the scope of non-impairment WSON, which is our current scope.
>>>
>>> Regards,
>>>
>>> Young
>>>
>>> *From:[email-masked] [mailto:[email-masked]] *On 
>>> Behalf Of *Giovanni Martinelli
>>> *Sent:* Tuesday, March 06, 2012 10:58 AM
>>> *To:* CCAMP
>>> *Subject:* [CCAMP] Fwd: New Version Notification for 
>>> draft-martinelli-wson-interface-class-02.txt
>>>
>>> Dear Ccamp,
>>>
>>> here's an update on  Optical Interface Class draft.
>>>
>>> The idea is to make WSON protocol extensions independent of explicit 
>>> optical parameters encoding as currently defined in following IDs 
>>> (referring only to wg documents):
>>> - draft-ietf-ccamp-rwa-info-13
>>> - draft-ietf-ccamp-rwa-wson-encode-13
>>> - draft-ietf-pce-wson-routing-wavelength-06
>>> And related draft protocol extensions that make use of them:
>>> - draft-ietf-ccamp-wson-signal-compatibility-ospf-07
>>> - draft-ietf-ccamp-wson-signaling-02
>>>
>>> As and additional benefit,  the optical interface class can be fully 
>>> compatible with ITU application code concept.
>>>
>>> Draft was first presented in Quebec and there were several good 
>>> reactions from the room, so please provide comments!
>>>
>>> Thanks in advance
>>> Giovanni & co-authors
>>>
>>>
>>>
>>>
>>> -------- Original Message --------
>>>
>>> *Subject: *
>>>
>>> 	
>>>
>>> New Version Notification for 
>>> draft-martinelli-wson-interface-class-02.txt
>>>
>>> *Date: *
>>>
>>> 	
>>>
>>> Tue, 06 Mar 2012 08:30:45 -0800
>>>
>>> *From: *
>>>
>>> 	
>>>
>>> [email-masked] <mailto:[email-masked]>
>>>
>>> *To: *
>>>
>>> 	
>>>
>>> [email-masked] <mailto:[email-masked]>
>>>
>>> *CC: *
>>>
>>> 	
>>>
>>> [email-masked] <mailto:[email-masked]>, [email-masked] 
>>> <mailto:[email-masked]>, [email-masked] 
>>> <mailto:[email-masked]>, [email-masked] 
>>> <mailto:[email-masked]>
>>>
>>> A new version of I-D, draft-martinelli-wson-interface-class-02.txt has been successfully submitted by Giovanni Martinelli and posted to the IETF repository.
>>>   
>>> Filename:       draft-martinelli-wson-interface-class
>>> Revision:       02
>>> Title:          WSON Optical Interface Class
>>> Creation date:  2012-03-06
>>> WG ID:          Individual Submission
>>> Number of pages: 13
>>>   
>>> Abstract:
>>>     Current work on wavelength switched optical network includes several
>>>     considerations regarding the interface signal compatibility.  In
>>>     particular ingress and egress optical interfaces will require a check
>>>     on several optical parameters to assess if the signal generated by
>>>     the ingress interface can be compatible with the receiving interface.
>>>     Current solution available encode all parameters in WSON protocol
>>>     extensions while in this draft will propose an alternative method to
>>>     keep into account the signal compatibility issue at protocol level.
>>>   
>>>                                                                                    
>>>   
>>>   
>>> The IETF Secretariat
>>
>>
>> _______________________________________________
>> CCAMP mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/ccamp
>
>
> -- 
> ===================================================
> Dr Greg Bernstein, Grotto Networking (510) 573-2237
>

---

From: Greg Bernstein <[email-masked]>
Date: Tue, 27 Mar 2012 08:49:32 -0700

Hi Giovanni, see below for responses to your questions.
Greg
On 3/27/2012 8:34 AM, Greg Bernstein wrote:
> Hi CCAMPers, I forgot to CC'd the entire CCAMP group with my comments 
> on this draft. Here are my comments along with some of Giovanni's 
> responses.
> Greg
>
--> Our choice in conjunction with the working group of which some also 
attend ITU-T. I can't remember if CCAMP has done a formal liason on this 
document with ITU-T. Deborah/Lou?
>> guiding principle in determining what to include in WSON has been 
>> that the control plane takes on just enough management plane 
>> information to perform a task.  We don't try to repeat all possible 
>> management plane information in the control plane. 
> parameters internal (Modulation format is just taken as an example 
> among the full set).
--> No, only those relevant to the non-impairment situation.  Maybe we 
should use the term "optical tributary signal class". This is where most 
of the updates are happening, i.e., new classes for 40G, 100G, etc...  
Some times we get negative feedback for too much ITU-T terminology, 
sometime positive.
> I guess this is part of WG discussion
--> Okay, but what would need to be changed in the non-impairment case 
and why?
>>> class concept is fully compatible with the ITU application code.   
>>> In the next revision we could figure out code points for all ITU 
>>>> G.698.1 and .2 talk about some modulation type (such as NRZ's). 
>>>>  But this was discussed in the context of black link.  We are 
>>>> discussing Modulation and FEC  in the context of resource block 
>>>> property (OEO/REG). Our ITU-T reference is 709, 975 and 959.1.
>>>>
>>>> The idea is to make WSON protocol extensions independent of 
>>>> explicit optical parameters encoding as currently defined in 
>>>> following IDs (referring only to wg documents):
>>>> As and additional benefit,  the optical interface class can be 
>>>> fully compatible with ITU application code concept.
>>>>