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

"Adrian Farrel" <adrian@olddog.co.uk> Thu, 29 January 2015 17:17 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 EF7181A8547 for <ccamp@ietfa.amsl.com>; Thu, 29 Jan 2015 09:17:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -99.45
X-Spam-Level:
X-Spam-Status: No, score=-99.45 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_CHARSET_FARAWAY=2.45, 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 yMEY5n69pnjD for <ccamp@ietfa.amsl.com>; Thu, 29 Jan 2015 09:17:54 -0800 (PST)
Received: from asmtp5.iomartmail.com (asmtp5.iomartmail.com [62.128.201.176]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BF4EA1A701E for <ccamp@ietf.org>; Thu, 29 Jan 2015 09:17:53 -0800 (PST)
Received: from asmtp5.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id t0THHpxd012569; Thu, 29 Jan 2015 17:17:51 GMT
Received: from 950129200 (194-166-224-30.adsl.highway.telekom.at [194.166.224.30]) (authenticated bits=0) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id t0THHlfs012474 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Thu, 29 Jan 2015 17:17:50 GMT
From: "Adrian Farrel" <adrian@olddog.co.uk>
To: <ccamp@ietf.org>
References: <7AEB3D6833318045B4AE71C2C87E8E1729C7F0A9@dfweml706-chm> <6D32668528F93D449A073F45707153D82C533567@US70UWXCHMBA03.zam.alcatel-lucent.com> <086901d03b3a$c7386c10$55a94430$@olddog.co.uk> <7AEB3D6833318045B4AE71C2C87E8E1729C7F161@dfweml706-chm> <00ff01d03bc6$d84bbcf0$88e336d0$@olddog.co.uk> <7AEB3D6833318045B4AE71C2C87E8E1729C7F37D@dfweml706-chm>, <54CA58EC.6050108@labn.net> <C636AF2FA540124E9B9ACB5A6BECCE6B47177034@SZXEMA512-MBS.china.huawei.com> <54CA5E28.10005@labn.net> <4A1562797D64E44993C5CBF38CF1BE481284DB62@ESESSMB301.ericsson.se>
In-Reply-To: <4A1562797D64E44993C5CBF38CF1BE481284DB62@ESESSMB301.ericsson.se>
Date: Thu, 29 Jan 2015 17:17:45 -0000
Message-ID: <006101d03be7$82516180$86f42480$@olddog.co.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset="gb2312"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQJJUQOjjDfAQ8oFRmu1FlrhpmJTlQFT1EnjAetg4z8CJ7+qqAFLKtJcAlkhiAcCIomVewG+WEREAgF2pA4B3gw5sZteyIeg
Content-Language: en-gb
X-TM-AS-MML: disable
X-TM-AS-Product-Ver: IMSS-7.1.0.1576-7.5.0.1018-21292.001
X-TM-AS-Result: No--35.230-10.0-31-10
X-imss-scan-details: No--35.230-10.0-31-10
X-TMASE-MatchedRID: 8HTFlOrbAtG+9Go4BgFPZrE4IzBBqenJveCbyZ3xax7deAKnvBMxfDt5 srv8z/2aHJg6MNOhyoHsUUZmBtLXVS9FtW7XfHueA9lly13c/gFVftPGBTR0rr0rWM4nIpJrcIa DpdIRhp06XjWVhznG94R6ktsj4/uorm3mcraXo0ORfvUfL+585sLiFiL0BG1uYrcY3gxKTqxgbu 9weiOWK8Sn3Mnad3/3EgzaIwkuq2OdLySUmQFkkqtWSWds/km2IZm2INWXDp7+lfDssyh86Neul 29/x8OD4OW+eedJy6KMxND4t+zSAxoeu+OCiwrS8eSmTJSmEv1R3sGN+j7mNO8r+DLQt6+yaBux LsECVpZy5OhXKYJ/x/AhDxMQoG8AUKy/w6wtmG6aVoAi2I40/b1bhFvvQSAEayjbe4qUImPhLW+ nuKkjluAve2ZfFr+nDY48dK45B3w0CYUOpITAYmA/V00XWjDtTPt84VW1BkIQ8QCSP+YM02/91t cqPFxkFPTdWb0B54ve7SIvqh7NRrpoSDOXAaIh/vIcMN/z71uOVtPg9ibsGnt4BUfB+P48/tR55 4lM1S12gzvDp637cCLMRa7gqiBwIaVPgU+koVHThGbP9qB93IBmvqGKeYuqmnnIaNaZOLEVjAea OyL90h1QXE+gJlXHQo0mAKckAx7G2nY1KR7wCW0PWqD0pliRhEIiqNvBrmOdI/DikZ1UPBJo5yr ADTARKYTUsamWzgzvAIaR9qqmkmTaT5Js0UdSJXKk/roE/RCPmFSaq6xM+GXczQlokCRZq+1liY blo0L9VVCUNaKG6nN8NpnKQPh3sk3Xm9yiC76eAiCmPx4NwLij7XOMI0NNooPRqITj5zirusVRy 4an8bxAi7jPoeEQftwZ3X11IV0=
Archived-At: <http://mailarchive.ietf.org/arch/msg/ccamp/JZ0wEaugT0gC-1W4mQ6-01v8sxI>
Cc: 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: Thu, 29 Jan 2015 17:17:58 -0000

Hi,

It is worth looking at how you would do the bis.

Option 1 says that an implementation can put absolutely anything in the field
under a single code point.
If you want to bis that, you automatically make all implementations broken
unless you define a new OI so you would have ...
0 reserved
1 vendor-specific unknown format
2 (in the bis) vendor-specific with OUI

Option 3 says that *today* there is no such thing as vendor-specific AI. In that
case the code point is not even seen and implementations today cannot do vendor
specific stuff.
So you would have S=0 reserved
And you would bis by S=1 means vendor-specific.

Either approach works.


Now, let's discuss existing implementations.
AFAICS no-one is close to shipping product (please tell me if I am wrong).
So there is no rush.

Now let's discuss timing.
Option 1 and option 3 allow publication soon, with a bis later. The bis would
not happen until the ITU-T has finalised the format for vendor-specific AIs
Option 2 can be approached two ways
a. *Guess* which way the ITU-T will define the vendor-specific AI
b. Wait until the ITU-T has finalised the format for vendor-specific AIs.

I would like the chairs to help me and the shepherd understand the preferred
approach so that we can determine what to do with the document.

Thanks,
Adrian







> -----Original Message-----
> From: CCAMP [mailto:ccamp-bounces@ietf.org] On Behalf Of Daniele Ceccarelli
> Sent: 29 January 2015 16:34
> To: Lou Berger; Zhangxian (Xian)
> Cc: 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
> 
> I think Xian's proposal makes sense.
> 
> I would like not to hold the draft for 6 more months.
> As chair I would suggest to go for option 1 or 3 and then go for a bis when G.
874.1
> will be consented.
> As contributor, among 1 and 3 I would prefer 1 but I think 3 leaves more room
for
> a simple and straightforward bis.
> 
> Opinions on this last statement?
> 
> BR
> Daniele
> 
> > -----Original Message-----
> > From: CCAMP [mailto:ccamp-bounces@ietf.org] On Behalf Of Lou Berger
> > Sent: giovedì 29 gennaio 2015 17:22
> > To: Zhangxian (Xian)
> > Cc: 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
> >
> > On 01/29/2015 11:17 AM, Zhangxian (Xian) wrote:
> > > Hi, Lou,
> > >
> > >    I support your proposal.
> > >
> > > Just a thought: given the massive support of Option 2 from WG,  maybe
> > > we can reconcile by moving the WG draft forward using either Option
> > > 1/3, while writing a short draft to document the update needed to
> > > match the to-be-updated G.874.1? So that once it is updated, we can
> > > move the draft quickly.
> > >
> >
> > Seems right to me (as contributor)
> >
> > Lou
> >
> > > Regards,
> > > Xian
> > >
> > > ________________________________________
> > > 发件人: CCAMP [ccamp-bounces@ietf.org] 代表 Lou Berger
> > [lberger@labn.net]
> > > 发送时间: 2015年1月29日 23:59
> > > 收件人: Leeyoung; adrian@olddog.co.uk; 'Varma, Eve L (Eve)';
> > > db3546@att.com; 'Lam, Hing-Kam (Kam)'; ggrammel@juniper.net;
> > > giomarti@cisco.com
> > > 抄送: paul.doolan@coriant.com; ccamp@ietf.org;
> > > ccamp-chairs@tools.ietf.org;
> > > draft-ietf-ccamp-rwa-wson-encode.all@tools.ietf.org
> > > 主题: Re: [CCAMP] Vendor-Specific Application Code in
> > > draft-ietf-ccamp-rwa-wson-encode
> > >
> > > I thought it would be good to let things settle a bit before
> > > responding as Shepherd.
> > >
> > > So option 1 (No definition of proprietary semantics and conflicts are
> > > handled outside of the control plane, i.e., belong to operator) was
> > > the intent of the WG at the time of publication request.  This
> > > approach was also aligned with the then, and actually current, state
> > > of the ITU-T data plane (and management info) as discussed in our
> > > joint meeting. I believe option 3 (dropping the vendor specific
> > > option) isn't in conflict with this.
> > >
> > > There now seems to be support for changing the document to align it
> > > with, what I understand is, a planned update to G.874.1.  This of
> > > course implies that such a change would result in this document being
> > > blocked until that update is published in 6 months or so, and assumes
> > > no substantive change its contents.
> > >
> > > Again with Shepherd hat on, I recommend avoiding the additional delay
> > > and not tie this document to the planned G.874.1 update at this time,
> > > i.e., by following option 1 (or even 3).  This allows for a future
> > > bis/update that is align with the expected update to G.874.1 once it
> > > is published.
> > >
> > > Comments, objections, support?  (AD, authors, chairs, wg, ...)
> > >
> > > Lou
> > >
> > > On 01/29/2015 09:51 AM, Leeyoung wrote:
> > >> Hi,
> > >>
> > >> It seems like the world is against Option 1. No big deal, please provide
> > relevant text to support Option 2.
> > >>
> > >> Young
> > >>
> > >>
> > >>
> > >> -----Original Message-----
> > >> From: Adrian Farrel [mailto:adrian@olddog.co.uk]
> > >> Sent: Thursday, January 29, 2015 7:24 AM
> > >> To: Leeyoung; 'Varma, Eve L (Eve)'; db3546@att.com; 'Lam, Hing-Kam
> > >> (Kam)'; ggrammel@juniper.net; giomarti@cisco.com
> > >> Cc: 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
> > >>
> > >> Hi again,
> > >>
> > >>> There is always a priori knowledge in optical network domain as to
> > >>> who are you interfacing with. So you know which vendor you are
> > interfacing.
> > >>> If you do not know, then you are in trouble.
> > >>
> > >> Hmmm. It is exactly type of trouble we are trying to detect and protect
> > against.
> > >>
> > >> I refute your statement of a priori knowledge. I think there is a priori
> > intention, but not knowledge. Unless you have very good eyesight or
> > someone at the other end of the fiber when you give it a tug, you don't
> > know. And even then. Fibering errors happen from time to time. Consider, in
> > particular a patch panel.
> > >>
> > >>> Now, what is the purpose of standard FECs and modulations in the AI?
> > >>> Given several choices each vendor may support in its device, the
> > >>> path computation would find a matched types for FEC and modulation
> > for a given optical path.
> > >>> This is what is intended when optical signal processing constraints
> > >>> were proposed as part of path computation constraints in optical
> > networks.
> > >>
> > >>
> > >> The case you are making here is for no standard control plane!
> > >> What is the point of standardising if there is never any interworking?
> > >> But actually, we know about interworking at the physical layer, and (more
> > important) we know about a single, end-to-end control plane that spans
> > multiple vendor devices. It all exists.
> > >>
> > >> Of course, we can fall back into the old-style vendor islands, and many
> > like to do so. But it is not a compulsory deployment model.
> > >>
> > >>> There is very little chance for vendor specific FECs and Modulations
> > >>> will match even if they are identified with the OUI code.
> > >>
> > >> You have it the wrong way round!
> > >> The OUI is largely to protect against expectations of interworking when
> > none can exist.
> > >> It might (much less frequently) be used to describe the way that vendorA
> > and vendorB pick FECs and modulations in order to achieve interworking.
> > >>
> > >> Adrian
> > >>
> > >> _______________________________________________
> > >> CCAMP mailing list
> > >> CCAMP@ietf.org
> > >> https://www.ietf.org/mailman/listinfo/ccamp
> > >>
> > >
> > > _______________________________________________
> > > CCAMP mailing list
> > > CCAMP@ietf.org
> > > https://www.ietf.org/mailman/listinfo/ccamp
> > >
> >
> > _______________________________________________
> > CCAMP mailing list
> > CCAMP@ietf.org
> > https://www.ietf.org/mailman/listinfo/ccamp
> _______________________________________________
> CCAMP mailing list
> CCAMP@ietf.org
> https://www.ietf.org/mailman/listinfo/ccamp