Re: [CCAMP] Vendor-Specific Application Code in draft-ietf-ccamp-rwa-wson-encode
"Lam, Hing-Kam (Kam)" <kam.lam@alcatel-lucent.com> Fri, 23 January 2015 17:09 UTC
Return-Path: <kam.lam@alcatel-lucent.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 16A9F1A8BC2 for <ccamp@ietfa.amsl.com>; Fri, 23 Jan 2015 09:09:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.909
X-Spam-Level:
X-Spam-Status: No, score=-6.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, 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 F6Wnkk_nWwqZ for <ccamp@ietfa.amsl.com>; Fri, 23 Jan 2015 09:09:41 -0800 (PST)
Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 00FAA1A1ADB for <ccamp@ietf.org>; Fri, 23 Jan 2015 09:09:39 -0800 (PST)
Received: from us70uusmtp4.zam.alcatel-lucent.com (unknown [135.5.2.66]) by Websense Email Security Gateway with ESMTPS id 3110DF77A8B36; Fri, 23 Jan 2015 17:09:33 +0000 (GMT)
Received: from US70UWXCHHUB02.zam.alcatel-lucent.com (us70uwxchhub02.zam.alcatel-lucent.com [135.5.2.49]) by us70uusmtp4.zam.alcatel-lucent.com (GMO) with ESMTP id t0NH9YrI006912 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 23 Jan 2015 12:09:34 -0500
Received: from US70TWXCHMBA12.zam.alcatel-lucent.com ([169.254.6.168]) by US70UWXCHHUB02.zam.alcatel-lucent.com ([135.5.2.49]) with mapi id 14.03.0195.001; Fri, 23 Jan 2015 12:09:34 -0500
From: "Lam, Hing-Kam (Kam)" <kam.lam@alcatel-lucent.com>
To: Gert Grammel <ggrammel@juniper.net>, "adrian@olddog.co.uk" <adrian@olddog.co.uk>, "'Giovanni Martinelli (giomarti)'" <giomarti@cisco.com>
Thread-Topic: [CCAMP] Vendor-Specific Application Code in draft-ietf-ccamp-rwa-wson-encode
Thread-Index: AQHQNyyAQjVyuIZDVkicZ67yfGpHF5zN7BoA
Date: Fri, 23 Jan 2015 17:09:33 +0000
Message-ID: <8DBC3FDAC14BE441AED9C5939C77758509EE3B48@US70TWXCHMBA12.zam.alcatel-lucent.com>
References: <006901d0371a$9e1f1960$da5d4c20$@olddog.co.uk> <8DBC3FDAC14BE441AED9C5939C77758509EE3A6C@US70TWXCHMBA12.zam.alcatel-lucent.com> <BN1PR05MB0411009341243A4FCC26E64CE360@BN1PR05MB041.namprd05.prod.outlook.com>
In-Reply-To: <BN1PR05MB0411009341243A4FCC26E64CE360@BN1PR05MB041.namprd05.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [135.5.27.18]
Content-Type: multipart/alternative; boundary="_000_8DBC3FDAC14BE441AED9C5939C77758509EE3B48US70TWXCHMBA12z_"
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/ccamp/NQMMMhu5gRmiQ6rX4MZnvyFCLMQ>
Cc: "Doolan, Paul (Coriant - US/Irving)" <paul.doolan@coriant.com>, "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:09:48 -0000
Hi Gert, A vendor can purchase an OUI (Organizationally Unique Identifier) from the IEEE Registration Authority. Once a vendor has its OUI, the vendor can manage its vendor-specific application identifiers under its own OUI. SG15 doesn't need to host any registry for this purpose. Regards, Kam From: Gert Grammel [mailto:ggrammel@juniper.net] Sent: Friday, January 23, 2015 11:49 AM To: Lam, Hing-Kam (Kam); adrian@olddog.co.uk; 'Giovanni Martinelli (giomarti)' Cc: Doolan, Paul (Coriant - US/Irving); ccamp@ietf.org; ccamp-chairs@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 Hi Kam, Is SG15 considering to host a registry for the vendor specific application code or is the IETF registry supposed to be used? Thanks Gert From: CCAMP [mailto:ccamp-bounces@ietf.org] On Behalf Of Lam, Hing-Kam (Kam) Sent: 23 January 2015 17:03 To: adrian@olddog.co.uk<mailto:adrian@olddog.co.uk>; 'Giovanni Martinelli (giomarti)' Cc: Doolan, Paul (Coriant - US/Irving); ccamp@ietf.org<mailto:ccamp@ietf.org>; ccamp-chairs@tools.ietf.org<mailto:ccamp-chairs@tools.ietf.org>; draft-ietf-ccamp-rwa-wson-encode.all@tools.ietf.org<mailto:draft-ietf-ccamp-rwa-wson-encode.all@tools.ietf.org> Subject: Re: [CCAMP] Vendor-Specific Application Code in draft-ietf-ccamp-rwa-wson-encode Dear all, For your information. In the last SG15 meeting, Q14/15 agreed to update G.874.1 to amend the specification of ApplicationIdentifier with the following additional text: If the ApplicationIdentifierType is STANDARD, the value of PrintableString represents a standard application code as defined in the ITU-T Recommendations. If the ApplicationIdentifierType is PROPRIETARY, the first six characters of the PrintableString must contain the Hexadecimal representation of an OUI assigned to the vendor whose implementation generated the Application Identifier; the remaining octets of the PrintableString are unspecified. Paul Doolan had an I-D "https://tools.ietf.org/html/draft-doolan-proprietary-ac-00" to the last IETF meeting with the similar proposal. Regards, Kam -----Original Message----- From: CCAMP [mailto:ccamp-bounces@ietf.org] On Behalf Of Adrian Farrel Sent: Friday, January 23, 2015 9:41 AM To: 'Giovanni Martinelli (giomarti)' Cc: ccamp@ietf.org<mailto:ccamp@ietf.org>; ccamp-chairs@tools.ietf.org<mailto:ccamp-chairs@tools.ietf.org>; draft-ietf-ccamp-rwa-wson-encode.all@tools.ietf.org<mailto:draft-ietf-ccamp-rwa-wson-encode.all@tools.ietf.org> Subject: [CCAMP] 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<mailto:adrian@olddog.co.uk> > Cc: Leeyoung; draft-ietf-ccamp-rwa-wson-encode.all@tools.ietf.org<mailto:draft-ietf-ccamp-rwa-wson-encode.all@tools.ietf.org>; > ccamp@ietf.org<mailto:ccamp@ietf.org>; ccamp-chairs@tools.ietf.org<mailto: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<mailto:giomarti@cisco.com>> > wrote: > > > Hi Adrian, > > > > On 21 Jan 2015, at 22:55, Adrian Farrel <adrian@olddog.co.uk<mailto: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<mailto:adrian@olddog.co.uk> > >>> Cc: Leeyoung; draft-ietf-ccamp-rwa-wson-encode.all@tools.ietf.org<mailto:draft-ietf-ccamp-rwa-wson-encode.all@tools.ietf.org>; > >>> ccamp@ietf.org<mailto:ccamp@ietf.org>; ccamp-chairs@tools.ietf.org<mailto: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<mailto: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<mailto:CCAMP@ietf.org> https://www.ietf.org/mailman/listinfo/ccamp
- [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