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

Lou Berger <lberger@labn.net> Fri, 23 January 2015 17:24 UTC

Return-Path: <lberger@labn.net>
X-Original-To: ccamp@ietfa.amsl.com
Delivered-To: ccamp@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DADF11ABD36 for <ccamp@ietfa.amsl.com>; Fri, 23 Jan 2015 09:24:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.278
X-Spam-Level:
X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_BIZ=0.288, IP_NOT_FRIENDLY=0.334] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XuquAFnSdtUQ for <ccamp@ietfa.amsl.com>; Fri, 23 Jan 2015 09:24:45 -0800 (PST)
Received: from newdragon.webhostserver.biz (newdragon.webhostserver.biz [69.25.136.252]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EB5881A886D for <ccamp@ietf.org>; Fri, 23 Jan 2015 09:24:35 -0800 (PST)
Received: from localhost ([::1]:38918) by newdragon.webhostserver.biz with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.84) (envelope-from <lberger@labn.net>) id 1YEhyE-0005Li-3J; Fri, 23 Jan 2015 20:24:34 +0300
Message-ID: <54C283CD.7030003@labn.net>
Date: Fri, 23 Jan 2015 12:24:29 -0500
From: Lou Berger <lberger@labn.net>
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0
MIME-Version: 1.0
To: Leeyoung <leeyoung@huawei.com>, "adrian@olddog.co.uk" <adrian@olddog.co.uk>, "'Giovanni Martinelli (giomarti)'" <giomarti@cisco.com>
References: <006901d0371a$9e1f1960$da5d4c20$@olddog.co.uk> <7AEB3D6833318045B4AE71C2C87E8E1729C7E09C@dfweml706-chm>
In-Reply-To: <7AEB3D6833318045B4AE71C2C87E8E1729C7E09C@dfweml706-chm>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - newdragon.webhostserver.biz
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - labn.net
X-Get-Message-Sender-Via: newdragon.webhostserver.biz: authenticated_id: lberger@blabn.com
X-Source:
X-Source-Args:
X-Source-Dir:
Archived-At: <http://mailarchive.ietf.org/arch/msg/ccamp/8ShDc9HvzgF2dpSbhWvxiQBMew8>
Cc: "ccamp@ietf.org" <ccamp@ietf.org>, "ccamp-chairs@tools.ietf.org" <ccamp-chairs@tools.ietf.org>, "draft-ietf-ccamp-rwa-wson-encode.all@tools.ietf.org" <draft-ietf-ccamp-rwa-wson-encode.all@tools.ietf.org>
Subject: Re: [CCAMP] Vendor-Specific Application Code in draft-ietf-ccamp-rwa-wson-encode
X-BeenThere: ccamp@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Discussion list for the CCAMP working group <ccamp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ccamp>, <mailto:ccamp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ccamp/>
List-Post: <mailto:ccamp@ietf.org>
List-Help: <mailto:ccamp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ccamp>, <mailto:ccamp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 23 Jan 2015 17:24:48 -0000

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:adrian@olddog.co.uk] 
> Sent: Friday, January 23, 2015 8:41 AM
> To: 'Giovanni Martinelli (giomarti)'
> Cc: Leeyoung; draft-ietf-ccamp-rwa-wson-encode.all@tools.ietf.org; ccamp@ietf.org; ccamp-chairs@tools.ietf.org
> 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:giomarti@cisco.com]
>> Sent: 23 January 2015 13:50
>> To: adrian@olddog.co.uk
>> Cc: Leeyoung; draft-ietf-ccamp-rwa-wson-encode.all@tools.ietf.org;
>> ccamp@ietf.org; ccamp-chairs@tools.ietf.org
>> 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) <giomarti@cisco.com>
>> wrote:
>>
>>> Hi Adrian,
>>>
>>> On 21 Jan 2015, at 22:55, Adrian Farrel <adrian@olddog.co.uk> 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:giomarti@cisco.com]
>>>>> Sent: 21 January 2015 21:22
>>>>> To: adrian@olddog.co.uk
>>>>> Cc: Leeyoung; draft-ietf-ccamp-rwa-wson-encode.all@tools.ietf.org;
>>>>> ccamp@ietf.org; ccamp-chairs@tools.ietf.org
>>>>> 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 <adrian@olddog.co.uk> 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
> CCAMP@ietf.org
> https://www.ietf.org/mailman/listinfo/ccamp
>