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

From: Giovanni MARTINELLI <[email-masked]>
Date: Thu, 05 Jul 2012 14:06:42 +0200

Hi Greg,

pls see my other mail for proposed encoding changes. I'll try to clarify 
your doubts here below

On 6/29/12 19:51 , Greg Bernstein wrote:
> Hi Giovanni, I'm still not sure what problem you are trying to solve.

the problem is "signal compatibility", I'm sure you know already all 
ccamp references for this.

The current solution in ccamp drafts list explicitly all parameters 
required today to assess the compatibility and has two main drawbacks:
1. Explicit values taken by parameters are (very) technology dependents.
2. The list of parameters is per-defined and works today, we are not 
granted for future technology evolution (e.g. flexspectrum already 
knocking at the doors,  other technology evolutions? ).

I'll further clarify below but let me remind an analogy: SRLGs defines 
what they should represent and the field format (e.g. 32 bits, etc.), 
hey do not defines specific bit encoding (within those 32 bits) or 
partitioning you may use. To some extent, the Optical Interface Class 
mimic this idea.

Or if you want a programmer analogy, the Optical Interface Class is like 
a pointer. Instead of carry around explicit structures you move only 
pointers (reference to).

> 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.
>

a) FEC values can be encoded according to section 5.3 of 
draft-ietf-ccamp-rwa-wson-encode and there are 10 values defined for FecID
b) Modulation formats encoded according to section 5.2, only 5 values 
defined.

- what if another FecID (e.g. =11) or an additional Modulation ID (e.g. 
= 6) is required (i.e. standardized) ? What the impacts on all protocol 
extensions using  this encoding?
- Is there any cross compatibility among differend FecID and 
ModulationID? It will never happen in the future?

If you turn this in Optical Interface Classes, you may want to follow 
the example on draft-martinelli-wson-interface-class-02 section 3.2

The Optical Interface Class does not simplify the problem as a whole but 
it will simplify wson protocol extensions. In addition the OIC concept 
is fully compatible with the ITU application code, we spent time 
discussing this but ITU application code is one instance (!) of the 
optical interface class.

Hope this helps

Cheer
G

> 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:
>>
>> 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
>>
>>
>>
>> _______________________________________________
>> CCAMP mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/ccamp
>
>
> -- 
> ===================================================
> Dr Greg Bernstein, Grotto Networking (510) 573-2237
>
>
>
> _______________________________________________
> CCAMP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ccamp

---

From: Greg Bernstein <[email-masked]>
Date: Mon, 09 Jul 2012 08:35:39 -0700

Giovanni, you are still removing specific information that we need to 
determine signal compatibility (modulation type and FEC type).  GMPLS 
RFCs have always been able to deal with incremental advances in 
technology via code point assignment. In addition the drafts provide for 
vendor specific encodings of information.  See below for detailed 
response to your comments.
Greg
On 7/5/2012 5:06 AM, Giovanni MARTINELLI wrote:
> Hi Greg,
>
> pls see my other mail for proposed encoding changes. I'll try to 
> clarify your doubts here below
>
>
--> GMPLS and IETF has dealt with these kind of problems many times. 
This is why code point registries are established with IANA. A new 
technology gets a new code point.
> partitioning you may use. To some extent, the Optical Interface Class 
--->  We started with general 32 bit labels, and then went and 
specialized to SONET/SDH labels, G.709 labels, G.694 labels, etc...
>
> Or if you want a programmer analogy, the Optical Interface Class is 
> like a pointer. Instead of carry around explicit structures you move 
> only pointers (reference to).
---> But this doesn't help interoperability.  Note that we provided a 
general mechanism for modulation types and FEC.
> - what if another FecID (e.g. =11) or an additional Modulation ID 
> (e.g. = 6) is required (i.e. standardized) ? What the impacts on all 
> protocol extensions using  this encoding?
--> Use either (a) the vendor specific encoding format we've provided, 
(b) allocate another code point there are thousands of them available.
> ModulationID? It will never happen in the future?
--> If say some type of Trellis (combined modulation/FEC method) coding 
is used then one can just define the modulation format code points. If 
there are additional ECC options that can go into the FEC code points.  
If this  standardized at ITU. Otherwise you can just use the vendor 
specific encoding method that is provided in the draft.
> The Optical Interface Class does not simplify the problem as a whole 
> but it will simplify wson protocol extensions. In addition the OIC 
> concept is fully compatible with the ITU application code, we spent 
> time discussing this but ITU application code is one instance (!) of 
> the optical interface class.
--> Once again we only extract what is needed for the control plane from 
ITU standards.  For compatibility we still need modulation type (ITU-T's 
optical tributary class) and FEC.
>
> Hope this helps
>
> Cheer
> G
>
>
>
>
>
>
>
>
>
>> If changes are needed we will incorporate them, as we have done in 
>> the past.
>>
>> Best Regards
>> Greg B.
>>> would happen if there is no need to list optical parameters and 
>>> their value.
>>>
>>>
>>> Cheers
>>> G
>>>
>>> Thanks
>>>
>>> Fatai
>>>
>>>
>>>

