Re: [CCAMP] Vendor-Specific Application Code in draft-ietf-ccamp-rwa-wson-encode
Gert Grammel <ggrammel@juniper.net> Fri, 23 January 2015 16:49 UTC
Return-Path: <ggrammel@juniper.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 472591A87AC for <ccamp@ietfa.amsl.com>; Fri, 23 Jan 2015 08:49:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] 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 pn0dYO-j7pbf for <ccamp@ietfa.amsl.com>; Fri, 23 Jan 2015 08:49:05 -0800 (PST)
Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0135.outbound.protection.outlook.com [65.55.169.135]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1473B1A1AD8 for <ccamp@ietf.org>; Fri, 23 Jan 2015 08:49:05 -0800 (PST)
Received: from BN1PR05MB041.namprd05.prod.outlook.com (10.255.202.140) by BN1PR05MB041.namprd05.prod.outlook.com (10.255.202.140) with Microsoft SMTP Server (TLS) id 15.1.65.19; Fri, 23 Jan 2015 16:49:03 +0000
Received: from BN1PR05MB041.namprd05.prod.outlook.com ([169.254.14.136]) by BN1PR05MB041.namprd05.prod.outlook.com ([169.254.14.136]) with mapi id 15.01.0065.013; Fri, 23 Jan 2015 16:49:03 +0000
From: Gert Grammel <ggrammel@juniper.net>
To: "Lam, Hing-Kam (Kam)" <kam.lam@alcatel-lucent.com>, "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: AQHQNyYVlxw97EbEt0aRBiXb7/iXxZzN6Tng
Date: Fri, 23 Jan 2015 16:49:03 +0000
Message-ID: <BN1PR05MB0411009341243A4FCC26E64CE360@BN1PR05MB041.namprd05.prod.outlook.com>
References: <006901d0371a$9e1f1960$da5d4c20$@olddog.co.uk> <8DBC3FDAC14BE441AED9C5939C77758509EE3A6C@US70TWXCHMBA12.zam.alcatel-lucent.com>
In-Reply-To: <8DBC3FDAC14BE441AED9C5939C77758509EE3A6C@US70TWXCHMBA12.zam.alcatel-lucent.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [193.110.55.14]
authentication-results: alcatel-lucent.com; dkim=none (message not signed) header.d=none; alcatel-lucent.com; dmarc=none action=none header.from=juniper.net;
x-dmarcaction-test: None
x-microsoft-antispam: BCL:0;PCL:0;RULEID:(3005004);SRVR:BN1PR05MB041;
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:;SRVR:BN1PR05MB041;
x-forefront-prvs: 0465429B7F
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(377454003)(51704005)(13464003)(164054003)(24454002)(2950100001)(2900100001)(19300405004)(19625215002)(102836002)(15975445007)(76176999)(19609705001)(50986999)(54356999)(54606007)(33656002)(19580395003)(561944003)(19580405001)(86362001)(46102003)(92566002)(99286002)(106116001)(54206007)(230783001)(2656002)(87936001)(2501002)(16236675004)(40100003)(77156002)(62966003)(76576001)(66066001)(74316001)(122556002)(19617315012); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1PR05MB041; H:BN1PR05MB041.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en;
Content-Type: multipart/alternative; boundary="_000_BN1PR05MB0411009341243A4FCC26E64CE360BN1PR05MB041namprd_"
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Jan 2015 16:49:03.3096 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN1PR05MB041
Archived-At: <http://mailarchive.ietf.org/arch/msg/ccamp/YURj9sKjn1mzJk5ba3I87OXKPmw>
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 16:49:09 -0000
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; '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 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