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

["Lam, Hing-Kam (Kam)" <[e-mail]>]

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:[e-mail]]
Sent: Friday, January 23, 2015 11:49 AM
To: Lam, Hing-Kam (Kam); [e-mail]; 'Giovanni Martinelli (giomarti)'
Cc: Doolan, Paul (Coriant - US/Irving); [e-mail]; [e-mail]; [e-mail]
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:[e-mail]] On Behalf Of Lam, Hing-Kam (Kam)
Sent: 23 January 2015 17:03
To: [e-mail]<mailto:[e-mail]>; 'Giovanni Martinelli (giomarti)'
Cc: Doolan, Paul (Coriant - US/Irving); [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
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:[e-mail]] On Behalf Of Adrian Farrel

Sent: Friday, January 23, 2015 9:41 AM

To: 'Giovanni Martinelli (giomarti)'

Cc: [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>

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:[e-mail]]

> Sent: 23 January 2015 13:50

> To: [e-mail]<mailto:[e-mail]>

> Cc: Leeyoung; [e-mail]<mailto:[e-mail]>;

> [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>

> 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)

> <[e-mail]<mailto:[e-mail]>>

> wrote:

>

> > Hi Adrian,

> >

> > On 21 Jan 2015, at 22:55, Adrian Farrel <[e-mail]<mailto:[e-mail]>> 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:[e-mail]]

> >>> Sent: 21 January 2015 21:22

> >>> To: [e-mail]<mailto:[e-mail]>

> >>> Cc: Leeyoung; [e-mail]<mailto:[e-mail]>;

> >>> [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>

> >>> 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 <[e-mail]<mailto:[e-mail]>> 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

[e-mail]<mailto:[e-mail]>

https://www.ietf.org/mailman/listinfo/ccamp