[CCAMP] Vendor-Specific Application Code in draft-ietf-ccamp-rwa-wson-encode
"Adrian Farrel" <adrian@olddog.co.uk> Fri, 23 January 2015 14:41 UTC
Return-Path: <adrian@olddog.co.uk>
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 1EF091A90C8 for <ccamp@ietfa.amsl.com>; Fri, 23 Jan 2015 06:41:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.9
X-Spam-Level:
X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, USER_IN_WHITELIST=-100] 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 RCGQbmukkZyv for <ccamp@ietfa.amsl.com>; Fri, 23 Jan 2015 06:41:17 -0800 (PST)
Received: from asmtp3.iomartmail.com (asmtp3.iomartmail.com [62.128.201.159]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3E52B1A90BA for <ccamp@ietf.org>; Fri, 23 Jan 2015 06:41:17 -0800 (PST)
Received: from asmtp3.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id t0NEf6Wf032241; Fri, 23 Jan 2015 14:41:06 GMT
Received: from 950129200 (089144224197.atnat0033.highway.a1.net [89.144.224.197]) (authenticated bits=0) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id t0NEeuPo032118 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Fri, 23 Jan 2015 14:41:04 GMT
From: Adrian Farrel <adrian@olddog.co.uk>
To: "'Giovanni Martinelli (giomarti)'" <giomarti@cisco.com>
Date: Fri, 23 Jan 2015 14:40:50 -0000
Message-ID: <006901d0371a$9e1f1960$da5d4c20$@olddog.co.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AdA3F39rUe0sT3nBRieZEz+A1ksBgQ==
Content-Language: en-gb
X-TM-AS-MML: disable
X-TM-AS-Product-Ver: IMSS-7.1.0.1576-7.5.0.1018-21276.004
X-TM-AS-Result: No--31.626-10.0-31-10
X-imss-scan-details: No--31.626-10.0-31-10
X-TMASE-MatchedRID: Qy8IQnwT72Q/FLJq3yHG9WzBijri5+RVJNroBaGZ+LW9K1jOJyKSa/U7 2nYVxvYN1eyLpsu4p9K3ISeKj4IBIP2TaclfE10aM0pZiLPQITpu/Xr6CKXiN3H+NJSyqjxjbyq cWT4FZRczkTO9kPlpFpPrkLG7Agm3ZF6ysdFjt0rx5KZMlKYS/VHewY36PuY0B6d3D+KIwZDxy/ H5BGyr4qpoI0gyGMJQ9AaJ/rCyiU1CzHFhiypoVppWgCLYjjT9Q95F2IiVUkT1bGUO+1Pc3KkLY bIpdhDAHIHA2mx0ec9Fcy9Xm9K+Vev0250SgRWKJMk7xo92oCX4uJ1REX4MHY/ysyGl2pMecQ2N 8UBEvedi4EZZUzX5yFpPtNJoAeE25lAcvk44nZXoe5XUFQlg8x7aUJN4PKIOfeHPnu31iHAEhlb ld58ez/Kw46gg+NH67QcXuKn618HpzoZfJABOunH7HV/mO4UTaBTWjXFXXd9Ev26FkhjLXcrpBM uiQ/7mrDHUBm6rZ1QhIMlpP/jXw2uCdtCAow1/71Wx2uUbPLdBldmDYjwlpqFSh25xC7TpBixx3 lAro9f8bQRM2WaSHJGTpe1iiCJqtD9qpBlNF8o/vucGn10dpvoA9r2LThYYKrauXd3MZDUD/dHy T/Xh7Q==
Archived-At: <http://mailarchive.ietf.org/arch/msg/ccamp/OCSENA4QvyxNgn2B56yyXLHmF6w>
Cc: ccamp@ietf.org, ccamp-chairs@tools.ietf.org, draft-ietf-ccamp-rwa-wson-encode.all@tools.ietf.org
Subject: [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
Reply-To: adrian@olddog.co.uk
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 14:41:20 -0000
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] Vendor-Specific Application Code in draft… Adrian Farrel
- Re: [CCAMP] Vendor-Specific Application Code in d… Lam, Hing-Kam (Kam)
- Re: [CCAMP] Vendor-Specific Application Code in d… Gert Grammel
- Re: [CCAMP] Vendor-Specific Application Code in d… Lam, Hing-Kam (Kam)
- Re: [CCAMP] Vendor-Specific Application Code in d… Leeyoung
- Re: [CCAMP] Vendor-Specific Application Code in d… Lou Berger
- Re: [CCAMP] Vendor-Specific Application Code in d… Adrian Farrel
- Re: [CCAMP] Vendor-Specific Application Code in d… Adrian Farrel
- Re: [CCAMP] Vendor-Specific Application Code in d… Lam, Hing-Kam (Kam)
- Re: [CCAMP] Vendor-Specific Application Code in d… BRUNGARD, DEBORAH A
- Re: [CCAMP] Vendor-Specific Application Code in d… Leeyoung
- Re: [CCAMP] Vendor-Specific Application Code in d… BRUNGARD, DEBORAH A
- Re: [CCAMP] Vendor-Specific Application Code in d… Leeyoung
- Re: [CCAMP] Vendor-Specific Application Code in d… Varma, Eve L (Eve)
- Re: [CCAMP] Vendor-Specific Application Code in d… Adrian Farrel
- Re: [CCAMP] Vendor-Specific Application Code in d… Leeyoung
- Re: [CCAMP] Vendor-Specific Application Code in d… Doolan, Paul (Coriant - US/Irving)
- Re: [CCAMP] Vendor-Specific Application Code in d… Fatai Zhang
- Re: [CCAMP] Vendor-Specific Application Code in d… Dieter Beller
- Re: [CCAMP] Vendor-Specific Application Code in d… Adrian Farrel
- Re: [CCAMP] Vendor-Specific Application Code in d… Huub van Helvoort
- Re: [CCAMP] Vendor-Specific Application Code in d… Leeyoung
- Re: [CCAMP] Vendor-Specific Application Code in d… Lou Berger
- Re: [CCAMP] Vendor-Specific Application Code in d… Gert Grammel
- Re: [CCAMP] Vendor-Specific Application Code in d… Gabriele Maria Galimberti (ggalimbe)
- Re: [CCAMP] Vendor-Specific Application Code in d… Zhangxian (Xian)
- Re: [CCAMP] Vendor-Specific Application Code in d… Lou Berger
- Re: [CCAMP] Vendor-Specific Application Code in d… Daniele Ceccarelli
- Re: [CCAMP] Vendor-Specific Application Code in d… Adrian Farrel
- Re: [CCAMP] Vendor-Specific Application Code in d… Lou Berger
- Re: [CCAMP] Vendor-Specific Application Code in d… Leeyoung
- Re: [CCAMP] Vendor-Specific Application Code in d… Leeyoung
- Re: [CCAMP] Vendor-Specific Application Code in d… Daniele Ceccarelli
- Re: [CCAMP] Vendor-Specific Application Code in d… Leeyoung
- Re: [CCAMP] Vendor-Specific Application Code in d… Adrian Farrel