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