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

From: Giovanni Martinelli <[email-masked]>
Date: Fri, 30 Mar 2012 10:21:44 +0200

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

---

From: Leeyoung <[email-masked]>
Date: Fri, 30 Mar 2012 08:30:23 +0000

Hi Givovanni,

Thanks for providing the feedback to the list.

Before we consider this, you need to define <OpticalInterfaceClassList>.
I suspect <OpticalInterfaceClass>::= <ModulationTypeList> <FECTypeList> <BitRateRange>.

If this is not the case, please clarify.

If this is the case, then the current information model does not break.

Regards,
Young

From: [email-masked] [mailto:[email-masked]] On Behalf Of Giovanni Martinelli
Sent: Friday, March 30, 2012 3:22 AM
To: CCAMP
Subject: [CCAMP] Optical int class, changes to draft-ietf-ccamp-rwa-info-14

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:

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

#2 Section 5.2
OLD:

NEW:

#3 Section 5.3.1
OLD:

      <modulation-list>::=

      5.3.3. FEC Type List

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

NEW:

---

From: Giovanni Martinelli <[email-masked]>
Date: Fri, 30 Mar 2012 10:33:08 +0200

I realize that proposing a change to a wg document with something like 
<OPTICAL_INT_CLASS> coming from outside the wg doc itself, require 
explicit statement:
according to my knowledge, there are no IPRs on <OPTICAL_INT_CLASS>.

Cheers
G

On 3/30/12 10:21 , Giovanni Martinelli wrote:
> _______________________________________________
> CCAMP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ccamp

---

From: Giovanni Martinelli <[email-masked]>
Date: Fri, 30 Mar 2012 10:39:02 +0200

Ciao Young!

> Before we consider this, you need to define <OpticalInterfaceClassList>.
defined in section 5.3.2 (the ::= operation shuld do the trick). The 
<OPTICAL_INT_CLASS>term itself will be defined elsewhere. The encoding 
will be suggested in a separate email since impact a different draft 
(the encoding one).

> If this is not the case, please clarify.
Not necessarly, the idea is to get rid of specifying each single optical 
parameter. The class semantic will be defined elsewhere (likely ITU 
applications codes, vendor publishing their class information etc.)

Hope this help understanding

Cheers,
G

> *From:[email-masked] [mailto:[email-masked]] *On 
> Behalf Of *Giovanni Martinelli
> *Sent:* Friday, March 30, 2012 3:22 AM
> *To:* CCAMP
> *Subject:* [CCAMP] Optical int class, changes to 
> draft-ietf-ccamp-rwa-info-14
>
> Dear WG,
>

---

From: Leeyoung <[email-masked]>
Date: Fri, 30 Mar 2012 08:53:22 +0000

Hi Giovanni,

You suggested the following changes.

#1  Section 5.2
OLD:

NEW:

YOUNG>> Here your <OpticalInterfaceClassList>  includes <Mod> <FEC> <BitRateRange>.

#2 Section 5.2
OLD:

NEW:

YOUNG>> Here your <OpticalInterfaceClassList> only represents  <Mod> <FEC> (but not <BitRateRange>).

This is very confusing. Information model should be very clear what the elements are for each definition. Information elements for <Input Constraints> and <Output Constraints> are not the same. With your <OpticalInterfaceClassList> used in both places, there is apparent confusion.  Whatever you want to call it (which I don't care) we have to define the elements for Input Constraint and Output Constraint clearly, respectively.

Am I confused or missing anything?

Young

From: Giovanni Martinelli [mailto:[email-masked]]
Sent: Friday, March 30, 2012 3:39 AM
To: Leeyoung
Cc: CCAMP
Subject: Re: [CCAMP] Optical int class, changes to draft-ietf-ccamp-rwa-info-14

Ciao Young!

Before we consider this, you need to define <OpticalInterfaceClassList>.
defined in section 5.3.2 (the ::= operation shuld do the trick). The <OPTICAL_INT_CLASS>term itself will be defined elsewhere. The encoding will be suggested in a separate email since impact a different draft (the encoding one).

Not necessarly, the idea is to get rid of specifying each single optical parameter. The class semantic will be defined elsewhere (likely ITU applications codes, vendor publishing their class information etc.)

Cheers,
G

Regards,
Young

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Giovanni Martinelli
Sent: Friday, March 30, 2012 3:22 AM
To: CCAMP
Subject: [CCAMP] Optical int class, changes to draft-ietf-ccamp-rwa-info-14

Dear WG,

#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:

---

From: Giovanni Martinelli <[email-masked]>
Date: Sat, 31 Mar 2012 09:09:25 +0200

Hi Young,

On 3/30/12 10:53 , Leeyoung wrote:
> *YOUNG>> Here your <OpticalInterfaceClassList>  includes <Mod> <FEC> 
> <BitRateRange>.*
>
>
> #2 Section 5.2
> OLD:
> *YOUNG>> Here your <OpticalInterfaceClassList> only represents <Mod> 
> <FEC> (but not <BitRateRange>). *
>
> **
>
[GM] Just took the current draft text (and, since you may reuse these 
terms for 3R regeneration you'd probably need a fix here).

> *This is very confusing. Information model should be very clear what 
> the elements are for each definition. Information elements for <Input 
> Constraints> and <Output Constraints> are not the same. With your 
> <OpticalInterfaceClassList> used in both places, there is apparent 
> confusion.  Whatever you want to call it (which I don't care) we have 
> to define the elements for Input Constraint and Output Constraint 
> clearly, respectively. *
>
> **
>
> *Am I confused or missing anything? *
>
[GM] You still want to look inside a class and decide what are the 
optical parameters that cares to you (and here I bet they won't be the 
same in few yrs time). The optical interface class abstract from what 
inside the optical gory details and class internals is out of scope here 
and should be defined by appropriate people (e.g. much like ITU 
applications code). Either a class holds 1 or 100 parameters why you 
care? You carry around the class reference and you only need to know 
that same class means two interface are compatible.

Cheers
G

> Young
>
> *From:*Giovanni Martinelli [mailto:[email-masked]]
> *Sent:* Friday, March 30, 2012 3:39 AM
> *To:* Leeyoung
> *Cc:* CCAMP
> *Subject:* Re: [CCAMP] Optical int class, changes to 
> Not necessarly, the idea is to get rid of specifying each single 
> optical parameter. The class semantic will be defined elsewhere 
> (likely ITU applications codes, vendor publishing their class 
> information etc.)
>
> *From:[email-masked] <mailto:[email-masked]> 
> [mailto:[email-masked]] *On Behalf Of *Giovanni Martinelli