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

"Adrian Farrel" <adrian@olddog.co.uk> Fri, 23 January 2015 14:41 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 1EF091A90C8 for <ccamp@ietfa.amsl.com>; Fri, 23 Jan 2015 06:41:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.9
X-Spam-Level:
X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 RCGQbmukkZyv for <ccamp@ietfa.amsl.com>; Fri, 23 Jan 2015 06:41:17 -0800 (PST)
Received: from asmtp3.iomartmail.com (asmtp3.iomartmail.com [62.128.201.159]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3E52B1A90BA for <ccamp@ietf.org>; Fri, 23 Jan 2015 06:41:17 -0800 (PST)
Received: from asmtp3.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id t0NEf6Wf032241; Fri, 23 Jan 2015 14:41:06 GMT
Received: from 950129200 (089144224197.atnat0033.highway.a1.net [89.144.224.197]) (authenticated bits=0) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id t0NEeuPo032118 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Fri, 23 Jan 2015 14:41:04 GMT
From: "Adrian Farrel" <adrian@olddog.co.uk>
To: "'Giovanni Martinelli \(giomarti\)'" <giomarti@cisco.com>
Date: Fri, 23 Jan 2015 14:40:50 -0000
Message-ID: <006901d0371a$9e1f1960$da5d4c20$@olddog.co.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AdA3F39rUe0sT3nBRieZEz+A1ksBgQ==
Content-Language: en-gb
X-TM-AS-MML: disable
X-TM-AS-Product-Ver: IMSS-7.1.0.1576-7.5.0.1018-21276.004
X-TM-AS-Result: No--31.626-10.0-31-10
X-imss-scan-details: No--31.626-10.0-31-10
X-TMASE-MatchedRID: Qy8IQnwT72Q/FLJq3yHG9WzBijri5+RVJNroBaGZ+LW9K1jOJyKSa/U7 2nYVxvYN1eyLpsu4p9K3ISeKj4IBIP2TaclfE10aM0pZiLPQITpu/Xr6CKXiN3H+NJSyqjxjbyq cWT4FZRczkTO9kPlpFpPrkLG7Agm3ZF6ysdFjt0rx5KZMlKYS/VHewY36PuY0B6d3D+KIwZDxy/ H5BGyr4qpoI0gyGMJQ9AaJ/rCyiU1CzHFhiypoVppWgCLYjjT9Q95F2IiVUkT1bGUO+1Pc3KkLY bIpdhDAHIHA2mx0ec9Fcy9Xm9K+Vev0250SgRWKJMk7xo92oCX4uJ1REX4MHY/ysyGl2pMecQ2N 8UBEvedi4EZZUzX5yFpPtNJoAeE25lAcvk44nZXoe5XUFQlg8x7aUJN4PKIOfeHPnu31iHAEhlb ld58ez/Kw46gg+NH67QcXuKn618HpzoZfJABOunH7HV/mO4UTaBTWjXFXXd9Ev26FkhjLXcrpBM uiQ/7mrDHUBm6rZ1QhIMlpP/jXw2uCdtCAow1/71Wx2uUbPLdBldmDYjwlpqFSh25xC7TpBixx3 lAro9f8bQRM2WaSHJGTpe1iiCJqtD9qpBlNF8o/vucGn10dpvoA9r2LThYYKrauXd3MZDUD/dHy T/Xh7Q==
Archived-At: <http://mailarchive.ietf.org/arch/msg/ccamp/OCSENA4QvyxNgn2B56yyXLHmF6w>
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
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 14:41:20 -0000

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