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

[Lou Berger <[e-mail]>]

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
>