---

From: Julien Meuric <[email-masked]>
Date: Tue, 10 Jul 2012 12:26:26 +0200

Hi all.

Sorry for interrupting.

 > general mechanism for modulation types and FEC.

Actually, the class approach does simplify the interoperability: instead 
of comparing a set of parameters (including some cross-compatibility 
complexity and the risk of missing some information), an implementation 
only has to match two 32-bit fields. Provided the operator can specify 
the class(es) associated to a given transponder, it just mimics the 
interconnection of 2 identical transmitters as done in real networks.

However, the drawbacks of the class approach do exist:
- from an implementation perspective, the capability to fallback to an 
alternative set of parameters, e.g. a more commonly implemented FEC;
- from the operator's perspective, the visibility on the parameters used 
within protocol analyzing tools, or the capability to be aware of the 
parameter which does not match so as to provision a compatible one.

I believe that behind the technical content of his pragmatic proposal, 
Giovanni is raising an interesting question. We are spending much effort 
on specifying an ideal detailed solution, but will operational people 
(as opposed to protocol engineers) really be bothered by those 
drawbacks? What if the actual maturity and experience (I'm not 
suggesting anything about Giovanni's age!) was to say "over-engineering 
is just bringing material to people you are still questioning the need 
of RSVP-TE signaling in optical networks"? Yes, SRLGs are opaque 
identifiers, but they have already proven to work.
Sometimes, "perfection is attained, not when there is nothing left to 
add, but when there is nothing left to take away..."

Regards,

Julien

---

From: "Ong, Lyndon" <[email-masked]>
Date: Tue, 10 Jul 2012 11:13:03 -0400

Hi Julien,

I think you have captured advantages of the class approach very nicely in your email.  In fact I think even the capability of falling back can be supported in the class approach through indication of multiple classes, since these can reflect alternate sets of parameters that are supported by the source or destination, such as combinations using alternative FECs.

Cheers,

Lyndon

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Julien Meuric
Sent: Tuesday, July 10, 2012 3:26 AM
To: Greg Bernstein
Cc: [email-masked]
Subject: Re: [CCAMP] 答复: 答复: FW: Optical int class, changes to draft-ietf-ccamp-rwa-info-14

Hi all.

Sorry for interrupting.

Regards,

Julien

---

From: "Giovanni Martinelli (giomarti)" <[email-masked]>
Date: Mon, 30 Jul 2012 21:03:04 +0000

Hi Julien,

thx for the very interesting comments, here my late reply... but still in time for ccamp discussion

> alternative set of parameters, e.g. a more commonly implemented FEC;

GM> well replied by Lyndon

> parameter which does not match so as to provision a compatible one.

GM> that's one (among other) concern. The idea was not to hidden parameters but it's a side effect of the approach. For sure the interface class add a level of indirection so has to be decoded in some way.  For the ITU application code case we start proposing such decoding, still a proposal but is step in clarifying this concern.  

> identifiers, but they have already proven to work.

GM> all in all I generally agree with your considerations here (apart from a suspected relationship between "maturity and experience" with "age" :P). Yes the interface class approach is pragmatic but at least allow to decouple protocols  evolution from  "compatibility problem gory details" .  

> add, but when there is nothing left to take away..."

GM> we take away three parameters but we add one, so we are still one parameter away from perfection... sorry for the joke, it's not the beer simply I couldn't resist

Cheers
G