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

From: Greg Bernstein <[email-masked]>
Date: Wed, 18 Apr 2012 12:11:38 -0700

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]
> https://www.ietf.org/mailman/listinfo/ccamp

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