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

Leeyoung <leeyoung@huawei.com> Fri, 23 January 2015 17:17 UTC

Return-Path: <leeyoung@huawei.com>
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 7CEBF1A883E for <ccamp@ietfa.amsl.com>; Fri, 23 Jan 2015 09:17:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.21
X-Spam-Level:
X-Spam-Status: No, score=-3.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
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 UQCSx4Q8vuBn for <ccamp@ietfa.amsl.com>; Fri, 23 Jan 2015 09:17:41 -0800 (PST)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D2D3E1A1B06 for <ccamp@ietf.org>; Fri, 23 Jan 2015 09:17:40 -0800 (PST)
Received: from 172.18.7.190 (EHLO lhreml405-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BRR16587; Fri, 23 Jan 2015 17:17:39 +0000 (GMT)
Received: from DFWEML704-CHM.china.huawei.com (10.193.5.141) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 23 Jan 2015 17:17:38 +0000
Received: from DFWEML706-CHM.china.huawei.com ([10.193.5.225]) by dfweml704-chm ([10.193.5.141]) with mapi id 14.03.0158.001; Fri, 23 Jan 2015 09:17:36 -0800
From: Leeyoung <leeyoung@huawei.com>
To: "adrian@olddog.co.uk" <adrian@olddog.co.uk>, "'Giovanni Martinelli (giomarti)'" <giomarti@cisco.com>
Thread-Topic: Vendor-Specific Application Code in draft-ietf-ccamp-rwa-wson-encode
Thread-Index: AdA3F39rUe0sT3nBRieZEz+A1ksBgQAGKR1A
Date: Fri, 23 Jan 2015 17:17:35 +0000
Message-ID: <7AEB3D6833318045B4AE71C2C87E8E1729C7E09C@dfweml706-chm>
References: <006901d0371a$9e1f1960$da5d4c20$@olddog.co.uk>
In-Reply-To: <006901d0371a$9e1f1960$da5d4c20$@olddog.co.uk>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.192.11.120]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <http://mailarchive.ietf.org/arch/msg/ccamp/oej7i8tMpyhr8fQl1d1Vw_yDD-M>
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:17:43 -0000

Hi,

Thanks Adrian for taking this on. 

My preference is Option 1. 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?
> >>
> >