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

[Lou Berger <[e-mail]>]

On 1/23/2015 12:17 PM, Leeyoung wrote:
> Hi,
>
> Thanks Adrian for taking this on. 
>
> My preference is Option 1. 
Thanks Young.

My memory is that this was the intent of the WG at the time this point
was discussed. So, I also prefer/support option 1.

Lou

> It would be hard to catch moving target around this area if we were to take Option 2. 
>
> Thanks,
> Young
>
> -----Original Message-----
> From: Adrian Farrel [mailto:[e-mail]] 
> Sent: Friday, January 23, 2015 8:41 AM
> To: 'Giovanni Martinelli (giomarti)'
> Cc: Leeyoung; [e-mail]; [e-mail]; [e-mail]
> Subject: Vendor-Specific Application Code in draft-ietf-ccamp-rwa-wson-encode
>
> Hi,
>
> I appreciate this discussion, but I am not seeing a specific conclusion from it.
>
> The current I-D makes (IMHO) the Vendor-Specific Application Code unusable. I
> offered three options:
>
> 1 This value is only to be used when it is known that all devices
>    participating in a network have the same understanding of 
>    the content of the Vendor-Specific Application Code field.
>    How this knowledge is achieved is outside the scope of this
>    document
>
> 2 When this value is set, the first 32 (or 48) bits of the Vendor-
>   Specific Application Code field contain an Enterprise Number
>   (or OUI) that defines the context in which the remainder of
>   that field is interpreted.
>
> 3 Remove the option to include a Vendor-Specific Application
>    Code field.
>
> If the WG could please pick one of these and help Young to update the document.
>
> Thanks,
> Adrian
>
>> -----Original Message-----
>> From: Giovanni Martinelli (giomarti) [mailto:[e-mail]]
>> Sent: 23 January 2015 13:50
>> To: [e-mail]
>> Cc: Leeyoung; [e-mail];
>> [e-mail]; [e-mail]
>> Subject: Re: [CCAMP] AD review of draft-ietf-ccamp-rwa-wson-encode
>>
>> One additional comment (hoping not additional confusion).
>>
>> The idea about Optical Interface Class was taken from SRLG. Good or bad is a
>> plain number and you do simple operations on it.
>>
>> Cheers
>> G
>>
>> On 22 Jan 2015, at 09:42, Giovanni Martinelli (giomarti) <[e-mail]>
>> wrote:
>>
>>> Hi Adrian,
>>>
>>> On 21 Jan 2015, at 22:55, Adrian Farrel <[e-mail]> wrote:
>>>
>>>> Hi,
>>>>
>>>> Well, you seem to have a half-way house.
>>>>
>>>> You have specified the existence of a thing, but not how to read it.
>>>>
>>>> If you wanted to make a statement that this object will only be used when
> it is
>>>> known that all systems in a network come from the same vendor and/or have
>> the
>>>> same understanding of the encoding, that might be OK (although how you
>> would
>>>> ascertain this might also need to be described).
>>>>
>>> The statement is to ensure the interface compatibility without encoding all
> the
>> possible details and parameter that define an interface (e.g. modulation
> format,
>> forward error correction etc.). This was the initial solution in the draft
> then
>> replaced by the interface class concept.   The WSON (RWA-only) has the
>> requirement is to make sure two interface are compatible. This requirement,
>> imho, can be satisfy by a simple comparison which has a boolean result.
>>> We end up then in  the ITU application codes for the "certified" (we'll this
> is my
>> term not 100% sure is the best one) compatibility where proper encoding is
>> provided.
>>>
>>>> Or you could entirely remove the vendor-specific option.
>>>>
>>>> Or you could put in an OUI / enterprise number followed by transparent
>> bytes.
>>> To me I'm perfectly fine with the second option.
>>>
>>> Cheers
>>> G
>>>
>>>
>>>> Adrian
>>>>
>>>>> -----Original Message-----
>>>>> From: Giovanni Martinelli (giomarti) [mailto:[e-mail]]
>>>>> Sent: 21 January 2015 21:22
>>>>> To: [e-mail]
>>>>> Cc: Leeyoung; [e-mail];
>>>>> [e-mail]; [e-mail]
>>>>> Subject: Re: [CCAMP] AD review of draft-ietf-ccamp-rwa-wson-encode
>>>>>
>>>>> Specifically to the Interface class here below.
>>>>>
>>>>> In the initial draft merged to this one there was the usage of OUI however
> (I
>>>>> guess after chatting with Lou) we decided to remove any encoding when the
>>>>> Interface class is not standard.
>>>>> In term of semantic the protcol does not need to decode the Interface
> class
>>>> since
>>>>> it only assess the interface compatibility if two interfaces has a class
> value
>>>> that
>>>>> match two interfaces cann be connected.
>>>>>
>>>>> Having saying that I don't have strong opinion in adding the OUI or
> leaving
>>>> room
>>>>> for maybe future public interfaces database. For sure there's a need to
> leave
>>>>> room for specific compatibility assesment since there optical multivendor
>>>>> compatibility has been already demonstrated.
>>>>>
>>>>> hope this help .
>>>>>
>>>>> Cheers
>>>>> G
>>>>>
>>>>>
>>>>> On 21 Jan 2015, at 21:57, Adrian Farrel <[e-mail]> wrote:
>>>>>
>>>>>>>> Section 4.1
>>>>>>>> How do I interpret a Vendor-Specific Application Code? Is there an OUI
>>>>>>>> I'm missing?
>>>>>>> [YOUNG] Not sure if I understood this question. What is "OUI"?
>>>>>> http://en.wikipedia.org/wiki/Organizationally_unique_identifier
>>>>>> http://www.iana.org/assignments/ieee-802-numbers/ieee-802-
>>>>> numbers.xhtml#ieee-802
>>>>>> -numbers-2
>>>>>>
>>>>>> Or perhaps an Enterprise Number
>>>>>> http://www.iana.org/assignments/enterprise-numbers/enterprise-
>> numbers
>>>>>> The question is:
>>>>>>
>>>>>> You have sections 4.1.1 through 4.1.4 to tell me how to interpret the
>>>> Optical
>>>>>> Interface Class field when it contains an ITU-T Application Mapping.
>>>>>> When I received s=0 and OI=1 it means that the Optical Interface Class
>>>> contains
>>>>>> a "Vendor Specific Optical Interface Class".
>>>>>> How do I interpret that Optical Interface Class?
>>>>>> Which vendor does it apply to?
>>>>>> Is there some information elsewhere that gives me a clue as to which
>> vendor
>>>>> has
>>>>>> encoded the information?
>>>>>> Or is the information supposed to be encoded in the Optical Interface
> Class,
>>>>>> perhaps as the first 48 bits?
>>>>>> Or am I supposed to know by context?
> _______________________________________________
> CCAMP mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ccamp
>