Re: [CCAMP] Vendor-Specific Application Code in draft-ietf-ccamp-rwa-wson-encode

["Gabriele Maria Galimberti (ggalimbe)" <[e-mail]>]

Hi All, 

I'm in favour of option 2 as well.

I'd like to note that there are other drafts in ccamp that may be affected
by this change:
- draft-galikunze-ccamp-g-698-2-snmp-mib
- draft-dharinigert-ccamp-g-698-2-lmp
- draft-dharini-netmod-g-698-2-yang

I'm co-author of them and as such I'll coordinate with the other authors
to fix the drafts.

Best Regards, 

Gabriele


Gabriele Galimberti
Technical Leader
Cisco Photonics Srl



via S.Maria Molgora, 48 C
20871 - Vimercate (MB)
Italy
www.cisco.com/global/IT/ <http://www.cisco.com/global/IT/>

[e-mail]
Phone :[phone]
Mobile :[phone]
Fax :[phone]















On 1/29/15 2:23 PM, "Adrian Farrel" <[e-mail]> wrote:

>Hi again,
>
>> There is always a priori knowledge in optical network domain as to who
>> are you interfacing with. So you know which vendor you are interfacing.
>> If you do not know, then you are in trouble.
>
>Hmmm. It is exactly type of trouble we are trying to detect and protect
>against.
>
>I refute your statement of a priori knowledge. I think there is a priori
>intention, but not knowledge. Unless you have very good eyesight or
>someone at the other end of the fiber when you give it a tug, you don't
>know. And even then. Fibering errors happen from time to time. Consider,
>in particular a patch panel.
>
>> Now, what is the purpose of standard FECs and modulations in the AI?
>>Given
>> several choices each vendor may support in its device, the path
>>computation
>> would find a matched types for FEC and modulation for a given optical
>>path. 
>> This is what is intended when optical signal processing constraints
>>were 
>> proposed as part of path computation constraints in optical networks.
>
>
>The case you are making here is for no standard control plane!
>What is the point of standardising if there is never any interworking?
>But actually, we know about interworking at the physical layer, and (more
>important) we know about a single, end-to-end control plane that spans
>multiple vendor devices. It all exists.
>
>Of course, we can fall back into the old-style vendor islands, and many
>like to do so. But it is not a compulsory deployment model.
>
>> There is very little chance for vendor specific FECs and Modulations
>>will match
>> even if they are identified with the OUI code.
>
>You have it the wrong way round!
>The OUI is largely to protect against expectations of interworking when
>none can exist.
>It might (much less frequently) be used to describe the way that vendorA
>and vendorB pick FECs and modulations in order to achieve interworking.
>
>Adrian
>
>_______________________________________________
>CCAMP mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/ccamp