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

"Adrian Farrel" <adrian@olddog.co.uk> Fri, 23 January 2015 18:59 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 791B11ACE32 for <ccamp@ietfa.amsl.com>; Fri, 23 Jan 2015 10:59:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.899
X-Spam-Level:
X-Spam-Status: No, score=-101.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 PBVNhb-AdOXC for <ccamp@ietfa.amsl.com>; Fri, 23 Jan 2015 10:59:22 -0800 (PST)
Received: from asmtp1.iomartmail.com (asmtp1.iomartmail.com [62.128.201.248]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C48111ACE2E for <ccamp@ietf.org>; Fri, 23 Jan 2015 10:59:21 -0800 (PST)
Received: from asmtp1.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id t0NIxE1e013394; Fri, 23 Jan 2015 18:59:15 GMT
Received: from 950129200 (089144209017.atnat0018.highway.a1.net [89.144.209.17]) (authenticated bits=0) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id t0NIx9Hq013374 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Fri, 23 Jan 2015 18:59:10 GMT
From: "Adrian Farrel" <adrian@olddog.co.uk>
To: "'Lam, Hing-Kam \(Kam\)'" <kam.lam@alcatel-lucent.com>, "'Gert Grammel'" <ggrammel@juniper.net>, "'Giovanni Martinelli \(giomarti\)'" <giomarti@cisco.com>
References: <006901d0371a$9e1f1960$da5d4c20$@olddog.co.uk> <8DBC3FDAC14BE441AED9C5939C77758509EE3A6C@US70TWXCHMBA12.zam.alcatel-lucent.com> <BN1PR05MB0411009341243A4FCC26E64CE360@BN1PR05MB041.namprd05.prod.outlook.com> <8DBC3FDAC14BE441AED9C5939C77758509EE3B48@US70TWXCHMBA12.zam.alcatel-lucent.com>
In-Reply-To: <8DBC3FDAC14BE441AED9C5939C77758509EE3B48@US70TWXCHMBA12.zam.alcatel-lucent.com>
Date: Fri, 23 Jan 2015 18:59:08 -0000
Message-ID: <010901d0373e$ac0d7ed0$04287c70$@olddog.co.uk>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_010A_01D0373E.AC1CE820"
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQKAmjcynMdOjxZUzM6y2aNWnfhgwAK7iupBAcWuDJQDAyHmlZsxJSUw
Content-Language: en-gb
X-TM-AS-MML: disable
X-TM-AS-Product-Ver: IMSS-7.1.0.1576-7.5.0.1018-21278.002
X-TM-AS-Result: No--39.203-10.0-31-10
X-imss-scan-details: No--39.203-10.0-31-10
X-TMASE-MatchedRID: CxmI61mtwh+nykMun0J1wuOkx3c0pwugWDdWpJMntKgSYpIWfxKyLEYl +n82wED1Om7tZZlzaJMge8lbIoY9eBac+UrRjxx+l1zsjZ1/6azj5lyuq8IOQTkIJSQdQ27uJMJ XDJjkqdS/jrDM22faPLoWtKVPf8jwzluq0iwuS6glcqT+ugT9EIvIYUxpc3wMa0TOsL14A2nBux 0R7Q0FJ5RUdkJMj3T0WfvheV6pyrREydReAd9gkJEbNXwHGDRxhHz3EzK//HzaqqH/oHw+kQUfw BgmtWYiKOlw30dgDcXmbW1ULHbdKOdv6cWcdrc0UKL/EMdwPN8+WWrj7s+yn+QydRUvl3QTWbzY 4GA2m4vV7Iumy7in0rchJ4qPggEg/ZNpyV8TXRozSlmIs9AhOm79evoIpeI3cf40lLKqPGMJH1L SVN31mW986exXflOnvO0K1FolbmBj5V+yyEyAremc4/pDEQa2jLOy13Cgb4+e9toQ6h6LE3v4ix lgc06fUN8dQnEOEkp3Vf2l/e+4VUWzDYun6RK4y7TSWcbz49bAWTziWGaDPJ2Vet7Q0hBwmOPy3 Gh6CrTUywZycJ7xGUXkE84/COkUtzBuLRbw+9Mk78SxLKShoOdJKF0CJUbKK6rsMmth5SZxtyA5 JI+wF59S3YgdG3IH1eeaKehxgUJjjEH+RszpJnH7HV/mO4UTaBTWjXFXXd9Ev26FkhjLXcrpBMu iQ/7mrDHUBm6rZ1QhIMlpP/jXw2uCdtCAow1/71Wx2uUbPLdBldmDYjwlpqFSh25xC7TpBixx3l Aro9cSDdG85CKy5pYlxuk1ogQA00ktvTk0SGmeAiCmPx4NwGmRqNBHmBvevqq8s2MNhPDPPeN6H N6d7P9SXNGQ0BxJVnRXm1iHN1Yj80Za3RRg8MQRSEWfQ5f/J0T393oKtIUuNbyaLtDrlDTEQRh+ 4EYgq4X/HlZlHuc=
Archived-At: <http://mailarchive.ietf.org/arch/msg/ccamp/pndJTGH1cLA6gZT4WtzC2H-hd88>
Cc: "'Doolan, Paul \(Coriant - US/Irving\)'" <paul.doolan@coriant.com>, 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
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 18:59:28 -0000

Thanks for being awake, Kam.
 
Useful info.
 
Gert, the OUI registry is an IEEE registry as Kam says. IANA has a registry page
for this, but it points to the IEEE page.
 
As I understand Kam, 874.1 is not yet updated so it would be premature to point
to it, but an option is to attempt to match it now and fix later if needed.
 
Adrian
 
From: Lam, Hing-Kam (Kam) [mailto:kam.lam@alcatel-lucent.com] 
Sent: 23 January 2015 17:10
To: Gert Grammel; 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 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; '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; 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
 
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