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

[Lou Berger <[e-mail]>]

Adrian,
	
> 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.
>

I read your message as saying you think option 3 is the better way to go
wrt a future bis.  I see traffic on the list supporting this.  As
Shepherd I think this would be fine.

Unless I'm misreading you, let's move forward with making the changes to
the document to drop support for "vendor-specific unknown format".  It
will take a day or two for the authors to get the revision out, and this
will give others a chance to chime in (i.e, oppose) this if they disagree.

Thanks,
Lou

On 01/29/2015 12:17 PM, Adrian Farrel wrote:
> 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:[e-mail]] On Behalf Of Daniele Ceccarelli
>> Sent: 29 January 2015 16:34
>> To: Lou Berger; Zhangxian (Xian)
>> Cc: [e-mail]; [e-mail]; draft-ietf-ccamp-rwa-wson-
>> [e-mail]
>> 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:[e-mail]] On Behalf Of Lou Berger
>>> Sent: giovedì 29 gennaio 2015 17:22
>>> To: Zhangxian (Xian)
>>> Cc: [e-mail]; [e-mail]; draft-ietf-ccamp-rwa-
>>> [e-mail]
>>> 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 [[e-mail]] 代表 Lou Berger
>>> [[e-mail]]
>>>> 发送时间: 2015年1月29日 23:59
>>>> 收件人: Leeyoung; [e-mail]; 'Varma, Eve L (Eve)';
>>>> [e-mail]; 'Lam, Hing-Kam (Kam)'; [e-mail];
>>>> [e-mail]
>>>> 抄送: [e-mail]; [e-mail];
>>>> [e-mail];
>>>> [e-mail]
>>>> 主题: 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:[e-mail]]
>>>>> Sent: Thursday, January 29, 2015 7:24 AM
>>>>> To: Leeyoung; 'Varma, Eve L (Eve)'; [e-mail]; 'Lam, Hing-Kam
>>>>> (Kam)'; [e-mail]; [e-mail]
>>>>> Cc: [e-mail]; [e-mail];
>>>>> [e-mail];
>>>>> [e-mail]
>>>>> 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
>>>>> [e-mail]
>>>>> https://www.ietf.org/mailman/listinfo/ccamp
>>>>>
>>>>
>>>> _______________________________________________
>>>> CCAMP mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/ccamp
>>>>
>>>
>>> _______________________________________________
>>> CCAMP mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/ccamp
>> _______________________________________________
>> CCAMP mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/ccamp
> 
> _______________________________________________
> CCAMP mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ccamp
>